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

Hi Peter,

Please be aware that my comment applies beyond the scope of this single I-D.

Talking about this one, see [JM] below.

Thanks,

Julien

May. 24, 2017 - ppsenak@cisco.com:
> 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.

[JM] I have seen, but we cannot use an unanswered 2-week poll on the
OSPF list as if it were an RFC deprecating section 3 of RFC 4203.

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

[JM] You are right: there may be a hole in IANA's registry, probably
missed during publication process. But the RFC is clear: "The only TLV
defined here is the Link Local Identifier TLV, with Type 1". Only the
request for registry creation was missed, which could be very easily fixed.

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