Re: [Lsr] Request WG adoption of TTZ

Uma Chunduri <umac.ietf@gmail.com> Wed, 15 July 2020 16:52 UTC

Return-Path: <umac.ietf@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 C6DD03A0064 for <lsr@ietfa.amsl.com>; Wed, 15 Jul 2020 09:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5U6iifoq3K5u for <lsr@ietfa.amsl.com>; Wed, 15 Jul 2020 09:52:41 -0700 (PDT)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 7A92B3A00C1 for <lsr@ietf.org>; Wed, 15 Jul 2020 09:52:41 -0700 (PDT)
Received: by mail-vs1-xe35.google.com with SMTP id q15so1454848vso.9 for <lsr@ietf.org>; Wed, 15 Jul 2020 09:52:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5RtTkwnyl7gM5OakfCIVHQtSiqq9LE5yb0JftAgmcvM=; b=W3hblvI4IvtJUFrUrQ5R+iR1BXTDAnodnAWI+5+66zG0QJzLD8iVeFSlQpTh6dYxcO ZWqz0TsnkdG3ZvCDbdyp2AzpchpVIL60LjLFEOgUkOT3xubbGp1srYGNx9N4OZy3dN11 aXrJg55sG6e24dWsOSSjGwwJzN/ERk4bzU8/c3uBWZEt22dBcHKbcKwCjTEB+wUzLFjE J2OnaQ0yH9ppxqoo2yn3OVydB+IcqTrj4zTwLjRuOxDo0OWYMl0oEwzSR3TrrkqQSTgD RC++49/Swx9tPaTvXyOUPDnZs1NcaTFBdMa4C+YAjkxVETGrc7idn3SVIdCVVMYmCPaE tn+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5RtTkwnyl7gM5OakfCIVHQtSiqq9LE5yb0JftAgmcvM=; b=fTBSZvOgwpU1D39PmsNiXL1DtgJsVsX0MsVffZ28oF4Q/hUhdwm6XXF/rFRWwciB0A OfjD7j3mzdQnj8lOvAJh1GE8EKBkVDDSKL06AWFWHO6yTU8cv94UcmSefzFzkr/yPYBN yK6xgLIIbDYdXZ6DEEbyxPtrhpjsWHHY1q1f9uzVJsOkNWF8DY2bs4mUEqxH8b4Q3dkc SyeD8SIpTh//kYptNeQzYQ48wGPdR3r0FvIVc5200mUXGSElYxdTM4lBa3epmtDaU65P Q+DVM9bQ/hxjO6nq1uW6sP/rH2xzCCpF4dCfDt2DmaoxsboXuxiTuH9dW23x79DBOkxf LMBw==
X-Gm-Message-State: AOAM532vja2hk+d1D5ApxspWOqUpWOLxc6R2kJrstKdxboQJsFKtScZB 2rzLrAfbzO1oHdc8NhIyhDwWPYPXHBWhDd5QXF6FVg==
X-Google-Smtp-Source: ABdhPJyUaKxrXUUVwZJoQ7tHkdXJQh2E81Yqx6vahE5minznAxKtIb3rsy3EAihX/p40n3vuwH/yMZ5wYlt2yVl9bFY=
X-Received: by 2002:a67:bd07:: with SMTP id y7mr38219vsq.235.1594831960545; Wed, 15 Jul 2020 09:52:40 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB31178756BB6166B2F1807CF6F2980@MN2PR13MB3117.namprd13.prod.outlook.com> <CAF4+nEHB+C8n22F-60FXYa5JXoFHxH9oDg0ANsWd4V_fdW9EiQ@mail.gmail.com> <DM6PR06MB509884AFCDB21593E2B4389DEE630@DM6PR06MB5098.namprd06.prod.outlook.com> <BYAPR13MB243779757964C2D31BB1AEB2D9600@BYAPR13MB2437.namprd13.prod.outlook.com> <MN2PR13MB3117E81B8CA6A298742C01D1F2610@MN2PR13MB3117.namprd13.prod.outlook.com> <c1add5e4fe4e3f387e83f7d6b76db5cb@xs4all.nl>
In-Reply-To: <c1add5e4fe4e3f387e83f7d6b76db5cb@xs4all.nl>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Wed, 15 Jul 2020 09:52:35 -0700
Message-ID: <CAF18ct5xyB5jrE0znNYFctJOE+ny8g65x+=+zinUBZkxRY9DMg@mail.gmail.com>
To: Henk Smit <henk.ietf@xs4all.nl>
Cc: Huaimo Chen <huaimo.chen@futurewei.com>, lsr@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007c1dae05aa7dc080"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/rXj8zIva5-XonDJX7zjGiGMTLas>
Subject: Re: [Lsr] Request WG adoption of 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, 15 Jul 2020 16:52:43 -0000

On Wed, Jul 15, 2020 at 5:22 AM Henk Smit <henk.ietf@xs4all.nl> wrote:

> Huaimo Chen wrote on 2020-07-14 06:09:
>
> >  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> > block or piece of an IS-IS area, which is to be abstracted. This seems
> > more flexible and convenient to users.
>
> I don't agree that this convenience is really beneficial.
>
I actually think this convenience is a downside.
>

I actually think not  having more configuration across the network to
enable a new feature is more useful even if
you don't do this operation every single day (especially if you want to
roll back).


Link-state protocols are not easy to understand. And we already
> have the misfortune that IS-IS and OSPF use different names for things.
> Adding the new concept of a "zone", while we already have the
> concept of an area makes things only more complex.
>

Agree in general.

I would say this is no more complex than what has been adopted already or
the slew of proposals we have been seeing here.

I too think as some other said we should have ideally adopted only one
proposal by merging whatever possible.
As  that is not the case and 2 parallel proposals have already been
accepted as WG experimental track, and given the interest/support on this
particular topic
I would think it's reasonable to continue this experiment in IS-IS too as
is done in OSPF.

--
Uma C.