[RAM] TIDR using the IDENTIFIERS attribute

[JUAN-JOSE.ADAN at giss.seg-social.es]

Hi all,

I am sending you the mail I promised
on Monday. 

I think we have mainly two problems
to solve: 
(1) scalability of the global BGP table,
(2) BGP churn.

(1) SCALABILITY OF THE ROUTING TABLE

We have several thousands of autonomous
systems in the
Internet, and we treat all of them
in the same way whether
they are transit or non-transit AS-es.
But we shouldn´t
forget that only 1/6 are transit AS-es.
And most likely
this fraction is decreasing over time
(any figures?).

In the draft on "Tunneled Inter-domain
Routing (TIDR)"
I presented a push method based on
the use of tunnels
which are announced using the LOCATOR
attribute. It is
the presence of the LOCATOR attribute
what permits to
say whether a prefix is a "locator
prefix" or an
"identifier prefix". This
separation will allows us to
treat these two types of prefixes differently.

But this separation can be achieved
either using the
LOCATOR attribute to assign locators
to identifiers,
or by using the IDENTIFIERS attribute
to specify which
identifiers can be reached through
the locator specified
in the NLRI of the BGP update. 

In TIDR, scalability of the routing
table is achieved
because whereas "locator prefixes"
are still stored in
the RIB, "identifier prefixes"
are moved to the TIB.
As a consequence of this, the RIB eventually
will
only store the "locator prefixes"
of the transit AS-es.


(2) BGP CHURN
As Heiner Hummel pointed out "with
Hierarchical Routing
the routing churn rate will dramatically
be reduced". 

I think he is right, because with hierarchical
routing not
all parts of the network are equally
important. So that,
an announcement or withdrawal of an
"identifier prefix"
will be far less important than that
of a "locator prefix".

The addition of a new attribute to
BGP (LOCATOR, IDENTIFIERS,
or both) obviously increases the amount
of information that
must be flooded by BGP. But in my opinion,
the main problem
is not this increase in the amount
of information but the
fact that a change in a leaf AS using
PI addressing implies
to modify the RIB and FIB of all the
routers in the DFZ.

In other words, the problem is not
to force every router in
the entire DFZ to carry an advertisement
for site X's
PI-prefix. The most important problem
is that it has to use
this announcement for routing, i.e.
it has to install it in
the RIB and download it into the FIB.
With TIDR things
improve because this announcement will
not modify the RIB
but only the TIB.

Therefore, if we want to reduce the
effect of the route churn
on the BGP convergence we will have
to modify BGP so that a
change in the identifier-locator map
will not affect the
interdomain routing system (more specifically
the RIB of
DFZ routers) but only the TIB. So,
we need two types of
BGP updates: "routing updates"
and "mapping updates".

Let's use for example the block 240.0.0.0/8
to assign
"locator prefixes" to transit
AS-es so that, for instance,
AS1 will use the block 240.0.1.0/24
for "locator prefixes".

Please notice that this is just an
example to explain
the inner workings of my proposal.
I think it is very
important to use a specific range of
IP addresses for
TIDR routing so that a transit AS is
assigned an address
block easy to identify.

The ORIGIN attribute is a mandatory
attribute that must
be always present in any BGP update.
At present this
attribute can have one of the following
values:
  - IGP: the NLRI is interior
to the originating AS
  - EGP: NLRI learned via the
EGP protocol
  - Incomplete: NLRI learned by
some other means

The ORIGIN=EGP value is no longer used.
Therefore I
propose to reinterpret this value as
EXTERNAL (to keep
the first letter the same), or to define
a fourth value
for the ORIGIN attribute, whatever
is simpler. If the
latter is simpler we could define ORIGIN=MAPPING
to
indicate that the BGP update is just
for ID-LOC mapping.

Bearing this in mind we proceed to
distinguish the two
aforementioned types of BGP updates:
  - "routing updates":
these are the current type of
    updates. They carry ORIGIN
IGP or INCOMPLETE.
    They are used to modify
the RIB.
  - "mapping updates":
they carry ORIGIN EXTERNAL or
    MAPPING, and are used
to modify the TIB. They
    carry the IDENTIFIERS
attribute to specify the
    set of "identifier
prefixes" that can be reached
    through the locator specified
in the NLRI of the
    update. They will be
treated with a priority
    lower than "routing
updates".

With these two types of BGP updates
we separate routing
events (those affecting the interdomain
infrastructure)
from those updates caused by changes
in the ID-LOC mapping.

Following the above example, AS1 will
generate "routing
updates" to announce prefix 240.0.1.0/24
or even longer
prefixes that will remain inside the
interdomain routing
infrastructure. What means that transit
AS-es will never
propagate these announcements to their
leaf customers,
for they are outside the interdomain
infrastructure.

And AS1 will also generate "mapping
updates" to specify 
within the IDENTIFIERS attribute which
"identifier prefixes"
can be accessed by sending tunneled
traffic to the locator
which is specified in the NLRI.

Notes:
a) I have continued to use LOCATOR
as the name of the first
   new attribute that I proposed
in the TIDR draft, but
   notice that this attribute
can be used to store several
   locators. Therefore the
name can be changed to LOCATORS.
b) When I say PI-prefix I also mean
a deaggregated PA-prefix.


Any comments?.

Regards,
Juanjo

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram