Subject: Updated WG Minutes

From: Acee Lindem <[email-masked]>
Date: Wed, 11 Dec 2002 20:52:52 -0500

I've gotten some corrections on from people on what they said and and
thought it might make sense to re-post the 55th IETF WG Minutes.
--
Acee
OSPF WG meeting - Thursday 22nd of november - 15:00-17:00
=========================================================
Reported by: Dimitri Papadimitriou

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

Summary:
--------

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

Discussion:
-----------

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: Might be a good idea to avoid FCFS allocation
policy and go with Standards Action, IETF consensus, or
at least expert review, we don't want to waste code points.
Some value may also be allocated for experimentation.

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 in OSPFv2 TE extensions is a
routable address, here you're changing it to a unique
number only. What are the signalling-related implications?

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: Seems that the confusion comes from the fact
that even though the OSPF Router ID is defined as a unique
32-bit integer in OSPFv2, many implementations chose to
use an IPv4 address for this purpose, while in OSPFv3
the 32-bit ID looses its possible address-related semantics.
The logic in the draft seems to follow this. [Ishi agrees]
However, the TE router-id is a separate notion. It is defined
as a routable address in OSPFv2/IPv4, and we should stick
with the same semantics in OSPFv3/IPv6.

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

Summary:
-------

- 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 224.0.0.5 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.

Discussion:
----------

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

Summary:
--------

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

5. Conclusion

   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)

Discussion:
----------

Alex Zinin: Questions about OSPFv3 for IPv4?

Acee Lindem: Not described in the current RFC

Alex Zinin: Let's not use this as the basement
for the argument then.

Kireeti Kompella: The inverse is done today

Alex Zinin: Do we agree?

Kireeti Kompella: Yes

Alex Zinin: Why do you need "opaque type" in OSPFv3
LSAs?

Kireeti Kompella: Opaque LSA, this is a v2 opaque LSA

Alex Zinin: What not have a single level of numbering?

Kireeti Kompella: This implies to change the code - do
you know how long it takes?

Alex Zinin: Yes

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: Final comment: leaving this up to the WG
to decide which way to go, but concerned with this
approach, as it will potentially create problems.

Acee Lindem: This is not a brand new application thus
I agree with Alex.

Alex Zinin: Our job here is to make sure independent
and interoperable implementations can be developed based
on what we specify, I think this approach may result
in underspecification.

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

Summary:
--------

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

Discussion:
----------

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

Summary:
-------

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 scenarios.

   Show graphics on the non-converged  LSAs Versus time
   as a function of the strength of the LSA storm (one curve
   for each LSA storm).  There is an upper limit or threshold
   of LSA storm that the network can live with without causing
   sustained CPU congestion.

   Show table illustrating that in all cases priority for Hello
   increases the LSA storm threshold that the network can sustain.  I
   In addition, if priority is given to LSA Ack as well then the
   LSA storm threshold is increased even further.  Also, with
   priority for Hello the adjacency is not declared down even
   under heavy CPU congestion.

4. Proposal: Prioritization of Hello and
   LSA Ack is proposed as a BCP.  One way of doing this
   would be to use one diffserv codepoint for higher priority
   OSPF packets and another diffserv codepoint for lower
   priority OSPF packets.  Another way would be to look at
   the packet headers of incoming OSPF packets and queue higher
   and lower priority OSPF packets separately.

Discussion:
----------

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

Summary:
-------

1. How to improve the LSA Storm threshold
   significantly?

2. Basic issue: in very large networks a
   large LSA storm may cause a sustained cpu congestion.

3. Flooding algos to be considered:
   - algo1: LSA flooding over all interfaces
   - algo2: LSA flooding over only one interface
            for parallel adjacencies
   - algo3: Full flooding only at Multipoint
            relays that are a subset of 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
   - algo5: algo2 for LSAs carrying intra-area topology
            info and algo4 for "other" LSAs.  A modified algo5
            also considered that makes the flooding links for
            "other" LSAs survivable under single link failure and
            single node failure (using dual spanning trees)

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:
     Algorithm 2 gives substantial improvement over Algorithm 1,
     Algorithm 3 provides marginal improvement over Algorithm 2,
     Algorithms 4 and 5 provide substantial improvements over
     Algorithm 2. Modified Algorithm 5 is in between Algorithms
     5 and 2.  Algorithm 4 is not robust under failures and
     should not be considered.

5. Conclusion: algo2, algo5 and modified algo5 should
   be pursued further

Discussion:
----------

Alex Zinin (as WG member): algo4 doesn't appear to be
robust, can you explain in which context you propose it?

Gagan Choudhury: In algo5 all LSAs carrying
topology info would be flooded to all neighbors all
the time. "Other" LSAs may not reach destination temporarily
in case the minimum spanning tree is broken. They may be
reflooded after the minimum spanning tree is repaired.

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: ATM Network is typically
designed to be able to carry traffic under single link and
single node failure. Our modified algo5 makes the flooding link
for "other" LSAs survivable under single link and single node
failures.

Alex Zinin: We had a flooding-related mailing list a while ago where a
similar discussion happened, an interesting aspect is that flooding
optimizations are interesting when we have many topology changes, as
this is when we have a lot to flood, but this also means that the
changes are likely to hit both STs.

Gagan Choudhury: During the failure, basic LSA's can carry
the needed information.

Alex Zinin: Which LSA's are flooded?

Gagan Choudhury: Full flooding is only for the
ones that are strictly needed.  This includes "Router" and
"Network" LSAs.  "Other" LSAs are flooded over spanning tree.

Alex Zinin: It is not really better to drop a type-4 or type-5
LSA as opposed to type-1 or type-2 (topology carrying), because
if a router misses a prefix in its routing table, we'll have
loops. Thinks if the WG is to consider flooding optimizations,
it will be hard to get away without resync'ing, which may be
heave with the current OSPF mechanisms, might need a passive
mechanism like ISIS CSNPs.

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 oscillate between two extremes: only bits on the wire
matter, vs implementation details. Alex thinks that specifying bits on
the wire is not enough for routing protocols, as node-local processes
affect behavior of the distributed system, however implementations
details are too much. It is possible, though, to find the middle
ground, see BGP route flap dampening for example.

==========================================================

Rohit Dube: charter update
===========================

Summary:
-------

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

Discussion:
----------

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 **

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 12 Dec 2002 14:23:28 -0800

Hi Acee,

> thought it might make sense to re-post the 55th IETF WG Minutes.

Here are some more corrections/clarifications, prefaced by >>>.

Kireeti.

2) Kunihiro Ishiguro (15 Mins): OSPFv3 Traffic Engineering Extensions

(snipped)

>>> A Router Address is a stable, routable address.  A router ID
>>> may not be routable.

>>> problem is, weigh the pros and cons and make a pragmatic

Discussion:
----------

>>> as the basis

for the argument then.

>>> I can't remember what I said here.

Alex Zinin: Do we agree?

Kireeti Kompella: Yes

Alex Zinin: Yes

>>> Thus OSPFv3 is not to be used for IPv4

>>> RSVP can use IPv6 addresses (for ERO) over an IPv4 backbone

>>> value 22 is just an example!

---

From: Acee Lindem <[email-masked]>
Date: Thu, 12 Dec 2002 17:36:25 -0500

Anybody else???? I should have know that if I sent them in I'd
get some additional comments.

Thanks,
Acee

--
Acee

---

From: Alex Zinin <[email-masked]>
Date: Fri, 13 Dec 2002 09:53:58 -0800

Acee,

 I sent you mine unicast yesterday.
 Let me know if you'd like me to repost them
 to the list, pls.

--
Alex