Re: [RRG] Separation vs. Elimination
Hi Michael, Thanks for confirming that you include Ivip as a Separation scheme. Likewise for agreeing that there are some similarities between APT and Ivip. I will continue the discussion comparing APT and Ivip, and about charging for BGP updates, in another thread: Comparing APT Ivip - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg
Re: [RRG] Separation vs. Elimination
Hi Michael, I am perplexed that you don't consider Ivip to be a member of the class of solutions known as Separation - the class of core-edge separation schemes. You wrote: It doesn't matter that Ivip has a faster mapping system which enables simpler mapping data and simpler ITRs and ETRs, or that it is not intended to prevent edge devices from sending packets to devices in the core. I think the Ivip mapping system is exactly the part that doesn't fit. We feel strongly that we need to make a technical argument (not an economic one) as to why we aren't just moving the problem to the mapping system. Ivip has the only mapping system that proactively pushes mapping updates through the core. I don't see how these issues affect the question of whether Ivip is a core-edge separation scheme. I attest it is. LISP, APT, Ivip and TRRP all move the problem to the mapping system - and to ITRs and ETRs etc. But we are crafting the new mechanisms to scale to much larger numbers of end-user prefixed (EIDs for LISP and APT - I call them micronets) then the global BGP system can handle. In addition, with Ivip, I intend there to be business arrangements so that end-users pay for their use of the mapping system. This means the whole thing can be run profitably and agreeably, scaling to very large usage rates, since each mapping changes generates revenue - rather than there being some end-users burdening other parties with rates of updates which the other parties consider unreasonable. I wouldn't claim that every part of the entire mapping distribution system is necessarily covered like this, but most of the top end would be - not the tail ends of the Replicator system and the full database query servers themselves. Ivip has the only mapping system that proactively pushes mapping updates through the core. I disagree. APT and Ivip are the most similar proposals, in my view. They are both hybrid push-pull systems. In both APT and Ivip, the full mapping data is pushed to full-database query servers - Default Mappers for APT. For both APT and Ivip these local full database query servers provide fast, low-cost, reliable mapping responses. This is totally different from the global query server arrangements of LISP-CONS, LISP-ALT or TRRP. (Six/One Router doesn't have any particular mapping system yet.) It is also totally different from LISP-NERD's approach of pushing all mapping data to every ITR. Ivip pushes the mapping fast and APT pushes it slowly. Ivip has a distributed, but still reasonably centralised, push system which fans out to all full database query servers. APT has multiple islands, with more diffuse pushing of the updates from multiple sources of mapping data within the islands. (I don't see any benefit in APT islands - I think there should be one APT system.) Your formal definition of separation is: separating edge networks from the transit core, and engineering a control and management layer in between. I attest that Ivip does this. I see below that you mean more by separation than I do. . . . I was just pointing out that I think that only Ivip and LISP with PTRs do this robustly. I think APT's approach isn't so thorough. I guess we have to agree to disagree on this. OK - but I don't understand how APT (with APT islands) can robustly support packets from non-upgraded networks when there are two EIDs such as /25 or longer, in the one /24, and the two end-user networks are using ISPs in different APT islands, in a setting where it is impossible to have advertisements for prefixes longer than /24 propagate across the DFZ. Also, keep in mind that APT is still under active development, particularly in this area. I wasn't trying to say that APT could never support packets from non-upgraded networks addressed to smaller EIDs - just that with the current arrangements, in my understanding, that it can't. . . . OK. Your paper indicates that Elimination schemes can't support packets from non-upgraded networks - at least that is my interpretation of (page 4): Under Elimination, transit networks can do nothing but wait for a unanimous action by all the edge networks before the routing table begins to scale. Perhaps I am reading too much into that statement, but it is profound benefit of Separation schemes that at least some of them support packets from non-upgraded networks, compared to none of the elimination schemes. I think you're reading a bit too much into it. =) We're talking specifically about scaling the routing table here. Of course, non-upgraded networks can still communicate with upgraded networks in an elimination scheme. However, if upgraded networks stop injecting their prefixes into the global routing table, they lose the benefits of multihoming when communicating with non-upgraded networks. That is what I mean - with Elimination schemes, there is no way of achieving the scalability goals whilst providing multihoming
Re: [RRG] Separation vs. Elimination
Hi Robin, Robin Whittle wrote: Hi Michael, I am perplexed that you don't consider Ivip to be a member of the class of solutions known as Separation - the class of core-edge separation schemes. You wrote: It doesn't matter that Ivip has a faster mapping system which enables simpler mapping data and simpler ITRs and ETRs, or that it is not intended to prevent edge devices from sending packets to devices in the core. I think the Ivip mapping system is exactly the part that doesn't fit. We feel strongly that we need to make a technical argument (not an economic one) as to why we aren't just moving the problem to the mapping system. Ivip has the only mapping system that proactively pushes mapping updates through the core. I don't see how these issues affect the question of whether Ivip is a core-edge separation scheme. I attest it is. Sorry, I guess I wasn't clear on what my point was -- I definitely and wholeheartedly agree that Ivip is a separation scheme. =) The reasoning above was just to explain why the differences in the Ivip mapping system would have made it somewhat contradictory to mention Ivip as an example in the HotNets paper. LISP, APT, Ivip and TRRP all move the problem to the mapping system - and to ITRs and ETRs etc. But we are crafting the new mechanisms to scale to much larger numbers of end-user prefixed (EIDs for LISP and APT - I call them micronets) then the global BGP system can handle. In addition, with Ivip, I intend there to be business arrangements so that end-users pay for their use of the mapping system. This means the whole thing can be run profitably and agreeably, scaling to very large usage rates, since each mapping changes generates revenue - rather than there being some end-users burdening other parties with rates of updates which the other parties consider unreasonable. I wouldn't claim that every part of the entire mapping distribution system is necessarily covered like this, but most of the top end would be - not the tail ends of the Replicator system and the full database query servers themselves. Ivip has the only mapping system that proactively pushes mapping updates through the core. I disagree. APT and Ivip are the most similar proposals, in my view. They are both hybrid push-pull systems. In both APT and Ivip, the full mapping data is pushed to full-database query servers - Default Mappers for APT. For both APT and Ivip these local full database query servers provide fast, low-cost, reliable mapping responses. This is totally different from the global query server arrangements of LISP-CONS, LISP-ALT or TRRP. (Six/One Router doesn't have any particular mapping system yet.) It is also totally different from LISP-NERD's approach of pushing all mapping data to every ITR. Agreed. Ivip pushes the mapping fast and APT pushes it slowly. Ivip has a distributed, but still reasonably centralised, push system which fans out to all full database query servers. APT has multiple islands, with more diffuse pushing of the updates from multiple sources of mapping data within the islands. (I don't see any benefit in APT islands - I think there should be one APT system.) I think the larger difference between the mapping systems is what I pointed out below -- the difference in what information is distributed. Regarding APT, I think you will find that APT islands that are not physically connected can be logically connected in the next version of our incremental deployment scheme. However, we can't force ISPs that don't already have business relationships to create them, so there is always the (as you say, probably undesirable) possibility of multiple, disconnected islands. Your formal definition of separation is: separating edge networks from the transit core, and engineering a control and management layer in between. I attest that Ivip does this. I see below that you mean more by separation than I do. Actually, I don't believe I do -- just a case of miscommunication on my part. . . . I was just pointing out that I think that only Ivip and LISP with PTRs do this robustly. I think APT's approach isn't so thorough. I guess we have to agree to disagree on this. OK - but I don't understand how APT (with APT islands) can robustly support packets from non-upgraded networks when there are two EIDs such as /25 or longer, in the one /24, and the two end-user networks are using ISPs in different APT islands, in a setting where it is impossible to have advertisements for prefixes longer than /24 propagate across the DFZ. I assume this is not possible. But that means it provides an incentive for the separate islands to converge to one. =) Also, keep in mind that APT is still under active development, particularly in this area. I wasn't trying to say that APT could never support packets from non-upgraded networks addressed to smaller EIDs - just that with the current
Re: [RRG] Separation vs. Elimination
Hi Steve, Steven Blake wrote: On Tue, 23 Sep 2008 13:03:04 -0700, Michael Meisel [EMAIL PROTECTED] wrote: Hi Tony, Tony Li wrote: |So it seems to me that ESDs are similar to PI addresses (i.e. GSE |doesn't eliminate the USE of PI addresses, but does get rid of them |in the transit space). This is exactly where I have to disagree. The ESD is simply not an address. It is a wholly orthogonal namespace. While it is globally unique, it shares no other properties with a PI address that I can see. But it must be used as an address in edge networks, right? How else would a packet get routed to its final destination host once it gets to the destination network? By STP + ESD (last 80 bits of the address field). ESD is just an interface identifier, no different than the IID in IPv6. It's only really used in the neighbor table lookup on the last hop router. Please re-read http://ietfreport.isoc.org/all-ids/draft-ietf-ipngwg-gseaddr-00.txt. When Lan says PI address, she's referring in a general sense to an address that wasn't assigned by your provider. It could certainly come from a different namespace than PA addresses under a separation scheme, since the PI addresses are no longer used in core routing. So in this sense, I would call the ESD a PI address. ESD bits are never used in a routing lookup, so I don't know why you want to call it an address by itself. Fair enough. I think this is really just a semantics issue though, the point is, whatever namespace you use to identify the hosts in your local network, those names are independent of the names that get used for global routing, and they are independent from who your provider(s) is/are. This is consistent with our definition of separation. Perhaps we should call it PI namespace or local namespace or something. |How is GSE similar to NAT? GSE does pure translation on the routing bits. In a NAT environment, ^backbone the routing goop is translated into an RFC 1918 address. In GSE, the routing goop gets zeroed out. GSE is better than NAT in that it does provide a real identifier that applications can now exchange freely, so that much of the translation ugliness within NAT (e.g., FTP port commands) can go away. It seems to me that there is still an important fundamental difference: when you address a packet to a host behind a NAT, you are addressing the packet to the routing goop directly. The translation happens only locally on the destination end (and ugliness results). That's true of IPv4 NAT, but in (hypothetical) IPv6 NAT you would never want to translate anything other than the provider prefix. With GSE, on the other hand, if you address a packet to a host inside a GSE network, you are addressing the packet to the ESD, so you need mapping information (from DNS, in this case) to determine the correct routing goop. That's true of IPv6 in general, whether the edge site is using PA or PI prefixes internally (or would have been, if A6 records had survived). As I pointed out previously, there is no concept of globally unique edge site prefixes in GSE. There is no destination prefix translation anywhere upstream of the destination edge site's border router. Ergo, there is no mapping system that associate(s) an edge prefix with the corresponding transit address. The routing behavior in GSE is unchanged from IPv6 outside of the destination edge site (excepting the source prefix re-write). True, there are no edge site prefixes in GSE, so this wording doesn't quite match up. But DNS does associates the destination *portion of the address* with the corresponding transit *portion of the address*. That is, an RG Name lookup looks like a mapping lookup to me, it just happens at the host instead of the border router. -Michael Regards, // Steve -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg
Re: [RRG] Separation vs. Elimination
Robin Whittle wrote: Hi Michael, You wrote (with some of my original text deleted): Here is some feedback on your paper: Towards A New Internet Routing Architecture: Arguments for Separating Edges from Transit Core http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf I agree with your basic premise that a separation scheme is preferable to an elimination scheme. My main suggestion is that it would have been better if you mentioned Ivip, which is a significant example of a core-edge separation scheme. Some of the characteristics you ascribe to separation schemes do apply to non-Ivip separation schemes, but not to Ivip. This is exactly why we omitted it -- it was a short paper, and Ivip's mapping system doesn't quite fit our definition of separation. I think it fits it well - the edge addresses are removed from the core routing system. Ivip is a core-edge separation scheme. It doesn't matter that Ivip has a faster mapping system which enables simpler mapping data and simpler ITRs and ETRs, or that it is not intended to prevent edge devices from sending packets to devices in the core. I think the Ivip mapping system is exactly the part that doesn't fit. We feel strongly that we need to make a technical argument (not an economic one) as to why we aren't just moving the problem to the mapping system. Ivip has the only mapping system that proactively pushes mapping updates through the core. Ivip's aims in terms of edge-core separation are identical to those of LISP, APT, TRRP and Six/One Router, with probably exception that APT aims to eventually prevent edge devices from being able to send packets to core devices. At the end of this message, I wonder how this could be assured - how could a border router allow already encapsulated packets from ITRs to the interdomain core while dropping identical looking packets emitted by attacker-controlled hosts? Each ITR would need a secure tunnel to the border router. However, only Ivip with OITRDs (Open ITRs in the DFZ) and LISP with PTRs (Proxy Tunnel Routers) are clearly able to support packets sent by non-upgraded hosts. There is a business plan for OITRDs, but not yet for LISP PTRs. http://psg.com/lists/rrg/2008/msg02021.html APT can support packets from non-upgraded networks, but for IPv4, as long as there are separate APT islands, and as long as the current /24 filtering of BGP prefixes prevails, then there is no robust way of supporting such packets sent to EID prefixes longer than /24. This significantly limits the usefulness of the system, since many networks would be happy to use one or a few IP addresses, rather than 256. In defense of APT, I think you are making a *lot* of assumptions about the present and future here which may not hold true. However, that's beside the point and I'd like to keep this discussion at a higher level... I was summarising what I have mentioned in a previous critique of APT - that in its current formulation, it only supports multihoming etc. for packets from non-upgraded networks if the EID prefixes are /24 or shorter: APT: no need for islands? 2008-03-12 http://psg.com/lists/rrg/2008/msg00734.html I think it is reasonable to assume that many end-user networks will be happy to use less than 256 IPv4 addresses of SPI (Scalable PI) space. (In IPv6, the same argument applies in general - EIDs will often be longer than the maximum length prefix the BGP system is configured to recognise, in any given part of the address space.) With separate APT islands and with the current /24 limit on BGP advertisements, two separate end-user networks with a /25 which form a /24 couldn't successfully get packets from non-upgraded networks as long as they were using separate APT islands. The problem goes away if there is only one APT system, which could be achieved by tunneling APT mapping information between ISPs, in addition to the current technique of relying on physical links between ISPs. Which, as you pointed out in your previous message, is fairly simple to do. This is also not necessarily the only way. One of the big differences between separation and elimination is that at least some separation schemes will, or least aim to, provide full portability and multihoming support for packets from non-upgraded networks. I was just pointing out that I think that only Ivip and LISP with PTRs do this robustly. I think APT's approach isn't so thorough. I guess we have to agree to disagree on this. Also, keep in mind that APT is still under active development, particularly in this area. TRRP aims to do it: http://bill.herrin.us/network/trrp-implementation.html with 6 sticks and 8 carrots. Six-One Router doesn't provide portability or multihoming for packets from non-upgraded networks. TRRP has an approach to support of packets from non-upgraded networks, but I recall that it involves various carrots and sticks.
Re: [RRG] Separation vs. Elimination
Robin Whittle wrote: Hi Dan and Colleagues, Hi Robin, Here is some feedback on your paper: Towards A New Internet Routing Architecture: Arguments for Separating Edges from Transit Core http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf I agree with your basic premise that a separation scheme is preferable to an elimination scheme. My main suggestion is that it would have been better if you mentioned Ivip, which is a significant example of a core-edge separation scheme. Some of the characteristics you ascribe to separation schemes do apply to non-Ivip separation schemes, but not to Ivip. This is exactly why we omitted it -- it was a short paper, and Ivip's mapping system doesn't quite fit our definition of separation. Elimination schemes are a retreat from the current responsibilities of the routing system - to give each host a stable IP address. They involve host changes, including to applications which do referrals - and probably in the way applications find the one address of multiple addresses which they should be using. They involve each host in some highly complex tasks which I think belong in the network. Elimination schemes involve scaling problems with tens of thousands of sending hosts trying each to do their own reachability testing to some host or network they are all communicating with. I think it is better to centralise the control of multihoming service restoration as Ivip does, rather than devolve it to sending hosts (SHIM6) or to ITRs (non-Ivip core-edge separation schemes). Elimination schemes are hard or impossible to introduce because they involve host changes and only provide benefits when both hosts in a communication are upgraded. They do not provide portability. However, only Ivip with OITRDs (Open ITRs in the DFZ) and LISP with PTRs (Proxy Tunnel Routers) are clearly able to support packets sent by non-upgraded hosts. There is a business plan for OITRDs, but not yet for LISP PTRs. http://psg.com/lists/rrg/2008/msg02021.html APT can support packets from non-upgraded networks, but for IPv4, as long as there are separate APT islands, and as long as the current /24 filtering of BGP prefixes prevails, then there is no robust way of supporting such packets sent to EID prefixes longer than /24. This significantly limits the usefulness of the system, since many networks would be happy to use one or a few IP addresses, rather than 256. In defense of APT, I think you are making a *lot* of assumptions about the present and future here which may not hold true. However, that's beside the point and I'd like to keep this discussion at a higher level... TRRP has an approach to support of packets from non-upgraded networks, but I recall that it involves various carrots and sticks. Six/One Router doesn't work for IPv4 and doesn't support packets from non-upgraded networks. I think your paper states or implies that separation schemes support packets (for multihoming and portability) from non-upgraded networks whereas elimination schemes don't. I think this is not true of all separation schemes. In the four paragraphs you wrote above, I think you are focusing on specific methods and implementations, whereas our paper is trying to argue for the broader idea of separation. Of course, only a properly designed realization of separation can achieve all of its benefits. I think your use of ER and DR in place of ITR and ETR doesn't achieve anything useful - and that if you use such new terms, you should mention their equivalents in the terminology used in LISP, APT, Ivip and TRRP. We are using our own terminology because we find the LISP terminology confusing. A lot of people we've talked to (outside of the RRG) misunderstand APT because they see that TR stands for Tunneling Router, and they understand tunneling as the use of a pre-configured tunnel, like an ssh tunnel. We felt encapsulating router and decapsulating router were much clearer. Page 2 col 1 para 1 Solutions in the elimination category require that edge networks take address assignments from their providers; as a result a multihomed edge network will use multiple PA addresses internally and must modify end hosts to support multihoming. It seems that all elimination schemes involve host-changes. None of them propose that the end-user network have some new router functions to support elimination, with the hosts unaffected. (NAT is an example of this, but it doesn't provide hosts with public addresses.) Also, the elimination schemes do not provide portability, or the possibility of IP address referrals AFAIK. My recent message to Iljitsch (Re: Elegance and the rejection of SHIM6 host-based multihoming) discusses how SHIM6 would require host changes to do referrals, since I think it would require using two or more IP addresses. Page 2 col 2 para 3 You mention LISP, APT, TRRP and Six/One Router,
Re: [RRG] Separation vs. Elimination
Hi Tony, Tony Li wrote: |So it seems to me that ESDs are similar to PI addresses (i.e. GSE |doesn't eliminate the USE of PI addresses, but does get rid of them |in the transit space). This is exactly where I have to disagree. The ESD is simply not an address. It is a wholly orthogonal namespace. While it is globally unique, it shares no other properties with a PI address that I can see. But it must be used as an address in edge networks, right? How else would a packet get routed to its final destination host once it gets to the destination network? When Lan says PI address, she's referring in a general sense to an address that wasn't assigned by your provider. It could certainly come from a different namespace than PA addresses under a separation scheme, since the PI addresses are no longer used in core routing. So in this sense, I would call the ESD a PI address. |How is GSE similar to NAT? GSE does pure translation on the routing bits. In a NAT environment, the routing goop is translated into an RFC 1918 address. In GSE, the routing goop gets zeroed out. GSE is better than NAT in that it does provide a real identifier that applications can now exchange freely, so that much of the translation ugliness within NAT (e.g., FTP port commands) can go away. It seems to me that there is still an important fundamental difference: when you address a packet to a host behind a NAT, you are addressing the packet to the routing goop directly. The translation happens only locally on the destination end (and ugliness results). With GSE, on the other hand, if you address a packet to a host inside a GSE network, you are addressing the packet to the ESD, so you need mapping information (from DNS, in this case) to determine the correct routing goop. -Michael Tony -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg
Re: [RRG] Separation vs. Elimination
On Tue, 23 Sep 2008 13:03:04 -0700, Michael Meisel [EMAIL PROTECTED] wrote: Hi Tony, Tony Li wrote: |So it seems to me that ESDs are similar to PI addresses (i.e. GSE |doesn't eliminate the USE of PI addresses, but does get rid of them |in the transit space). This is exactly where I have to disagree. The ESD is simply not an address. It is a wholly orthogonal namespace. While it is globally unique, it shares no other properties with a PI address that I can see. But it must be used as an address in edge networks, right? How else would a packet get routed to its final destination host once it gets to the destination network? By STP + ESD (last 80 bits of the address field). ESD is just an interface identifier, no different than the IID in IPv6. It's only really used in the neighbor table lookup on the last hop router. Please re-read http://ietfreport.isoc.org/all-ids/draft-ietf-ipngwg-gseaddr-00.txt. When Lan says PI address, she's referring in a general sense to an address that wasn't assigned by your provider. It could certainly come from a different namespace than PA addresses under a separation scheme, since the PI addresses are no longer used in core routing. So in this sense, I would call the ESD a PI address. ESD bits are never used in a routing lookup, so I don't know why you want to call it an address by itself. |How is GSE similar to NAT? GSE does pure translation on the routing bits. In a NAT environment, ^backbone the routing goop is translated into an RFC 1918 address. In GSE, the routing goop gets zeroed out. GSE is better than NAT in that it does provide a real identifier that applications can now exchange freely, so that much of the translation ugliness within NAT (e.g., FTP port commands) can go away. It seems to me that there is still an important fundamental difference: when you address a packet to a host behind a NAT, you are addressing the packet to the routing goop directly. The translation happens only locally on the destination end (and ugliness results). That's true of IPv4 NAT, but in (hypothetical) IPv6 NAT you would never want to translate anything other than the provider prefix. With GSE, on the other hand, if you address a packet to a host inside a GSE network, you are addressing the packet to the ESD, so you need mapping information (from DNS, in this case) to determine the correct routing goop. That's true of IPv6 in general, whether the edge site is using PA or PI prefixes internally (or would have been, if A6 records had survived). As I pointed out previously, there is no concept of globally unique edge site prefixes in GSE. There is no destination prefix translation anywhere upstream of the destination edge site's border router. Ergo, there is no mapping system that associate(s) an edge prefix with the corresponding transit address. The routing behavior in GSE is unchanged from IPv6 outside of the destination edge site (excepting the source prefix re-write). Regards, // Steve -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg
Re: [RRG] Separation vs. Elimination
Steve, Thank you for your comments on our paper. On Sep 22, 2008, at 12:23 AM, Steven Blake wrote: On Sat, 2008-09-20 at 23:10 -0600, He Yan wrote: On Sep 20, 2008, at 8:42 PM, Steven Blake wrote: The statement A common requirement of all the separation solutions is a mapping system that associate an edge prefix with the corresponding ^s transit addresses. on page 2 is false. GSE, for instance, requires no such mapping. In GSE, isn't there a similar mapping between ESD and RG? Correct me if I am wrong. In GSE there is no notion of globally unique edge site prefixes. When a host resolves an address for another host in an external site and sends a packet to it, that packet has (one of) the RG(s) of that external site in it's destination address field. I've read the GSE draft several times. My understanding is that in GSE, every host has a globally unique ESD. In fact, the unique source/host ESDs are used as a connection identifier at the transport layer (they can't be used this way if they're not globally unique). So it seems to me that ESDs are similar to PI addresses (i.e. GSE doesn't eliminate the USE of PI addresses, but does get rid of them in the transit space). DNS provides the mapping between ESDs and RGs. GSE is just a very clever form of NAT. NAT in general is a separation scheme that does not require the mapping you describe above. I don't quite understand your above comment. How is GSE similar to NAT? Lan -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg
Re: [RRG] Separation vs. Elimination
On 2008-09-22 19:25, Tony Li wrote: |So it seems to me that ESDs are similar to PI addresses (i.e. GSE |doesn't eliminate the USE of PI addresses, but does get rid of them |in the transit space). This is exactly where I have to disagree. The ESD is simply not an address. It is a wholly orthogonal namespace. While it is globally unique, it shares no other properties with a PI address that I can see. |How is GSE similar to NAT? GSE does pure translation on the routing bits. In a NAT environment, the routing goop is translated into an RFC 1918 address. In GSE, the routing goop gets zeroed out. GSE is better than NAT in that it does provide a real identifier that applications can now exchange freely, so that much of the translation ugliness within NAT (e.g., FTP port commands) can go away. The cost of that excellent property is that transport protocols, IPsec, and any address-depedencies in upper layers, all have to be tweaked iirc. ILNP also needs DNS enhancements; probably any GSE solution does. However, I fully agree with Steve; I have always referred to GSE as architected NAT. Brian -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg
Re: [RRG] Separation vs. Elimination
Hi Dan and Colleagues, Here is some feedback on your paper: Towards A New Internet Routing Architecture: Arguments for Separating Edges from Transit Core http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf I agree with your basic premise that a separation scheme is preferable to an elimination scheme. My main suggestion is that it would have been better if you mentioned Ivip, which is a significant example of a core-edge separation scheme. Some of the characteristics you ascribe to separation schemes do apply to non-Ivip separation schemes, but not to Ivip. Elimination schemes are a retreat from the current responsibilities of the routing system - to give each host a stable IP address. They involve host changes, including to applications which do referrals - and probably in the way applications find the one address of multiple addresses which they should be using. They involve each host in some highly complex tasks which I think belong in the network. Elimination schemes involve scaling problems with tens of thousands of sending hosts trying each to do their own reachability testing to some host or network they are all communicating with. I think it is better to centralise the control of multihoming service restoration as Ivip does, rather than devolve it to sending hosts (SHIM6) or to ITRs (non-Ivip core-edge separation schemes). Elimination schemes are hard or impossible to introduce because they involve host changes and only provide benefits when both hosts in a communication are upgraded. They do not provide portability. However, only Ivip with OITRDs (Open ITRs in the DFZ) and LISP with PTRs (Proxy Tunnel Routers) are clearly able to support packets sent by non-upgraded hosts. There is a business plan for OITRDs, but not yet for LISP PTRs. http://psg.com/lists/rrg/2008/msg02021.html APT can support packets from non-upgraded networks, but for IPv4, as long as there are separate APT islands, and as long as the current /24 filtering of BGP prefixes prevails, then there is no robust way of supporting such packets sent to EID prefixes longer than /24. This significantly limits the usefulness of the system, since many networks would be happy to use one or a few IP addresses, rather than 256. TRRP has an approach to support of packets from non-upgraded networks, but I recall that it involves various carrots and sticks. Six/One Router doesn't work for IPv4 and doesn't support packets from non-upgraded networks. I think your paper states or implies that separation schemes support packets (for multihoming and portability) from non-upgraded networks whereas elimination schemes don't. I think this is not true of all separation schemes. I think your use of ER and DR in place of ITR and ETR doesn't achieve anything useful - and that if you use such new terms, you should mention their equivalents in the terminology used in LISP, APT, Ivip and TRRP. Page 2 col 1 para 1 Solutions in the elimination category require that edge networks take address assignments from their providers; as a result a multihomed edge network will use multiple PA addresses internally and must modify end hosts to support multihoming. It seems that all elimination schemes involve host-changes. None of them propose that the end-user network have some new router functions to support elimination, with the hosts unaffected. (NAT is an example of this, but it doesn't provide hosts with public addresses.) Also, the elimination schemes do not provide portability, or the possibility of IP address referrals AFAIK. My recent message to Iljitsch (Re: Elegance and the rejection of SHIM6 host-based multihoming) discusses how SHIM6 would require host changes to do referrals, since I think it would require using two or more IP addresses. Page 2 col 2 para 3 You mention LISP, APT, TRRP and Six/One Router, but not Ivip. You describe Six/One Router as using address rewriting. Translation is another term for this - perhaps the preferred term. You might also have referred to: http://www.firstpr.com.au/ip/ivip/comp/ which compares LISP, APT, TRRP and Ivip. Page 2 col 2 last para - continuing to page 3 Your discussion of mapping systems for separation schemes applies only to the non-Ivip schemes. You assume that the mapping system does not get information to the ITRs in real-time and that therefore it contains two or more ETR addresses for every EID prefix (micronet for Ivip). Because of this, and because you assume that the preferences for multihoming service restoration would not change often, you assume that there would only be a mapping change every month or so. Ivip works on completely different assumptions. Mapping changes are done in real-time, giving the end-user network direct control over the world's ITRs. This means the ITRs and ETRs are not involved in reachability detection or in deciding how to restore service via another ETR. Each mapping update pays its way - the user pays
Re: [RRG] Separation vs. Elimination
Hi Dr. Blake, Thank you for the comments. In response, I will try to clarify our definition of 'separation' and 'elimination'. On Sun, 2008-09-21 at 14:27 -0400, Steven Blake wrote: The statement in your paper that I pointed out is still false. The mapping change for GSE you point out above is the exact same mapping change needed for an elimination scheme (modulo any splitting of RG and ESD+STP in the DNS). Elimination refers to eliminating the use of PI addresses. Separation does not eliminate the use of PI, but places PI outside of routable space which requires a mapping. So either get all edge sites off of PI(elimination) or let them use PI and map/resolve their addresses somehow to a routable PA address(separation). The definition you are using for separation in your paper is either inconsistent, or not very useful. The definition is not inconsistent(see above). The utility of the definition and categorization I'll leave for others to judge. There are schemes that fall under elimination - they don't use unroutable PI and thus need no PI-PA mapping. For awhile, multipath transport was discussed(not necessarily by the authors) as a way to eliminate the need for PI to support multihoming, which would hopefully get edge sites off of PI and into PA, thus relieving our scalability issue. Thank you again for taking time to review our work. All further comments are welcome. Dan Jen -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg
Re: [RRG] Separation vs. Elimination
Hi Dan, I read the paper and liked it. Very clear and to the point! Just one comment. The terms separation and elimination do not really correspond to each other as the first term points to the solution and the second term to a result. Elimination of longer prefixes from BGP routing tables by multi-homed end nodes corresponds to hiding these prefixes by routing separation. I hope this makes clear what I mean. Best regards, Michael Dan Jen wrote: Hi all, We have published a paper comparing the two major approaches discussed on the RRG regarding routing scalability: separation and elimination. We believe that the proposals discussed on the list can be placed into either of these two categories. The paper goes on to argue why separation is a better direction than elimination when trying to achieve routing scalability. The separation approach involves separating edge networks from core networks, taking edge prefixes out of the routing tables. Map Encap schemes such as APT, LISP, and Ivip fall into this category. So do translation schemes such as SixOne. The elimination approach eliminates the use of PI addresses, moving edge networks into aggregatable PA blocks. Transport layer solutions fall into this category, as well as Shim6. The paper will be presented at the upcoming Hotnets VII workshop. It can be found here: http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf Agree? Disagree? Questions/Comments welcomed. Dan Jen -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:[EMAIL PROTECTED] http://www3.informatik.uni-wuerzburg.de/research/ngn -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg
Re: [RRG] Separation vs. Elimination
On Fri, 2008-09-19 at 15:36 -0700, Dan Jen wrote: Hi all, We have published a paper comparing the two major approaches discussed on the RRG regarding routing scalability: separation and elimination. We believe that the proposals discussed on the list can be placed into either of these two categories. The paper goes on to argue why separation is a better direction than elimination when trying to achieve routing scalability. The separation approach involves separating edge networks from core networks, taking edge prefixes out of the routing tables. Map Encap schemes such as APT, LISP, and Ivip fall into this category. So do translation schemes such as SixOne. The elimination approach eliminates the use of PI addresses, moving edge networks into aggregatable PA blocks. Transport layer solutions fall into this category, as well as Shim6. The paper will be presented at the upcoming Hotnets VII workshop. It can be found here: http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf Agree? Disagree? Questions/Comments welcomed. The statement A common requirement of all the separation solutions is a mapping system that associate an edge prefix with the corresponding ^s transit addresses. on page 2 is false. GSE, for instance, requires no such mapping. Regards, // Steve -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://psg.com/lists/rrg/ ftp://psg.com/pub/lists/rrg
