Hi Tony,
please see inline:
On 9/4/14 21:02 , A. Przygienda wrote:
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.
ok, we will add a text to make it clear.
"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.
ok, we will add a text to clarify.
.,..
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.
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, 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 ?
ok, we will add a tiebreaker there.
thanks,
Peter
--- tony
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
.
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
