Subject: Re: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

From: "Tom Petch" <[email-masked]>
Date: Tue, 6 Jun 2006 12:18:32 +0200

I am curious about the choice of prefix for these object descriptors, a mix of
mplsTe
mplsP2mp
mplsMP2p
I find this hard to follow and would prefer a single prefix (although I realise
there are ample precedents in MPLS:-)  - is there an underlying logic?

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Thomas D. Nadeau" <[email-masked]>
Sent: Thursday, June 01, 2006 12:59 AM
Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

> Hi,
>
> 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.
>
> Cheers,
> Adrian
>
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, May 31, 2006 8:50 PM
> Subject: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt
>
>
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> >
> > Title : Point-to-Multipoint Multiprotocol Label
> >                          Switching (MPLS) Traffic Engineering (TE)
> >                          Management Information Base (MIB) module
> > Author(s) : A. Farrel, et al.
> > Filename : draft-farrel-mpls-p2mp-te-mib-00.txt
> > Pages : 36
> > Date : 2006-5-31
> >
> >   This memo defines a portion of the Management Information Base
> >   for use with network management protocols in the Internet community.
> >   In particular, it describes managed objects for point-to-multipoint
> >   Multiprotocol Label Switching-based traffic engineering.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-farrel-mpls-p2mp-te-mib-00.txt
> >

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 6 Jun 2006 17:51:01 +0200

Hey it compiles cleanly so stop complaining! *)

	Yes, we will make the prefixes consistent.

	--Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 7 Jun 2006 02:08:43 +0100

Tom,

> there are ample precedents in MPLS:-)  - is there an underlying logic?

The (impeccable) logic is simply that when you bash out code in a hurry you 
make some errors in things like naming.

Adrian

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 7 Jun 2006 12:25:49 +0200

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Thomas D. Nadeau" <[email-masked]>
Sent: Thursday, June 01, 2006 12:59 AM
Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt
> 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
RFC3813.

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.

Tom Petch

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 7 Jun 2006 17:23:07 +0100

Hi Tome,

> mplsP2mpTunnelSubGroupID has a range of (1..4294967295)?

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

> unnelDestination          - need SIZE constraints in order to keep SMI 

Probably right. And a good thing anyway.

> so the special values should be 'single octet with the value 0x00' as in

Good catch

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

> read more than once and differenced.  (RFC3813, along with other Mib 

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

> there be a discontinuity object?

Yes.

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

> that this enumeration is in line with RFC3812 where those values are in 

Yes.

Very many thanks.
Adrian