Advertising all of ISP A's prefix isn't the issue at all. The real
question is: what happens at the geo-patch abstraction (action)
boundary? Where is that boundary?
I think I have explained this: At the event that an IP packet shall
be forwarded, the first (like the following) inside some geopatch
realizes that its own as well as the packet's destination have the
same longitude/latitude and therefore the next hop is determined
based on the recognized destination node which has a best suitable
reachability info.
And I think I have explained the routing protocol. Maybe I should
write more about the recursion.
I'm interested in the abstractions in the routing protocol, not the
forwarding plane.
Who is responsible for traffic arriving into the geo-patch?
the receiving node, who else ? but maybe I do not understand the
question.
Who administers that receiving node? Can it receive traffic for a
different AS? If so, what does it do with it? How do they get
compensated for forwarding it?
What happens if the topology within the geo-patch is internally
disconnected?
Permanent partition ( I placed just a few line to show that I am
aware of this problem which is certainly for further study). Maybe
it should be requested that at least one representative node must
also show up in the next higher level map. Then any node of one
particular partition will learn via the next upper level map that
there are more such representative nodes than disposed/contributed
by this partition. Hence the partition is detected. I am sure that
there are several ways to treat this problem (partition id?,
partition bridging area,...
I am optimistic. When we started PNNI we had much less available.
I think that this needs to be made explicit. Partition repair is a
non-trivial subject, especially when it might have to be repaired at
some arbitrarily higher level in the hierarchy.
The traditional explanation is that there must be regulations
requiring an interconnect for the geo-patch and all providers must
connect to that interconnect. The alternative is that providers
with links outside of the geo-patch end up receiving traffic
destined for other providers and end up providing free transit.
COMMENT: At first it takes knowledge about shortest path routing.
Then we can come up with provider constraints and assign QOS/policy
attributes to the loose links.
Sorry, but the constraints frequently make the topologically shortest
path irrelevant. Again, this is why today's inter-domain routing is
so much more complicated than OSPF.
More generally, if the entry point at an abstraction action
boundary is not directly connected to all of the sub-abstractions,
then you have a situation where traffic must traverse a sub-
abstraction, which will violate commercial constraints. Thus, the
abstraction action boundary must be located where there is common
(or free) connectivity to all of the sub-abstractions. You can
conceivably shift the abstraction action boundary away from the
abstraction naming boundary to help with this (i.e., do proxy
aggregation), but how is this maintained in the face of changing
topology and across hierarchical levels?
I am not sure I understand your questions. Maybe I should write
more about the adjacency of two different nxm-square-degree geo-
patches.
Maybe this helps to avoid wrong understanding: In the past Germany
conquered parts of France, and vice versa France conquered parts of
Germany. But that did not change the shortest path between Paris
and Berlin at all.
No, that doesn't help at all, sorry.
Let's see if I can explain the problem differently: suppose that we
have a geo-patch that is "France". This abstraction is circulated
outside of France and is advertised outwards at each border.
However, the administration of Alsace-Lorraine has a grudge with the
national government of France. All traffic that arrives in Alsace-
Lorraine that is not destined within Alsace-Lorraine and is forwarded
on to other areas has an associated charge of 1 Euro per packet. If
this is not paid, then the packet is dropped. How do you prevent
this situation?
The OSPF assumption that all routers are willing to carry all
traffic simply doesn't hold in the inter-domain routing arena.
See COMMENT above. I assume, EBGP hops only won't deliver the
packet either, will they? Honestly, if you have a viewed topology
(nicely sparsed to become scalable), you can do better policies and
TE than by just having AS-path strings, right?
Yes, EBGP hops would compute paths around the non-transit domains and
deliver the traffic, albeit with the cost of only being able to
aggregate to the prefix/AS level.
Yes, we could do better TE if we had a full map everywhere, but we
can't because propagating policy (and I include destination, transit,
and source policies) requires disclosure of policy information that
is today considered proprietary.
Tony
