[OSPF] Some comments on draft-ietf-ospf-transport-instance

["Osborne, Eric" <[e-mail]>]

This draft came up in the discussion of the OSPF flowspec stuff, so I figured I'd read it.  Some comments:

Overall it makes sense - I see what it's trying to do and how it does it.  I think there are some areas that need fleshing out, though.

1)
section 2.3 lists two methods, ships in the night or child instance.  Section 2.3.1 covers SIN in more detail, but I was expecting 2.3.2 to talk about child instances.  Is that what "Tighter Coupling with Normal OSPF Instances" is supposed to cover?  At a minimum the subsection title should match up, and whatever section is supposed to cover child instances should talk about it more detail.  Is that ultimately planned for this draft, or does 'future study' mean some other document?

2)
I assume the 'flash precedence' thing is as much tongue-in-cheek as it is anything else.  In reality it needs to be configurable; I might want to put something in a transport instance that's as important as routing, or I might have already used AF3x for something else entirely.  Should probably say "SHOULD default to Flash and REALLY REALLY SHOULD  be configurable" or something.

3)
for sparse topologies, how do I build them?  Having to hardcode a tree is a non-starter.  Is there some existing OSPF mechanism to build these?  Can you steal something from multicast?  If neither of those is Yes then I think you need more content here.

4)
Section 2.5 needs some massaging.
It currently says
"OSPF routers SHOULD NOT advertise any transport instance LSAs containing IP or IPv6 prefixes"

but what if I want to use multi-instance to do some sort of overlay thingy?  I don't necessarily have a service in mind, but I'd hate to lay down a law that says "you CANNOT use transport instances for any IP prefixes at all ever" and then come back later with a doc that backs that out.  What about "transport instances MUST NOT advertise any routing information which would conflict with the base IP routing instance and SHOULD NOT advertise any routing information without a really good reason"?

Also, "this implies that..." is a little wishy-washy.  The implication isn't obvious to me.  Is the goal to only use transport instances to carry things in opaque LSAs and allow just enough topology information for those opaques to be calculated?  If so, that should be spelled out - maybe you only allow 1/2/5/9/10/11?

5)
2.7.1 should probably be 2.8, as remote neighbors are an option in addition to sparse topologies, not a sub-version of them.
Also, why not reuse virtual links here instead of introducing a separate ability to have targeted neighbors?
And 'Other salient features' makes me think there's much more to targeted neighbors than just the three bullets you have listed.  As much as I'd like to believe that you can get away with a bullet that says 'implementer MUST know what they're doing' and another one that says 'implementer MUST NOT screw this up', you probably need to get into a little more detail for the sake of those to whom the subtleties aren't obvious.


.02




eric