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

[prz <[e-mail]>]

Acee, ack. Looking forward to the backwards compatibility section &
document version.  

We have here NOT a "one implementation considers"
problem. We have a problem of standards track published documents that
are either unclear or have been deployed as intended and now suggestions
of more documents that have a good chance to contradict the published
standards or make impossible to adhere to all published standards. I
don't have to point out that the word "standard" looses any meaning in
such a case without proper consideration sections, errata or proper
"updates" or "obsoletes" track procedures ...  

thanks  

--- tony 


On Mon, 8 May 2017 14:19:06 +0000, "Acee Lindem (acee)"  wrote: 


From: prz 
Date: Monday, May 8, 2017 at 12:16 AM
To: prz 
Cc: Acee
Lindem , OSPF WG List 
Subject: Re: [OSPF] WG Adoption Poll for "OSPF
LLS Extensions for Local Interface ID Advertisement" 

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.      
The application
we are talking about here is neighbor interface ID discovery and what
Shraddha has, in fact, suggested is link-local flooding scope. Many see
usage of TE Opaque LSAs for non-TE purposes as repurposing while one
implementation sees it as a deployed standard. I think we have discussed
to the point of impasse and further discussion is circular and would
only impede WG progress. The OSPF LLS Interface ID draft will address
backward compatibility.  

Thanks, 
Acee 

--- 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] [11]] 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]
[14] mailto:[e-mail]
[15]
mailto:[e-mail]
[16] mailto:[e-mail]
[17]
mailto:[e-mail]
[18] mailto:[e-mail]