Hi Tony,
please see inline:
On 10/05/17 17:57 , prz wrote:
On Tue, 09 May 2017 12:54:08 +0200, Peter Psenak <[email protected]> wrote:
Hi Tony,
let me try to clarify.
1. This draft does not change, nor does it conflict with RFC3630 in
any way.
Peter, my bad, I got confused forgetting that the Link ID in 3630 is a
different beast from the 4203 link ID. Thanks for pointing that out.
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.
Discussion ongoing ... Your question about 4203 deployment is valid and
needs answers and yes, we need a backward compatibility section explaining
a) @ which OSPF hello states the new signaling is supposed to be present
all hellos, will clarify that in the draft
b) what happens if the value ever changes (tear down adjacency?) or whether
it's a violation
no need to tear down the adjacency. Just update anything that uses the
link ID.
c) what happens if flooded 4203 values (on LSAs) contradict signaling
(e.g. you're holding to the flooded LSA with "old" value) while
neighbor LLS'es a new value
we must set some preference, e.g. LLS value is always preferred.
d) what happens if both signaling types show up on the link
if they are signaling the same value, there is no problem. If values are
different, we prefer LLS.
Per earlier mails, clarification WHEN the new signaling is supposed to
be used
would be also helpful. 4203 Link ID signaling seems to be used only in
case of unnumbered.
any link, will clarify that in the draft.
So, overall I think we agree on scope of the problem that needs to be
addressed so we get a coherent set of standards out
so would you agree to make this a WG document?
thanks,
Peter
thanks
--- tony
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
