Tom Petch <nwnetworks <at> dial.pipex.com>
2006-06-07 10:25:49 GMT
----- Original Message -----
From: "Adrian Farrel" <adrian <at> olddog.co.uk>
To: <mpls <at> lists.ietf.org>
Cc: "Thomas D. Nadeau" <tnadeau <at> cisco.com>
Sent: Thursday, June 01, 2006 12:59 AM
Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt
> We have put together a first (somewhat rough) stab at defining a MIB module
> for P2MP MPLS-TE and for describing how the existing MPLS-TE MIB modules are
> used in support of P2MP MPLS-TE. Hopefully the existence of this I-D will
> help the P2MP MPLS-TE solutions work along its path to becoming an RFC.
> Please review, comment, implement (!) and tell us what we have done wrong.
Looks good, impressive even for a rough stab
Some minor doubts
1) Why is mplsP2mpTunnelSubGroupIDNext limited to (0..65535) when
mplsP2mpTunnelSubGroupID has a range of (1..4294967295)?
2) mplsP2mpTunnelDestEntry has an awesome INDEX which is fine but I think that
the two InetAddress - mplsP2mpTunnelSubGroupOrigin and
unnelDestination - need SIZE constraints in order to keep SMI happy.
3) mplsP2mpTunnelBranchOutSegment is of SYNTAX MplsIndexType ie OCTET STRING
so the special values should be 'single octet with the value 0x00' as in
4) I wonder if the meaning of the special value "that MIB module is inaccessible
or not implemented." is not too strict. Could there not be other circumstances
when the table as a whole is accessible but the relevant row is not?
5) mplsP2mpTunnelDestCreationTime should reference sysUpTime.
6) Several Counter32 have a DESCRIPTION
"Specifies the number of times the ..."
I never like 'specifies' sinces it begs the question of since when, and being a
counter, there is no when. Counters, by definition, are only meaningful when
read more than once and differenced. (RFC3813, along with other Mib Modules,
avoids this word).
7) Again on counters, particularly for mplsP2mpTunnelBranchPerfEntry, should
there be a discontinuity object?
8) I am puzzled why mplsP2mpTunnelDestUp and mplsP2mpTunnelDestDown are defined
in terms of down state. It means, for example, that the transition from down to
testing or lowerLayerDown would generate an Up NOTIFICATION; odd.
9) mplsP2mpTunnelDestOperStatus lacks values 5 and 6; I suggest adding a note
that this enumeration is in line with RFC3812 where those values are in use.
mpls mailing list
mpls <at> lists.ietf.org