Cable Modem [really more about PPPoE]

The other would be to Wholesale the last mile connection to the ISP
customer. In this scenario you need to hand off the end user traffic to
your ISP customers.
DHCP alone is not a viable option in this model. How do you get the end
user traffic to the ISP and back in a pure IP environment? Policy routing,
GRE, MPLS, force your ISP customer to interconnect at every location,
etc.?

Hello Chris;

You provide frustrating few details and a statement "DHCP alone is not
a viable option in this model." Could you restate more concretely
what is your design problem which can only be solved by
ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some
constraint I don't know about.

At this point ATM and PPPoE become considerations each with its own
advantages. If the service offering is business class ATM may be preferred
(required by your customer) for COS/QOS. From a configuration management
standpoint PPPoE has advantages especially in a residential environment as
you do not need to reconfigure the PVC when the end user changes
providors.

What follows is not directed at you personally, but you happened to say
the wrong thing at the wrong time :slight_smile: Apologies in advance.

<rant>

I don't believe any of this "ATM is the way to do" COS/QOS crap. I
have had it in my face for 10 years (my graduate work in the early
90's was performance of IP over ATM. This just in: it sucks.) IPoATM
has never worked; prove to me it will work, then we can talk.

Same goes for MPLS, with knobs on.

Fat pipes; big buffers; simple protocols; get out of the way.

</rant>

We avoided doing DSL (much) until Etherloop and Ethernet was available
because ATM sucks so much. I don't have much sympathy for people who
decided otherwise. They knew, or should have known, the problems with
the ATM pvc approach.

If IPoATM worked; Ethernet would have been dead long ago.

In a wireless environment this becomes even more of a consideration as
most of the current hardware is limited in ATM or L3 functionality...

I am sincerely sorry you are stuck using broken hardware. As a person
who has thrived by deliberately passing up "the latest thing" until
the proper hardware was available to implement good designs, I urge
you to question your assumptions about whether using broken hardware
is a good idea.

I do not intend to argue one technology over another, just to point out
that there are reasons PPPoE exists and is in use.....

Reasons don't equate to good reasons :slight_smile:

A good network design also needs to consider the business model of the
company it supports.

I couldn't agree more! But the converse of that is true; the business
model of a network company should reflect good network design. I
believe the only workable model for networking companies is to have
network engineers involved at the highest levels. That is, they have
to have veto power over decisions. I don't understand how people
think they can thrive in an industry in which they do not have at the
senior level deep knowledge of the product.

My undergraduate degree was in English; my graduate degrees are in CS.
I worked for nine years at BBN before starting this company. Our COO
was an a EE and a practicing network/compuer engineer for years before
he got his law degree. Our CFO was a CPA, but has been in the
commercial Internet business since its inception (ANS/AOL/UUnet).
Technical experience works for us, while I note success does not seem
to be widespread in the industry.

regards,
fletcher

The constraint is that outbound packets need to go to the right ISP. That
is, the packets need to go through the carrier network according to the
business relationship, not according to the destination IP address.

Some method of identifying the ISP associated with each outbound packet is
necessary. Policy routing, tunnels and PVC's are a few methods. VLAN
tagging works, too.

-Steve

>
> You provide frustrating few details and a statement "DHCP alone is not
> a viable option in this model." Could you restate more concretely
> what is your design problem which can only be solved by
> ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some
> constraint I don't know about.

The constraint is that outbound packets need to go to the right ISP. That
is, the packets need to go through the carrier network according to the
business relationship, not according to the destination IP address.

Some method of identifying the ISP associated with each outbound packet is
necessary. Policy routing, tunnels and PVC's are a few methods.

Ditto

VLAN tagging works, too.

Ouch:)

>
> > DHCP alone is not a viable option in this model. How do you get the end
> > user traffic to the ISP and back in a pure IP environment? Policy routing,
> > GRE, MPLS, force your ISP customer to interconnect at every location,
> > etc.?
>
> Hello Chris;
>
> You provide frustrating few details and a statement "DHCP alone is not
> a viable option in this model." Could you restate more concretely
> what is your design problem which can only be solved by
> ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some
> constraint I don't know about.

The constraint is that outbound packets need to go to the right ISP. That
is, the packets need to go through the carrier network according to the
business relationship, not according to the destination IP address.

