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

[prz <[e-mail]>]

Having thought a bit about it a possible idea is to think whether the
suggested TLV 18 would try to take precedence over sub-TLV 2 in TLV on
RFC3630.  

That has another interesting problem. 3630 does not talk
about scope of the opaque in normative language (Shraddha suggested it's
link local but it looks like she was talking about 4203 in fact) but
3630 allures in Introduction that it's type 10 (area scope) talking
about "flooding rules" which would make the "preference" idea null and
void.  

So IMO we have a really interesting backwards section here with
deployed 4203 and 3630 backwards compatibility considerations.  

---
tony 

On Sun, 07 May 2017 21:01:33 -0700, prz  wrote:  

OK, intention
clear.  

What baffles me: can you specify where the idea of
"repurposing" existing, implemented and deployed standards RFC comes
from? And what does that look like in practice? You intend to publish an
errata? And how will we deal with deployed gear that uses RFC3630 on all
interfaces? And how will traffic engineering metrics be obtained on
interfaces if RFC3630 is "repurposed" to some type of interfaces only?


Or do you expect RFC3630 being advertised without the sub-TLV 2 now on
some kind of interfaces while still using all the others sub-TLVs after
being "repurposed" and all the tooling rewritten to look for the
suggested draft while being backwards compatible without having an
indication what is actually implemented on the combination of both
routers on both sides of an interface?  

Any hack works for a super
special deployment case but that seems to be suggest an orthogonal,
clean standard. Really?  

--- tony  

On Mon, 8 May 2017 00:13:21
+0000, "Acee Lindem (acee)" wrote:  
From: prz 
Date: Sunday, May 7,
2017 at 3:47 PM
To: "Les Ginsberg (ginsberg)" 
Cc: Acee Lindem , OSPF WG
List 
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for
Local Interface ID Advertisement"  

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?      
RFC 3630 is specific to OSPF TE Opaque LSAs
and what I'm saying is that for this specific usage for interface ID
discovery, the repurposing the TE LSAs is limited to unnumbered
interfaces. For the second time, can you confirm???    

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 ...      
Absolutely not - the draft that is under
WG consideration is for general purpose discovery of interface IDs. I
believe this point is clear if you read the draft.  
Thanks, 
Acee   


? 

--- 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] [6]] 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]
[8] mailto:[e-mail]
[9]
mailto:[e-mail]
[10] mailto:[e-mail]
[11]
mailto:[e-mail]
[12] mailto:[e-mail]
[13]
mailto:[e-mail]