Bill, I am sympathetic to your sentiment on the proposed RFC1490 approach to build the NAPS particularly because so many people labored so hard to come up with RFC 1577. However, as one of the person involved in the NAP proposal, I would like to point out RFC 1483/1577 over AAL5 with LLC/SNAP has always been our goal since at least one year ago. Given that we have the same goal, it appears to me what you are objecting to is the use of a temporary solution to meet the time table imposed on us. Since changing the time table is not a viable option, I am curious if you have other suggestions in mind? I am asking this question just want to make sure that we did not miss anything significant in our collective decision process.
The difficulties with the RFC 1490 approach were listed in the Toronto meeting. I list them here:
There is no clear migration path from this approach to a more correct/robust implementation using RFC 1577 encapsulation over native ATM (OC3c).
My conversation with Cisco indicates that 1490/AAL5 software patch for AIP is available and 1483/AAL5 for ADSU and 1483/AAL5 for T3-AIP should be available withing about 6 months. So, indeed ther are several migration path available, not clear which is the best for all NAPs. Perhaps different NAP location may have different business needs based on what their customers desire.
There are additional points of failure and additional costs with the requirement for an ADSU.
I think HSSI is a proven technology. HSSI/ADSU probably has lower failure rate than AIP based on the typical bath tub curb for new product reliablity.
The listed approach requires manual configuration.
I like the flexibility of AIP, but how to configure AIP to avoid congestion is still a research topic for me.
This appears to lock the NAP into a top speed of 45Mbps or DS3 speeds.
Hopefully, we can unlock this as soon as we feel comfortable with other approaches. BTW, I think the Merit paper is useful and good work as you said. Since RFC1490 is the only viable option exposed to Merit, saying it is one of those is a bit too harsh. Liang
Thank you for your insightful comments. I would like to be enlightened on exactly how a proposed migration from RFC1490 to RFC1483/1577 will occur. As I understand it, there needs to be a translation method between NLPID and LLC/SNAP. There seem to be other locations in the stack where translation must occur. Is there capability today or even planned that will do these translations?
There is no clear migration path from this approach to a more correct/robust implementation using RFC 1577 encapsulation over native ATM (OC3c).
My conversation with Cisco indicates that 1490/AAL5 software patch for AIP is available and 1483/AAL5 for ADSU and 1483/AAL5 for T3-AIP should be available withing about 6 months. So, indeed ther are several migration path available, not clear which is the best for all NAPs. Perhaps different NAP location may have different business needs based on what their customers desire.
True.
There are additional points of failure and additional costs with the requirement for an ADSU.
I think HSSI is a proven technology. HSSI/ADSU probably has lower failure rate than AIP based on the typical bath tub curb for new product reliablity.
The points of failure are the additional cables and connectors, not to mention the electrionics of a seperate box (the ADSU) and power. These cost, plus the extra rack space and potential co-location fees to accomodate this extra gear. Your concerns wrt infant mortality on new hardware seem to apply to the ATM switches in general. Most of the equipment, while being "long in the tooth" as far as cell switching capability is concerned, has a -very- limited exposure to data transmission. Even the closed ATM Forum has trouble standardizing specs that appear to be needed to support full interoperability (just when will UNI3.1 come out and when will the text be available on-line?... but I digress)
The listed approach requires manual configuration.
I like the flexibility of AIP, but how to configure AIP to avoid congestion is still a research topic for me.
As it is for everyone. The manual configuration specified here is the need to code static routes and ARP entries to make BGP4 work. Traffic shaping does not even come into this equation.
This appears to lock the NAP into a top speed of 45Mbps or DS3 speeds.
Hopefully, we can unlock this as soon as we feel comfortable with other approaches.
HISSI at faster than 45Meg? I am very interested. Please tell me more.
BTW, I think the Merit paper is useful and good work as you said. Since RFC1490 is the only viable option exposed to Merit, saying it is one of those is a bit too harsh.
Perhaps. My biggest concern was that the Merit paper would be construed as the -only- way an ATM NAP would work. They clearly did not indicate there were potential choices nor did they indicate the assumptions that were made for their test. -- --bill
Perhaps. My biggest concern was that the Merit paper would be construed as the -only- way an ATM NAP would work. They clearly did not indicate there were potential choices nor did they indicate the assumptions that were made for their test.
Bill, now I doubt if you read the paper carefully or not. First of all, this paper does not design the ATM-NAP architecture BUT is a ROUTING DESIGN for the planned ATM-NAP architecture. Please don't confuse these two different issues. For the planned ATM-NAP architecture (i.e. RFC1490/AAL5) with the current availability of the RS's (i.e. SUN) ATM interface product, what other choices do we have to connect the RS and do NAP routing at this time frame? --Jessica
Perhaps. My biggest concern was that the Merit paper would be construed as the -only- way an ATM NAP would work. They clearly did not indicate there were potential choices nor did they indicate the assumptions that were made for their test.
Bill, now I doubt if you read the paper carefully or not.
Oh I read it. Several times. I even think I can claim to understand what you were saying.
First of all, this paper does not design the ATM-NAP architecture BUT is a ROUTING DESIGN for the planned ATM-NAP architecture. Please don't confuse these two different issues.
Your routing design is clever & solves a series of interesting issues that are raised when level 3 activities are needed in a sub-optimal level 2 environment. Good Job.
For the planned ATM-NAP architecture (i.e. RFC1490/AAL5) with the current availability of the RS's (i.e. SUN) ATM interface product, what other choices do we have to connect the RS and do NAP routing at this time frame?
Native implementation, while a bit fuzzier in the near-term (1-6 months) has many longer term benefits (see the notes from Milo et al on this thread) and does not present the ISP with the potential of "forklift" replacment of (expensive) equipment in less than a year. Some ISPs may see this cost a "noise" in comparison with the overall picture while many more will see this as a major captial item with a 3-5 year payout. Can we afford to live w/ a 1490 implementation for that long? I, for one, give the net and its denizens the benefit of the doubt. I would expect the trafic loads on the infrastructure to exceed 45Mbps before 3 years. Now the main problem I have is that there is a gap in product availablity. There are only a handful of vendors looking at solving these problems for people. If Cascade is successful, then part of my argument folds. However, this product is further behind the release curve than other vendors solutions. No easy way out of the mess, but there are alternatives to RFC1490 implementations that have much more flexability and are feature rich. I think we should be willing to experiment and test before we foist a 1490 model onto the unsuspecting ISPs and hang ourselves with a deadend technology for years. Mind, I am willing to buy off on a crippled, brain-dead, solution IF there is no other way. I just want it to be VERY clear that I won't go willingly and I want others to know why. After all, everyone is entitled to my opinion. :) --bill
First of all, this paper does not design the ATM-NAP architecture BUT is a ROUTING DESIGN for the planned ATM-NAP architecture. Please don't confuse these two different issues.
Your routing design is clever & solves a series of interesting issues that are raised when level 3 activities are needed in a sub-optimal level 2 environment. Good Job.
Thank you! That is what the paper is about i.e. a routing design for a given ATM-NAP protocol stack selected at the ATM-NAP workshop. It identifies the routing issues and present a solution to it. --Jessica
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 issues. Large numbers of PVC's are going to be a royal pain to tend, esp. if they have to be configured manually. I can just imagine the problems stemming from asynchonous updates of VC configurations by the various attachees at the NAP's. I also happen to believe that the network management issues associated with an ADSU are more complicated and make it harder to debug problems than with a native inboard unit like an AIP, but I realize that none of the other major router vendors are shipping AIP equivalent devices right now (and the AIP is a nice piece of work to be sure). This means that if you don't support the ADSU's, you pretty much lock people into use of ciscos, which I oppose on the principle of assuring multivendor interoperation. That issue isn't cisco's fault of course, but rather that we're being rushed to put immature and still evolving ATM technology into a critical piece of the operational Internet infrastructure before it really makes sense to do so because of marketing and regulatory issues, but that's another story. :-) Thanks, Milo
That issue isn't cisco's fault of course, but rather that we're being rushed to put immature and still evolving ATM technology into a critical piece of the operational Internet infrastructure before it really makes sense to do so because of marketing and regulatory issues, but that's another story. :-)
Tongue Firmly Planted in Cheek... "The Internet is an experiment and should not be depended on for production service" - zippy "imature and still evolving" ... like 64meg in routers bgp4 idrp mbone ..... ipv6? --bill
> That issue isn't cisco's fault of course, but rather that we're bein g > rushed to put immature and still evolving ATM technology into > a critical piece of the operational Internet infrastructure before i t really > makes sense to do so because of marketing and regulatory issues, but > that's another story. :-) > Tongue Firmly Planted in Cheek... "The Internet is an experiment and should not be depended on for production service" - zippy "imature and still evolving" ... like 64meg in routers Needed because the network is growing so fast. bgp4 Needed to support CIDR to prevent the previous point from killing everyone. idrp Not clear this is the same league as the above. Noone uses CLNP for anything serious at this point (at least across the Internet) right now. mbone ..... ipv6? Noone is forcing anyone to run mbone or ipv6 right now. The issue behind the NAP's is that they could have been engineered to use simpler and more mature interconnect technology at the start, but are instead using immature technology to meet non-technical requirements that the customers of the NAPs are not they themselves imposing. This is a fundamentally different issue that the above items you raised. Noone disagrees that ATM will be playing a significant role in the future, but I have serious problems with pushing it into service early and forcing all of us to deal with the consequences now rather than waiting until things have calmed down later and less pain will be required on our part, and that we would have better multivendor support. And I will point to the fact that ATM isn't being used in the other interconnects like the CIX, the FIXes, SWAB, MAE-East, etc... So I will disagree that ATM is required for this sort of thing. Thanks, Milo
In message <199408312318.QAA08553@cincsac.arc.nasa.gov>, "Milo S. Medin" writes: | The issue behind the NAP's is that they could have been engineered to | use simpler and more mature interconnect technology at the start Agreed. | [...] deal with the consequences now rather than waiting until things | have calmed down later and less pain will be required on our part, and that | we would have better multivendor support. Also agreed, especially wrt the priority NAPs. Admittedly, though, NSF likes to test out new technology, and while their stated goal is to ensure full connectivity between their clients and everyone else, I imagine that they don't mind a bit of unproven technology being used to accomplish that goal. | And I will point to the fact that ATM isn't being used in the other | interconnects like the CIX, the FIXes, SWAB, MAE-East, etc... So I will | disagree that ATM is required for this sort of thing. I agree with you that ATM is not needed, however, fast packet is fast packet is fast packet, whether you layer something on top of it or not. SMDS is being used at the SWAB and will be offered as an access method into the CIX. MAE-EAST and the D.C. NAP (currently) do ethernet (and FDDI) layered on top of ATM. I am not a fast-packet fan, and some of my colleagues (at Sprint and elsewhere) agree with me. Others like fast-packet/cell-relay, but agree that it has some maturing to do before it's relied upon for anything critical, especially when it comes to touching down with other NSPs. We tend to prefer stabler, simpler technologies, and that's reflected (among other places) in the MAE-EAST+ development in the Gallows Road MFS colocate space which we will use instead of SWAB or the D.C. NAP, our desire to use the two FIXes as primary peering points, and also in design of the Pennsauken NAP. Sean. - -- Sean Doran <smd@sprint.net> SprintLink Engineering +1 800 669 8303
Sean, After a series of conversations and meeting today Karl and I have decided to connect NET 99 to MAE east. While there is a congestion problem there I would expect to see improvement in the near future. Many other NSP's have been pushing us in that direction and I feel that we have made a good choice. We are NOT going to be connecting to any of the NAPs at this point. Given the many other points available to us it makes sense for us to avoid the NAPs and " Just Say No " at this time. If the market changes in the future, along with the technology we might re-consider. Joseph Stroup Telecommunications - Network Consultant Mr. Packet says: Don't Delay, Re-route Today !
milo: I think idrp is multi-protocol not clnp specific. ipng and ip is just fine. Sue
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 issues. Large numbers of PVC's are going to be a royal pain to tend, esp. if they have to be configured manually. I can just imagine the problems stemming from asynchonous updates of VC configurations by the various 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 b) likely to be maintained long term. Bill
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
I don't think anyone ever expected the NAP's to be all things to all people. 1. Someone please name 10 commercial providers that will attach to ALL the NAPs. 2. Why even do this in the first place ? Joseph Stroup Telecommunications - Network Consultant Mr. Packet says: Don't Delay, Re-route Today !
01- RealTimeRUs Net 02- BlockbusterNet 03- GameNet 04- 1900 05- MJ/PP music&videos 06- TPCinc 07- NBC 08- EDS/RJR 09- Sprint 10- MCI Everyone else is next tier as a reseller or vertical niche player. Or did you not want the 5 year view? --bill
I am very glad to see it. Dumb me, no one ever posted it to the other lists and I think its important, Thanks, Joseph Stroup Telecommunications - Network Consultant Mr. Packet says: Don't Delay, Re-route Today ! On Wed, 31 Aug 1994 bmanning@ISI.EDU wrote:
01- RealTimeRUs Net 02- BlockbusterNet 03- GameNet 04- 1900 05- MJ/PP music&videos 06- TPCinc 07- NBC 08- EDS/RJR 09- Sprint 10- MCI
Everyone else is next tier as a reseller or vertical niche player. Or did you not want the 5 year view?
--bill
Whoa!! Sarcasm is so hard these days. The attached list of 10 is fiction. Pure and Simple. It was ment to point out that the players on the NAPS will change over time and that my PERSONAL impression is that the big-boys with Madison Ave backing (obscure US specific reference for advertizing folks) will bury the existing commercial players in the next few years. This is only after I have been off my chocolete ration for too long and I am depressed.
I am very glad to see it. Dumb me, no one ever posted it to the other lists and I think its important,
Thanks,
Joseph Stroup
On Wed, 31 Aug 1994 bmanning@ISI.EDU wrote:
01- RealTimeRUs Net 02- BlockbusterNet 03- GameNet 04- 1900 05- MJ/PP music&videos 06- TPCinc 07- NBC 08- EDS/RJR 09- Sprint 10- MCI
Everyone else is next tier as a reseller or vertical niche player. Or did you not want the 5 year view?
--bill
-- --bill
I thought you were serious. Because I agree that most of the big advertisers and content people are in fact considering building their own networks. Marty
Whoa!! Sarcasm is so hard these days. The attached list of 10 is fiction. Pure and Simple. It was ment to point out that the players on the NAPS will change over time and that my PERSONAL impression is that the big-boys with Madison Ave backing (obscure US specific reference for advertizing folks) will bury the existing commercial players in the next few years. This is only after I have been off my chocolete ration for too long and I am depressed.
I am very glad to see it. Dumb me, no one ever posted it to the other lists and I think its important,
Thanks,
Joseph Stroup
On Wed, 31 Aug 1994 bmanning@ISI.EDU wrote:
01- RealTimeRUs Net 02- BlockbusterNet 03- GameNet 04- 1900 05- MJ/PP music&videos 06- TPCinc 07- NBC 08- EDS/RJR 09- Sprint 10- MCI
Everyone else is next tier as a reseller or vertical niche player. Or did you not want the 5 year view?
--bill
-- --bill
NBC is an ISP? m
01- RealTimeRUs Net 02- BlockbusterNet 03- GameNet 04- 1900 05- MJ/PP music&videos 06- TPCinc 07- NBC 08- EDS/RJR 09- Sprint 10- MCI
Everyone else is next tier as a reseller or vertical niche player. Or did you not want the 5 year view?
--bill
Marty asks the clueless newbie..
NBC is an ISP?
Bill decides to detail the whole list for the edification of the entire network community, exposing himself as a naive user and very weak politico. So yes Marty, NBC is an ISP... Network Bits Cabal - The newest ISP. :)
01- RealTimeRUs Net
ToysRUs & ILM/Disney spinoff
02- BlockbusterNet
Videos on demand
03- GameNet
Sega & Nintendo join forces
04- 1900
Smut online
05- MJ/PP music&videos
Michael & Prisilla Join forces w/ Prince & Madona to wipe out Music TV
06- TPCinc
Mr. Smyth does global printing
07- NBC
See above
08- EDS/RJR
Madison Ave sells the consumer dream
09- Sprint 10- MCI
Leave token existing players just so the whole market does not change. My Goodness, It sure seems that there is no sense of humor these days. -- --bill
participants (9)
-
Bill Norton -
bmanning＠ISI.EDU -
Jessica Yu -
Joseph W. Stroup -
ltwu＠faline.bellcore.com -
Martin Lee Schoffstall -
Milo S. Medin -
Sean Doran -
Susan Hares