From: prz <p...@zeta2.ch<mailto:p...@zeta2.ch>>
Date: Sunday, May 7, 2017 at 3:47 PM
To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>
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)" 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> 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:ospf-boun...@ietf.org] 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 <p...@zeta2.ch<mailto:p...@zeta2.ch>>
Date: Saturday, May 6, 2017 at 12:58 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
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)" 
<a...@cisco.com<mailto:a...@cisco.com>> 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 <p...@zeta2.ch<mailto:p...@zeta2.ch>>
Date: Friday, May 5, 2017 at 11:09 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
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




_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to