Hi Tony,
let me try to clarify.
1. This draft does not change, nor does it conflict with RFC3630 in any way.
2. This draft does not change anything in RFC4203 either. It provides an
alternative and more generic way to exchange Link Local Identifier on
the interface. Your are right that in our draft we need to specify the
behavior in case the mechanism described in RFC4203 AND the new
mechanism specified in our draft are both active at the same time. We
will add a new section in a next version that covers this part. I don't
believe it will be too difficult, given that the value of the Link Local
Identifier is the same same in both cases, the only difference is the
the mechanism how it is advertised.
Hopes this helps and moves us forward.
thanks,
Peter
On 08/05/17 06:01 , 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)" <a...@cisco.com>
wrote:
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
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
