Subject: [Gen-art] Gen-ART review of draft-ietf-v6ops-3gpp-eps-03

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 9 Aug 2011 13:53:00 +0800

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

Document: draft-ietf-v6ops-3gpp-eps-03
Reviewer: Martin Thomson
Review Date: 2011-08-10
IETF LC End Date: 2011-08-12
IESG Telechat date:

Summary: This draft is ready for publication as an informational RFC.

The document does a reasonable job of summarizing the state of IPv6 deployment for 3GPP access.  There are a number of editorial issues that affect readability, but nothing that should prevent this from going to the RFC editor.  

Major issues: none

Minor issues: none

Nits/editorial:

The draft relies on a definition of "layer-2" that is implied.  For instance, from Section 5:

   [...] The mobile host must
   always support layer-2 based address configuration, [...]

It's easy to infer from reading further that "layer-2" implies "pre-IP", but that view is at odds with the view that other nodes necessarily have: signaling is distinctly layer-7 to those that operate upon it.  Is this accurate?

   The mobile host must always support address configuration using signaling during bearer setup, ...

Idnits picked up two warnings, one of which is a false alarm, the other of which is a downref to draft-ietf-dhc-pd-exclude.  What is the publication status of the prefix delegation exclusion draft?
 
   [...]  IETF is working on a solution
   for DHCPv6-based prefix delegation to exclude a specific prefix from
   the 'delegated prefix' [I-D.ietf-dhc-pd-exclude].

Rather than make this statement, which wont be of any value once pd-exclude is published or not.  Could you make a statement that is less temporary?  Does 3GPP reference the mechanism in pd-exclude?

There are more than the usual quantity of acronyms in this document.  I encourage you to do a final pass to check that each is expanded on first use.  There were a few that I encountered, but I probably missed a few instances.  PDN, "PDP Type" (as opposed to context), NAT44.  Fortunately [*], the target audience should have sufficient context to wade through the dense thicket of acronyms and terms without needing this; I pity the reader who is unfamiliar with the 3GPP architecture.

Also missing: "user plane".

The decision to interchangeably use UE, MN, Mobile, etc... is greatly confusing to a reader.  My experience with 3GPP specifications shows a consistent use of "UE", can you not also choose one form and consistently use that?

In addition to the above, I didn't see any reason to make a distinction between TE+MT and UE.

Section 2, Terminal Equipment: s/to the use./to the user./

Figure 2 shows the UTRAN and BSS as nodes (boxes) rather than composite systems (clouds).  That might be misleading.

Sections 3 and 4 duplicate some of the information that is provided in Section 2.  For instance, the definition of the eNodeB and MME is duplicated at the end of Section 4.1.

Section 5.2 includes a citation for DHCPv6 that is placed in a way that implies more than I think is intended.  RFC 3315 supports the definition rather than the statement.
   Stateful DHCPv6-based address configuration is not supported by 3GPP
   specifications [RFC3315].  
Suggest:
   Stateful DHCPv6-based address configuration [RFC3315] is not supported 
   by 3GPP specifications.

Section 5.2 needs a citation for RFC 4861.

Section 5.2 uses "must" and "may" several times.  Since these statements are not prescriptive, they could probably use other forms, for instance:

   This implies that the M-bit _is_ always clear in the Router Advertisement (RA) [RFC4861] sent to the UE.

Section 8.1, Point 3: s/be build on IPv6/be built on IPv6/

The language in Section 8.5 is hard to parse.  Consider breaking the first paragraph (the list structure).  Re-consider the use of colloquialisms like "basically" and the use of parenthetical statements.

Section 8.6:
   Other types of configurations are considered network planning
   mistakes.  
Seems like a value statement, rather than a statement of fact.  [*] See also statements containing "unfortunately".

---

From: jouni korhonen <[email-masked]>
Date: Tue, 9 Aug 2011 11:28:05 +0300

Hi Martin,

Thank you for a thorough review! I have few comments/answers inline.

> It's easy to infer from reading further that "layer-2" implies "pre-IP", but that view is at odds with the view that other nodes necessarily have: signaling is distinctly layer-7 to those that oper…

Right.. maybe we should also say that PDP context/EPS bearer setup procedures equals setting up the layer-2 link and the address configuration can be part of that signaling?

>   the 'delegated prefix' [I-D.ietf-dhc-pd-exclude].

In its 3rd WGLC as we speak.

> Rather than make this statement, which wont be of any value once pd-exclude is published or not.  Could you make a statement that is less temporary?  Does 3GPP reference the mechanism in pd-exclude?

The pd-exclude is referenced from 3GPP. How about:

   is not part of the 'delegated prefix'.  IETF defined solution to
   exclude a specific prefix from the 'delegated prefix' is used to
   enable this [I-D.ietf-dhc-pd-exclude].

> 
> There are more than the usual quantity of acronyms in this document.  I encourage you to do a final pass to check that 

Welcome to 3GPP ;)

> each is expanded on first use.  There were a few that I encountered, but I probably missed a few instances.  PDN, "PDP Type" (as opposed to context), NAT44.  Fortunately [*], the target audience should have sufficient context to wade through the dense thicket of acronyms and terms without needing this; I pity the reader who is unfamiliar with the 3GPP architecture.

Ok. I'll check for these.

> Also missing: "user plane".

