Re: [RRG] LISP-EMACS (was: LISPEMACS LISP-ALT)

Hi Scott, You wrote: LISP-EMACS ... does not seem to be tied to LISP-ALT That's right. OK - but I understand that the multicast system is on an overlay system of special routers, which use GRE tunnels - and presumably their own instance of BGP - much like that of the LISP-ALT system. The

Re: [RRG] LISP-ALT (was: LISP-EMACS LISP-ALT)

Hi Scott, Thanks for your response. I understand that LISP-ALT is not a physically separate network, but that it uses tunnels through the current network to create a structurally independent network, with its own use of address space, its own BGP system and its own new use of BPG's ASNs. I

[RRG] Practicality of upgrading hosts

Tony Li wrote in Re: [RRG] A new draft about Hierarchical Routing Architecture: Alternately, it's pretty clear that we're getting to the point where OS release updates are getting to be pretty well automated. We can certainly expect that as we get large-scale experience with v6, we will find

Re: [RRG] Idea for shooting down

Hi Brian, With your proposal: http://www.cs.auckland.ac.nz/~brian/DFZng.pdf I get the impression that the result would be the Internet being much less meshed than it is at present. This would have negative impacts including: 1 - Less robustness in the event of link and router failure. 2 -

Re: [RRG] NIRA:Combining the hier. interdomain and the OSPF-intradomain network topology

Hello Heiner, In the last three or so months you have written 26 messages to this list. I think none of them have contained constructive criticism of other peoples' proposals. In general you have asserted that there is a new way of solving the routing scaling problem. So far, I think you have

Re: [RRG] MTU, jumboframes, ITR ETR placement, ITR function in hosts

Hi again Iljitsch, I hope others can join this discussion. I think that ITRs and ETRs are going to be ubiquitous. I can't see how IPv6 (or any other imaginable replacement for IPv4) is going to be widely enough adopted in the next decade or two to make ordinary users happy without a public or

Re: [RRG] Sprite IPTM while PMTU probing is in progress

Hi Fred, You wrote: I don't clearly understand this. Iljitsch has not been able to convince me - or anyone else AFAIK - that it it will be practical to insist on massive hardware upgrades broad enough for the wide range of location I think ITRs and ETRs need to be located. (Host to host,

Re: [RRG] LISP and IP Interworking - Anycast PTRs == Ivip

Hi Darrel, Thanks for posting this text, which I assume will become an ID soon. In recent months there have been various on-list references to LISP Proxy Tunnel Routers for ensuring sites without ITRs can send packets to hosts with LISP-mapped (EID) addresses. There has also been discussion of

Re: [RRG] Convergence - design-goals-01: IPv4 utilization, portability

Short version: I think the Design Goals could be improved in terms of terminology eg. control plane and to include the following goals: Portability Since many end-users want this and since ITR-ETR schemes do provide it, it should be one of the

[RRG] Mobility in the future

I am replying to Russ White's message 716 (Thoughts on the RRG/Routing Space Problem) regarding mobility. Hi Russ, You wrote, in part, quoting Scott Brim: - Routing and addressing are more fundamental than mobility. Mobility can adapt to RA but not vice versa. In other words, mobility is a

[RRG] Is 12 bytes really so scary?

I listened to the Friday morning meeting via a 64kbps MP3 stream - and didn't notice any glitches whatsoever. This is a modest, commonplace, consumerish, data rate - completely uneventful, across the planet in 17 hops from Oregon to Melbourne, Australia. An ITR-ETR scheme with real-time (a few

Re: [RRG] Is 12 bytes really so scary?

Heiner, I am not responding to your suggestions because I am only interested in proposals which are incrementally deployable. You discuss modifying TCP/IP, introducing a completely new routing architecture etc. I will be away from email for a few days - back on Wednesday. Maybe the wariness

[RRG] Comparing BGP with map-encap schemes

The previous message went out with with lines of unlimited length due to Format Flowed being on - sorry about this. To turn it off in Thunderbird: http://www.firstpr.com.au/web-mail/Mozilla-mail/#FF Short version: The functions and communication needs of the various

Re: [RRG] ALT + NERD is inelegant inefficient, compared to APT or Ivip

I am responding to the messages from Eliot Lear, David Meyer, Brian Carpenter and Tony Li. Eliot wrote: RW NERD on its own won't work because every ITR in the world would RW need the full feed of mapping updates. Table 1 in Section 5.1 of draft-lear-lisp-nerd-02.txt addresses this somewhat.

Re: [RRG] draft-fuller-lisp-alt-01.txt

Hi Iljitsch, I am not sure why each ALT router would need to decapsulate the traffic packet. Doesn't it get forwarded to the correct ETR according to its outer destination address - that of the destination host, which the authoritative ETR has advertised into the ALT network? (I don't

[RRG] ALT's strong aggregation often leads to *very* long paths

Even assuming a global query server (and initial packet delivery) network was desirable, which I think it is not, ALT suffers from the problem that many paths from ITR to ETR will be extremely long - longer than half-way round the Earth. The paths will often be far longer than via the most direct

Re: [RRG] ALT's strong aggregation often leads to *very* long paths

Hi Xu, You wrote: LISP-ALT routers are deployed in a hierarchy which matches the EID prefix allocation hierarchy. LISP-ALT routers at each level in the this hierarchy are responsible for aggregating all EID prefixes learned from LISP-ALT routers logically below them and advertising summary

Re: [RRG] ALT's strong aggregation often leads to *very* long paths

Hi Noel, I am replying to your two messages, in which you wrote, in part, and in a different order: I had too much difficulty understanding how CONS would work anyway. CONS is conceptually fairly simple; think DNS, but replace DNS names with IDs and A/etc records with RLOCs. The fine

Re: [RRG] ALT's strong aggregation often leads to *very* long paths

Hi Noel, I am keen to know what you and others think of my critique of ALT's core design principle of strong address aggregation being at odds with the need for short total path lengths. http://psg.com/lists/rrg/2008/msg00229.html http://psg.com/lists/rrg/2008/msg00237.html In two days only

[RRG] Single Host Granularity (SHG) with full database ITRs Query Servers

Hi Xiaohu, In Re: [RRG] draft-fuller-lisp-alt-01.txt you wrote: Hi Robin, As Tony said, the mapping system should be flexible so that it can support host granularity. If that statement is true in the future network, do you believe the default mapper is still suitable to support such a huge

Re: [RRG] ALT's strong aggregation often leads to *very* long paths

Hi David, Thanks for your respsonse, in which you wrote: It seems we have a choice: a) scalable to host granularity but imposing some delay at session initiation - or - b) no additional latency but more limited scalability. My understanding of what you wrote is: a) Scaling to the

[RRG] Messages not getting to the List?

One recent message of mine (Single Host Granularity) and another from Xiaohu Xu (re: [RRG] draft-fuller-lisp-alt-01.txt, which was CCed to me) didn't make it to the RRG list, but were successful on a second attempt. I have written a bunch of messages recently and will now maintain radio silence

[RRG] Why delaying initial packets matters

In Re: [RRG] Re: Aggregation Implies Provider Dependence (LISP-ALT) Ivip dependencies too, Brian Carpenter wrote: However, user expectations are of a noticeable delay between dialling a phone number and hearing the ringing tone. So e2e lookup solutions to both number portability and roaming

Re: [RRG] Why delaying initial packets matters

Short version: We have choices other than pure push or pure pull. A suitably flexible hybrid push-pull system can be deployed according to all the prevailing conditions and provide minimal packet delays, due to the use of query servers which are always local - a lot closer and

Re: [RRG] Why delaying initial packets matters

I agree entirely with Lars. - Robin But there are maybe a few million routers in the world, and maybe even fewer for which scalability is a serious issue, compared to a few billion hosts. Deploying something new at the network layer that might require changes to host stacks or applications

Re: [RRG] Why delaying initial packets matters - complex web pages real-time P2P

Marshall Eubanks wrote: Note, too, that many simple web pages have in them pieces from other servers and other IP addresses (banner ads are frequently done this way) and so this could put a real performance hit on web page load times in the real world. I have been thinking of this, but this

[RRG] Map-encap space for server vs. client end-users?

Hi Bill, In Re: [RRG] Why delaying initial packets matters - complex web pages real-time P2P you wrote: It seems to me that one assumption which has run heavily through this thread is that man-n-encap would entirely replace the existing system where the EID and LOC are the same. It strikes

[RRG] Ivip Fast Push ID 8 page Conceptual Summary and Analysis

