Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt

["A. Przygienda" <[e-mail]>]

>>> prefixes can have different flooding scope. Today intra-area and
>>> inter-area prefixes have area flooding scope and external prefixes
>>> have domain wide flooding scope. You can not mix prefixes of different
>>> flooding scope in a single Extended Prefix LSA, because Extended
>>> Prefix LSA can only have a single flooding scope.
>>>
>> yes, this is now clearly spelled out.  I suggest adding that to the
>> draft with a MUST NOT and addition that if they are, the behavior of the
>> protocol is unspecified/incorrect.
> I guess I still see this is a tautology since the LSA type defines the
> flooding scope that need not be in the draft. If you advertise a prefix in
> an LSA with a given flooding scope, then by definition, the prefix is
> advertised at the flooding scope of that LSA. Let me try and reword this
> so that it reflects the required flooding scope for the prefix.

yes, you can see it like that, i.e. if the  flodding scopes are strictly
linked to each other, then the
text should be

    advertise  LSA-1,.. @ area scope
    advertise LSA-5,.. @ domain scope

Any LSA-1 in domain scope MUST be disregarded & so on.

That makes it tight, clean and easy to understand. I'm with you here.

>
>
> All my issues have been adressed then except concerns about the 'any
> prefix in any opaque'. Let me explain.
>
> Let's say I have an extended prefix X providing service X'.  The prefix
> is advertised in opaque O_1.
> If I remove it from O_1 and move it to O_2 (due to running out of space,
> weak implemenation and so on)
> but O_1 is flooded out there before people pick up O_2, service X' will
> be interrupted.
>
> This sounds not too bad but imagine you advertise 50 new prefixes that
> slide 50 prefixes from the original
> O_1.  Same for deletions. Now your protocol becomes quite fragile (if
> interested further,
> look @ ISIS treatement of that problem)
> OSPFv3 has this situation today as well for Router-LSA links - in this
> case, implementations will reoriginate all the changed Router-LSAs at
> ³nearly" the same time and, more often than not, the changed LSAs are
> processed by other OSPFv3 Routers in the same SPF cycle. This is an
> implementation issue and the protocol itself need not try and guarantee
> seamless transition. However, I will think about how to add some guidance.
> One of the many advantages of OSPF over ISIS is that OSPF allows for
> intelligent grouping of information in separate LSAs to avoid the inherent
> problems with regeneration of LSPs.
>

Yes, I agree with the grouping but the same type of information can
still blow out an opaque (as here) and then
some, as you say, implementation guidance is, albeit not strictly
protocol specification, beneficial to have
higher quality implementations out there (which for OSPF, with lots of
people @ different clue level
implementing it, is probably more important even than for ISIS).

Yes, it's largely matter of judgement so I'm just lighting out the
complete landscape to get a draft of max quality out & don't feel
strongly either way about this one.

--- tony