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

[prz <[e-mail]>]

 On Tue, 09 May 2017 12:54:08 +0200, Peter Psenak <[e-mail]> 
 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
 b) what happens if the value ever changes (tear down adjacency?) or 
 whether
    it's a violation
 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
 d) what happens if both signaling types show up on the link

 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.

 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

 thanks

 --- tony