In accordance with: http://psg.com/lists/rrg/2007/msg00908.html I have written an 8 page Conceptual Summary and Analysis of Ivip: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf and linked to it from the Proposal Summaries section of the wiki:

Re: [RRG] Re: Map-encap space for server vs. client end-users?

Short version: I still think the new map-encap space has to be free of stuff like significant initial packet delay, since we have to make it attractive to large and small end-users. I would appreciate some debate of my message about this: Large companies with PI, small with

[RRG] Map-encap space only for small end-users? PI space prices

Hi Bill, In Re: [RRG] Map-encap space for 'server' vs. 'client' end-users?, you wrote: If the entire Net changed to add some small delay, then this would not be a barrier to adoption of the new map-encap scheme. However, as I and others have written, if the new address space performs worse,

Re: [RRG] Future mapping DB size, small micronets/EIDs

Hi Brian, Regarding maximum length of LISP EID prefixes, you wrote: I think we've had that conversation (at least, I was having it with Tony). My conclusion is that the longest prefix is undoubtedly /32 or /128, but that doesn't answer the important question of how many prefixes need to be

Re: [RRG] How to Incrementally Deploy APT

Hi Dan and Micheal, Here are some questions prompted by your explanation of how packets from a host in a non-APT network will find their way to the destination host which uses address space which is managed by APT. I have redrawn your diagram to add ISP5 to the left island. |

[RRG] Mobile robustness via layer 7, or multiple tunnels to TTRs

Hi Brian, In Re: [RRG] Mobility frequency you wrote: I think we should also remember Layer 7 mobility. There are many application suites that recover in one way or another from a low frequency of Layer 3 disconnects and re-addressing events, using Layer 7 identities to restore a connection

Re: [RRG] Re: Delays inherent in TRRP's DNS-like lookup?

Hi Bill, Thanks for explaining TRRP in greater detail and improving my understanding of DNS. I will return to that below. Sure, but if a new kind of address space involves a new kind of delay, and you have the choice between this and the original kind of address space which has no such

[RRG] TRRP Waypoint Routers

Hi Bill, In your page: http://bill.herrin.us/network/trrp-aapip.html which I understand is not at all finalised, you describe a system for getting initial packets to their destinations while the ITR is waiting to get the mapping information. This (initial packet delay) can be mitigated by

Re: [RRG] How to Incrementally Deploy APT

Hi Dan and Michael, Thanks for your response, in which you wrote: | APT Island 1 | | __ | |/ ISP5 \=\ |\__,___/||| | ___/ ||| | / | BGP __\/__ BGP | APT Island

[RRG] Re: Delays inherent in TRRP's DNS-like lookup?

Short version: How TRRP's DNS system could be souped up to provide much faster response times. This involves integrating the nameservers and anycasting them all from multiple sites around the Net. The result is a hybrid push-pull

[RRG] Re: TRRP Waypoint Routers

Hi Bill, Thanks for your explanation: http://psg.com/lists/rrg/2008/msg00478.html which helped me understand: http://bill.herrin.us/network/trrp-aapip.html I now recognise that the TRRP Waypoint Router system bears no resemblance to LISP-ALT. You wrote: A waypoint is a combination

[RRG] Security of TRRP mapping replies

Hi Bill, How would you secure each ITR from bogus map replies which pretend to be from the authoritative nameserver? It would be possible for an attacker to send a packet to host X, with source address B. The attacker wants the ITR which X uses to cache some bogus mapping information. The

[RRG] TRRP's micronet length specification?

Hi Bill, It has been a while since I read your TRRP material, but I thought, perhaps incorrectly, that when the ITR queries the authoritative nameserver about some IP address X, it gets a response not just for X, but for the entire micronet of which X is a part. (That micronet could just be for

Re: [RRG] Are host-stack modifications allowed or disallowed ?

Hi Brian, You wrote: I'm thinking that there may be a class of solutions which will work as far as aggregation and scaling are concerned without any host modifications, but would allow host modifications to have substantial impact on traffic engineering for the benefit of sites hosting

Re: [RRG] Process proposal: Conceptual Summary and Analysis documents

Lixia and Tony wrote, in part: Thanks to Robin who reminded us about this (see his msg February 19, 2008 7:00:47 AM PST) and was the first one to submit the requested documents! I missed the deadline by a day or two, but Christian Vogt's documents were there before the deadline. In the event

[RRG] Scaling: ad-hoc to unified or unified from the start?

Short version: TRRP starts off ad-hoc and decentralised with a pre-existing protocol (DNS) for map enquiries. When fully optimised to reduce delays and eliminate bottlenecks, it winds up being a hybrid push-pull system, with dozens

Re: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6 Interworking, Backwards-Compatibility

Short version: I see many problems which would seem to prevent Six/One Router from being feasible for IPv4. Some of these are also relevant for IPv6. Hi Christian, Here is my initial view of your Six/One Router proposal.

[RRG] Scaling, Mobility 228 mapping changes a second

Warning: Long message ahead. Short version:Mapping only needs to change when the mobile node (MN) moves a long distance, such as to another large country or 1000km or more, if the MN uses a Translating Tunnel Router (TTR)

[RRG] For Newbies: ITR, ETR, DFZ, TE, ITRD other terms explained

I received a message from someone who has recently started to follow the RRG list and had some trouble understanding some terminology in the Ivip Conceptual Summary and Analysis document: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf Here is what I wrote, explaining some terms and

[RRG] LISP gleaning looks insecure and therefore unusable

Short version:Gleaning seems to be completely insecure, so I can't imagine how it could be useful. Hi Dino and Team, Here are some questions about gleaning. I am basing these on: http://tools.ietf.org/html/draft-farinacci-lisp-06

Re: [RRG] LISP gleaning looks insecure and therefore unusable

Hello Xiaohu, You wrote: Exactly, but not just this security risk, the cache in ETR may also be overwhelmed by a lot of host-granularity mapping entries which is triggered by some attacker. Yes, this is an additional problem. Resource depletion in ITRs due to DoS attacks is a concern, but

[RRG] LISP PMTU fragmentation problems

Short version:lisp-06's new material on Path MTU limits includes some text on how to resolve the problems if they are deemed to be bad enough to need a solution within LISP. I can't understand this text in any way which

[RRG] Re: LISP gleaning looks insecure and therefore unusable

Short version: My understanding of Dino's response is that my critique of gleaning is correct. His statements seem to be contrary to the description of gleaning in the lisp-06 ID, and look more realistic to me - so I suggest

[RRG] Mapping model discussion - push, pull, hybrids and notify

As noted in a recent message (Agenda) there is an item Mapping Model Discussion for discussion on Tuesday: http://www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaPhily I am not sure what this discussion will entail. Perhaps it will be theoretical discussion of different ways of getting the

[RRG] APT: no need for islands?

Short version:Use tunnels between APT networks which have no direct BGP physical links to carry the APT mapping information with a BGP link over the tunnel - but don't use this link for traffic packets. Then there is a

Re: [RRG] Comments on draft-lewis-lisp-interworking

Regarding: http://tools.ietf.org/html/draft-lewis-lisp-interworking-00 and further to Brian's request for more information on Darrel's: You can consider PTRs optional, but NAT is a core requirement for any sensible interworking between LISP and non LISP-NR sites. I too would appreciate an

Re: [RRG] Comments on draft-lewis-lisp-interworking

Hi Darrel, Thanks very much for your response to my points 1 to 4 in: http://psg.com/lists/rrg/2007/msg00674.html 1 LISP-NAT works when the LISP-NR EID side initiates the connection, true. OK - that is my main critique. A further critique is that the nature of the communication session

[RRG] Anyone want to co-author present an Ivip paper at ACM MobiArch, Seattle, in August?

Is there anyone who would like to present a paper on Ivip's approach to mobility, perhaps as a co-author? I am based in Melbourne Australia and don't have funds for travel. So I can't make it to the 22 August workshop: MobiArch '08 — The 3rd ACM International Workshop on Mobility in the

[RRG] Re: Supposed impossibility of scaling for mobility

Hi Joel, Thanks for your response, in which you wrote: Robin, I think that you are misunderstanding my point. Let me try listing some items I take as givens. Others may disagree. 1) Solving problems that we don't need to solve is going to weaken a solution. (Good solutions will, as

[RRG] Notify = proactive updates; flexible placement of full db ITRs query servers

Hi Tony and Scott, In Re: Generic requirements on mapping mechanisms you wrote, in part: One way of shifting that cost further is for the advertising site to proactively issue updates based on historical requests. Are you suggesting that if the advertising site does this, the caching site

