Subject: Rm: [Idr] Draft on "Tunneled Inter-domain Routing"

From: [email-masked]
Date: Fri, 10 Nov 2006 12:18:24 +0100

Robert,

Thank you very much for your comments.
You can find my comments below.

Regards,
Juanjo

----- Remitido por JUAN JOSE ADAN LUENGO/GISS/SEG-SOCIAL con fecha
10/11/2006 12:01 -----

Robert Raszuk <[email-masked]> escribió el 08/11/2006 14:48:08:

> Juan,
>
> Excellent doc !!!! I must say that I with few other folks from Cisco are
> also actively working on a very similar idea for about last 8 months. I
> am not sure if you would like to continue the individual work or would
> be willing for a joint collaboration.
>

The draft I sent to the IDR WG is based on a paper I tried to publish
in the journal of big networking company based on San Jose (California),
without success. Later, I rewrote the paper for the Global Internet
Symposium of INFOCOM-2006, but it was rejected. Therefore this is my
third attempt to get it. However I must say I am new. This is my
first research paper and I don't know if it could published as an
individual submission, after it is pulished by all of your comments
of course.

The draft is a general overview of TIDR, and I left for a second
draft the specifications for the LOCATOR attribute and the
modifications for the BGP bestpath algorithm. For this second draft,
if my proposal is interesting, I will be very glad to write
it with you.

I am also preparing a third draft on "The use of TIDR with IGPs".

>
> While reading your draft I found a few opportunities which may even more
> relax the need for a separate locator advertisement. Also AS numbers are
> now 4 bytes not two :). I will try to spend some time this week to
> comment on it.
>
> Cheers,
> R.
>
>
> > Hi,
> >
> > I sent a draft in October on "Tunneled Inter-domain Routing" (TIDR):
> > draft-adan-idr-tidr-00.txt.
> >
> > TIDR is a proposal to modify the way in which traffic is routed to
> > "stub networks". The meaning of "stub network" is not the same for
> > inter-domain routing than for intra-domain routing.
> >
> > For BGP a "stub network" is simply a leaf autonomous system, whether
> > it be single- or multi-homed. ISPs would add a new transitive BGP
> > attribute called LOCATOR to a client prefix so as to specify how other
> > autonomous systems can send tunneled traffic for that client prefix.
> > The tunnel type is left open in TIDR (we can use several types), but
> > the best way to understand TIDR is to think on multipoint GRE tunnels.
> >
> > This LOCATOR attribute will eventually allow us to move client prefixes
> > from the global RIB to a new table called "Tunnel Information Base"
(TIB).
> > And this move provides many benefits, e.g. client prefixes
instabilities
> > will affect only the TIB, not the RIB.
> >
> > ISP prefixes used for TIDR tunnels endpoints will be stored in the RIB
> > and they will act as true locators for the client prefixes. And client
> > prefixes will be stored in the TIB and will be used as identifiers.
> >
> > When routing a packet to a leaf AS, the TIB will be search to perform
> > locator imposition, and the RIB will be used for actual routing. The
> > ISP that added the LOCATOR attribute will de-tunnel the traffic before
> > delivering it to its cliet.
> >
> >
> > This is the abstract:
> >
> >    In this paper we propose a new hierarchical method to enhance
> >    the current routing and forwarding paradigm for the Internet
> >    called Tunneled Inter-Domain Routing (TIDR). We will present the
> >    way in which TIDR permits to establish tunnels to the edge of
> >    the network, and how they will be used to forward traffic to
> >    stub networks. These tunnels will be explicitly signaled by
> >    using a new transitive BGP attribute called LOCATOR. This new
> >    routing and forwarding paradigm provides, among others, the
> >    following benefits: global routing table reduction, inter-domain
> >    routing infrastructure protection, improved multi-homing of edge
> >    networks, numerous forwarding decisions for a particular address
> >    prefix, it stops the AS number consumption, and it can be
> >    smoothly deployed.
> >
> >
> > Any comments will be appreciated.
> >
> > Juanjo
> >
> >
> >
> > _______________________________________________
> > Idr mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/idr
> >

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr