Hello Albert,
epic task - I appreciate your work :-)
And I agree with Florin and others that less may be more. What I mean is:
- I think it's generally accepted that stopping or reversing the constant
growth of routing tables is a good thing. No need to explain the potential
problems of large(r) tables.
- no doubt it's a good idea to refer to this original reason why LISP was
started
- I would tend towards statements that are less fundamental, e.g.
However, nodes and routing have fundamentally different
requirements,
is IMHO not correct as a general statement. There are millions of nodes that
are happy with the address they get from their DSL or cable provider - which
is solely based on the provider's routing plan. These nodes simply don't care
about topology vs. identity.
True is that newer phenomena like multihoming, mobility, over-the-top, [...]
can be addressed by this view that node location != node identity. And yes,
this shows that LISP is chasing something bigger than "just" Internet routing
table size.
Still have to read more of your document :-)
Regards, Marc
On Sun, 5 Oct 2014 23:46:09 +0200, Albert Cabellos wrote:
> Hi all
>
> I would like to ask the WG about this section, should we we describe
> the problem that LISP is trying to solve in the Introduction section?
>
> Some people suggest that we should while others that it provides too
> many details.
>
> Below you can find a sample description of the problem statement.
>
> Thanks
>
> Albert
>
> There is a rough consensus that the Internet routing and addressing
> system is facing severe scalability issues [RFC4984]. Specifically,
> the growth in the size of the routing tables of the Default-Free Zone
> (DFZ) is accelerating and showing a supra-linear slope [DFZ]. The
> main driving force behind this growth is the de-aggregation of BGP
> prefixes, which results from the existing BGP multihoming and traffic
> engineering mechanisms that are used -at the time of this writing- on
> the Internet, as well as non-aggregatable address allocations.
>
> This issue has two profound implications, on the one hand Internet
> core routers are exposed to the network dynamics of the edge. For
> instance this typically leads to an increased amount of BGP UPDATE
> messages (churn), which results in additional processing requirements
> of Internet core routers in order to timely compute the DFZ RIB.
> Secondly, the supra-linear growth imposes strong requirements on the
> size of the memory storing the DFZ FIB. Both aspects lead to an
> increase on the development and production cost of high-end routers,
> and it is unclear if the semiconductor and router manufacturer
> industries will be able to cope, in the long-term, with such
> stringent requirements in a cost-effective way[RFC4984].
>
> Although this important scalability issue is relatively new, the
> architectural reasons behind it are well-known many years ago.
> Indeed, and as pointed out by [Chiappa], IP addresses have overloaded
> semantics. Currently, IP addresses both identify the topological
> location of a network attachment point as well as the node's
> identity. However, nodes and routing have fundamentally different
> requirements, routing systems require that addresses are aggregatable
> and have topological meaning, while nodes require to be identified
> independently of their current location.
>
> On Thu, Oct 2, 2014 at 1:53 AM, Albert Cabellos
> <[email protected]> wrote:
>> Hi all
>>
>> This is the proposed Introduction following the comments on the list:
>>
>> This document introduces the Locator/ID Separation Protocol (LISP)
>> [RFC6830] architecture, its main operational mechanisms and its design
>> rationale. Fundamentally, LISP is built following a well-known
>> architectural idea: decoupling the IP address overloaded semantics.
>> Indeed and as pointed out by [Chiappa], currently IP addresses both
>> identify the topological location of a network attachment point as
>> well as the node's identity. However, nodes and routing have
>> fundamentally different requirements, routing systems require that
>> addresses are aggregatable and have topological meaning, while nodes
>> require to be identified independently of their current location.
>>
>> LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
>> RLOCs (Routing LOCators), both are -typically, but not limited to-
>> syntactically identical to the current IPv4 and IPv6 addresses. EIDs
>> are used to uniquely identify nodes irrespective of their topological
>> location and are typically routed intra-domain. RLOCs are assigned
>> topologically to network attachment points and are typically routed
>> inter-domain. With LISP, the edge of the Internet -where the nodes
>> are connected- and the core -where inter-domain routing occurs- are
>> architecturally separated and interconnected by LISP-capable routers.
>> LISP also introduces a publicly accessible database, called the
>> Mapping System, to store and retrieve mappings between identity and
>> location. LISP-capable routers exchange packets over the Internet
>> core by encapsulating them to the appropriate location.
>>
>> By taking advantage of such separation between location and identity,
>> LISP offers Traffic Engineering, multihoming, and mobility among
>> others benefits. Additionally, LISP’s approach to solve the routing
>> scalability problem [RFC4984] is that with LISP the Internet core is
>> populated with RLOCs which can be quasi-static and highly
>> aggregatable, hence scalable [Quoitin].
>>
>> It is important to note that this document does not specify or
>> complement the LISP protocol. The interested reader should refer to
>> the main LISP specification [RFC6830] and the complementary documents
>> [RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835], [RFC6836] for the
>> protocol specifications along with the LISP deployment guidelines
>> [RFC7215].
>>
>> Albert
>
> _______________________________________________
> lisp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
