Tony,
> > Michael Thomas wrote: > > So I have a question for those who support > > connected site locals: what would prevent a new > > RFC from updating Brian's wording for site locals > > (if that's the right thing)? > > > > I say this because it seems to me that there's a > > lot of issues being conflated in these arguments > > and what's sort of frightening to me is that they > > need to be teased apart. In particular, the desire > > for provider independent addressing seems to > > factor in here fairly largely too, and I wonder if > > the better part of valor might not be to get > > together a BOF which focuses on the actual real > > life requirements here. It's possible that site > > locals in the end might make sense here, but it's > > also possible that it can be done other ways too > > (or that the entire problem is totally intractable > > which is the way it looks to me now). > > > > Some of the uses for SL would be better served by PI > addresses, but not all. > > Take the case of a 20,000 node network where half are allowed > global access and half are not. It is much more complex to > sort through a 10,000 node list per packet for access > filtering than it would be to have two entries, SL deny & PA > allow. Yes the list of which 10,000 nodes are allowed the > global prefix has to be maintained, but it can be applied > according to allocation policy rather than per packet processing. > I miss something here. How do you make sure that nodes configure just site local and not global address on seeing an RA ? Are you keeping them in separate networks i.e not mixing nodes that require globals and site locals ? If so, then I can do the same with globals with appropriate partitioning i.e subnet 1 - 100, is for private use only. Then the check is very simple. Could you clarify ? thanks mohan > Yes we need a PI format, and there are a few being batted > around on multi-6, but even there we are into engineering > trade-offs about allocation efficiency vs. routing table > exception handling efficiency. My intent was to bring a PI > format proposal to this wg after multi-6 established > requirements, but that wg seems to have been derailed into > the long running saga of overhauling the entire protocol > suite. If there is interest in discussing a PI format to get > that off the table for the SL discussion, I will ask the > chairs to consider it as a WG doc. > > Tony > > > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
