Subject: [RRG] Assumptions and mapping tools

From: <[email-masked]>
Date: Thu, 20 Mar 2008 17:13:06 +0200

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.

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?

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.

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.

Regards 
Hannu

---

From: David R Oran <[email-masked]>
Date: Thu, 20 Mar 2008 11:44:21 -0400

On Mar 20, 2008, at 11:13 AM, <[email-masked]> wrote:
> 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.
> 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.
> 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 :-)

--
to unsubscribe send a message to [email-masked] 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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Mar 2008 10:42:01 -0700

> would like get some clarification.

I will respond with respect to the LISP solution.

> valid assumption it should be documented as it is a clear constraint  

What DaveO said.

> 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  

There are products out there that monitor site to site packet  
performance. They can be used in a LISP environment as well.

> 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.

> that are very much needed for the backwards compatibility and  

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