Re: Evaluation: draft-ietf-pilc-link-design - Advice for Internet Subnetwork Designers to BCP

[Alex Zinin <zinin@psg.com>]

Harald,

> Ignoring the specifics of your message and what to do with the specific
> document.....

> the basic problem seems to be that if you have

>  IP router --------- IP router -------- IP router
>            --------- IP router --------

I would even use something like this:

 [Rtr]---\                 /---[Rtr]
 [Rtr]--- [Rtr] .... [Rtr] ----[Rtr]
  .         :          :
  .       [Rtr] .... [Rtr]
 [Rtr]--/                  \---[Rtr]

i.e., the number of "edge" routers is usually higher
than those in the backbone...

> on the physical layer (middle routers are layer 2 and layer 3 devices), and 
> the subnet technology forces you to act as if you had

>  IP router ---- Cloud
>  IP router ---- where all hops
>  IP router ---- look the same
>  IP router ----

not only this one, even if you represent the cloud as a collection
of virtual p2p interfaces, you still have the same O(N^2) problem
if you want any-to-any connectivity. Configuring hub-n-spoke usually
didn't work, because it increased the packet delay and didn't allow
to use BW effectively.

> then IP routing will not be optimal, either in terms of resource usage
> or in terms of convergence time and amount of state kept.

yep

> the cloud is presumably implemented because one wants other services to run 
> across it, so just converting the links to IP-over-foo is not an option.

correct

> seems to me one viable design approach would be to allow IP to limit its 
> usage of the subnet technology to the hops that have real simple physical 
> mappings - much as one used to manually configure ATM PVCs that followed 
> the fiber ducts while there was still thought to be a potential market for 
> non-IP use of ATM.

see above. the PVCs would tend to follow the connectivity graph over
the cloud, so we end up with the same problem

> the general issue used to be ROLC once upon a time. For a while I thought 
> it had transmogrified into CCAMP.

> But it's one of those architectural issues that doesn't seem to go away.

Indeed, and I hoped that we've learned our lessons :)

Alex