Subject: [Gen-art] GEN-ART Review of draft-ietf-v6ops-v6-in-mobile-networks-03

From: <[email-masked]>
Date: Mon, 21 Feb 2011 20:01:21 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-v6ops-v6-in-mobile-networks-03
Reviewer: Kathleen Moriarty
Review Date: 11-02-21
IETF LC End Date: 11-02-21
IESG Telechat date: (if known)

Summary:  I have a number of nits that could improve the readability of the document that should be considered.  There is a high number of transitional phrases used in the document.  Reducing these and making sentences more concise would increase the readability of the document.  There are also many places where commas are used that are unnecessary.  I went through the document and made a few suggestions listed below, but can take another pass through once these are corrected to assist further.

Major issues:

Minor issues:

Nits/editorial comments:

Introduction, first sentence:
Change from: The dramatic growth of the Mobile Internet is accelerating the
   exhaustion of available IPv4 addressing pool.
To: The dramatic growth of the Mobile Internet is accelerating the
   exhaustion of available IPv4 addresses.
OR: The dramatic growth of the Mobile Internet is accelerating the
   exhaustion of the available IPv4 addressing pool.

Introduction, second sentence (some commas are unnecessary):
Change from: It is widely accepted
   that IPv6 is necessary for the continued operation, and growth of the
   Internet in general, and that of the Mobile Internet in particular.
To: It is widely accepted
   that IPv6 is necessary for the continued operation and growth of the
   Internet in general, and that of the Mobile Internet in particular.

Introduction, forth sentence (remove comma):
Change from: This document describes such
   challenges, and outlines the applicability of the existing IPv6
   deployment solutions.
To: This document describes such
   challenges and outlines the applicability of the existing IPv6
   deployment solutions.

Section 2, first paragraph:
Change from: An APN is a logical
   concept which can be used to specify what kinds of services, such as
   Internet access, high-definition video streaming, content-rich
   gaming, and so on, a MN is entitled to.  And, each APN can specify
   what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on
   that particular APN.

To: An APN is a logical
   concept which can be used to specify what kinds of services, such as
   Internet access, high-definition video streaming, content-rich
   gaming, etc., a MN is entitled.  Each APN can specify
   what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on
   that particular APN.

Section 2, Second paragraph.
The first sentence is a run-on, I recommend breaking it up.  What is the comparison being made to use the word "whereas" at the start of this paragraph?  I am not quite able to follow this, so maybe a change would clear it up.

Section 2, second paragraph:
Consider adding some text to the transition sentence before the bulleted list.  What is the connection from this paragraph to the items in the bulleted list?  It would help to include that information in this transition sentence.
Change the sentence, "The different nodes in the figure are defined below:"  to include the link from this paragraph to the bulleted list.

For each of the bullets in this section, the acronyms should first be spelled out and then followed by the acronym.  For example:
Change from: o BS: The radio Base Station which provides wireless connectivity
      to the MN.
        o ANG: The Access Network Gateway.  This is a node that forwards
      IP packets to and from the MN.

To:  o Base Station (BS): the radio BS which provides wireless connectivity
      to the MN
        o Access Network Gateway (ANG):  The ANG is a node that forwards
      IP packets to and from the MN.

Section 3.1, second to last sentence, remove the comma.

Section 3.1 paragraph 2:
Change from: In the
   following, we primarily focus on translation based mechanisms such as
   NAT44 (i.e., translation from public IPv4 to private IPv4 and vice
   versa) and NAT64 (i.e., translation from public IPv6 to public IPv4
   and vice versa); we do this because the 3GPP architecture already
   defines a tunneling infrastructure with the GPRS Tunneling Protocol
   (GTP), and the architecture allows for dual-stack and IPv6-only
   deployments.
To: In the
   following, we primarily focus on translation based mechanisms such as
   NAT44 (i.e., translation from public IPv4 to private IPv4 and vice
   versa) and NAT64 (i.e., translation from public IPv6 to public IPv4
   and vice versa).  This approach is taken because the 3GPP architecture already
   defines a tunneling infrastructure with the GPRS Tunneling Protocol
   (GTP) and the architecture allows for dual-stack and IPv6-only
   deployments.

Section 3.1, third paragraph:
Change from: A PDN connection may support both IPv4 and IPv6
   traffic (as in a dual-stack PDN in 4G LTE networks) or it may support
   either one only (as in the existing 3G UMTS networks).
To: A PDN connection may support both IPv4 and IPv6
   traffic (as in a dual-stack PDN in 4G LTE networks) or it may support
   only one of the two traffic types (as in the existing 3G UMTS networks).

Section 3.1, forth paragraph:
Change from: An approach to
   address this problem is to make the always-on PDN to be IPv6, and
To: An approach to
   address this problem is to make the always-on PDN to be IPv6 and
Change from: In any case, there need to be appropriate triggers to initiate DHCP
To: In any case, there needs to be appropriate triggers to initiate DHCP

Section 3.1, fifth paragraph:
Change from: And, the existing so-called pre-Release-8 deployments do not support the dual-stack PDP connection.  Hence two separate

To: The existing so-called pre-Release-8 deployments do not support the dual-stack PDP
   connection.  Hence, two separate

Section 3.1, last paragraph:
Change from: Operators can introduce IPv6 in
   their networks, perhaps to access operator's own applications and
   services to begin with.
To: Operators can introduce IPv6 in
   their networks, perhaps to access operator's own applications and
   services.

Section 3.2, paragraph 3: BR is already defined and should be used consistently.
Change from: Some network deployments use the "centralized model" where
   the pool is managed by a common node, such as the PDN's Border
   Router, and the pool shared by multiple gateways all attached to the
   same BR.
To: Some network deployments use the "centralized model" where
   the pool is managed by a common node, such as the PDN's BR, and the pool shared by multiple gateways all attached to the
   same BR.

Section 3.2, paragraph 3:
Change from: This model has served well in the pre-3G deployments where
   the number of subscribers accessing the mobile Internet at any given
   time, perhaps, has not exceeded the available address pool.
To: This model has served well in the pre-3G deployments where
   the number of subscribers accessing the mobile Internet at any given
   time has not exceeded the available address pool.

Section 3.2, Paragraph 5:
I am wondering why is each MNG limited to the use of the Net10 block and not all of the non-routable networks set aside for this purpose?

Section 3.2, last paragraph:
Consider breaking this sentence into two:
   Whereas the
   centralized models with a common NAT have the advantages of
   continuing their legacy deployments, re-use of private IPv4
   addressing, and centralized NAT, they need additional functions to
   enable traffic differentiation, and NAT state correlation with
   subscriber state management at the MNG.
Recommend removing the first comma in this sentence:
   The distributed models also
   achieve private IPv4 address re-use, and avoid overlapping private
   IPv4 traffic in the operator's core, but without the need for
   additional mechanisms.

Section 3.3, last paragraph:
Consider changing the first sentence from:
Roaming is important in mobile networks and roaming introduces
   diversity in network deployments.
To: Roaming is important in mobile networks and introduces
   diversity in network deployments.

Section 3.4, first paragraph:
Change from: And, an All-IP mobile network service
   provider is required to provide voice service as well, whereas a
   fixed network provider is not required to.
To: An All-IP mobile network service
   provider is required to provide voice service, whereas this is not required for a
   fixed network provider.
Change from: Such architectural differences, as well as policy and business model
   differences, make convergence challenging.
To: Architectural, policy, and business model differences make convergence challenging.

Section 3.4, second paragraph:
Second sentence, was this intended to say:
For instance, IPv4 address management is a
   common concern for both the access networks and <something else>.
OR:
For instance, IPv4 address management is a
   common concern for both of the access networks.

Third sentence, consider rewording:
This implies the same
   mechanisms discussed earlier, i.e., delaying IPv4 address exhaustion
   and introducing IPv6 in operational networks, apply for the converged
   networks as well.

I am having trouble reading and understanding the intent of the first three sentences of this section and am unsure how to fix this and keep the meaning as intended.

Note:
There are a large number of examples in this section.  Would it be possible to provide them in a list format or is the set of examples not intended to cover all possible use cases?  Having the examples grouped as they are related to each other may increase readability.  The transitional phrases, such as however, are used quite frequently.  As a reader, the examples used with these statements make it difficult to decipher the set of examples and the exceptions that need to be tracked for each example.

Section 3.4, forth paragraph:
Change from: Using IPv6 for
   the Femto (or any other access technology), on the other hand, could
   alleviate some of these concerns if the IPv6 communication could
   bypass the NAT.
To: Using IPv6 for
   the Femto (or any other access technology) could
   alleviate some of these concerns if the IPv6 communication could
   bypass the NAT.

