Open Shortest Path First WG (ospf) Scribe: Dimitri Papadimitriou Monday, December 3rd from 13:00-15:00 (Salon 3) =============================================== CHAIR(s): Abhay Roy Acee Lindem o) Administriva - 5 minutes - Mailing list: ospf@ietf.org * Subscribe/Unsubscribe: ospf-request@ietf.org with "subscribe" or "unsubscribe" in the body of the message * Archive: http://www.ietf.org/mail-archive/web/ospf/current/index.html - Scribe: Dimitri Papadimitriou - Blue Sheets o) Agenda Bashing - Acee: Observes first full agenda meeting since a long time. ----- o) Document Status - Acee - 15 minutes AD evaluation - Next step IESG: . OSPFv3 Graceful Restart - draft-ietf-ospf-ospfv3-graceful-restart-07.txt (Standards Track) Pretty much ready for IESG, no problem expected, except for security aspects. . OSPF for IPv6 - draft-ietf-ospf-ospfv3-update-18.txt (Standards Track) Has been last called several times - Still will accept input on mapping of precedence to traffic class solicited (in latest version). Ready for ADs. . OSPF Multi-Area Adjacency - draft-ietf-ospf-multi-area-adj-07.txt (Standards Track) WG Finished - Waiting on ADs and Implementations: . Traffic Engineering Extensions to OSPF version 3 - draft-ietf-ospf-ospfv6-traffic-07.txt. Waiting on interoperability (Standards Track). Have requested early allocation of TLV and sub-TLV code points. Need to have proposal completed to have normative ref. since document used in CCAMP. . RFC 2370 Respin, aka OSPFv2 Opaque LSA (Standards Track) - draft-ietf-ospf-rfc2370bis-txt. ADs to evaluate . Database Optimization (Informational) - draft-ietf-ospf-dbex-opt-02.txt. Close to WG Last Call: . OSPF Link-Local Signaling as Standards Track - draft-ietf-ospf-lls-03.txt. WG last call pretty soon. Needed for experimental RFC as MANET documents make use of it. Implementations exist. . Management Information Base (MIB) for OSPFv3 as Standards Track - draft-ietf-ospf-ospfv3-mib-12.txt Revision after Chicago meeting - getting close to WG last call Plan to WG last call shortly after Vancouver OSPF WG meeting. . Support of address families in OSPFv3 - draft-ietf-ospf-af-alt-06.txt. Simple alternative. Boeing implements this on top of Quagga open source Need Better Review/Discussion: . Multi-topology routing in OSPFv3 (MT-OSPFv3) - draft-ietf-ospf-mt-ospfv3-03.txt (Needs work on implementations) . OSPF Version 2 MIB for Multi-Topology (MT) - Routing (Standards Track) - draft-ietf-ospf-mt-mib-01.txt . OSPF HMAC Cryptographic Authentication (Standards Track) - draft-ietf-ospf-hmac-sha-00.txt Non-WG Documents - Discussion needed before progressing as WG I-D: . Extensions to OSPFv2 for Advertising Optional Route/Link Attributes -draft-mirtorabi-ospf-tag-04.txt More discussion needed . OSPF MANET Drafts (Experimental) Drafts will go through the normal WG review and Last Call process - Is this the last update? . Authentication/Confidentiality for OSPFv2 (Standards Track) - draft-gupta-ospf-ospfv2-sec-00.txt Delta on top of RFC 4552 - define sec. association for OSPFv2 ----- o) OSPFv2/v3 System Name - Danny McPherson - 10 minutes No draft yet Overview: . Define mechanism for OSPF routers to learn about symbolic host names . Much akin to IS-IS dynamic host name exchange mechanism - RFC 2763 Motivations: . Current mechanism, DNS, relies on IP connectivity - May not be able to resolve if reachability problems . May want system name different than that in DNS, or new routers not yet in DNS . DNS resolution introduces extra load, could be particularly problematic in times of problem resolution . RI LSA (4970) is standardized, offers convenient place to advertise system name . Move to IPv6 will result in more difficult human parsing of IP addresses Specific points: . OSPFv3 contains single 32-bit router-ID, may be an issue as IPv6 is further deployed - Out of scope here but likely needs attention . draft-venkata-ospf-dynamic-hostname-01.txt took a stab at definition mechanism in 2003 - Using Opaque LSAs, RFC 2763 as base for ID Proposed actions: . Is there sufficient interest in defining system name mapping mechanism for OSPF? . If so, define with RI Opaque LSA or other mechanism? . Anything to use from venkata draft? . What about 32-bit router ID for OSPFv3? Discussions: - Acee: Who thinks it is a good idea? Show hands . Good support (lots of hands raising) . No opposition - Acee: What about TLV definition and other implementation specific aspects? - Dave Ward: Why did not become a WG effort in 2003? - no suitable TLV at that time - Acee: But implementation had already use of fully qualified system names - Acee: Now this is a definitive system name mapping mechanism for OSPF - Acee: In OSPFv3 the Router-ID (encoded over 32-bit) is not IPv6 address (may not even be IPv4 address) Link Local addresses are also less meaningful then IPv4 for OSPFv3 - Dave: Any fix planned for OSPFv3 - Acee: OSPFv3 will use a 32-bit Router-ID forever (not IPv6 address) - Abhay: When DNS system is down, one can not overcome DNS failures - Dave: OSPF catches up with IS-IS ----- o) OSPFv2 Multi-Instance - Abhay - 5 minutes draft-acee-ospf-multi-instance-00.txt OSPFv3 Multiple Instance - Overview: . OSPFv3 supports multiple instances with an Instance ID field in the header . Applications include: Single link serving multiple communities of OSPF Routers Single link belonging to two or more OSPF areas . OSPFv2 can do the same by using the first 8 bits of the AuType as Instance ID -> see OSPFv2 Multi-Instance Header . Maps to unknown AuType for routers not supporting it Backward Compatibility: . Issues with implementations logging errors - Can they cause more drastic issues? . Could do something more radical to "insulate" legacy implementations Separate IP protocol Separate Multicast IP Address . Authors don't feel this is necessary - Begs question as to why we don't redesign the protocol . Implementations should already silently ignore unknown authentication type or, at least, rate limit the errors o) OSPFv2 Transport-Instance - Abhay - 15 minutes draft-acee-ospf-transport-instance-00.txt OSPFv2/3 Transport-Instance: . OSPF protocol has the extensibility to carry arbitrary information: OSPFv2 Opaque LSAs OSPFv3 LSA function code . All this information can potentially contend with "routing" information On the wire In the router . This contention can impact timely route computation and network convergence . Goal is to send "non-routing" information in a separate OSPF instance Transport Instance Packets Differentiation: . We can use Instance ID in OSPFv3 . We can introduce Instance ID in OSPFv2 Transport Instance Relationship to Normal OSPF Instance: . Ships in the Night: The Transport Instance has no relationship or dependency on any other OSPF instance. . Child Instance: The Transport Instance has a child-parent relationship with a normal OSPF instance is dependent on a normal OSPF instance for topology information and assuring the "condition of reachability". Transport Instance - Ships in the Night: . Additional overhead as topology information must be advertised to satisfy the condition of reachability . Prefix information can be suppressed . OSPFv2: Only router-LSAs, network-LSAs, and type 4 summary-LSA must be advertised. In the router-LSAs, the stub (type 3) links may be suppressed. . OSPFv3: Only router-LSAs, Network-LSAs, and inter-area-router-LSAs must be advertised. Transport Instance - Child Instance: . Transport Instance will establish neighbor adjacencies just like a normal instance. . Topology information is not advertised. . Transport Instance will be dependent on its parent instance to verify the "condition of reachability" for any OSPF router. . Other optimizations are possible as well and are under discussions. Network Prioritization: . Transport Instance will use an on-the-wire preference which is lower than normal OSPF instance: don't contend with "routing"instance . Use CS3 (011000) for Transport Instance . Normal OSPF instances uses CS6 (110000) . Applicable to both OSPFv2 and OSPFv3 Transport Instance Information Encoding: . TLV style encoding similar to Traffic Engineering Extensions . OSPFv2: Application specific information will be flooded in opaque LSAs - Application ID = Opaque LSA ID (8 bits) . OSPFv3: Application specific information will be flooded in separate LSAs with separate LSA function codes - Application ID = LSA Function Code (13 bits) . Note: 8 bit Opaque LSA ID gives us 256 Applications (in last 9 years only 4 values have been used). Is that enough for future applications? Next Steps: . How much innovation should be devoted to solving this problem? . Instances can be separated with Instance ID . Add Standardized packet deprioritization for transport instance . Add omission of prefix information from transport instance . Add sharing of topology information and possibly other state information between transport instance and corresponding standard OSPF instance - Implies congruency restrictions . Shall it become Working Group Item/Document? Discussions: - Alex Zinin: Real motivation is to make it simpler for implementation - Is that not already solved with opaque LSAs? - Abhay: Yes, additionally we could do level of separation on the wire - Alex: You mean, by flooding opaque LSA and changing instance? - Abhay: To the non-default transport instance - Alex: Is dynamic change between instance possible? Between routing (default) and non-routing (non-default) instance? - Abhay: Could make it. Such implementation decisions are possible to achieve (such as to prevent mixup) here with such mechanism we can further constraint the flooding process. - Alex: Regarding the child instance approach are you going to use the parent instance for actual flooding - Abhay: Transport (child) instance is the one which is flooding the application specific information - Alex: Then parent instance is re-used for self-configuration - Acee: Both are going to be flooded, there is a the simple DB synchronization process - Abhay: It is expected that child DB exchanges will take much longer (than parent DB exchanges) No more questions raised for this doc. version. - Acee: Who has read the documents? -> Less than half the audience - Acee: Who thinks it is a good idea -> No one thinks it is good idea - Acee: Who thinks it is a waste of time? -> No one thinks it is a waste of time - Acee: First action point initiate further discussions on the list ----- o) Multi-Segment PW OSPF Advertisement Update - Andrew Dolganow - 10 minutes draft-dolganow-pwe3-ospf-ms-pw-ext-01.txt Andrew presented changes since last version: Priority given to define consensus parts required for basic functionality: . Advertise AIIs required for placement of MS-PW using OSPF . Router does not necessarily need to have T-LDP or Tunnel to advertise PW Switching LSA . Opaque LSA mechanism used to flood the advertisements (both Area and AS scope are allowed) . Pseudo Wire switching LSAs carry AIIs attached at T-PEs / routable through S-PE using Exterior AII TLV. Routers learn which AIIs to advertise through: Configuration, Advertisement, and Interaction with exterior gateway protocols (BGP) Full alignment with Dynamic Placement of Multi Segment Pseudo Wires Next steps . Adopt this draft as PWE3 WG draft (continue to work closely with OSPF group on any OSPF related topics) . Create an ISIS version Discussions: - Abhay: Flooded information size? Change rate? - Andrew: Using basic opaque LSA functionality. you only have to flood summarized info which would not change current opaque LSA processing - Acee: if everything is flooded everywhere? Every node has to process the AIIs TLVs and other PW specific information (while only needed at PEs) - Andrew: Flooding requires passing this information towards PEs. This can be further optimized. - Acee: This would be definitely a case to make of use a transport instance. Good candidate? - Alex: Only edge routers interested by this information a) physical topology to flood base routing information b) virtual topology to flood the PW specific information. The same thing for TE is used today. - Dimitri: L1VPN use a similar mechanism for edge information flooding - Acee: In case of L1VPN there is no IP routing concern due to applicability. - Dimitri: Not correct since the control protocol relies on IP routing information to route control packets. PCE has similar issues (no every router make use of PCE disc. information). - Alex: Here we have a small amount of information flooded in a summarized way - Andrew: It can be as simple as a single LSA (one prefix in a single LSA) - Dave: If the end of the doc. on congestion issues with different techniques. All these issues go away with non-routing information. write rule on processing for generic application instance. - Andrew: May be simpler than dealing with multiple instance. but this is hard to evaluate. Not even comparable to TE today. - Acee: This type of discussion shows an example of routing instance used to distribute information not related to IP reachability. I think it is a motivator for multi-instance solution. - Alex: Noble goal of the separation of routing instances but concern: It will take a couple of years before coming at something implementable. At the same time there is a real life behind PW - OSPF work. So concerned about gating any further work. This is a practical concern. - Dave: First item is to look at congestion removal and detail possibilities such as to allow implementation to support multiple instances (as also indicated in the doc. Section 5.2) - Alex: In any case, not willing to be gating further progress - Dave: Just need to document the way to go with a separate instance (when available) - Alex: WG document? PWE3 first and then OSPF for detailed review - Chairs: Yes ----- o) OSPF MANET Extensions (MDR) - Fred Templin for Richard Ogier - 20 minutes draft-ogier-manet-ospf-extension-10.txt - F.Templin presented changes since last version . Several changes to improve readability. . A more unified treatment of partial-topology and full-topology LSAs that applies to all choices of the parameters LSAFullness and AdjConnectivity. . Modified LSA construction in version 9 . Simplification of detailed algorithm for Backup MDR selection . Added the optional Phase 5 to the MDR selection algorithm (to reduce flooding overhead) . Removed the section on "Optional Treatment of Broadcast Network as MANET" . Packet format changes OSPF-MDR Simulation Update were also presented Discussions: - Thomas Clausen: Lots of different options in the draft without discussion the choices/options -> Too many options - Fred Templin: bring this discussion on the list - Thomas Clausen: flooding implies higher complexity (motivates the change) that came in v10 - Ahmad Yazdi: What is the implementation performance? - Fred: Recommend contact R. Ogier for proper perf. estimations - Abhay: Is the draft in its final shape? - Fred: Bring the point to point to the authors attention directly - Acee: Not re-requisite for making working group document. We could not agree on one technique - Need to go forward this year. So we plan to make them all experimental draft until someone come and say i have an (experimental) deployment using one of these approaches - Fred: need to be discussed with the authors (?) - Acee: OSPF MANET offers better behavior for flooding optimization (use of alt. spanning trees) - Thomas: before accepting this draft, we need to conduct experiment with these protocols because for the time being we have a tool with a large number of options. - Before moving these documents forward it is hopeful to do comparable experiments. - Acee: Need to get drafts out. That said, there are significant differences in the approaches. ----- o) OSPF Lite - Matthew Thomas - 20 minutes draft-thomas-hunter-reed-ospf-lite-00.txt Branch version of OSPF (OSPF's baby brother) . Avoids design phase. . "Instant on" for customers with no configuration if required. . Vendors can sell direct to client for large networks. . Simple single area concept . Support for external routes LSA 5s / Opaque LSAs . The ability to "boot up" (2 stage) over non fully meshed multi-access network. . MPLS core: Service Providers can implement a simplified OSPF protocol on growing MPLS clouds without resorting to IS-IS. Major adaptations (of OSPF): a) Single unified link type within the LSA Type 1 (only p2p) - Independent of the underlying network medium - All networks treated by OSPF-lite as OSPF-lite-stub or OSPF-lite-transit - P2MP, and BA removed, compensation for NBMA b) Promiscuous Hello Protocol c) LSA type reduction (single Router LSA 1) to describe router itself (data required to build the calculation graph is carried inside the Router LSA 1). External LSA, and Opaque LSA 9,10,11 are supported d) DR removal. OSPF-lite removes all of the LSA 2’s. Each LSA 2 is flooded throughout the whole area in OSPFv2. OSPF-lite uses O(n2) when prudent e) Areas/multiple instances Presenter: Call for interest and simplification of LS protocols Discussions: - Matthew: Why not grab a UDP port for this? - Ahmad Yazdi: not convinced about what this going to solve in terms of scalability. - Matthew: Idea is to remove such complexity that impacts scalability. Use of basic OSPF properties here to solve problem of rolling out OSPF while keeping cost within certain margin (FR and DSL networks). - Acee: Why not just have an informational draft on how to configure simple ospf in a single area doing everything that you propose without a single line of code - Matthew: Right. Trouble with info there is no follow-up. think are more simplification if ietf supports it otherwise no value if not ietf support - Dave Ward: Instead of speaking about technical merits? Who supports this approach? -> Dave (questioning chairs): Make a WG I-D? or not? Acee: (no hands/interest) More discussion needed. - Dave: Refers to discussion in Sept. but little came out of the discussions (3 people on it without technical merit) - Acee: Do we need to spend time on this? - Lou Berger: Additional comments. Like the idea of informational doc. but why not make a BCP (for simple OSPF configuration) instead of providing a completely new protocols. Insane to make a new protocol for this purpose. Support Acee proposal (OSPF configuration document) - Matthew: Point taken - Mark Handley: Rrange of possible solutions. Operational goal is ok but does not require new version of the protocol. This is not necessary. better grasp what can not be done with the existing protocol version. here discussions comes as a bundle (e.g scalability) but the protocol changes need to have separate discussions that seem to be painful. - Matthew: In terms of coding, yes, this is the case. - Mark: Specify command to configure protocol is possible to document but the question here is about new protocol mechanism underneath - Chris Lonvick(?): Ex-operator hat, usually when deploying new protocol operators need to have troubleshooting and training. in this case operators will for sure need for training. Vendors will also have to develop a new protocol version -> this is not a zero cost solution for both vendors and operators. - Acee: Do not see need for another lightweight IGP - Matthew: Indeed, I see not much support for new version of OSPF but support for BCP detailing OSPF configuration Conclusion: BCP document for documenting config. aspect (deployment and protocol profile) shows fair support - Alex: We have also the doc. on emulating p2p Ethernet links - Acee: All pieces are thus in place for such document - Dino Farinacci: Suggestion of having OSPF light with absolutely no protocol change - Dave Ward: Please take it to the list ----- o) Multicast Blackhole Mitigation - Thomas Morin - 10 minutes draft-morin-mboned-mcast-blackhole-mitigation-00.txt Problem statement: PIM needs cooperation from IGP to solve the problem arising when routing adj: up but PIM adjacency: not ready/not up yet (PIM hellos not exchanged yet) -> as PIM Join propagate along this path, this result in multicast traffic blackhole Note: LDP has the same issue -> LDP-IGP sync effort at MPLS WG (note similarity is not identical since label translate L3 FECs and the behavior of the routing instance remains independent of the service running on top) Proposed solution: use a MT-topology, PIM following a dedicated IGP topology (MT topology). Mandate that this dedicated IGP topology/routing instance waits for PIM adj.up (on PIM enabled interface) before advertising the link within that topological inst. upon PIM adj.ready condition verification. Next steps: Will be proposed to MBONED. Expects feedback from OSPF WG. Discussions: - Dino: First point: sending join to a non-PIM neighbor. PIM Join accepted only if the adj. is up (from known PIM neighbor). so, problem can be solved by having PIM enabled on the link. second point: make sure all routers run PIM and uses this approach. but this assumes PIM runs everywhere not on a subset of routers only - Thomas: Solves point number 1. Are PIM Hellos useless in this case? - Dino: No. When PIM Join sent toward non_PIM upstream device must first wait for hellos adj to be up. on the resiliency issues / fast recovery issue, it is safer to work with configuration otherwise requires heavy weight solution - Thomas: Need to accept PIM Joins in any case? - Dino: Router needs to send or prune in that case, by checking adjacency can determine whether neighbor is a PIM neighbor or not (indeed PIM Join message should only be accepted for processing if it comes from a known PIM neighbor). But need to clarify (in RFC 4601) processing when a router has to send PIM Joins on an interface toward a router from which it has not yet received any PIM Hello message (otherwise the receiving neighbor may discard the Join message). - Thomas: The proposal only impacts implementation. - Dino: Impacting implementation impacts the protocol. - Thomas: Second point: Situations where mcast running on some links only. - Dino: When PIM runs, it runs everywhere and not in subset of links. MT topology routing may then be effective but in any case all routers are PIM enabled. It is dangerous to use PIM Hellos as a unicast routing protocol trigger. - Thomas: Proposal does not require any complex implementations (IOS). PIM adj. is problematic. - Acee to Dino: Is the use of sync. useful (like LDP sync)? - Dino: Unicast wants to re-route but blocked by the other apps hence slower. Less synchronization is preferable today. send a PIM join by checking availability of the adj. would be preferable (instead of sending without any adj.up). Thus, need to check side effects of doing this - Thomas: Does not see any problem in applying the proposed mechanism - Dino: You only speak about the initial case. Real concern: Making IGP complex with synchronization by introducing a dependency. - Dave: IGP have LDP awareness. For PIM, is this useful or not? - Acee: Prefer solution within PIM protocol itself instead of devising synchronization with the IGP. - Dave: With LDP, synchronization is the only way to solve the problem. - Alex: you do not want to couple things (between PIM and IGP). from the operational perspective. As they run multiple services on top of the unicast IGP topology. So driving the behavior of the default topology by a given application has side effects due to this coupling. - Thomas: Document proposes to use MT topology, so no impact on the default topology. - Acee: Present at the MBONED working group - Thomas: Analogy with LDP-IGP sync. - Alex: Different dynamics here. I would not use of this to influence the base routing instance. For the multi-topology this requires further thinking - Chairs: Present the document at MBONED WG for feedback. -- Meeting is adjourned --