On Sat, May 8, 2010 at 9:57 PM, Paul Jakma <[email protected]> wrote:
> On Sat, 8 May 2010, Dae Young KIM wrote:
>
>> It seems your idea is based on global IP addressing. What I have in mind
>> is to get rid of global addressing.
>
> Yes, I gathered that, but it's unnecessary AFAICT.
>
>> So, IDR routers look only at AS numbers, not at IP addresses which bears
>> no meaning in IDR.
>
> Sure, but why? :) What problem are you trying to address? If you're trying
> to force aggregation by AS, then why not use an IPv6 prefix that embeds the
> ASN? Basically, the underlying forwarding technology isn't the problem - the
> problem is finding a good way to apply some higher-level structure to it.
>
> IPv6 almost certainly has the room to accomodate any reasonable addressing
> structure that can't fit with IPv4. If you're proposing a solution that
> requires all forwarding infrastructure to be upgraded, it'll have to have
> amazing benefits, and be impossible to layer onto IP.
>
> Also you need to consider "Why do we currently have ASes that originate
> multiple disparate prefixes?".
Yes, the correct question.
Well... let me try. Let's take the case of IPv4 which is facing more
imminent/urgent routing scalability problem.
What is the maximum size (in node) of operating domains that are
managed by an intra-domain routing? Would 2*16 be too big? .. and they
don't do prefix aggregation in intra-domain routing, or do they?
It happens that AS number is also 16 bit, although larger AS numbers
began to be issued. Would you still need prefix aggregation if the
prefix (or the AS number) is 16 bit long? If not, you can apply LS
routing also to inter-domains.
In fact, I won't be against virtual prefix, either; IRON, RANGER,
Ivip, etc. Even with virtual prefix,
o Addressing can be local within domains(or enterprise or site).
Any addressing in fact; IPv4, IPv6, and even CNLP/NSAP. Or any other
addressing if you deal with sensor or smart dust networks. Freedom to
users.
o DNS query would return
Destination address (of any type) + Domain virtual prefix
o Virtual prefix would be imbedded in the option field of packets.
(Or some people might prefer to put it in outer encapsulator).
o Virtual prefixes will be mapped to prefixes provided by ISP's at
exiting the domains.
o Since prefixes provided by ISPs will be used in DFZ, prefix
aggregation will take place much more effectively, to combat routing
scalability.
o Or tunneling can take place in DFZ as in IRON or similar ones.
One burden here is to manage virtual prefixes and mapping to PA
prefixes. Since it seems most people are read for this additional
mapping, it's OK to me, too.
Or.. perhaps, I'm drifting around again...
>
> regards,
> --
> Paul Jakma [email protected] Key ID: 64A2FF6A
> Fortune:
> Nihilism should commence with oneself.
>
--
Regards,
DY
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
