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

Alia Atlas <akatlas@gmail.com> Wed, 14 June 2017 17:40 UTC

Return-Path: <akatlas@gmail.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 9C23912878D for <isis-wg@ietfa.amsl.com>; Wed, 14 Jun 2017 10:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GcQvKPDt2vls for <isis-wg@ietfa.amsl.com>; Wed, 14 Jun 2017 10:39:57 -0700 (PDT)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E159B129411 for <isis-wg@ietf.org>; Wed, 14 Jun 2017 10:39:54 -0700 (PDT)
Received: by mail-wr0-x229.google.com with SMTP id q97so10335961wrb.2 for <isis-wg@ietf.org>; Wed, 14 Jun 2017 10:39:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=89MWOJZB+U9aZ6I6x0LgLGESacHpePP8SwPSUNl08Bw=; b=hK/aYlOvcFXKCvffC/5CwKXteCWeap6NdARhG0PV7okUvHnYAOJACNychimLdPErDm XNoVgkvoOF37PbN8sqXZlgtVg4j8O+igpRQNHFTpePY1uj5THTPp2BHfi0GrX+tU51xn 6MP/l7J0CcHAyNAQGeybxroTw37B0InW+18voWcyDsnmsFmalvodBarqVGn1d/83Sxko Ilik5gI2TmXunUpkEn7/kuZ5qEL5AXAwa0idFbIN5KYwKTu6XtbTnmkeKv3rV/wpWz/8 tnnJEJWhViEhHIQ7Z3CYb3vM5aIcSlEUIU8HTavPxjV33S+n8H8dTfWmQMS+DuzTY9Wv mCqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=89MWOJZB+U9aZ6I6x0LgLGESacHpePP8SwPSUNl08Bw=; b=pp2oU+kwb1QEtKS6pXvfRrU7UOeBhNzmQ/ibS/O+NazRYoq8FyDTr1HoLMkxTG4+kt qTEEuHM4KZZSoB7CcFuGa0TYMdNPAiMUO6w5P2qDj1HkZZQcDEZqNZGq7m0+cB1mOoyD tZOl59QzKnPqebd1l7bJCmS2dfrQcZG8296qv9/qFnYoQdUCPD6YAWf6M51zeT9wVBld h1ETKHaECS6mdyunbnyFtN1t7K6rqJzf6IC41gSeMHBuJWBrkty+Bvv0pVoaeg2IDSne OSe4k6/p2g0IXE0AtWKmsCLsXa8fBSuCyuLunfSO6J25reWSsqVPXSRw8e9es+rnLPRx FCaw==
X-Gm-Message-State: AKS2vOyNErSG5x6P8WVk33B+BCl9/lCj252EZQdhLdKxuHASFyCy/DXy wbIQytvI9BN+YvM9XQfVlZWH9aIdFw==
X-Received: by 10.223.133.167 with SMTP id 36mr919067wrt.86.1497461993155; Wed, 14 Jun 2017 10:39:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.131.66 with HTTP; Wed, 14 Jun 2017 10:39:52 -0700 (PDT)
In-Reply-To: <64254d6f9a8540bd82842d29a0136e67@XCH-ALN-001.cisco.com>
References: <20170430081555.026C1B8183C@rfc-editor.org> <bd426412060143b18b888f9fb9135728@XCH-ALN-001.cisco.com> <AM4PR03MB171368B3A0BC936159ABE14A9D150@AM4PR03MB1713.eurprd03.prod.outlook.com> <F45DED94-22FE-436D-A2E9-AD01AB454832@cisco.com> <AM4PR03MB171381904BE473010383FAD89D140@AM4PR03MB1713.eurprd03.prod.outlook.com> <5C8FC259-C018-4542-B77D-F23BC3E212A9@cisco.com> <HE1PR03MB1722501D2C6E614E8551AD319DE90@HE1PR03MB1722.eurprd03.prod.outlook.com> <CAG4d1reBKcwk0UZVvQgOoLhWramwcqtjPOXegcg5ubnRJsOkiQ@mail.gmail.com> <6c75a3bb-4a00-f0b7-861a-1fbd4496964e@gredler.at> <CAG4d1rcPAS2GdcR0ZSi5RVpQkfi1b0iGuxytygEXjKdTNVNNxw@mail.gmail.com> <64254d6f9a8540bd82842d29a0136e67@XCH-ALN-001.cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Wed, 14 Jun 2017 13:39:52 -0400
Message-ID: <CAG4d1rd+9Do-s7tvBaeY29RwajAP5FCfFQtXF6C4yTb4hc1TkA@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Hannes Gredler <hannes@gredler.at>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "Naiming Shen (naiming)" <naiming@cisco.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, "db3546@att.com" <db3546@att.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "chopps@chopps.org" <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="001a1147f6d02ab4650551ef0aad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/ftkEOg-zTQ9U0c5ycebI_JDUT84>
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: Wed, 14 Jun 2017 17:40:05 -0000

