Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 11 Nov 2002 10:17:08 -0500

At 03:28 PM 10/15/2002 -0700, Elwin Eliazer wrote:
>Hi Joan,
>
>Thanks for your very valid comments.
>Excuse us for the delay in responding.
>My responses are in-lined below.
>
>Cheers,
>Elwin.
>
>-----Original Message-----
>From: Joan Cucchiara [mailto:[email-masked]]
>Sent: Thursday, October 10, 2002 11:13 AM
>To: [email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Subject: questions on draft-ietf-ppvpn-vr-mib-02.txt
>
>
>Hello,
>
>A few questions and comments on the MIB.
>
>1) Is the Internal Virtual Link used to connect to VRs in
>the same PE, or is it a link between VRs in a different PEs?
>
>Elwin> It is for VRs in the same PE.
>
>
>2) Is there a one to many relationship between the vrTunnelIpAddress
>and the Virtual Routers?
>
>Elwin> One to many is possible for the cases of tunnels having a
>Elwin> demultiplexing field.

         Is this field defined anywhere in PPVPN documents?  If not,
then please do not support this relationship in the MIB unless
there is strong opinion from the WG. This is the sort of thing that
can get standard MIBs in trouble for interoperability.

>3) do you want any scalars to configure the number of VRs on
>    the device?
>
>Elwin> That will be nice to add.

         Knowing the number of active ones is always helpful instead
of having to determine that from a MIB walk (especially if the
number of VRs is large).

>4) regarding VPN-ID, have you considered adding some sort of
>    mapping table to which is indexed by VPN-ID, VR?
>
>
>Elwin> This could be for quick searching. Inverse VPN/VR table??
>Elwin> Sure...That sounds okay.

         Consider making the implementation of these tables optional
and only the basic table mandatory.  Sometimes mapping tables are
nice to have, but they put an unnecessary burden on initial implementations
that might want to just get the base objects implemented.

>5) Having a TC called VrIndexOrZero which is like the above but
>    includes zero, where zero needs to be defined in the Description
>    Clause of the objects
>
>     * for VrConfigNextAvailableVrId have zero mean that no more VRs
>       can be created.  (for example, if the device is out of resources)
>
>     * for vrId have zero mean that VR 0 is the NULL VR.
>
>Elwin> Good suggestion.
>
>6) Limit the vrName to fewer characters (32 is probably good, but
>    could be bigger.  255 seems quite large).  This description
>    should probably say these names need to be unique within the table.

         32 characters might not be long enough.  Is there anything
in the VR specification for this? If not, perhaps it should be
added?  Having the MIB guess on something like this could be
a problem if the protocol later allows the use of a 33 character
name.  In the least, the variable should include a reference to
a protocol/architecture specification justifying its size.

>Elwin> agreed.
>
>7) vrAdminStatus: could testing be added here?
>
>Elwin> Sure.

         What does testing mean?  Be specific if you can.

>8) vrContextName - why is this a read-create and not a read-only?
>
>Elwin> This allows the user to specify the VR context, or community,
>Elwin> for the particular VR being created.  If it were read-only, this
>Elwin> would mean the device is creating the context for the VR.
>
>9) vrType, not clear what this is, could more description be added?
>
>Elwin> This has to be removed.
>
>10) (minor) please change the vrStat to be vrStatus
>
>Elwin> will do.
>
>11) RouterId should this be  2 objects ( AddressType and Address )
>     (as in the INET-ADDRESS-MIB).
>
>Elwin> good point.
>
>12) have you considered having the VrIfTable indexed by
>     vrId and vrIfIndex ?  (seems like a VR would want to quickly
>     see all of its interfaces).
>
>Elwin> No, a VR is identified by the community string itself.
>Elwin> We are suggesting managing multiple instances of the
>Elwin> "VrIfTable" using a model similar to that described in RFC2571.

         This is not very standard and runs into all sorts of problems.
For instance, how does one format the community string?  What
are the security implications?

>13) vrUp/vrDown traps need to contain a varbind.  The vrId is an index.
>
>Elwin> No, the vrId MAX-ACCESS is defined as accessible-for-notify.

         Why? You generally only use accessible-for-notify if you
have an index that comes from another module that you want to
include. In this case, it is beneficial to just include one of the
objects from the table -- perhaps VrName -- that will implicitly
include the index?  Also, I strongly suggest adding a rate limiting
value for notifications such as we have defined recently in the
MPLS-TE MIB called mplsTunnelNotifMaxRate.

         --Tom

Success is relative; the more success, the more relatives. -Anonymous

---

From: "Sam Hancock" <[email-masked]>
Date: Mon, 11 Nov 2002 11:47:37 -0800

Hello All,
I added some comments for item 13.
Cheers,
Sam>

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Monday, November 11, 2002 7:17 AM
To: Elwin Eliazer
Cc: [email-masked]; [email-masked]; Sam Hancock;
[email-masked]
Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt

         Why? You generally only use accessible-for-notify if you
have an index that comes from another module that you want to
include. In this case, it is beneficial to just include one of the
objects from the table -- perhaps VrName -- that will implicitly
include the index?
[<Sam>] Actually, the value "accessible-for-notify" indicates an object
[<Sam>] which is accessible only via a notification [RFC1902].  Since the 
[<Sam>] vrName could be NULL, the vrId is more appropriate to include in
[<Sam>] the traps.

Also, I strongly suggest adding a rate limiting
value for notifications such as we have defined recently in the
MPLS-TE MIB called mplsTunnelNotifMaxRate.

[<Sam>] Adding control for Rate limiting is a good idea.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 11 Nov 2002 15:02:15 -0500

>[<Sam>] vrName could be NULL, the vrId is more appropriate to include in

         I understand the meaning of accessible-for-notify. It is
generally a better idea to not use it in cases where you can
just send an object in the varbind that has additional information,
since the same index is also transmitted in the varbind.

         --Tom

---

From: "Sam Hancock" <[email-masked]>
Date: Mon, 11 Nov 2002 12:18:31 -0800

> Sent: Monday, November 11, 2002 12:02 PM
> To: Sam Hancock
> Cc: Elwin Eliazer; [email-masked]; 
> [email-masked];

[<Sam>]  This is a good point.  Even if the vrName were NULL,
[<Sam>]  the vrId would be implicitly transmitted in the varbind.
[<Sam>]  Therefore, using vrName is a better option than using vrId.