Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Julien Meuric <> Wed, 24 May 2017 08:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A44CE12896F for <>; Wed, 24 May 2017 01:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.635
X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IhOTqaivBLIg for <>; Wed, 24 May 2017 01:54:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8291F127337 for <>; Wed, 24 May 2017 01:54:06 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 4F2025D897B; Wed, 24 May 2017 10:54:05 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 377965D8974; Wed, 24 May 2017 10:54:05 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.319.2; Wed, 24 May 2017 10:54:04 +0200
To: "Acee Lindem (acee)" <>, OSPF WG List <>
References: <>
From: Julien Meuric <>
Organization: Orange
Message-ID: <>
Date: Wed, 24 May 2017 10:54:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 May 2017 08:54:09 -0000

Hi Acee,

There is indeed overwhelming support on the feature. However, reading
this brand new -01 (thanks for the advertisement) and the necessary
backward compatibility section it had to include, I wonder if this I-D
is specifying a solution to a problem vs. creating new issues...

More generally, we should clarify how much we, as community, are ready
to duplicate protocol extensions/codepoints on a solely "repurposing"
basis. If there is a risk of redefining all extensions originally
specified for the TE use-case, we must right now discuss where to
globally draw the line between what we may accept and what we will not.
Otherwise, we will jump onto a controversy each time a new parameter set
is tackled in a dedicated I-D.

Please note there are some other ways forward in the Routing area. For
(random) example, PCEP has been repurposed from a its original scope to
encompass capabilities to push state. To do so, some features and
objects had to be repurposed, but the specification managed to reuse the
original ones, avoiding any backward compatibility considerations...



May. 23, 2017 -
> The WG adoption poll has concluded and there is overwhelming  support
> for this document. 
> Additionally, addresses
> the comments received the adoption poll. 
> Authors, 
> Please republish the document as draft-ietf-ospf-lls-interface-id-00.txt. 
> Thanks,
> Acee
> From: OSPF < <>> on
> behalf of Acee Lindem < <>>
> Date: Thursday, May 4, 2017 at 2:45 PM
>     This draft was presented in Chicago and there was acknowledgment
>     that a solution was needed. The authors have asked for WG adoption
>     and we are now doing a WG adoption poll. Please indicate your
>     support or objection by May 20th, 2017. 
>     Thanks,
>     Acee