Re: [OSPF] OSPF WG Minutes from IETF 95

"Acee Lindem (acee)" <acee@cisco.com> Wed, 13 April 2016 15:24 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 D60FB12D13D for <ospf@ietfa.amsl.com>; Wed, 13 Apr 2016 08:24:42 -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 53mZgj9-9O64 for <ospf@ietfa.amsl.com>; Wed, 13 Apr 2016 08:24:41 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB3A12D8E2 for <ospf@ietf.org>; Wed, 13 Apr 2016 08:24:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5634; q=dns/txt; s=iport; t=1460561074; x=1461770674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tsPCqfOo0gibnsnBGPE224Uh3sW886wzduC98YHlLUE=; b=em7SRmUmC5Sy3Bg0fJw0QXIQjXnq6DLESDDdn4inp1WytMoFQwcTQkqn iNkAG+vITgWivl5Nn2JABfz8SP85+TnaLA1O+4lDZ6ziugRjXeMz1td2s ZSpofPxO81Pc03oAN24DvACtDByQh/pZYJwRC4KCsfYEPcs8oFbIicpvg k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxBQDrYw5X/5hdJa1egzdTfQa4N4Idg?= =?us-ascii?q?XQihWwCHIEjORMBAQEBAQEBZSeEQQEBAQMBIxFFEAIBCBgCAiYCAgIwFRACBA4?= =?us-ascii?q?FiCAIDrBVkjsBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyJcIQ9gwKCVgWTG4RtA?= =?us-ascii?q?YV2iBaPEI8mASEBQIIEGYFKbIh8fgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,480,1454976000"; d="scan'208";a="260274518"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2016 15:24:34 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3DFOXmv030554 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 15:24: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; Wed, 13 Apr 2016 11:24:33 -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 11:24:32 -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//9JIAA==
Date: Wed, 13 Apr 2016 15:24:32 +0000
Message-ID: <D333DB19.59F07%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>
In-Reply-To: <alpine.LFD.2.20.1604131455120.18471@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: <5405BF15C717544694ED1D199DD3221B@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/etgnMYxnrYxJun_Y_4Chz5n2GQc>
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 15:24:43 -0000


On 4/13/16, 10:08 AM, "Paul Jakma" <paul@jakma.org> wrote:

>On Mon, 11 Apr 2016, Acee Lindem (acee) wrote:
>
>> 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.
>
>Part of the issue here was that the stub-router RFC features language
>that is often used to indicate authoritative changes to behaviour:


>
>"3.  Maximum Link Metric
>
>     Section 2 refers to the cost of all non-stub links as MaxLinkMetric,
>     which is a new fixed architectural value introduced in this
>     document.
>
>    MaxLinkMetric
>       The metric value indicating that a router-LSA link (see Section 2)
>       should not be used for transit traffic.  It is defined to be the
>       16-bit binary value of all ones: 0xffff."
>
>Note the "should not".
>
>Given that just discouraging traffic but still allowing transit, doesn't
>require any special metric valie to be called out - any high metric will
>do, that's just normal behaviour of metrics; and given that having the
>means to be able to totally disallow transit is desirable (see R-bit in
>v3, and the H-bit)... It's then not at all impossible to think the above
>did intend to mean 0xffff to not allow transit.

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”. 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).


4.  Deployment Considerations

   When using MaxLinkMetric, some inconsistency may be seen if the
   network is constructed of routers that perform an intra-area Dijkstra
   calculation as specified in [RFC1247] (discarding link records in
   router-LSAs that have a MaxLinkMetric cost value) and routers that
   perform it as specified in [RFC1583] and higher (do not treat links
   with MaxLinkMetric cost as unreachable).  Note that this
   inconsistency will not lead to routing loops, because if there are
   some alternate paths in the network, both types of routers will agree
   on using them rather than the path through the stub router.  If the
   path through the stub router is the only one, the routers of the
   first type will not use the stub router for transit (which is the
   desired behavior), while the routers of the second type will still
   use this path.

   On the other hand, clearing the R-bit will consistently result in the
   router not being used for transit.

   The use of MaxLinkMetric or the R-bit in a network depends on the
   objectives of the operator.  One of the possible considerations for
   selecting one or the other is in the desired behavior if the path
   through the stub router is the only one available.  Using
   MaxLinkMetric allows for that path to be used while the R-bit
   doesn't.


I believe the above is clear.

>
>> 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.
>
>That won't work, I think.

Note that I said “didn’t want to use the link for any traffic.”



>
>Other hosts won't have a backlink then, and won't be able to calculate a
>route to the host. The OSPF host may then be unreachable. That's
>qualitatively different from other hosts still being able to calculate a
>path to the host it self.



>
>For the RFC6987 desired behaviour, any high metric other than 0xffff
>will universally work.

You have misinterpreted it.

Thanks,
Acee 



>
>For "no transit, and I really mean it", Quagga will follow the H-bit as
>soon as it's clear it will be a standard.
>
>regards,
>-- 
>Paul Jakma	paul@jakma.org	@pjakma	Key ID: 64A2FF6A
>Fortune:
>Small is beautiful.
> 		-- Schumacher's Dictum