IETF Logo Mail Archive

Re: [Lsr] Review of draft-ietf-lsr-isis-ttz-00.txt

Christian Hopps <chopps@chopps.org> Fri, 02 October 2020 10:03 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174523A0F78 for <lsr@ietfa.amsl.com>; Fri, 2 Oct 2020 03:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 ZqjPOYv0k7lo for <lsr@ietfa.amsl.com>; Fri, 2 Oct 2020 03:03:50 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 398E93A0EF0 for <lsr@ietf.org>; Fri, 2 Oct 2020 03:03:50 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 9E4A060424; Fri, 2 Oct 2020 10:03:49 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <935951C4-C130-43E4-9BD9-AEB9AEC55982@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_2D0C5221-EC1D-41E1-B426-5B39A433AB21"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 02 Oct 2020 06:03:48 -0400
In-Reply-To: <CAF4+nEF954uSeTw_tzDvimGdwhzTto-xV_ZFE1t5bMaARw-YFA@mail.gmail.com>
Cc: Christian Hopps <chopps@chopps.org>, lsr@ietf.org
To: Donald Eastlake <d3e3e3@gmail.com>
References: <CAF4+nEF954uSeTw_tzDvimGdwhzTto-xV_ZFE1t5bMaARw-YFA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/mZWcaG-BnEWp8HR1P1n734D0I-M>
Subject: Re: [Lsr] Review of draft-ietf-lsr-isis-ttz-00.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2020 10:03:52 -0000


> On Sep 22, 2020, at 1:21 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:
> 
> 
> One final question: I may be confused but my understanding of IS-IS is
> that there are Level 1 links, Level 2 links, and links that are both
> Level 1 and 2. A border router between Level 1 and Level 2 is a router
> that has both types of links attached to it. Such a router is a part
> of each Level 1 Area to which it is linked and a part of Level 2. So,
> the Level 1 / Level 2 boundary is, in a real sense, internal to such a
> border router.

Actually IS-IS is different than this (your last 2 sentences). This is a key conceptual difference between OSPF and IS-IS. In OSPF an OSPF router (instance) can be attached to several areas. In IS-IS an L1 or L1L2 router (instance) resides belongs to only a single L1 area. Thus in OSPF area boundaries exist within the OSPF instance, while in IS-IS the L1 area boundaries exists on the wire between L2 adjacencies.

Thanks,
Chris.

v2.23.0 | Report a Bug | By Email