Re: [Lsr] Barry Leiba's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

Alvaro Retana <> Wed, 06 May 2020 11:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 883E43A0941; Wed, 6 May 2020 04:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZWfYa_zF8snO; Wed, 6 May 2020 04:06:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FBB53A0935; Wed, 6 May 2020 04:06:32 -0700 (PDT)
Received: by with SMTP id k12so2096403wmj.3; Wed, 06 May 2020 04:06:32 -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:content-transfer-encoding; bh=VgH1kE+RQ7toEzMp0n9nh4PD5x4uuuqhwTY6FrS2UWw=; b=nbTi+wm6U+LYdbai5ZpSreE+EYmI6FnuPBZWI17o6OJCEt/ChcNNUBpgj72UisWnoR 3H4JX2utyvUnt5C0Qtw6AC2ZWqZS1s8D+mLM3yMW4grNfFM1Q5K3nbs1cNRLIq/2G3Im bl6BlIog+WHk7lB49BWB7hNg4BU7kkksEQMNc5QONBmGAKJLePT0rXoee5b1/E9AtTyh vPgEl6Zo0YDTsbhn7seOTky4F3oFkhvXnxEd/TVr1MrwGJ8DUtNnPL1mnUTTh2t+Cr0a mJpqmcm8+/3TufEEP3jw1kOvqeylQqVX7hm4SoMGtiulNiSY4x4uB6Qsac7jaqoRzIr2 33kQ==
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:content-transfer-encoding; bh=VgH1kE+RQ7toEzMp0n9nh4PD5x4uuuqhwTY6FrS2UWw=; b=d0MtmWW+PFRUEV0RBiLx96VKZ1NoGOX7dFFCY0qR3/BffDfz+7DhXOzQ9abmQLQi6E MkYj/k4N1D+MuPs40M3K1SC6DllBOp9iegksNcVFW8bJEjXo/vOhQqOo5LRzFoXGeCpe ixyxNbmm9zJ6QEqe/sp0L2/pMZLoqy2p1jDIuw0TUmFd/A1oWRMtw9AUANQQOZ9R66fb bLY+2MunGNvgGwJ22YvqdyU8nTUrq3KhErQeZoKVS5edk/N94q7ME5FsB9mhqL2+2Td5 vDDXFNCTD9rJfalmPLzfpyIym764p4hs5K0Hw5uURe7NTaTe7ZJSv6JoA/bY5OCXMUQR BwKA==
X-Gm-Message-State: AGi0PuanNGsg7PBSp7MpzJGgufb1SYJ94N8C0+IE4un8lrxgf/WxVSOo XnMyB2RoKUm7ArAhvEgR7RHvl1C/YCwhytEKslhOHBvk
X-Google-Smtp-Source: APiQypJHTnm2ty4jp1lkUrPkPfvD9Er7EfIkhxWvDmdProQ08lMa+PXa+Rc90EFwm21zDqlqtijwSnYIsN1aYhWKOqg=
X-Received: by 2002:a1c:f312:: with SMTP id q18mr3710315wmq.175.1588763190609; Wed, 06 May 2020 04:06:30 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 6 May 2020 04:06:30 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Date: Wed, 6 May 2020 04:06:30 -0700
Message-ID: <>
To: Barry Leiba <>, The IESG <>, Barry Leiba via Datatracker <>
Cc: Acee Lindem <>,,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Lsr] Barry Leiba's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)
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: Wed, 06 May 2020 11:06:35 -0000

On May 6, 2020 at 1:12:42 AM, Barry Leiba wrote:



> — Section 4 —
> The ERLD is advertised in a Node MSD sub-TLV [RFC8476] using the
> ERLD-MSD type defined in [I-D.ietf-isis-mpls-elc].
> Just checking: is the IS-IS draft the right reference here in this OSPF
> document?

Yes, it is.  The new ERLD-MSD type is defined there for all routing protocols.

> There does seem to be so much common text between that document and this one
> that I really don’t understand why these (the IS-IS and OSPF signaling) were
> not put into one document, and this reference really drives that home.

One of the objectives of merging the (old) isis and ospf WGs into the
lsr WG (this happened a couple of years ago) was to have common
discussions about two IETF protocols that are similar: both are link
state protocols, for example.

However, they are different protocols and deployments use one or the
other -- sometimes with religious-like fervor.

We have discussed the prospect of having a single document specifying
both OSPF and ISIS behavior, plus any corresponding BGP-LS extensions.
Among other things, that could reduce the document load...  However,
the consensus in the WG is that the result of that would be potential
confusion when it comes time to talk about the features supported or
required in a specific network.  For example, it is much clearer if an
RFP requests support for rfcxxx than if it has to be specific about
rfcxxx/Section y (where the desired protocol extension is specified),
while not requiring Section z (for the other protocol).

As a result we ended up with two documents.  As a tradeoff, I've
insisted in as much common language as possible and to process the two
documents the same time when possible.