IETF Logo Mail Archive

Re: [OSPF] OSPF WG Minutes from IETF 95

"Acee Lindem (acee)" <acee@cisco.com> Wed, 13 April 2016 22:31 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 DA49912D50A for <ospf@ietfa.amsl.com>; Wed, 13 Apr 2016 15:31:15 -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 L_QGgcnlLbSD for <ospf@ietfa.amsl.com>; Wed, 13 Apr 2016 15:31:14 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0F912D1AE for <ospf@ietf.org>; Wed, 13 Apr 2016 15:31:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3120; q=dns/txt; s=iport; t=1460586674; x=1461796274; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fl3PNG7LPYGONim58w2MmopViyqCDGcD/UAyz8BWQqw=; b=QVbVzCpYtCGehExyb4ZoBsNeANeGVeHR+ztBaPFv4elMuC3qtofFiBZM rivrjeisCdzF+PjFe+P+24w9JQPjn8uAmJzLeYNH00NFTBn97MzcSJ08X wh3I2Oo/Xp8me4qFd3QKw63VGj4Vncrg0M9Q3xTY8ggnWMgM74Ao8aYq/ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANAgBEyA5X/4wNJK1egzeBUAa4OIIPAQ2BcYJegzACHIEiOBQBAQEBAQEBZSeEQQEBAQMBIxFFBQsCAQgYAgImAgICMBUQAgQOBYghCLBckkABAQEBAQEBAQEBAQEBAQEBAQEBF3yJcIQ9gwKCVgEEmAgBjgyBZ4ROgyiFM48mAR4BAUKDZ2yIfH4BAQE
X-IronPort-AV: E=Sophos;i="5.24,481,1454976000"; d="scan'208";a="96173410"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2016 22:31:13 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3DMVDSg010250 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 22:31:13 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 18:31:12 -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; Wed, 13 Apr 2016 18:31:12 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Paul Jakma <paul@jakma.org>
Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95
Thread-Index: AQHRk+ug+9xkeFSUNUaQhV0sMu+UBZ+E5gwAgANQ+gD//9JIAIAAlAqA///jKQA=
Date: Wed, 13 Apr 2016 22:31:12 +0000
Message-ID: <D3343D78.5A358%acee@cisco.com>
References: <D330445B.58C7B%acee@cisco.com> <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> <D3313626.58E6F%acee@cisco.com> <alpine.LFD.2.20.1604131455120.18471@stoner.jakma.org> <D333DB19.59F07%acee@cisco.com> <alpine.LFD.2.20.1604132106430.13056@stoner.jakma.org>
In-Reply-To: <alpine.LFD.2.20.1604132106430.13056@stoner.jakma.org>
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: <36CB72DC44BBD14D9D8EE298646A4203@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/wR1jmPx1DeESCzmrynC0DDCo-mU>
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: Wed, 13 Apr 2016 22:31:16 -0000


On 4/13/16, 4:14 PM, "Paul Jakma" <paul@jakma.org> wrote:

>On Wed, 13 Apr 2016, Acee Lindem (acee) wrote:
>
>> Are you familiar with the requirements language? While the use of
>> “should not” is unfortunate, it is not normative. To be normative it
>> would need to be “SHOULD NOT”.
>
>Capitals are not required.

This is not my convention - please see RFC 2119.


>If one is used to RFC2328, one would not
>expect normative language to be shouty.




>
>> Furthermore, RFC 6987 is informational as opposed to standards track.
>> Finally, the document goes on to precisely state the behavior (refer
>> to the last paragraph of section 4).
>
>> I believe the above is clear.
>
>Sure, 4 reads the other way but "deployment considerations" . I'm not
>saying how it must be read, just saying it is possible to read the
>stronger language of 3 another way.
>
>I'm not trying to argue, I'm trying to explain why we are here.

One of the authors or myself will write an errata to clarify this
definition. 

>
>>> For the RFC6987 desired behaviour, any high metric other than 0xffff
>>> will universally work.
>>
>> You have misinterpreted it.
>
>I may have misinterpreted RFC6987, sure.
>
>However, it is a fact that the behaviour desired by RFC6987 can be
>universally achieved with metrics of 0xfffe or lower. That was true
>before any misinterpretation, and is still true now.

But the OSPF stub router functionality is achieved using 0xffff, so your
proposal is NOT backward compatible.


>
>0xffff today will not universally be recognised as meaning "you can
>still calculate transit paths out of a router using that link".

There will always be software bugs and these should be corrected.

> 0xfffe 
>or below will.

See above - this is not backward compatible.

>
>That is the reality today.

The reality is that the standards WILL NOT change to match your
interpretation. If you want to change the standard, we look forward to
your proposal in draft form with backward compatibility for the
implementations with the correct interpretation.

Thanks,
Acee 


>
>regards,
>-- 
>Paul Jakma	paul@jakma.org	@pjakma	Key ID: 64A2FF6A
>Fortune:
>Even a blind pig stumbles upon a few acorns.

v2.23.0 | Report a Bug | By Email