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

[Daniel Joyal <[e-mail]>]

> -----Original Message-----
> From: Acee Lindem [mailto:[e-mail]]
> Sent: Wednesday, April 30, 2003 3:26 PM
> To: [e-mail]
> Subject: Re: Working Group Last Call for
> draft-ietf-ospf-mib-update-06.txt
>
>
> Daniel Joyal wrote:
> >
> >
> >  > -----Original Message-----
> >  > From: Acee Lindem [mailto:[e-mail]]
> >  > Sent: Wednesday, April 30, 2003 11:37 AM
> >  > To: [e-mail]
> >  > Subject: Re: Working Group Last Call for
> >  > draft-ietf-ospf-mib-update-06.txt
> >  >
> >  >
> >  > 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
>
> >
> > -Dan
> >
> >  >
> >  > Thanks,
> >  > --
> >  > Acee
> >  >
> >
>
>
> --
> Acee
>