Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Acee Lindem (acee_at_REDBACK.COM)
Date: Thu Nov 28 2002 - 22:38:18 CST
I've incorporated comments and made some corrections
OSPF WG meeting - Thursday 22nd of november - 15:00-17:00 =========================================================
Document status (Acee Lindem and Rohit Dube): ---------------
- RFC 3101 (Not-So-Stubby-Area) currently in final RFC editorship - Traffic engineering extensions to OSPF v2 (a.k.a. OSPF-TE) passed the working group last call (completed) - IETF wide last call to be issued soon. - Hitless restart - 04 version to be issued soon. Expect to have WG last call on this version. - Detecting Inactive Neighbors over OSPF Demand Circuits (draft-ietf-ospf-dc-05.txt) is pending and is pending wg chair comments. - OSPF Refresh and flooding reduction in stable topologies (draft-pillay-esnault-ospf-flooding-04.txt) needs a couple of edits but no significant changes. - Alternative OSPF ABR Implementations (draft-ietf-ospf-abr- alt-05.txt) in the comment cycle, it is pretty much done and the last call will be issued pretty quickly - mib-update-05.txt - May want to add the graceful restart capabilities
Agenda bashing --------------
- Acee Lindem: Propose to move hitless restart after Kireeti presentation.
- Kireeti Kompella: Agrees
On the Agenda: -------------
1) Rahul Aggarwal (10 Mins): Extensions to IS-IS and OSPF for Advertising Optional Router Capabilities http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt
Several changes to this i-d since the last meeting.
1. Review of the motivation and benefits - MPLS-TE (and related) capability discovery mechanism - Network management and trouble shooting options are not extensible thus something generic needed
2. OSPF router information LSA - Optional router information LSA of type 4 and opaque ID 0 - Format of the TLV's in the body of the router info information lsa is the same as the TLV format used for the TE LSA's - Optional TLV must be included as the router capability sub-TLV (flags representing the capabilities), sub-TLV allows for adding additional information flags in the future depending on the needs
3. Router capability bits - see i-d
4. Conclusion - Application through router local policy - Flooding scope dependent on application
Acee Lindem: LSA option bits limited thus to be extended with the sub-TLV
Rohit Dube: No mailing list comments so far. How will this fit into the charter? Right now there is not a specific item.
Rahul Aggarwal: Proposal is made here to pass some information through the use of opaque LSA.
Alex Zinin: Which part of this work is within the charter? Thus confrontation of this work wrt to the charter needs to be covered in addition to an IANA consideration section.
Rahul Aggarwal: Agrees
Alex Zinin: FIFO allocation better std based with expert review before the codepoint allocation by the iana (no arbitrary stuff) experimental values to be also considered here.
Tom Petch: Negotiation before exchange these opaque LSAs? as a first step?
Rahul Aggarwal: Usage is a local matter, and also avoids the use of negotiation.
Dimitri Papadimitriou: What are the TE mesh groups mentioned in this i-d? What is behind traffic-engineering? Are we sure that the underlying concepts are well cooked? What are the relation with TEWG, the current i-d covers one of the application of TE, but generic mechanism can also be considered that overlaps with GMPLS-OSPF.
Rahul Aggarwal: Troubleshooting and specific application such as path computation server, may need additional work.
Alex Zinin: Refers to the previous comments made during the previous meeting it seems that other WG participants prefers the usage of other mechanism to deliver such capability.
Kireeti Kompella: Agrees
Rohit Dube: People that oppose may not necessarily be here
Rahul Aggarwal: Will send another mail for discussion in order to see where in which direction this i-d has to go after this meeting.
2) Kunihiro Ishiguro (15 Mins): OSPFv3 Traffic Engineering Extensions http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic-01.txt
Summary: - Using the proposed framework, proposes an intra-area TE LSA with function code 10, flooding scope is area wide scope, u bit set to 1, thus if the router does not understand LSA it must be flooded anyway. - OSPFv3 TE TLV, katz i-d used as a base. TLV thus the router address and the link TLV are considered here for the OSPFv3 router LSA.
Acee Lindem: There is an alternate proposal to be discussed thus comments to come after.
Alex Zinin: Router id related question - reachable address because it can be signalled thus what are the signalling implication related to the proposed change?
Kunihiro Ishiguro: Not sure at this moment and depends upon the implementation.
Kireeti Kompella: Does IPv6 provide a addressable and/or reachable address?
Kunihiro Ishiguro: Depends upon the implementation
Kireeti Kompella: Take for instance, BGP over ipv6 what do you advertize as the next hop?
Acee Lindem: It can be the router-id in IPv4.
Kireeti Kompella: Router address TLV has been proposed to sync up ISIS and OSPF topologies, and as used in BGP today (to connect BGP with an incoming LSP request), the missing thing here is that links can be unnumbered and thus the point of the router id (the router address that it identifies) is that it needs to be globally unique or defined as unique wide address or sometimes it may be routable thus the same thing is needed with v6.
Kunihiro Ishiguro: This comes from the traffic engineering implementation and or BGP, here a "stable IP address is not needed" but for traffic engineering purposes it seems to be.
Alex Zinin: WRT to OSPFv3 it seems that we change the semantic of the protocol, in OSPFv2, this address is a reachable IP address, in ipv6 this is not the case, thus if things are different they should be kept separate in order to maintain the consistency and the semantic of the ospfv3 protocol.
Acee Lindem: Questions about the semantic of the router-id.
Kireeti Kompella: This is the router address TLV.
3) Acee Lindem (5 Mins): OSPF Hitless Restart Update http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-03.txt note: version -04.txt posted to list
- Hitless restart i-d of J. Moy, Acee Lindem acts as editor for this document and has an implementation for the interoperability testing. Padma Pillary-Ensault is also an author with an implementation.
- Changes from 03->04 . Grace period restricted to the LSA refresh time . Alternative to saving crypto seq numbers in non-volatile storage . Alternate help mode termination (ignore LSA changes under configuration control) . Always flood to 18.104.22.168 in the case of unplanned restart which is important since a router loses the knwoledge of being previsouly elected as a designated router . Remove mospf, from future work and add less conservative helper termination
- Proposed change: Add alternative to apply the grace LSA to all neighbor adjacencies for orinating router (Padma Pillay-Esnault). This only applies to the case where there are parallel adjacenncies - appears to be fully compatible as long as the grace LSA is flooded on all interfaces.
Acee Lindem: Thus ready for last call? Will re-issue the draft for comments and wait a couple weeks.
Alex Zinin: Interoperability tests available?
Acee Lindem: Redback is interoperable with Juniper (not tried the Moy's implementation), Force10 also has an implementation.
Padma: Implementation between Juniper and Force10 tested.
4) Kireeti Kompella (10 Mins): OSPFv2 Opaques in OSPFv3 http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt
1. OSPFv2 compared to the OSPFv3 opaque LSA format
2. Proposal to migrate OSPFv2 opaque to OSPFv3, Use new OSPFv3 LSA type, everything else remains the same; the LSA ID is the same and the opaque LSA info is the same.
3. Issue with the backdoor problem - yes this is a backdoor but why it is a problem?
4. Related question? Is OSPFv3 for IPv6 (only) or an improvment of OSPFv2? Thus we should be able to run an IPv4 network with OSPFv3? - If so OSPFv3 is a superset of OSPFv2 - If not remove all the IPv4 prefix infromation from v3
Consider OSPFv3 as superset of OSPFv2 - Then we can migrate properly from v2 to v3 - If not all sorts of functions will break during the migration
Alternative: - Define a new lsa function for each of the opaque LSA type: one for TE LSA, one for the grace LSA, etc. - What's the length of the opaque id? 24 or 32 bits? But this would break the migration
Pros and cons for v2 opaque lsa in v3 - Pros: Code reuse v3 includes v2, migration - Cons: Theoritcal backdoor issue Pros and cons for translating opaque lsa one-by-one - Pro:? - Con: Would make the migration less pragmatic
Next steps: We need to understand what's this backdoor problem is weight, the pro and cons and make a pragmatic decision (to have an opaque LSA ready code)
Alex Zinin: Questions about OSPFv3 for IPv4?
Acee Lindem: Not described in the current RFC
Alex Zinin: Thus not to be used for the arguments? since this is an orthogonal problem: announce IPv4 information using OSPFv3 does not make sense
Kireeti Kompella: The inverse is done today
Alex Zinin: Do we agree?
Kireeti Kompella: Yes
Alex Zinin: Opaque type?
Kireeti Kompella: Opaque LSA, this is a v2 opaque LSA
Alex Zinin: Have a single level of numbering
Kireeti Kompella: This implies to change the code - do you know how long it takes?
Alex Zinin: Yes and i try to simplyify the code we use
Kireeti Kompella: The code to use is very simple, look at the opaque type...
Alex Zinin: What's problem we try to solve?
Kireeti Kompella: New opaque type in OSPFv3 and useful for OSPFv2 as well since I do not want to change my code for interoperability reasons
Alex Zinin: No difference between the two proposals, thus which one to select
Kireeti Kompella: Want to do it once (for all)
Alex Zinin: With the proposal you grab the function code in OSPFv3, the only difference here is, v2 in v3, by doing that you create an overlap specification space and please think about the implication
Rohit Dube: OSPFv3 for IPv6 is a different protocol from v2 in terms of a model it should be considered as different protocols.
Kireeti Kompella: Thus OSPFv3 not used for IPv4
Alex Zinin: Thus we don't use it for discussion
Kireeti Kompella: Make a statement, if the protocols are different then state this in the corrresponding document
Rohit Dube: Could you clarify your point
Kireeti Kompella: Since IPv4 in OSPFv3 is not specified, I will make the clarification in order to allow for that; by analogy, RSVP can use IPv6 identification over IPv4 everything is ready except the OSPFv2 document while people ask this from my side, thus this is a real problem and not a theoretical problem as the backdoor one.
Alex Zinin: The working group should decide what to do, but Alex's concerns with this approach is that it will create potential problem while not solving the intended problem - thus a cleaner approach should be provided.
Acee Lindem: This is not a brand new application thus I agree with Alex.
Alex Zinin: Things must always be specificed
Kunihiro Ishiguro: type 9 is already used by v2,
Kireeti Kompella: Types 9, 10, and 11 map in the value 22 in v3, meaning it is a v2 opaque LSA, but the backdoor problem is there anyway
Rohit Dube: This problem will be further discussed on the mailing lists as well the respective merits of the two approaches.
5) Jerry Ash (10 Mins): Congestion Avoidance & Control for OSPF Networks http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt
1. Introduction: Draft addresses the problem of scalability; Evidence is failure experience, vendors analyzing their own OSPF implementations, and analysis of the LSA storms
2. Background and motivation
3. Failure experience: failure experience in 4/13/98 in the ATT frame relay network.
4. Proposed protocol mechanism: Signal a congestion state, to become to a specific OSPF protocol processing during the congestion detection, the neighbors will be notified about the slowdown and adjust the flooding rate.
5. Lot's of discussion on the list - is there a problem? We feel there is a problem.
Initiate a debate on how to solve the problem, the protocol is complete as it is, and these problems will be resolved by having better implementations but operators asks for interoperable implementations this is the reason for these i-d's.
Thus proposal to go beyond this and go to a procedure for that purpose? The proposed congestion response is analogous to the helper router response to a 'grace LSA' from a congested router in hitless restart.
Concerning the approach of better coding? does it solves the problem but in the mean time we think that the better standard between vendors would be to solve these issues
Padma: Concerning the protocol extensions, grace LSA is not necessarily applicable since a restarting router is not a (necessarily) a congested router; are these to be considered as real protocol extensions (like for instance the throttling) or just more fine tuned implementations?
Jerry Ash: The congested router would signal its congestion state before it saturates, this would reduce congestion by slowing down the neighbor LSAs sent to the congested router. These mechanisms are considered as protocol extensions: the neighbor response to the congestion notification is analogous to the helper router response to the 'grace LSA' from a congested router in hitless restart.
Rohit Dube: Move discussions after the second presentation
Acee Lindem: But keep track of the charter concerning the hello and ack prioritization.
6) Gagan L. Choudhury (10 Mins): Explicit Marking and Prioritized Treatment of Specific OSPF Packets for Faster Convergence and Improved Network Scalability and Stability http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-02.txt
1. Basic issue: failures in the network generating sustained CPU usage, LSA storms, and positive feedback loops.
2. Proposal: Priority for the hello and the ack's the question is how to deliver it, ask for having this as BCP, for instance diffserv codepoints for high priority and another for low priority.
3. Simulation study: Three priority scenarios, and two network scenarios, tested with 2 LSA scenaros.
Show graphic(s) on the non converged LSA's vs the LSA storm (in seconds) to represent the strenght of the LSA storm (the actual curves)
Show graphic(s) illustrating that priority allows for pacing the storm but until a certain threshold only and if the usage of priority for acks is also provided this theshold is higher.
In all cases, the usage of priorities there is an improvement for the sustainted cpu usage.
4. Proposal: Use of special marking (at least a to become a BCP) and use of it for the prioritization of hellos.
Gagan Choudhury: Should we move to the next one?
Acee Lindem: yes
7) Gagan L. Choudhury (10 Mins) LSA Flooding Optimization Algorithms and their Simulation Study http://www.ietf.org/internet-drafts/draft-choudhury-manral-flooding-simulation-00.txt
1. How to improve this threshold significantly?
2. Basic issue: in very large networks an LSA storm a sustained cpu congestion may appear.
3. Flooding algos to be considered: - algo1: LSA flooding over all interfaces - algo2: LSA flooding over only one interface for parallel adjecencies - algo3: full flooding at mp relays to the immediate neighbors
Alex Zinin: algo3 does not guarantee the reliability of the flooding
- algo4: flooding only along a minimum spanning tree - algo5: algo2 for non-te (topological) LSA's and algo4 for the te LSA's
Alex Zinin: We can't use all of them or a selection
4. Simulation results:
. Presentation of the five different cases each analyzed with the allowed LSA storm size
. Observations on the flooding algorithms
5. Conclusion: algo2, algo5 and modified algo5 should be pursued further
Alex Zinin (as WG member): algo5 doesn't appear to be robust, can you explain in which context you propose it?
Alex Zinin (as WG member): An ATM switch fails, while the IP router is unaware of the routing topology, how does it work?
Gagan Choudhury: Network watches for any link and node failure but here we speak about the flooding link (...)
Alex Zinin: Referring to previous mailing list discussion, flooding trees generates problem when a single link fail, there is a lot of topology activity here, raising potential multiple trees
Gagan Choudhury: During the failure, basic LSA's can carry the needed information
Alex Zinin: Which LSA's are flooded?
Gagan Choudhury: Only the ones that are strictly needed
Alex Zinin: It is not always safe to say there is no topology info exchange with more efficient flooding algo's, resyncing neighbors may be heavy... something equivalent to ISIS
Acee Lindem: Basic flooding paradigm with proposed techniques seems reasonable but anything beyond this is questionable?
Gagan Choudhury: Agrees
Acee Lindem: Explicit marking, as specified in RFC 1812, says all OSPF packets should be sent at Internet Control level. If something new is proposed, it must be precisely specified.
Gagan Choudhury: Agrees, BCP and explicit marking needs more details
Rohit Dube: To be a bit stronger, priority of hellos, acks, use of other packet for the reset timer; all of these can be done without any protocol changes, to be abstracted and added as a WG i-d; everything else should be included in a separate document,
Gagan Choudhury: Agrees
Jerry Ash: Not only a BCP but also needs for an explicit notification mechanism.
Rohit Dube: BCP talks about hellos and acks, and this seems to be agreed, everything requiring protocol changes (such as flooding) should be discussed separately.
Jerry Ash: Proposed to start with the ECN (Explicit Congestion Notification)
Rohit Dube: Propose a vote concering the ECN
Acee Lindem: (describing the consensus) Clearly more people against.
Padma Pillay-Esnault: Understand the congestion problems but most of these are related to bugs and implementation issues, the extensions are not really implementation-based solution since they can generate other problems; thus proposes to take them in offline discussions to be tackled by the implementation.
Alex Zinin: EC notification and EC detection also needs mailing list discussion, people are afraid of specifying the implementation details, and believe that we don't have to go to these two extremes, (bits on the wire only versus implementation details), Alex would like to open the discussion concerning these very dynamic behaviors.
Rohit Dube: charter update ===========================
Charter update has been sent out on the list
Selection criteria are as follows: - Rough consensus on the list - Technical quality of these i-ds - Urgency of the item - Charter proposal pending for a bit (queue up)
Done things: ----------- - OSPF for IPv6 - NSSA update - OSPF-TE extensions
To do list: ---------- - See proposal
Dropped: ------- - MOSPF - OSPF flooding reduction
Note: To be reconsidered in case of strong need
Alex Zinin: IPv6 meeting today on "site local" issues. Site border work not needed for now.
Rohit Dube: Will submmit the chrter to these i-ds
Acee Lindem: New items will be added or removed per evaluation criteria. ** end of the meeting **