Subject: Meeting Minutes for 58th IETF OSPF WG in Minneapolis

From: Acee Lindem <[email-masked]>
Date: Mon, 24 Nov 2003 10:31:07 -0500

Thaks to Dimitri  Papadimitriou for taking the meeting minutes. If you
have comments, please
send them to me in a private E-mail. I will send an update to the list
before sending  the final version
to the proceeding. I'd especially encourage those who spoke up at the
meeting to review your
statements as transcribed in the minutes.

Thanks,
Acee
Monday November 10 (15:30 - 17:30)
=================================

CHAIRS: Rohit Dube  <[email-masked]>
        Acee Lindem <[email-masked]>

AGENDA:

o Chairs (5 Mins): Agenda Bashing

o Chairs (10 Mins): WG document status

- Published "Traffic Engineering (TE) Extensions to OSPF Version 2"
  as RFC3630

- Approved for publication "OSPF Refresh and Flooding Reduction
  in Stable Topologies" - draft-pillay-esnault-ospf-flooding-07.txt

- To be published "Graceful OSPF Restart"
  draft-ietf-ospf-hitless-restart-08.txt

- IESG Evaluation/Revised I-D needed:
  . "Detecting Inactive Neighbors over OSPF Demand Circuits"
    draft-ietf-ospf-dc-06.txt

- Awaiting I-D write up
  . "Prioritized Treatment of Specific OSPF Packets and Congestion
    Avoidance" - draft-ietf-ospf-scalability-06.txt

- WG Last Call
  . "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs"
    draft-ietf-ospf-2547-dnbit-01.txt

- Soon to become WG documents:
  . "OSPF version 2 Management Information Base" (update of the
    RFC1850) - draft-ietf-ospf-mib-update-07.txt
  . "Authentication/Confidentiality for OSPF version 3"
    draft-ietf-ospf-ospfv3-auth-03.txt

- More discussion needed to get WG status:
  . "Management Information Base for OSPF version 3"
    draft-ietf-ospf-ospfv3-mib-07.txt
  . "Traffic Engineering Extensions to OSPF version 3"
    draft-ietf-ospf-ospfv3-traffic-01.txt
  . "Extensions to OSPF for Advertising Optional Router Capabilities"
    draft-ietf-ospf-cap-01.txt

- RFC1264 - requirements for ptotocols and major features
  . implementation survey

*********************************************************************

o Acee Lindem (10 mins): "Graceful OSPF Restart Implementation
  Report" - draft-ietf-ospf-graceful-impl-report-00.txt

Summary:
-------

This document provides an implementation report for the Graceful
Restart extension to the OSPF protocol per RFC 1264 (stating the
requirements for a report on implementation experience).

- Five vendors have implemented graceful OSPF and have completed the
  implementation survey.

- Implementation Differences:
  . Whether or not strict LSA checking was implemented and, if so,
    whether it was configurable (note: strict LSA checking indicates
    whether or not a changed LSA will result in termination of the
    graceful restart by a helping router.)
  . Whether a received grace LSA would be taken to apply only to the
    adjacency on which it was received or all adjacencies with the
    restarting router.
  . Whether or not additional extensions were implemented to
    accommodate other features such as protocol redistribution or
    interaction with MPLS VPNs

- Addition to the OSPFv2 MIB:
  . 5 new objects to the ospfGeneralGroup
  . 3 new objects to the ospfNbrEntry
  . 3 new objects to the ospfVirtNbrEntry

Discussions:

- Acee Lindem: anyone else interested (from the already listed 5
  vendors) ?

-> yes, 2 additional vendors expressed interest and will be included
   upon completion of the survey.

*********************************************************************

o Rahul Aggarwal (10 Mins): "Support of address families in OSPFv3"
  draft-mirtorabi-ospfv3-af-alt-00.txt

Summary:
-------

- Agenda: Motivation, Proposed solution, Design consideration