[RRG] Re: Supposed impossibility of scaling for mobility - easy explanation

Here's an easy way to convert an understanding of conventional mobile IP into an understanding of the Ivip approach. This Ivip vision of mobility is very different from Bill Herrin's (message 766). His vision involves the ITRs tunnelling packets directly to Care of Addresses in each access

Re: [RRG] Re: Supposed impossibility of scaling for mobility - easy explanation

Hi Fred, You wrote: The question of mobility interactions with scalable routing was raised (by me) at the MEXT meeting yesterday, and I will be looking to these messages to help formulate requirements that might actually be attainable. I will try to comment in more detail next week.

Re: [RRG] LISP next steps

Hi David, I haven't yet listened to Friday's meeting, so perhaps some of my questions would be answered by that. My understanding of the RRG's role and planned timeline is based on: http://www.irtf.org/charter?gtype=rggroup=rrg http://psg.com/lists/rrg/2007/msg00686.html (2007-12-02)

[RRG] Newbies: Unofficial guide to LISP

There is no central, comprehensive, web page which links to all the LISP Internet Drafts, so I tried to create one myself: http://www.firstpr.com.au/ip/ivip/lisp-links/ This lists all the IDs I know of - past and present - some key documents, and some critiques of LISP. I caution this is is

[RRG] Reactivating the RAM list?

Hi Vince, In Re: LISP next steps you wrote: Since there would appear to be much to discuss in this space and that a great deal of that discussion has now been deemed out-of-scope for the RRG, perhaps it is time to re-active the [EMAIL PROTECTED] list and take the general topic of RA scalling

[RRG] Hosts, DFZ, purity incremental deployment

Short version:In case anyone actually doubts this . . . I try to show why architectural purity of having a completely independent namespace is bound to be incompatible with incremental deployability in the current

Re: [RRG] Hosts, DFZ, purity incremental deployment

Short version: Comparing my notion of incrementally deployable with Tony's. I thought we all agreed on what this meant. Hi Tony, I think it would be good to have a clear definition of incremental deployability - if you and I disagree about it so much, others

[RRG] Mobility, update rates charging per update

Short version: Map-encap direct support for mobility doesn't mean frequent updates, because the mapping change only occurs when a new TTR is used - which only happens when the mobile device moves to an access network ~1000 km distant

Re: [RRG] Mobility, update rates charging per update

Hi Jari, Thanks for this: And I agree with Robin that mobility does not have to imply change of the tunnel router endpoint. This does reduce mapping changes. I am maintaining links to messages and other resources concerning map-encap support for mobility at:

Re: [RRG] What does incremental deployment mean

Short version: The two differing understandings of incrementally deployable may result from asking two different questions. Hi Xiaohu, You wrote: I definitely agree to your opinion. We should not judge whether an approach supports incremental deployment

Re: [RRG] What does incremental deployment mean - 2 questions

Oops, I fluffed the last line in: http://psg.com/lists/rrg/2008/msg00846.html My use of the term incrementally deployable is actually shorthand for something more involved: (9) Is the technology fully or widely deployable in a purely incremental fashion? For this to be true, the

Re: [RRG] On jack-down models - independent namespaces

Quickly:Sorry this is long, but I promise it is of interest to anyone who believes that there are separate namespaces for locator and identifier in an IPv4-in-IPv4 or IPv6-in-IPv6 map-encap scheme. I don't think the word

Re: [RRG] RRG shouldn't try to directly address mobility, including qualifying mobility attributes

Hi Eric, In some ways I tend to agree with you that the RRG shouldn't devote its attention in detail to mobility - which, as you wrote, is a huge and somewhat disjointed field. However, I actually disagree. I think it would be best to have a continued exploration of mobility, as part of

Re: [RRG] Consensus check: mapping granularity

Hi Olivier, I understand from what you wrote: For scalability reasons, I would propose to define this requirement as follows : The identifier to locator mapping function MUST support mapping entries for aggregates of identifiers. It MAY also support mapping entries for host identifiers.

Re: [RRG] What does incremental deployment mean - 2 questions

Hi Philip, I think your question is a valuable one: What's the minimum deployment where the benefit for the party deploying is greater than the party's cost/pain? The answer is quantitative, so it doesn't work as a definition of incrementally deployable on its own, unless you define some

Re: [RRG] Comments on draft-lewis-lisp-interworking

Short version: Agreeing with Joel and requesting the LISP team write a unified account of LISP Proxy Tunnel Routers, with detailed examples. Hi Joel, You wrote: But when it comes to deployment analysis, ignoring the question of who pays, and why, is

Re: [RRG] Text proposal: mapping granularity

Hi Tony, Here are a few potential improvements to your draft text: 3.1.1. Granularity The granularity of the mapping function controls the specificity of the entries that make up the map. Mapping large blocks of identifiers to a common set of locators is highly efficient because

[RRG] Ivip's Open ITRs in the DFZ (OITRDs), formerly Anycast ITRs in the core

Open ITRs in the DFZ is the new name for the ITRs previously known as Anycast ITRs in the core/DFZ. As Darrel Lewis has pointed out to me off-list, and as I think other people have recognised, anycast is not the right word for these ITRs. Thanks Darrel - it has taken me a while to think of an

Re: [RRG] What does incremental deployment mean - 2 questions

Tony Li wrote: I liked Joel Halpern's characterization. I thought he said it all. OK, in Re: [RRG] Mobility, update rates charging per update 2008-03-17: http://psg.com/lists/rrg/2008/msg00833.html Joel wrote: One small aspect that I think I am seeing here is the same words

Re: [RRG] What does incremental deployment mean - 2 questions

environment, in addition to the technology itself. Hi Randall, Thanks for all you wrote in your two messages: Earlier, Robin Whittle wrote: % Still, I think my definition: % % (9) Is the technology fully or widely deployable in a purely

Re: [RRG] Consensus check: mapping granularity

The granularity specification has some unavoidable implementation implications which I think sufficiently impact the scaling of the whole map-encap system that we should make the choices I suggest here. I have changed my preference for IPv6 mapping granularity from an integer number of IP

[RRG] Dynamics of the mapping function

Hi Tony, In your untitled message: http://psg.com/lists/rrg/2008/msg00964.html you wrote: I'd like to turn now to the issue of the dynamics of the mapping function. I understand from this that a new topic is being opened with the aim of arriving at some text for which there is rough

[RRG] Concerns about the RRG process ... how not to design an airliner

Short version:I think the RRG's aim of creating a fresh design for a future routing and addressing architecture runs into problems due to the fact that each viable alternative design involves many inter- related specific

Re: [RRG] Concerns about the RRG process ... how not to design an airliner

