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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 04 May 2017 15:31 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 09C40129496; Thu, 4 May 2017 08:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.581
X-Spam-Level:
X-Spam-Status: No, score=-4.581 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 pjSrBnaSw_Fb; Thu, 4 May 2017 08:31:52 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F8E129B59; Thu, 4 May 2017 08:31:45 -0700 (PDT)
Received: from [85.158.138.179] by server-7.bemta-3.messagelabs.com id B0/48-02202-E594B095; Thu, 04 May 2017 15:31:42 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe1BMURzHnXv3PlRrTlvpZxWz6y2l0pg7ZCZ 5zDamwX9qNNzlaje7W3PvMjWD2ZBHGYomNKtQmiGPHiYNkhrCCjNp/JE2sYbsKO/BhLF3b8j5 63vO5/s73/M7cw5LagZoLSvk2gXRxlv0dIAqQZeUEZ2REpgWu68QuCODFSQ3fPg9yZU1tpHc4 8Iihqv7Uc9wt9vfUdzuvj6G29n6hU5iDQWvWijDm0NOZOhzVxGG0uF6ylBd/Z0wOPZ0UKvodM psM2bnrqdMdd13UU5HG5Xb/2y7A1U3U4UogFXhPSR4XXuRPNHgEgIueIZIZfIMgetokY+MZWm 8CBpq3XQhYtlQHA9Vr6NkD4kvElDW9dHvCcGL4WDNU0bWoTgZKt93korOgtZeLy1rFZ4K+R/q /H41Xgulg1cJJaxJBU8OvCNkMBYvg8YeByVrhMfDV9d5/zqJw6HnZaVfA8ZQff0RqegweOP55 e8H4SIET14U0wrQwbE+JyMDwAdIOHmjW6WAVDhY+00ltwN4ClweyFA8TgQFnQ9HijfD14qWkb RtcK1zaET3EOC6MlHREVA27KSU4vM0eAY7COUutODu3j9yLxEw0NtCKS3YoP/XJVLpPxjuHX+ pKkbTy0d1Vz7KVj7KVu47K4lnwaWrcxWLDkqLnjOKngkFzhPM6PWTiDmHZkqCuFUQo+PmxRhF c6bJbuXNlui42HkxVkGS+EzBwhulmA3Z1gbke4FjfKMZNV1JaUcTWEIfpp7hZdI044zZG/NMv GRaJ26xCFI7imBZPagdhsA0TbAoZAq5m8wW3zP+g4EN0oeqN8tYLeXwVsmcqSAX0mnD1ZNlgG Vg2mL7W/bnA3ShSG2IGvkOognKEUSr2f4/96JwFulD1PnyLkFmm/3v7l5fMOEL3hXJysF2/h/ SOpDQOudtVVyC23W0Zvejhe7QpvzZqRVcVnyC560nzTIj42bE6cTSITFsmhj8gFs5f0nzp62N 1qhY4nNSSNvSW8/vtB9Zzt+nU+ZkRTcGrljQ1vVtzfTr3dfioy7vSE+lT6Vrmycl9ubxq9eeM a5PPJtfoysxLji7qPbeT8OSnoC8/mSbXiWZ+LjZpCjxvwErmHHG+wMAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-13.tower-169.messagelabs.com!1493911897!114391512!1
X-Originating-IP: [52.33.64.93]
X-StarScan-Received:
X-StarScan-Version: 9.4.12; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 19504 invoked from network); 4 May 2017 15:31:39 -0000
Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (52.33.64.93) by server-13.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 4 May 2017 15:31:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z1I0J5Y0OAItX7iVcEtnjE5ITvwJxMNoHxNelmoBVU8=; b=BvfXJlnoinJ2TDcAZGnC+fDBaqp1UOwKUS2bfVN05vQVlp9oZYXCW5rmKu2iwxeHJKbD8ttzKRKOYr3vujW1wWYhhS3tqjM6AB6MpgPwEz8aaV70sZpf16VDVF+DR7JjoTJXkr1kH7NAJF0kduqHl5JJQuvJaBEqr3CpYcSImVk=
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1714.eurprd03.prod.outlook.com (10.167.88.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 4 May 2017 15:31:34 +0000
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::dd45:832a:e658:e737]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::dd45:832a:e658:e737%14]) with mapi id 15.01.1047.019; Thu, 4 May 2017 15:31:34 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: "alex.zinin@alcatel-lucent.com" <alex.zinin@alcatel-lucent.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "db3546@att.com" <db3546@att.com>, "chopps@chopps.org" <chopps@chopps.org>, RFC Errata System <rfc-editor@rfc-editor.org>, OSPF WG List <ospf@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)
Thread-Index: AQHSwYoCxBhcZtgLd0CoSDR/tVhrP6Hd9k4AgAAWr1CAAEQmAIAAyIsggAB7swCABGI0EIAASD2AgAANeICAAAYZoA==
Date: Thu, 4 May 2017 15:31:34 +0000
Message-ID: <AM4PR03MB171312438A18419DB3F566A59DEA0@AM4PR03MB1713.eurprd03.prod.outlook.com>
References: <20170430081555.026C1B8183C@rfc-editor.org> <bd426412060143b18b888f9fb9135728@XCH-ALN-001.cisco.com> <AM4PR03MB171368B3A0BC936159ABE14A9D150@AM4PR03MB1713.eurprd03.prod.outlook.com> <c8cbc9ccc7924bb59a6394978d757b54@XCH-ALN-001.cisco.com> <AM4PR03MB1713D57C0046833F38BB4F699D140@AM4PR03MB1713.eurprd03.prod.outlook.com> <e0c87dc6be1c4ae6a5fcf0c1a60a23de@XCH-ALN-001.cisco.com> <AM4PR03MB1713C1E72D8F9E187E718F399DEA0@AM4PR03MB1713.eurprd03.prod.outlook.com> <D530AFCB.ACAFA%acee@cisco.com> <4796c57dba3248059888714707985534@XCH-ALN-001.cisco.com>
In-Reply-To: <4796c57dba3248059888714707985534@XCH-ALN-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1714; 7:DFp1UEx6PV/F7TDSRHf8pyyu+jdzAoxkA9UtvZsEdGNqZhV2hdX0EdhEDx8GrCwvaOnr8gWWmgzecG2OFEe81Iq0EtXf5xkIfD4pksb1wY9WDOwUSMp0mR3GJRuAWRY4bzmvQEEeV39PQRYAV8qWtv4VS3j96xYHrXSeDpxf90Do2IB6z/5qeytbGWKCb92hwiKY42SXaTwq8stmHT7fXgkN7hmMwHLUqxNe9+calSNMkx1R8Lz+uJR8ekH8n3l0rgLbA4BUr2NoeM5tnvfMrTYH08OXLd1G3YL6m+Yzg0wCDO/mT4C/BEbcSGCa8fGzsXUa+kX5nI90Fk7GGmyVZQ==
x-ms-office365-filtering-correlation-id: cb7df7f5-d548-4060-8ce8-08d49302a5bf
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR03MB1714;
x-microsoft-antispam-prvs: <AM4PR03MB17144EE4304D1A52BF3C9A5E9DEA0@AM4PR03MB1714.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(97927398514766)(100405760836317)(95692535739014)(21748063052155)(279101305709854);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:AM4PR03MB1714; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1714;
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39860400002)(39850400002)(39400400002)(39840400002)(39450400003)(377454003)(51914003)(85664002)(51874003)(252514010)(13464003)(4326008)(33656002)(5660300001)(966004)(53936002)(53946003)(9686003)(54896002)(236005)(3280700002)(2906002)(81166006)(2900100001)(50986999)(8676002)(76176999)(54356999)(7906003)(229853002)(110136004)(38730400002)(15188155005)(74316002)(16799955002)(7736002)(86362001)(6306002)(93886004)(6916009)(66066001)(5890100001)(25786009)(508600001)(3660700001)(55016002)(7696004)(6116002)(53546009)(2950100002)(99286003)(606005)(6506006)(102836003)(3846002)(54906002)(790700001)(6436002)(189998001)(8936002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1714; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM4PR03MB171312438A18419DB3F566A59DEA0AM4PR03MB1713eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 15:31:34.4483 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1714
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/EDnfpjrXf6vUUXBfLOubn2lTfTY>
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: Thu, 04 May 2017 15:31:57 -0000

Les,
ARP issues will not occur between a pair of LAN (not P2P) interfaces with mismatched subnets running OSPF, because the Hello packets received by one of the interfaces would be rejected claiming wrong subnet as the reason.
But this check in OSPF is disabled for P2P interfaces (i.e., for interfaces that are P2P from the OSPF POV).

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Thursday, May 04, 2017 6:08 PM
To: Acee Lindem (acee) <acee@cisco.com>om>; Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: alex.zinin@alcatel-lucent.com; isis-wg@ietf.org; db3546@att.com; chopps@chopps.org; RFC Errata System <rfc-editor@rfc-editor.org>rg>; OSPF WG List <ospf@ietf.org>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Acee –

Any ARP issues which might occur for numbered interfaces where neighbors do not have matching subnets will occur independent of P2P mode. I therefore see no reason why RFC 5309 should address this issue.

If you feel this needs to be addressed (I don’t – but YMMV) then I think errata should be against RFC 2328.

Note that in the case of IS-IS we have RFC 3787 Section 10 – which concludes by saying:

“…The  network administrator should ensure that there is a common IP subnet
   assigned to links with numbered interfaces, and that all routers on
   each link have a IP Interface Addresses belonging to the assigned
   subnet.”

   Les


From: Acee Lindem (acee)
Sent: Thursday, May 04, 2017 7:20 AM
To: Alexander Vainshtein; Les Ginsberg (ginsberg)
Cc: alex.zinin@alcatel-lucent.com<mailto:alex.zinin@alcatel-lucent.com>; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; db3546@att.com<mailto:db3546@att.com>; chopps@chopps.org<mailto:chopps@chopps.org>; RFC Errata System; OSPF WG List
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

+ospf-wg list

While very implementation specific, P2P over LAN isn’t described anywhere other than RFC 5309. The point Sasha is making is that OSPF doesn’t enforce subnet match checking on P2P links (which is true) and the ARP must do the same. Hence, I would agree with the errata.

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

Let’s go forward with this and not spend any more time debating it.

Thanks,
Acee



From: Isis-wg <isis-wg-bounces@ietf.org<mailto:isis-wg-bounces@ietf.org>> on behalf of Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Date: Thursday, May 4, 2017 at 6:03 AM
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Cc: "alex.zinin@alcatel-lucent.com<mailto:alex.zinin@alcatel-lucent.com>" <alex.zinin@alcatel-lucent.com<mailto:alex.zinin@alcatel-lucent.com>>, "isis-wg@ietf.org<mailto:isis-wg@ietf.org>" <isis-wg@ietf.org<mailto:isis-wg@ietf.org>>, Deborah Brungard <db3546@att.com<mailto:db3546@att.com>>, Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>, RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Les,
Lots of thanks for a detailed response. It seems that we are now in sync regarding the problem.

Doing nothing with this problem is of course one of the possible options☺.
I wonder how should we reach consensus regarding its handling.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Monday, May 01, 2017 6:04 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Cc: isis-wg@ietf.org<mailto:isis-wg@ietf.org>; RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; Naiming Shen (naiming) <naiming@cisco.com<mailto:naiming@cisco.com>>; alex.zinin@alcatel-lucent.com<mailto:alex.zinin@alcatel-lucent.com>; akatlas@gmail.com<mailto:akatlas@gmail.com>; db3546@att.com<mailto:db3546@att.com>; Alvaro Retana (aretana) <aretana@cisco.com<mailto:aretana@cisco.com>>; chopps@chopps.org<mailto:chopps@chopps.org>; hannes@gredler.at<mailto:hannes@gredler.at>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Sasha -

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Monday, May 01, 2017 12:50 AM
To: Les Ginsberg (ginsberg)
Cc: isis-wg@ietf.org<mailto:isis-wg@ietf.org>; RFC Errata System; Naiming Shen (naiming); alex.zinin@alcatel-lucent.com<mailto:alex.zinin@alcatel-lucent.com>; akatlas@gmail.com<mailto:akatlas@gmail.com>; db3546@att.com<mailto:db3546@att.com>; Alvaro Retana (aretana); chopps@chopps.org<mailto:chopps@chopps.org>; hannes@gredler.at<mailto:hannes@gredler.at>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Les,
Lots of thanks for the clarification.
I fully agree with you that configuring a pair of interfaces across a P2P link with IP addresses from different subnets should not be encouraged even if these interfaces operate as P2P from the POV of the routing protocol.

[Les:] This is not what I said. I said:

“allowing an adjacency to be formed on a numbered LAN with mismatched subnets is neither introduced nor altered by these RFCs .”

The problem is that the scenario I’ve described is quite real, and, AFAIK,  no standard explicitly says that it is not supported.

[Les:] Yes – it is real. But as RFC 5309 did not introduce or alter this behavior it is not the appropriate place to comment on it.

I also do not fully  understand  your usage of plural (“these RFCs”) – I have been only asking about a correction in a single RFC -5309.

[Les:] My mistake – I was thinking there was a separate RFC for OSPF/IS-IS – but RFC 5309 cobvers both.

I see several ways to resolve the problem:

1.       Recognize the erratum and hold it for the update of 5309

2.       Explicitly state that numbered P2P-over-LAN interfaces must still configure the terminating interfaces of the LAN link with IPv4 addresses from the same subnet (could be another sort of update for 5309).

What would you suggest?

[Les:] I suggest we do no nothing.

   Les

Regard, and lots of thanks in advance,
Sasha



Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Sunday, April 30, 2017 10:44 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Cc: isis-wg@ietf.org<mailto:isis-wg@ietf.org>; RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; Naiming Shen (naiming) <naiming@cisco.com<mailto:naiming@cisco.com>>; alex.zinin@alcatel-lucent.com<mailto:alex.zinin@alcatel-lucent.com>; akatlas@gmail.com<mailto:akatlas@gmail.com>; db3546@att.com<mailto:db3546@att.com>; Alvaro Retana (aretana) <aretana@cisco.com<mailto:aretana@cisco.com>>; chopps@chopps.org<mailto:chopps@chopps.org>; hannes@gredler.at<mailto:hannes@gredler.at>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Sasha –

The language you are asking to be changed is in regards to ARP. I am saying allowing an adjacency to be formed on a numbered LAN with mismatched subnets is neither introduced nor altered by these RFCs .
What is introduced is the possibility of operating on an unnumbered LAN – which is why the RFCs speak to that.

If you want to ask that protocol base specifications discuss ARP issues when mismatched subnets are allowed (which I am NOT encouraging you to do) then you will be directing your comments at the correct documents.
Asking that of these RFCs is inappropriate.

   Les


From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, April 30, 2017 8:51 AM
To: Les Ginsberg (ginsberg)
Cc: isis-wg@ietf.org<mailto:isis-wg@ietf.org>; RFC Errata System; Naiming Shen (naiming); alex.zinin@alcatel-lucent.com<mailto:alex.zinin@alcatel-lucent.com>; akatlas@gmail.com<mailto:akatlas@gmail.com>; db3546@att.com<mailto:db3546@att.com>; Alvaro Retana (aretana); chopps@chopps.org<mailto:chopps@chopps.org>; hannes@gredler.at<mailto:hannes@gredler.at>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)


