Comments

Wed Aug 31 21:16:31 UTC 1994

	 Milo -

	   >I think there is also an issue with the fact that the ADSU's can't 
	deal
	   >with anything other than PVC's.  In my opinion, we really need to
	   >move to an SVC environment ASAP to simplify the VC management issue
	s.
	   >Large numbers of PVC's are going to be a royal pain to tend, esp. i
	f
	   >they have to be configured manually.  I can just imagine the proble
	ms 
	   >stemming from asynchonous updates of VC configurations by the vario
	us
	   >attachees at the NAP's.

	 I would agree except for the fact that the peering relationships are

	 a) to be established only after humans negotiate, and then are

So, let's say that you have a route server there that's distributing 
routes, and it tells you the next hop is some IP address that is talked
to via a VC that isn't configured?  You can't send the packet to the RS,
since he's not acting as a forwarder.  

Do you really expect that if you end up with 40 or so providers at a NAP
that everyone will have bilateral agreements with everyone else, AND that
all the RS configuration information is going to kept in sync with this
and the VC configuration (that the NAP providers does, not the RA right?)?
This is a lot of human interaction, and I gurantee you short cuts are 
going to happen.  

Also, just because you have a bilateral agreement between parties, that
doesn't mean necessarily a single VC, esp if an NSP ends up with
multiple routers being physically or logically attached to a NAP (switched
technology is great ain't it?) for redundancy or load balancing reasons.

Also remember that at least some of the NSP's will have to carry R&E traffic
without recharge, and that means lots of folks will be expecting more
than just bilateral agreements with everyone at the NAPs.  This will also
likely swell the number of entities who will want attachment there.

	 b) likely to be maintained long term.

Equipment changes, and so does the number of participants at the NAPs.  You
may be assuming the the NAP is only catering to the needs of the big NSP's,
and therefore so few parties will be involved that it's not a major effort,
but that is inconsistent with the marketing literature I've seen from
PacBell (who is actively trying to sell T1 access to Pacific Rim countries)
and others.  I'll agree if you can keep the total number of parties down
to a few (like at the FIX'es), then I agree it's not as big an issue.  But
then someone ought to tell PacBell and the other NAP providers this.

There are a wide variety of trade-off's that have to be made in building a 
robust interconnect.  You can't optimize for everything.  Right now,
I wish people could just agree that's true and put in a process for 
deciding what is the most important and what isn't.  This clearly isn't 
happening now, and I think different people all have different views 
and that's contributing to the confusion.  Until people realize that
the NAP's are not going to be all things to all people, we'll never get
a good analysis of the tradeoffs for how we should implement and 
use them.  And this will endanger the success of the backbone transition 
effort.  

						Thanks,
						   Milo