Hi Bill and Team, What you are proposing here: We need a comprehensive set of questions that are reasonable across the entire solution tree so that we can do an apples-to-apples comparison of the various proposals. They all solve the same core problem (the current BGP-based DFZ is

Re: [RRG] What does incremental deployment mean

Hi Fred, You wrote: From: Xu Xiaohu [mailto:[EMAIL PROTECTED] Hi Noel and Dino, You can drop the Without that commitment. It's very simple: Any solution that *requires* host changes is infeasible. According to this criteria, many proposals, including v6 EID over v4 RLOC of LISP have

Re: [RRG] Re: Taxonomy: 25 questions

Hi Bill and Lixia, Bill, I will read and respond to your TRRP details later. Thanks for filling in the gaps in my understanding. Lixia, you wrote: Hi Robin, Since your subject line is taxonomy, I'll offer a short clarification reply first, without getting into the specifics of the 25

Re: [RRG] new draft on A Taxonomy for New Routing and Addressing Architecture Designs

Hi Lixia, You wrote, in part: In fact I reread your long critique msg (dated March 10, 2008 6:42:15 AM PDT) last weekend, and I wasn't sure our understandings of the various proposals are entirely aligned. That's one of the things on my list to comment on. On page 1 you seem to indicate

Re: [RRG] Taxonomy: 25 questions - Heiner Hummel's proposal

Hi Heiner, I have never been able to understand your proposal in any concrete sense. I understand you have some radical new way of using the existing IPv4 address space. If you are using some other addressing system, then this means host changes and usage changes for the vast majority of hosts,

Re: [RRG] Taxonomy: 25 questions - Heiner Hummel's proposal

Hi Heiner, Looking at your proposal: http://www.hummel-research.de/nira.pdf I find: IPv4 addresses may stay fairly forever, because they have to be unique only within the same 1x1-square-degree geo-patch. which is impossible for me to reconcile with compatibility with today's Internet,

[RRG] Is ISATAP a practical solution?

Short version: From what little I know about ISATAP, it is not a practical solution to routing scalability or IPv4 address depletion. I explain why I think this and suggest criteria which ISATAP or any other proposal

Re: [RRG] RE: Is ISATAP a practical solution? IPv6 adoption

Hi Fred, I will respond to what you wrote about header lengths and SEAL in a separate thread. You wrote: http://tools.ietf.org/html/draft-templin-ipvlx-08 Yet this ID hasn't been revised since May last year, its abstract doesn't mention the routing scaling problem, and I don't recall it

[RRG] SEAL, PMTUD, IPv6 header bloat, header compression

Hi Fred, in two messages in the Is ISATAP a practical solution you mentioned some things to do with the problem of Path MTU Discovery for ITRs to ETRs, fragmentation of packets etc. - and your SEAL proposal which intended to help with these. http://tools.ietf.org/html/draft-templin-seal-04

[RRG] Moving the problem to the global mapping system

In Re: [RRG], responding to Tony's message of 22 March: http://psg.com/lists/rrg/2008/msg00964.html Michael Meisel wrote, in part: (1) Is the mapping function successful in preventing edge network reachability from being propagated into the global routing system? (2) If yes,

Re: [RRG] Moving the problem to the global mapping system - fast-push

Short version: Discussion of critique that Ivip would not be able to cope with a flood of mapping updates. I think the charge per update model answers that critique - but APT doesn't have such arrangements.

Re: [RRG] Not moving the problem to the global mapping system

Hi Brian, You wrote, in part: I can't say how much I agree with this. If the mapping system degenerates into a reachability-driven routing system, we might just as well switch to two layers of BGP immediately. I would suggest turning this into a concrete goal, such as: strawman The

Re: [RRG] Not moving the problem to the global mapping system

Short version: Brian's strawman criteria and the current map-encap proposals. A note about LISP-ALT having a form of push added, by which ETRs would solicit a mapping request from ITRs which are

[RRG] Newbies: Comparison of NERD, ALT, APT, Ivip TRRP

Newbies trying to come up to speed with RRG discussions might find this page helpful: http://www.firstpr.com.au/ip/ivip/comp/ This is based on a message to the list earlier this month, with extra material from Bill Herrin regarding TRRP. I eliminate the proposals for solving the routing

Re: [RRG] Path MTU Discovery: a new approach

Hi Fred, You wrote: Your proposal needs to talk about the setting of DF in the outer IPv4 header after encapsulation. Based on my 5+ years of studying this, if it sets DF=1, its busted. For the RPD2 probing protocol, the outgoing IPv4 packets definitely are DF=1 and IPv6 packets can't be

[RRG] SEAL IPTM: differing goals

Hi Fred, There are no-doubt mistakes in my attempt to understand your goals and broader assumptions with SEAL - so please correct them. I will write a separate message on how IPTM could be improved to handle IPv4 DF=0 packets. The note below * discusses the possibility of IPTM ITRs sending DF=1

[RRG] IPTM PMTUD with only DF=0 packets

Here are some thoughts on how I may change IPTM: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ to handle the following situation: The only traffic packets longer than ~1200 bytes which the ITR needs to handle are IPv4 packets with DF=0. If there was various length packets DF=1 longer

[RRG] Updates to Ivip analysis and homepage

I have somewhat updated the Conceptual Summary and Analysis document to include the new PMTUD approach and the new OITRD terminology. A changelog is on the homepage, and the original 19 March version is available there too. The Ivip homepage is better organised, and the comparison page has an

Re: [RRG] Arguments against Transport, Translation Six/One Router

Hi Tony, You wrote: Is there anyone other than Christian Vogt who thinks it could be practical? Yes. OK - I assume this means you think Six/One Router is practical, or could be made so - however defined. How is it practical for the 2nd translation router (in the destination provider

[RRG] What do we have consensus on?

Hi Tony and Lixia, Can you list what decisions the RRG has achieved consensus on? I think clarity on these points would help us reach consensus on whether to keep open discussions about solutions in the Translation and Transport areas of the total possible solution space. For instance, is

  1   2   3   >