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

Peter Psenak <ppsenak@cisco.com> Wed, 24 May 2017 11:26 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893FE12953F for <ospf@ietfa.amsl.com>; Wed, 24 May 2017 04:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 sHKrZt8413ua for <ospf@ietfa.amsl.com>; Wed, 24 May 2017 04:26:56 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C0D129548 for <ospf@ietf.org>; Wed, 24 May 2017 04:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4231; q=dns/txt; s=iport; t=1495625216; x=1496834816; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=pLW86AxqumT2d5kiVa8oBu8Hi0EUw4Mh/GSxiMQ2uhE=; b=U/92mFY/eP/qK3GfCsswLy679FPd3kzvqLG5auSn2Fo3yK6XT/aLh3nf Y4yq2hsUqG7zYFTLYerLz20icEeBwmbftd4c6OLl4UC9PBetqJr61mZn6 at96DphSx8OG7R6uTsqMa5JRD/uNIrmTHL4OpNFz42Ar18UB4O2ohynAI 4=;
X-IronPort-AV: E=Sophos;i="5.38,385,1491264000"; d="scan'208";a="652060969"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2017 11:26:54 +0000
Received: from [10.147.24.31] ([10.147.24.31]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v4OBQrtp011640; Wed, 24 May 2017 11:26:54 GMT
Message-ID: <59256DFD.1020107@cisco.com>
Date: Wed, 24 May 2017 13:26:53 +0200
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Olivier Dugeon <olivier.dugeon@orange.com>, Julien Meuric <julien.meuric@orange.com>, "Acee Lindem (acee)" <acee@cisco.com>, OSPF WG List <ospf@ietf.org>
References: <D549C342.AFC83%acee@cisco.com> <3733295c-3e40-d780-ad7b-78d02ff0c50b@orange.com> <5925543D.60800@cisco.com> <4dbc99c6-15b7-f35c-42de-2b61086242a9@orange.com>
In-Reply-To: <4dbc99c6-15b7-f35c-42de-2b61086242a9@orange.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/1dPdKQiAQf1rybbW-tWJAP4lKSQ>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 May 2017 11:26:58 -0000

Olivier,

On 24/05/17 12:19 , Olivier Dugeon wrote:
> Hi Peter,
>
>
> Le 24/05/2017 à 11:37, Peter Psenak a écrit :
>> Julien,
>>
>> - I don't know if there is any implementation that uses the solution
>> proposed in RFC 4203. I sent a query to the WG list and so far I have
>> not heard about a single one.
> I already write a basic support of RFC 4203 publish originaly in Quagga
> and now available in FRRouting. Link Local /Remote Identifier are
> decoded and it is quiet simple to add configuration at the interface
> level to advertise them.
> I could provide a patch if needed.
>>
>> - there is not even IANA registry created for the Sub-TLVs of the Link
>> Local TLVs and there is no IANA value reserved for Link Local
>> Identifier TLV as defined in RFC4203.
> For us, there is a simple solution: Just use Link Local / Remote
> Identifier TLVs with Remote Identifier set to 0 if it is unknown.

that is not what RFC4203 suggests, so it's not a standardized behavior.

thanks,
Peter

> There
> is no need to create one more TLVs parameters. From an operator point of
> view, it is already very hard to manage all existing TE parameters. Why
> adding extra TLVs when existing ones could be used ?
>
> Regards
>
> Olivier
>>
>> So at the end we may not even have any duplication at all.
>>
>> regards,
>> Peter
>>
>> On 24/05/17 10:54 , Julien Meuric wrote:
>>> 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...
>>>
>>> Regards,
>>>
>>> Julien
>>>
>>>
>>> May. 23, 2017 - acee@cisco.com:
>>>> The WG adoption poll has concluded and there is overwhelming  support
>>>> for this document.
>>>>
>>>> Additionally,
>>>> https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-01.txt
>>>> 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 <ospf-bounces@ietf.org <mailto:ospf-bounces@ietf.org>> on
>>>> behalf of Acee Lindem <acee@cisco.com <mailto:acee@cisco.com>>
>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>> .
>>>
>>
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>
> --
> logo Orange <http://www.orange.com>
>
> Olivier Dugeon
> Senior research engineer in QoS and network control
> Open Source Referent
> Orange/IMT/OLN/WTC/IEE/OPEN
>
> fixe : +33 2 96 07 28 80
> mobile : +33 6 82 90 37 85
> olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>
>