Hi Julien,
On 5/24/17, 6:08 AM, "OSPF on behalf of Julien Meuric" <ospf-boun...@ietf.org on behalf of julien.meu...@orange.com> wrote: >Hi Peter, > >Please be aware that my comment applies beyond the scope of this single >I-D. I’m glad you are not trying to obstruct this simple ID that aligns OSPFv2 with OSPFv3 and IS-IS for interface ID discovery. > >Talking about this one, see [JM] below. The discussions are ongoing with respect to TE reuse and we are taking the path we agree to in Chicago with respect to application specific attributes. Backward compatibility will, no doubt, play a significant role in these discussions. Thanks, Acee > >Thanks, > >Julien > > >May. 24, 2017 - ppse...@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 - a...@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-boun...@ietf.org <mailto:ospf-boun...@ietf.org>> on >>>> behalf of Acee Lindem <a...@cisco.com <mailto:a...@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 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
