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

[Acee Lindem <[e-mail]>]

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.


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


--
Acee