Re: [lisp] Updated Intro section for lisp-introduction
We could state the topo-id correlation as the problem, prefix fragmentation and growing routing tables as first symptoms. At 0 correlation routing == switching, no scale. Something needs to be done, hence the draft. Can connect the dots for those who try to address network virtualization using lisp as in the newer drafts. --szb > On Oct 5, 2014, at 8:31 PM, Florin Coras wrote: > > My take is less details as well. Being an intro document, focus should be on > the problem LISP was originally chartered to solve. Having said this, let us > know if you have specific use cases we didn't mention in > draft-saucez-lisp-impact. > > Florin > >> On 10/5/14 3:07 PM, Chad Hintz (chahintz) wrote: >> I agree, I would vote to less detail and maybe listing some of the problems >> its solves but mention they will not be covered in detail. It always a good >> idea to list why it was created or the original problem it was aimed at >> fixing. >> >> Chad Hintz >> >> Sent from my mobile device, please excuse the spelling mistakes. >> >>> On Oct 5, 2014, at 5:52 PM, Dino Farinacci wrote: >>> >>> >>> >>> On Oct 5, 2014, at 5:46 PM, 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? >>> I think LISP solves multiple problems and adds many new capabilities. It >>> would be hard to include all of them. Including the original problem >>> statement is just that, the first problem that LISP solved. But as LISO >>> evolved we found other, arguably, more important than the original problem >>> statement. >>> >>> So I vote for less detail. If the group really wants to identify the >>> problems, I would suggest doing it Inna couple of statements and simply >>> list the problems LISP solves rather describing all of them (or describing >>> the original problem statement). >>> >>> Dino >>> 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 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
Re: [lisp] I-D Action: draft-ietf-lisp-introduction-05.txt
Albert, Thanks for the updates they all look good. One note below. On Oct 5, 2014, at 23:42, Albert Cabellos wrote: >> Section 3.1 >> Please add references to the RFCs defining the cache management mechanisms. >> > > Could you please further elaborate this comment? You mean RFC6830? I meant for each of the three individual mechanisms, so rfc6830 and rfc6834. thanks Isidor ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Updated Intro section for lisp-introduction
My take is less details as well. Being an intro document, focus should be on the problem LISP was originally chartered to solve. Having said this, let us know if you have specific use cases we didn't mention in draft-saucez-lisp-impact. Florin On 10/5/14 3:07 PM, Chad Hintz (chahintz) wrote: I agree, I would vote to less detail and maybe listing some of the problems its solves but mention they will not be covered in detail. It always a good idea to list why it was created or the original problem it was aimed at fixing. Chad Hintz Sent from my mobile device, please excuse the spelling mistakes. On Oct 5, 2014, at 5:52 PM, Dino Farinacci wrote: On Oct 5, 2014, at 5:46 PM, 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? I think LISP solves multiple problems and adds many new capabilities. It would be hard to include all of them. Including the original problem statement is just that, the first problem that LISP solved. But as LISO evolved we found other, arguably, more important than the original problem statement. So I vote for less detail. If the group really wants to identify the problems, I would suggest doing it Inna couple of statements and simply list the problems LISP solves rather describing all of them (or describing the original problem statement). Dino 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 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, t
Re: [lisp] Updated Intro section for lisp-introduction
> On Oct 5, 2014, at 9:56 PM, Sharon Barkai wrote: > > Initially the toll was just bigger and bigger routing tables, these were in > retrospect just early signs. As more network evolution factors start to > way-in (virtualization, mobility, things..) the non correlation situation > becomes unsolvable without the specified LISP IP indirection architecture. Yes, agree. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Updated Intro section for lisp-introduction
We could look at the "original" problem as early signs of the reduced correlation between end-point IP identity and topological locations. Initially the toll was just bigger and bigger routing tables, these were in retrospect just early signs. As more network evolution factors start to way-in (virtualization, mobility, things..) the non correlation situation becomes unsolvable without the specified LISP IP indirection architecture. --szb > On Oct 5, 2014, at 2:52 PM, Dino Farinacci wrote: > > > > >> On Oct 5, 2014, at 5:46 PM, 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? > > I think LISP solves multiple problems and adds many new capabilities. It > would be hard to include all of them. Including the original problem > statement is just that, the first problem that LISP solved. But as LISO > evolved we found other, arguably, more important than the original problem > statement. > > So I vote for less detail. If the group really wants to identify the > problems, I would suggest doing it Inna couple of statements and simply list > the problems LISP solves rather describing all of them (or describing the > original problem statement). > > Dino > >> >> 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 >> 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-capab
Re: [lisp] Updated Intro section for lisp-introduction
I agree, I would vote to less detail and maybe listing some of the problems its solves but mention they will not be covered in detail. It always a good idea to list why it was created or the original problem it was aimed at fixing. Chad Hintz Sent from my mobile device, please excuse the spelling mistakes. > On Oct 5, 2014, at 5:52 PM, Dino Farinacci wrote: > > > > >> On Oct 5, 2014, at 5:46 PM, 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? > > I think LISP solves multiple problems and adds many new capabilities. It > would be hard to include all of them. Including the original problem > statement is just that, the first problem that LISP solved. But as LISO > evolved we found other, arguably, more important than the original problem > statement. > > So I vote for less detail. If the group really wants to identify the > problems, I would suggest doing it Inna couple of statements and simply list > the problems LISP solves rather describing all of them (or describing the > original problem statement). > > Dino > >> >> 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 >> 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 bet
Re: [lisp] Updated Intro section for lisp-introduction
> On Oct 5, 2014, at 5:46 PM, 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? I think LISP solves multiple problems and adds many new capabilities. It would be hard to include all of them. Including the original problem statement is just that, the first problem that LISP solved. But as LISO evolved we found other, arguably, more important than the original problem statement. So I vote for less detail. If the group really wants to identify the problems, I would suggest doing it Inna couple of statements and simply list the problems LISP solves rather describing all of them (or describing the original problem statement). Dino > > 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 > 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 RLOC
Re: [lisp] Updated Intro section for lisp-introduction
> Finally it is worth noting that in some cases an entry of the "... an entry in the map-cache ..." > map-cache can be proactively refreshed using the mechanisms described > in the section below. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Updated Intro section for lisp-introduction
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 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 lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Updated Intro section for lisp-introduction
Hi Christian Thanks, see inline my comments: On Thu, Oct 2, 2014 at 4:45 PM, Christian Cassar wrote: > Hello Albert, > > I have been through the current version of the document, and it reads well - > thanks! > > I have added a few nits below - feel free to pick and choose: > > 2.3 Data-plane > > In "This header is created by the source end-host and remains unchanged." > "remains unchanged" -> "is left unchanged by LISP data plane processing on > the ITR and ETR". (TTL processing, as part of IP forwarding, is done on that > header as usual.) > Ok, thanks. > 3.2. RLOC Reachability > > You describe RLOC probing in this section which is expected. However, you may > also want to allude to RLOC probing in the previous Cache Management section > too; an ITR implementation can exploit RLOC probing to infer instances where > it might be sensible to refresh entries in a map cache. > What about adding the following sentence at the end of section 3.1: Finally it is worth noting that in some cases an entry of the map-cache can be proactively refreshed using the mechanisms described in the section below. > 3.4. MTU Handling > > The Stateless comment is a tad misleading. I think the salient point in the > stateless mechanism is that the effective MTU is assumed from ITR's > perspective. The fact that ITR fragments packets that are too big, and can be > fragmented is common across both stateless and stateful mechanisms. > What about this: Stateless: With this mechanism the effective MTU is assumed from the ITR's perspective, in case that a packet is too big reassembly is typically performed at the destination host. > Couple of typos in here (defeines and framgented). > > > > The rest are exclusively style/spelling comments - feel free to pick and > choose. Oh, and I should add that English is my second language (as if it > weren't obvious already) - so you would do better to get some one with a good > command of the language to give it a once over. > Thanks! We´ll apply all your suggestions. >> 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. > > The word 'architecturally' doesn't seem to add much here, and 'are' might be > replaced by 'can be' - for example my IPv6 host may be reachable over LISP > over IPv4 and directly over IPv6. > Agreed, what about logically? > Thanks again > Christian > Thanks Albert ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-introduction-05.txt
Ack. Thanks Albert. I agree with all your responses. Dino > On Oct 5, 2014, at 5:03 PM, Albert Cabellos wrote: > > Hi Dino > > Thanks, I´ve removed the parts for which I agree, below my comments: > > On Fri, Oct 3, 2014 at 6:40 PM, Dino Farinacci wrote: > Change "supra" to "super". But saying super-linear is like saying "that was a long minute". ;-) I think you should say exponential slope. >>> >>> I think that the correct mathematical term is supralinear: >>> >>> http://en.wiktionary.org/wiki/supralinear >> >> I am not questioning the definition of supra linear, I just think we should >> use exponential because we have done so so many times before. Not a big deal. >> > > Ok, thanks for clarifying. Anyhow this part has been removed from the > updated introduction. > > > In order to resolve a query LISP-DDT operates iteratively and in a > similar way to the DNS. DDT clients (usually Map-Resolvers) generate It may worth saying that DDT does not do recursive lookups like DNS but does do iterative lookups like DNS. >>> >>> Why stating what DDT is not? I think that this way is shorter and clearer. >> >> Because if you state that DDT is DNS, then people may assume that recurisve >> lookups are done as they are in DNS. DNS has recursive and iterative >> lookups. DDT only borrowed the iterative lookup idea from DNS. > > Ok, what about this: > > In order to resolve a query LISP-DDT operates in a similar way to the > DNS but only supports iterative lookups. > >> > return a Map-Reply, also sent on the data-plane. The active nature > of RLOC-probing provides an effective mechanism to determine > reachability and, in case of failure, switching to a different > locator. Furthermore the mechanism also provides useful RTT > estimates of the delay of the path that can be used by other network > algorithms. We should say that echo-noncing and RLOC-probing can work together. That is if a nonce is not echoed, a ITR could RLOC-probe to determine if the path is up (because the return bidirectional path may have went silent). Or, when echo-noncing determines a forward path to an RLOC is up, RLOC-probes can be suppressed to save sending extra messages. >>> >>> See my updated paragraph below: >>> >>> It is worth noting that RLOC probing and Echo-nonce can work together. >>> Specifically if a nonce is not echoed, an ITR could RLOC-probe to >>> determine if the path is up because the return bidirectional path may >>> have failed. Alternatively, when echo-noncing determines a forward >> >> Or the the return path is not used. That is there is only a unidirectional >> path. >> >>> path to an RLOC is up, RLOC-probes can be suppressed to save messages. >> >> This part to explain suppressing RLOC-probes is good. >> > > Ok, I´ve appended your sentence, see below: > > Specifically if a nonce is not echoed, an ITR could RLOC-probe to > determine if the path is up because the return bidirectional path may > have failed or the return path is not used, that is there is only a > unidirectional path. > >> Thanks a lot, >> Dino >> > > Thanks! > > Albert ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-introduction-05.txt
Hi Dino Thanks, I´ve removed the parts for which I agree, below my comments: On Fri, Oct 3, 2014 at 6:40 PM, Dino Farinacci wrote: >>> Change "supra" to "super". But saying super-linear is like saying "that was >>> a long minute". ;-) I think you should say exponential slope. >>> >> >> I think that the correct mathematical term is supralinear: >> >> http://en.wiktionary.org/wiki/supralinear > > I am not questioning the definition of supra linear, I just think we should > use exponential because we have done so so many times before. Not a big deal. > Ok, thanks for clarifying. Anyhow this part has been removed from the updated introduction. In order to resolve a query LISP-DDT operates iteratively and in a similar way to the DNS. DDT clients (usually Map-Resolvers) generate >>> >>> It may worth saying that DDT does not do recursive lookups like DNS but >>> does do iterative lookups like DNS. >>> >> >> Why stating what DDT is not? I think that this way is shorter and clearer. > > Because if you state that DDT is DNS, then people may assume that recurisve > lookups are done as they are in DNS. DNS has recursive and iterative lookups. > DDT only borrowed the iterative lookup idea from DNS. Ok, what about this: In order to resolve a query LISP-DDT operates in a similar way to the DNS but only supports iterative lookups. > return a Map-Reply, also sent on the data-plane. The active nature of RLOC-probing provides an effective mechanism to determine reachability and, in case of failure, switching to a different locator. Furthermore the mechanism also provides useful RTT estimates of the delay of the path that can be used by other network algorithms. >>> >>> We should say that echo-noncing and RLOC-probing can work together. That is >>> if a nonce is not echoed, a ITR could RLOC-probe to determine if the path >>> is up (because the return bidirectional path may have went silent). Or, >>> when echo-noncing determines a forward path to an RLOC is up, RLOC-probes >>> can be suppressed to save sending extra messages. >>> >> >> See my updated paragraph below: >> >> It is worth noting that RLOC probing and Echo-nonce can work together. >> Specifically if a nonce is not echoed, an ITR could RLOC-probe to >> determine if the path is up because the return bidirectional path may >> have failed. Alternatively, when echo-noncing determines a forward > > Or the the return path is not used. That is there is only a unidirectional > path. > >> path to an RLOC is up, RLOC-probes can be suppressed to save messages. > > This part to explain suppressing RLOC-probes is good. > Ok, I´ve appended your sentence, see below: Specifically if a nonce is not echoed, an ITR could RLOC-probe to determine if the path is up because the return bidirectional path may have failed or the return path is not used, that is there is only a unidirectional path. > Thanks a lot, > Dino > Thanks! Albert ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-introduction-05.txt
Good point, thanks We´ll do this Albert On Fri, Oct 3, 2014 at 11:04 AM, Luigi Iannone wrote: > What I did in other documents is to explicitly put a pointer to RFC6830 but > also copy verbatim the section as an appendix. > In this way the lazy reader will have the definitions at hand ;-) > > L. > > > On 02 Oct 2014, at 02:05, Albert Cabellos wrote: > >> Ok, then I´ll add a sentence in the Introduction section pointing to >> the Definitions of Terms of RFC6830 >> >> Albert >> >> On Thu, Oct 2, 2014 at 2:03 AM, Joel M. Halpern wrote: >>> While it is not a strict rule, it is usually better to point to a definition >>> rather than copy it, and much better to point to it rather than to copy and >>> modify it. >>> >>> Yours, >>> Joel >>> >>> >>> On 10/1/14, 7:48 PM, Albert Cabellos wrote: Hi Fabio Thanks for your comments, please find below our answers: On Fri, Sep 26, 2014 at 2:28 AM, Fabio Maino wrote: > > > Albert, Damien, this is a very good document, that I think fits > very well with the charter requirements. I like that you keep it > short, dry, and to the point. > > From a structure perspective, I don't see a Definition of Terms > section. Maybe you could point to RFC6830 definitions, or copy > those needed in this document (XEID is possibly the only term that > is not already in RFC6830 glossary). I like that you didn't use new > terminology. > Find below a proposed "Definitions of Terms", We have used a simplified version of RFC6830,RFC6832,RFC6833 definitions, we don´t need so much detail and this way the text is lighter and easier to understand: >> >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-introduction-05.txt
Hi Isidoros Thanks for your comments, please see below our replies: On Thu, Oct 2, 2014 at 3:41 PM, Isidoros Kouvelas wrote: > > Albert, Damien, > > Thanks for the document. It provides a good overview of LISP. I have the > following comments: > > Section 2.3.1 page 7. > “The Instance ID field is used to distinguish traffic that belongs to > multiple tenants inside a LISP site, and that may use overlapped but > logically separated addressing space.” > Please expand on the instance ID description to state that it is used to > support segmentation of *EID* space. > Ok, please see below an updated sentence: The Instance ID field is used to distinguish traffic that belongs to multiple tenants inside a LISP site, and that may use overlapped but logically separated EID addressing. > > Section 2.4.2 > The start of this section refers to Map-Requests and Map-Reqplies as > “queries" and “responses". Their definition below does not refer to the > “query” and “response” role. Either modify the definitions to tie the two > together or use the standard terms from the beginning of the section. > Below the updated paragraph that introduces Section 2.4: The LISP control-plane, specified in [RFC6833], provides a standard interface to register, request, and resolve mappings. The LISP Mapping System, is a publicly accessible database that stores such mappings. In what follows we first describe the mappings, then the standard interface, and finally the Mapping System architecture. > Section 2.4.2 > “Map-Notify: When requested by the ETR, this message is sent by the > Map-Server in response to a Map-Register to acknowledge the correct reception > of the mapping.” > The Map-Notify message is also used to convey the latest Map-Server state on > the EID to RLOC mapping. > I´ve appended your suggested sentence at the end of the definition, please see below the updated paragraph: Map-Notify: When requested by the ETR, this message is sent by the Map-Server in response to a Map-Register to acknowledge the correct reception of the mapping and convey the latest Map-Server state on the EID to RLOC mapping. > Section 2.4.2 > “Please note that a Map-Reply may contain a negative reply if the queried EID > is not part of the LISP EID space. In such cases the ITR typically forwards > the traffic natively (non encapsulated) to the public Internet.” > Worth mentioning that this behavior is defined to support incremental > deployment of LISP. > Again, I´ve appended your suggested sentence, please see below the updated paragraph: Map-Reply: This message is sent by Map-Servers or ETRs in response to a Map-Request and contains the resolved mapping. Please note that a Map-Reply may contain a negative reply if the queried EID is not part of the LISP EID space. In such cases the ITR typically forwards the traffic natively (non encapsulated) to the public Internet, this behavior is defined to support incremental deployment of LISP. > Section 2.4.3.1 > “Every ETR involved in the ALT topology advertises its EID prefixes making > the EID routable on the overlay” > The Map-Servers participate in ALT, ETRs do not as the mapping system > interface hides the fact that the ALT is in use. The MS advertises the EID > prefixes that are registered against it in the ALT. > Dino rised a very similar issue with this paragraph, we suggested him this one alternatively, please let me know if you agree with it: The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first Mapping System proposed, developed and deployed on the LISP pilot network. It is based on a distributed BGP overlay participated by Map-Servers and Map-Resolvers. The nodes connect to their peers through static tunnels. Each Map-Server involved in the ALT topology advertises the EID-prefixes registered by the serviced ETRs, making the EID routable on the ALT topology. > Section 2.4.3.1 > “When an ITR needs a mapping, it sends a Map-Request to a nearby ALT router.” > The ITR sends the Map-Request to a nearby Map-Resolver that is ALT connected. > Again, Dino rised a similar issue, here´s the updated paragraph: When an ITR needs a mapping it sends a Map-Request to a Map-Resolver that, using the ALT topology, forwards the Map-Request towards the Map-Server responsible of the mapping. Upon reception the Map-Server forwards the request to the ETR that in turn, replies directly to the ITR using the native Internet core. > Section 2.5 > “In some scenarios, LISP sites may be unable to send encapsulated packets to > the legacy Internet.” > Should this be “unable to send unencapsulated packets with a local EID > address as a source”? > Here´s our updated sentence: In some scenarios, LISP sites may be unable to send encapsulated packets with a local EID address as a source to the legacy Internet. > Section 3.1 > Please add references to the RFCs defining the cache management mechanisms. > Could you please further elaborate this comment? You mean RFC6830? > Se
Re: [lisp] Updated abstract for lisp-introduction
Ok, thanks! Albert On Fri, Oct 3, 2014 at 8:40 PM, Darrel Lewis (darlewis) wrote: > I like. :-) > > A minor suggestion to the last sentence, I suggest: > > “This document is used for introductory purposes, more details can be > found it RFC6830, the protocol specification.” > > > > -D > On Oct 1, 2014, at 4:50 PM, Albert Cabellos > wrote: > > > Hi all > > > > This is the new proposed abstract: > > > > This document describes the architecture of the Locator/ID Separation > > Protocol (LISP), making it easier to read the rest of the LISP > > specifications and providing a basis for discussion about the details > > of the LISP protocols. This document is used for introduction > > purposes, more details is available in the protocol specification. > > > > Albert > > > > ___ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
