Subject: [RRG] Question about ITR and ETR deployment

From: "Gang Chen" <[email-masked]>
Date: Tue, 1 Apr 2008 10:51:47 +0800

Dear Tony and Lixia:
       May I ask you question about ITR and ETR deployment location? In the
LISP draft-farinacci-lisp-06.txt, both CE and PE router can be used  for
tunnel endpionts. I wonder to know where is the optimal location to reduce
router table size in DFZ greatly?

Best Regards
Gang Chen
[email-masked]

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 31 Mar 2008 22:56:42 -0700

On Mar 31, 2008, at 7:51 PM, Gang Chen wrote:
> Dear Tony and Lixia:
>        May I ask you question about ITR and ETR deployment location?  
> In the LISP draft-farinacci-lisp-06.txt, both CE and PE router can  
> be used  for tunnel endpionts. I wonder to know where is the optimal  
> location to reduce router table size in DFZ greatly?
>
> Best Regards
> Gang Chen
> [email-masked]
>
*personal* view:

- the optimal location for tunnel end point is a good question
   (which is an independent question from individual proposed solutions)

- map-n-encap approach reduces the global routing table by hiding user  
network prefixes; the exact location of tunnel end point (PE or CE)  
does not impact the DFZ table size in general, once the solution is  
globally rolled out.

- the exact location of tunnel end point (PE or CE), I believe, does  
have an impact on the details of a design, and more importantly, on  
the incremental rollout (if interested, you may want to take a look of  
the APT incremental deployment presentation slides from Philly meeting)

Lixia

--
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: Scott Brim <[email-masked]>
Date: Tue, 1 Apr 2008 11:53:26 -0400

> the APT incremental deployment presentation slides from Philly meeting)

The more we take these ideas and try to apply them to real life
operations, the more we realize how helpful coordination among xTRs
is.  In order for a site to be able to coordinate behavior of its
xTRs, to any degree and in any way it chooses, it is good to have them
under the site's direct control.  I don't believe we can predict or
should control how a site's xTRs will need to work together -- they
might do something surprising.  So I don't think a site should depend
on inter-provider cooperation.  That means I believe that it's better
to place xTR functionality in CEs.

Scott

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 1 Apr 2008 22:50:04 -0700

On Apr 1, 2008, at 8:53 AM, Scott Brim wrote:
> under the site's direct control.

I completely agree with the above.

(although I suspect, maybe only slightly, that what we have in mind  
about "site" in the above statement could be different, i.e. a  
customer site vs an ISP AS)

>  I don't believe we can predict or
> on inter-provider cooperation.

again I strongly agree that one AS should not depend on others  
cooperation.

and following all the above I had expected the next sentence to say  
that it's better to place xTRs in PE, but it said the opposite! :-)

>  That means I believe that it's better

this makes a perfect example to illustrate my concern in the earlier  
reply Robin: even when people may make the same statement, that does  
not necessarily mean we all understand each other.  So gaining a real  
understanding, rather than critique based on incomplete understand, is  
a first important thing.

Scott and I had a skype chat earlier which helped me solve the above  
puzzle. Below is my summary of that conversation; Scott can help  
correct for any part I got wrong.

To deploy encapsulation requires two points coordination, the encap  
point (ITR) and decap point (ETR) (I tried to avoid the word  
"tunneling" here, as Scott pointed out that tunneling is often used to  
refer to configured tunnels)

Scott considered CE the right place, based on the assumption that CE  
can decides whether to perform encap, based on its understanding of  
whether the other end know the new game to do decap.

Why I concluded PE as the right place: since we said earlier that
(1)to deploy encapsulation requires two points to collaborate, and
(2)one AS should not depend on others cooperation to deploy  
encapsulation.
Furthermore, whoever making the first deployment needs to have an  
incentive (some payback)
Putting all the above together: if an ISP is a first mover:
- it can have both ITR and ETR be "under the site's direct control",
   i.e. they'd be the ISP's border routers (PEs), so traffic get  
tunneled
   through the ISP
- as I explained in Philly's talk, there is a good hope that the ISP can
   get payback in terms of reduced BGP table size.

Lixia

---

From: Scott Brim <[email-masked]>
Date: Sun, 06 Apr 2008 17:33:15 -0400

On 4/2/08 1:50 AM, Lixia Zhang allegedly wrote:
> about "site" in the above statement could be different, i.e. a customer 
> site vs an ISP AS)
> 
> again I strongly agree that one AS should not depend on others cooperation.
> 
> and following all the above I had expected the next sentence to say that 
> it's better to place xTRs in PE, but it said the opposite! :-)
> 

> reply Robin: even when people may make the same statement, that does not 
> necessarily mean we all understand each other.  So gaining a real 
> understanding, rather than critique based on incomplete understand, is a 
> first important thing.

OK.  As it turns out, the confusion seems to be with the term 
"cooperation" (or coordination).  I didn't expect that.

> point (ITR) and decap point (ETR) (I tried to avoid the word "tunneling" 
> here, as Scott pointed out that tunneling is often used to refer to 
> configured tunnels)
> 
> Scott considered CE the right place, based on the assumption that CE can 
> decides whether to perform encap, based on its understanding of whether 
> the other end know the new game to do decap.

I was talking about cooperation betwen xTRs of the *same* site, for 
example to deal with operational up/down changes and policy-based 
mapping, coordinating on control of incoming traffic.  I wasn't talking 
about cooperation between an ITR and an ETR (in order to encapsulate) at 
all.

My thinking was: If a site (i.e. an area of the network addressed only 
by EIDs and surrounded by xTRs) is connected to more than one ISP/AS, 
and the how can you

   - have the xTRs in PEs, under control of the ISPs

   - have good cooperation between the xTRs, and

   - not depend on cooperation between the ISPs

I can see how if you are using encapsulation to cross a single ISP, to 
relieve the burden on internal routers, it would be useful to have both 
ITR and ETR under the same administration.

Sorry for the confusion.

Scott

---

From: Michael Meisel <[email-masked]>
Date: Wed, 09 Apr 2008 22:15:58 -0700

>   - not depend on cooperation between the ISPs

Hi Scott,

Let me use APT as an example of how this is possible.

In APT, a site provides preferences and weights for TE separately to 
each of their providers. (Let's call these preferences and weights "TE 
data".) So there is an exchange of information between customer and 
provider, which would need to occur in order to establish a business 
relationship, anyway. But there is no need for the TRs to cooperate 
directly.

TE data is propagated separately from each provider to all default 
mappers in the network. Default mappers store all TE data along with the 
corresponding ETR address. When an ITR needs to find an ETR address for 
a site, it can ask its default mapper. The default mapper assigns an ETR 
address to the ITR based on the accumulated TE data.

In the grander scheme of things, the major difference here (versus LISP) 
is not related to the CE vs. PE debate. The difference is that we 
require TE data to be the same globally -- that is, we don't support 
source-specific TE (from the ETR's perspective). This is simply because 
we have picked a different point in the tradeoff space -- one, global 
set of TE data allows for one, global system for distributing it. To 
summarize, I believe source-specific TE and our hybrid push-pull model 
are mutually exclusive.

-Michael

---

From: Scott Brim <[email-masked]>
Date: Thu, 10 Apr 2008 11:13:14 -0400

> address to the ITR based on the accumulated TE data.

So far so good, but that's just setup, and the main motivation for 
coordination between xTRs is operational.  When traffic is flowing and a 
CE-PE link goes down, what happens to traffic flowing through it?  Who 
discovers the problem, and how is it dealt with?  What does the remote 
ITR do in response?  How many intermediaries and systems have to be 
involved?  How long does it take for the entire path, end-to-end, to 
stabilize again?  Those are the kinds of questions I'm concerned about.

Also, how far is the operational change flooded?  To multiple mapping 
points in anticipation?  To just the ones with traffic flowing?  What 
happens when the situation is corrected?

Scott

---

From: Michael Meisel <[email-masked]>
Date: Thu, 10 Apr 2008 13:21:45 -0700

Scott Brim wrote:
>>> My thinking was: If a site (i.e. an area of the network addressed 
>>> only by EIDs and surrounded by xTRs) is connected to more than one 
>>> ISP/AS, and the how can you
>>>
>> mappers in the network. Default mappers store all TE data along with 
>> the corresponding ETR address. When an ITR needs to find an ETR 
>> address for a site, it can ask its default mapper. The default mapper 
>> assigns an ETR address to the ITR based on the accumulated TE data.
> 

Hi Scott, we answer all of these questions in our APT documents. For 
example, if you read section 4.4 in our RRG summary:

http://www.cs.ucla.edu/~meisel/apt-rrg.pdf

I think that will answer these questions for you, and it isn't very 
long. But let me know if it's confusing.

-Michael