IETF Logo Mail Archive

Re: [Lsr] A review of draft-ietf-lsr-isis-ttz

Tony Li <tony.li@tony.li> Wed, 17 February 2021 17:55 UTC

Return-Path: <tony1athome@gmail.com>
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 997C53A1C0C; Wed, 17 Feb 2021 09:55:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 vr5h7_71RkN7; Wed, 17 Feb 2021 09:55:14 -0800 (PST)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 DB9EE3A1C0A; Wed, 17 Feb 2021 09:55:13 -0800 (PST)
Received: by mail-pg1-x52b.google.com with SMTP id o7so8969549pgl.1; Wed, 17 Feb 2021 09:55:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yEFk9Hp7P1EG0S2RdAKzYocmIY0SS/JP9+ob6XHA4n8=; b=b4W8AMJUe8QfhYVIjzs4X7HsBn17wqRLQNDyzZU/wGSuAvgTqjXB1+JkDgMOy6IAMd 2BPMVL5pT07+J1fh1df6jfoNmO7R+nCCtskyHYdDv/GWguKhqFkuTs94i5laV50W0OgZ FWe2xj09b6+snHLnoszGa4e7a/C7h2hBYzvTITdtuKFpxTZuuyskbkD9e/onNwHRIUy3 4GqwFkToFOx4BR6TdGTO+e/KEVMnODlWBdaWeYk+SZNBrvDljYb7S8pmgOy22h1jGtuF bQoMQzSiKFhlfyK6d0M8/bGf48pC3zN3qPEDVq5TVIEVSZ2/OdCvV9F6p0gWG/kZtMDp 6ocw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yEFk9Hp7P1EG0S2RdAKzYocmIY0SS/JP9+ob6XHA4n8=; b=tLoY93UVVVCVXJuqIaBGX4uhEkSPjBxBkq9J6p6Wno0FEN06fpXUWgOsV8nKG1SMLw nD5+ATGSzUrcmJzluzxwt1o7nui+sA1FuDLbX44MLzId8Kygg+fFjWKRX5j1UYmolyUH h3SQCv5Hc+f70zEQLLIllMz/ynZyeRBWbrysZP8hEj0XE3y1a0NsJ7aGaidrT2NzWExO KVb+1fGszoRBuYxs+QFsZJpE7IwoP+kXO/NxePfWTSPzBz+U4BqBikQXInOmon1dJsC8 1virftoFhy7mAv2l2DkaIL3KJcubo2oSeZ8hhdzKfMbnFIP+tT7+Wk+9r1eeWk6QOjKP mtCw==
X-Gm-Message-State: AOAM531mCCmrwcJ/o+iwk7lKxPNzLAkFTGdaVA2iDIcNDeY27/Izr1qn y98c8UYxjrXeAF3D7RUW6/4GsB7vZ70=
X-Google-Smtp-Source: ABdhPJykH/gPNrIdnuNp3XWWuofoW9HoD68fiNwCReVKIJq3N8nuXAv/OuVBRsMx/Mbl1aHRxSiAFg==
X-Received: by 2002:a63:4085:: with SMTP id n127mr462973pga.155.1613584513143; Wed, 17 Feb 2021 09:55:13 -0800 (PST)
Received: from [192.168.4.41] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id 68sm3321943pfg.90.2021.02.17.09.55.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2021 09:55:12 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <9AC89351-F84D-478B-8EBB-0EA88ADE8B6F@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6EB17D53-78D8-43AB-9274-6A57E476CEE0"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Date: Wed, 17 Feb 2021 09:55:11 -0800
In-Reply-To: <034801d70247$a3d0e970$eb72bc50$@olddog.co.uk>
Cc: lsr <lsr@ietf.org>, draft-ietf-lsr-isis-ttz@ietf.org
To: Adrian Farrel <adrian@olddog.co.uk>
References: <034801d70247$a3d0e970$eb72bc50$@olddog.co.uk>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/xiMzt0IeO_HHT18MtIbXbrFnjaM>
Subject: Re: [Lsr] A review of draft-ietf-lsr-isis-ttz
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: Wed, 17 Feb 2021 17:55:16 -0000

Hi Adrian,

> On Feb 13, 2021, at 12:34 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 
> I have some pretty strong opinions on the idea of a single node
> abstraction. The main challenge comes when there is a partial failure in
> the zone such that the zone is partitioned (or the path between two
> zone neighbors across the zone is severely degraded). It is not possible
> to represent this in the node model since your only options are:
> - drop the connection to a neighbor
> - move to represent the zone as two nodes


I’m not one of the authors and I don’t mean to interfere, but I have to ask whether you’re raising the bar here.

Partitioned areas have been a sore spot within IS-IS since day one. While we’ve frequently discussed alternative solutions (e.g., tunneling through L2 to restore L1 continuity), I’m unaware of a practical, deployed solution to the problem. We have always addressed this by placing the burden on network architects: ensure that your L1 area has enough redundancy to never partition. While this seems like it is annoying, it does seem to be doable.

While it is certainly fair to call this out as a discussion item, requiring that TTZ (and Area Proxy) solve issues that we haven’t been able to solve to date seems to be asking for technological breakthroughs as table stakes.

Regards,
Tony

v2.23.0 | Report a Bug | By Email