Subject: [pim] [[email-masked]: PIM WG meeting in Yokohama needs to be cancelled]

From: Liming Wei <[email-masked]>
Date: Tue, 9 Jul 2002 11:06:16 -0700 (PDT)

Folks,

The PIM WG will not meet in Yokohama this time. But please continue the
discussions, send updates or progress report on the list.

 Thanks,
-Liming

------- Start of forwarded message -------
Return-Path: <[email-masked]>
Delivered-To: [email-masked]
Date: Tue, 9 Jul 2002 11:04:59 -0700 (PDT)
From: Liming Wei <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked]
Subject: PIM WG meeting in Yokohama needs to be cancelled
Reply-To: [email-masked]

Hi,

Neither Tom or I will be able to attend the Yokohama IETF, and the PIM
WG meeting (Routing area), on Tues morning, will need to be cancelled.

There has been no request for presentation slots from authors of any
WG drafts. The DM spec and the PIM MIB authors have short status updates
but will not be there in Yokohama.

 Thanks,
 
- -Liming Wei
------- End of forwarded message -------
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Tue, 09 Jul 2002 16:00:52 -0700

Liming:

I want to again question the need for sending a Prune message to the old
RPF router when there is a change in unicast routing.  It was discussed
On this list at one time but I don't see any changes in the spec that is
Currently available.  (probably because I didn't bring it up -that- long
Ago.)

It seems that it is "obvious" that pruning the old route is the right
Thing to do, but in practice not all routers on a network get the same
Information at the same time so on multiaccess links, the result of
Pruning the old path will result in another router sending a join
To override that prune, only to end up sending the prune again
Later when it finally figures out what the unicast routing is doing.

So in practice the result is that the upstream routers choose who is
Going to be the forwarder through an assert process, and all the
Prunes to the old RPF neighbor don't help anything but cause the
Routers to spin.

Even on p2p links, pruning the old RPF isn't necessarily all that helpful
Since one route flap generally results in another.

2cents

---

From: Mark Handley <[email-masked]>
Date: Tue, 09 Jul 2002 16:19:36 -0700

>Since one route flap generally results in another.

This was discussed at the last IETF.  My recollection is that we
decided that it didn't make a great deal of difference either way - in
that the plus side and minus side of sending prunes vs not sending
prunes seemed fairly even.  In neither case is the worst-case terribly
bad.  

So the conclusion was to leave the spec unchanged on this issue.

 - Mark