Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Sun, 30 April 2017 14:21 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA70C1289B0 for <isis-wg@ietfa.amsl.com>; Sun, 30 Apr 2017 07:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 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.001, SPF_HELO_PASS=-0.001, 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 b0QMKa_zqcXJ for <isis-wg@ietfa.amsl.com>; Sun, 30 Apr 2017 07:21:06 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F6C1293E4 for <isis-wg@ietf.org>; Sun, 30 Apr 2017 07:18:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4116; q=dns/txt; s=iport; t=1493561934; x=1494771534; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pOFLtmIkOKNo+PqFIAGAlhG8qHdfBtYlDR/LKt1OnsU=; b=g+d3GopddfUSC18ApGxoesjAAnPS0AsapUU+mycfDn8wGy+HUBHrKA8n Vl8YE4gfKpomdgjBnF2CpyZ/7of6dME3n20doLRojRzTqtS3cUGtmlUas kpwu2FohODufRBdJIEi3C4CuC/0anOibD/P4pT7H/BlUBdct4H9eDCJAE Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAAC/8QVZ/4sNJK1BGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMqK2KBDAeNeZFNiCKNS4IPIQuFeAKENz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBODQLBQcEAgEIEQQBAR8JByEGCxQJCAIEAQ0FCIl/Aw0IDjGxJ?= =?us-ascii?q?YclDYNbAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZfgV0BgxuBPIEYTYFJH4U/BYk?= =?us-ascii?q?9EYgYizI7AYcahyiERYILVYRiiiWLHYkPAR84FnRvFRoqhHEcgWN1AROHQ4ENA?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.37,395,1488844800"; d="scan'208";a="239551625"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2017 14:18:53 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3UEIrU0027811 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 30 Apr 2017 14:18:53 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Apr 2017 09:18:53 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Sun, 30 Apr 2017 09:18:52 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "Naiming Shen (naiming)" <naiming@cisco.com>, "alex.zinin@alcatel-lucent.com" <alex.zinin@alcatel-lucent.com>, "akatlas@gmail.com" <akatlas@gmail.com>, "db3546@att.com" <db3546@att.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "chopps@chopps.org" <chopps@chopps.org>, "hannes@gredler.at" <hannes@gredler.at>
CC: "Alexander.Vainshtein@ecitele.com" <Alexander.Vainshtein@ecitele.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)
Thread-Index: AQHSwZVpYjRBuN4W+UWjHHVAZGnaGKHd9FxQ
Date: Sun, 30 Apr 2017 14:18:52 +0000
Message-ID: <bd426412060143b18b888f9fb9135728@XCH-ALN-001.cisco.com>
References: <20170430081555.026C1B8183C@rfc-editor.org>
In-Reply-To: <20170430081555.026C1B8183C@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.101.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/eBJCNvz1Ub62DfC94dF0Pyup-hc>
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Apr 2017 14:21:09 -0000

Alexander -

I am not speaking for the RFC authors, but regarding your point:

> o	Are assigned with IP addresses and subnet masks yielding different
> subnets

I fail to see why this issue is unique to (or associated with) running in P2P mode. 

The unnumbered case is specifically mentioned because in such a case it can be expected that the next hop address will be a loopback address and therefore there will be no common subnet.
But in the numbered case whether you have one neighbor in P2P mode or many neighbors in multi-access mode the msimatched subnet issue is the same. Therefore I see no reason why these RFCs should discuss it.

???

   Les


> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of RFC Errata
> System
> Sent: Sunday, April 30, 2017 1:16 AM
> To: Naiming Shen (naiming); alex.zinin@alcatel-lucent.com;
> akatlas@gmail.com; db3546@att.com; Alvaro Retana (aretana);
> chopps@chopps.org; hannes@gredler.at
> Cc: Alexander.Vainshtein@ecitele.com; isis-wg@ietf.org; rfc-editor@rfc-
> editor.org
> Subject: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)
> 
> The following errata report has been submitted for RFC5309, "Point-to-Point
> Operation over LAN in Link State Routing Protocols".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5309&eid=5007
> 
> --------------------------------------
> Type: Technical
> Reported by: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> 
> Section: 4.3
> 
> Original Text
> -------------
> For the ARP implementation (which checks that the subnet of the source
> address of the ARP request matches the local interface address), this check
> needs to be relaxed for the unnumbered p2p-over-lan circuits.
> 
> Corrected Text
> --------------
> For the ARP implementation (which checks that the subnet of the source
> address of the ARP request matches the local interface address), this check
> needs to be relaxed for the p2p-over-lan circuits (both numbered and
> unnumbered).
> 
> Notes
> -----
> Consider the following situation:
> 1.	Two routers, R1 and R2, are connected by a physical P2P  Ethernet
> link
> 2.	OSPFv2 is enabled on the interfaces representing the endpoints of
> this link.
> 3.      From the OSPF POV these interfaces:
> o	Are configured as P2P
> o	Belong to the same area
> o	Are assigned with IP addresses and subnet masks yielding different
> subnets
> 4.    ARP check mentioned in the problematic text is not relaxed.
> 
> Under this conditions:
> -Both R1 and R2 will accept Hello messages sent by the other router (becase
> it ignores subnet in Hello messages received via P2P interfaces)
> - Adjacency between R1 and R2 will progress to FULL state (because all
> OSPFv2 messages will be sent with AllSPFRouters multicast IPv4 address)
> - Unicast traffic sent by R1 to R2 (and vice versa) will be blackholed because
> ARP will not resolve addresses assigned to the corresponding interfaces.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please use
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party can log in to change the status and
> edit the report, if necessary.
> 
> --------------------------------------
> RFC5309 (draft-ietf-isis-igp-p2p-over-lan-06)
> --------------------------------------
> Title               : Point-to-Point Operation over LAN in Link State Routing
> Protocols
> Publication Date    : October 2008
> Author(s)           : N. Shen, Ed., A. Zinin, Ed.
> Category            : INFORMATIONAL
> Source              : IS-IS for IP Internets
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg