Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt

From: Don Goodspeed <[email-masked]>
Date: Mon, 28 Apr 2003 18:49:24 -0400

All,

From my review of the diff's file between these two revisions,
I have one specific comment and two general comments.

1. (specific comment)  At the end of page 17, the description for
the new ospfStubRouterAdvertisement attribute needs to end with a
double-quote.  I see an o with an umlaut above it.

2. (general comment)  In the description for all of the new restart
objects and notifications, replace the text "hitless restart" with
"graceful restart".  This reflects the recent name change of that
draft from Acee's last update (Graceful OSPF Restart).

3. (general comment)  All in all, the objects, their definitions,
etc., look well thought out and well-defined.  In my last email
on this MIB, I suggested including all the needed items to
"complete" this MIB update per most common implementations and per
the most recent drafts.  I think we've met this goal.

Thanks for moving this forward,
Don Goodspeed

--- On Wed 04/23, Acee Lindem < [email-masked] > wrote:
From: Acee Lindem [mailto: [email-masked]]
To: [email-masked]
Date: Wed, 23 Apr 2003 14:30:00 -0400
Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt

We've decided do another revision of this draft prior to WG<br>last call. If you forward comments quickly (I don't have an<br>exact date), they can be incorporated into the next revision.<br><br>Thanks,<br>Acee<br><br>Acee Lindem wrote:<br>> This is the start of a Working Group last call for<br>> draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 Management<br>> Information Base. All comments must be received by Wednesday,<br>> May 7th, 2003.<br>><br>> This document reached the AD review phase once before but<br>> we decided to add MIB support for recent OSPF extensions.<br>><br>><br>> A URL for this Internet-Draft is:<br>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt<br><br><br>--<br>Acee<br>

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

---

From: Daniel Joyal <[email-masked]>
Date: Tue, 29 Apr 2003 09:57:59 -0400

Version -06 of the OSPFv2 MIB update includes:

- 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)
- Change status of RFC 1850 compliance and conformance groups from
"deprecated" to
  "current"
- Add support for Graceful Restart

Pending updates for version -07

- Configuration objects to support detection of inactive neighbors
- Resolution of issues raised by IESG's OAM expert reviewer on version -05
- Remaining open issues on traps
- Add section on MIB support for multiple OSPF instances
- Fix smilint errors/warnings
- Fix ospfStubRouterAdvertisement Description clause per Don's comment
- Change "hitless restart" to "graceful restart" per Don's comment
- Any additional issues from WG

-Dan

> -----Original Message-----
> From: Don Goodspeed [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 6:49 PM
> From my review of the diff's file between these two
> revisions, I have one specific comment and two general comments.
>
> 1. (specific comment)  At the end of page 17, the description
> for the new ospfStubRouterAdvertisement attribute needs to
> end with a double-quote.  I see an o with an umlaut above it.
>
> 2. (general comment)  In the description for all of the new
> restart objects and notifications, replace the text "hitless
> restart" with "graceful restart".  This reflects the recent
> name change of that draft from Acee's last update (Graceful
> OSPF Restart).
>
> 3. (general comment)  All in all, the objects, their
> definitions, etc., look well thought out and well-defined.
> In my last email on this MIB, I suggested including all the
> needed items to "complete" this MIB update per most common
> implementations and per the most recent drafts.  I think
> we've met this goal.
>
> We've decided do another revision of this draft prior to
> WG<br>last call. If you forward comments quickly (I don't
> have an<br>exact date), they can be incorporated into the
> next revision.<br><br>Thanks,<br>Acee<br><br>Acee Lindem
> wrote:<br>> This is the start of a Working Group last call
> for<br>> draft-ietf-ospf-mib-update-06.txt, OSPF Version 2
> Management<br>> Information Base. All comments must be
> received by Wednesday,<br>> May 7th, 2003.<br>><br>> This
> document reached the AD review phase once before but<br>> we
> decided to add MIB support for recent OSPF
> extensions.<br>><br>><br>> A URL for this Internet-Draft
> is:<br>>
http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt<br><br
><br>--<br>Acee<br>

---

From: Daniel Joyal <[email-masked]>
Date: Wed, 30 Apr 2003 16:07:09 -0400

> From: Acee Lindem [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 3:26 PM
> Daniel Joyal wrote:
> >  > From: Acee Lindem [mailto:[email-masked]]
> >  > Sent: Wednesday, April 30, 2003 11:37 AM
> >  > Jeff Parker wrote:
> >  > >>>What other TE stuff would we need?
> >  > >>
> >  > >> From a configuration standpoint, there is also TE
> color. From a
> > > >>monitoring standpoint, there is all the bandwidth state.  > How
> > did ISIS  > >>handle this?
> >  > >
> >  > >
> >  > > IS-IS doesn't configure TE information, anymore than it
> >  > configures the
> >  > > MTU.  It just finds stuff through some implementation
> >  > dependant method
> >  > > and reports it.
> >  > >
> >  > > This is visible through the LSP Database (Link State
> PDU, not Label
> >  > > Switched Path) which allows someone to see what is
> being flooded.
> >
> > Likewise for OSPF through the TE LSAs in the Area LSDB Table.
> >
> >  >
> >  > Sounds reasonable. So why would we want to allow
> >  > configuration or visibility of TE information in the OSPF MIB?
> >
> > I think we might want to configure protocol-specific TE
> information in
> > the protocol MIBs and non-protocol-specific information in
> the TE MIB.
> > Both the IS-IS MIB and the updated OSPF MIB currently support the
> > configuration of the enabling/disabling of TE for the protocol.
> >
> > isisSysLevelTEEnabled OBJECT-TYPE
> >         SYNTAX TruthValue
> >         MAX-ACCESS read-create
> >         STATUS current
> >         DESCRIPTION
> >             "Do we do Traffic Engineering at this level?"
> >         DEFVAL { false }
> >     ::= { isisSysLevelEntry 9 }
> >
> > ospfTrafficEngineeringSupport OBJECT-TYPE
> >         SYNTAX       TruthValue
> >         MAX-ACCESS   read-write
> >         STATUS       current
> >         DESCRIPTION
> >            "The router's support for OSPF traffic engineering."
> >         ::= { ospfGeneralGroup 17 }
> >
> > In the "Traffic Engineering Extensions to OSPF Version 2" document,
> > the traffic engineering metric sub-TLV seems to be specific
> to OSPF.
> > From section 2.5.5.
> >
> >    "The Traffic Engineering Metric sub-TLV specifies the
> link metric for
> >    traffic engineering purposes.  This metric may be
> different than the
> >    standard OSPF link metric.  Typically, this metric is
> assigned by a
> >    network admistrator."
> >
> > Similarly, the "IS-IS extensions for Traffic Engineering" document
> > defines sub-TLV 18.  From section 3.7.
> >
> >    "This sub-TLV contains a 24-bit unsigned integer.  This metric is
> >    administratively assigned and can be used to present a
> differently
> >    weighted topology to traffic engineering SPF calculations."
> >
> > As Don suggested, these might be candidates for a new configuration
> > objects in the protocol MIBs. Bandwidth, Admin Groups, etc. are
> > covered in the TE MIB.  draft-ietf-tewg-mib-04.txt
>
> Okay - I'm not strongly opposed. However, I took a look at
> the TE MIB (draft-ietf-tewg-mib-04.txt) and its tunnel table
> is relative to a complete TE'ed path (e.g., LSP). Whereas,
> the OSPF TE stuff applies to a specific interface. It almost
> seems to me like all this TE stuff should be included or go
> in a separate MIB. The problem with included it is that the
> extensions go on an on.
>

If we want to go with a separate OSPF TE MIB, that's OK. I'll
remove the ospfTrafficEngineeringSupport object from the next
revision of the OSPF MIB draft. I think someone in the WG once
volunteered to write a TE MIB for OSPF.

-Dan
> >  > Thanks,
> >  > --
> >  > Acee
> --
> Acee