[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Assumptions and mapping tools
In the RRG proposals we seem to a set of implicit assumptions that I
would like get some clarification.
I will respond with respect to the LISP solution.
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.
What DaveO said.
ITR/ETR selection (based on weights and priorities) guides the
bindings of EID to RLOC
ITRs encapsulate packets so they will choose an ETR at a remote site
based on the locator priorities and reachability bits.
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
LISP proposes the customer edge. eFIT/APT proposes the provider edge.
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
Yes, you are right. And from all the customer input we have received,
the control *needs* to be at the site. Just like the control for DNS
servers for a site for their domain names resides at the site.
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?
There are products out there that monitor site to site packet
performance. They can be used in a LISP environment as well.
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
Right, ISPs will put up PTRs for their customers, so they can reach
the ISP's customers LISP sites or non-customer LISP sites.
The ISPs are motivated to get LISP sites up because it relieves their
routing table sizes in their routers.
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, but if the PTRs are not there, the ITR can do address
translation. What we propose in LISP is a very simple address
translation technique. It is not full-blown NAT we have grown to hate-
and-flame about.
If the ITRs run BGP (which they may for underlying routing) they will
know if the EID prefix is in the underlying routing, so it's easy to
determine if you should translate or not.
The LISP-NAT idea documented in draft-lewis-lisp-interworking-00.txt
indicates that an ITR will translate the source EID of a egressing
packet to a routable address and that an ETR will translate the
destination address of an ingressing packet to the internal to site EID.
It has simple as that and no more functionality that I described in
the above paragraph.
Think it's relatively simple? If you want local control you do LISP-NAT.
Thanks for your general questions, it allows us to recap what is there
to get everyone on the same page.
Dino
--
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