Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04

"Acee Lindem (acee)" <acee@cisco.com> Mon, 23 January 2017 21:27 UTC

Return-Path: <acee@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 D0BFB127ABE; Mon, 23 Jan 2017 13:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Level:
X-Spam-Status: No, score=-17.721 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=-3.199, 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 x5m6cWGru27G; Mon, 23 Jan 2017 13:27:02 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EFE120726; Mon, 23 Jan 2017 13:27:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11216; q=dns/txt; s=iport; t=1485206822; x=1486416422; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3KzcKS3DZJ/0a3m1uxzxm/rYaPi0ONKJatsKEo4hf4s=; b=XpUPiE2g0BMjpMYpKPgnLqoy8B/3Mrx11zzBuk1V/TAP86LuD7KABw9e P1j9Yh3MWhj8rgoCOO/qx2N/96tu/ImPYImV2w3/bBmMb6ZS4yow6ZRMo TdGXW/yI/dY4m3qcQKG+OKfOjCvJuPmB3ATcx3Jdr2UcxMHUlg0qnFShL Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQDEdIZY/4kNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz0BAQEBAR9ggQkHg0yKCJIFlS6CDR8LhXgCGoFqPxgBAgEBAQE?= =?us-ascii?q?BAQFjKIRpAQEBBAEBGxc6CwwEAgEIEQQBAQEEIwUCAiULFAkIAgQBDQWJDA6PV?= =?us-ascii?q?Z1GBoIniloBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEFijaHSYJkAQSbSwGGYYs?= =?us-ascii?q?IkG6SdQEfOIFHFTqGNnOFYSuBA4ENAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,275,1477958400"; d="scan'208";a="201972161"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jan 2017 21:27:01 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0NLR0En005045 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Jan 2017 21:27:01 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Jan 2017 16:26:59 -0500
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.1210.000; Mon, 23 Jan 2017 16:27:00 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Christian Hopps <chopps@chopps.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
Thread-Index: AQHScLlfiAQ81s+pYEybS3QN6rpQoqFEiGEAgACb/QCAABBiAIAAXvoAgADtMYCAABx0gA==
Date: Mon, 23 Jan 2017 21:27:00 +0000
Message-ID: <D4ABDEA3.98F7B%acee@cisco.com>
References: <87mvepkiag.fsf@chopps.org> <D4AA1E05.983BF%acee@cisco.com> <15933d66e9e3427ea850374610372296@XCH-ALN-001.cisco.com> <D4AAAE86.98591%acee@cisco.com> <2e5307bbafeb4f17b9ff50b476981aad@XCH-RCD-001.cisco.com> <D4ABC549.98D7E%acee@cisco.com>
In-Reply-To: <D4ABC549.98D7E%acee@cisco.com>
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.201]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <2C760218A71F5E4F801365C02C4C5000@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/5Kncqys3lY_O0bjOLX-UOcGWo8w>
Cc: "draft-ietf-isis-auto-conf@ietf.org" <draft-ietf-isis-auto-conf@ietf.org>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>, "isis-ads@ietf.org" <isis-ads@ietf.org>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 23 Jan 2017 21:27:05 -0000

Les, et al, 
I see now that the intention was to “prevent” adjacencies between
auto-configured and non-autoconfigured IS-IS routers. Hence, I am fine
with this version of the document.
Thanks,
Acee 

On 1/23/17, 2:45 PM, "Acee Lindem (acee)" <acee@cisco.com> wrote:

