|
In einer eMail vom 28.11.2007 03:39:10 Westeuropäische Normalzeit schreibt
tli@cisco.com:
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?
Which 1x1 square degree geo-patches are supposed to form a cluster for the
next upper nxm-square degree patch, and which n1xm1-square-degree geopatches are
supposed to form the next upper n2xm2 quare-degree geopatch - this is up
to IANA directives.
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?
Can a border node of some geo-patch receive packets for different ISPs? Of
course it can.
And of course policies can be implemented which mark certain loose links to
be non-transit.
How do adjacent ISPs get paid ? I guess they make a mutual contract.
I am convinced that a viewed topology provides more for
implementing policies which overrule the absolute shortest path principle, than
a multitude of AS-path strings. BGP-Question: Can/would/does some AS advertise
its access to some destinations and combine it with a withdrawal threat in case
that some other, disliked AS wants to append itself to the AS-PATH ? I don't
think so.
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.
Right, partition repair is not trivial, but it starts out with recognizing
that there is a partition.
There should be more than sufficient routing expertise all around to
a) define what is best, what is acceptable, what is not acceptable for any
solution and b) implement the respective solution.
If you look at the newest graph picture on my website you will see that
there are many routes to the destination besides the blue shortest route.
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.
I would rather say, because the tools are less capable. With the current
interdomain-routing protocol you can neither afford nor do
the implementation of OSPF-MT like solutions.
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?
Advertise policy attributes for respective loose links.
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
=
Some additional remark:
The drafted core algorithm was already published in 1988. This is more than
17 years ago. Hence no one can have IPRs on it. You may google for Voronoi,
Delaunay, Mehlhorn.
Heiner
|