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

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

Robert,

I have included my comments to your observations. I hope
they put more light on my proposal.

I will be out for a week. I will check later about the
possibility of having a meeting somewhere in Europe.
I will have to convince my boss first :-).

Regards,
Juanjo

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

Robert Raszuk <[email-masked]> escribió el 09/11/2006 00:56:33:

> Hi Juan,
>
> Below are my more detailed comments. You have a choice to ignore them or
> attempt to work together to simplify the current proposal to be much
> more easy to deploy both from vendor as well as customers point of view.
>
> Comments:
> ---------
>
> > I sent a draft in October on "Tunneled Inter-domain Routing" (TIDR):
> > draft-adan-idr-tidr-00.txt.
>
> > 1. Introduction
> >
> >    Routing protocols install all subnet prefixes in the routing table
> >    in the same manner, without taking into consideration the place
> >    where these subnets reside within the network. Because of this fact,
> >    every time there is a change in a stub network the RIB is always
> >    rebuilt again,
>
> Well most of the modern implementations do not "rebuild" RIB again on
> delete/update/modify message. Incremental updating of both RIB & FIB are
> well known technics.

When I say "rebuild" I don´t mean to rebuild the RIB _from scratch_.

>
> > thus possibly causing an instability to the routing
> >    system:
> >
> >    1) In the Internet, prefixes of a multi-homed non-transit domain,
> >       i.e. an autonomous system not participating in true inter-domain
> >       routing, are given the same treatment as the prefixes of a
transit
> >       domain. Irrespective of the type of domain all prefixes are
> >       installed by BGP [1] in the same global routing table, also known
> >       as the global routing information base (RIB).
> >
> >    2) Within a single domain, stub network prefixes are installed by
> >       interior gateway protocols (IGPs), like OSPF [2] or IS-IS [3],
> >       in the same routing table (RIB) where they install transit
> >       networks, whether stub network prefixes are installed as a
> >       result of a full SPF run or a partial SPF run.
>
> Well with BGP you are correct. With IGPs not so much ;) The general
> practice is to install just a summary route to a stub area. The issue
> here is that with MPLS and MPLS applications there is requirement for
> /32s that's why those are leaked everywhere in many MPLS networks. But
> this is more of exception then a rule in general.

When I say "stub network" I don't mean "stub area". If we have
a big routing domain configured as a single area, OSPF or IS-IS,
the number of "stub networks" (those in which the IGP doesn´t
establish any adjacencies) may be _very big_, thus making the RIB
and obviously the FIB very big even for a single area.

>
> >    Tunneled Inter-Domain Routing (TIDR) modifies both the usual routing
> >    and forwarding processes currently used in IP networks by treating
> >    stub networks in a different way than transit networks. This special
> >    treatment is twofold: stub network prefixes will not be installed in
> >    the RIB; and traffic for stub networks will be sent over tunnels
> >    established to the edge of the network. We will show how this
special
> >    treatment of stub network prefixes is nothing else but an easy
> >    solution to the identifier-location split problem, and some of the
> >    many benefits that such a split provides in terms of scalability,
> >    stability and the introduction of new routing features.
>
> Well let's focus on BGP part only. You have to realize and observe that
> to get most of the benefits you are targeting this work to such a split
> is not a must. As long as you can identify in the current stub/transit
> networks an element which can be used as the tunnel endpoint we are
> fine. There is no need for introduction of new Locator attribute. We (I
> & Stefano Previdi) have proposed just the use of AS IP address as the
> automated locator. Of course keeping in mind that even the mapping could
> be automated. Most of the gains are the same while implementation and
> deployment realistic. I do not think that we will go far if the ask for
> implementations to support TIB. See the bottom line is that especially
> in transit networks having big BGP RIB on the RP is no issue. What is
> the biggest saving is to have a contained FIB. This is why I think that
> there is a lot of gain without much implementation changes to be
proposed.

I think the locator/ID split has appeared many times in
many WGs as the possible solution to many problems of the
current routing paradigm.

