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

[prz <[e-mail]>]

I try to parse that and am still not clear what you both are saying


1. It seems you both saying that RFC3630 is expected now to be used on
unnumbered only (for which I find no indication) or are you claiming
it's only used that way? Based on which implementation or document? What
is "repurposing"? RFC3630 is a published Standards track RFC and I don't
know what "re-purposing" standards RFCs means?  

2. Or are you saying
that the new draft will be restricted to unnumbered only? In which case
I expect a new version of draft to discuss further and agree taht the
backwards compat section colllapses to "unnumbered link" considerations
only ...  

? 

--- tony  

On Sat, 6 May 2017 18:15:21 +0000, "Les
Ginsberg (ginsberg)"  wrote:  

Tony - 

It is known that link
identifiers are useful even in cases of numbered links e.g. some
telemetry applications prefer to use link identifiers to identify all
links (numbered and unnumbered). 

So I share Acee's expectations. 


Les 

FROM: OSPF [mailto:[e-mail]] ON BEHALF OF Acee Lindem
(acee)
SENT: Saturday, May 06, 2017 10:04 AM
TO: prz
CC: OSPF WG
List
SUBJECT: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for
Local Interface ID Advertisement"   

Hi Tony,   

I'll have to discuss
with the authors - but my impression is that this would not be limited
to unnumbered links. My understanding is that the repurposing of
link-local OSPF TE LSAs is only done on unnumbered links so that would
be the main focus of the backward compatibility discussion.   

Thanks, 


Acee  

FROM: prz 
DATE: Saturday, May 6, 2017 at 12:58 PM
TO: Acee
Lindem 
CC: OSPF WG List 
SUBJECT: Re: [OSPF] WG Adoption Poll for "OSPF
LLS Extensions for Local Interface ID Advertisement"  

Hey Acee,  

1.
looking fwd to read the revision with backwards compatibility section
and definition which Hello FSM states the extension applies to 

2. I
try to read what you say carefully but please clarify: there's nothing
in rfc5613 that prevents LLC on any link so do you mean, you suggest to
use this TLV on unnumbered links _only_? Or do you suggest that RFC3630
implies somehow that LS TE LSAs are used on unnumbered links _only_? If
so, I don't see anything in the RFC to this effect ...  

--- tony  

On
Fri, 5 May 2017 15:14:30 +0000, "Acee Lindem (acee)"  wrote:  

Hi Tony,
 

The authors will cover this in the next revision. Based on
discussions, the usage of link-scoped TE LSAs is limited to unnumbered
point-to-point links. If this is the case, the backward compatibility is
much simpler than the other discussions we've been having.   

Thanks, 


Acee   

FROM: prz 
DATE: Friday, May 5, 2017 at 11:09 AM
TO: Acee
Lindem 
CC: OSPF WG List 
SUBJECT: Re: [OSPF] WG Adoption Poll for "OSPF
LLS Extensions for Local Interface ID Advertisement"   

Not sure it
made it from my other address so rtx to the list ...  

A conditional
against here ...  

I am fine with adoption if I see a version that
spells the detailed behavior and especially interactions between RFC4302
and this draft in a detailed section, i.e. both on, RFC4302 gets
configured/unconfigured, are the LLS extensions advertised on every
hello or just until a specific state (like ISIS padding thingies) and so
on ...   

I'd rather have this now than a LC discussion ...   

The
idea is deceptively simple but it is a redundant mechanism and those
always end causing inter-op problems unless cleanly spelled out ...  


--- tony   

 

Links:
------
[1] mailto:[e-mail]
[2]
mailto:[e-mail]
[3] mailto:[e-mail]
[4]
mailto:[e-mail]
[5] mailto:[e-mail]
[6]
mailto:[e-mail]
[7] mailto:[e-mail]