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

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

>>>>
>>>> It's also wise to add 'if the same extended prefix TLV (i.e. for same
>>>> prefix) is seen twice in same opaque LSA only use the first and force
>>>> people to put all sub-tlvs into a single tlv.
>>>
>>> it's kind of obvious, but we can add a text to be sure.
>>
>> As I see it, the purpose of an RFC is to assure interoperability. If
>> there are two
>> interpretations available of the same packet that will make two
>> solutions not interoperable,
>> the standard has to mandate the correct one.
>
> ok, we will add a text to make it clear.
ack
>
>>
>>> because existing LSA are not extensible, any additional link/prefix
>>> attributes must be advertised in a separate LSAs. We called it
>>> "extended", but it does not mean that existence of the extended LSA
>>> require existence of the base LSA. I had a text in the original SR
>>> draft around that, we can add it here too.
>>
>> yepp, once it spelled out, it's obvious but the first conclusion one
>> jumps to is that they are inter-dependent otherwise.
>
> ok, we will add a text to clarify.
ack
>
>>>> Acee, you mean remove the restriction ?  I see how some
>>>> implementations
>>>> may benefit from cramming all type-3 into the same opaque but I would
>>>> also suggest to not restrict this and remove the text.
>>>
>>> the restriction can not be removed. All the Extended Prefix TLVs that
>>> you put in a singe Extended Prefix LSA will only use a flooding scope
>>> of the Extended LSA itself.
>>
>> I still think it's not clear what the original paragraph means.
>
> 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.
>>
>>
>>>
>>>
>>>>        * what happens if the same extended prefix TLV shows up
>>>> twice in
>>>> two different opaques of same type ?  You use the one that is in lower
>>>> opaque ID ?
>>>
>>> I would call it a bug on the originator side.
>>
>> yes, but still, the draft should mandate what the desired behavior is @
>> this point in time otherwise some will use the lower ID, some higher and
>> some none of the above & the implementations will not interop ?
>
> ok, we will add a tiebreaker there.
ack

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)


Waiting for new version

-- -tony