This isn't necessarily the case. Take a look at rent-a-POP dialups. UUNet sells services to LOTS of ISPs from all of its POPs. The RADIUS authentication has to get to the proper ISP, but the traffic certainly does NOT travel to the ISP's network before going out into the world. Traceroutes from your dialup account will show that the traffic goes directly. UUNet charges the ISP a fee for the use of the dialup, and UUNet provides a relaying of the RADIUS traffic to the right ISP, and provides transport for the end user's packets.

The same scenario COULD be used in DSL or cable setups. That's not to say that it will be.

Some method of identifying the ISP associated with each outbound packet is
necessary. Policy routing, tunnels and PVC's are a few methods. VLAN
tagging works, too.

Right. Assuming the business model where the ISP actually handles the traffic.

[..]

This isn't necessarily the case. Take a look at rent-a-POP dialups. UUNet
sells services to LOTS of ISPs from all of its POPs. The RADIUS
authentication has to get to the proper ISP, but the traffic certainly does
NOT travel to the ISP's network before going out into the world.
Traceroutes from your dialup account will show that the traffic goes
directly. UUNet charges the ISP a fee for the use of the dialup, and UUNet
provides a relaying of the RADIUS traffic to the right ISP, and provides
transport for the end user's packets.

.. which btw could be anything. Could be proxy RADIUS or proxy DHCP or
whatever.

The same scenario COULD be used in DSL or cable setups. That's not to say
that it will be.

If I may add my $.02...

I think you hit the nail right on the head. And cost pressure is what *may*
change that COULD to a WILL. (Seems things have to get a lot worse before they
will get really better).

Seems that the model works for dial because nobody has any ill conceived
notions about needing to 'own' the last mile like connection to the subscriber
to offer value add services. For two reasons: a) people have realized that
there really isn't much value in owning dial POPs anymore and b) it's difficult
to add much of any value add services to the link itself because of the limited
bandwidth.

This notion of selling value add services and 'owning' the subscriber is
something very commonly found in broadband networks.

Sure, you could send broadcast quality TV down a DSL pipe, but who's actually
doing this as a generally available service?

Dial appears to be such a low end commodity that people have given up on that
type of model, and just want to get folks on the net with a certain quality of
access but that's about it. Isn't that the one thing what most if not all
DSL and cable lines achieve?

Seems to me that there's too much marketecture driving these deployments, and
that the rent-a-POP model could drive cost down considerably. Which would mean
that all of us would be better off for it. Those who object to rent-a-POP
models typically are the same that think # of hops matters vs actual
latency/quality of service/access and believe that video etc services must
always be supplied locally to be working properly. Again, clueless
marketecture methinks.

I don't claim to have a solution, I just find it interesting that there appears
to be a fairly narrow horizon in this area, when it has clearly been proven
that folks are willing to live with the other model just fine. The rent-a-POP
model's sole weakness is an organization's inability to work out a proper
business model...

Now, what does all this have to do with DHCP or RADIUS? Well, in the
rent-a-POP model, nobody cares how the actual authentication and accounting is
done as long as it is accurate and fits the billing system needs of the
wholesale customer. Whatever works, is relative to the other options cheapest
and most reliable (offering the greatest economies of scale) is the one that's
chosen...

Do I carry a religion either way? Not really. Seems that DHCP & DynDNS
integration is more readily available than RADIUS & DynDNS... But that's just
my opinion and not a representative survey.

Cheers,
Chris

>The constraint is that outbound packets need to go to the right ISP. That
>is, the packets need to go through the carrier network according to the
>business relationship, not according to the destination IP address.

This isn't necessarily the case. Take a look at rent-a-POP dialups. UUNet
sells services to LOTS of ISPs from all of its POPs. The RADIUS
authentication has to get to the proper ISP, but the traffic certainly does
NOT travel to the ISP's network before going out into the world.

Well, are we talking about carrier transport or a wholesale Internet
access? For UUNet to do this is a perfectly acceptable business
relationship. For SBC to do this is a big no-no.

The same scenario COULD be used in DSL or cable setups. That's not to say
that it will be.

I suppose an unregulated DSL provider could do this. However, I would not
assume that even the DSL CLECs would be permitted, so I'm not sure such an
animal exists. In any case, I know that this was _not_ what our customers
wanted when I was working for a DSL CLEC. They represented their business
access products on the strength of their transit arrangements and support.

Now, if we're talking about purely residential services, it's potentially
a different ball game. Price and ease of use are king -- more so than
redundancy and consistent performance.

Cable providers act as ISPs. If they offer wholesale Internet access,
rather than carrier transport, then they can run their networks like UUNet
dial POPs. I think most of them still offer neither...

-Steve