Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

Alvaro Retana <> Thu, 14 May 2020 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 973583A0C4F; Thu, 14 May 2020 12:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kx5QrM5vvilz; Thu, 14 May 2020 12:46:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7D463A0C4D; Thu, 14 May 2020 12:46:11 -0700 (PDT)
Received: by with SMTP id y3so228655wrt.1; Thu, 14 May 2020 12:46:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=+IsOwcBsqmVwgL1qhDUalf7mrRFVXIkSWL602P/zkiM=; b=W1qc4qJrLYnMxKSzNrm3FnpXIeqG2wQAbcjVT1fgggFv9XSuai1yhofvl/Jf/Jc7vs DP345LHqzIP12mmvIln/BqKyBafVbMAT0R5ZNt5BBFZsiuwSoYH5MNvVHZwhpLUuoblt tucMDnqwsRqKXQJCljblNF+XGaNSfQsLwgZSnLr33hQdWNwdnFZSvSruo4dhPa5eRk8K 1PXVrv19gD3VaiReStxj5qvx7QTTY3NzvKPdmckK+ZMRAHZhmUbvq6M0a59cdnsQ7QD9 6OE5/kCKOT4Vv1m053ns0S/gDtbKoo8SpZXJh+fICCJT1LdGozLZi8EdvNrKSVOA/kmW Ad1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=+IsOwcBsqmVwgL1qhDUalf7mrRFVXIkSWL602P/zkiM=; b=KLFfxvHYCeQ0dleylz4MxSsGOfUoH0FBJ9qRViLWCLKOhhtX1PO2ph5jb5o16NUz8z e9z3bbq87PZbV5oBSM36vYgQ0SYLBlKRCVmN0V9uuAVbu0Nmne1HznwtGVAfomHyn6Lr TqIQpnP+1VFkHqwDVjCY5cWoszuZmM2OdPbORExDdcrCJp5ZIIAiNr8eY3DY5epYCUvY +IpR3bDvJIjHCkca/IweFyGcC9rA0aVm//lPyb8+j9zJvZWLnTQdToqrU36g8CESLHkd A2CdJI8q5FcUgkGm5qMIuBibclxjxAmzC8K8u0EeOBLonnbr7re+bDABk4Ij4F3C1pA3 6F9g==
X-Gm-Message-State: AOAM532D4GVxkf8FkXS/cDzt/nCjbN4T3RN+7MyIy0ZLKqMiC1YfLMJG pIDc9+VJE911mcmVhyl6Wt23u4lMEBqvc21HQnE=
X-Google-Smtp-Source: ABdhPJxldCTQ+SiVpiQ0CFH3YHMVhHcsWxWqfhI8xjZH7ElRgIHy0zuGa1586uJYxxL4UX8Q1nMiBk4UeQ/zxucmxKU=
X-Received: by 2002:a5d:5089:: with SMTP id a9mr41228wrt.147.1589485570292; Thu, 14 May 2020 12:46:10 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 14 May 2020 12:46:09 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Date: Thu, 14 May 2020 12:46:09 -0700
Message-ID: <>
To: "Acee Lindem (acee)" <>, "Peter Psenak (ppsenak)" <>, Elwyn Davies <>, "" <>
Cc: "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000cb044b05a5a0f296"
Archived-At: <>
Subject: Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 May 2020 19:46:15 -0000


Yes, we cannot specify something that routers unaware of this specification
should or shouldn’t do.

I believe that Elwyn’s point is this: *if a router supports this
specification* then when would it not advertise the ELC?  IOW, the
specification only obviously applies to implementations that support it —
in that case I would think that if a router supports ELs on all of its
interfaces then it would always advertise the ELC, right?



On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) ( wrote:

Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support
multipath forwarding entropy using MPLS entropy labels but do not signal
that capability in OSPF. We can't have a document that retroactively
mandates that they signal it. This wouldn't be backward compatible. How can
you possibly see this as a serious issue?