[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft on ISP broad-band deployment scenarios

Hello Pekka,

Please see my response between &&&.


At 10:32 AM 9/24/2004 +0300, Pekka Savola wrote:
Inline...

On Thu, 23 Sep 2004, Salman Asadullah wrote:
> >There are native deployments today, but AFAIK they have been
> >relatively small scale (thousands of users).
> >
> >The crux is whether the ISP wants to (try to) offer service to *all*
> >of its customers, requiring no hardware upgrades or purchases, with no
> >assumptions about what the user has deployed -- or just those which
> >are OK the assumptions, upgrades/purchases, etc.
> >
> >I'm concerned that if we focus too much on "native only", only
> >(relatively) few users will likely be able to get the service.
> >
> >It's true that it may be difficult for an ISP to generate revenue out
> >of e.g., tunneling based service, offered to anyone, but if some ISP's
> >are still interested in this kind of approach, would it be worth
> >considering?
>
> &&&
> This is true but we have observed many of the BB ISPs are interested in
> deploying native IPv6, driven by new services such as VoD using Multicast
> and etc. Some of the examples for these BB ISPs, who are deploying IPv6
> are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in
> France, XS4ALL in The Netherlands and etc.

Sure. But do these ISPs use a link-layer which supports multicast,
e.g., bridged-mode DSL (I think it does..)?

That is, if you do something like L2TPoE (which I think many are
doing), doesn't that require that multicast transmission be
duplicated (on a lower layer) in any case, causing equal amount of
traffic as a tunneling based distribution?

&&&
Well, some might go for L2TPoE but not necessarily. We discussed that option for the sake of completeness and in case some SPs really, really like that model but .... if they do go for L2TPoE then yes, they will not gain much new. On the other hand we talked about the alternatives where the IPv6 traffic is routed while the IPv4 is still L2TPoE. That is for example the case of one of the biggest BB ISP who are providing IPv6 commercial services, where IPv4 is L2TP but IPv6 is routed. They did that for the very reason as they wanted to deploy mcast over it (what you referring to).
&&&

 
> Our intent in this draft is to the make the worldwide BB ISP community
> aware of possible options available to deploy IPv6 natively today.
>
> We agree that for some ISPs the native IPv6 solution would not be feasible
> due to several reasons as you mentioned previously, with the information
> provided in our draft, some ISPs might realize that the extra investment
> for a native deployment might make sense for their long term
> goals. Besides, for some countries this might be a viable option, think of
> Japan, Korea and some other countries where the ISPs are getting tax cuts
> from the government, if they deploy IPv6.
> &&&

Extra investment is always possible, and many will certainly do it.
The question is just how the ISPs would transition from "v4-only" to
"v4+v6 natively". My argument is that it would be easier for the ISPs
to start with tunneling and native v6 where possible, than to require
through-out upgrade to native v6.

That would reduce the number of up-front investment requirement, but
would not prevent from making the investment when it's clear that
there will be demand for the service.

That would also make it more lucrative to the customers whcih have
boxes that don't support v6. They wouldn't have to upgrade
immediately to get that service..

&&&
Ahh ....

We totally agree on this and finally understand where you are coming from :-)

In order to achieve the above and make this document complete and beneficial for all, we should include the tunneling options as well for remaining environment, FTTH, DSL and Wireless.  Tunnelling options for Cable is already discussed (off course we have noted all the comments and feedback which we will address in the next revision of the document).

So, we think we would need couple of more things:

1. A general summary section up front stating the intent of the document and available deployment options (tunneling and native).
2. Add a general tunneling section for FTTH, DSL and Wireless sections as another option. We believe this section would be general since we can simply talk about the different tunnelling solutions available and reasons of choosing one or the other and point the reader to the respective tunnel draft/rfc for details.

This will make the document complete with both options available in one place for all the BB ISPs.  Depending on what stage the BB ISPs are, they can chose whatever they want.

Does this sounds like a good plan ?
&&&


