> The fundamental difference is the assumption about what is a reasonable > network topology. It is absolutely wrong to turn off SL just because a > global exists, because neighboring nodes on a single wire may have local > policy to be globally visible or not.
it is absolutely wrong to expect apps to deal with a mixture of SLs and globals, because that forces those apps to develop their own addressing and routing schemes, essentially making any notion of SL to indicate 'policy' irrelevant. > Insisting that SL gets turned off > because one node on the wire needs a global creates a very unreasonable > burden to manage access lists, particularly if that node moves around > between segments that would otherwise have no global nodes. well, I'd probably agree with that, because it provides an easy way to attack an isolated network that was legitimately using SLs. still, a network that is using globals shouldn't be using SLs. > Again, I am sympathetic to the point that multi-party apps should refuse > to refer a SL if any of the members has a global, but that is at best a > BCP targeted at app developers. it would never get published as a BCP because it's not a good practice to recommend - first because the app has no way of knowing in advance whether any of its (current or future) members has a global, and second because this prevents referrals between hosts in the same scope from going through an intermediary that doesn't share the same scope. in other words, it forces apps to know about topology. and for similar reasons that it's not okay for SLs on the net to fail when they happen to see a global, neither is it okay for apps to start refusing to refer SLs when they see a global. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
