Concludes58th IETF OSPF WG Minutes - Reported by Dimitri Papadimitriou
Monday November 10 (15:30 - 17:30)
=================================
CHAIRS: Rohit Dube <rohit@utstar.com> Acee Lindem
<acee@redback.com>
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 protocols and major features .
implementation survey
****************************************
*****************************
o Acee Lindem (10 mins): "Graceful OSPF Restart Implementation Report" -
draf
t-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 ospf General Group . 3
new objects to the ospfNbrEntry . 3 new objects to the ospf
VirtNbrEntry
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.
- Sina Mirtorabi: There was some discussion with Pat sometime ago
regarding a scenario and sending Hello over TA ( not making it as DC) help to
avoid the problem.
- Alex Zinin: making it as DC or not should not matter for recursive TA.
- Sina Mirtorabi: I think this need more thought for recursive TA.
- 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/Prob
lem_Statement_for_O
SPF_Extensions_for_Mobile_Ad.pdf>
<ftp://ftpeng.cisco.co
m/fred/manet/Problem_Stateme
nt_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 ***
|
