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

Alvaro Retana <aretana.ietf@gmail.com> Fri, 22 May 2020 14:59 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 34B9E3A0AEB; Fri, 22 May 2020 07:59:38 -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 Sc-wJlsj6LM1; Fri, 22 May 2020 07:59:37 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 BE35B3A0AE5; Fri, 22 May 2020 07:59:36 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id l11so10510645wru.0; Fri, 22 May 2020 07:59:36 -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=Q+r9VrrEDxjffKFTgr0yjpSyNYJif+IV4+2yWjW8JFs=; b=k6SUqQ8rp0EQqqlOI7oeDAZbHk5lJ9Q40D7YCzHl2OjcIOxcsiPBzZHCeqqbI3qBYM LoB8paEol/Ig/02F9d33qkBVOstO9sNj3qBO4CwGnqHhFqhWWdxiHeRVpqXKIMA22l+5 FYAJw3Txp8QX1pXDKkXVmvjpV+Gwuonf1EluO06zTi/BTJjv/bgbuqiTg0mHRZhD1y4x zOZWM1oSifk4gUQp6GXKHnXpWP/+Q6r8d5HcMWA7k4xumfxNp5D6QP2BWwidDhYe9gC1 MobKPxxtUYlbLeMNQrXo49dI5USRwvZqwqIEdL5iNko10Ez//1n65tpRgbBEC5iaddd3 a3fg==
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=Q+r9VrrEDxjffKFTgr0yjpSyNYJif+IV4+2yWjW8JFs=; b=FhqG1a0BUfyVuoueVtSQUMx9MrnNp7YQI6Syr/1irHrOAQrHPrbLNmb+Qa8pEQbbJa XYzYtcZl3Cm5JyVdtBuCTsyLuIg5KBo/blToWlFZJ9OKdBAZhBaKHNYgghChiw3uOrsj nlS4k6W6iMYkWGo3MSg/iu2e//yYJSwsMWwZsNR9djNJGNfrw8C8FjkM1PxfgeN2tKqT J2EtFrfTYbTfCmW3Hehii71iNuh+jybJSlMSmeKVdbYB3f1YycGplrcZ0dB+mXW1bRNk mQyBQoiTDuo5423xy/WIHbtYta4i5NDN+RW0TI8Yu92xTXNhe7lMIJCllf7Rr4U0jsCR hHJw==
X-Gm-Message-State: AOAM533hC2eJISaCqjkprvwH6PnCBgCDQec9+1WWgB4AuKMfCxGvdDnh 86oyHL3kfext+xjk0Ji4ol2r0RbGaqm6DJ+lhGg=
X-Google-Smtp-Source: ABdhPJybwEaNKB5ApNV7YweJd1vxJxuH8u31rYi9aomaJ3AQunmyOxTPx56DqRYHegkpar2ml7kw1hlMyp+XH9e4HGM=
X-Received: by 2002:a5d:6943:: with SMTP id r3mr3638135wrw.113.1590159575143; Fri, 22 May 2020 07:59:35 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 May 2020 14:59:34 +0000
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <20200521193856.GJ58497@kduck.mit.edu>
References: <158992828112.6026.1646593855480055081@ietfa.amsl.com> <1242ad52-bb48-8526-b65b-d413e0cd9e25@cisco.com> <20200521193856.GJ58497@kduck.mit.edu>
MIME-Version: 1.0
Date: Fri, 22 May 2020 14:59:34 +0000
Message-ID: <CAMMESsxo56ZK+DKBMkKvFcXf+1GFPF+wDtRCW=+md8WCoKODxw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Peter Psenak <ppsenak@cisco.com>
Cc: Acee Lindem <acee@cisco.com>, draft-ietf-isis-mpls-elc@ietf.org, The IESG <iesg@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/dnvn6Qc09YiLJ-ZqzNQ-L8fAJAE>
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: Fri, 22 May 2020 14:59:39 -0000

On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote:


Peter:

Hi!


> With respect to Alvaro's clarification, your answer for (1) makes sense;
> thanks! I think Alvaro has offered to help work out what (if any)
> additional text we might want to be sure that the answer to (2) is clear in
> the document.

I think that #1 is where some clarification could be useful. :-)


I'm including both ISIS and OSPF suggestions below to consolidate the
discussion.


...
> > 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...
>
> depends on the attribute or a bit. Some are propagated some are not.
> That's why we are saying this one MUST be preserved.

Right.

For ISIS I think the current text is in line with the specification of
the other bits in rfc7794.  No changes are needed.

If anything, you may want to change the order of this sentence to
address Ben's comment:

OLD>
   When a router propagates a prefix between ISIS levels ([RFC5302], it
   MUST preserve the ELC signaling for this prefix.

NEW>
   The ELC signaling MUST be preserved when a router propagates a prefix
   between ISIS levels ([RFC5302]).

[Similar for OSPF.]



I think that for OSPF it is not that simple...

For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix
Opaque LSA depends on the scope of the advertised prefixes", which I
assume means that for intra-area prefixes the scope will be
area-local...so the ABR wouldn't simply propagate it; it would have to
originate a new LSA.

Suggestion (Add to 3.1)>
   When an OSPFv2 Area Border Router (ABR) distributes information between
   connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA
   [RFC7684] including the received ELC setting.  If the received information
   is included in an LSA with an AS-wide scope, then the new LSA is not needed.


For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find
anything in rfc5340 saying that the received values should be copied
into the Inter-Area-Prefix-LSA (nor that they should not).

Suggestion (Add to 3.2)>
   When an OSPFv3 Area Border Router (ABR) distributes information between
   connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA
   MUST be the same as the received value.




> > (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?
>
> drawback are identical to what is mentioned in the Security
> Considerations section.

I think that text is ok.


Thanks!

Alvaro.