Subject: Re: New PIM version 2 dense mode specification

From: Tom Pusateri <[email-masked]>
Date: Fri, 12 Mar 1999 17:45:42 -0500

I was going to write a draft on a new neighbor option as well but
maybe we can merge ideas and save some bits.

I wanted add a hello neighbor option that includes:

1. Generation ID (as you specified)
2. Router ID (for detection of parallel links)
   Use encoded source address
   What you do with them is another issue... ;-)
3. interface mode
   bitfield with low order bit for dense mode and next significant bit
   for sparse mode. (secretly lets you encode sparse-dense mode without
   it needing to be mentioned in the spec.) ;-)
4. list of neighbors you've heard hellos from as encoded source addresses
   A 3-way handshake is desperately needed in PIM.

So if you want some text, I'll be glad to contribute or if you'd rather
I just go on and write it all separately and not mess up your draft,
that will be fine too.

Thanks,
Tom

In message <[email-masked]> you write:
>> From: Yunzhou Li <[email-masked]>
>> 
>> We will appreciate it if you can cite our proposal for the GenID option
>> in your reference list...
>> 
>
>Sure, just skimed through your draft. There should not be any serious
>issues on such a minor option :-). But I do have three comments
>
> 1) The action of triggering join/prunes is over-specified since
>    the triggering already happens due of the "unicast" RPF change;
>
> 2) Using the wall clock seconds as GenID is no good; A router can easily
>    get to that instruction within the same "second" each time it reboots.
>    This is why we didn't put down an example of what a "usual" random
>    number is in the latest PIM dense mode spec;
>
> 3) You probably want to resubmit it under the PIM working group (i.e. if
>    you want PIM working group members to find it easily).
>
>    We'll add a reference in the PIM sparse mode draft to your draft.
>
>    Also let Tom/me know if you want to do a presentation at Minneapolis
>    on this subject.
>
>Let me know how this sounds.

>-Liming

---

From: Liming Wei <[email-masked]>
Date: Fri, 12 Mar 1999 14:21:11 -0800 (PST)

-Liming

---

From: Yunzhou Li <[email-masked]>
Date: Fri, 12 Mar 1999 18:07:20 -0500 (EST)

Liming,

Thanks a lot for your comments...

>     the triggering already happens due of the "unicast" RPF change;

Agree... but in case a downstream router does not have parallel
paths to the source, the "unicast" RPF change would not happen...

>     number is in the latest PIM dense mode spec;

Sorry, my intention was to use the mini-seond portion of the wall clock.
Agree, we don't have to specify any particular algorithm to generate 
the random number...

>     you want PIM working group members to find it easily).

Okay, we'll do it that way for next version ;-)

>     We'll add a reference in the PIM sparse mode draft to your draft.

Thanks...

>     Also let Tom/me know if you want to do a presentation at Minneapolis

I am not able to attend this coming IETF because my baby will be coming
out in next few days ;-).  Billy, can you make it, please?

Thanks,
Yunzhou

---

From: Liming Wei <[email-masked]>
Date: Fri, 12 Mar 1999 15:15:36 -0800 (PST)

> From: Tom Pusateri <[email-masked]>
> 

It seems cycling through the equal cost unicast routes can do the same
trick ?  Can the router IDs be borrowed from the unicast routing table ?
Wanna write a brief draft on what benefits the router ID has ?

>    it needing to be mentioned in the spec.) ;-)

Understand. It was forced by history, rather than done intentionally :-).
I guess all PIM authors are reading this, maybe this time we can
put the bits in...

>    A 3-way handshake is desperately needed in PIM.

We have more than 3-way handshake, it is infinite-way handshake,
except it is done slowly :-). Please explain what this really is.

> I just go on and write it all separately and not mess up your draft,

Sure. How about a brief note with more explanations, to make it easier
for other people to go through. Don't worry about messing the draft,
we can freeze the current ones, and work on the "next revision" at
the same time. I guess the 20-some implementation projects will
benefit from the frozen specs.

BTW, do you want your proposal(s) to be immeidately reflected in
the "semi-frozen" specs, or to be incoporated in the "next revision"
specs ?

-Liming

---

From: Yunzhou Li <[email-masked]>
Date: Fri, 12 Mar 1999 18:33:25 -0500 (EST)

Tom,

Sure we are open and appreciate your working with us on the merged
ideas. Thanks!

>    it needing to be mentioned in the spec.) ;-)

Looks great to me...

>    A 3-way handshake is desperately needed in PIM.

We used to include a list of neighbors. But later we decided to take it
away because hello timeout value was 105 seconds while hello interval is
30 seconds and it seems not to buy us a lot. Do you have any specific
issue for this need?

> I just go on and write it all separately and not mess up your draft,

Again, we are happy to work with you to merge ideas as a single option.
Maybe we can discuss offline in more detail...

Thanks,
Yunzhou

---

From: Liming Wei <[email-masked]>
Date: Fri, 12 Mar 1999 15:55:19 -0800 (PST)

> If I send a hello before I receive a hello, my neighbor will start
> flooding me with traffic and I won't have an upstream neighbor yet.
> This needs to be solved. A neighbor list is one way to solve it.
> I'm open to any other ways.

Sounds interesting. Care to write up some more details ?

> I don't have a preference.

Ok, Then let's lean on the "next revision".

-Liming

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 12 Mar 1999 18:44:59 -0500

>Wanna write a brief draft on what benefits the router ID has ?

The links don't have to be equal cost but it is nice to know they
go the same place. The cost of comparing a router id to doing route
lookups is also much lower. For 4 bytes, it seems silly not to.

Thanks,
Tom