[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[OSPF] IETF 70 - OSPF WG Minutes
Please unicast any omissions/corrections to me. Thanks to Dimitri for
taking the minutes.
Open Shortest Path First WG (ospf)
Scribe: Dimitri Papadimitriou <Dimitri.Papadimitriou at alcatel-lucent.be>
Monday, December 3rd from 13:00-15:00 (Salon 3)
===============================================
CHAIR(s): Abhay Roy <akr at cisco.com>
Acee Lindem <acee at redback.com>
o) Administriva - 5 minutes
- Mailing list: ospf at ietf.org
* Subscribe/Unsubscribe: ospf-request at ietf.org with "subscribe" or
"unsubscribe" in the body of the message
* Archive: http://www.ietf.org/mail-archive/web/ospf/current/index.html
- Scribe: Dimitri Papadimitriou
- Blue Sheets
o) Agenda Bashing
- Acee: Observes first full agenda meeting since a long time.
-----
o) Document Status - Acee - 15 minutes
AD evaluation - Next step IESG:
. OSPFv3 Graceful Restart
- draft-ietf-ospf-ospfv3-graceful-restart-07.txt (Standards Track)
Pretty much ready for IESG, no problem expected, except for security aspects.
. OSPF for IPv6
- draft-ietf-ospf-ospfv3-update-18.txt (Standards Track)
Has been last called several times - Still will accept input on mapping of
precedence to traffic class solicited (in latest version). Ready for ADs.
. OSPF Multi-Area Adjacency
- draft-ietf-ospf-multi-area-adj-07.txt (Standards Track)
WG Finished - Waiting on ADs and Implementations:
. Traffic Engineering Extensions to OSPF version 3
- draft-ietf-ospf-ospfv6-traffic-07.txt.
Waiting on interoperability (Standards Track).
Have requested early allocation of TLV and sub-TLV code points.
Need to have proposal completed to have normative ref. since document
used in CCAMP.
. RFC 2370 Respin, aka OSPFv2 Opaque LSA (Standards Track)
- draft-ietf-ospf-rfc2370bis-txt.
ADs to evaluate
. Database Optimization (Informational)
- draft-ietf-ospf-dbex-opt-02.txt.
Close to WG Last Call:
. OSPF Link-Local Signaling as Standards Track
- draft-ietf-ospf-lls-03.txt.
WG last call pretty soon.
Needed for experimental RFC as MANET documents make use of it.
Implementations exist.
. Management Information Base (MIB) for OSPFv3 as Standards Track
- draft-ietf-ospf-ospfv3-mib-12.txt
Revision after Chicago meeting - getting close to WG last call
Plan to WG last call shortly after Vancouver OSPF WG meeting.
. Support of address families in OSPFv3
- draft-ietf-ospf-af-alt-06.txt.
Simple alternative. Boeing implements this on top of Quagga open source
Need Better Review/Discussion:
. Multi-topology routing in OSPFv3 (MT-OSPFv3)
- draft-ietf-ospf-mt-ospfv3-03.txt (Needs work on implementations)
. OSPF Version 2 MIB for Multi-Topology (MT) - Routing (Standards Track)
- draft-ietf-ospf-mt-mib-01.txt
. OSPF HMAC Cryptographic Authentication (Standards Track)
- draft-ietf-ospf-hmac-sha-00.txt
Non-WG Documents - Discussion needed before progressing as WG I-D:
. Extensions to OSPFv2 for Advertising Optional Route/Link Attributes
-draft-mirtorabi-ospf-tag-04.txt
More discussion needed
. OSPF MANET Drafts (Experimental)
Drafts will go through the normal WG review and Last Call process
- is this the last update ?
. Authentication/Confidentiality for OSPFv2 (Standards Track)
- draft-gupta-ospf-ospfv2-sec-00.txt
Delta on top of RFC 4552 - define sec. association for OSPFv2
-----
o) OSPFv2/v3 System Name - Danny McPherson - 10 minutes
No draft yet
Overview:
. Define mechanism for OSPF routers to learn about symbolic host names
. Much akin to IS-IS dynamic host name exchange mechanism - RFC 2763
Motivations:
. Current mechanism, DNS, relies on IP connectivity
- May not be able to resolve if reachability problems
. May want system name different than that in DNS, or new routers not yet in DNS
. DNS resolution introduces extra load, could be particularly problematic in
times of problem resolution
. RI LSA (4970) is standardized, offers convenient place to advertise
system name
. Move to IPv6 will result in more difficult human parsing of IP addresses
Specific points:
. OSPFv3 contains single 32-bit router-ID, may be an issue as IPv6 is
further deployed
- Out of scope here but likely needs attention
. draft-venkata-ospf-dynamic-hostname-01.txt took a stab at definition
mechanism in 2003
- Using Opaque LSAs, RFC 2763 as base for ID
Proposed actions:
. Is there sufficient interest in defining system name mapping mechanism
for OSPF?
. If so, define with RI Opaque LSA or other mechanism?
. Anything to use from venkata draft?
. What about 32-bit router ID for OSPF v3?
Discussions:
- Acee: Who thinks it is a good idea? Show hands
. Good support (lots of hands raising)
. No opposition
- Acee: What about TLV definition and other implementation specific aspects ?
- Dave Ward: Why did not become a WG effort in 2003? - no suitable TLV
at that time
- Acee: But implementation had already use of fully qualified system
names
- Acee: Now this is a definitive system name mapping mechanism for OSPF
- Acee: In OSPFv3 the Router-ID (encoded over 32-bit) is not IPv6
address (may not even be IPv4 address) Link Local addresses are also less
meaningful then IPv4 for OSPFv3
- Dave: Any fix planned for OSPFv3
- Acee: OSPFv3 will use a 32-bit Router-ID forever (not IPv6 address)
- Abhay: When DNS system is down, one can not overcome DNS failures
- Dave: OSPF catches up with IS-IS
-----
o) OSPFv2 Multi-Instance - Abhay - 5 minutes
draft-acee-ospf-multi-instance-00.txt
OSPFv3 Multiple Instance - Overview:
. OSPFv3 supports multiple instances with an Instance ID field in the header
. Applications include:
Single link serving multiple communities of OSPF Routers
Single link belonging to two or more OSPF areas
. OSPFv2 can do the same by using the first 8 bits of the AuType as Instance ID
-> see OSPFv2 Multi-Instance Header
. Maps to unknown AuType for routers not supporting it
Backward Compatibility:
. Issues with implementations logging errors - Can they cause more
drastic issues?
. Could do something more radical to "insulate" legacy implementations
Separate IP protocol
Separate Multicast IP Address
. Authors don't feel this is necessary
- Begs question as to why we don't redesign the protocol
. Implementations should already silently ignore unknown authentication type
or, at least, rate limit the errors
o) OSPFv2 Transport-Instance - Abhay - 15 minutes
draft-acee-ospf-transport-instance-00.txt
OSPFv2/3 Transport-Instance:
. OSPF protocol has the extensibility to carry arbitrary information:
OSPFv2 Opaque LSAs
OSPFv3 LSA function code
. All this information can potentially contend with "routing" information
On the wire
In the router
. This contention can impact timely route computation and network convergence
. Goal is to send "non-routing" information in a separate OSPF instance
Transport Instance Packets Differentiation:
. We can use Instance ID in OSPFv3
. We can introduce Instance ID in OSPFv2
Transport Instance Relationship to Normal OSPF Instance:
. Ships in the Night: The Transport Instance has no relationship or
dependency on any other OSPF instance.
. Child Instance: The Transport Instance has a child-parent relationship with
a normal OSPF instance is dependent on a normal OSPF instance for topology
information and assuring the "condition of reachability".
Transport Instance - Ships in the Night:
. Additional overhead as topology information must be advertised to satisfy
the condition of reachability
. Prefix information can be suppressed
. OSPFv2: Only router-LSAs, network-LSAs, and type 4 summary-LSA must be
advertised.
In the router-LSAs, the stub (type 3) links may be suppressed.
. OSPFv3: Only router-LSAs, Network-LSAs, and inter-area-router-LSAs
must be advertised.
Transport Instance - Child Instance:
. Transport Instance will establish neighbor adjacencies just like a
normal instance.
. Topology information is not advertised.
. Transport Instance will be dependent on its parent instance to verify the
"condition of reachability" for any OSPF router.
. Other optimizations are possible as well and are under discussions.
Network Prioritization:
. Transport Instance will use an on-the-wire preference which is lower than
normal OSPF instance: don't contend with "routing"instance
. Use CS3 (011000) for Transport Instance
. Normal OSPF instances uses CS6 (110000)
. Applicable to both OSPFv2 and OSPFv3
Transport Instance Information Encoding:
. TLV style encoding similar to Traffic Engineering Extensions
. OSPFv2: Application specific information will be flooded in opaque LSAs
- Application ID = Opaque LSA ID (8 bits)
. OSPFv3: Application specific information will be flooded in separate LSAs
with separate LSA function codes
- Application ID = LSA Function Code (13 bits)
. Note: 8 bit Opaque LSA ID gives us 256 Applications
(in last 9 years only 4 values have been used).
Is that enough for future applications?
Next Steps:
. How much innovation should be devoted to solving this problem?
. Instances can be separated with Instance ID
. Add Standardized packet deprioritization for transport instance
. Add omission of prefix information from transport instance
. Add sharing of topology information and possibly other state information
between transport instance and corresponding standard OSPF instance
- Implies congruency restrictions
. Shall it become Working Group Item/Document?
Discussions:
- Alex Zinin: Real motivation is to make it simpler for implementation
- Is that not already solved with opaque LSAs?
- Abhay: Yes, additionally we could do level of separation on the wire
- Alex: You mean, by flooding opaque LSA and changing instance?
- Abhay: To the non-default transport instance
- Alex: Is dynamic change between instance possible?
Between routing (default) and non-routing (non-default) instance?
- Abhay: Could make it. Such implementation decisions are possible to
achieve (such as to prevent mixup) here with such mechanism we can
further constraint the flooding process.
- Alex: Regarding the child instance approach are you going to use the parent
instance for actual flooding
- Abhay: Transport (child) instance is the one which is flooding the
application specific information
- Alex: Then parent instance is re-used for self-configuration
- Acee: Both are going to be flooded, there is a the simple DB
synchronization process
- Abhay: It is expected that child DB exchanges will take much longer
(than parent DB exchanges)
No more questions raised for this doc. version.
- Acee: Who has read the documents?
-> Less than half the audience
- Acee: Who thinks it is a good idea?
-> No one thinks it is good idea
- Acee: Who thinks it is a waste of time ?
-> No one thinks it is a waste of time
- Acee: First action point initiate further discussions on the list
-----
o) Multi-Segment PW OSPF Advertisement Update - Andrew Dolganow - 10 minutes
draft-dolganow-pwe3-ospf-ms-pw-ext-01.txt
Andrew presented changes since last version:
Priority given to define consensus parts required for basic functionality:
. Advertise AIIs required for placement of MS-PW using OSPF
. Router does not necessarily need to have T-LDP or Tunnel to advertise
PW Switching LSA
. Opaque LSA mechanism used to flood the advertisements
(both Area and AS scope are allowed)
. Pseudo Wire switching LSAs carry AIIs attached at T-PEs / routable
through S-PE using Exterior AII TLV. Routers learn which AIIs to
advertise through: Configuration, Advertisement, and Interaction with
exterior gateway protocols (BGP)
Full alignment with Dynamic Placement of Multi Segment Pseudo Wires
Next steps
. Adopt this draft as PWE3 WG draft (continue to work closely with
OSPF group on any OSPF related topics)
. Create an ISIS version
Discussions:
- Abhay: Flooded information size? Change rate?
- Andrew: Using basic opaque LSA functionality. you only have to flood
summarized info which would not change current opaque LSA processing
- Acee: if everything is flooded everywhere? Every node has to
process the AIIs TLVs and other PW specific information (while only
needed at PEs)
- Andrew: Flooding requires passing this information towards PEs. This
can be further optimized.
- Acee: This would be definitely a case to make of use a transport
instance. Good candidate?
- Alex: Only edge routers interested by this information a) physical
topology to flood base routing information b) virtual topology to
flood the PW specific information. The same thing for TE is used today.
- Dimitri: L1VPN use a similar mechanism for edge information flooding
- Acee: In case of L1VPN there is no IP routing concern due to applicability.
- Dimitri: Not correct since the control protocol relies on IP routing
information to route control packets. PCE has similar issues (no every
router make use of PCE disc. information).
- Alex: Here we have a small amount of information flooded in a summarized way
- Andrew: It can be as simple as a single LSA (one prefix in a single LSA)
- Dave: If the end of the doc. on congestion issues with different
techniques. All these issues go away with non-routing information.
write rule on processing for generic application instance.
- Andrew: May be simpler than dealing with multiple instance. but this
is hard to evaluate. Not even comparable to TE today.
- Acee: This type of discussion shows an example of routing instance
used to distribute information not related to IP reachability. I
think it is a motivator for multi-instance solution.
- Alex: Noble goal of the separation of routing instances but concern:
It will take a couple of years before coming at something
implementable. At the same time there is a real life behind PW - OSPF
work. So concerned about gating any further work. This is a practical
concern.
- Dave: First item is to look at congestion removal and detail
possibilities such as to allow implementation to support multiple
instances (as also indicated in the doc. Section 5.2)
- Alex: In any case, not willing to be gating further progress
- Dave: Just need to document the way to go with a separate instance
(when available)
- Alex: WG document ? PWE3 first and then OSPF for detailed review
- Chairs: Yes
-----
o) OSPF MANET Extensions (MDR) - Fred Templin for Richard Ogier - 20 minutes
draft-ogier-manet-ospf-extension-10.txt
- F.Templin presented changes since last version
. Several changes to improve readability.
. A more unified treatment of partial-topology and full-topology LSAs
that applies to all choices of the parameters LSAFullness and
AdjConnectivity.
. Modified LSA construction in version 9
. Simplification of detailed algorithm for Backup MDR selection
. Added the optional Phase 5 to the MDR selection algorithm
(to reduce flooding overhead)
. Removed the section on "Optional Treatment of Broadcast Network as MANET"
. Packet format changes
OSPF-MDR Simulation Update were also presented
Discussions:
- Thomas Clausen: Lots of different options in the draft without discussion
the choices/options
-> Too many options
- Fred Templin: bring this discussion on the list
- Thomas Clausen: flooding implies higher complexity (motivates the
change) that came in v10
- ?: what are the implementation performance ?
- Fred: Recommend contact R. Ogier for proper perf. estimations
- Abhay: Is the draft in its final shape?
- Fred: Bring the point to point to the authors attention directly
- Acee: Not re-requisite for making working group document. We could
not agree on one technique
- Need to go forward this year. So we plan to make them all
experimental draft until someone come and say i have an
(experimental) deployment using one of these approaches
- Fred: need to be discussed with the authors (?)
- Acee: OSPF MANET offers better behavior for flooding optimization
(use of alt. spanning trees)
- Thomas: before accepting this draft, we need to conduct experiment
with these protocols because for the time being we have a tool with a
large number of options.
- Before moving these documents forward it is hopeful to do comparable
experiments.
- Acee: Need to get drafts out. That said, there are significant
differences in the approaches.
-----
o) OSPF Lite - Matthew Thomas - 20 minutes
draft-thomas-hunter-reed-ospf-lite-00.txt
Branch version of OSPF (OSPF's baby brother)
. Avoids design phase.
. "Instant on" for customers with no configuration if required.
. Vendors can sell direct to client for large networks.
. Simple single area concept
. Support for external routes LSA 5s / Opaque LSAs
. The ability to "boot up" (2 stage) over non fully meshed multi-access network.
. MPLS core: Service Providers can implement a simplified OSPF protocol
on growing MPLS clouds without resorting to IS-IS.
Major adaptations (of OSPF):
a) Single unified link type within the LSA Type 1 (only p2p)
- Independent of the underlying network medium
- All networks treated by OSPF-lite as OSPF-lite-stub or OSPF-lite-transit
- P2MP, and BA removed, compensation for NBMA
b) Promiscuous Hello Protocol
c) LSA type reduction (single Router LSA 1) to describe router itself
(data required to build the calculation graph is carried inside the
Router LSA 1). External LSA, and Opaque LSA 9,10,11 are supported
d) DR removal. OSPF-lite removes all of the LSA 2?s. Each LSA 2 is flooded
throughout the whole area in OSPFv2. OSPF-lite uses O(n2) when prudent
e) Areas/multiple instances
Presenter: Call for interest and simplification of LS protocols
Discussions:
- Matthew: Why not grab a UDP port for this?
- ?: not convinced about what this going to solve in terms of scalability
- Matthew: Idea is to remove such complexity that impacts scalability.
Use of basic OSPF properties here to solve problem of rolling out OSPF
while keeping cost within certain margin (FR and DSL networks).
- Acee: Why not just have an informational draft on how to
configure simple ospf in a single area doing everything that you propose
without a single line of code
- Matthew: Right. Trouble with info there is no follow-up. think are
more simplification if ietf supports it otherwise no value if not
ietf support
- Dave Ward: Instead of speaking about technical merits? Who supports
this approach?
-> Dave (questioning chairs): Make a WG I-D? or not?
Acee: (no hands/interest) More discussion needed.
- Dave: Refers to discussion in Sept. but little came out of the discussions
(3 people on it without technical merit)
- Acee: Do we need to spend time on this?
- Lou Berger: Additional comments. Like the idea of informational doc. but why
not make a BCP (for simple OSPF configuration) instead of providing a
completely new protocols.
Insane to make a new protocol for this purpose.
Support Acee proposal (OSPF configuration document)
- Matthew: Point taken
- Mark Handley: Rrange of possible solutions. Operational goal is ok but
does not require new version of the protocol. This is not necessary. better
grasp what can not be done with the existing protocol version. here
discussions comes as a bundle (e.g scalability) but the protocol
changes need to have separate discussions that seem to be painful.
- Matthew: In terms of coding, yes, this is the case.
- Mark: Specify command to configure protocol is possible to document
but the question here is about new protocol mechanism underneath
- Chris Lonvick(?): Ex-operator hat, usually when deploying new protocol
operators need to have troubleshooting and training. in this case
operators will for sure need for training. Vendors will also have to
develop a new protocol version -> this is not a zero cost solution for
both vendors and operators.
- Acee: Do not see need for another lightweight IGP
- Matthew: Indeed, I see not much support for new version of OSPF but
support for BCP detailing OSPF configuration
Conclusion: BCP document for documenting config. aspect (deployment and
protocol profile) shows fair support
- Alex: We have also the doc. on emulating p2p Ethernet links
- Acee: All pieces are thus in place for such document
- Dino Farinacci: Suggestion of having OSPF light with absolutely no protocol change
- Dave Ward: Please take it to the list
-----
o) Multicast Blackhole Mitigation - Thomas Morin - 10 minutes
draft-morin-mboned-mcast-blackhole-mitigation-00.txt
Problem statement: PIM needs cooperation from IGP to solve the problem
arising when routing adj: up but PIM adjacency: not ready/not up yet
(PIM hellos not exchanged yet) -> as PIM Join propagate along this path,
this result in multicast traffic blackhole
Note: LDP has the same issue -> LDP-IGP sync effort at MPLS WG (note
similarity is not identical since label translate L3 FECs and the
behavior of the routing instance remains independent of the service
running on top)
Proposed solution: use a MT-topology, PIM following a dedicated IGP
topology (MT topology). Mandate that this dedicated IGP topology/routing
instance waits for PIM adj.up (on PIM enabled interface) before
advertising the link within that topological inst. upon PIM adj.ready
condition verification.
Next steps: Will be proposed to MBONED. Expects feedback from OSPF WG.
Discussions:
- Dino: First point: sending join to a non-PIM neighbor. PIM Join
accepted only if the adj. is up (from known PIM neighbor). so, problem
can be solved by having PIM enabled on the link. second point: make
sure all routers run PIM and uses this approach. but this assumes PIM
runs everywhere not on a subset of routers only
- Thomas: Solves point number 1. Are PIM Hellos useless in this case?
- Dino: No. When PIM Join sent toward non_PIM upstream device must first
wait for hellos adj to be up. on the resiliency issues / fast recovery
issue, it is safer to work with configuration otherwise requires heavy
weight solution
- Thomas: Need to accept PIM Joins in any case?
- Dino: Router needs to send or prune in that case, by checking
adjacency can determine whether neighbor is a PIM neighbor or not
(indeed PIM Join message should only be accepted for processing if it
comes from a known PIM neighbor). But need to clarify (in RFC 4601)
processing when a router has to send PIM Joins on an interface toward
a router from which it has not yet received any PIM Hello message
(otherwise the receiving neighbor may discard the Join message).
- Thomas: The proposal only impacts implementation.
- Dino: Impacting implementation impacts the protocol.
- Thomas: Second point: Situations where mcast running on some links only.
- Dino: When PIM runs, it runs everywhere and not in subset of links. MT
topology routing may then be effective but in any case all routers are
PIM enabled. It is dangerous to use PIM Hellos as a unicast routing
protocol trigger.
- Thomas: Proposal does not require any complex implementations (IOS).
PIM adj. is problematic.
- Acee to Dino: Is the use of sync. useful (like LDP sync) ?
- Dino: Unicast wants to re-route but blocked by the other apps hence
slower. Less synchronization is preferable today. send a PIM join by
checking availability of the adj. would be preferable (instead of sending
without any adj.up). Thus, need to check side effects of doing this
- Thomas: Does not see any problem in applying the proposed mechanism
- Dino: You only speak about the initial case. Real concern: Making IGP
complex with synchronization by introducing a dependency.
- Dave: IGP have LDP awareness. For PIM, is this useful or not?
- Acee: Prefer solution within PIM protocol itself instead of devising
synchronization with the IGP.
- Dave: With LDP, synchronization is the only way to solve the problem.
- Alex: you do not want to couple things (between PIM and IGP). from the
operational perspective. As they run multiple services on top of the
unicast IGP topology. So driving the behavior of the default topology
by a given application has side effects due to this coupling.
- Thomas: Document proposes to use MT topology, so no impact on the default
topology.
- Acee: Present at the MBONED working group
- Thomas: Analogy with LDP-IGP sync.
- Alex: Different dynamics here. I would not use of this to influence
the base routing instance. For the multi-topology this requires
further thinking
- Chairs: Present the document at MBONED WG for feedback.
-- Meeting is adjourned --
_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www1.ietf.org/mailman/listinfo/ospf