Les,

Lots of thanks for a prompt response.



As I see it, the difference between the P2P and LAN modes is essential for OSPF:

- If an OSPF interface is a LAN (broadcast) interface, there is a check of the same subnet for received Hello packets. If the received Hello packets do not pass this check, they are discarded and an error is reported via SNMP.

- However, if an OSPF interface is a P2P interface, then the subnet check on the Hello packets is bypassed  by design as defined in Section 10.5 of RFC 2328:



                     The generic input processing of OSPF packets will

        have checked the validity of the IP header and the OSPF packet

        header.  Next, the values of the Network Mask, HelloInterval,

        and RouterDeadInterval fields in the received Hello packet must

        be checked against the values configured for the receiving

        interface.  Any mismatch causes processing to stop and the

        packet to be dropped.  In other words, the above fields are

        really describing the attached network's configuration. However,

        there is one exception to the above rule: on point-to-point

        networks and on virtual links, the Network Mask in the received

        Hello Packet should be ignored.



I.e., having different subnets on two ends of a PPP link would not cause any problems for OSPF - the adjacency would be successfully recognized, it would progress to its FULL state, and unicast traffic would cross such a link without any problem.



But if we have a P2P-over-LAN link (which is the case for RFC 5309), the result would be quite different - unless the ARP implementations go beyond what 5309 says and relax the check for all such links, be they numbered or unnumbered.



Do I miss something substantial here?







Regards,

Sasha



Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>





-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; Naiming Shen (naiming) <naiming@cisco.com<mailto:naiming@cisco.com>>; alex.zinin@alcatel-lucent.com<mailto:alex.zinin@alcatel-lucent.com>; akatlas@gmail.com<mailto:akatlas@gmail.com>; db3546@att.com<mailto:db3546@att.com>; Alvaro Retana (aretana) <aretana@cisco.com<mailto:aretana@cisco.com>>; chopps@chopps.org<mailto:chopps@chopps.org>; hannes@gredler.at<mailto:hannes@gredler.at>
Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)



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<mailto:alex.zinin@alcatel-lucent.com>;

> akatlas@gmail.com<mailto:akatlas@gmail.com>; db3546@att.com<mailto:db3546@att.com>; Alvaro Retana (aretana);

> chopps@chopps.org<mailto:chopps@chopps.org>; hannes@gredler.at<mailto:hannes@gredler.at>

> Cc: Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>; isis-wg@ietf.org<mailto: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<mailto: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<mailto:Isis-wg@ietf.org>

> https://www.ietf.org/mailman/listinfo/isis-wg

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________