- Motivation: Need to carry multiple AF in OSPFv3 (such as
  multicast IPv6, unicast or multicast IPv4) in addition to
  IPv6 unicast

- Proposed solution:
  . Multiple AFs are introduced in OSPFv3 by reserving Instance IDs
    and using one OSPFv3 instance for exactly one AF.
  . Each AF establish different adjacency, have different LSDB and
    compute different SPT.
  . Hello processing: to avoid blackholing, hello processing is
    changed in order to only establish adjacency with the routers
    that have the AF-bit set in their Options field.
  . Modification of the semantic of some of the Option field bits
    defined in RFC2740.
  . Carrying Prefixes in new AF's: each Prefix has a prefix length
    facilitating the advertisement of prefixes of different lengths
    in different AF's (no need to define new LSAs).
  . Virtual Link (VL): virtual link are not currently supported in
    other AF's than IPv6 unicast AF (as there cannot be a multihop
    forwarding based on global IPv6 address or such a path may not
    exist).

- AF Design Considerations:
  . Mmapping an instance to an AF doesn't introduce new mechanisms
    in the protocol
  . Minimizes the protocol extensions required and simplifies the
    implementation.
  . Presence of a separate LSDB per AF is easier to debug and
    operate.
  . Does not change the existing instance, area and interface based
    configuration model of most OSPF implementations

- Request to make it a WG document

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

- Fred Baker: Agree to make it working group document but concern
  wrt mobile ad hoc networks (MANET) - does not want to have two
  neighbor relationships and favor keeping a single instance.

  Also this solution potentially doesn't address MANET concerns
  and requirements.

- Acee Lindem: everybody here is in agreement that in OSPFv3 has
  to support multiple AF's so we need to address this issue

- Fred Baker: In favor of having a single instance (neighbor
  with a process of transitioning) and doesn't want to see both
  OSPFv2 and OSPFv3 using AF's (doesn't want to have separate
  protocols for achieving this capability).

  This is a solution for allowing mutliple address families in
  OSPFv3 but this solution doesn't necessarily meet the MANET
  requirements.

  However, agrees to make it a working group document.

- Hasmit Grover: Not specific to this solution, questions
  the duplication of information in OSPFv3.

- Rahul Aggarwal: Not duplicating anything, it is a matter of
  having two router LSAs instead of one.

- Hasmit Grover: Still need duplication of topology information
  and it would not be more complicated to have a single instance
  for doing this.

- Acee Lindem: The target was simplication.

- Hasmit Grover: Doesn't know how much that problem it is, why
  OSPFv3 is so different ?

- Rahul Aggarwal: not TLV based

- Acee Lindem: By comparison, using a single instance for providing
  this would require more work (than what is proposed here).

- Rahul Aggarwal: Request for WG document ?

- Acee Lindem: I would like to have some more discussion on the
  proposed solution, but the requirement is acheived - it seems
  that no one disagrees that this is a requirement for OSPFv3.

- Acee Lindem: Sense the meeting room for WG document status.

-> Few people in favor

- Acee Lindem: Sense the meeting room for having an integrated
  solution.

-> Few people in favor

- Acee Lindem: WG document status and see how the discussion can
  progress.

- Rahul Aggrawal: This is document is good basis to work on this
  topic.

- Acee Lindem: The target for the working group is to come with
  something simpler.

*********************************************************************

o Rahul Aggrawal (10 Mins): "Advertising a Router's Local Addresses
  in OSPF TE Extension" - draft-raggarwa-ospf-te-node-addr-00.txt

Summary:
-------

- Agenda: Motivation, Problem Statement, Proposed solution, Conclusion

- Motivation: in some cases (for instance in a network carrying VPN
  and non-VPN traffic it is desirable to setup) CSPF computed MPLS TE
  LSPs to local addresses of a router that are not advertised in the
  TE LSAs i.e. loopback and non-TE interface addresses.

