transit policy syntax

Tony Li <tli@cisco.com> Mon, 11 May 1992 22:13 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa11473; 11 May 92 18:13 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa18200; 11 May 92 18:18 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa18195; 11 May 92 18:18 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa19988; 11 May 92 17:50 EDT
Received: from BBN.COM by PARK-STREET.BBN.COM id aa19984; 11 May 92 17:49 EDT
Received: from lager.cisco.com by BBN.COM id aa01396; 11 May 92 17:45 EDT
Received: by lager.cisco.com; Mon, 11 May 92 14:44:50 -0700
Date: Mon, 11 May 92 14:44:50 -0700
From: Tony Li <tli@cisco.com>
Message-Id: <9205112144.AA19790@lager.cisco.com>
To: RobertWoodburn <woody@sparta.com>
Cc: msteenst@bbn.com, tli@cisco.com, idpr-wg@bbn.com
In-Reply-To: Robert "Woody" Woodburn's message of Mon, 11 May 92 17:45:40 -0400 <9205112145.AA01183@crusher>
Subject: transit policy syntax

   I think that using the attributes scheme I described earlier would
   improve the extensibility of policy messages.

   Tony, would this help any, or do you see a more basic problem?  I
   would think that as long as attributes are independent of each
   other, then a route server could use attributes that it recognized
   and just ignore the others.  However, I'm not sure that works
   entirely either, since some of those attributes describe specific
   conditions to which the policy term applies.  Unless the RS
   understood the attribute, it would probably go off calculating
   nonsense.  But this would be caught by setup.  At least the route
   server would have something it could understand and try a
   computation with, rather than discarding the entire update.

I think that this would certainly be on way to address the problem.

Tony