transit policy syntax
Robert Woody Woodburn <woody@sparta.com> Mon, 11 May 1992 22:08 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa11466;
11 May 92 18:08 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17944;
11 May 92 18:13 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa17935;
11 May 92 18:13 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa19977;
11 May 92 17:49 EDT
Received: from BBN.COM by PARK-STREET.BBN.COM id aa19973; 11 May 92 17:48 EDT
Received: from SPARTA.COM by BBN.COM id aa01267; 11 May 92 17:41 EDT
Received: from crusher.SPARTA.COM by sparta.com (5.65/1.34)
id AA24820; Mon, 11 May 92 17:45:44 -0400
Received: by crusher (5.65/1.34)
id AA01183; Mon, 11 May 92 17:45:40 -0400
Date: Mon, 11 May 92 17:45:40 -0400
From: Robert Woody Woodburn <woody@sparta.com>
Message-Id: <9205112145.AA01183@crusher>
To: msteenst@bbn.com, tli@cisco.com
Cc: idpr-wg@bbn.com
In-Reply-To: msteenst@BBN.COM's message of Mon,
11 May 92 16:30:56 -0400 <9205112113.AA24527@sparta.com>
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. wood y
- transit policy syntax msteenst
- transit policy syntax Robert Woody Woodburn
- transit policy syntax Tony Li