Subject: Re: [pim] PIM State Refresh Reduction

From: Toerless Eckert <[email-masked]>
Date: Fri, 12 Nov 2004 11:26:03 -0800

To repeat on the mailing list what i said during the working group meeting:

a) "The PIM-SM RFC is first"

   We first need to have the current PIM-SM draft go out the door and
   become an RFC. No changes whatsoever from the WG are to be considered
   for this draft anymore.

b) "refresh reduction is not the same as PIM Hello reduction"

   We should clealy differentiate between "PIM refresh reduction" that i
   think applies primarily to PIM j/p messages (and maybe asserts) and
   "PIM Hello reduction" because i think there may be common requirements
   for "PIM refresh reduction" across different solutions, but likely
   different "PIM Hello reduction" methods in different solutions.

   As an example, in networks with large scale numbers of directly 
   connected PIM routers (like a satellite network), actual PIM Hello
   _reduction_ is likely required, whereas in MVPN and other large scale
   networks with indirectly connected PIM neighbors, PIM Hellos might
   rather be completely replaced by for example leveraging some form of
   BGP information.

c) "Useful but not mandatory for MVPN"

   Refresh reduction came up as a result of a discussion in L2VPN about
   the rosen MVPN draft. There is i think no agreement as to what importance
   refresh reduction has for moving that draft forward.
   
   I think that refresh reduction is absolutely NOT a mandatory requirement 
   for MVPN work to progress. I think it would be a very good option
   for future scalability extensions though, but by beng targeted as a
   generic PIM improvement it logically becomes a modular issue independent
   of the actual MVPN specs.

d) "More work for PIM than just refresh reduction"

   I think it is premature to focus right now purely on refresh reduction
   for PIM as the most important task. I rather think we need to step
   back and collect input as to what functionalities in PIM-SM/Bidir-PIM
   are missing from the new RFC(s), collect this information, prioritize it
   and then find appropriate solution. Playing ramdom-pick in before
   such an analysis will i think lead to a waste of time.

   I for once think that there is a lot to be said about providing a
   solution for Hello and refresh reduction, as well as reliability
   and flow-control for PIM messages to get fast&reliable convergence.

   Right now PIM really sucks in that respect and while that opens up
   the market for optimized implementations to overcome those
   intrinsic protocol problems, i think it is not acceptable to stick with a
   messaging system that effectively relies on non-flow controlled bursts
   of maybe multiple megabytes of messages in the case of reconvergence.

   In my opinion too, the logical conclusion is to provide at least
   as an option a hard-state reliable (maybe TCP) based signalling
   for PIM on a per-interface basis mostly important for backbone
   interfaces), but such conclusions really should only be revisited
   after collecting and agreeing of priorities of missing features/
   performance limitations.

So, if possile, could we please adjust the scope of evlaution or
work to be done ?

Thanks
    Toerless

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 12 Nov 2004 12:44:48 -0800

Toerless,

Thanks for your comments! You have some great points.

>   become an RFC. No changes whatsoever from the WG are to be considered

The Sparse mode spec is for all practical purposes out of the hands
of the working group. There is no intention to try to add anything to
the sparse mode draft at this point.

>   different "PIM Hello reduction" methods in different solutions.

The work item that was communicated to me was "state refresh reduction".
If the working group determines that this is a smaller part of a larger
problem, we can propose larger changes that fix more than just the
periodic join/prune issue.

It might also help to get an official write up from the L3VPN
working group to make sure we solve the problem they are asking us
to solve. I will send a note to the working group chairs to
obtain this.

>   refresh reduction has for moving that draft forward.

I understood it to be generally useful for all of the MVPN proposals,
not just the rosen one.

>   of the actual MVPN specs.

Yes, state refresh reduction is useful outside the context of VPNs.
It is useful simply with a large number of (S,G) joins in core routers.

>   such an analysis will i think lead to a waste of time.

As a working group, we work on the items we are chartered to work on.
The state refresh reduction has become a work item based on the request
of the chairs of the L3VPN working group. Our charter should be
updated to reflect this.

There is a process for updating the charter which includes discussion
amoung the working group and approval by the area directors.

So if you have other proposals of work items for the working group
to consider, please send them to the list for discussion. In the
past, the area directors would not allow us to add new items to our
charter because they were using the only leverage they have in order
to force us to complete the existing work items on our charter which
was to not allow us to add new work items. Since we have been
effective in completing our list, they are now more willing to allow
us to propose new work items.

The importance of work items to the working group will depend on the
importance of the items to the individuals who make up the working
group. "State refresh reduction" may be more important to some than
others.

Fortunately, the working group can work on multiple items at the same
time and the work can be spear headed by different individuals.
I asked for interested individuals to work on "state refresh reduction".
As other work items become clear, we will also ask for interested
individuals to work on these items. They do not have to be the
same individuals but there may be some overlap. The teams can work
independently and progress at different rates.

>So, if possile, could we please adjust the scope of evlaution or

This is a great topic for discussion.

Yes, it is possible to expand the "state refresh reduction" work item
into something larger that solves other problems. The first step is
to identify the problems we currently have with PIM so we can decide
how many of them we want to solve at once or how many different sub groups
we create to work on items.

>From our emails, the list currently looks like this:

1. reduce processing of periodic join/prunes

	This kind of implies reliable messages because if you get rid
	of periodic updates then you have to guarantee that you received
	the messages. But I'm not sure reliable messages in itself is
	a work item. Reliable messages are more of a potential solution.
	But some clever participant may discover a way to reduce periodic
	join/prune processing without reliable messages so lets not
	discuss solutions yet.

2. fast convergence

	You say "fast & reliable convergence" but I think convergence
	implies reliable.

	We need a goal or metric to measure our success here.
	How fast is fast? How do we determine convergence?

	Today, do we not converge and so we want to modify the protocol
	to guarantee convergence or do we converge but just not fast enough
	and so we need to decrease the convergence time?

	What would you like to see?

3. reconvergence burstiness

	This sounds mostly like an implementation issue to me but
	I would like to understand more about your thoughts. What
	is the problem you are trying to solve here? Are you afraid
	of dropping joins/prunes because of receive buffer overflow?
	Or CPU load due to being bombarded with RPF changes?

	This one conflicts with "fast convergence" so we need to compromise
	between these two.

Did I miss any? Anyone else having problems with PIM they want to fix?

Thanks,
Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 12 Nov 2004 14:15:27 -0800

>> So, if possile, could we please adjust the scope of evlaution or

    How about:

    e) Nothing needs to change because it works good enough.

Dino

P.S. A 747 doesn't take me to the grocery store very well. But it doesn't mean
     the plane is broken.

    To be more blatant about my analogy. Just because people think PIM won't
    work well for MVPNs might mean that MVPNs don't work well rather than 
    PIM not working well.

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 13 Nov 2004 08:09:42 -0800

>     work well for MVPNs might mean that MVPNs don't work well rather than 

Too bad you were not at the IETF meeting, that would have given a whole
other dimension to the discussion. If my memory serves me correctly,
Jakhov did imply in L3VPN at one point the equivalent to "we did design 2547
as a 747 for a reason - it is needed". And then there was one customer who
complained that they bought routers for the price of a 747 but it only gets
them to the grocery store.

I think that i asked for more accurate metrics for any scalability discussions.

Cheers
	Toerless

---

From: Suresh Boddapati <[email-masked]>
Date: Sun, 14 Nov 2004 23:18:52 -0800 (PST)

Tom,

I think reconvergence burstiness can be an issue if we
are talking about scaling PIM to hundreds of thousands
of entries. And IMO, solving reconvergence burstiness
is not necessarily in conflict with the goal of fast
convergence.

For example, on an RPF change that effects a lot of
(S,G) entries, if a Join PDU is dropped (for whatever
reason, including exhaustion of rx buffers at the
upstream router), there is no way for the downstream
router to know that. The result: until its Join timer
expires and the state is refreshed again (the default
is 60 seconds per the PIM spec), the flow(s) will not
be received on that interface. And the chances of this
happening increases during burstiness. The question
is, is this disruption acceptable? In some cases,
especially in a MVPN environment, it may not be. 

Most protocols have one way or the other to resolve
this issue. OSPF has explicit acknowledgements (LS
ACKS), ISIS uses CSNPs/PSNPs to detect this and BGP of
course uses TCP. So even if something gets dropped,
the recovery happens "reasonably" quickly. This is not
the case with PIM. Now if you measure convergence as
how soon all the flows are back up after an event such
as a RPF change, which can be a cause of burstiness,
you can see how these two can be related. 

If you solve the burstiness problem using schemes such
as pacing, then yes, it conflicts with fast
convergence in the sense that it will not converge as
fast as it would have if there were no pacing of the
Joins transmitted (in the event that no packets were
lost). On the other hand, if you add reliability of
some sort, then there is not necessarily a conflict
since the convergence will solely depend on how many
JP packets were lost and how soon they can be
"recovered". In other words, you could burst and if no
packets were lost, then the convergence would be the
same as today, but if you did lose something, then the
convergence will be significantly faster than what it
would be without reliability. A combination of the two
schemes would be a desirable compromise indeed. 

Comments?

Suresh

====================================================
3. reconvergence burstiness

	This sounds mostly like an implementation issue to me
but
	I would like to understand more about your thoughts.
What
	is the problem you are trying to solve here? Are you
afraid
	of dropping joins/prunes because of receive buffer
overflow?
	Or CPU load due to being bombarded with RPF changes?

	This one conflicts with "fast convergence" so we need
to compromise
	between these two.

Did I miss any? Anyone else having problems with PIM
they want to fix?