Re: Draft on ISP broad-band deployment scenarios

[Salman Asadullah <sasad@cisco.com>]

Hello Pekka,

Please see our response below between &&&.

At 09:58 AM 9/22/2004 +0300, Pekka Savola wrote:
> Hi,
>
> Sorry for not getting back to this earlier :-(.. inline..
>
> On Fri, 10 Sep 2004, Adeel Ahmed wrote:
> > Please see my responses inline with +++++++++++++++:
> > 
> > At 02:43 PM 9/7/2004 +0300, Pekka Savola wrote:
> > >Sorry for the delay in responding.. inline...
> > >
> > >(I've removed some comments which we seemed to agree or be
> clear
> > >about.)
> > >
> > >On Wed, 1 Sep 2004, Ciprian Popoviciu wrote:
> > > > >On Thu, 19 Aug 2004, Pekka Savola wrote:
> > > > > > Adeel Ahmed, Ciprian Popoviciu, and Salman
> Asadullah from Cisco did a
> > > > > > lot of work in a very short time and produced a
> really extensive
> > > > > > scenarios document discussing the IPv6
> deployment scenarios for
> > > > > > broadband (DSL, cable, etc.).
> > > > >
> > > > >A couple of general observations:
> > > > >
> > > > >  0) is the document aiming to only describe the
> scenarios, or is the
> > > > >goal to also provide analysis where potential gaps
> have been
> > > > >identified, and where e.g., a tunneling mechanism
> would be needed?  If
> > > > >the latter, it probably needs to be expanded a
> bit.
> > > >
> > > > @@@
> > > > Pekka, to put this document in perspective, here are some
> elements of our
> > > > original intent:
> > > > - focus on production type deployments. We did not intend
> to discuss 
> > > tunneling
> > > > unless it is the only alternative currently available due
> to 
> > > limitations of
> > > > a given access
> > > > technology (cable).
> > >
> > >OK, though I'm not sure how certain types of tunneling solutions
> could
> > >not be considered "production" (or sufficiently near
> that) to be
> > >useful on a larger scale.  The justification for that is that
> there
> > >may be lots of equipment that is not IPv6-capable, and having to
> wait
> > >for it to be replaced to be able to offer (or get) IPv6
> connectivity
> > >may be a big assumption for deployment.
> > 
> > 
> > +++++++++++++++
> > Our goal in this draft is to get SPs to move towards deployment
> of
> > native IPv6. So leading to such deployments tunneling would be
> a
> > stepping stone for the SPs. However, considering that there 
> are
> > native deployments today, we wanted to focus more on them
> rather
> > then on the transitional phase in which it might be rather
> difficult
> > for an SP to generate revenue from a tunnel based service till
> they
> > move towards native IPv6 deployments.
>
> 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.

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

>  
> > In the case of Cable (section 5) we had to talk about tunnels due
> to
> > the current limitations in DOCSIS but all the other access
> > technologies discussed in the draft are ready for native IPv6
> > deployment today. 
> > +++++++++++++++
>
> The approach depends on the ISP's strategy.  If it wants to offer 
> services to just those which have the right kind of set-up, no 
> interfering NAT boxes, their own wireless routers, or whatever, that's
> fine.  But I'm quite concerned about making such assumptions, because
> in practice that implies that the deployment gets much more difficult
> and demanding (also due to need for financial justifications) for the
> users.
>
> > >The question I was asking was whether you intended to analyze
> the
> > >applicability of different methods for getting IPv6 connectivity
> (in
> > >case there would be multiple: for example, where you cite 6to4,
> there
> > >could very likely be others as well, possibly even more suitable
> than
> > >that), or just pick one (or none) and describe how that would
> work.
> > >In other words, I was interested whether you were
> considering
> > >"generic" deployment (with as few assumptions as
> reasonable, about,
> > >e.g., equipment at the customer's premises), or
> "specific" deployment
> > >(where you could or could not assume some things, like being
> able to
> > >upgrade a certain box or having public IPv4 addresses).
> > >
> > >The document would certainly seem to be most useful if it
> was
> > >sufficiently "generic", but a "specific"
> document is also better than
> > >nothing ;-), provided that the assumptions are very clearly
> spelled
> > >out.
> > 
> > +++++++++++++++
> > We've actually tried to be specific in sections 6,7 & 8. We've
> used
> > kind of a generic approach in section 5 due to the current state
> of
> > cable networks and the limitations in DOCSIS. We will try to
> spell
> > out some of the assumptions more clearly in our next revision of
> the
> > draft. 
> > +++++++++++++++
>
> OK.  Please also state clearly the caveats of "native only, if 
> technologically possible" approach (discussed above, for
> example).

&&&
Sure. Will do.
&&&


> > > > >  2) the document seems to
> make some assumptions e.g., when it 
> > > specifies to
> > > > >use 6to4 e.g., for cable.  Are all of the networks
> using public v4
> > > > >addresses?  What if the customer has deployed a NAT
> box so that the public
> > > > >address is consumed by that box?  Further, I'm not
> sure whether the
> > > > >situation where the customer has deployed some
> equipment has been 
> > > considered
> > > > >throughout the document.
> > > >
> > > > @@@
> > > > Again, it is a case very specific to the current state of
> Cable
> > > > access.
> > >
> > >Do you mean that cable operators are widely offering a public
> IP
> > >address per customer?  However, I'd venture to guess there are
> a
> > >significant number of operators which only give private
> addresses to
> > >begin with.
> > 
> > +++++++++++++++
> > Actually that is a common practice with most Cable
> > Operators. We've worked with major Cable providers in the
> America,
> > EMEA and APAC regions and they all offer public IP addresses 
> to
> > their customers. 
> > +++++++++++++++
>
> OK, please make this assumption and justification explicit in the 
> document.

&&&
Sure. Will do.
&&&


> > > > Nevertheless we could probably
> offer more detail for this
> > > > case. For example, one solution would be to have the box
> that is
> > > > doing the NAT for the user also terminate the 
> tunnel.
> > > >
> > > > This is another point that we need to clarify however, the
> Gateway
> > > > Router (GWR) can be SP owned but also it can be customer
> owned and
> > > > in that case it would reflect a customer deployed
> equipment like a
> > > > box that does NAT for v4.
> > > > @@@
> > >
> > >Exactly, this cuts both ways: one approach could be to assume
> that the
> > >NAT box (which may be beyond the control of the SP) is upgraded
> --
> > >this could take quite a long time to achieve.  Another approach
> could
> > >be to provide mechanisms which work irrespective of NATs --
> there are
> > >already a plenty of those, for example Teredo, and some
> others
> > >probably to come (think of "configured tunneling over UDP
> with
> > >keepalives"), in one form or the other.
> > >
> > >I think what you were assuming that you only need to care about
> the
> > >case of upgrading the NAT box.  That may be acceptable with
> certain
> > >assumptions about the deployment (if that's the case, they must
> be
> > >very clearly spelled out), but it may not be sufficient in
> more
> > >general -- so if you agree that one would want to provide v6
> access
> > >also when there are NATs or other obstacles in the way, one
> such
> > >approach is to specify v6 connectivity mechanissm which work
> through a
> > >NAT.
> > 
> > +++++++++++++++
> > That's a good point, we will make a note of that in section 5 where
> we 
> > discuss initiating a tunnel from
> > the host. Since our goal is to provide IPv6 access natively this
> should not 
> > be an issue for other technologies.
> > +++++++++++++++
>
> OK.
>  
> > > > @@@
> > > > These are deployment issues that we could elaborate a bit
> more on. The
> > > > provider usually
> > > > is not responsible for the additional equipment added by
> the customer and
> > > > under the
> > > > constraints of a service deployment that is limited by the
> current 
> > > state of
> > > > DOCSIS it is likely that
> > > > the provider will have to provide a new device to the
> subscriber. We will
> > > > add a note on this
> > > > topic.
> > > > @@@
> > >
> > >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.
&&&

> > >OK -- I'm just having trouble
> visualizing any ISP doing so, because
> > >that might directly jeopardize their IGP to the customers.. and
> I'd be
> > >interested in hearing why they would be doing something like
> this (is
> > >this some kind of backup routing plan for some SOHO customers or
> the
> > >like or what).
> > 
> > +++++++++++++++
> > 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.

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

> and 2) would want to use something as
> "unreliable" (with some definition of unreliable) as Cable,
> instead of
> DSL, Serial, Ethernet.

&&&
Sure, there are pros and cons with every technology. 
If you ask me personally, I prefer Cable over DSL :-)
&&&

>  
> > > > >6.2.1 POINT-TO-POINT MODEL
> > > > >
> > > > >
> > > > >==> this model has the built-in assumption that ATM
> is used as
> > > > >point-to-point.  Is this strictly necessary, or could
> you just use any 
> > > other
> > > > >media as well?
> > > >
> > > > @@@
> > > > Could you please clarify this comment?
> > > > @@@
> > >
> > >I meant that wouldn't it be possible to use e.g., Ethernet
> (instead of
> > >ATM) as the point-to-point uplink?  I haven't seen this myself,
> but
> > >I've heard reports of such deployments..
> > 
> > +++++++++++++++
> > We've discussed this in the FTTH section 7.2.1. So we did not really
> assume 
> > that only ATM will be used as a point-to-point uplink.
> > +++++++++++++++
>
> But couldn't you provide ADSL (instead of FTTH or Ethernet to the 
> home) using Ethernet or something like HomePNA on the uplink instead
> of ATM?
>
> I don't know enough of the deployments to be able to say whether
> "ADSL
> with Ethernet-like uplink" and "FTTH" are synonymous, but
> if I had to
> venture a guess, I'd say there's probably some difference
> there.

&&&
Sure.  We'll investigate some of the differences.
&&&


> > > > @@@
> > > > Why would you see it as a bad practice having the router
> acquire via 
> > > stateless
> > > > autoconfig an address for the uplink to the provider? We
> should probably
> > > > discuss
> > > > all options for completeness purposes.
> > > > @@@
> > >
> > >Well, if you have a router, I'd generally expect it to act as a
> router
> > >on all of its interfaces.  There has been some debate of this
> mixed
> > >"host/router" behaviour on IPv6 WG list before, but I
> think the
> > >conclusion has been that mixed host/router is acceptable by the
> specs
> > >at least.  I'd however personally rather see that the routers in
> these
> > >situations would have other means to configure an address (if
> they
> > >need one).
> > 
> > +++++++++++++++
> > We've seen customer interest in using this approach for IPv6
> therefore we 
> > discuss it in the draft.
> > Similar approach is also available in IPv4.
> > +++++++++++++++
>
> Please state explicitly that this is takes a mixed host/router 
> approach to ND.

&&&
Sure. Will do.
&&&


> > >These arguments should maybe go in
> the draft, but still keep in mind
> > >that MLD/IGMP have not been meant to authenticate the
> users.
> > >
> > >I'd expect that the same features can be obtained with encrypted
> data.
> > >You would get the key which would be valid only for some time
> from a
> > >web server, and that key would be only valid for a certain
> stream.
> > >That way you could get the keys etc. only only those parts of
> the
> > >transmission you'd want.  There are possibly other approaches. 
> MSEC
> >
> >(http://www.ietf.org/html.charters/msec-charter.html)
> WG has been
> > >looking at this problem.
> > 
> > +++++++++++++++
> > We do realize that there are multiple ways of doing this but we went
> with
> > MLD authentication approach because we have seen requirements for
> this
> > from customers and it's a rather simple approach.
> > 
> > But we will try to add more explanation in the next revision of the
> draft.
> > +++++++++++++++
>
> Thanks.  Justification and listing the caveats is
> good.

&&&
And thanks for your time and continuos valuable feedback :-)
&&&

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