Re: [OSPF] OSPF WG Minutes from IETF 95

"Acee Lindem (acee)" <acee@cisco.com> Mon, 11 April 2016 15:29 UTC

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F116912F08A for <ospf@ietfa.amsl.com>; Mon, 11 Apr 2016 08:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFwYUo2crE_X for <ospf@ietfa.amsl.com>; Mon, 11 Apr 2016 08:29:34 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8386F12F088 for <ospf@ietf.org>; Mon, 11 Apr 2016 08:29:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3408; q=dns/txt; s=iport; t=1460388574; x=1461598174; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1kr1nfdv2ZaS3bT3D0YDyIWMTbiN+69FSpgz/7VO5h8=; b=BATjpaSNu8tT6dSuhqyLtCLfm5EWY8KCsKeTIn+lYkv32btQKF/Z8Hhw mm3Gp/W7fkzK6VfI6KXtHHI9axzdawVD4Jy6iliDHHKwXN1lzTqeuTf47 WeHop1/17zbqarwGhNqSz/uvZ6G3fM/xVk9HgO8wuX60XZoCHv91YXn7E I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxBQCcwQtX/5BdJa1cgzdTfQa4RoIdg?= =?us-ascii?q?XIhgjyDMAIcgRE6EgEBAQEBAQFlJ4RBAQEBAwEjEUUFCwIBCBgCAiYCAgIwFRA?= =?us-ascii?q?CBA4FiB8IDq0OkVsBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyJcIRVgmqCVgWYB?= =?us-ascii?q?AGFdogVgWeETYhZhh+JBgEnDS6CBBmBSmyJLX4BAQE?=
X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208";a="95887887"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2016 15:29:33 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3BFTXp4004274 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Apr 2016 15:29:33 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 11:29:32 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 11:29:32 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: prz <prz@zeta2.ch>
Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95
Thread-Index: AQHRk+ug+9xkeFSUNUaQhV0sMu+UBZ+E5gwA
Date: Mon, 11 Apr 2016 15:29:32 +0000
Message-ID: <D3313626.58E6F%acee@cisco.com>
References: <D330445B.58C7B%acee@cisco.com> <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch>
In-Reply-To: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.202]
Content-Type: text/plain; charset="utf-8"
Content-ID: <420A9D780C54544D9E685E472D609EB5@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Na6wiKYxh0bBot0CA-ZuQVdZFcg>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] OSPF WG Minutes from IETF 95
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2016 15:29:37 -0000


On 4/11/16, 8:13 AM, "prz" <prz@zeta2.ch> wrote:

> On Sun, 10 Apr 2016 21:56:46 +0000, "Acee Lindem (acee)"
> <acee@cisco.com> 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