Subject: OSPF WG Minutes

From: Acee Lindem <[email-masked]>
Date: Mon, 15 Aug 2005 10:19:50 -0400

Attached are the minutes from the Paris OSPF WG meeting. Thanks to
Dimitri for taking them.

Acee

Open Shortest Path First WG (ospf) - Scribe: Dimitri Papadimitriou

Wednesday, August 3 at 1030-1230
================================

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

AGENDA:

 o Administriva                                            5 minutes

   - Mailing list: [email-masked]
     Subscription/Removal: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1
   - Scribe?
   - Blue Sheets

 o Document Status                                         10 minutes
   Acee

 o OSPFv3 Update                                           10 minutes 
   draft-ietf-ospf-ospfv3-update-04.txt
   Acee

 o Extensions to OSPFv2 for Advertising Optional           15 minutes
   Route/Link Attribute - draft-miratorabl-ospf-tag-00.txt
   Sina Mirtorabi

 o OSPFv3 Graceful Restart -                               10 minutes
   draft-ietf-ospf-ospfv3-graceful-restart-01.txt
   Padma Pillay-Esnault

 o OSPF MANET Design Team Update and Next Steps            20-30 minutes
   Tom Henderson (Acee presenting)  

 o Issues with existing Cryptographic Protection Methods   15 minutes
   for Routing Protocols
   draft-manral-rp-existingcrypto-01
   Russ White or Vishwas Manral

+ Alex MTR Forwarding  

-----

o) Document status (Acee)

Progress achieved since Minneapolis meeting (IETF 62)

- RFC 4126 (OSPF Refresh and Flooding Reduction in Stable Topologies)

- BCP document on "Prioritized Treatment of Specific OSPF Version 2 Packets and 
  Congestion Avoidance" most implementation do already here tese practices 
  have been documented

- Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs 
  (draft-ietf-ospf-2547-dnbit-04.txt): blocking on L3VPN

  . Alex: Lots of activity here, with the main OSPF draft there were a lot of   
    comments; lots of back and forth with the authors and changes to the document; 
    then bring back in L3VPN + OSPF WG with the perspective to have enough details 
    concerning interoperability - so it is for review

  . Acee: Invite for review for those familiar with the technology.

- OSPFv2 Graceful Restart Implementation Report 
  (draft-ietf-ospf-graceful-impl-report-05.txt) waiting on OSPFv2 MIB 
  (normative reference)

  . Alex: Does not have to be listed as normative reference

  . Acee: So going to take it as informative and progress with the document

- OSPFv2 Management Information Base (MIB) (draft-ietf-ospf-mib-update-08.txt)         

- OSPF Multi-Area Adjacency (draft-ietf-ospf-multi-area-adj-03.txt): 
  not standards track because of lack of implementation

. Alex: Why is it not implemented ?

. Acee: Because nobody intends to implement

. Alex: It is not because it does change the protocol ?

. Acee: Augmentation but not a change to the protocol

- Multi-Topology (MT) Routing in OSPF (draft-ietf-ospf-mt-04.txt)

- Extensions to OSPF for Advertising Optional Router Capabilities 
  (draft-ietf-ospf-cap-07.txt): Last version addresses Adrian's comments

- Authentication/Confidentiality for OSPFv3 (draft-ietf-ospf-ospfv3-auth-07.txt): 
  Revised I-D needed, before LC new version of the draft

- Traffic Engineering Extensions to OSPFv3 (draft-ietf-ospf-ospfv3-traffic-05.txt): 
  Last call hung in CCAMP WG as we are going to do this anyway as the WG is going to 
  satisfy ASON requirements with the extensions; so, we are going to add new sub-TLVs 
  to satisfy these requirements (ASON = TE information to control optical switches)

- Advertising a Router's Local Addresses in OSPF TE Extensions 
  (draft-ietf-ospf-te-node-addr-02.txt): Relationship with ASON but pretty done here

- IANA Considerations for OSPF (draft-ietf-ospf-iana-01.txt): Useful to have this 
  document in the process and have this as a generic document

Draft on the table
------------------

- OSPFv3 (OSPF for IPv6) revision (draft-ietf-ospf-ospfv3-update-04.txt): see below

- OSPFv3 Graceful Restart (draft-ietf-ospf-ospfv3-graceful-restart-01.txt)

