Re: [Lsr] Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

Warren Kumari <> Wed, 31 March 2021 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 215A93A3655 for <>; Wed, 31 Mar 2021 13:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 YILx3A5sDUMs for <>; Wed, 31 Mar 2021 13:30:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E64C13A369F for <>; Wed, 31 Mar 2021 13:29:56 -0700 (PDT)
Received: by with SMTP id f16so25456495ljm.1 for <>; Wed, 31 Mar 2021 13:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zRhVcHwUstIyhN6isRQhfFHsB2hPOQXIjXR3/vyl37Q=; b=B+C2gqEqH2p1owZ9bubJxrGYc+n58f03ko8exjfSWx3/lyfervpii9mfr5TQ0J5rlx xSJZvF82wadnlzegYSRrYI+DiQ4HAdizm7h8XX8Ci7+c/quSKy6EKaWE5FGN9J+SyY8/ LEOMJmKdGVLoEXVtKgxyrbAXNoxsMqOJTY1axP0xMFzgxb1JUkvAMO45U6tNKg2iuowN rZLAxZFZ2jKoLyw5iQk5VnZvxXNxDk6B1Xs6KaTnweEwKRriOstFDREtCcW8FWPryXvs w4lwM+GFqPttx0g6zjJl/YIw6aNkrkSy3RVpGq/6d5jL2tUfOmAq9bGEe4SYKO43/SoL 5o1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zRhVcHwUstIyhN6isRQhfFHsB2hPOQXIjXR3/vyl37Q=; b=kAOdyn4SSmvLWoRbfJB53sLGHRLwz2h85yXNvht6zXsv8ojisWLml+Y+LgqD01t2PY 7BZlgcDz7RLBezY2/9PN5rmJQpEemY4TefoH7t+oMjwhiQh0otzZ2xqJKXd5gBeVd7Ub zscyBHgn1WG8RKlDOAwhKh9wbPNU/tg15PKQMNMSDuOdGfF+jCwKAdHVJhM88EWgRdte RvrGxY184ysH0K62j5UzTtB70xAyqVPzSBY98pjBRz2qldUJlM8L3kFqmeHIR/u0ZStb k+ztb3ydNA2VFPhdtLmxF841Ck2ax1hWE/Eqeel6MJuLVsDZhiX+oIX0NcKHnKNt2BiE 7Qnw==
X-Gm-Message-State: AOAM533e9ByyxpLmol05Mpdt9MlOOrqHC/Yatbqo3TpCd9m718ldS5Mc CXQwG/moluF2a9RXrR3QteIp30+aJu/lbaJpRYZnGQ==
X-Google-Smtp-Source: ABdhPJyMQkIXAckAbihjGoes10FDMqFwOwktAVbmycIla3AkwqH7E/zWQ1YwtH2qdLWQgst0n40aS7n7E5o1WNtK+R8=
X-Received: by 2002:a2e:5753:: with SMTP id r19mr3182570ljd.126.1617222593701; Wed, 31 Mar 2021 13:29:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Wed, 31 Mar 2021 16:29:17 -0400
Message-ID: <>
To: "Ketan Talaulikar (ketant)" <>
Cc: The IESG <>, "" <>, "" <>, "" <>, Christian Hopps <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000003879b505bedafa44"
Archived-At: <>
Subject: Re: [Lsr] Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: (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, 31 Mar 2021 20:30:05 -0000

On Wed, Mar 31, 2021 at 2:46 AM Ketan Talaulikar (ketant) <>

> Hi Warren,
> Thanks for your review and please check inline below. Will look forward to
> your inputs on how best to incorporate them in the draft.
> -----Original Message-----
> From: Warren Kumari via Datatracker <>
> Sent: 31 March 2021 00:53
> To: The IESG <>
> Cc:;;
>; Christian Hopps <>rg>;;
> Subject: Warren Kumari's No Record on
> draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)
> Warren Kumari has entered the following ballot position for
> draft-ietf-lsr-ospf-prefix-originator-09: No Record
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I'm balloting No Objection, but I really would like a response...
> 1: I'm assuming I'm just missing something obvious here, but Section 2.2
> sayeth:
> "A received Prefix Source Router Address Sub-TLV that has an invalid
> length (i.e. not consistent with the prefix's address family) or a Router
> Address containing an invalid IPv4 or IPv6 address (dependent on address
> family of the associated prefix) MUST be considered invalid and ignored. "
> What is an "invalid IPv4" address here? If the length is 4, and the route
> address is 00000001 or 0xc0a80001, how do you know that that's not what I'm
> using? Again, I suspect that there is something obvious that I'm missing
> here...
> [KT] I did some digging around and was not really able to find a good
> reference to what would be "invalid IPv4" in this context. 0x00000001 would
> be invalid but 0xc0a80001 would be valid. A multicast or ClassE or
> 0xffffffff would also be invalid. Basically, any address that cannot be
> used as Router Address (i.e.
> would be invalid. Not
> sure if we should just remove the "invalid" part here or to attempt to go
> about specifying it.

I'd suggest just removing it -- trying to specify what "invalid" means in
this case will likely lead to madness. If you really want to keep it, I'd
suggest just saying something along the lines of "A received Prefix Source
Router Address Sub-TLV that has an invalid length (i.e. not consistent with
the prefix's address family) or a Router Address containing any address
that cannot be used as Router Address (i.e. MUST be considered
invalid and ignored." If it were me, I'd just delete the last bit, and back
away slowly.... Actually, I'm not even sure that ignoring it *is* the right
answer. If I look through $whatever and see a Router Address of 0xffffffff,
it is "meaningless", but possibly it is evidence that something, somewhere,
is horribly borked, and I should probably go investigate.

> 2: This presumable has the side effect of increasing the size of the lsdb,
> possibly by a fairly large margin. It seems like it would have been nice to
> include an operational considerations section noting this, and, while you
> are at it, that this document will significantly aid in debugging....
> [KT] Almost all of the protocol extensions do result in increase of the
> LSDB size. However, depending on the use-case, these extensions may be used
> for select prefixes (e.g. the leaf networks to which traffic/service flows
> are destined to). The Sec 3 does have the following text that touches upon
> mitigation for this scaling part:
>    Implementations MAY support the selection of specific prefixes for
>    which the originating node information needs to be included with
>    their prefix advertisements.
>    Implementations MAY provide control on ABRs to selectively disable
>    the propagation of the originating node information across area
>    boundaries.

Noted (and that all extensions do increase the LSDB size) -- this extension
is *possibly* different in that it seems that it has larger scope. Whatever
the case, a simple "This may provide information hiding, and also limit the
increase of the LSDB size" or "Consideration should be given to the
operational impact of the increase in LSDB size" somewhere would make me a
happy bunny. Note that my ballot is a NoObjection (non-blocking), and I
will not be overly sad if you ignore this...

> [KT] Regarding the debugging part - I agree. Should we add an operational
> considerations section here or just include this aspect in the introduction
> within the following text?
>    The primary use case for the extensions proposed in this document is
>    to be able to identify the originator of a prefix in the network.  In
>    cases where multiple prefixes are advertised by a given router, it is
>    also useful to be able to associate all these prefixes with a single
>    router even when prefixes are advertised outside of the area in which
>    they originated.  It also helps to determine when the same prefix is
>    being originated by multiple routers across areas.

Either. I'd personally like an operational considerations section (hey, I'm
an OpsAD, I *always* want an Operational Consideration section :-)), but
I'm also fine with this just being stuffed elsewhere in the document. If
you**do** add an operational consideration section it would be a perfect
place for the above comment :-)

> Thanks,
> Ketan

The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra