The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Tome,

> Some minor doubts
>
> 1) Why is mplsP2mpTunnelSubGroupIDNext limited to (0..65535) when
> mplsP2mpTunnelSubGroupID has a range of (1..4294967295)?

Because I changed the size of SubGroupID and forgot about IDNext.

> 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.

Probably right. And a good thing anyway.

> 3)  mplsP2mpTunnelBranchOutSegment  is of SYNTAX MplsIndexType ie OCTET 
> STRING
> so the special values should be 'single octet with the value 0x00' as in
> RFC3813.

Good catch

> 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?

Hmmm. Not sure. I guess this requires a careful parse of the compliance in 
that module.

> 5) mplsP2mpTunnelDestCreationTime should reference sysUpTime.

Yes.

> 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).

Actually, I probably cutted and pasted this from one of the MPLS MIB 
modules.
But you are right.

> 7) Again on counters, particularly for mplsP2mpTunnelBranchPerfEntry, 
> should
> there be a discontinuity object?

Yes.

> 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.

Good thing to be puzzled about.
I was aiming for consistency with the MPLS TE MIB module.

> 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.

Yes.


Very many thanks.
Adrian



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls