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
- transit policy syntax msteenst
- transit policy syntax Robert Woody Woodburn
- transit policy syntax Tony Li