Open Shortest Path First WG (ospf) - Scribe: Dimitri Papadimitriou
Wednesday, August 3 at 1030-1230
================================
CHAIRS: Rohit Dube
Acee Lindem
AGENDA:
o Administriva 5 minutes
- Mailing list: OSPF@PEACH.EASE.LSOFT.COM
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.
Vishwas: OSPF spec does not state that the clock should be used for cryptographic sequence numbers.
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
|
