Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Robert Raszuk <robert@raszuk.net> Wed, 02 September 2020 15:02 UTC

Return-Path: <robert@raszuk.net>
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 57DF03A1048 for <lsr@ietfa.amsl.com>; Wed, 2 Sep 2020 08:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 PBPsO0oINaNX for <lsr@ietfa.amsl.com>; Wed, 2 Sep 2020 08:02:52 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 2B0243A102B for <lsr@ietf.org>; Wed, 2 Sep 2020 08:02:52 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id c10so5245346edk.6 for <lsr@ietf.org>; Wed, 02 Sep 2020 08:02:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pK16+yjnkSeImN3crqjUQYU6Co4kh/l6AmyB0km/SZA=; b=TNFC/ZxNucdXJZT8pHKCm5mPTknuMEQfQRbdg+XYoll+FJM9cGuEwo7I2Iy99ieatE U4c7GdxkF12IhhusqVN7ijnZWXZA6e4zTfyTcj78Cx2A042toxGk7r1BT7Dq4/BmVrmu oOSLpIVJYej8ZNJz8u8dJlHrTTlFte6wtKGazexwqJRL5WV5x+s7s3OEDNSYy6I2tXC9 j0EDPaDDWws2JVkfbeJJn3uPhvP/eX2PlNx5bG04c8YM47BIB0e2Fa4Q3yElmp+v8Amp XKIE/9e+WsZ0684KyqX5auaue4Kuqc+txnnXcPoPZ/wnxQyJNBwfd4FEHO2PmJNhcN2m 9PnQ==
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=pK16+yjnkSeImN3crqjUQYU6Co4kh/l6AmyB0km/SZA=; b=a1wPJSCnkXrSZHwkdQ38XYRaCxhCChops4tvP75B2+rfu+bPnpn4hBgVwyEiaUzdp7 ALE+Xsvkn3Styzsva9O+Ut5RyTw1CGANYBVYK3Ri69VPj2OfmrvrKFaMQuux8QxHA+ak ATiNsBIHXAImxA1bc/OqEW7FOuexvxJw0FbinL9LPf78Z4+jlHfltLff2WBuhMzpUrY8 bedJd4fvDbLWPDE7f44PVNofjw1gm7iL0ubY+0rsm6F9lJ6TZwio8aE7Rmg2ZLZNNOfy ou4doIy26IN89TeVJ3mODqU+r5o08qD9E0V6e9RmOBCO8MlWtFe7uqQwjlYR8smg0Zvy aXGQ==
X-Gm-Message-State: AOAM530evFtRn2Ex03wtfNz0Fl/tOz7UAsqDAHRbaqWyVppSmSOfy1YZ IKqtLYHizPnHZduS9j0uLCNLmTHA3Br3rFMHF4wDBQ==
X-Google-Smtp-Source: ABdhPJy5fa9c6ouQ6Hrjo14afvuMnmkrUD4G2SulF1mS2gwcH5bhd5l8tYrYf9qoV/ctwr+SwmKs8nO0CFkaJfS9m3U=
X-Received: by 2002:a05:6402:50f:: with SMTP id m15mr496941edv.41.1599058970658; Wed, 02 Sep 2020 08:02:50 -0700 (PDT)
MIME-Version: 1.0
References: <F30AFA48-367E-4B32-B6E1-390B07507410@cisco.com> <BY5PR11MB4337D71462A6D7AF48C0E75EC15C0@BY5PR11MB4337.namprd11.prod.outlook.com> <MN2PR13MB3117C2EB2A0275AAC50671D1F25C0@MN2PR13MB3117.namprd13.prod.outlook.com> <BY5PR11MB4337CC18142C5355FB00BB80C15C0@BY5PR11MB4337.namprd11.prod.outlook.com> <MN2PR13MB3117E8AE76A4A22ECD649B68F25C0@MN2PR13MB3117.namprd13.prod.outlook.com> <BY5PR11MB4337FDF6AD2773B7DB70D67EC15C0@BY5PR11MB4337.namprd11.prod.outlook.com> <MN2PR13MB3117C29A75A371B630C62B00F22E0@MN2PR13MB3117.namprd13.prod.outlook.com> <975EC661-7C9F-4E0E-8B3D-EF3F0584659A@tony.li> <04351a69c1ee48f9b9f2f22b349db01a@huawei.com> <BDFC2601-B568-4211-A8E7-6C2EAC95F4EB@tony.li> <3d930fc3401449769e2f016c5d7bb0c2@huawei.com> <73F4793F-4CA0-4CE5-AE90-09904CBB1A9C@tony.li>
In-Reply-To: <73F4793F-4CA0-4CE5-AE90-09904CBB1A9C@tony.li>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 02 Sep 2020 17:02:39 +0200
Message-ID: <CAOj+MME7ov+CTyONq-sBU6RDjsj192_Q5ES2ek6JYdGzeLTVAg@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, Les Ginsberg <ginsberg@cisco.com>, Huaimo Chen <huaimo.chen@futurewei.com>, "lsr@ietf.org" <lsr@ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ebe2be05ae55ed85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/W9SbiHL2AaY44DDS6N7gSD9-BZM>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.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: Wed, 02 Sep 2020 15:02:54 -0000

> - The transition mechanisms

Hmmm maybe I missed some explanations by authors, but to me concept of
zones is positioned as an addition to the concept of areas or levels - not
a replacement of those.

So when you say "transition" means that something existing no longer would
be in place after successful deployment of a new thing.

Here I am actually not sure if IGP domain could be only constructed with
zones without areas ?

Of course said all of the above I am still not seeing any value in the
proposed new abstraction regardless if such abstraction would be positioned
to exist in parallel to areas/levels or by definition be nested within the
area/level.

r.

On Wed, Sep 2, 2020 at 4:48 PM <tony.li@tony.li> wrote:

>
> Hi Xueson,
>
> My intension was not to talk about math/engineering/marketing or compare
> the size of marketing department. Them are not relevant to this thread.
>
>
>
> You are the one who suggested we leave it up to the market…
>
> I want to make clear about IETF process. In my understanding the document
> does not need to be perfect at this stage, as long as it is in the right
> direction to solve some acknowledged problem( IGP scalability). Comments
> will be helpful if it could provide ideas about how to improve.
>
>
>
> That’s what we’ve been trying to tell you all along:
>
> - If there is a benefit to zones, it’s not clear to us.  You need to do a
> better job articulating that.
>
> - The transition mechanisms seem awkward and painful. Can you reduce the
> complexity?
>
> But IMO the discussion in the mailing list about this draft has gone off
> the rails of technology, including keeping challenging tradeoff between
> value and complexity, which seems reasonable at the first sight, but at
> this stage, has turned out to be a question with no right answer and may
> bring endless argument.
>
>
>
> Technology is all about maximizing benefits while minimizing costs.  This
> is why we don’t wire houses using gold and silver.
>
> Yes, this does seem to be an endless argument.  Welcome to the IETF.
>
> Regards,,
> Tony
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>