Julien,
On 24/05/17 12:08 , Julien Meuric wrote:
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 - 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.
my point is that if people were implementing this, they would figure the
missing IANA allocations.
regards,
Peter
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
