Subject: Re: PIM hello option DR priority

From: Bill Fenner <[email-masked]>
Date: Tue, 30 May 2000 23:51:28 -0700

>I disagree. This option doesn't address all the backward interop 
>issues. The discussion is still open, IMO.

What are the options, as you see it?  Liming's message listed:

 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

#1 maximizes the pain for everyone, so seems like a bad idea (but perhaps
the most fair).

#2 is the best for cisco, and for anyone who implemented the DR-priority
option after October 1999.  However, since the value of #19 was the most
recent value published for the DR-Priority option from March 1998 thru
October 1999, it hardly seems fair to those who implemented from the best
resource available to them.  (The argument that the I-D was expired is,
IMHO, bogus; what are people who want to implement the DR priority option
*supposed* to do except use the latest information available, whether
it's an expired I-D or not?  Also, the assertion that the PIM-SM spec
with the changed DR-Priority option assignment was posted on the PIM
mailing list is not backed by the mailing list archives.)

#3 is the best for people who implemented from the DR priority draft.

Do you see any other options?

  Bill

---

From: Yiqun Cai <[email-masked]>
Date: Wed, 31 May 2000 09:07:18 -0700 (PDT)

> Do you see any other options?

No, I don't see any other options.

In the meantime, I don't think this is going to be an easy or 
painless transition, so I want to take some time to really 
understand all the ramfication. I hope we don't rush into any 
decision.

To me, which option to take is not just based on the pain to the 
implementors. We must also consider the backward compatibility 
issues. After all, we implement a protocol so that people can use.

BTW, in my view, #2 is at least as good as #3. 

-- 
Yiqun