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

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


> - present the possible deployment scenarios and identify the major elements
> for each one in terms of enabling IPv6 services.
> - highlight changes that have to be made in the deployment process and some
> issues that the SP has to keep in mind while planning such a deployment.
>
> As you can see, the document is rather large as it is so we did not consider
> going into more detail then we already did. We did want however to underline
> topics that should be kept in mind during deployment, even items that should be
> further investigated. We believe that this approach is what you mentioned above
> but maybe we need to highlight more some aspects of the document. Could you
> clarify
> your comment above so that we make sure we properly understand the changes you
> suggest? We would like to make this work as useful as possible.
> @@@

This is partially clarified later in this message, esp. point 1)
below.

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

> > 1) the doc seems to be lacking large-scale v6 enablement
> >considerations, w/o customer interaction and manual config. That is,
> >at least in section 5, I got the impression that for the customer to
> >enable v6 over a tunnel, the customer and the ISP would have to do
> >some manual configuration. This seems unscalable and unfeasible.
> >Shouldn't we try to have mechanisms where the nodes automatically
> >detect if IPv6 is available through a tunnel, and activate it if so?
>
> @@@
> This is a good point that we should elaborate on. It is also true that
> while in some cases simple provisioning is available (use of autoconfig or
> DHCP-PD) in others there might not be a solution available today. In such
> cases,
> based on your comment above, it looks like you would like to see us clearly
> identify such limitations and possibly open the door for further work. Is this
> correct?

Yes -- I don't see it as a problem that a document idenitifies gaps or
room for further work.  That's good, because at least some folks
already have their own view on what's needed, and by writing it down
we can discuss and get (hopefully!) agreement on what's needed.

Note that there has already been work in progress in some of these
areas (see, for example,
http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-01.txt).

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

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

> >  3) there's duplicated text in very many of the sections which applies
> >to about all the scenarios, for example:
> >
> >    Depending on the design of the edge portion of the ISP network, some
> >    Edge Routers might have to run iBGP for IPv6. In this case it is
> >    expected that two peer sessions are established between the Edge
> >    Router and a pair of redundant Route Reflectors.
> >
> >.. instead of duplication, would there be a good logical place to put
> >all the "generic considerations" wrt. access networks (e.g., about
> >prefix summarization, etc.) into a dedicated section? -- And just
> >describe the access-network -specific issues under the access
> >network.. that might remove duplicate text and make the document more
> >concise.
> >
> >This might force the reader to think about the generic issue and how they
> >map to the specific access network scenario a bit more, but it would
> >probably improve the readability and correctness.
> >
> >The tradeoff of course is that each access network description would no
> >longer be readable on its own without reading the rest, but that should
> >probably be acceptable ... as it is, there seems to be significant overlap
> >with the sections, especially with DSL, Ethernet, and WLAN, but a bit
> >otherwise as well.
> >
> >If that was done, it might be possible to push down from 60 pages to
> >20-30 pages, and even increase the amount of unique content in the
> >process.
>
> @@@
> Before writing the document we actually discussed this topic amongst
> ourselves. Our thought is that some items might seem similar between
> sections but they might not be in all their details. Moreover, we
> did want to provide each Access Technology section a certain
> completeness and independence in order to make the sections more
> readable, without having to send the reader very far through
> referencing. Even if we were to compress the repeated subsections we
> doubt that the document will shrink to only 30 pages. We received
> pro and con arguments on this topic so for now we would like to keep
> it in this format as it might even be easier to further flesh out
> some sections based on the feedback received. As the document
> evolves we can revisit the formatting if it proves advantageous.
> @@@

Would there be some kind of middle-path, e.g., a section describing
more generic considerations which are actually common to all the
access networks (or close enough)?  I'm a bit afraid of the scenario
where we'd have to include identical text in 5 different sections if
we figured out we needed to add some common text :)

But if you believe this is sufficient at this point, I can live with
it.  I've just seen (in the past) a lot of work getting spent in
keeping the text in sync, and I wanted to avoid that if possible.

+++++++++++++++
Your point is well taken. For now we would like to keep the format as it is to maintain consistency among
different sections. We can revisit this issue in the future.
+++++++++++++++

> >==> actually, the current recommendation (RFC 3177) is even larger: a /48
> >per home :-). This should probably be mentioned..
>
> @@@
> True. We sort of touched on that with our DHCP-PD recommendations. There
> are also
> SPs that might assign prefixes between /48 and /64 with the intent of charging
> for address space.
> @@@

Yes, seems inevitable -- but let's just hope they'd still give at
least /64 or something like that, instead of /128's.

> > 2. IPv4 Cable (HFC) Network, GWR at customer site
> >
> > In this case the cable network, including the CM and CMTS remain
> > IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This
> > scenario is also easy to deploy since the cable operator just needs
> > to add GWR at the customer's site.
> >
> >==> is this necessarily this simple? What is the cable operator already has
> >deployed v4-only GWR for other purposes? Does it need to be upgraded to
> >dual-stack? Or what if the user has added a box of its own, e.g., a
> >firewall/NAT/wireless router? I guess it again needs to be upgraded.
>
> @@@
> 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.
+++++++++++++++

> >5.2.2.2.4 Routing
> >
> >
> >    For 6to4 tunneling,a static 2002::/16 route and a default IPv6 route
> >    can be manually configured on the GWR with the IPv6 address of the ER
> >    as the next hop. A similar IPv6 route will need to be configured on
> >    the ER pointing back to the GWR at customer site.
> >
> >==> does that require manual configuration at ER for each customer?
> >Hopefully not! (AFAICS, there's nothing needed for 6to4, but manual
> >tunneling would need it.)
>
> @@@
> We will discuss provisioning in more detail and hopefully this question
> will be answered in
> that context. It is worthwhile to note that we don't advocate the use of a
> specific tunneling
> mechanism for this temporary solution for Cable Networks. We will more
> clearly identify
> items to be considered when making the selection for the tunnel but the
> selection will
> be left to the person planning the deployment.
> @@@

OK --  Analyzing the different mechanisms is fine.  However, if it
requires IETF specification, there must be some document that makes
the decision what needs to be specified (if not everything).  It
doesn't need to be in this doc, though.  (This was my point zero at
the start of the message -- whether this doc was intended to
include analysis, and if so, how much of it...)

+++++++++++++++
We do understand your point. We will try to address this in our next revision of the draft.
+++++++++++++++


> > If using maunual tunneling, the GWR and ER can use static routing or
> > they can also configure RIP-ng. The RIP-ng updates can be transported
> > over a manual tunnel, which does not work when using 6to4 tunneling.
> >
> >==> is there a particular usage case for RIP-ng over cable modem to the GWR?
> >I can't see any valid scenario for doing so....
>
> @@@
> This is a valid point. We need to provide more context to the statement,
> but it is worthwhile
> to note that it is a current practice in IPV4 networks where business
> customer do run RIPv2
> between the CM/GWR and the CMTS. Those customer routes are redistributed in
> the ISP's IGP.
> @@@

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


> > The CMTS/ER should protect the ISP network and the other subscribers
> > against attacks by one of its own customers. For this reason uRPF and
> > ACLs should be used on all interfaces facing subscribers. Filtering
> > should be implemented with regard for the operational requirements of
> > IPv6 (ICMPv6 types).
> >
> >==> I don't understand what you mean by the last sentence?
>
> @@@
> We probably used too few words. We wanted to say that while configuring IPv6
> ACLs, one has to make sure that the ACLs do not stop IPv6 specific controll
> plane traffic (like ND, DHCP-PD etc).
> @@@

I'd hope that folks wouldn't filter ICMPv6 at all, but that's probably
too much to hope for.. remember, you cannot use e.g., 'ping' for host
scanning purposes as you have about  2^64 potential hosts in a
subnet...

> > In IPv6, with [RFC3306] there is a better mechanism available for ASM
> > IPv6 address allocation than in IPv4. This reduces the problems of
> > using ASM in IPv6 to some degree. On the other hand, the protocol MSDP
> > standard with PIM-SM is not currently defined for IPv6. In general,
> > SSM for IPv6 is also considered to be the protocol to promote for the
> > majority of future interdomain IP multicast applications and it is
> > less complex solution to operate.
> >
> >==> you might want to check out and refer to
> >draft-ietf-mboned-ipv6-multicast-issues-00.txt which discusses exactly this
> >issue, and solutions if you'd still need ASM.
>
> @@@
> Yes, we are aware of this work and we will reference it. We didn't really
> want to get into a model other then SSM despite the fact that there are
> feasible
> ways for ASM. The idea was that SPs will be more inclined to go for an SSM
> model
> at first (maybe even on a longer run) because of the business model of content
> delivery (video/audio). Probably we should however have a discussion on the
> topic.
> Do you see the ASM discussion important beyond referencing the draft you
> mentioned?
> @@@

Well, ASM is what's used (or actually, not being widely used :) today,
so it's a bit surprising to see it waved off just like that.. I guess
it would be OK to mention ASM more briefly, and refer to possible
solutions, but concentrate on SSM (and state the reasons for doing so,
i.e., the easier business model for content delivery).


+++++++++++++++
Sure, we can do that in the next revision of the draft.
+++++++++++++++



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

> > If a Customer Router is present:
> >
> >[...]
> > - it dynamically acquires through autoconfiguration the address for the
> > link between itself and the Edge Router. This step is followed by a
> > DHCP-PD [RFC 3633] request for a prefix shorter then /64 that in turn is
> > divided in /64s and assigned to its interfaces connecting the hosts on
> > the customer site.
> >
> >==> s/present/present, either:/
> >
> >==> the router doesn't autoconfigure the address unless it has been
> >configured to act as a host on its upstream interface... which would
> >probably be bad practice.. so either the upstream link has no global
> >addresses (which would be OK), or it could just use a subnet from the
> >DHCP-PD prefix.
>
> @@@
> 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.
+++++++++++++++


> > MLD authentication, authorization and accounting is usually
> > configured on the edge router in order to enable the ISP to do
> > controll the subbscriber access of the service and do billing for
> > the content provided.
> >
> >==> the non-standardized methods for adding AAA to IGMP/MLD have been
> >proposed, but they're generally considered very broken models, and I'm not
> >sure how much text we should have about them, at least without disclaimers.
> >The right thing to do would probably be to encrypt the data, and provide the
> >decryption key only to those who pay (or whatever for the stream.
>
> @@@
> We believe that such a feature is important to all SPs that deploy
> mcast services for video and audio streaming. Maybe this is not
> critical at the start of the service but would be when the service
> offering solidifies. Such a feature offers more granularity in
> controlling and charging a customer then the key proposal. With the
> key proposal the user would have access to possibly a predefined
> package of channels while with proper MLD AAA the user can select
> any channel, any time and be charged only for that use.
> @@@

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

Kind Regards,
Adeel Ahmed.


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