>Les 
>
>On 1/22/17, 7:36 PM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com> wrote:
>
>>Acee -
>>
>>> -----Original Message-----
>>> From: Acee Lindem (acee)
>>> Sent: Sunday, January 22, 2017 3:56 PM
>>> To: Les Ginsberg (ginsberg); Christian Hopps; isis-wg@ietf.org
>>> Cc: draft-ietf-isis-auto-conf@ietf.org; isis-chairs@ietf.org;
>>>isis-ads@ietf.org
>>> Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
>>> 
>>> Hi Les,
>>> 
>>> On 1/22/17, 12:57 PM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
>>> wrote:
>>> 
>>> >Acee -
>>> >
>>> >Thanx for reviewing the document.
>>> >Responses inline.
>>> >
>>> >> -----Original Message-----
>>> >> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Acee
>>> >>Lindem
>>> >> (acee)
>>> >> Sent: Sunday, January 22, 2017 5:39 AM
>>> >> To: Christian Hopps; isis-wg@ietf.org
>>> >> Cc: draft-ietf-isis-auto-conf@ietf.org; isis-chairs@ietf.org;
>>> >>isis-ads@ietf.org
>>> >> Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
>>> >>
>>> >> Hi IS-IS WG,
>>> >>
>>> >> I have reviewed the document and support publication. I have the
>>> >>following  minor comments:
>>> >>
>>> >>     1. It should be made clear that the A-Bit indicates that an
>>>IS-IS
>>> >>router  supports auto-configuration and, is not, necessarily
>>> >>auto-configured itself.
>>> >> After reading the whole draft, I know that this is the definition of
>>> >>the bit but  the initial text says the router is ³operating in
>>> >>auto-configuration mode.²
>>> >
>>> >[Les:] It is clearly stated that the A flag does indeed mean
>>> >
>>> >" the router is operating in auto-configuration mode."
>>> >
>>> >I do not see any text which suggests otherwise.
>>> 
>>> But there is no prior definition of “auto-configuration mode”. I think
>>>most
>>> readers would believe that this indicates that only routers performing
>>>auto-
>>> configuration will form adjacencies. Yet the documents
>>> states:
>>> 
>>>    This document also defines mechanisms to prevent the unintentional
>>>    interoperation of auto-configured routers with non-autoconfigured
>>>    routers.  See Section 3.3.
>>> 
>>> 
>>> Where is the interoperation? This definitely needs to be clarified - I
>>>don’t see
>>> how the authors can argue on this point!
>>[Les:] Section 3.4.2.  Adjacency Formation
>>
>> "  Routers operating in auto-configuration mode MUST NOT form
>>   adjacencies with routers which are NOT operating in auto-
>>   configuration mode.  The presence of the Router Fingerprint TLV with
>>   the A bit set indicates the router is operating in auto-configuration
>>   mode."
>>
>>I do not see that anything further is needed.
>>??
>
>The problem is that there is no prior definition of auto-configuration
>mode. Hence, one could interpret the above text as only allowing
>adjacencies between auto-configured routers. This directly contradicts the
>interoperability with non-autoconfigured routers.
>
>>
>>> 
>>> >
>>> >???
>>> >
>>> >>     2. In the duplicate detection in section 3.4.3, could you note
>>> >>that an IS-IS  router should be able to detect discern the case where
>>> >>two interfaces on the  IS-IS router performing auto-configuration are
>>> >>connected to the same  network.
>>> >>
>>> >[Les:] Multiple connections of the same system to the same network can
>>> >occur in the absence of auto-configuration and detection of this case
>>> >is not altered by auto-configuration. This is detected by receiving a
>>> >hello with the same source MAC address as a local interface. There are
>>> >then the following cases:
>>> >
>>> >1)Two interfaces on the local router are connected to the same media.
>>> >This is further validated by having the same systemID. The means for
>>> >detecting this as well as resolving this are not altered by
>>> >auto-configuration.
>>> >
>>> >2)Two neighbors connected to the same network have the same source
>>> MAC
>>> >address. This is distinguished by having different system IDs in the
>>> >hellos. The means for detecting this as well as resolving this are not
>>> >altered by auto-configuration.
>>> >
>>> >3)Two neighbors connected to the same network have the same source
>>> MAC
>>> >address and the same systemID. This is distinguished by having
>>> >different router fingerprint TLVs in the hellos - something only an
>>> >auto-config router could do. But the additional detection capability
>>> >does not provide any additional means to correct this issue.
>>> >
>>> >The authors discussed this point during the writing of the draft and
>>> >decided specifically NOT to comment on this issue as it by nature is
>>>no
>>> >different than what can occur without auto-config and there is no good
>>> >way to automatically recover from this case i.e. clearly we cannot
>>> >alter the physical connections by programmatic means - nor do we
>>> >assume/require a programmatic capability of assigning MAC addresses.
>>> >
>>> >So, I am not sure what we could say other than to note that this can
>>> >occur - but non-auto-config implementations already have to detect
>>>this
>>> >- so does it make sense to comment on this in the auto-config draft?
>>> 
>>> Given that consequences of this mis-wiring are more severe when IS-IS
>>>auto-
>>> configuration is being used, I think this deserves at least the
>>>discussion above
>>> included in the draft.
>>> 
>>[Les:] I do not see that this issue is any more/less severe when
>>operating in autoconfig mode.
>>Manual intervention is required to resolve the issue regardless of mode -
>>the protocol cannot heal itself in this case. All we can do is send out a
>>notification and be smart in the implementation so as to avoid constant
>>adjacency churn. This behavior is required/recommended regardless of
>>autoconfig mode. In fact, it could be argued the problem is more severe
>>for larger networks as the side effects of churn associated with
>>sub-optimal handling of this problem will be far worse in a large
>>network.
>>
>>Interestingly, I do not even see a notification defined for this
>>condition in the MIB (RFC 4444) - perhaps we will do better when defining
>>the YANG data model. :-)
>>
>>This is perhaps a problem worth discussing - but I don’t see that it is
>>in any way unique to or related to autoconfig - so adding it to this
>>specification doesn’t seem appropriate.
>
>With the respect to this being a problem in any mode, I agree. One
>motivation for at least having a statement in this draft is that it
>specifically addresses duplicate System-ID handling and I’m not sure
>whether that is addressed in any other IS-IS specifications. However, I
>don’t feel that strongly. Here is what we had in RFC 7503:
>
> An OSPFv3 router implementing this specification should ensure that
> the inadvertent connection of multiple router interfaces to the same
> physical link is not misconstrued as detection of an OSPFv3 neighbor
> with a duplicate Router ID.
>
>
>Thanks,
>Acee 
>
>
>>
>>   Les
>>
>>
>>> Thanks,
>>> Acee
>>> 
>>> 
>>> 
>>> >
>>> >   Les
>>> >
>>> >
>>> >> Thanks,
>>> >> Acee
>>> >>
>>> >> On 1/17/17, 7:00 AM, "Isis-wg on behalf of Christian Hopps"
>>> >> <isis-wg-bounces@ietf.org on behalf of chopps@chopps.org> wrote:
>>> >>
>>> >> >
>>> >> >Hi Folks,
>>> >> >
>>> >> >We are starting a WG Last Call for
>>> >> >
>>> >> >  "ISIS Auto-Configuration"
>>> >> >  - https://datatracker.ietf.org/doc/draft-ietf-isis-auto-conf/
>>> >> >
>>> >> >The WGLC will expire in 2 weeks on Jan 31, 2017.
>>> >> >
>>> >> >Thanks,
>>> >> >Chris & Hannes.
>>> >>
>>> >> _______________________________________________
>>> >> Isis-wg mailing list
>>> >> Isis-wg@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/isis-wg
>>
>