- Management Information Base (MIB) for OSPFv3 (draft-ietf-ospf-ospfv3-mib-09.txt): 
  Trap need to be added

- Multi-topology routing in OSPFv3 (draft-ietf-ospf-mt-ospfv3-00.txt)

- AF ALT for support of addresses families in OSPFv3: should move forward

Pekka Salvoa: a document not product of this WG "Point-to-point operation over LAN in 
  link-state routing protocols" (draft-ietf-isis-igp-p2p-over-lan-05.txt) stuck because 
  normative ref. to IS-IS for IPv6 if we want to have this out of the stack something 
  has to be done like separate document; this is something to consider

Acee: This function exists and people do it for years but is there much of a rush to 
      make it a separate document ?

... no

Acee: The base spec is implemented for years

Alex: Check for having informational reference

-----

o) OSPFv3 Update                                           10 minutes 
   draft-ietf-ospf-ospfv3-update-04.txt
   Acee

Summary:
- Work completed
. many corrections
. remove reference to site local
. NSSA support added
. multiple interfaces per link clarified
. VL/IF ID clarified
. Add DN bit

- Section 2.9 mandates that an OSPFv3 router should not advertize an 
  unknown LSA if the U bit is set to 1 (flood as if known) into stub area; 
  This should be removed in RFC 2740 re-spin limits backward compatibility
. no corresponding rules for opaque LSAs
. fact that LSA is flooded implies one router is stub/NSSA understand it
. ineffective/non-deterministic protection of the database limit

Alex: is there a message to the ML ?

Acee: yes, 2 messages but no responses; I think the original intention was an 
 attempt to limit size of the DB but it does not work but as dependent on the topology 

Alex: Problem with the fwd'ing address ?

Acee: Done

Alex: There was a problem when mapping the fwd'ding address to the 
       ext-hop address (link-local)

Acee: Not using link-local address as a fwd'ding address; The problem has been fixed 
  by not advertising the fwd'ing address except for NSSAs; The reason for doing this 
  is that we do not do anything like that in OSPFv2

Alex: This is not what I mean: when an ASBR advertises an AS-external-LSA with 
      as fwd'ing address the (global) address of a router connected to this ASBR, 
      the calculating router will have to map this address to a link-local address

Acee: Which is not advertised

Alex: Indeed, but in IPv6, the next-hop must be link-local and you may not have a 
      routing entry to perform this resolution

Acee: I do understand the problem but I did not fix it, for NSSA you must have a fwd'ing address

Alex: Will continue the discussion on the list

----

o Extensions to OSPFv2 for Advertising Optional           15 minutes
  Route/Link Attribute - draft-miratorabl-ospf-tag-00.txt
  Sina Mirtorabi

Purpose
- carry one or more attribute associated to link/route
- appl. admin tags in internal OSPF routes
- other applications can define further attributes

Router Attributes (RA) Opaque LSA (RA LSA)
- LSDB Opaque type of 5
- Attr LS Type (one byte)
- Unique ID (two bytes)
- TLV (payload is TLV based)

Four attributes:
- Link attribute  
- Inter-area route attribute
- External route attribute
- NSSA External route attribute

Link Attribute TLV (LA-TLV) (TLV Type 1)
Inter-Area/External Route Attribute TLV (RA-TLV) (TLV Type 2/3/4)

Definitions of sub-TLV
- Standard TAG sub-TLV: carry one or more Tags (for a route)
- Extended TAG sub-TLV: carry one or extended Tags (for a route)
- MT-ID sub-LTV: carry attributes corr. to multiple topologies as defined in [MTOSPF] 

Generation of RA LSA
- a router configured to advertise link or route attributes
- regeneration only if a change occur in the attribute value
- across area boundary, an ABR will generate
. area scoped RA LSA
. AS scoped RA LSA
. unless specified by local policy

Backward Compatibility
. no issues
. ABR should be able to flood correctly unless AS scope RA LSA

Ask for WG I-D ... consideration as WG I-D ?

Acee: Will send a pointer to the list

Acee: The encoding as sub-TLV for the topology is to find rapidly information and this the 
 first case of nested sub-TLV but would be introduced incrementally; Also, the document 
 suggests a partition of the LSA ID field (Attr LS Type + ID)

