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

Peter Psenak <ppsenak@cisco.com> Wed, 24 May 2017 13:02 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 2EC53129B0D for <ospf@ietfa.amsl.com>; Wed, 24 May 2017 06:02:27 -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 bFVKgUhq8Jsx for <ospf@ietfa.amsl.com>; Wed, 24 May 2017 06:02:20 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E136D129AE5 for <ospf@ietf.org>; Wed, 24 May 2017 06:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6187; q=dns/txt; s=iport; t=1495630940; x=1496840540; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=E0aLPEKraRn71CzBAnjhXXaOdROKkNjdpfjVO5g5/Pc=; b=V/YUhrtwIeds2T/li77ioyg38FToBE3PZt3ZEDvt7dfLqVvg6sdkWBLd RhxgKzU2gbY51zDfYBsKOWNSUvoSgg9fa1zzBuwBZebHsaopUZMtCjUKa uMONIn57NczuPVi5Q+yTTp/zViRpZPF3ZJ8jVyrL7hoZwhiE8bYrhbRv3 M=;
X-IronPort-AV: E=Sophos;i="5.38,386,1491264000"; d="scan'208";a="653084875"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2017 13:02:18 +0000
Received: from [10.147.24.31] ([10.147.24.31]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4OD2Gt3000697; Wed, 24 May 2017 13:02:17 GMT
Message-ID: <59258458.4060500@cisco.com>
Date: Wed, 24 May 2017 15:02:16 +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> <59256DFD.1020107@cisco.com> <acb4f197-5f5f-5f7c-b09b-91e58fa07c89@orange.com>
In-Reply-To: <acb4f197-5f5f-5f7c-b09b-91e58fa07c89@orange.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/ld9rpMNlI4m2DirucqTG1myUVgg>
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 13:02:27 -0000

Olivier,

On 24/05/17 14:46 , Olivier Dugeon wrote:
> Peter,
>
>
> Le 24/05/2017 à 13:26, Peter Psenak a écrit :
>> 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.
> Yes I know. It is just a proposal. IMHO, it is sometimes preferable and
> smoother to just allocate new code point / bit mask to an existing RFC
> instead of adding a new RFC.
>
> In the particular case of RFC4203, like Julien mention, it just require
> a IANA allocation that has not been performed when the RFC was
> published. Sending an opaque LSA (disregarding its flooding scope)
> remains a simple operation once the opaque LSA framework is in place.
>  From a code perspective, I agree that it is simple to add Link Local to
> Hello Message compared to sending an opaque LSA. But, this impose the
> support of Link Local Signalling. I'm curious to know if some commercial
> implementation support LLS and not TE and reciprocally. From my
> knowledge, Quagga, and thus FRrouting, have no support for LLS, but have
> support for TE.

LLS is a standardized mechanism used for exchanging arbitrary data on a 
link, used by many standards and independent of TE. We are proposing 
this simple mechanism to be used to exchange interface ID, making parity 
with other protocols like OSPFv3 and ISIS.

Maybe time for Quagga/FRrouting to add support for LLS.

thanks,
Peter


>
> Regards
>
> Olivier
>>
>> 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>
>>>
>>
>
> --
> 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>
>