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

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