Tony & Joel, outbound traffic is the topic that I'm trying to have a discussion on, sort of "first mile traffic engineering" at an enterprise.
I'm taking this scenario a little bit further, the link between attachment point B and the corresponding ISP goes down - then we have a black hole because nor the host neither the DNS system is aware of the link failure. One way to overcome this situation would be to create a "link state protocol" between ILNP border routers and the DNS , e.g. if the upstream link fails the DNS becomes aware of this and once DNS is aware of this situation it updates the records, updates its own clients so they can send out ICMP messages to their correspondents. This sounds a little bit scary to create a dynamic protocol between the routing system and DNS - I'm not really comfortable with this approach but let us have a look on the option. For outbound traffic from client A via either attachment point B, C and D you would use today the 0/0 route concept towards one of the attachment points, in this case B. From there you would use local preferences to go out via the preferred border router - but this is today prefix based. So if you could add a new attribute for ILNP, i.e. "local identifier preference" to iBGP and each identifier can be given an own value you can direct outbound traffic per host to either attachment points B, C and D (and achieve load balancing). But to minimize administrative tasks you should be able to set the metric of the "local identifier preference" at one place, e.g. DNS which then informs the border routers how hosts should use the attachment points. So perhaps a "link and identifier state protocol" is needed between the routing system and DNS .... I'm still not happy what this "link and identifier state protocol" approach. If I have three attachment points I would prefer to use all three points concurrently for each host, i.e. a multipath transport protocol would be great. We have had SCTP for a while but is not widely deployed and I believe the reason is that it cumbersome and expensive to deploy a multipath enabled enterprise network from client A to the attachment points B, C and D. You need to have three separate networks, three identical security architectures that needs to have the same security rules - the economics are not there - it just become too challenging to build, maintain and troubleshoot. And I'm afraid that MPTCP will have the same problem to get deployed in an enterprise network for the very same reasons - mobility is a different issue If ILNP could have a shim header where the host A sets the preferred outgoing attachment point you could create a "first mile traffic engineering" solution, i.e. you can establish three separate paths from client A to the attachment points B, C and D. Some routers in between needs to able to read the shim header and switch the packets to the correct paths. The border router for the initiator shouldn't rewrite the locator, instead the border router in front of the responder would swap the locator headers (as in hIPv4). The outcome would be that the hosts are located by an edge locator value and one or several core locator values - the great thing with this approach is that the economics for multipath transport protocols arrives. Only one NIC on the hosts, only one local network at the enterprise and also one security architecture - which could be build upon the identifier values and _not_ on the locators. But then you should be able to protect your identifier from being stolen, and here I haven't made my mind up - should I trust ILNP that it will protect my identifier or should I prefer HIP to take care of the identifier...... Also, it seems that "link and identifier state protocol" between the routing system and DNS is no longer needed - responsibility to solve the black hole issue is on the transport protocol. Thoughts? Also, I might have missed something... -- patte On Fri, Jun 4, 2010 at 12:44 AM, Joel M. Halpern <[email protected]> wrote: > I believe that Patrick is asking about outbound traffic routing, not > inbound. > > Which is very reasonable question to ask. > > Unfortunately, until we are prepared to make a much larger set of changes, > we do not have the tools to allow a host to choose which outbound site > connection is used by the hosts outbound traffic. (There are many use cases > which would like those capabilities, but we have not found a good way to > deliver them.) > > yours, > Joel > > Tony Li wrote: >> >> >> On 6/4/10 5:21 AM, "Patrick Frejborg" <[email protected]> wrote: >> >>> A question regarding ILNP and multi-homing scenario. >>> The primary path from A towards Internet goes via attachment point B >>> and this is announced in DNS. Then ISP taking care of attachment point >>> B have some performance problems and the service is not good enough >>> for host A - he decides to switch to attachment point C and updates >>> DNS. But how does the packet get routed from host A to attachment >>> point C instead of B in large enterprise network where there could be >>> a lot of routers and some security nodes between the host and the >>> attachment points? >>> I don't want to tweak the local routing domain but when I change the >>> DNS records host A should start to use new attachment point (C), some >>> other hosts might still use the old one (B). >> >> >> In ILNP, a host controls how packets arrive by changing the locators that >> are advertised. Outbound, intra-domain packet routing is separate, and >> COULD be based on the hosts source locator, but this is a separate >> enhancement that we could make. >> >> Once the host updates DNS with the C locator, it should also concurrently >> send ICMP locator updates to its active correspondents and inform them of >> the C locator. >> Tony >> >> >> _______________________________________________ >> rrg mailing list >> [email protected] >> http://www.irtf.org/mailman/listinfo/rrg >> > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
