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

Regards,
-Shishio


(2012/03/15 15:44), Acee Lindem wrote:
> 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
> 
> On Mar 14, 2012, at 11:02 PM, Shishio Tsuchiya wrote:
> 
>> Acee
>> Thank you for reply.
>> 2012/03/15 6:28), Acee Lindem wrote:
>>> [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?
>>
>> 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
>>
>>>
>>> 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?
>>
>> 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
>>
>>>
>>> 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 protected]
>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to