Hi Lixia, A comment inline
On Tue, Nov 17, 2009 at 9:29 AM, Lixia Zhang <[email protected]> wrote: > > On Nov 10, 2009, at 11:28 AM, Tony Li wrote: > >> Lixia Zhang wrote: >> >>> 2/ most importantly, I was calling attention to Postel's comments on >>> slides 7 & 8: these quotes were taken from the meeting minutes then: >>> - “Transport layer ID is not an issue that we >>> need be concerned with for now. Once we >>> decide what to do for IP addresses, then >>> transport people can easily figure out how >>> they may use the address.” >> >> >> Well, what we already know is that we want our routing tokens to be >> changeable. We need hierarchy in the address space to provide scalability. >> We have seen that we need to form that hierarchy on the topology, > > the above seems a general statement that everyone would agree. > the real question is: are we talking about a single address hierarchy that > everyone's routing table would conform to, or somewhat different hierarchies > as viewed from different ASes... > >> otherwise we have to morph the topology to fit the hierarchy, and morphing >> the topology is expensive. So when a host changes its position in the >> topology, the routing token needs to change. > > I could not decipher the last sentence: when a host changes its attachment > point, its IP address changes -- do you mean routing token = IP address? >> >> Unfortunately, that breaks the transport connection. > > depends. > there exist multiple implementations today that do not break transport > connections when host change IP addresses. > If you have hierarchy in the address space you will have two types of locators (IP addresses), one locator that is describing how your endpoint is connected to the local network (ELOC) and the second locator describing how your local network is attached to the Internet (ALOC). If the endpoint changes inside the local network (endpoint mobility) then the connection gets disconnected, you would need Mobile IP or HIP in order to survive. But if your attachment locator (ALOC) changes in a multi-homing solution the ELOC will not change, not for the local endpoint nor for the remote endpoint - it is only the remote or local ALOC value that changes when network failure occurs. And today the applications do not see any ALOC values at the API, only ELOC values, i.e. local and remote IP addresses. So when the border routers detect a network failure, the border router could replace the ALOC value with the backup path's ALOC value, route the packets via the backup path using policy based routing and the endpoints can continue without knowing that a redundant path has been taken. Or the border router could send an ICMP message to the endpoints so that they are aware that ALOC values changes and the endpoints changes the ALOC values themselves - but the application is not aware of the change since the ELOC values remains intact. But then we have the security issues - it would be a nice tool for the dark side to hijack connections by sending out ICMP messages form the Internet, wouldn't it? So something needs to be added somewhere, IMO the transport layer should carry session identifier so that the endpoints are aware of the change in the path, or the endpoints negotiate the change. And even better if the transport layer is multi-path capable, load balancing is achieved and also a much faster network convergence for the application can be provided. And endpoint mobility inside the local network can also be supported. I'm working on to add an appendix in my draft for the scenario above, adding a more detailed description than above. It seems that it is possible to migrate from a multi-homing solution towards a multi-pathing solution if there is a little bit more intelligence in the endpoints - outcome is that the workload of the network gets decreased - a better balance between the endpoints and network is achieved. It will though take some time before it is ready (time constraints) - I also need to add a section regarding NAT, thanks to Fred Templin's presentation I found a use case for NAT. -- patte >> We already understand enough about the routing token and the transport >> token to understand that we need to fix this overloading. >> >> >>> - “We must avoid circular dependencies; >>> - “we must define a substrate of the >>> system that can operate without DNS. ... >>> - “we must not depend on DNS to >>> bootstrap the core operation of the >>> system” >> >> Relevance? I have yet to see one proposal make this mistake. > > Do not depend on DNS to get packet delivered. > > >> Note that using the DNS and creating a circular dependency are two >> different things. We're already at the point where DNS is a fundamental >> requirement for Internet operations. > > for Internet applications. > >> If you cannot resolve www.google.com, www.yahoo.com and www.cnn.com, then >> for all practical purposes, the net is down. > > yes, from end users view point. > But we still want to be able to send IP packets even when DNS is done. > > Lixia > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