Ok.

> The decision to interchangeably use UE, MN, Mobile, etc... is greatly confusing to a reader.  My experience with 3GPP specifications shows a consistent use of "UE", can you not also choose one form…

Ok. Will consistently change everything to UE.

> In addition to the above, I didn't see any reason to make a distinction between TE+MT and UE.

Ok. If you refer to Figure 2 I can change that to the UE.

> Section 2, Terminal Equipment: s/to the use./to the user./

Ok.

> Figure 2 shows the UTRAN and BSS as nodes (boxes) rather than composite systems (clouds).  That might be misleading.

Ok. I'll try fitting clouds there.

> Sections 3 and 4 duplicate some of the information that is provided in Section 2.  For instance, the definition of the eNodeB and MME is duplicated at the end of Section 4.1.

Ok. Will remove duplicates.

>   Stateful DHCPv6-based address configuration [RFC3315] is not supported 

Sounds better. Will change this.

> Section 5.2 needs a citation for RFC 4861.

Ok.

>   This implies that the M-bit _is_ always clear in the Router Advertisement (RA) [RFC4861] sent to the UE.

Ok.

> Section 8.1, Point 3: s/be build on IPv6/be built on IPv6/

Ok.

> The language in Section 8.5 is hard to parse.  Consider breaking the first paragraph (the list structure).  Re-consider the use of colloquialisms like "basically" and the use of parenthetical state…

Right.. I'll try to reword this section.

> Seems like a value statement, rather than a statement of fact.  [*] See also statements containing "unfortunately".

Do you have a suggestion for better wording? The statement is here because it is possible and rather easy to deploy a network that allow other types of handovers. However, in that case the outcome is unpredictable, especially when the network has equipment from multiple vendors.. and those cases and recovery procedures are not even documented.

- Jouni

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Aug 2011 09:27:21 +0800

On 2011-08-09 at 18:28:05, jouni korhonen wrote:
> > It's easy to infer from reading further that "layer-2" implies "pre-
> IP", but that view is at odds with the view that other nodes 
> necessarily have: signaling is distinctly layer-7 to those that 
> operate upon it.  Is this accurate?
> 
> Right.. maybe we should also say that PDP context/EPS bearer setup 
> procedures equals setting up the layer-2 link and the address 
> configuration can be part of that signaling?

I notice that you use the term "bearer" fairly frequently to refer to both PDP context/EPS bearer.  When you say "layer-2 signaling" you could be more specific and say "bearer setup".

> In its 3rd WGLC as we speak.

Great.  MISREF wont keep this in the editors queue long then.

>    enable this [I-D.ietf-dhc-pd-exclude].

Or just:
  An option to exclude a prefix from delegation [I-D....pd-exclude] 
  prevents this problem.

> > There are more than the usual quantity of acronyms in this document.
> Welcome to 3GPP ;)

Oh, it's not my first time, trust me.  Incidentally, I have to note that you've done an excellent job with the acronyms on the whole.  I didn't encounter any that I didn't know, and only a few that weren't expanded.

> Ok. I'll try fitting clouds there.

BTW, nice clouds, and some of the nicest ASCII art that I've seen.
 
> Do you have a suggestion for better wording? The statement is here 
> because it is possible and rather easy to deploy a network that allow 
> other types of handovers. However, in that case the outcome is 
> unpredictable, especially when the network has equipment from multiple 
> vendors.. and those cases and recovery procedures are not even 
> documented.

I understand that it _is_ unfortunate.  As you say, it has other more concrete consequences.  In some cases, simply removing the "Unfortunately," would work.  Maybe something like:

OLD:
   Unfortunately, it is not mandatory to implement/deploy 3GPP standards
   based solution to selectively prohibit IPv6 roaming without also
   prohibiting other packet services (such as IPv4 roaming).  However,
   there are few possibilities how this can be done in real deployments.
   The examples given below are either optional and/or vendor specific
   features to the 3GPP EPC:
NEW:
3GPP does not specify a mechanism whereby IPv6 roaming is prohibited without also disabling IPv4 access and other packet services.  The following options for disabling IPv6 access for roaming subscribers could be available in some network deployments:

Don't feel beholden to me on this one though.  Use your discretion.  The first sentence didn't parse particularly well, but I'm not sure whether my suggestion retains the whole of your original intent.
 
> - Jouni

--Martin

---

From: jouni korhonen <[email-masked]>
Date: Thu, 11 Aug 2011 08:40:45 +0300

Hi,

> I notice that you use the term "bearer" fairly frequently to refer to both PDP context/EPS bearer.  When you say "layer-2 signaling" you could be more specific and say "bearer setup".

Right.. how about:

   specifications, but is not used in wide scale.  The mobile host must
   always support address configuration as part of the bearer setup signaling,
   since DHCPv4 is optional for both mobile hosts and networks.

>  An option to exclude a prefix from delegation [I-D....pd-exclude] 

Ok. Sounds much better.

> 3GPP does not specify a mechanism whereby IPv6 roaming is prohibited without also disabling IPv4 access and other packet services.  The following options for disabling IPv6 access for roaming subsc…

Thanks. I'll use this.

> Don't feel beholden to me on this one though.  Use your discretion.  The first sentence didn't parse particularly well, but I'm not sure whether my suggestion retains the whole of your original int…

- JOuni