Subject: RE: snapshot of the new pim-sm spec is available

From: Bill Fenner <[email-masked]>
Date: Mon, 10 Jul 2000 11:08:54 -0700

>Am I to take this to mean that PIM will still contain *,*,rp support?  Sorry
>if I missed that post...

There was no clear consensus for removing it, and there are technical
reasons (like BGMP interop) for keeping it; sorry for failing to reply
after the discussion was over with my take on the result.

  Bill

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Thu, 20 Jul 2000 13:20:26 -0700

> after the discussion was over with my take on the result.

Going back to old discussion, there is still something that bothers
me re. the technical reasons for keeping (*,*,RP).

=====
In another email Dave Thaler wrote why we need (*,*,RP) for BGMP:
"...
Technically one would only need a bunch of (*,Gprefix,RP) joins per RP
but those aren't specified, so a single (*,*,RP) per RP works :)
..."
=====

The Encoded-Group-Address format in PIM-SM has a field "Mask Len",
and because the E-G-A format is used in the Join/Prune messages,
therefore we can have (*,Gprefix) J/P messages in PIM-SM.
Hence, if there is no (*,*,RP) support, the border router will
originate a number of (*,Gprefix) Joins that would be sent
(implicitly, based on the mapping in the Bootstrap messages) toward
the corresponding RP (instead of a single (*,*,RP) message).

I don't think that sending a number of (*,Gprefix) messages instead
of a single (*,*,RP) will create a large overhead.
Only if the network configuration was such that the Gprefix->RP
mapping is fragmented into a very large number of small prefixes,
then the larger number of (*,Gprefix) joins may be an issue.
However, fragmenting the Gprefix->RP mapping is anyway going to
increase the Bootstrap/Cand-RP messages overhead, so it is very
unlike that such configuration will be used in practice.

However, if there was overlapping such as, to say, 224.0.0.0/8 maps
to RP1 and 224.1.0.0/16 maps to RP2, then the (*,Gprefix) joins
need to be sent toward the right RP. If the upstream routers
toward RP1 and RP2 were the same, sending a single 224.0.0.0/8 Join
should be OK. However, if an intermediate router receives
224.0.0.0/8 Join, and the upstream routers toward RP1 and RP2 and
different, then it needs to send, for example, 224.1.0.0/16 Join
toward RP2 and (224.0.0.0/8 Join, 224.1.0.0/16 Prune) toward RP1.

If the intermediate routers cannot handle at all the (*,Gprefix)
J/P, then we need (*,*,RP) to fix the situation.
However, if a router handle (*,Gprefix) by just splitting each
(*,Gprefix) Join/Prune into a number of (*,G) Join/Prunes,
we still can get away by removing the (*,*,RP) support. The large
number of (*,G) messages will be per-hop, because an upstream, more
intelligent router can always aggregate them back into (*,Gprefix).

Here is the time to ask two questions:

 * How do implementations that have been widely deployed handle
   (*,Gprefix) J/P messages?

 * Shoudn't the spec be explicit how a router has to handle a
   (*,Gprefix) J/P messages?

====
In another email Yunzhou Li wrote:

"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."
====

If, instead of a single (*,*,RP) join message, a router receives all
(*,Gprefix) joins that match this (*,*,RP) state, the router needs
a little intelligence to find out that logically all those
(*,Gprefix) joins correspond to a single (*,*,RP). But even without
applying this logic, the mechanism used by this router to aggregate
its state is up to the implementation, and the external (*,*,RP)
join message will not help the router in making/improving the
aggregation decision. 

Apart of those two arguments, I did not see any other reasons why
we need (*,*,RP) support. Am I missing anything else?

Pavlin