Subject: RE: draft-ietf-l3vpn-vr-mib-03.txt

From: "Schliesser, Benson" <[email-masked]>
Date: Mon, 3 Jan 2005 13:57:07 -0600

Ron-

Thanks for these comments/questions. I hope the other contributors will
comment with any of their own thoughts, but here are mine.

> 1) The draft is based upon the premise that a single SNMP 
> agent should represent every virtual router on a physical 
> router. An alternative approach would be to deploy a separate 
> SNMP agent for each virtual router. Have you explored that 
> option? If so, why did you reject it? Had you chosen that 
> option, would a vr-mib be required at all?
> 
> (I honestly don't know which alternative is better. I'm just 
> checking to see that the alternative was explored.)

Creating multiple agents for use by the administrator (SP) could be
done, for instance by binding to different ports or addresses on the
P-node. But from a resource perspective, it is more efficient to use a
single agent and multiplex based on the community/context as described
in the draft. In either case, though, a VR-MIB is needed to map each VR
to its respective agent or context.

There is one case that I'd like to point out, where a separate agent per
VR is useful, though not as a replacement for the VR-MIB. If the
platform supports instantiation of an agent *within* the VR then the VPN
user could query stats, etc., from that agent. This isn't a replacement
for the VR-MIB because (in addition to the above points) the SP may very
well not have reachability/connectivity (not to mention uniqueness in
addressing) into the VPN. I.e., the SP may not have management-network
access to the customers' networks.

> 2) The vr-mib goes to some length the support configuration 
> using SNMP.
> Other MIBs tend to be for monitoring purposes, with an 
> occasional read-write variable. Do you see this MIB being 
> used much for configuration?

I, speaking as one SP, intend to use it only for monitoring. This is
largely because I have other mechanisms available for configuration of
my platforms, such as Corba or XML interfaces, that I find more valuable
for this function.

However, I see value in having configuration capabilities in the MIB.
The VR-MIB fills in a gap, allowing for creation of the VR, while the VR
context MIBs allow for configuration of the VR itself. This might prove
useful, perhaps even allowing for interoperable management tools.

Is there perhaps a precedent for better stating the requirement levels
such that configuration functionality is not a MUST? This might satisfy
both perspectives.

> 3) The document has a few formatting problems (e.g., section 
> numbering).
> Please see http://www.ietf.org/ID-Checklist.html

We'll clean things up. We should also include some text relating to the
above discussion.

Thanks,
-Benson