Section 4, first paragraph:
Consider changing from: In this document, we discussed the considerations in
   deploying IPv6 in mobile networks.  Specifically, we discussed:
To: This document discusses the considerations of deploying IPv6 in mobile networks.  The following bullets summarize the point discussed.

Bullet one:
Change from:
o IPv4 address exhaustion and its implications to mobile networks:
      we saw that, as the mobile networks begin to deploy IPv6,
      conserving the available IPv4 pool and delaying its exhaustion
      implies the need for network translation in mobile networks.  At
      the same time, providers can make use of the 3GPP architecture
      constructs such as the APN and PDN connectivity to introduce IPv6
      without affecting the (predominantly IPv4) Internet access.  The
      IETF dual-stack model [RFC4213] can be applied to the mobile
      networks readily.
To:
o IPv4 address exhaustion and its implications to mobile networks:
      As mobile networks begin to deploy IPv6, conserving the available IPv4 pool is necessary to delay its exhaustion and implies the need for network translation in mobile networks.  At
      the same time, providers can make use of the 3GPP architecture
      constructs such as the APN and PDN connectivity to introduce IPv6
      without affecting (predominantly IPv4) Internet access.  The
      IETF dual-stack model [RFC4213] can be applied to the mobile
      networks readily.

Consider changing the second bullet to:
o The placement of NAT functionality in mobile networks:
      Both the centralized and distributed models of private IPv4
      address pool management and their relative merits were discussed.  By
      enabling each MNG to manage its own NET10 pool, the distributed
      model achieves re-use of available private IPv4 pool and avoids
      the problems associated with the non-unique private IPv4 addresses
      for the MNs without additional protocol mechanisms.  The
      distributed model augments the "subscriber management"
      functions at an MNG, such as readily enabling NAT session
      correlation with the rest of the subscriber session state.  On the
      other hand, the existing deployments which have used the
      centralized IP address management can continue their legacy
      architecture by placing the NAT at a common node.  The centralized
      model can achieve private IPv4 address re-use, but needs
      additional protocol extensions to differentiate overlapping
      addresses at the common NAT, as well as to integrate with policy
      and billing infrastructure.

Consider changing the third bullet to:
o IPv6-only mobile network deployments:
      This deployment model is feasible in the LTE architecture for an operator's own services
      and applications.  Existing MNs still expect an
      IPv4 address assignment<, which could be problematic>.  Roaming, which is unique to mobile
      networks, requires that a provider support IPv4 connectivity when
      their (outbound) users roam into a mobile network that is not
      IPv6-enabled.  Similarly, a provider needs to support IPv4
      connectivity for (inbound) users whose MNs are not IPv6-capable.
      In this use case, IPv6 - IPv4 interworking is necessary
      for IPv6-only MNs to access the IPv4 Internet.

Consider changing the forth bullet to:
o Fixed-Mobile Convergence:
The examples provided illustrate
      the differences in the requirements of fixed and mobile networks.
      While some harmonization of functions may be possible across the
      access networks, the service provider's core network is
      best-suited for converged network architecture.  Perhaps even
      greater gains are feasible in the service and application layers.
I am not following the last two sentences of this bullet and why it might be the case that the core is best suited for convergence, but then 'greater gains' might be seen in the service and application layers.  It reads as though both are the best over the other.  Some rewording or expanded thoughts may help here.

Thanks,
Kathleen

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 25 Feb 2011 15:06:24 -0800

Hi Kathleen,

Thank you for your detailed review.

Please see my comments below:

>    exhaustion of the available IPv4 addressing pool.
                   ^^^
The latter is fine.

>    Internet in general, and that of the Mobile Internet in particular.

Okay. 

>    challenges and outlines the applicability of the existing IPv6

Okay. 

>    what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on

Ok, but I think the first sentence needs to end in "..a MN is entitled to."

> The first sentence is a run-on, I recommend breaking it up.  What is the
> comparison being made to use the word "whereas" at the start of this
> paragraph?  I am not quite able to follow this, so maybe a change would clear
> it up.

I see. I will break it up:

"While an APN directs a MN to an appropriate gateway, the MN needs
an end-to-end "link" to the gateway. In the Long-Term Evolution (LTE)
networks, this link is realized through an Evolved Packet System (EPS)
bearer. In the 3G UMTS networks, such a link is realized through a Packet
Data Protocol (PDP) Context."

> Consider adding some text to the transition sentence before the bulleted list.
> What is the connection from this paragraph to the items in the bulleted list?
> It would help to include that information in this transition sentence.
> Change the sentence, "The different nodes in the figure are defined below:"
> to include the link from this paragraph to the bulleted list.

The linking sentence:

"The other nodes involved in the MN communication are defined below:"

> 
> For each of the bullets in this section, the acronyms should first be spelled
> out and then followed by the acronym.  For example:

Okay, I like it.

> Section 3.1, second to last sentence, remove the comma.

NEW:

" There are two simultaneous approaches to addressing the run-out problem:
   delaying the IPv4 address exhaustion and introducing IPv6 in
   operational networks."

>    (GTP) and the architecture allows for dual-stack and IPv6-only

I would revise to:

" In the
   and vice versa). We do this because the 3GPP architecture already
   deployments."

>    only one of the two traffic types (as in the existing 3G UMTS networks).

Ok. 

>    address this problem is to make the always-on PDN to be IPv6 and

Ok. 

> To: In any case, there needs to be appropriate triggers to initiate DHCP

I see.

> Change from: And, the existing so-called pre-Release-8 deployments do not
> support the dual-stack PDP connection.  Hence two separate
> 

Ok.

>    their networks, perhaps to access operator's own applications and

I would revise to:

"To begin with, the operators can introduce IPv6 for their own applications
and services."

>    the pool is managed by a common node, such as the PDN's BR, and the pool
> shared by multiple gateways all attached to the
>    same BR.

Check. 

>    time has not exceeded the available address pool.

Ok. 

> I am wondering why is each MNG limited to the use of the Net10 block and not
> all of the non-routable networks set aside for this purpose?
> 

It may, but typically the provider networks go by cap on the NET10 block for
the gateway.

>    subscriber state management at the MNG.

Revise to:

   "The centralized models with a common NAT have the advantages of
   continuing their legacy deployments and the re-use of private IPv4
   addressing. However, they need additional functions to
   enable traffic differentiation, and NAT state correlation with
   subscriber state management at the MNG."

>    IPv4 traffic in the operator's core, but without the need for

Revise to:

   "The distributed models also
   achieve private IPv4 address re-use and avoid overlapping private
   IPv4 traffic in the operator's core, but without the need for
   additional mechanisms."

>    diversity in network deployments.

Fine.

>    provider is required to provide voice service, whereas this is not required

Ok. 

> To: Architectural, policy, and business model differences make convergence

I will stick with the former, but remove the second comma.

>    common concern for both of the access networks.
....

The latter. 

>    and introducing IPv6 in operational networks, apply for the converged

Its fine I think. May be I could add "This implies that.."

> I am having trouble reading and understanding the intent of the first three
> sentences of this section and am unsure how to fix this and keep the meaning
> as intended.
> 
> 
> Note:
> There are a large number of examples in this section.  Would it be possible to
> provide them in a list format or is the set of examples not intended to cover
> all possible use cases?  Having the examples grouped as they are related to
> each other may increase readability.  The transitional phrases, such as
> however, are used quite frequently.  As a reader, the examples used with these
> statements make it difficult to decipher the set of examples and the
> exceptions that need to be tracked for each example.
> 

Are you referring to Section 3.4?

I counted the number of "However" in section 3.4 and onwards. Emacs gave me
a count of 2 :-)

>    alleviate some of these concerns if the IPv6 communication could

Fine.

> To: This document discusses the considerations of deploying IPv6 in mobile
> networks.  The following bullets summarize the point discussed.
> 

I would stick with the former, but change the second sentence to "We
summarize the discussion in the following:"

The following bullets are about revising the first sentence, which I can do.

>       As mobile networks begin to deploy IPv6, conserving the available IPv4
> pool is necessary to delay its exhaustion and implies the need for network
> translation in mobile networks.  At
> I am not following the last two sentences of this bullet and why it might be
> the case that the core is best suited for convergence, but then 'greater
> gains' might be seen in the service and application layers.  It reads as
> though both are the best over the other.  Some rewording or expanded thoughts
> may help here.
> 

Good point. I will reword to:

" Fixed-Mobile Convergence: the examples discussed illustrate
      the differences in the requirements of fixed and mobile networks.
      While some harmonization of functions may be possible across the
      access networks, the service provider's core network is perhaps
      better-suited for converged network architecture.  Similar
      gains in convergence are feasible in the service and application
layers."

Thanks again for your thorough review.

Regards,

-Rajeev