Subject: Re: PIM hello option DR priority

From: John Meylor <[email-masked]>
Date: Thu, 01 Jun 2000 14:51:33 -0700

Liming Wei wrote:
> I can think of the following few options to move forward:
> 
>  1) Deprecate both values of 19 and 18 as valid Hello options.
>     Assign new values to both DR-prio and Bi-Dir options. Everyone
>     needs to switch;
> 
>  2) Keep the current PIM-SM option value assignment, and let those
>     who implemented draft-ietf-idmr-pimv2-dr-priority-00.txt
>     change their code;
> 
>  3) Deprecate the current Bi-Dir option code 19, making it the
>     DR priority election priority code again. Make code 18 an
>     invalid option, and reassign a new code for Bi-Dir option

Ok, 
 We'd like to propose the following then for resolving this:

- First, we support proposal #3 (and we'll move to change our 
implementation to use 19 for TLV for DR priority.)  Note, this 
will effect deployed implementations using 18 (including ours), 
but will resolve the deadlock on this and provide a consistant 
reference for all other implementations moving forward.

We propose that it is up to implementation whether to interop
with implementations using values other than 19 for DR priority.

- Second, since 19 was also described for use by bidir in certain docs
(like most recent PIM-SM draft) we would propose that we also 
standardize now on 22 as PIM Hello TLV option for bidir for all
future implementations.

- Finally, since any DR priority implementation today is based on
expired documentation, and to avoid similiar confusion with other PIM
Hello TLV options in the future, we propose that all PIM Hello options
be specified in an information draft (we will submit this for next
IETF), which can either proceed to RFC or perhaps be incorporated into
the next valid PIM-SM/SSM draft, and that any ref to PIM Hello options 
in other drafts be updated to reflect use of 19 for DR priority 
and 22 for bidir, or use a reference which reflects these numbers.

Anyone see problems with this approach?

 John

---

From: Liming Wei <[email-masked]>
Date: Thu, 1 Jun 2000 15:45:11 -0700 (PDT)

> Date: Thu, 01 Jun 2000 14:51:33 -0700
> From: John Meylor <[email-masked]>
> 
> Liming Wei wrote:

Good. I expect this to be acceptable to most folks.

> and 22 for bidir, or use a reference which reflects these numbers.

I'd suggest to go one step further. I think this should be
incorporated into the exsiting spec, and Yiqun should submit the
existing PIM-SM spec with this update as an informational RFC (with
minimal editorial work). This will be useful after the current spec
has expired, and a complete re-written new spec shows up.

 Comments ?

-Liming

---

From: John Meylor <[email-masked]>
Date: Thu, 01 Jun 2000 16:36:22 -0700

> has expired, and a complete re-written new spec shows up.

I believe at the last IETF the decision was to have Hugh/Bill/Mark
others proceed on new PIM-SM draft which includes SSM descriptions
as well new re-write of PIM-SM thus addressing some of issues in existing
PIM-SM draft.  I believe a first draft may be available at next
IETF (I'll let aurhors speak on that), but if so, then that might
be useful location for listing PIM Hello options.

 John

---

From: Thomas Maufer <[email-masked]>
Date: Thu, 1 Jun 2000 19:47:39 -0700

>Anyone see problems with this approach?

John--

Not a problem, but a document would be perpetually
out of date.  Why not document all current (agreed-
on) values and then pass the info to IANA and let
them administer the Hello Option value space?

My $0.005,
Tom
-- 
Thomas Maufer                 It's never too late to be            |o|
                                  what you might have been.        |o|
PGP Key Fingerprint (DSS):         -- George Eliot                 |o|
 0E37 CE46 9D05 63C5 BD8C                                          |o|
 1242 5240 843D A36B FEB1  _________________________________________ |

---

From: John Meylor <[email-masked]>
Date: Thu, 01 Jun 2000 20:03:30 -0700

> them administer the Hello Option value space?

yes, I understand this was also proposed during talks 
about the new PIM-SSM/SM draft, so perhaps the authors
have more recent insight on this approach. I think its
excellent idea.

 John