Re: Draft on ISP broad-band deployment scenarios

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 24 Sep 2004, Salman Asadullah wrote:
> > > &&&
> > > 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).
> &&&

Right.  This consideration wrt. multicast might be worth spelling out 
somewhere.

> >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 :-)

Great :)
 
> 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 ?
> &&&

Sounds like a good approach.  Note that the choice probably also
depends a lot on what the BB ISP thinks their customers' status (and
willingness) wrt.  IPv6 support is.  If the customers employ a lot of
NAT boxes or similar, they might have to take these scenarios into
account as well, and provide a tunnel service to those people.

> >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.

Thanks!

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