Mark, At 05:54 PM 12/9/2002, Mark Smith wrote:
I was trying to see how many bits I could have left over and still use the EUI-48 as the basis for the global token. I think I agree that it would be simpler just using the whole 48-bits and shrink the area.Hi Bob,A few thoughts / questions / comments on your draft : 3.0 Proposal & 3.1 Global Token * 8 bit areas I'm curious as to why you chose to allocate 8 bits for the area. Allocating 6 bits for area would allow aggregation to take place on the /16 bit boundary. I think this would make it a easier for network admins to manage their site-local area prefixes when bounded at /16. I was going to suggest putting back the u and g bits, which would make connecting to the origin router for this prefix easier (just telnet to fec0 + EUI-64 + EUI-64), but then realised that your site local global token is generated from an EUI-48 :-( I think there probably is some value in keeping the full EUI-48 as the global token for trouble shooting reasons, at the sacrifice of 2 area bits.
I agree. I think one of the good things about this approach is that could be made to auto-configure the subnets. I wasn't attempting to solve all of the issues to make that work in this draft.3.2 Assignment * maybe be a bit more explicit about how manual configuration is achieved. I agree with and understand the motivation for manual assignment of these prefixes. However, the whole proposal has a strong "auto-configuration" theme - deriving site-local addresses from EUI-48s sounds a lot like something that would be done automatically by default.
Would a typical implementation of this manual assignment be a toggle switch / [on / off] configuration option within a router ?
I agree adding some text to clarify how this could work would make it clearer. Semi-automatic might be a good way to describe it. The administrator could be give a choice of creating a prefix based in the interfaces EUI-48 address, enter a global token, or use a prefix it has heard advertised from another router. This would make the installation of the routers fairly simple and in most cases avoid typing in big strings of digits.If so, additional text suggesting that these prefixes will be automatically generated, but manually enabled / disabled (defaulted to disabled) might help overcome the "auto-configuration" theme of the generation of these prefixes.
The use of area was not coincidental. I was thinking about OSPF areas as that is probably about the right size to flat route a number of subnets.* the term "area" might be a bit vague, in the sense that usually people talk about "areas", they are referring to OSPF areas. I found when I initially read this term, I immediately wondered whether this field has some use or value wrt OSPF.
Another question is the area field that useful or would it be better to just have /64 prefixes and flat route them in a site. This might make the proposal simpler and better. On the other hand, it is nice to have a way of scaling the routing protocol inside the site.A different name for this field might be a bit less confusing. - I don't feel that strongly on this, I think it is just that "area" is in such common usage in the OSPF context (and to my knowledge, no where is in IP routing / addressing), most people would immediately associate any usage of the term "area" in an RFC with OSPF.
Thoughts?
Bob
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