Alex: In this new LSA, is the announced information part of the (original) router LSA ?

Sina: Yes you are making a reference to this LSA 

Alex: So no substitution to the existing type ?

Sina: No... but we could - this is why there is no metric field we do not do 
      that for the time being and just do this for the existing LSA

Alex: We already have the TE LSA for some equivalent purposes

Sina: Usage of this LSA is to associate one of more attributes to routes

Alex: What kind of information do you envision as associated to routes ?

Sina: TAGs can be associated to routing information for filtering e.g. 
 for fast convergence or situation where you want to carry BGP community information; 
 Also in some situations when using IGP and there is a need to carry BGP 
 attributes transparently 

Alex: This is similar to the IS-IS discussion ... referring to the VPN attribute 
 information better define a specific attribute for doing this

Sina: Here any attribute can be associated to the TAGs

Acee: TAGs are used for different purposes and this goes already like this today; 
      it is difficult to get advertisement for TAGs

Alex: TAGs are needed (not questioning the reason for TAGs) but if 
 you have a mechanism to automatically do something you want not necessarily 
 to expose this to the operation

Acee: Here looking for more flexibility... 
     TLVs do not overload the protocols - People overload protocols.

Sina: Carry standard TAGs for NSSAs but they carry single TAG and not multiple 
      so would like to be able to carry more than one tag anyway

-----

o) OSPFv3 Graceful Restart -                               10 minutes
   draft-ietf-ospf-ospfv3-graceful-restart-01.txt
   Padma Pillay-Esnault

- Common methodology for OSPFv2 and v3
- OSPFv3 specific considerations
- OSPFv3 Grace LSA
- Going forward 
  . proposed standard
  . two implementations exist

- Questions ?

Acee: This is the document closest for LC as all issues are covered ... 
      so pretty good for PS as well

Padma: questions ?

?: Grace LSA would not require usage of the interface ID

Padma: There are other LSAs that use the interface ID e.g. TE specific LSA

Acee: The network LSA uses the interface ID as the LSID.
      Editors note: As does the link LSA.

-----

o) OSPF MANET Design Team Update and Next Steps            20-30 minutes
   Tom Henderson (Acee presenting)  

Evaluation of proposal for using OSPF for IGP in MANET experimental protocol and field trial

Brief History
- MANET WG Std a set of experimental RFCs
- PS: draft-baker-...

PS 
- OSPFv3 rather than OSPFv2
- compatibility with non-wireless OSPFv3
- intra-area extensions only
- not focusing on transit network case but should not be precluded
- scaling goal is 50-100 nodes on wireless channel
- leverage on existing MANET work were possible
- use RFC 3668 guidance
...

Consensus reached so far:
- working on defining a new MANET interface type rather than a MANET area type
- focusing first on designing an optimized flooding mechanism for new LSA generations
- Focus on two active I-Ds
- ...

Both drafts focus on selecting more efficient relay node sets RNS for flooding

Differences between drafts:
- source independent vs source dependent Connected Dominated Set (CDS)
- use of hellos or LSA for dissemination of two-hop neighborhood information
- differential (incr.) hello implementation
- draft-ogier* proposes reduction of adjacencies formed in dense networks

Review of optimized flooding draft-chandra*
Review of draft-ogier*

Design team evaluation software
- both drafts have been implemented 

Simulations conducted by Boeing
- Criteria for evaluation 
- Simulation code and documentation shared with the design team members

Both techniques reduce the flooding overhead but OSPF was meant to be robust and 
not necessarily efficient in terms of adj. flooding, etc. Ogier's reduces an extra 
step in terms of unnecessary routing adjencies

Next steps:
- Design team struggle to reach consensus on a single recommended approach
- proposed to run one more meeting cycles
- boeing to process or release reporting and reference implementations (and simulator)

Acee: evaluate the two designs so it would be interesting to look at this 
Boeing code and I am going to look at it.

Acee: any comments ?

----  

o) MT Routing Fwd'ing considerations (Alex Zinin)

In both ISIS MT and OSPF MT, cases with multiple AF on same interface. In general 
MT requires separate FIBs and need to map incoming packets to MT/FIBs. Implementations 
have different demux'ing options such as DSCP or arb. IP field (policy-based) but 
there is no method which is mandatory so interoperability issue

Method works but:
  . no standard demux method
  . manual configuration
  . error prone

No intend to say do not implement a specific method but we could have one mechanism 
to be implemented as the standard something that could be used for this is e.g. a DSCP 
mapping or something being MPLS based

Would like to encourage discussions and drafts

Tony Li: seems to be unnecessary ... market will do it

Alex: which market ?

Tony: the market determines interoperability 

Alex: so ... is interoperability not necessary in your view ? 

Tony: Specify how implementations interoperate is not necessary since the market is 
  going to drive what you are going to implement so you may end with something 
  relevant so no need or irrelevant

Dave Ward: Nothing to be standardized at the data plane level however something 
  informational around the mapping for topology that would otherwise not form 
  adjacencies - but nothing to standardize at the data plane level as explain usage 
  of DSCP code-points would fall into the problem of standardizing code-points - the 
  best-case scenario: have the flexibility to mark the packets and how operators want to use his

Acee: I think the usefulness is going to be difficult - we end up with nice names but 
  impossible to have the ISP to implement what we documented here - so it may potentially 
   generate a lot of work without necessarily standardizing the actual usagex

Alex: Would that not be useful ?

Acee: I share on Dave's views - some level of information document but this may 
      not be complete

Chris Hopps: Agree - Tony has a really good point - the interoperability is going to be 
  determined by the providers and the market(ing) is going to drive the different 
  behavior in terms of forwarding 

Dave: we are discussing intra-domain (?)

Alex: Inter-domain single carrier case is also part of this ... there was a requirement 
  for doing this from the operator side to the vendors

Tony: At the IETF, we generally standardize the protocols on the wire 
  not their implementation 

Alex: So we agree that we disagree 

Tony: You require a configuration option

Alex: This is not resulting from a configuration option - here just mappings - anything 
  that is specific in a protocol can potentially be part of the specification but this is 
  not a protocol specification

Tony: protocol specification is about protocol on the wire; take a look at the 
  history of the IETF documents e.g. configuration of stub areas

Alex: This is not a good analogy here we are speaking about the consistent 
  forwarding behavior

Tony: we do not have documents that are specifying forwarding behavior

Alex: you have to be capable to forward on the longest prefix match

Tony: this is purely a per-system operation

Chris: is this not an operator issue ? ... so, it is not up to the spec to 
  fix bad configuration

Alex: Purpose is to make easier to specify a common profile between different implementations

Tony: Show hand... more hands showing disagreement

Dave: We will never be able to limit to this specific case (inter-vendor case)... 
   so we are going to specify a new specific forwarding behavior but what can be 
   standardized is the correlation and the prevention of mis-configurations that can 
   happen, leading to mis-advertisement of specific prefixes but this is outside of the 
   IGP protocol specification and separated from the forwarding behavior asked here

Alex: A, B, C being the possible behaviors (possible mappings) 

Dave: Yes, we could be marking topology X, Y, Z with an ID with the possible 
   behaviors A, B, C ... but I do not have all the details here 

-----

Acee: Lots of things that are no in the charter that are going to be added in 
    the charter (Annoncement before everyone sneaks off to lunch). 
-----

 o Issues with existing Cryptographic Protection Methods   15 minutes
   for Routing Protocols
   draft-manral-rp-existingcrypto-01
   Russ White or Vishwas Manral

Discussion:

Acee: In practice, for OSPFv2 the sequence numbers are not monotically increasing; 
  Usage of router's clock for cryptographic sequence number generation reduces the 
  chance for replay attacks across restarts. 

?: OSPF spec does not say it ... 

Acee: Graceful Restart document recommends this as one way to avoid saving the 
      sequence numbers in non-volatile storage.

Rich Graveman: This is a good document for someone that understand protocol 
  security but don't understand the routing protocol issues and for someone that 
  understand the security aspects it is now possible to work on required security 
  properties for the routing protocol - example: layer violation have big effect 
  on security or issues due to the message length that may have an impact on choice
   of security mechanism

Acee: Please, read this draft and articulate what's missing on the RSPEC list. 

Russ: In RSPEC this may become an informational document and if requirements 
  come out of this it would be interesting to have discussion about the security 
  implication of some of the protocol choices such as for instance usage of multicast