- Problem: OSPF routers can only use CSPF to compute MPLS TE LSPs to
  the router ID or the local addresses of TE enabled links, of a
  remote router.

  This because:
  . OSPFv2/v3 TE extensions only advertise the router ID and the
    local addresses of TE enabled links, of a given router -> other
    routers cannot populate their TED with other local addresses of
    the advertising router i.e. loopback and non-TE i/f addresses.
  . OSPFv2 stub links in the OSPFv2 router LSA OSPFv2 provide stub
    reachability information but not sufficient to learn all the
    local addresses of a router (same problem w/ intra-prefix LSAs
    in OSPFv3)

- Proposed solution:
  . Advertise the local addresses in a new node attribute TLV, in
    the OSPF TE LSA
  . Node attribute TLV carries the attributes associated with a
    router - it contains one or more IPv4/v6 local address sub-TLVs

Discussions:
-----------

- Acee Lindem: Put the discussion on the mailing list

- Acee Lindem (to Rahul): You could poll this information out of
  the router LSA and set that information from the topology?

- Rahul Aggarwal: Will give the details.

- Acee Lindem: Ask for comments on the mailing list, this document
  is a small amount of work since it slightly modifies OSPF-TE

*********************************************************************

o Sina Mirtorabi (10 Mins): "OSPF Tunnel Adjacency"
  draft-mirtorabi-ospf-tunnel-adjacency-00.txt

Summary:
-------

- What it is a Tunnel Adjacency (TA): Proposal to solve the intra-
  area/inter-area path preference, generalization of virtual links,
  it can force OSPF to take the desire path and it has the on-
  demand partition capapbility

- What does TA resolve: intra/inter-area path preferecne, in hub
  and spoke topology, it saves the cost of adding a new interface,
  between ABRs, it helps in repairing by avoiding segmented areas

- How a TA is established: configured as for VL's, and then it is
  announced

- How data packet is fowarded:
  . if ABR-ABR link is direct link -> sent w/o encaps
  . if ABR-ABR link is mutli-hop -> encapsulation needed (doesn't
    need configuration)

- TA Configuration/Parameters:
  . TA is configured between two ABRs attached to the same OSPF
    area.
  . Parameters: Tunnel-adjacency Transit Area (TTA) and as for
    VL's, a TA is identified by Router ID of the other endpoint
    and its Area ID

- TA resolves the VL limitations:
  . a TA link can belong to any area,
  . summarization is not affected
  . TA can't go through stub/nssa area

- TA has added value features:
  . TA cost is configurabken
  . Provides on-demand partition repaitr
  . Mutliple TA through a given path

Discussions:
-----------

- Padma Pillay-Esnault: Don't see what this adds wrt to tunneling
  between two ABR's.