Les,

Thanks!   I'll let this sit for a day or so to see if there are more
comments
and then reject the errata with this note.

Regards,
Alia

On Wed, Jun 14, 2017 at 1:34 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com
> wrote:

> Alia –
>
>
>
> Try this:
>
>
>
> “RFC 5309 introduced the possibility of supporting an unnumbered
> configuration on a LAN. Statements in this RFC regarding ARP concerns are
> therefore deliberately limited to this new configuration.
>
>
>
> For IS-IS, RFC 3787 Section 10 discusses concerns regarding mismatched
> subnets on numbered links.
>
>
>
> For OSPF it is well known that there are some existing implementations
> which have supported mismatched subnets for many years.
>
>
>
> Any concerns with ARP behavior  in support of mismatched subnets on
> numbered LANs is out of scope of RFC 5309.”
>
>
>
>    Les
>
>
>
>
>
> *From:* Alia Atlas [mailto:akatlas@gmail.com]
> *Sent:* Wednesday, June 14, 2017 7:59 AM
> *To:* Hannes Gredler
> *Cc:* Alexander Vainshtein; Naiming Shen (naiming); Les Ginsberg
> (ginsberg); isis-wg@ietf.org; RFC Errata System;
> alex.zinin@alcatel-lucent.com; db3546@att.com; Alvaro Retana (aretana);
> chopps@chopps.org
> *Subject:* Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)
>
>
>
> On Wed, Jun 14, 2017 at 9:02 AM, Hannes Gredler <hannes@gredler.at> wrote:
>
> hi alia,
>
> the issue at hand IMO does not warrant an errata.
>
> this is more related to how ARP & nexthop handling
> is performed internally in a routing-stack which is IMO a bit outside
> of what isis-wg should work on.
>
>
>
> I agree that it is a bit outside the scope - but the issue comes up
>
> from interactions.   I am happy to reject the errata, if that is the
>
> consensus, but I could use a clearly written note explaining why.
>
> I'm also fine with having it become an advisory note; I think it is
>
> useful to provide non-normative guidance.
>
>
>
> Regards,
>
> Alia
>
>
>
>
>
>
> /hannes
>
> On 6/13/17 23:18, Alia Atlas wrote:
> > Chris, Hannes, Les, Sasha,
> >
> > Is there a conclusion about this Errata report?
> >
> > From the discussion, it sounds like there is a problem and the argument
> > is about
> > what layer it should be handled by.  Perhaps, instead of normative text,
> > it could be
> > a note?
> >
> > Regards,
> > Alia
> >
> > On Sun, May 7, 2017 at 1:35 AM, Alexander Vainshtein
> > <Alexander.Vainshtein@ecitele.com
> > <mailto:Alexander.Vainshtein@ecitele.com>> wrote:
> >
> >     Naiming,____
> >
> >     Lots of thanks for a very detailed response.____
> >
> >     __ __
> >
> >     I fully agree with you that reasonable ARP implementations
> >     (including Linux) provide for enabling or disabling the check of the
> >     source IP address. ____
> >
> >     I also agree that disabling this check on unnumbered P2P-over-LAN
> >     interfaces is the most useful use case when this check must be
> >     disabled.____
> >
> >     __ __
> >
> >     I also agree that the if a pair of connected interfaces are
> >     configured with IP addresses from mismatched subnets, traffic would
> >     not pass unless ARP check is relaxed for both LAN and P2P
> >     interfaces. My point is that, in the case of OSPF, if the interfaces
> >     were not configured as P2P, */an OSPF adjacency would not be
> >     formed/*. Therefore the link would not be part of the network graph
> >     and not taken into account in the OSPF routes computation. ____
> >
> >     __ __
> >
> >     But if these interfaces are configured as P2P for OSPF, an adjacency
> >     is formed and it reaches its FULL state. The result is blackholing,
> >     and RFC 5309 neither instructs the operators to avoid such
> >     configuration nor requires from the implementations to relax the ARP
> >     check.____
> >
> >     __ __
> >
> >     Regards,____
> >
> >     Sasha____
> >
> >     __ __
> >
> >     Office: +972-39266302 <tel:+972%203-926-6302 <+972%203-926-6302>
> >____
> >
> >     Cell:      +972-549266302 <tel:+972%2054-926-6302
> <+972%2054-926-6302>>____
> >
> >     Email:   Alexander.Vainshtein@ecitele.com
> >     <mailto:Alexander.Vainshtein@ecitele.com>____
> >
> >     __ __
> >
> >     *From:*Naiming Shen (naiming) [mailto:naiming@cisco.com
> >     <mailto:naiming@cisco.com>]
> >     *Sent:* Friday, May 05, 2017 8:44 AM
> >
> >
> >     *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com
> >     <mailto:Alexander.Vainshtein@ecitele.com>>
> >     *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com
> >     <mailto:ginsberg@cisco.com>>; isis-wg@ietf.org
> >     <mailto:isis-wg@ietf.org>; RFC Errata System
> >     <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>>;
> >     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,____
> >
> >     __ __
> >
> >     Thanks for the comments.____
> >
> >     __ __
> >
> >     In OS implementations, in particular linux, there are various
> >     releases and____
> >
> >     configure options, so it varies quite a bit for ARP. This pointer
> >     shows how to change____
> >
> >     the ARP behavior on linux:____
> >
> >     __ __
> >
> >     http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/
> arp_ignore_to_disable_ARP
> >     <http://kb.linuxvirtualserver.org/wiki/
> Using_arp_announce/arp_ignore_to_disable_ARP>____
> >
> >     __ __
> >
> >     For example, the variable ‘arp_ignore’, has the code sample in
> >     ‘arp.c’:____
> >
> >     http://elixir.free-electrons.com/linux/latest/source/net/ipv4/arp.c
> >     <http://elixir.free-electrons.com/linux/latest/source/net/ipv4/arp.c
> >____
> >
> >     __ __
> >
> >     static int arp_ignore
> >     <http://elixir.free-electrons.com/linux/latest/ident/arp_ignore
> >(struct
> >     in_device
> >     <http://elixir.free-electrons.com/linux/latest/ident/in_device>
> >     *in_dev, __be32
> >     <http://elixir.free-electrons.com/linux/latest/ident/__be32> sip
> >     <http://elixir.free-electrons.com/linux/latest/ident/sip>, __be32
> >     <http://elixir.free-electrons.com/linux/latest/ident/__be32>
> tip)____
> >
> >     {____
> >
> >                         struct net *net = dev_net
> >     <http://elixir.free-electrons.com/linux/latest/ident/dev_net
> >(in_dev->dev);____
> >
> >                         int scope
> >     <http://elixir.free-electrons.com/linux/latest/ident/scope>;____
> >
> >     __ __
> >
> >                         switch (IN_DEV_ARP_IGNORE
> >     <http://elixir.free-electrons.com/linux/latest/
> ident/IN_DEV_ARP_IGNORE>(in_dev))
> >     {____
> >
> >                         case 0:          /* Reply, the tip is already
> >     validated */____
> >
> >                                              return 0;____
> >
> >                         case 1:          /* Reply only if tip is
> >     configured on the incoming interface */____
> >
> >                                              sip
> >     <http://elixir.free-electrons.com/linux/latest/ident/sip> = 0;____
> >
> >                                              scope
> >     <http://elixir.free-electrons.com/linux/latest/ident/scope> =
> >     RT_SCOPE_HOST
> >     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST
> >;____
> >
> >                                              break;____
> >
> >                         case 2:          /*____
> >
> >                                              * Reply only if tip is
> >     configured on the incoming interface____
> >
> >                                              * and is in same subnet as
> >     sip____
> >
> >                                              */____
> >
> >                                              scope
> >     <http://elixir.free-electrons.com/linux/latest/ident/scope> =
> >     RT_SCOPE_HOST
> >     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST
> >;____
> >
> >                                              break;____
> >
> >     I have two linux boxes with ubuntu 16.04 connected on an ethernet
> ____
> >
> >     and with two different subnet:____
> >
> >     lenovo (enp3s0 with IP 192.168.1.35/24 <http://192.168.1.35/24>) <—>
> >     vaio (enp2s8 with IP 192.168.2.100/24 <http://192.168.2.100/24>)____
> >
> >     __ __
> >
> >     on vaio: I run an arping to request ARP resolution of 192.168.1.35
> >     <http://192.168.1.35>:____
> >
> >     vaio:~$ sudo arping 192.168.1.35 -i enp2s8____
> >
> >     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=0 time=6.538
> >     msec____
> >
> >     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=1 time=1.464
> >     msec____
> >
> >     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=2 time=8.418
> >     msec____
> >
> >     __ __
> >
> >     I made sure on lenovo as described arp_announce is ‘2’, and
> >     arp_ignore is ‘0’:____
> >
> >     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# echo 2 > arp_announce
> ____
> >
> >     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# cat arp_ignore ____
> >
> >     __ __
> >
> >     Run tcpdump on lenovo interface enp3s0 to get ARP packets:____
> >
> >     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# tcpdump -i enp3s0 arp
> >     -vv____
> >
> >     __ __
> >
> >     22:14:01.774491 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> >     192.168.1.35 tell 192.168.2.100, length 46____
> >
> >     22:14:01.774511 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> >     192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28____
> >
> >     22:14:02.775522 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> >     192.168.1.35 tell 192.168.2.100, length 46____
> >
> >     22:14:02.775541 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> >     192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28____
> >
> >     __ __
> >
> >     __ __
> >
> >     Ok, so what I’m getting at is that, if you know the system needs to
> >     run____
> >
> >     numbered and mismatched IP addresses over the same cable, then____
> >
> >     regardless of p2p-over-lan or other applications, you probably need
> >     to____
> >
> >     adjust the local ARP behavior to match what is expected on the
> OS.____
> >
> >     __ __
> >
> >     I agree that RFC 5309 does mention the matching IP subnet, and
> >     probably____
> >
> >     should refer to unnumbered is the most useful use case.____
> >
> >     __ __
> >
> >     Best Regards,____
> >
> >     - Naiming____
> >
> >     __ __
> >
> >         On May 1, 2017, at 12:40 AM, Alexander Vainshtein
> >         <Alexander.Vainshtein@ecitele.com
> >         <mailto:Alexander.Vainshtein@ecitele.com>> wrote:____
> >
> >         __ __
> >
> >         Naiming,____
> >
> >         Lots of thanks for a prompt response.____
> >
> >          ____
> >
> >         Unfortunately, I do not think that your response addresses your
> >         concern.____
> >
> >          ____
> >
> >         RFC 5309 explicitly mentions “ARP implementation (which /checks
> >         that the subnet of the source address of the ARP request matches
> >         the local interface address/)”. Actually, ARP implementations
> >         frequently check that /the source IP address in an ARP request
> >         is in the subnet of the local interface address/. E.g., AFAIK,
> >         this is the standard behavior of the Linux ARP implementation.
> >         To the best of my understanding this was the check that RFC 5309
> >         implied, /because there is no way the subnet of the source
> >         address of the ARP request could be known/.____
> >
> >          ____
> >
> >         If such check is applied, then the scenario I’ve described
> >         becomes valid. I can add that I have observed several
> >         implementations that experience the described behavior (i.e.,
> >         blackholing of unicast IP traffic that OSPF tries to route via
> >         such a link). Some other implementations seem to behave
> better.____
> >
> >          ____
> >
> >         Regards,____
> >
> >         Sasha____
> >
> >          ____
> >
> >          ____
> >
> >          ____
> >
> >          ____
> >
> >          ____
> >
> >         Regards,____
> >
> >         Sasha____
> >
> >          ____
> >
> >         Office: +972-39266302 <tel:+972%203-926-6302 <+972%203-926-6302>
> >____
> >
> >         Cell:      +972-549266302 <tel:+972%2054-926-6302
> <+972%2054-926-6302>>____
> >
> >         Email:   Alexander.Vainshtein@ecitele.com
> >         <mailto:Alexander.Vainshtein@ecitele.com>____
> >
> >          ____
> >
> >         *From:* Naiming Shen (naiming) [mailto:naiming@cisco.com]
> >         *Sent:* Monday, May 01, 2017 5:34 AM
> >         *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com
> >         <mailto:Alexander.Vainshtein@ecitele.com>>
> >         *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com
> >         <mailto:ginsberg@cisco.com>>; isis-wg@ietf.org
> >         <mailto:isis-wg@ietf.org>; RFC Errata System
> >         <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>>;
> >         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)____
> >
> >          ____
> >
> >          ____
> >
> >         Alexander, ____
> >
> >          ____
> >
> >         If you are saying the local LAN interface is explicitly
> >         configured with____
> >
> >         a different subnet IP address then the peer, I don’t think there
> >         is any____
> >
> >         problem with the ARP, and also with this RFC. Since ARP will
> >         always____
> >
> >         reply to answer its own IP addresses on the interface upon
> >         request.____
> >
> >          ____
> >
> >         This RFC is only saying, if it’s p2p-over-lan over an unnumbered
> >         IP address,____
> >
> >         and this LAN interface needs to proxy-ARP the IP address it
> >         binds to.____
> >
> >         If the ARP already replies since you have an IP address, and
> our____
> >
> >         p2p-over-LAN intf also uses this IP address, nothing is
> broken.____
> >
> >          ____
> >
> >         thanks.____
> >
> >         - Naiming____
> >
> >          ____
> >
> >             On Apr 30, 2017, at 8:50 AM, Alexander Vainshtein
> >             <Alexander.Vainshtein@ecitele.com
> >             <mailto:Alexander.Vainshtein@ecitele.com>> wrote:____
> >
> >              ____
> >
> >             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 <tel:+972%203-926-6302
> <+972%203-926-6302>>____
> >
> >             Cell:      +972-549266302 <tel:+972%2054-926-6302
> <+972%2054-926-6302>>____
> >
> >             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
> >             <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
> >             <http://webdefence.global.blackspider.com/urlwrap/?q=
> AXicE3RmiL7GwDDlCANDUU6lgUmSXnFRmV5uYmZOcn5eSVF-
> jl5yfi5DmYmhUUREcLmBkaGRuQmDY05qRWJeSmqRXlhiZl5xRklqZp5DanJm
> SWpOKlh9RklJgZW-fmpKZkl-kV5-UToDA0PFQQYGAOFQJGs&Z>____
> >
> >             > 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
> >             <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
> >             <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.
> >     ___________________________________________________________
> ________________
> >
> >
>
>
>