Subject: Re: [OSPF] status of draft-ietf-ospf-rfc3137bis

From: Acee Lindem <[email-masked]>
Date: Wed, 14 Mar 2012 17:28:09 -0400

[Speaking as a WG member]

Hi Shishio,

I guess I didn't read this close enough the first time. 

On Feb 28, 2012, at 2:15 AM, Shishio Tsuchiya wrote:

> Acee
> Thank you for information.
> But a lot of vendors already supported the high link metric to announce as stub.
> Therefore I think the draft should describe both of high link metric and R-bit.
> What do you think if the author add only one or two sentence which mentioned exist of R-bit to current internet draft?

Due to its simplicity, I think the R-bit should be the preferred option. Since all OSPFv3 implementations should support the R-bit, there are no compatibility issues. Does everyone agree? 

The only value I can see in using the high-link metric is that it allows the existing implementations you cite to say they conform this draft.  Is that worth having two mechanisms? 

Thanks,
Acee 

> 
> Regards,
> -Shishio
> 
> (2012/02/28 7:23), Acee Lindem wrote:
>> Hi Shishio,
>> If I remember correctly, there was discussion as to whether to just use the R-bit rather than the high link metric for OSPFv3. Given the goals of the draft, I'd be in favor of this change.
>> Thanks,
>> Acee
>> On Feb 24, 2012, at 12:04 AM, Shishio Tsuchiya wrote:
>> 
>>> Hi
>>> After this draft be WG documents,it expired.
>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-rfc3137bis/
>>> 
>>> Was there any objection? or just maintenance issue?
>>> 
>>> Regards,
>>> -Shishio
>>> _______________________________________________
>>> OSPF mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ospf
>> 
> 
>

---

From: Shishio Tsuchiya <[email-masked]>
Date: Thu, 15 Mar 2012 12:02:40 +0900

Acee
Thank you for reply.
2012/03/15 6:28), Acee Lindem wrote:
> Due to its simplicity, I think the R-bit should be the preferred option. 
> Since all OSPFv3 implementations should support the R-bit, there are no compatibility issues. Does everyone agree?

Yes,I strong agree that OSPFv3 should support the R-bit.
It's described on rfc5340.
My draft described two mode R-bit and high link metric.
http://tools.ietf.org/html/draft-shishio-ospf-ospfv3-stub

I thought Alvaro's the draft should describe only high link metric.
http://www.ietf.org/proceedings/80/slides/ospf-2.pdf

> Is that worth having two mechanisms?

I could not find any difference essentially in 2 modes when I wrote the draft and discuss about this topic.
But merit of high-link metric are
-easy to implementation : most of vendor already supported this mode.
-same operation OSPFv2 and OSPFv3: the operator needs to check metric value.(do not need to know new bit)

I agree R-bit should be preferred option, but I think the draft should describe high-link metric also.

Regards,
-Shishio

---

From: Acee Lindem <[email-masked]>
Date: Thu, 15 Mar 2012 10:44:48 -0400

Hi Shishio,

I just looked at the expired draft and it doesn't include any discussion of the R-bit. 

http://tools.ietf.org/id/draft-ietf-ospf-rfc3137bis-00.txt

Can you put that in the next revision? 

Thanks,
Acee

---

From: Shishio Tsuchiya <[email-masked]>
Date: Mon, 26 Mar 2012 13:42:41 +0200

Acee
I had discussed Alvaro and co-authors about this by mail.
Alvaro will update the draft after this ietf.

Regards,
-Shishio