- Sina Mirtorabi: 3 differences, config overhead (IP address),
  rely on IP address (reachability is done in given area, while
  tunnel doesn't guide the reachability), and provides automatic
  partition repair.

- Alex Zinin: RFC 2328 limits the configuration of the VLs so
  that they can only transit through non-backbone areas and
  always belong to the backbone. Among other things this prevents
  "recursive" VLs, i.e., VLs relying on other VLs.

  The draft relaxes this and suggests that the TA can belong to
  any area and can transit any area. This opens up a possibility
  for TA1 that belongs to area A1 to transit area A2 that has TA2.
  This means that it could be possible for packets to be
  encapsulated more than once. It seems it could also be possible
  to have recursive TA resolution, e.g. in the case above, TA2
  transiting area A1.

- Padma Pillay-Esnault: You're making people trying to avoid VL,
  while topological changes are going to generate re-routing.

- Sina Mirtorabi: VL issue is that it was recommended to "not use
  VL".

- Padma Pillay-Esnault: Any trigger in its own area is going to
  generate path re-computation.

- Acee Lindem: But any intra-area topological change is going to
  generate path re-computation in one way or another.

- Padma Pillay-Esnault: But here you may trigger several SPFs and
  thus end up with several levels of SPF,

- Acee Lindem: Yes, changes can trigger other changes during re-
  computation

- Acee Lindem: Express concerns about the requirements, today we
  have a limitation on an interface belonging to a single area. This
  requirement can be satisfied by considering the area ID but do
  we want to go further and have an automated tunneling ?

- Sina Mirtorabi: Main reason is to have a solution that avoids
  direct links, otherwise Pat Murphy approach was there to solve
  this issue.

- Acee Lindem: But that draft was too complicated.

  -> Take this to the list?

*********************************************************************

o Kiretti Kompella (10 Mins): "OSPFv2 Traffic Engineering Extensions
  for Multi-access Networks"
  draft-kompella-ospf-multiaccess-te-00.txt

Summary:
-------

- Traffic Engineering extensions for OSPFv2 for dealing with multi-
  access networks since the bandwidth attributes in the OSPFv2 TE
  do not accurately model the available bandwidth across a multi-
  access network.

- LAN being modelized as a star (modelisation X=DR being one of the
  router attached to the LAN) but X doesn't generate a TE LSA thus
  the bandwidth availability (i.e. Unreserved Bandwidth) is not
  available in the reverse direction (e.g. X->D)

- Motivation comes from that fact that switches are increasingly the
  router interconnection of choice and it is fairly trivial to
  achieve this, by advertizing the reverse bandwidth (i.e. from
  the DR)

- Next steps:
  . Two questions is this useful? Hole in RFC 3630 but also be
    a requirement from service provider?
  . Vendors to tell if this a reasonable solution.

Discussions:
-----------

- Acee Lindem: Put the question on the list?

  This is one is a bit more complicated than the previous TE
  extension (Rahuls), with two more vectors of information.

- Acee Lindem: Do we want TE to this level of detail that keeps
  track of the type of switch ?

- Dave Ward: There is a requirement to solve the problem, this
  is also a requirement for which Cisco is receiving input to
  define such kind of extensions.

- Acee Lindem: Wonders if this has to be dealt here in the OSPF
  WG or in the TE WG?

- (?): any admission control issue ?

- Kireeti Kompella: Implementation needs a change to use this,
  backward compatible means that routers by seeing this, they
  don't pick out (of course they wouldn't be capable of using this);
  also by using a new TE LSA, router on the LAN would have to
  understand this TE LSA - concerning CAC issue suggests you read
  the draft

- (?): interaction between admission control and RSVP ?

- Kireeti Kompella: when TE extensions where defined, conclusion
  was that it doesn't make sense to say how RSVP-TE interacts
  with this, (this has not been done in OSPF-TE as well) some of
  the hints to do have been given in the document. Kireeti says
  it should be clear for the reader.

- (?): put the information here asks the question of what is the
  added value of having this information to perform the CSPF.

- Kireeti Kompella: Information is there to do admission control
  on the LAN.

- George Swallow: It works in the fully point-switched case, but
  not in the case of cascaded switches.

- Acee Lindem: Put also on the TE WG mailing list

*********************************************************************

o Fred Baker (10 Mins): "Problem Statement for OSPF Extensions for
  Mobile Ad Hoc Routing"
  draft-baker-manet-ospf-problem-statement-00.txt

- Problem statement for OSPF extensions for mobile ad hoc networks

- Presentation:

<ftp://ftpeng.cisco.com/fred/manet/Problem_Statement_for_OSPF_Extensions_for_Mobile_Ad.pdf>
    <ftp://ftpeng.cisco.com/fred/manet/Problem_Statement_for_OSPF_Extensions_for_Mobile_Ad.ppt>

Discussions:
-----------

- Rahul Aggarwal: High level comment, the argument on why OSPF is
  suitable is that one MANET network may co-exist with an existing
  LAN network -> so good to think about extensions

  The question is if meeting the MANET requirements generate a
  fundamental change is it not better to have a separate protocol?

