Re: [Lsr] Tsvart last call review of draft-ietf-isis-te-app-13

Kyle Rose <krose@krose.org> Thu, 21 May 2020 13:08 UTC

Return-Path: <krose@krose.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 C68D53A0C71 for <lsr@ietfa.amsl.com>; Thu, 21 May 2020 06:08:45 -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 (1024-bit key) header.d=krose.org
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 q9pPNqxE6GOz for <lsr@ietfa.amsl.com>; Thu, 21 May 2020 06:08:43 -0700 (PDT)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 055083A0C6E for <lsr@ietf.org>; Thu, 21 May 2020 06:08:42 -0700 (PDT)
Received: by mail-ua1-x930.google.com with SMTP id f9so2548061uaq.2 for <lsr@ietf.org>; Thu, 21 May 2020 06:08:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dC7x8Fwk62lXhe5QA+M0WmsxvY5U8aoS0MTfCoqJRu8=; b=W32uAf1+UYGLgoW9NFjkeCwxha4eCheLRpOpb6dlco0n00fVdG+8S11XS+jQvSPkNS nggME+YBE1FksnfGNTi6eTE7G99VJCvdpLBXzLbH5b+ZXUdvhTGUMqy3NTNPRwDhrMuz bznWODvIR4Pg2gwEHsCrUiFy5VPm+N6lOmaE0=
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=dC7x8Fwk62lXhe5QA+M0WmsxvY5U8aoS0MTfCoqJRu8=; b=Y2u2OWAi17pUDLlCOBrTKbRHlmyp47C+eVpkeTeK/QaPoOqNv2HChF2vZiYPlpYQ5W OWGggVvZFf+gIIoIXXdSOyal7v0+lnv9D5dvoicJsbShw0H6wm8yB9IJ6Q+qfI6eqyZc GqUrW9SmF0Wz8XzvoZKE3emD+yQkZP2OFUiAjzEswhK/VCKsO2vefHCJymnhpqSy12Zk PzS4VE7c/x91hpNHINmTtzxV0DaVx0z1B7VfkntNNn0Am9Qf2hZko6mqekd1FwN27eCP WwU9Lni/Xn9icHOgrPGdnzgMfRoy4vTn2ehBiuS+yllKU4lggPfIheIKeuV9VzrDR5EN QwdA==
X-Gm-Message-State: AOAM53266fkgm3dxHSD5vZULdoWrm/9lh4KLciSgui7B0ZWggTp5z11J aD14lyAyxoTuS6q95kILVX6p5mX9QJMMj8qRxmPM/A==
X-Google-Smtp-Source: ABdhPJxgCS+DM4pUzw/8RB3VpLRxTwxVA10aH2/FZ1DsYITesOPlPe7+RMRW4nHxmvFhaUrgJD2ENOB+cNILGcwFzG0=
X-Received: by 2002:a9f:2603:: with SMTP id 3mr6838492uag.57.1590066521304; Thu, 21 May 2020 06:08:41 -0700 (PDT)
MIME-Version: 1.0
References: <159001647095.11068.10737326366413541910@ietfa.amsl.com> <MW3PR11MB4619078973BA1AC8CADF9EDAC1B70@MW3PR11MB4619.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB4619078973BA1AC8CADF9EDAC1B70@MW3PR11MB4619.namprd11.prod.outlook.com>
From: Kyle Rose <krose@krose.org>
Date: Thu, 21 May 2020 09:08:30 -0400
Message-ID: <CAJU8_nWdOEDOsQ=bOYe54PfC1kcgOpm75Kua06N8UsGj4bJNDw@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-isis-te-app.all@ietf.org" <draft-ietf-isis-te-app.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002c093f05a6283661"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/CeALsIm2o7yxfxq6R-aNuiVd990>
Subject: Re: [Lsr] Tsvart last call review of draft-ietf-isis-te-app-13
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: Thu, 21 May 2020 13:08:46 -0000

On Thu, May 21, 2020 at 2:28 AM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> > * Update language?
> >
> > There are several places in which it is possible that normative language
> in
> > prior RFCs is revised. For example, in section 6.1, the last paragraph
> states:
> >
> >   New applications which future documents define to make use of the
> >   advertisements defined in this document MUST NOT make use of legacy
> >   advertisements.
> >
> > This looks like it was written in such a way as to avoid requiring such
> > updates, but it would be good to confirm that there is no normative
> language
> > in
> > older documents that would conflict with this requirement.
> >
> [Les:] For applications which preexisted the writing of this draft (the
> ones defined in Section 7.4) there are existing deployments which use
> legacy advertisements.
> Transitioning to use new advertisements has to account for partial
> deployment of such support.
> And the transition has to be managed by the network operator using knobs
> provided by implementations. This is onerous - but unavoidable in these
> cases.
>
> For new applications we want to avoid this complexity/pain. So we specify
> new applications MUST use the new advertisements from day ONE.
>
> As these are new applications there is no legacy to deal with and no
> existing specification which would be in conflict.
>

That's what I figured. Is it the case that new standardized applications
require an RFC? If so, I think this is fine.


> > * Encoding
> >
> > In section 4.1, the bit masks are defined with a 7 bit length field for
> which
> > only 4 bits are useful (values 0-8). It may make sense to keep the 3
> high order
> > bits as "reserved" and set to zero, but either way it would be nice to
> > understand the justification for whatever design decision is made.
> >
> > You go to some length to save space (e.g., a zero-length SABM means "all
> > applications") but always include an octet for UDABM length, which I
> > presume
> > will be zero outside the lab in most cases. How much does an extra octet
> > cost?
> > If it's a lot, you could use the three high-order bits to represent the
> first
> > three applications (RSVP-TE, SRTE, and LFA) and save yourself an octet
> until a
> > fourth application appears.
> >
> > For that matter, how likely are you to get to 256 standardized
> applications
> > under IS-IS?
> >
> [Les:] The limitation for the xABM length to be no more than 8 bytes was
> introduced only recently based on a review comment.
> The concern was that without a limit, it would be theoretically possible
> for the ABM itself to consume the full sub-TLV space, leaving no room for
> the actual link attribute advertisements.
> So we placed a maximum length to avoid this potential issue.
> As each application consumes one bit, with an 8 byte maximum length we can
> support 64 applications.
>
Sigh... yes, math is hard.


> This seems more than we will ever get to - but if anyone in the WG thinks
> this is not large enough they should speak now so we can increase the
> maximum.
>

I suspect even 64 is safely more than you'll need, but if not there's
always the possibility of a new TLV later on. :-)


> There are existing implementations of this draft which have been deployed.
> Changing the bit positions as you suggested would not be backwards
> compatible.
> I do not think the small space savings would be worth the trouble.
>

Understood, though I will point out that this illustrates the potential
harm in deploying something hard to change prior to standardization.
Thankfully, IS-IS is not interdomain, meaning that any such change would
impose costs only on those who deployed early.

> > In effect, use of legacy advertisements vs. app-specific advertisements
> is
> > all-or-nothing. If that's the case, wouldn't a top-level TLV specifying a
> > legacy mask for applications be more compact, less redundant, and further
> > reduce the overall number/size of advertisements?
> >
> [Les:] The information being advertised here (link attributes) is
> necessarily associated with a top level TLV describing a link to a neighbor
> (TLVs 22, 23, 25, 141, 222, and 223) . Without that context the link
> attribute information is meaningless.
>

Yes, this makes sense, and probably would have been obvious were I more
familiar with IS-IS and link state routing in general.
Thanks,
Kyle