Re: [OSPF] OSPF WG Minutes from IETF 95

"Alvaro Retana (aretana)" <aretana@cisco.com> Thu, 14 April 2016 14:52 UTC

Return-Path: <aretana@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 BA45312E57A for <ospf@ietfa.amsl.com>; Thu, 14 Apr 2016 07:52:20 -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 vpA807RRPZB6 for <ospf@ietfa.amsl.com>; Thu, 14 Apr 2016 07:52:19 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A671612E579 for <ospf@ietf.org>; Thu, 14 Apr 2016 07:52:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1426; q=dns/txt; s=iport; t=1460645539; x=1461855139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QrkENlOQ0VtCZfVmvs9jLgdGYMjm0V1x92WBySPU6eQ=; b=LolROeWcTrbilpzFb/4R1wpdLbpbObHV6rhKOri4Z1tJgp79swoVC8/q z2YwFeIFQCJB2iYYJKmKkvqozsIBHVZerteDRWE+mW05eBzJ39e85XhX+ OGHqnCu2pRMh8+nOtu5kpqqxd+ig+4YEshHlutoG4SOo3oWCSkJVDDJgA s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BnAgBmrg9X/5NdJa1egziBUAa4GoIPA?= =?us-ascii?q?Q2BcYYOAoE3OBQBAQEBAQEBZSeEQgEBBCdSEAIBCEYyJQIEAQ0FiCnCXgEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARWGIYRLihUBBI4KhROEbgGODIFnjSmGIYkHAR4BA?= =?us-ascii?q?UKDZ2yICQc4fgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="scan'208";a="260628932"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 14:52:12 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3EEqCHS018712 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 14:52:12 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 09:52:11 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 09:52:12 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, Paul Jakma <paul@jakma.org>
Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95
Thread-Index: AQHRk3PgRnVqmNZNrEiwg2kB/ZG01J+FBA8AgAA2vgCAAw3sAIAAFVgAgABQ+oCAACY8AIAAt5cAgABGXID//9EOAA==
Date: Thu, 14 Apr 2016 14:52:12 +0000
Message-ID: <D3351B60.11EE2F%aretana@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> <D3343D78.5A358%acee@cisco.com> <D3350F54.11EDC1%aretana@cisco.com> <D33513B2.5AACC%acee@cisco.com>
In-Reply-To: <D33513B2.5AACC%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <10259F30EB7A8C458DCDA6ECD59F7F38@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/rrjBKTHfs-me-rY_kkvEU1q0dF8>
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: Thu, 14 Apr 2016 14:52:21 -0000

On 4/14/16, 9:40 AM, "Acee Lindem (acee)" <acee@cisco.com> wrote:

Acee:

...
>...I¹d leave the section 4 text as is
>and modify the section 3 text.

I agree with your proposal.

The reason for proposing a change in 4 is because if only one path exists
it may result in a loop (if pre-rfc1583 and current routers are present):

<-- 0/0 -- rtr1 -- rtr2 -- rtr3 -- destination -->

In this network there's a default route going left and the destination we
want to reach is on the right.  rtr2 is a pre-rfc1583 router and rtr3 uses
rfc6987.

If the source is connected to rtr1, rtr1 will decide to use rtr3 as
transit (it is the only path).  But rtr2 will not and send the packet back
to rtr1 (following the default), resulting in a loop.

...so the text below clarifies that it is a possibility.


We can file these are independent errata and let the AD deal with them.
;-)  In both cases I think the update doesn't change the spirit of the RFC
and can just be help for document update.

Thanks!

Alvaro.


>>
>>NEW>
>>4.  Deployment Considerations
>>...
>>   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, while the routers
>>   of the second type will still use this path, which may result in a
>>routing 
>>   loop.
>>...
>>