> >
> > 2. Identifiers and Locators in TIDR
> >
> >    It is well known that IP addresses are semantically overloaded
because
> >    they carry information on both the location and the identity ofa
device.
> >    The need to split these two roles has been discussed many times in
many
> >    different forums with regard to (a) the possible introduction of a
new
> >    hierarchical routing paradigm in the Internet [4] [5] [6], (b) as a
way
> >    to provide scalable site multi-homing [7], or (c) the introduction
of a
> >    new addressing architecture [8], among other benefits.
>
> Very true.
>
> >    Some have pointed out that NAT is the feature that finally breaks
the
> >    semantic overload of the IP address as both a locator and a global
> >    identifier [9] but what NAT really does is to translate global
> >    identifiers into another set of identifiers, namely private
> >    identifiers, which is precisely the reason why the end-to-end
principle
> >    is broken by NAT. TIDR clearly differentiates the use of locators
and
> >    identifiers and does not impede the use of either identifiers or new
> >    mechanisms for endpoint identification within the applications.
>
> I was never keen on the NAT approach to scale the net ;).
>
> > 3. Tunneled Inter-domain Routing
> >
> >    Do we really need stub networks prefixes for actual IP routing?.
TIDR
> >    permits to send traffic for stub networks over tunnels established
to
> >    the edge of the network. But, where is the edge of a network?. In
TIDR,
> >    the edge of a network will be the place where stub networks
areattached.
> >    And the exact meaning of "stub network" will be relative to the
> >    environment we are analyzing: the Internet or an enterprise domain.
> >
> >    TIDR proposes a new method that current routing protocols will use
to
> >    manage stub networks. In TIDR stub networks will not be installed in
the
> >    RIB, as usual, but in a new table called Tunnel Information Base
(TIB).
>
> See above comment.
>
> >    Afterwards, when routing a packet to the destination prefix, the TIB
will
> >    be searched first to perform tunnel imposition, and secondly the RIB
for
> >    actual routing.
>
> If TIB has to be searched there is no need for split. To do it at line
> rate it has to be done in hardware. Btw - Just FYI hardware already does
> recursion easily on the same tables :).
>

When I say we need a new table, the TIB, I am not precluding
the implementation of the TIB in a specific manner. In fact
it could be included within the FIB. The problem appears if
the number of tunnels in the TIB is too big. But don´t forget
that the TIB is not necessary on pure transit routers but
only of edge routers, those facing clients.

The idea of having an IP address for an AS is something that
I also considered but I think it is much more interesting to
have a prefix so that we could even specify a specific entry
point in the AS por traffic directed to a specific "identifier
prefix". And a specific locator could be configured as an anycast
IP address so that in case of a problem in an entry point, the
tunneled traffic could be delivered through another entry point.

>
> >    After the edge router performs tunnel imposition, all
> >    routers in the middle will route this packet until the router being
the
> >    tail-end of the tunnel.
> >
> >    All we need is to find a way for a router to tell it is able to
receive
> >    tunneled traffic for a given prefix. For that purpose we will
analyze
> >    current routing protocols to find out what information can be used
as a
> >    locator for a specific stub network. Once we find a possible locator
then
> >    we will be able to send tunneled traffic for that stub network,
provided
> >    that both the router performing tunnel imposition and the router
receiving
> >    the tunneled packet are TIDR-aware. Therefore, the receiving router,
in
> >    addition to the IP address of the tunnel destination (locator),will
have
> >    to tell the types of encapsulations it supports for a particular
prefix,
> >    and the router performing tunnel imposition will have to support
that
> >    specific encapsulation method, a multipoint GRE tunnel for instance.
>
> Well we already have a number of draft proposals defining for tunnel
> encapsulation attributes or ext communities for that purpose. I wrote
> one with Rahul in the past, Jeremy did some original work, then we hand
> tunnel safi (now called info-safi), and coming up yet another one soon
> from me :-). Not sure there is a new need for yet another tunnel decap
> capability encoding.
>

I think my proposal is much more general. Most of the value-added
services are based on tunnels (mobility, VPNs, TE,...). I think
there is a need for a richer routing paradigm, and in my opinion
the solution is something like TIDR. TIDR is not an overlay solution
but a way to combine direct and indirect routing, the latter based
on tunnels. And I think TIDR paradigm could also be valuable for
other WGs (v6ops, trill, ...). I think we need the come of age
of tunnels within the IP architecture.

> >    This IP could be formed using a spare /8 prefix and the AS
> >    number for second and third octets, and it would be used as
> >    an anycast address assigned to a
>
> Why second & third octet ? Sure we can use 000/8 which is reserved by
> IANA since 1981 but now we have 4 bytes ASes. We could use three bytes
> out of it.
>

I know that AS numbers are 4-byte long. I mention 2-byte ASNs
in my doc to leave the fourth byte for example to specify a
specific entry point in the AS.

> >    Let's continue to look at the AS_Path attribute: if the
> >    penultimate AS in the path would be able to accept
> >    tunneled traffic for that prefix then we could
>
> Why do you still proposing the coupling of locator to prefixes in saying
> "for that prefix" ? IMHO we should keep those two independent. In other
> words if ASBR X is able to de-capsulate traffic to it's AS (if stub or
> stub-penultimate) it should be ok for any prefix to be tunneled to such
AS.

Maybe my English is not clear enough. "Locator prefixes" and
"Identifier prefixes" are kept independent. What I mean is
that traffic for a leaf AS (stub or multi-homed) should be
decapsulated by any of its upstream ISPs. Obviously this
is also true for the ISP prefixes that the ISP uses for
its own services (DNS, web servers, ...). In other words,
the "identifier prefixes" within the ISP network are also
assigned "locator prefixes" when the former are announced
by BGP.

> > 5.2. TIDR Basic Mechanism for a Single-Homed Site.
> >
> >    Let�s consider a site single-homed to upstream provider ISP1 that
uses a
> >    provider-independent prefix, what implies its presence in the
> >    BGP global RIB. Let's suppose now that ISP1 is TIDR-aware, which
means
>>     it will advertise the prefix using a new transitive BGP attribute
called LOCATOR
>
> You do not advertise the prefix using new attribute. The new attribute
> could be attach to the update msg if ever required.
>

The prefix of the client network will become an "identifier prefix"
when its ISP adds the LOCATOR attribute. The prefixes used by the ISP
for the tunnel endpoints will be announced without adding any
LOCATOR attribute, i.e. they will be "locator prefixes", as are
all the prefixes currently stored in the global Internet table.
Prefixes in the current global BGP table are "locator prefixes"
in the sense that they are used for actual routing.

> >    When all autonomous systems in the Internet are TIDR-aware the
> >    final resultis that all routers having full-routing will have
> >    the customer prefix both in the RIB and the TIB. When a new
> >    packet is sent to the customer only the first TIDR-aware router
> >    will have to look up the TIB+RIB whereas the rest of the
> >    transit routers will only have to look up the RIB. In other
> >    words, the router performing tunnel imposition will use the
> >    TIB+RIB, and the others will use the RIB.
>
> How does the transit router know to which tabel to look ? You said above
> that the lookup is TIB -> RIB ... I do not see a way for the transit
> node to examine the dst and make a lookup table decision based on this.
>

Once the edge router performs tunnel imposition the following
routers will route towards the tunnel destination.

> >    When these two BGP announcements arrive to the routers of the
> >    TIDR-aware ISP3 they will install the prefix in the RIB as usual,
> >    but they will also install the prefix in the TIB. Later, when
> >    one of these routers receives a packet for the multi-homed site
> >    it will check the TIB before the RIB and  it will find
> >    two locators.
>
> Well as of today it will not find two locators simply due to fact of
> best path only advertisement from either local ISP3 RR or some IPv4 RR
> on the way. Also think there are other good ways to achieve multihoming
> but in fact do not ask ISP2 & ISP1 for any cooperation. It could be just
> customer who is the end point via two (or N) peering ISPs.
>

Yes. The BGP best path selection algorithm will have to be
modified in the followint sense: if a router receives two
announcements for prefix X, the first announcement having
Locator1 and the second announcement having Locator2, the
BGP best path algorith will work as usual BUT it will have
to add both Locator1 and Locator2 to the bestpath.

> >    To avoid that only one of the locators arrives to ISP3 because
> >    of the effect of the BGP best path selection algorithm
> >    somewhere in the path, we will need to slightly modify this
> >    algorithm
>
> I do not think that this is practically doable to modify Internet like
> this. Especially where there are alternatives which do not require such
> modifications ;).
>

I don´t know about the alternatives you mention. Can you please
provide more info?. The BGP best path algorithm will work as
usual. We will only need to append both locators to the
announcement. Both locators would be in the same LOCATOR attribute,
i.e. the LOCATOR attribute permits to announce several locators
at the same time, and having different tunneling techniques
(GRE, IP-in-IP, ...).

> > 6. Locators of Locators for a Hierarchical Internet: The Onion Model
> >
> ...
> >    Let'ss suppose now that ISP-101 supports hierarchical TIDR
> >    (H-TIDR), which means that ISP-101 will assign new locators
> >    to the locator prefix that ISP1 announced to the Internet.
> >    The LOCATOR attribute for this locator prefix will now
> >    contain as tunnel destination an IP address of ISP-101, and
> >    the LOCATOR attribute will mark this new locator as a level-2
> >    locator. When this BGP announcement arrives to a level-2 aware
> >    AS, it will not install the locator prefix in the TIB as with
> >    any identifier locator but it will install the locator prefix
> >    in the RIB and it will mark it to know that a level-2 locator
> >    is available for it. This level-2 locator will be installed in
> >    a new table called RIB-2. Later, when ISP-101 receives traffic
> >    which is tunneled with the level-1 locator it will perform
> >    either a second tunnel imposition using the
> >    level-2 locator (telescoping) or even it could swap the incoming
> >    level-1 tunnel encapsulation with a new level-2 tunnel
> >    encapsulation (tunnel swapping).
>
> I agree with the N stage of encap. But again as in the original case I
> do not think that using locators is necessary. Just routing to AS IP
> addresses seems more then sufficient yet automatic and does not require
> any new signaling.
>

Don't you think it is better to have several AS IPs instead of just one?.

> Thx,
> R.
>
> PS. More comments when/if we agree on the above ;). As it seems that we
> are both currently located in Europe perhaps a direct meeting would be
> better to have a focused day on this.

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