Hi Tony,
your thoughts, if I understand you correctly, is to propagate some
universally understood handling information in the header of each TLV.
So far in OSPF intention (and to large extent - the practice) was to
verify ability of routers to understand the information in LSAs via
option bits in LLS/RI LSA (and for older features - in option bits in
LSAs and packets).
BGP, which you gave as an example of protocol with per-TLV handling
information, is p2p protocol with ability to filter and modify
information per-session and per-prefix.
OSPF, being link-state protocol, should always remember that all
routers in the area share LSDB view. Verifying feature support per-TLV
is not scalable, mechanism of per-router bits works better.
So in your "routing on Sundays" example, author of the feature has a
choice of:
- Do not compute "routing on Sundays" until all routers in the scope
support it
- Define "routing on Sundays" computation algorithm to avoid routers not
supporting it
- etc. etc.
This is all possible and doesn't require per-TLV handling bits.
Anton
On 11/10/2013 11:48 PM, A. Przygienda wrote:
On 11/10/2013 08:12 PM, David Lamparter wrote:
On Sun, Nov 10, 2013 at 12:55:00PM +0100, A. Przygienda wrote:
Thinking further, maybe in the type of TLV encoding it would be good to
think about having a 'mandatory/transitory/optional' bit in terms of use
by routers (kind of ripping off the BGP'ish and other TLV encodings).
Just food for thought here when starting to think about e.g. aggregation
of TLVs over prefixes and so on.
I suggested that a while ago, and in the end it was dismantled because
there was no real use case that didn't fall apart. If you can come up
with a good design and something close to a realistic scenario where
this is used...
Hey David, well, searched the archives & found it. Remember even having
read it & actually seems
I commented on it from a different angle. It was more of
the 'ignore/strong unreachable' type & that's why my brain slipped the
connection.
So let me ask the question again from yet a different angle and verify
some assumptions I'm making
not having been to OSPF WGs recently:
The way I see this draft, it's immediate
purpose is to get today some 'carrier encoding' for things like Seg-Routing
& Src-Dst routing without the necessity of tons of new LSA types, more
flexibility than
the usual rather clunky
add-a-options-bit-add-something-to-an-LSA-grab-a-cap-bit or having
to link lots of info between LSAs and stuff-stuffed-in-opaques.
If this is the *only*reason, then further discussion I start here makes
no sense, no new TLVs can
ever influence core behavior such as SPF/summaries/flooding and at first
glance, the whole thing could have been
done using Opaque LSAs just like the optional-router-caps and this draft
is a redundant,
somewhat more elegant encoding.
But reading and thinking about it, I see further potential to glue
new TLV "things" easily (and more elegantly than opaques)
to 'links' and 'interfaces' and 'routers'. In short, it could help to
move OSPF more into an
TLV-type-encoded protocol format rather than a fixed-format used today
(to largest extent). Think
OSPFv3.5 ;-) where the extended-LSA is THE LSA format.
As we know, TLVs are a sharp stick, they allow to extend the protocol
easily and quite elegantly
but they can poke you in the eye as well. Overall, they are where things
go since the
strongest traditional reasons for fixed encodings such as
4-bytes-aligned MMU C structures
;-) are things of the past given the raw amounts of power & CPU
available & the popularity
of IGPs as loosely-synchronized-network-databases ;-)
vs. the old times of well-understood one-purpose mechanism to get
reachability @ L3 within AD.
So, assuming you all have in mind coming glorious days of OSPFv3.5,
people would use it of course to do things like adding new TLVs that
will influence
SPF behavior, interface types, prefix reachabilities and so on. Now, how
to keep this beast
in check and that's where my observations were going.
In crux the question would be then, how is the draft supposed to keep
compatibility with 'newer' versions of this encoding
when new TLVs are being introduced and suggested and start to influence
things. Well, people who
have been in the game for longish time tend to think about this stuff in
terms of
mandatory/transitory/summarizing properties of data/TLVs and it is a
rathole but one that
always opens in these situations.
So I follow this kind of thinking a tad down the road to clarify the
scope of the extended-lsa-draft
here as of how far this draft is supposed to
reach [ If that thinking is tad cross to usual OSPF-hat-on-design, an
optional
way of thinking about this protocol architecture issue
would be to 'add-another-options-bit' for every TLV that is introduced
and influences
SPF/redist/summaries. This is nothing else but a 'mandatory' bit on some
new TLV. You may run out of bits quickly though ;-) ]
Hypothetical examples to justify all this rambling (I try to keep things
simple as first examples):
1. someone adds a 'I-can-only-route-traffic-on-sundays' TLV: this would
be manadatory, that means any router not understanding this TLV
would have to not compute through this router. Everything would go
well until sunday when a router upstream understanding the TLV would
send you traffic to carry through to a router downstreamnot
understanding the TLV and then it would loop. Logical conclusion:
you don't understand mandatory, get out of next-hop SPF or otherwise
you end up in the multi-topo cornerwith multiple SPFs.
2. someone adds a 'only-generate-type-5-from-this-type-3-on-sundays':
as you see, you'd have to get out the redistribution/summarization
if you have a mandatory TLV like this. That leads
into'transitory/summarizing' type of bits but those are difficult to
get right (we can take the discussion further from here butI never
saw them 'gotten right'). Logical conclusion. You don't understand
the mandatory prefix TLV, leave the area (since you havedifferent
reachability assumptions than other routers understanding the TLV).
3. Someone adds 'I-have-disjoint-path-computation-property' TLV which
would be non-mandatory fornormal SPF but mandatory for a
source-destination-disjoint-path-SPF. So, people can do SPF overit
as normal but someone running disjoint-path-source-dest-SPF reads
the internal mandatory flagfor it & computes the path omitting the
link (should be obvious that in source-dest type of SPFs you can mix
routers understanding a mandatory TLV with some that don't contrary
to next-hop SPFs).
To summarize:
* As authors, ask yourself the intellectually honest question whether
this encoding is ONLY for thingsthat will never touch
SPF/redist/summarization/prefix reachability. If answer is YES, then
state forcefully in the draft that this is NOT a
new-OSPF-TLV-encoding but more elegant way to do opaques and nothing
else.
* If answer is NO and this goes into direction of OSPFv3.5 with TLV
encodings:
* think about reserving two or three bits in type (or length, 14
bits still give you 8K TLVs with sub-TLVs)along the
mandatory/transitive line of thinking and start to work out what
happens when a router does not understand mandatory/transitory.
Section 12.1 is then largely unnecessary but instead maybe a new
section is in order. Not only get-in-get-out behavior needs to
be precisely specified (but also things like multiple copies of
same TLV, misformatted TLVs, missing required TLVs, sequence of
TLVs, TLV type spaces and so on). This sounds excessive but it
isn't given the fact that this encoding would be a very deep
foundation for many years to come (and well, I'd help to write
it ;-)
So, I hope I'm contributing here to clarification of purpose rather than
stultifying ;-)
thanks
--- tony
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
