[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
San Diego OSPF WG Meeting Minutes
The minutes are attached. Thanks to Bill Fenner for taking them.
------
Acee
IETF 60 OSPF WG Minutes
Bill Fenner (Scribe)
Acee Lindem (Some Editing)
Refer to the slide prsentations in conjunction with these
minutes.
Document Status:
- Graceful Restart (RFC 3623) published
- Already some ideas on having it less strict about exiting restart but
maintaining the same functionality.
- Flooding Reduction in Stable Topologies
- Has a minor comment pending that should be able to be handled with
an rfc-editor note
OSPF Wireless Design Team:
Tom Henderson: Everyone's waiting for someone else to step forward -
what are the expectations wrt deadliens and organization?
Acee: We should have someone leading it - not me because of my interests
and job responsibilities. first thing should be requirements +
problem statement, then there are a lot of ways to handle the problems
that are stated. Common thread of all solutions is flooding reduction.
Tom: Of the people in the room today, maybe let's meet to discuss next
steps.
Rohit: This was discussed - had a plan for how this was going to proceed
and what the deliverables would be - formalize that and that'll be the
design team charter.
Note: Change from web agenda: Manet considerations ahead of Manet extensions.
Design considerations for Wireless OSPF interface - Tom Henderson (Boeing)
draft-spagnolo-manet-ospf-design
Summary: - Analysis of overhead; LSU flooding and Ack is dominant
ways to characterize simulations independent of specifics to be able
to compare different simulations
- Presents some results on the improvements of reliable flooding
optimizations.
- More results on unreliable flooding
- LSU flooding is dominant contributor; can reliable optimizations
do better than 50%?
- Unreliable flooding can provide up to 10x reduction without
sacrificing performance (large # of external LSAs are a problem)
database exchange optimization may also be important in a frequently
partitioning network.
- List possible future work:
* Flooding algorithm?
* DB sync optimizations?
* Differential encoding?
* Limit adjacencies?
Tom: Of the people in the room today, maybe let's meet to discuss next
steps.
Joe Macker: When you did packet delivery ratios, was it under congested
or was loss just from mobility?
Tom: Just mobility.
Joe: Was this the draft that had the different 2026 boilerplate?
Tom: this one was different; we picked it based on our intention to provide
information to the design team
Joe: would it be a problem if the design team picked up stuff from here?
Tom: No
Acee: Do you intend to keep with this future work? Should we publish this
as informational as a historical record?
Tom: We do intend to keep going down these paths, discuss with design team
to decide next steps
Acee: It's a good piece of work, it may be nice to preserve it.
Sue Hares: In the paramaterization, you have neighbor change rate,
but the draft seems to have a fixed 20 neighbors; is there a reason
for this? Other simulations picked different values.
Tom: We picked 20 as a representative number; we've done up to ~100;
for a lot of these it was faster to look at different scenarios doing
smaller # of nodes; have other work that shows some of the scaling
performance as you increase the number of nodes. There's nothing
magical about 20. For completeness, maybe we could do more.
Sue: Did you go higher than 100?
Tom: no
Sue: That's number of nodes in the network, right?
Tom: Yes.
Sue: Why not use link up/down seperately from neighbors up/down?
Sue: Some of the larger numbers you might see a different dominant factor
Rohit: Let's have this discussion on the list.
OSPF Wireless Interface Extensions - Russ White (Cisco)
draft-chandra-ospf-manet-ext.txt
Russ: Hello may not be a place of huge overhead, but it does pass
info that may not be needed to all neighbors; looking at
incremental state. Use state sequence #'s to describe current
state.
Joe: Optimized flooding is something we've been doing for years
in manet; are you borrowing?
Russ: Yes, this is very similar to OLSR, slightly different
overlapping relay set.
Acee: Hybrid p2mp but meshed funny.
Russ: Yes, it's a single subnet.
Acee: It's on one interface, but it's just who you relay to.
Russ: Yes. Our assumption is that the device is going to have one
"air" interface. Even if there are multiple interfaces, they're
all going to work the same way.
Alex: With optimized flooding: how do you ensure reliability?
Russ: You're still acking, and if you've suppressed your flood but you
haven't heard an ack for a little longer than normal then you
reflood.
Alex: What if you don't have connectivity to the guy you want to hear an
ack from?
Russ: You wouldn't reflood, since you've lost connectivity.
Alex: Worried whether it's provably reliable.
Russ: I think so.
Acee: If the hello overhead is < 2%, why would we want to mess with it?
Russ: We may not want to; we don't know what the real overhead is.
if it's so low that it's not worth it then we won't do it.
Sue: On slide 6, C doesn't *stop* flooding; he just floods slower?
How does C know that B has flooded?
Russ: He is on the same broadcast medium, and he will see E's ACK to the
packet that it got from B.
Sue: If B goes away, will C ever speed up?
Russ: As soon as B drops his relationship with E, the hello stuff will
catch up; A will learn that B can't reach E so will tell C t
to flood.
Sue: Timing there is critical.
Russ: Alvaro, did our simulation cover that? I don't think we know these
numbers.
Alvaro: I don't know. We look at the router-LSA, not hellos, so it's
convergence time, not hello cycle.
Tom: For hellos, is it true that there are 2 aspects changed: differential
hellos but also overlaying the relay set selection on hello messages.
Russ: Yes. You can do relay set selection on type1s but you've already
flooded by that point so you don't save anything in the initial
flood.
Rohit: This applies equally to tom - purely for the MANET side, how many
nodes do you expect to see?
Russ: 40-1000.
Joe: You can have a channel in an urban environment that fluctuates
quickly, you may want some hysteresis to keep links like this from
going away.
Russ: Yes, we should consider this.
Joe: We should talk about this on the design team; it can be disasterous
to lose links briefly like this.
Uoe: Is there a time the design team can meet? Possible interim meeting?
Acee: Russ can sponsor one in RTP :^)!
OSPFv3 Authentication Issues/Resolution - Suresh Melam (Nokia)
draft-ietf-ospf-ospfv3-auth-04.txt
Suresh: Will update draft based on lunchtime discussion with SEC & RTG ADs.
An SA per instance is impossible to validate - any instance could use
any valid SA, so one SA per link.
Should we new/old IPsec drafts?
Bill: Should use new because of multicast and replay protection advances.
Acee: Problem with instance ids are bad on multi instances: you can use
multiple SAs?
Bill: But that won't protect SAs from each other.
Mukesh: Plus you can't have some instances doing security and some not.
Unknown: IPsec can't pick the right SA on outbound with multiple instance on the
same interface.
Acee: And we thought this was going to be easy!
Multi-topology routing for OSPFv2 - Peter Psenak (Cisco)
draft-psenak-MT-OSPF-00.txt
Peter: Reuse 1583-style TOS LSAs for multi-topology use.
Unknown: How does the routing table look?
Peter: Depends on implementation; you can have different table per topology
or all in one table.
Unknown: Sounds a lot like why you go to MPLS in the first place.
Acee: The alternative is multiple instances; that's more intensive with
memory and processing power. I don't think those are issues with
today's networking equipment.
Alex: On routing tables: I know why you don't want to say why
routing tables are stored. We need to worry about
interoperability. If one does one thing and one does another
they may not interoperate.
Peter: Why? Route lookup should be the same no matter what your data
structures. Looking in one table should be the same as looking in
multiple tables.
Acee: First issue is do we want to do this in OSPF?
Alex: Another question is what about forwarding? Do we want standard way
for routers to interoperate in forwarding plane?
Tom henderson: Supports this becoming a WG document. We did something
similar to this and found it useful to do this kind of thing without
deploying a full-blown TE solution.
Acee: No real opposition, some support, take it to the OSPF WG list to
move forward.
Padma: There are definitely ISIS multi-topology deployments.
Route Attribute Opaque LSA - Acee Lindem (Redback)
draft-lindem-ospf-route-attr-00.txt
Unknown: Could you clarify - s this just for the next-hop or is it general?
Acee: It could be general for other applications as well.
Padma: For NSSA, the ABRs need to translate - what if you have several ABRs
translating the same type 7 LSA?
Acee: Hopefully both would be doing the same translation since they're
using the same rules to select the route. If it's a multipath,
it's the concatenation of the attributes.
Padma: So you could have two nexthops?
Acee: Hadn't thought of protection going across an NSSA boundary.
Destination address filter - Acee Lindem
draft-lindem-ospfv3-dest-filter-00.txt
Very short on time - No comments
OSPF IANA Considerations - Kireeti Kompella (Juniper)
draft-kompella-ospf-iana-00.txt
Kireeti: RFC 2328 doesn't have an IANA considerations section; This
document goes through each number space and creates registries for
them - included space for standards, experiments, private. Coming
up with more when other standards bodies are using OSPF for different
purposes. We need more rigor in allocating code points and a
point of control. This is our "take back our protocol" program
(Analogous to "take back the neighborhood").
Acee: Some codepoints you can't allocate without standards action and
remain compatible. For example, there is no protocol handling for
undefined link types in a router LSA.
OSPF TE Capabilities - JP Vasseur (Cisco)
draft-vasseur-ospf-te-caps-00.txt
JP: Twp implementation: routing info LSA & TE info
Acee: More discussion on this draft needed.