[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Assumptions and mapping tools
On Mar 20, 2008, at 11:13 AM, <hannu.flinck@nsn.com> wrote:
In the RRG proposals we seem to a set of implicit assumptions that I
would like get some clarification.
We are assuming that the networks using EIDs are stub networks,
networks that do not provide transit and do not peer between each
other. Is this really what is needed and required? If this is a
valid assumption it should be documented as it is a clear constraint
of the applicability.
Not necessarily, only that there is a clear addressing partition
between the things on the network used for transit and the "AS local"
address space used to address hosts and other local resources. For
example, there's no reason why Verizon, or France Telecom, or... could
not use whatever scheme we decide on to provide independence of
renumbering of their hosts. Now, the motivation to do that is small,
since I suspect Verizon would not necessarily want their hosts multi-
homed with France Telecom, but stranger things have occurred :-)
ITR/ETR selection (based on weights and priorities) guides the
bindings of EID to RLOC which facilitates how the traffic is
tunneled (routed and forwarded) over the core. The ingress and
egress devices can be located either at the customer edge or at the
provider side. This location impacts whether the originating and
receiving sites have access to underlying routing preferences.
Should we provide tools to the ingress/egress devices to have
visibility to the routing policies affecting how the tunnel is
performing? For instance, should the ingress benefit from knowing
the hop counts/costs of certain RLOCs of the egress?
This is, I believe, and open design question, except that I think
everybody has agreement that injecting routes inbto the global routing
table to accomplish the TE and/or resilience is not in the solution
set being considered, since that would put us back where we started
with respect to routing scalability.
The location of PTR/proxy matters as they attract traffic and are in
charge of forwarding packets causing transit fees. Typically ISPs
will forward traffic of their customers routes, and peer supplied
routes, but not the traffic of their providers nor between
providers. Is this still a valid constraint in the new routing
system we are devising? I must assume it is. Consequently the
topology and ISP relationships constraint where to place the proxies
that are very much needed for the backwards compatibility and
incremental deployment.
Yes, I think you've got this right.
In small case trials how traffic is routed (i.e. the topology and
policies) may not really matter much, but in larger ones where the
traffic volumes are significant the path selection will matter as
their is a cost factor associated to it.
Right, if this didn't matter we'd just do random routing :-)
Regards
Hannu
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg