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

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

On 09/04/2014 12:24 AM, Peter Psenak wrote:
> Hi Tony,
>
> please see inline:

Hey Peter, same

>
> On 9/3/14 18:13 , A. Przygienda 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.

>
>>
>> "OSPFv2 requires functional extension beyond what can readily be done
>> with the fixed-format Link State Advertisements (LSAs) as described
>> in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based
>> on Type-Length-Value (TLV) tuples that can be used to associate
>> additional attributes with advertised prefixes or links."
>>
>> That's strongly suggestive of "you advertise normal LSA and then you use
>> opaque to 'extend' it" . Extended extends and is not independent from
>> original stuff in normal use of English idiom.
>
> 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.

>
>
>> .,..
>> the area that do not support opaques, an additional text is needed
>> saying  "never compute through routers without opaques using information
>> in opaques that influences reachability or metrics". Actually, it's
>> worse since if a router without opaques forwards through a router
>> advertising opaques influencing metrics (for sake or simplicity), you
>> cannot start using opaques to keep on forwarding.  In case that all
>> doesn't parse, I can do a simple looping example.
>
> we are not advertising any metrics in the extended LSAs, so I do not
> see why we would have to deal with that case here. If one day someone
> wants to do that, then it would have to be covered in a separate draft
> and we would deal with it at that time.

agreed here. you're correct. That would be overspecification in this draft

>
>> OK, I still don't understand 'WHICH flooding scope', the  type-3 vs.
>> type-5 one or the 'opaque flodding scope one'.  I think you mean 'all
>> prefixes in the same opaque must have the same OSPF-route-type
>> [0+unevens]'  but the text is really hard to parse here.
>>
>> 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.

>
>> yes, and again, I think 'extended' is an ill chosen name maybe if that's
>> the intention of the draft.
>>
>> BTW, what is the plan if all the TLVs blow out the MTU of the opaque ?
>
> you can generate many Extended Prefix or Extended Link LSAs, so there
> is no issue.

ack

>
>> I'm missing something ?   RFC5250 is not describing how the instance
>> (they call it Opaque ID) is supposed to be generated (it references
>> appendix A referencing section 7 which has nothing in it about this).
>> I'm divining the instance allows to have multiple opaques of the same
>> type which leads to bunch interesting discussions
>>       * what happens when the MTU gets blown & TLVs are shifted into
>> next 'fragment' in ISIS speak [with all the restrictions how the TLVs
>> can migrate between fragments, ISIS guys suffered this one [as did PNNI]
>> @ length & will surely lend a helping hand in such a case].
>
> TLVs can come and go and move from one Extended Opaque LSA to the
> other. Implementation needs to track these changes and deal with them.

I would let the ISIS guys chime in here. They have tons experience with
TLVs sliding fragments and what kind of implementation/operation pain
that can cause.

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

--- tony