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

From: Bill Fenner <[email-masked]>
Date: Fri, 9 Jun 2000 14:41:14 -0700

>> 3) Most importantly, does anyone have any objections to eliminating
>>    the (*,*,RP) functionality?
>
>I agree that DWR is a better way. But my only concern is how widely
>is it being used, especially in the existing dense mode stub areas
>like enterprises.  I know of at least one vendor which has only PIM-DM
>and does not have support for DWR. All such enterprises would need to
>add DWR supporting router interfaces on all of their internal LANs to
>transition to DWR.

But are these people using (*,*,RP) now?  So far, only 2 out of 6 vendors
who have replied support (*,*,RP), and you're the only one who has PMBR.
(*,*,RP) is not useful for attaching a dense mode stub to the existing
infrastructure, since there are no global RP's.  It's really most useful
for attaching a sparse mode stub to a dense mode backbone.

>Are there other good reasons to not include <*, *, RP> in protocol
>specification?

Simply elimination of unnecessary complexity with no clear gain.
(*,*,RP) probably can't be represented in forwarding hardware, since to
match (*,*,RP) state you have to hash the G.

  Bill

---

From: Liming Wei <[email-masked]>
Date: Fri, 9 Jun 2000 15:55:54 -0700 (PDT)

> From: Bill Fenner <[email-masked]>
> Date: Fri, 9 Jun 2000 14:41:14 -0700
> 

We need to keep the public documentation of implemented machineries.
It is hard to exhaust the deployment scenarios. Plus, one man's
poison can be another's delicacy.

I'm for a better version of the PIM SM spec, but I'm against deleting
the (*,*,RP) mechanism all together. It needs to be documented
somewhere in the public place. One way to do it is to put the current
SM spec into the RFC repository. If not as a standard track document,
it can be an informational RFC reflecting implemented and deployed
machineries. As newer implementations come by, they can get obsoleted
by lack of reference.

-Liming

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 9 Jun 2000 17:13:42 -0700

>> machineries. As newer implementations come by, they can get obsoleted

    Furthermore, we don't want people to reinvent (*,*,RP).  

Dino

---

From: Mark Handley <[email-masked]>
Date: Fri, 09 Jun 2000 17:53:27 -0700

>machineries. As newer implementations come by, they can get obsoleted

If it's going to get obsoleted anyway, it's better to remove it from
the ongoing standards track document - it would have to be removed
when the document goes to Draft Standard anyway.

It's already documented in RFC 2362, so probably doesn't need a
separate document unless the (*,*,RP) mechanism has changed
significantly since then, which doesn't seem to be the case.

 - Mark

---

From: Liming Wei <[email-masked]>
Date: Fri, 9 Jun 2000 18:02:54 -0700 (PDT)

> From: Mark Handley <[email-masked]>
> Date: Fri, 09 Jun 2000 17:53:27 -0700
> 

True.

> significantly since then, which doesn't seem to be the case.

There have been numerous corrections and changes on other operations
that affect it. I am sugggesting this only because I had email
exchanges with (*,*,RP) implementors from at least 4 or 5 different
companies/organizations in the past.

-Liming

---

From: Dave Thaler <[email-masked]>
Date: Fri, 9 Jun 2000 20:34:48 -0700 (PDT)

> for attaching a sparse mode stub to a dense mode backbone.

As a co-author of the BGMP spec, I'd respond (to the chair of the BGMP
WG... :) that when PIM-SM is used as the IGP, while the recommended scenario
is to have the BR's be RPs, some people have suggested that they would
prefer the luxury of having the RPs and BRs be separate (go figure).

To allow this, I think you either have to use MSDP internally (with its 
potential encapsulation problems) or (*,*,RP) from the best exit router 
back to the RP.  Removing (*,*,RP) would have the effect of leaving only 
two options: MSDP and RP=BR.  This is probably acceptable but it's worth
knowing.

-Dave

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 11 Jun 2000 15:42:37 -0700

>> two options: MSDP and RP=BR.  This is probably acceptable but it's worth

    This is not acceptable architecturally. BGMP is suppose to scale inter-
    domain multicast better than current solutions. Thereby, allowing to
    not use all the current solutions. Requiring both MSDP and BGMP, plus
    having to run PIM inside your domain is a maintenance nightmare for the
    poor network operator.

Dino

---

From: Liming Wei <[email-masked]>
Date: Sun, 11 Jun 2000 22:21:23 -0700 (PDT)

> From: Dino Farinacci <[email-masked]>
> 

To allow BGMP to function without restriction as a commonly accepted
long term solution, the new PIM-SM spec should contain (*,*,RP).

-Liming

---

From: Dave Thaler <[email-masked]>
Date: Mon, 12 Jun 2000 10:45:36 -0700 (PDT)

>     having to run PIM inside your domain is a maintenance nightmare for the

BGMP does not require you to run PIM or MSDP, as you appear to be arguing
against.

-Dave

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 12 Jun 2000 10:50:32 -0700

>> BGMP does not require you to run PIM or MSDP, as you appear to be arguing

    But running an already widely deployed PIM with various strategies fro
    RP placementt makes it nearly impossible to deploy BGMP.

Dino