Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Thu, 21 May 2020 11:44 UTC

Return-Path: <aretana.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 839AD3A0BCF; Thu, 21 May 2020 04:44:40 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 BQQKhSqL-v7V; Thu, 21 May 2020 04:44:39 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 C53883A085C; Thu, 21 May 2020 04:44:38 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id w7so6304602wre.13; Thu, 21 May 2020 04:44:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=3u3kyW2m9beL+RlcXbScO1Gd2aDH5e+xPkESMVYnTJQ=; b=Q4U8Lit/kbt9Oml4ftLvdjupODT2OZnVGDY6WKQT+SbuUZMhkaQwvsa6mATvhMaac5 gFHCmqelJqqXZGdV+aVjGZnozyX3IGy9rfhCNbp9AC11o86CUkNrYY1o1fIsH97l3GtM cDZRQb/3nERx7SGt/Rc2ff91+Qf/xdkkThkbJfOqcSMRB/R4ozOz3alIHlLBrfAH4kcr rvQ1+8uItgqOYM9nUtTDN+bfkhFCtCuCI4XaaAi4yU/DfWRNatWV9NdGICeOgmrvoJPU zxD6o477Sac30x7k9E7RQcz/OZAEIU0LFiW+l0amm5tbnMMkcFTmbocTbmMHiAZGE4sN 5f/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=3u3kyW2m9beL+RlcXbScO1Gd2aDH5e+xPkESMVYnTJQ=; b=FFX45pZWSEOhQhtnr9bE/06Bhu0zqJ4+8/Z8rEz5UKOZjt0HGMy23EEKjYbNyR2WS0 XYuQ7rRikg4ekgEiqbtWSqxzqYhKD6ielmVK/r6Fnj1/ZNREEdB8Xrvyl/M1zOcJFtkq 36glr8spGkLIB54fjlUvJolTXcRlzZ+Nn1HDLIeTnha/hSS5lGOoSU67KFoVWdzLhGuN MZYiZ2eS0nSiK3HLg3KU41TxkwR6ChclD/9zYOUWxqXm6x1fn0c+ZFQkTu/xROPz1e/X 2Vx7hMntUwRo5Z+uWYrGYSEUJYK3BJp/mBjoyYgLE8kAs85wtvV38UlgNF5JisLJMhat FvPQ==
X-Gm-Message-State: AOAM531n9ZAlH4gmZndPAX2UHSkCpJLxHGZxA93M05QTxNfwtzAGxbVu YjheDiUYl9UCtw7DKqHeBgJoZTCwGgrLZ9KPE84=
X-Google-Smtp-Source: ABdhPJzeFqJIQNd/hSaIn7xOW79s1W6bMJf++JXslg8+NvGZKBFeQuOSB0Y3rp5uG0xsmQxykbFMJcn8jSP7aKMjIPk=
X-Received: by 2002:adf:ef83:: with SMTP id d3mr4993338wro.145.1590061477054; Thu, 21 May 2020 04:44:37 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 May 2020 11:44:36 +0000
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <1242ad52-bb48-8526-b65b-d413e0cd9e25@cisco.com>
References: <158992828112.6026.1646593855480055081@ietfa.amsl.com> <1242ad52-bb48-8526-b65b-d413e0cd9e25@cisco.com>
MIME-Version: 1.0
Date: Thu, 21 May 2020 11:44:36 +0000
Message-ID: <CAMMESsz3esEVMBgaPZQd3bUQG9-t5=vG6W3_P0rDZ51Ua25hRw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Peter Psenak <ppsenak@cisco.com>, The IESG <iesg@ietf.org>
Cc: Acee Lindem <acee@cisco.com>, draft-ietf-isis-mpls-elc@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/POP8t8MXDOo7849GILDlPh-wk9Q>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
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 11:44:41 -0000

On May 21, 2020 at 6:05:41 AM, Peter Psenak wrote:


Peter:

Hi!


> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > As for other reviewers, many of my comments duplicate those for the OSPF
> > document; I expect that the analogous responses apply and am fine if
> > they only appear for one document's review.
> >
> > Here, the question I have about normative language applies to the text
> > in Section 3:
> >
> > When a router propagates a prefix between ISIS levels ([RFC5302], it
> > MUST preserve the ELC signaling for this prefix.
> >
> > The scenario in question is analogous to the OSPF cross-area case: is
> > the router propagating the prefix between ISIS levels required to
> > implement this document; is preservation of the flag value a new
> > requirement from this document vs. a preexisting property; and is this
> > document trying to make normative requirements of devices that don't
> > implement this document?
>
> ##PP
> this is a new requirement and only applies to the routers that support
> this document. We are not making normative requirements of devices that
> don't implement this document, we cannot.
>
> Maybe we can add that it only applies to the routers that supports this
> extension:
>
> "When a router supporting this extension propagates a prefix between
> ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix."
>
> Would it work?


You're right, we can only apply requirements to routers that support
this specification.  IOW, adding the clarification is not necessary.


My interpretation of Ben's question is two-fold:

(1) Would ISIS routers normally propagate the information to a
different level?  The ELC is a new prefix attribute flag -- are prefix
attributes always propagated (unchanged) to other levels?  If so, then
the requirement (MUST) is not needed.  My reading of rfc7794 is that
the propagation is optional...

(2) If the propagation is not automatic, and the L1L2 router doesn't
support this specification, then what are the drawbacks/failure
scenarios?  IOW, for multi-level operation is it a requirement that
the L1L2 support this specification?


Thanks!

Alvaro.