Olivier,
On 24/05/17 14:46 , Olivier Dugeon wrote:
Peter,
Le 24/05/2017 à 13:26, Peter Psenak a écrit :
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.
Yes I know. It is just a proposal. IMHO, it is sometimes preferable and
smoother to just allocate new code point / bit mask to an existing RFC
instead of adding a new RFC.
In the particular case of RFC4203, like Julien mention, it just require
a IANA allocation that has not been performed when the RFC was
published. Sending an opaque LSA (disregarding its flooding scope)
remains a simple operation once the opaque LSA framework is in place.
From a code perspective, I agree that it is simple to add Link Local to
Hello Message compared to sending an opaque LSA. But, this impose the
support of Link Local Signalling. I'm curious to know if some commercial
implementation support LLS and not TE and reciprocally. From my
knowledge, Quagga, and thus FRrouting, have no support for LLS, but have
support for TE.
LLS is a standardized mechanism used for exchanging arbitrary data on a
link, used by many standards and independent of TE. We are proposing
this simple mechanism to be used to exchange interface ID, making parity
with other protocols like OSPFv3 and ISIS.
Maybe time for Quagga/FRrouting to add support for LLS.
thanks,
Peter
Regards
Olivier
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 - 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
--
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.dug...@orange.com <mailto:olivier.dug...@orange.com>
--
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.dug...@orange.com <mailto:olivier.dug...@orange.com>
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
