On Fri, 19 Apr 2002, Howard C. Berkowitz wrote:
> While many things about the next generation architecture are yet in
> the fogs of the future, it does seem that more information hiding
> will take place and less global information will propagate among
> "federations" or whatever we call domains.
>
> We have mentioned operational requirements insofar as they seem to
> impact protocol operation. I suggest that there may be at least two
> additional areas that are not part of the "routing architecture," but
> will have to be there to make things work. They are apt to be at the
> application layer, but might propagate through special channels.
>
> The first is the trusted distribution of policy, which to some extent
> has been discussed.
I have some questions about policy here. I remembered in the groupb's
document it mentions if there is a need to have a policy model. at least
to me policy has always been a very ambiguous word. i intially interpreted
policy as the filtering rule for the BGP routes received and announced.
and later on i think you mentioned once RPSL means policy, which covers
more than filtering rules. But recently I have been studying the BGP
Policy Propogation feature in the Cisco routers, which is about using the
BGP community string to carry QoS policy information for routes.
My questions follow:
1.) when you say policy, does it mean all the policies that can be
described by RPSL?
2.) I think RPSL cannot describe all routing policies. There is at least
another important set of policy, QoS policy, that should be a subset of
routing policy. Should RPSL be extended to cover QoS policy as well?
3. Though it's a dispute if BGP transmits policy or not (I personally
believe community is increasingly a way of sending policies), at least we
agree that 2 adjacent ASes may send policy information such as, Outbound
Route Filtering, to each other. As far as policy distribution is
concerned, I feel it's practically possible and needed for 2 adjacent ASes
to exchange policy depending on their business relationship. The question
here is if there is a need for policy to be distributed further to other
ASes, and even further, for every AS in the Internet to tell all the other
ASes its policy.
4. I still feel an AS's policy is opaque to any non-related AS, and this
should be the guiding principle in the design of any future inter-domain
routing protocol, though at RIPE many ASes register their policy
information, which is incomplete and outdated. That will imply it's not
possible to design a map distribution protocol. Am I right?
Comments?
/Yong
>
> The second, which I have not seen mentioned, could be called
> operational coordination or incident communications. It deals with
> how we may have to troubleshoot with less global information than we
> now have. Are there requirements for standards for failure
> notification to NOCs--even to _finding_ NOCs? Will the deployment
> need Best Current Practices for cooperative troubleshooting?
>
> Does robustness need a way to quarantine domains that are causing
> global problems (e.g., AS 7007)? Obviously, if misused, this could
> be a form of DoS or of political censorship.
>
> Food for thought.
>
>
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT