Re: [Isis-wg] WG Adoption poll for draft-ginsberg-isis-te-app
Tony Przygienda <tonysietf@gmail.com> Thu, 29 June 2017 00:40 UTC
Return-Path: <tonysietf@gmail.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 B0B1D126B7F; Wed, 28 Jun 2017 17:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 TsvFRHIZaKck; Wed, 28 Jun 2017 17:40:28 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 1FEB21200ED; Wed, 28 Jun 2017 17:40:28 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id b184so74984114wme.1; Wed, 28 Jun 2017 17:40:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dg3B+lzXv9tcbX62iDOhtJa8bCIdYdJh/KH4txSlgOI=; b=MW3aNyVc2HMpn2sFoytwci+2MO9jMkkQEI/BzsaMLN5oqOV5zqqEiOIpqrcdklkeZw o2ILcUXzMZVvtRkH3fn312k9nbqaymBkxnucevEUCW7ij1Mt62Hjpee/ZWA5bopQR2kk Tiu3fMxC4c+/maM0VAZtwrq5rW6+ui9nJa7VVqXnDhjIeMqQB1UMzSIcUl5gnhatbd9s go1DDzGULimNayMfUoQfQjKeeea1CktjHQ8+XaNwSSNsrzgcH/YqEZRxRVZqgab9St7g h9QYEXaDVdHLpxHYyItVxcziwIdORy69MeKS2wAyi3V7wJ1+xNGlXniYnO4aE1YyrWmQ T72A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dg3B+lzXv9tcbX62iDOhtJa8bCIdYdJh/KH4txSlgOI=; b=Nm7jMRAkUnhGTF9U5zG3Rs2n/aOYtB/pEPJ2YetmDhSDfmzdUzClkcbHeCib5h9vPk jq1ceYyA/vVPIuip5iUlqKWSp6laAa/QUty6Jobgo5gZHO30gTGWVtVBf8UhJflyP9Is PsrUDRsmF2hgPtBVciHJxKMRMePCVCnKTCJw5G1uEDpx1i/4PCW3x/V9KxU2rHgiPWSo BCNhfHtkGG3aPmQu+dKesC8xAn6EWizwlsXdWFbOnhtR9dZvqEHsl1tq4ymKBl6JbUSz gY1B357eskjaxrWuKR+1i0jDCR5IX89Ly2jwxUCUKm+eArhueOnfPCL4j9a/0jbhutyf x7Og==
X-Gm-Message-State: AKS2vOzHFLaxITF3njKa8w1HrfcWI5Vm6psPWYyy0dR1CJwT/XUsIpz/ +AvSgNk7BJdJOWhdOYDHyvUUOon/m3xSwsA=
X-Received: by 10.80.170.23 with SMTP id o23mr9519740edc.164.1498696826605; Wed, 28 Jun 2017 17:40:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.183.131 with HTTP; Wed, 28 Jun 2017 17:39:46 -0700 (PDT)
In-Reply-To: <8760fgfakp.fsf@chopps.org>
References: <8760fgfakp.fsf@chopps.org>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Wed, 28 Jun 2017 17:39:46 -0700
Message-ID: <CA+wi2hNKkFdX1GANVETzEHOCUU=YvyPiJ0U2x9Zf_hNgYx8fwQ@mail.gmail.com>
To: Christian Hopps <chopps@chopps.org>
Cc: "isis-wg@ietf.org list" <isis-wg@ietf.org>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>, "draft-ginsberg-isis-te-app.authors@ietf.org" <draft-ginsberg-isis-te-app.authors@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0df41cf9d6cb05530e8ba4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/kbXpOcnxGaNSUw-t7CkT3naa7m4>
Subject: Re: [Isis-wg] WG Adoption poll for draft-ginsberg-isis-te-app
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 29 Jun 2017 00:40:31 -0000
After some prodding by multiple people I went and looked somewhat closer @ the 2 docs to form a more qualified opinion ;-) Meta-observation: I see two different albeit partially overlapping problems that the documents are solving. Let me distill it to a list of requirements without judging first 1. SRTE/LFA may need a different set of extended metrics (that’s what I call RFC5305) than RSVP-TE. More generic, new applications may come in the future and need TLV22/222 metric values per application OR may share the same value. 2. The application topologies may be incongruent 3. Backwards compatibility is necessary, i.e. extensions (if any) should be able to “roll forward” without a “flag day” 4. An advertisement should indicate whether an application _provides_ any of the extended metrics 4a. An advertisement should indicate whether an application _uses_ any of the extended metrics 4b. An advertisement indicates whether an application _is enabled/active_ on the link 5. Unify the RFC6119,RFC5307 link identification Now, observations to specific drafts, draft-ginsberg-isis-te-app-03 first a) I was blatantly wrong (did I read an early version or just flew too fast, who knows in the daily struggle of surviving’ the onslaught of documents ;-) and this draft does NOT define an orthogonal encoding but tries to subtly dis-entangle from one set of extended metrics into per application metrics. As usual, Les kept me firm but straight ;-) b) 4b is a NON-requirement. c) 4a seems to be a requirement but it doesn’t seem to be met (unless the set of sub-TLVs in application specific sub-TLV indicates that only THOSE are used by the application [unless the L-flag is set which seems to imply that the generic ones are ‘inherited’ but ‘overwritten’. I think some examples would be helpful here to show what the combinations of sub-TLV and L-bit on/off really mean for the application on a router understanding it and one that doesn’t have the extensions.]) d) draft seems to satisfy 1/2/4 and 3 and 5 only partially (2 by using MT if the topology has to be restricted) e) to support 3 fully a node capability would be necessary indicating whether a router understands the new sub-TLV for 22/23/141/222/223 or maybe I missed something how redundant info can satisfy 3 (then again, when do you know that ALL routers support it and can stop advertising redundant info?). f) the problem how a router would be dealing with application specific SLRG while TLV138 and TLV139 are present @ the same time does not seem to be addressed (or maybe the L-bit allows backwards compatibility here but I didn’t think through all the combinations and examples would be helpful again). Looking @ draft-hegde-isis-advertising-te-protocols-02 on the other hand I see a) 4b is a requirement b) 1,2,4,5 are not addressed c) 4a is addressed by https://www.ietf.org/mail-archive/web/isis-wg/current/msg05081.html (but to be fair not part of the original draft itself) Ultimately, I would venture to observe that a) the whole 1/2/3/4/5 problem seems to me easily addresses by using a MT per application if one is willing to accept this relationsship. It allows fully orthogonal application deployment (show different values in 222,223) and fully coupled (show same values in 222,223). The complexity of such a solution seems significantly lower than adding all those additional, fairly convoluted encoding machinery in both cases. b) 4a can be addressed by other means like administrative group (with some limitations due to the 4 octet size) or in case of MT the presence of an MT may indicate that the protocol is enabled. draft-hegde-isis-advertising-te-protocols-02 is indicating this. *So, my take after having spent the time dissecting it? Well, those draft address different requirements and we would have to argue what is the set we want to address and whether we want to address them in a single draft. * I do think that 4b should be addressed. If I'm not mistaken interaction of e.g. BW indications and how they interplay is something worth talking about. Running RSVP-TE and SR on same link both with some bandwidth guarantees without exceeding the link seems not addressed to me at all. Arguably it’s not part of the syntactic encoding but syntax without semantics is misleading at worst and meaningless at best … *With all that, I do retract my objection to WG adoption and take no position except encouraging the authors to follow several suggestions extended in this email. * On Wed, Jun 28, 2017 at 7:31 AM, Christian Hopps <chopps@chopps.org> wrote: > > Hi Folks, > > The authors have requested the IS-IS WG adopt > > https://datatracker.ietf.org/doc/draft-ginsberg-isis-te-app/ > > as a working group document. Please indicate your support or no-support > for taking on this work. > > Authors: Please indicate your knowledge of any IPR related to this work > to the list as well. > > Thanks, > Chris & Hannes. > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > > -- *We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* —Robert Wilensky
- [Isis-wg] WG Adoption poll for draft-ginsberg-isi… Christian Hopps
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Stefano Previdi
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Peter Psenak
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Acee Lindem (acee)
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Ketan Talaulikar (ketant)
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Chris Bowers
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Robert Raszuk
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Naiming Shen (naiming)
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Tony Przygienda
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Tony Przygienda
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Dolganow, Andrew (Nokia - SG/Singapore)
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Osborne, Eric
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Luay Jalil
- Re: [Isis-wg] WG Adoption poll for draft-ginsberg… Christian Hopps