- Fred Baker: INRIA want to have their own protocol, but I want to
  keep both in one place - the only concern is related to the
  scalability properties of OSPF - note also the concern on the
  training issue (so ask if possible to just add a new interface).

- Joseph Macker: A bit of history, in essence these protocol
  requirements seem applicable to OSPF, in addition people deploy
  and know how to manage it, it has homogeneous properties, and
  provides prefix summarization - here lot of interesting things
  in deploying OSPF for MANET networks seems to be stimulated
  by the development of this (new) problem statement.

  -> Is there a place for this development and in order to start
  this we need a problem statement document

- Rahul Aggarwal: Arguments seem valid, but seeing the Baker's
  presentation, it also seems there are lot of changes to be
  expected.

- Fred Baker: Not proposing to change the area hierarchy, what we
  are proposing is adding a MANET (radio) interface which is not
  behaving as a canonical "OSPF interface".

- Rahul Aggarwal: We need probably more discussions.

- (?): how do we address the bandwidth constraint issue?

- Fred Baker: Turns out there are lot of things to be said here
  concerning this but we speak here in terms of Mbits .

- INRIA rep: Disagrees strongly that they were not interested
  in OSPF, on the contrary INRIA put a lot attention and interest
  in OSPF, and are clearly  also looking at OSPF extensions.

- Alex Zinin: Refers to an understatement by "simply adding an
  interface" - before starting to speak about adding an interface,
  there are lot of things that may be impacted by adding such kind
  of interface and this even if it looks like very simple, it might
  not be the case.

- Acee Lindem: Now OSPF is a general purpose protocol, if we take
  on all these requirements it will look like very different from
  what it is today? But I fear that if you take all the military
  requirements, I am not sure we will end up with the same protocol
  as we have today - Give the example of authentication in OSPFv3
  using shared key multicast model - Thus take into account the
  military requirements may require a chain of changes from the
  existing documents.

- Joseph Macker: We don't speak about military requirements, lot
  of these are like the existing requirements of an ISP, Baker's
  proposal was about optimization but wasn't pushed out and here
  proposal using a kind of stub within OSPF, being less intrusive
  but also less flexible - it is pretty easy to understand.

- Sue Harres: Subsets have been worked out by the ISP's and how
  these changes can be allowed - point to the summarization issue.

- Acee Lindem: Concurs on fears concerning summarization.

- Sue Harres: Router protocols converge very fast today.

- Acee Lindem: My fear was the change to the basic area hierarchy

- Fred Baker: What I expect with the area boundary behavior, is
  that we will summarize at an area boundary as done now, but now
  information is spread, here departure by having a specific
  propagation w/i a specific area with longest prefix match first.

- Sue Harres: Worry about the inter-region flooding, solved if
  there are multi-admin hierarchy, we have to gauge where we're
  getting benefits and problems.

- Fred Baker: The big problem comes from the exponential explosion
  in messages and managing that growth (not the summarization).

- Acee Lindem: there must be a defined hierarchy, the existing
  protocol will be summarizing when the entity moves from area
  to another.

- Alex Zinin: Subsequent convergence in IGP is not the same wrt to
  the density of the topology - injecting information from an area
  to another while the majority of the nodes remains in the same
  area?

- Rao: This would generate lot of dynamic state changes - using a
  list of neighbors depending on the region where the entity is
  located, this list would be pre-configured, but by moving from
  one region to another are you still keeping the same group of
  neighbors?

- Fred Baker: Doesn't understand -> take offline

- Joseph Macker: Idea with this is to find which WG can host the
  discussion here, proposes to discuss where people think this
  item has to go, key thing is to know if this protocol can be
  implemented using OSPF

- Acee Lindem: Someone to send the list of drafts so that people
  can take a look about what we are talking about.

*** Meeting is adjourned ***