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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 23 May 2017 14:48:40 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Acee Lindem <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 4, 2017 at 2:45 PM
To: OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

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

---

From: Julien Meuric <[email-masked]>
Date: Wed, 24 May 2017 10:54:04 +0200

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 - [email-masked]:
> From: OSPF <[email-masked] <mailto:[email-masked]>> on
> behalf of Acee Lindem <[email-masked] <mailto:[email-masked]>>
>     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 
>
>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 24 May 2017 11:37:01 +0200

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.

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

So at the end we may not even have any duplication at all.

regards,
Peter

On 24/05/17 10:54 , Julien Meuric wrote:
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
> .
>

---

From: Julien Meuric <[email-masked]>
Date: Wed, 24 May 2017 12:08:22 +0200

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

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

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

>>> Additionally,
>>> https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-01.txt
>>> addresses
>>> the comments received the adoption poll.
>>>
>>> Authors,
>>>

---

From: Olivier Dugeon <[email-masked]>
Date: Wed, 24 May 2017 12:19:47 +0200

Hi Peter,

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

-- 
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
[email-masked] <mailto:[email-masked]>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 24 May 2017 13:26:53 +0200

Olivier,

On 24/05/17 12:19 , Olivier Dugeon wrote:
> 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.

thanks,
Peter

> There

---

From: Peter Psenak <[email-masked]>
Date: Wed, 24 May 2017 13:28:15 +0200

Julien,

> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 24 May 2017 12:14:51 +0000

Hi Julien, 

>Please be aware that my comment applies beyond the scope of this single

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

---

From: Olivier Dugeon <[email-masked]>
Date: Wed, 24 May 2017 14:46:05 +0200

Peter,

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

Regards

Olivier

Olivier Dugeon

fixe : +33 2 96 07 28 80

---

From: Peter Psenak <[email-masked]>
Date: Wed, 24 May 2017 15:02:16 +0200

Olivier,

> knowledge, Quagga, and thus FRrouting, have no support for LLS, but have

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