Hi Tony,
please see inline:
On 9/3/14 18:13 , A. Przygienda wrote:
Hey Acee,
b) section 2.
It may be well writing a sentence or two what should happen if an OSPFv2
Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11
changes) and what should happen if the same prefix appears in two
different flooding scopes with different information (ignore prefix in
both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it
open may lead to different treatement per router and surprising effects
as far as the information in the two LSAs are the same, having the prefix in
two LSAs with different flooding scopes is not a problem - happens today with
regular LSAs.) The problem would be if the content of TLVs associated with the
prefix is controversial, in which case it would be a defect on the originator
side.
This is another case where the segment routing mapping server requirement makes
this more complicated. I think the guidance for the case should be to give
preference to the information in the LSA with area flooding scope.
agree. preferring area (or in extreme case link scope ?) is simplest
resolution of the issue. Agree with Acee here.
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.
It may be also helpful to add that if an opaque extended is present but
the prefix (of the according type) is not in the standard LSAs, such
information must be disregarded.
no, that is a valid case. One may want to advertise some extended prefix
attributes without advertising the prefix's reachability.
Here I think the draft may benefit from some clearer writing. Even an
experienced OSPF reader is lead to assume that original LSA must be
present to use the extended.
"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.
On top, if you start to advertise opaques & people start to compute
reachability or distance based on opaques (unless you specificall state
in this draft that it _cannot_ be used for that purpose, i.e. opaque
influences reachability or computed metric) and you can have routers in
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.
c) section 2.1
Multiple OSPF Extended Prefix
TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but
all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA
MUST have the same flooding scope.
may be misleading. Since they are in a opaque, the flooding scope is
controlled by opaque. If the type-5 vs. type-3 is meant than 'flooding
scope' must be disassociated between 'opaque flooidng scope' and
'route-type flooding scope [as in we don't flood type-1 across ABRs]' ?
LSA can only have single flooding scope, so all information inside LSA is
limited to that flooding scope. That is what was meant by the above texts.
Actually, I had considered removing this statement when I separated the generic
protocol extensions from the SR specific 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.
d)
I think it may be a valid suggestion to implementors that (for every
version) the according LSA SHOULD be flooded _before_ the opaque LSA
is flooded (which can be tad tricky [but doable] if the opaque carries a
bunch of those]). Yes, with reordering of flooding etc. it's not a
guarantee for anything but a good practice to give the protocol a chance
to distribute the referent (LSA) before distributing any references
(opaques) and additionally, will make sure that LSAs which are far more
important normally get out the box before opaques.
as I said, not flooding regular LSA, only extended LSA is a valid case.
In any case, an application using extended attributes will need to be triggered
by the extended prefix/link attribute LSAs. The advertising router may
originate one or both of them independently. I will try to capture this
disjointness in a paragraph.
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.
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.
* 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.
thanks,
Peter
All nit-picking based on ample scar tissue with TLV based protocols in
real deployments.
thanks
--- tony
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
