[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Question about ITR and ETR deployment

Scott Brim wrote:

On 4/10/08 1:15 AM, Michael Meisel allegedly wrote:

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 
  - have the xTRs in PEs, under control of the ISPs

  - have good cooperation between the xTRs, and

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

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?

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

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