[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIB Doctor (architectural) review needed
On Thu, 4 Dec 2003, Wijnen, Bert (Bert) wrote:
> Document: draft-ietf-pwe3-arch-06.txt
>
> Section 8 has a "architectural overview" of how PWE3 related
> MIBs fit in their architecture. We may want to check this out.
>
> It is on IESG agenda today (Dec 4th)... so probably too late
> to feed any comments into the telechat today. I will take a defer
> so we as MIB doctors can do EARLY review instead of LATE review.
Apart from the editorial comments discussed in yesterday's e-mail
message, the only issue of an archirectural nature that I have with
the material in sections 8.1 and 8.2 of draft-ietf-pwe3-arch-06.txt
is that there is no mention of the role of the IF-MIB. The main
reason that this is a concern is that the IF-MIB is usually a
prerequisite for the MIB modules that the manage native services
(such as SONET or Ethernet) that run over a PWE3 pseudo-wire, and it
is necessary for the PWE3 service layer MIB modules that work in
conjunction with the native service MIBs modules to take that fact
into account. It seems that most, but not all, of the existing PWE3
MIB modules got this right; so it's not clear to me whether it's
necessary to burden the architectural document with extra text, or
whether diligent review of the MIB modules themselves will suffice.
In order to get a feel for this issue I did a mini-review of the
following drafts(*) to look at how the relationship with the IF-MIB
is handled:
draft-ietf-pwe3-enet-mib-02.txt Ethernet Service MIB
draft-ietf-pwe3-cep-mib-03.txt SONET Service MIB
draft-ietf-pwe3-pw-tc-mib-02.txt PWE3 TC MIB
draft-ietf-pwe3-pw-mib-01.txt PWE3 MIB
draft-ietf-pwe3-pw-mpls-mib-03.txt PWE3 over MPLS MIB
The PW-MIB (draft-ietf-pwe3-pw-mib-01.txt) that manages generic PWE3
virtual circuits explicitly does not use an ifTable entry for each
VC. It states that if there is an ifTable entry corresponding to a
VC then the mapping is done in a PWE3 service layer MIB module,
e.g., the PW-CEP-STD-MIB (draft-ietf-pwe3-cep-mib-03.txt) or the
PW-ENET-MIB (draft-ietf-pwe3-enet-mib-02.txt) or in a VC layer MIB
module such as PW-MPLS-MIB (draft-ietf-pwe3-pw-mpls-mib-03.txt).
That's all OK.
I don't know enough about the underlying MPLS MIB modules to tell
whether the ifIndex usage in draft-ietf-pwe3-pw-mpls-mib-03.txt is
consistent with those MIB modules, but I did not see anything that
raised any red flags.
The ifTable usage in draft-ietf-pwe3-enet-mib-02.txt does seem to be
consistent with all of the companion MIB modules. In cases where
the EtherLike-MIB would be used pwVcEnetPortIfIndex would point to
an interface of type ethernetCsmacd(6).
The ifTable usage in draft-ietf-pwe3-cep-mib-03.txt, on the other
hand, does seen to have some problematic aspects. On the one hand,
the introduction says:
The model for CEP management is a MIB. The CEP MIB described in this
document works closely with the MIBs described in [PWMIB] and the
textual conventions defined in [PWTC]. In the spirit of the [IFMIB],
a CEP connection will be a pseudo-wire (PW), and will therefore not
be represented in the ifTable.
whereas Section 6.2, "CEP configuration Step by Step" says:
Configuring a CEP PW involves the following steps.
First create an entry in the pwVcTable and configure the PSN tunnels:
- Follow steps as defined in [PWMIB].
Configure the SONET Path parameters:
- Set the SONET path width in the sonetPathCurrentTable [SONETMIB].
- Set the SONET path index and the SONET path starting time slot in
the pwVcCepTable.
Looking in the pwVcCepTable we find the object pwVcCepSonetIfIndex,
which is of type InterfaceIndexOrZero. If it is of type
sonetPath(50) or sonetVT(51), then it points to approiate rows in
the SONET-MIB path or VT tables (e.g., sonetPathCurrentTable or
sonetVTCurrentTable). So far, so good; this follows the model in
the architecture documents that is appropriate for structured SONET
circuit emulation, where the interface device terminates the section
and line layers (and possibly the path layer) and paths or VTs are
extracted and transmitted via PWE3 VCs, with all the SONET entities
managed by the SONET-MIB. However, the DESCRIPTION clause of
pwVcCepSonetIfIndex also allows it to be "the ifIndex of the
physical port emulated in VT mode if the VT to be emulated is
directly feeded from a physical interface." That is NOT consistent
with the instructions in Section 6.2, as such a signal would NOT be
managed via the SONET MIB, nor would it make sense to set
pwVcCepSonetTimeSlot to associate a SONET time slot or VT tributary
number with the VC. It's not entirely clear to me whether this is
just a case of a MIB module that needs some editorial cleanups or
whether it is in fact inconsistent with the MIB architecture set
forth in draft-ietf-pwe3-arch-06.txt; this is part of what caused
me to question whether it might not be wise to include some language
in the architecture document requiring that PWE3 service MIBs
respect the ifTable usage mandated by any native service MIB whose
use they require.
Comments?
//cmh
---
(*) Note that draft-ietf-pwe3-pw-tc-mib-02.txt and
draft-ietf-pwe3-pw-mib-01.txt are expired drafts. The IETF I-D
repository does contain -03 versions but those are just expiration
notices so I went to retrieve the -02 versions from
http://www.watersprings.org/pub/id/index-all.html It turned
out that draft-ietf-pwe3-pw-mib-02.txt contained the wrong
MIB module, so I retrieved the -01 version of this draft in order
to proceed with this review.