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

["Acee Lindem (acee)" <[e-mail]>]

On 9/6/14, 10:47 AM, "A. Przygienda" <[e-mail]> wrote:

>
>>>>>
>>>>> 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.

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.




>>>
>>>
>>>>
>>>>
>>>>>        * 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)

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.

Thanks,
Acee 




>
>
>Waiting for new version
>
>-- -tony
>
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf