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

[Olivier Dugeon <[e-mail]>]

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. 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 - [e-mail]:
>>> 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 <[e-mail] <mailto:[e-mail]>> on
>>> behalf of Acee Lindem <[e-mail] <mailto:[e-mail]>>
>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
>> .
>>
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> 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 : [phone]
mobile : [phone]
[e-mail] <mailto:[e-mail]>