Re: [OSPF] OSPF WG Minutes from IETF 95

["Acee Lindem (acee)" <[e-mail]>]

On 4/11/16, 8:13 AM, "prz" <[e-mail]> wrote:

> On Sun, 10 Apr 2016 21:56:46 +0000, "Acee Lindem (acee)"
> <[e-mail]> wrote:
>> The minutes for are posted here:
>> https://www.ietf.org/proceedings/95/minutes/minutes-95-ospf
>>
>> Thanks to Les Ginsberg from Cisco for taking them.
>>
>> Note that there were two names that we were not sure of and they are
>> preceded with “(???)”. Please E-mail me if you know either of these
>> full
>> names and I will update the minutes.
>>
>
> hmm, reading minutes & grinning, wasn't that you that chided me on the
> mike 2-3 IETFs ago
> with "by now since 10 years e'one got the max-link-metric stuff right"
> ;-)

I guess I underestimated the inherent fallibility of software produced by
homo sapiens ;^).

David Lamparter did some research and found that RFC 1247 (July, 1991)
actually had LSInfinity defined as a variable length constant:


LSInfinity
    The link state metric value indicating that the destination is
    unreachable.  It is defined to be the binary value of all ones.  It
    depends on the size of the metric field, which is 16 bits in router
    links advertisements, and 24 bits in both summary and AS external
    links advertisements.


Additionally, the link would not be used for transit traffic (section
16.1): 


    (d) If the cost of the link (from V to W) is LSInfinity, the link
        should not be used for data traffic.  In this case, examine the
        next link in the advertisement.


However, this was changed in RFC 1583 (March, 1994).

 LSInfinity
        The metric value indicating that the destination described by a
        link state advertisement is unreachable. Used in summary link
        advertisements and AS external link advertisements as an
        alternative to premature aging (see Section 14.1). It is defined
        to be the 24-bit binary value of all ones: 0xffffff.

If in 2016 (22 years later), one particular implementation chooses to not
comply to the specification, then there really isn’t anything the WG can
do about it. The draft
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ allows a
link to be used exclusively for non-transit traffic. Of course, if you
also didn’t want to use the link for any traffic you simply wouldn’t
advertise it. 

Thanks,
Acee 





>
> Agree on the comment with the bandwidth encoding. No need to invent
> another one.
>
> --- tony