Open Shortest Path First WG (ospf)
Monday, March 17 (13:00 - 15:00)
================================
Reported by: Dimitri Papadimitriou
CHAIRS: Rohit Dube <rohit@xebeo.com>
Acee Lindem <acee@redbgraphics/.com>
AGENDA:
Agenda Bashing 5 Mins
MIB Update 10 Mins Dan Joyal
<draft-ietf-ospf-mib-update-05.txt>
<draft-ietf-ospf-ospfv3-mib-05.txt>
OSPF as the PE/CE Protocol in BGP/MPLS VPNs 10 Mins Eric Rosen
<draft-rosen-ospf-2547bis-dn-00.txt>
Support of address families in OSPFv3 15 Mins Abhay Roy
<draft-mirtorabi-ospfv3-af-00.txt>
WG document status 10 Mins Chairs
WG Charter Update 15 Mins Chairs
----------------------------------------
-----------------------------------------
Meeting minutes:
================
Agenda Bashing 5 Mins
----------------------------------------
-----------------------------------------
1) MIB Update (10 Mins): Dan Joyal (Acee Lindem)
<draft-ietf-ospf-mib-update-05.txt>
<draft-ietf-ospf-ospfv3-mib-05.txt>
OSPF MIB Status (Dan Joyal, discussed by Acee Lindem)
o OSPFv2 MIB:
Latest version -05.txt (Nov'00)
Pending updates:
- Add support for Graceful Restart
- Add General group object for configuring reference bandwidth
- Change General group object ospfOpaqueLsaSupport MAX-ACCESS from
read-write to read-only
- Deprecate ospfExtLsdbTable and add ospfAsLsdbTable
- Add external route tag object to
ospfAreaAggregateTable for NSSA (RFC 3101)
- Add configuration support for detecting inactive neighbors over DC
- Change status of RFC 1850 compliance and conformance groups to
current
Acee Lindem: respond and then WG last call (before the next ietf
meeting)
o OSPFv3 MIB:
Lastest revision is -05 (Apr'02)
Pending updates:
- Add support for Graceful Restart
- Add General group object for configuring reference bandwidth
- Add General group counter object for External LSAs (for database
overload)
- Add external route tag object to
ospfv3AreaAggregateTable for NSSA
- Add configuration support for detecting inactive neighbors over DC
- Add instance ID object to virtual interface entry
- Remove LSA type enumerations from LSDB tables because OSPFv3
supports unrecognized LSA types
- Add object to LSDB table to indicate whether the LSA is locally
recognized
Acee Lindem: respond and then WG last call (before the next ietf
meeting)
----------------------------------------
-----------------------------------------
2) OSPF as the PE/CE Protocol in BGP/MPLS VPNs (10 Mins): Eric Rosen
<draft-rosen-ospf-2547bis-dn-00.txt>
Summary:
-------
o Overview: Scenario (Customer with multiple OSPF sites)
- Service Provider connects sites over a shared bgraphics/bone
- Not with tunnels but by using BGP to distribute customer routes from
site to site
- Use of BGP is transprent to customer, SP converts BGP routes to OSPF
(type 3, usually)
o Topology view (see slides, discussing CE and PE definitions)
Note: Eric also explains the problem under consideration, the
difference betweeen BGP and OSPF (no ASPath send accross CE-PE link)
defining the need for loopfree exchanges.
o Route Distributions:
- PE -> CE: Type 5 LSA (ASBR): use tag for avoiding looping
- PE -> CE: Type 3 LSA : LSAs can start to loop around
=> Looping can happen with LSA Type 5, or with LSA Type 3 exchanged over
PE-CE area 0 links.
o Proposed Solution (to prevent from looping)
- LSA Options field bit set when PE sends LSA's to CE
- Do not generate BGP updates when PE receives LSA's from CE with bit set
Discussions:
--------------------
- Acee Lindem: we have now 3 methods for loop avoidance: Route Tag, DN Bit
and for Intra-Area link (sham links)
- Eric Rosen: route tags can be eliminated in favor of the DN bit, but
sham links cannot be.
- Acee Lindem: Thus we would have two preferred methods: DN bit and sham
links.
- Eric Rosen: DN bit applies only to type 3/5 LSAs.
- Acee Lindem: The DN bit proposal will be revisited during the OSPF WG
charter discussion (note: see also below)
----------------------------------------
-----------------------------------------
3) Support of Address Families in OSPFv3 (15 Mins): Abhay Roy
<draft-mirtorabi-ospfv3-af-00.txt>
Summary:
-------
o Overview:
- What do we have today in OSPFv3 specification
- What does this draft propose
- What does this draft introduce
- Introduction of the capability in OSPFv3
- Interaction with non-AF capable routers
- Conclusion
o Problem Statement: What do we have today in OSPFv3 specification
- Router and Network LSAs carry only topology information
- Only IPv6 address family is currently defined
- IPv6-bit defined in Options field (can be used to include or
exclude a node in IPv6 address-family)
o What does this draft propose:
- Enhance the per node support of AF to per link support to allow a link
to be included or excluded explicitly in a given address-family
- To be used during SPF in order to have incongruent AF topologies
o What does this draft introduce:
- A new bit (AF bit) in the Options field in order to support this
feature (so routers supporting this draft must set this bit)
- An unused field in the Router-LSA is defined with Address
Familiies per link
- AddressFamiles field is defined as:
. each bit corresponds to an address-family (for the time being, only
the v6 AF bit has been defined)
. v6 AF bit must be set when a link participates in IPv6 topology
otherwise it must be cleared
. note: when a link participate in more than one AF, all of the
corresponding bits will be set
- A new LSA called AF-Functionality-LSA is defined to carry bits for
each address families (area flooding scope and U bit is set)
note: not needed for IPv6 AF (uses these bits from the
router-lsa hdr)
o Interaction with non-AF capable routers
o Conclusion:
- Enhances OSPFv3 address-family support from a per node to a per link
- It enables incongruent topologies for different
address-families
- Applications ?
Discussion:
----------
- Q1 (?): What about routers that do not support this feature ?
- Abhay Roy: new AF capability only available when supported
(obviously), here the bgraphics/ward compatibility applies to routers that would
support this feature
- Q1 (?): What happens if this capability is only supported on a
per-node basis
- Abhay Roy: you cannot build incongruent topologies
- Q1 (?): Your proposal doesn't seem to be *so* bgraphics/ward compatible
- Abhay Roy: (?)
- Ghesam: Step towards IS-IS and half-bit with few things missing
(metric) here ending with separated approaches - prefix itself carried in
different LSA's to be modified on a per family basis, apart from that i
don't have any specific issues with this proposal
- Abhay Roy: we don't have an urgent need for it today (no per link
support) and there is no possibility to have it in an easier way
- Padma: parallelism with M-ISIS, also OSPFv3 does it have to carry IPv4 ?
so it seems a bit too advanced with respect to the situation where we are
and where want to go
- Abhay Roy: Proposed implementation uses OSPF options bits, the debate
OSPFv2/OSPFv3 and IPv4/IPv6 is orthogonal here, also this feature is
useful in case of multicast topologies so it may become important in the
future
- Rohit Dube (to Abhay Roy): we allow for support of IPv4 in OSPFv3 and
multicast with this new capability, do you see any other
application(s) ?
- Abhay Roy: IPv6/Multicast may require new topology, also other address
families support than IPv6 might be needed ? but here the objective is to
enhance this capability from a per node to a per link
- Q2 (?): this capability is useful if you don't use the IPv6
proposal, thus suggest to wait for the first application before moving with
that; but moving forward seems to be a bad choice at this point in time
- Abhay Roy: agree, if we wait too long, new developments may need this and
the per link capability is the real motivation behind
- Rohit Dube: if needed better sooner than later but since we don't have any
application why bother to include this feature now ?
- Acee Lindem: mentions another problem (using RFC 1793, as example) where
the bgraphics/ward compatibility issue required more code than the real
feature, this aspect must also be taken into account when evaluating the
present feature
----------------------------------------
-----------------------------------------
4) WG document status (10 Mins): WG Chairs
o RFC 3101 - Open Shortest Path First (OSPF) "Not-So-Stubby Area" (NSSA)
Option is now published
o Traffic Engineering Extensions to OSPF Version 2: IETF wide last call
completed. Decision to defer IANA update should allow publication but it
will published at some point in time
o OSPF Hitless Restart has completed the WG last call and will be
udpated with clarifications based on the received comments (2 major
comments - see mailing list - will be addressed in this update)
o Detecting Inactive Neighbors over Demand Circuits - WG Last Call is
completed and document submitted to IESG
o Alternative OSPF ABR Implementations is in the RFC Publication Queue
o OSPFv2/v3 MIBs both to be refreshed with additional MIB variables
o Draft-ietf-ospf-scalability-02.txt should focus more on
implementation rather than simulations (note: suggest a shorter title)
o Authentication/Confidentiality for OSPFv3
(draft-ietf-ospf-ospfv3-auth-00.txt) requires more substantive
discussions to move forward
o TE extensions for ospfv3
(draft-ishiguo-ospf-ospfv3-traffic-02.txt) item added to the charter and it
will become a WG document (we have a clear consensus through the ospf
mailing list)
Discussions:
-----------
- Rohit: Any comments ? Any other issue on the drafts and their status ?
Note: no reactions or comments from the room/group
----------------------------------------
-----------------------------------------
5) WG Charter Update (15 Mins): WG Chairs
o OSPF as a PE/CE Protocol in BGP/MPLS VPNs
<draft-rosen-ospf-2547bis-dn-00.txt>
- Rohit Dube: PPVPN WG works on OSPF for a while now, the
recommendation here is to make it as part of the OSPF WG charter. Any
comment from ppvpn participating people?
o Support of Address Families in OSPFv3
<draft-mirtorabi-ospfv3-af-00.txt>
- Note: discussion seems a bit pre-matured, no comments
o Optional Router capabilities
<draft-raggarwa-igp-cap-01.txt>
- Kireeti Kompella: it seems that we take the proposed drafts and
include them in the charter rather than producing drafts from charter
items
- Rohit Dube: agrees
- Kireeti Kompella: gives examples such as AF families coverage and
multiple topologies
- Acee Lindem: DN bit is to be added in the charter ? any objection ?
anyone opposed ? Not an overhwhelming interest but due to the
interaction with the PPVPN WG this item might come into
consideration
- Kireeti Kompella: Charter should say we want to interface with PPVPN WG
since also sham links and others specific proposals related to the PPVPN WG
are currently under discussion, so PPVPN WG does some work asking some
change to OSPF.
Kireeti argues in favor of larger charter items coverage rather than
specific items to be covered
- Rohit Dube: work items listed are managed and this does not go
against inclusion of larger items within the charter of the OSPF working
group
- Alex Zinin: agrees with the relevance of the Kireeti's
intervention, for the OSPF WG to extend the charter, the OSPF WG first
needs to be in agreement that the group wants to extend than charter and
then bring it to the IESG
o OSPF flooding and refresh reduction in stable topologies
<draft-pillay-esnault-ospf-flooding-04.txt>
- Rohit Dube: OSPF Flooding reduction in stable topologies, either we
keep it or leave it?
- Padma: sent an update which addresses comments received from
Acee/Alex and she wants to see it going on and moving forward
- Rohit Dube: for a couple of documents we want to be a bit more strict
- Acee Lindem: target as PS initially, now it seems that
informational is more appropriate
- Padma: i am open to any proposal, it could be a proposed standard
since not invalidating OSPF and just want to go forwad and close this item
- Acee Lindem: implementation are available, as opposed to DC we
propose here to go for informational (this i-d doesn't really build
something new on top of RFC 1793)
- Alex Zinin: pointing to this discusion, some discussions with SP's show
that they are concerned with this draft that proposes to disable any LSA
advertisement
- Padma: only LSA refreshes are disabled by the Do Not Age (DNA) bit, LSA
triggering still occurs independently of the DNA bit setting
- Alex Zinin: LSA flooding rules shouldn't be stopped unless LSAs goes
over the DC link, this method is not for application in case of
"normal" (i.e. non-DC) link
- Padma: we will take this discussion offline
- Alex Zinin: DNA bit applicability won't go any further, all
interfaces are DC interfaces so only flooded to the nearest neighbor
- Acee Lindem: applicable if there are DC links otherwise not further
flooded, agrees to take the discussion on the mailing list
o Bgraphics/ to Optional Router capabilities
- Acee Lindem: is there a consensus to move forward with this item ?
- Acee Lindem: seems there is a disagreement until really needed (Acee
also indicates that he is co-authoring this i-d but mentions that he sees
one application for this i-d being the Path Computation Server - PCS)
- Kireeti Kompella: PCS should be seen "as part" of the CCAMP WG
charter but is not there today since we need first to include
inter-area routing in the CCAMP WG charter; at that point PCS approach
might be seen as a potential item
- Rohit Dube: we wait until the CCAMP WG decides, so OSPF WG won't take
any decision for the time being
- Jean-Philippe Vasseur: MPLS WG also deals with the management of TE
LSPs
- Rohit Dube: then let's wait until MPLS working group decides
- Rohit Dube: do we have any other option than 1) wait for
CCAMP/MPLS WG outcomes or 2) define the capabilties that some
application would use in the future
- Acee Lindem: anybody else than the authors is interested in this i-d ?
- Rohit Dube: it seems there is a very weak interest at this point in
time
o Bgraphics/ to Support of AF in OSPFv3
- Rohit Dube: same question for the Support of AF in OSPFv3. Poll for
people that would like to see this item as part of the woking group
charter?
Note: this i-d doesn't seem to receive a lot of support from the group to
work on this item
o Bgraphics/ to Optional Router capabilities
- Rohit Dube: same question for the IGP Capabilities. Poll for people
that would like to see this item as part of the woking group charter ?
Note: no consensus on draft-raggarwa-... (due to room silence)
- Rohit Dube: discussion on the mailing list will start once bgraphics/ from
this IETF meeting
- Acee Lindem: meeting is adjourned
========================================
====================
===============================
|