> > > >This is one approach, as noted at the start of the message; another is
> > > >providing tunneling support. Both could be feasible, depending on
> > > >deployment, but the latter is more generic at least.
> > >
> > > +++++++++++++++
> > > Right, so cable operators currently do provide a GWR which is managed by
> > > them. In order
> > > to deploy IPv6 the operator can upgrade or replace this GWR with a v6
> > > capable device.
> > > +++++++++++++++
> >
> >Right. But my practical concern is that if it costs the ISP XXX XXX $
> >to replace the GWR's with ipv6-supporting versions, but XXXX $ (XXX
> >XXX >> XXXX) to provide tunneling support, I'd guess most ISPs would
> >be interested in going for tunneling first, and just looking at
> >replacing GWR's based on their natural EOL schedule.
>
> &&&
> You are correct, the first step in some cases will be tunneling (for
> example cable).
>
> But in other cases BB ISPs are taking the next step and inclined more
> towards the native deployments
>
> Also the extra cost might be justified by the:
>
> - Services provided and charges ($$ earned) over IPv6 like VoD, video
> streaming, IPT and etc.
> - Tax cuts received by the governments for IPv6 deployments
> - and etc.
> &&&

See above. I think all services which are available over native v6
can be offered, at least initially, through tunneled v6. If it's
still possible to get the service profits, and reduce the amount of
initial investment, why wouldn't the ISPs do it?

&&&
Sure. Agreed upon.
&&&



>
> > > +++++++++++++++
> > > This is currently a normal practice for Cable Operator's business
> > customers.
> > > There are only a handful of these customer routes which are summarized and
> > > redistributed into the Cable Operator's IGP. This is not really meant for
> > > residential
> > > customers which account for majority of the customer base.
> > > +++++++++++++++
> >
> >But what I don't understand is why the business customers would 1)
> >need dynamic routing in the first place (what is the actual reason for
> >using a routing protocol?),
>
> &&&
> The cable business customers in todays world get a /27 or something
> similar. The issue is how does the CMTS keep track of which business
> customer owns that particular /27 and how does it get advertised to the
> rest of the world. One way to do this is to use static routing but the
> problem is that if the cable modem goes down, the CMTS will end up black
> holing that traffic and vise versa, thus requiring an IGP. There are
> several reasons of using RIPv2, out of which a simple one is that there are
> hardly any CM/GWR which support OSPF.

But the point is, unless those business customers have backup
connectivity, over which they also use the same IGP, the packets will
be discarded in any case, so it doesn't seem to matter whether static
routing does it whether they are discarded due to lack of a route.

The only difference (unless the business is multihomed, and I think
you said only few were) is whether the CMTS sends back an ICMP
unreachable message to the hosts trying to connect to the business,
before it discards the actual packet. That doesn't seem worth the
cost & complexity.

Further, putting an IGP there will allow business customers to hijack
any addresses w/ appropriate prefix advertisements, practically
requiring duplicating the ACLs at the CMTS side to allow only the
valid prefix. But with the same trouble you could do a static route.
 
> Today's cable deployments uses this, so we had to discuss it in the draft
> to make it close to reality. The BB ISP will use RIPng as they were using
> RIPv2. We felt this explanation is out of the scope of this document so we
> did not include.
> &&&

It's OK to say they use RIPv2 and thus RIPng seems applicable, but it
seems also justified to point the discussion above, that routing
protocol is not needed unless you're multihomed or you care a lot
about sending ICMP unreachables when the link goes down. It's also
worth noting the filtering requirement for the routing protocol, to
prevent hijacking.

&&&
Sure. We will incorporate both options in the next revision.

Another point to note that in last mile BB environment dual/multi-homed scenarios are hard to find.  Cable ISPs use dynamic routing since they find it much more convenient.  If they have to configure couple of hundred static routes at each CMTS, in large deployments, it adds up and becomes hard to manage.  Again, this is how it is done out there.
&&&

This has been a great discussion which clarified lot of points and hopefully will make this document to be very beneficial in years to come.

We would like to thank you and all the individuals on the list for their interest and valuable feedback (we have received several unicast replies with good points and valuable feedback).

We will integrate all the feedback in the next revision.

Regards,
Salman Asadullah
Technical Leader
Cisco Systems, Inc.


--
Pekka Savola                "You each name yourselves king, yet the
Netcore Oy                   kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings