Re: IDPR MIB

Kenneth Carlberg <carlberg@cseic.saic.com> Tue, 05 January 1993 22:09 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10224; 5 Jan 93 17:09 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10220; 5 Jan 93 17:09 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa18891; 5 Jan 93 17:09 EST
Received: from pizza by PIZZA.BBN.COM id aa07215; 5 Jan 93 17:05 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa07211; 5 Jan 93 17:04 EST
Received: from CSEIC.SAIC.COM by BBN.COM id aa10223; 5 Jan 93 17:04 EST
Received: from caspian.cseic.saic.com by cseic.saic.com (4.1/1.34) id AA06781; Tue, 5 Jan 93 17:00:12 EST
Date: Tue, 5 Jan 93 17:00:12 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Kenneth Carlberg <carlberg@cseic.saic.com>
Message-Id: <9301052200.AA06781@cseic.saic.com>
To: dlee@erg.sri.com
Subject: Re: IDPR MIB
Cc: idpr-wg@bbn.com

> A point can be made that all status objects have only local
> implementation significance

i take it you mean local to the domain, as opposed to a VG or a PG.

> However, having a status object allows the network manager to view,
> modify, or delete a policy without using a separate out-of-SNMP-band
> channel.  This seems to be a nice feature to me.

i agree.

> > I still have fundamental problems with the idea of modifying
> > configuration between restarts without changing the config file, unless
> > we change the implementation to also dump a config file back out when a
> > change is made.
>
> If we permit the network manager to only change the state from active
> to inactive and do not allow dynamic instantiation of new policies,
> then trying to keep consistent configuration databases is probably
> less of an issue.

Personally, I would extend the capability to *modifying* a policy. An
example that runs through my head is a stub domain that is connected to
two providers (transit domains) - one VG per provider:

	transit-1		 Transit-2
		\		    /
		 VG-1		 VG-2
		  \		  /
		   \_____stub____/
	
In my example, I have a set of policies that pertain to each VG 
(ie. each entry/exit point of my stub domain). 
These sets of policies would not change under 
normal circumstances (whatever they may be). But if per chance, one
provider is (temporarily) having serious problems and I can't send 
traffic through it, then it would seem like a nice idea to alter
the VG portion, for example, of a policy (or the on/off that you 
talk about) on the fly as opposed to making a definitive change in 
the policy files.

In other words, I would like to view the policy files as a static
entity, and change things on the fly as the need arises. In this
manner, I don't have to remember what my original policies are
when things go to normal because I will never have changed my original
set of policies.

my $0.02

-ken