Subject: [v6ops] Reminder: draft-ietf-v6ops-3gpp-eps WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 22 May 2011 19:00:04 +0100

The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 May 2011 11:45:00 -0700

> The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

I am in the target audience for this document, so my contributions will seem more critical than constructive and predominantly editorial in nature, mainly because I'm not confident that my knowledge of 3GPP protocols and technologies is complete.

Please do not interpret my criticisms as opposition to this draft.  I very much want to see a document with this information published in the RFC series.

----

p1. The abstract seems overly verbose.  Here is a proposed rewrite:

   Use of data services in smart phones and broadband services via HSPA
   and HSPA+, in particular Internet services, has increased rapidly
   and operators that have deployed networks based on 3GPP network
   architectures are facing IPv4 address shortages at the Internet
   registries and are feeling a pressure to migrate to IPv6.  This
   document describes the support for IPv6 in 3GPP network
   architectures.

p2. This sentence needs updating:

   However, the support for IPv6
   in commercially deployed networks by the end of 2010 is nearly non-
   existent.

p3. In section 2.1, Terminology, I think it would help if the abbreviations were all collected into one table and expanded once in each glossary subsection entry and in each top level section where they are used.  The terms in the glossary subsection should be headed by expanded abbreviations, and they should be presented in alphabetical order.

p4. In section 2.1, Terminology, the definition of "Packet Data Network" introduces what seems to be a specialized term, 'packet domain network,' that goes undefined in this section.  Please clarify.

p5. In section 2.1, Terminology, the definition of "Policy and Charging Control (PCC) framework" explains that it's used for QoS policy, which I think I might understand, but also for 'charging control' which is never defined.  It also doesn't appear to be inferable from context in the draft.  The dependent clause "but needed if dynamic policy and charging control by means of PCC rules based on user and services are desired" is therefore really not much use.  Please clarify.

p6. In section 2.1, Terminology, the term "evolved packet core" is introduced and used in the document, but never defined.  Please clarify.

p7. I think section 2.2, The concept of APN, might more properly belong in section 3 [but I'm not sure].  If it really belongs in section 2, because it describes an architecture independent of the Internet Protocol, then perhaps this should be explicitly mentioned here.

p8. In section 3.1, figure 2, what does the abbreviation TE mean?  Also, I gather that PLMN stands for Public Land Mobile Network, but this term is not properly introduced.  The "i.e." parentheticals in the Gn/Gp table entry are no help to me.

p9. In section 5.3, Prefix Delegation, the second paragraph is mostly unintelligible to me.  The citation of RFC 3633, section 12.1, is confusing, because that document doesn't place any limitations on the delegating router, only the requesting router, which is contrary to what this draft states.  The sentences that follow in that paragraph therefore don't make sense to me.  Please clarify.

p10. In section 6, the abbreviation "DS" is used, presumably to stand for 'dual-stack,' but no proper introduction is given.  I think it would be better to eliminate some uses of it, particularly in figures 5, 6 and 7, and expand it fully everywhere else.

p11. In section 6.4, the abbreviation IPv4v6 is introduced and used several places thereafter.  I can infer that this signals a special type of 3GPP bearer that transports both IPv4 and IPv6 at the same time, but I don't like this abbreviation.  If it's official 3GPP terminology, then please cite it and add it to the Terminology section.  Otherwise, please come up with a more descriptive term, e.g. "dual-stack IP" should work in a pinch, and use that instead.

p12. Throughout, I think it would be better to use a hyphen when writing IPv4-only and IPv6-only.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: <[email-masked]>
Date: Wed, 25 May 2011 05:40:39 +0000

Hi James,

On 5/23/11 9:45 PM, "james woodyatt" <[email-masked]> wrote:

>> The working group last call for this draft announced last week
>>continues for another week. Please feel free to comment on it.
>
>I am in the target audience for this document, so my contributions will
>seem more critical than constructive and predominantly editorial in
>nature, mainly because I'm not confident that my knowledge of 3GPP
>protocols and technologies is complete.
>
>Please do not interpret my criticisms as opposition to this draft.  I
>very much want to see a document with this information published in the
>RFC series.
>
>----
>
>p3. In section 2.1, Terminology, I think it would help if the
>abbreviations were all collected into one table and expanded once in each
>glossary subsection entry and in each top level section where they are
>used.  The terms in the glossary subsection should be headed by expanded
>abbreviations, and they should be presented in alphabetical order.
>
>p4. In section 2.1, Terminology, the definition of "Packet Data Network"
>introduces what seems to be a specialized term, 'packet domain network,'
>that goes undefined in this section.  Please clarify.
>
>p5. In section 2.1, Terminology, the definition of "Policy and Charging
>Control (PCC) framework" explains that it's used for QoS policy, which I
>think I might understand, but also for 'charging control' which is never
>defined.  It also doesn't appear to be inferable from context in the
>draft.  The dependent clause "but needed if dynamic policy and charging
>control by means of PCC rules based on user and services are desired" is
>therefore really not much use.  Please clarify.
>
>p6. In section 2.1, Terminology, the term "evolved packet core" is
>introduced and used in the document, but never defined.  Please clarify.
>
>p7. I think section 2.2, The concept of APN, might more properly belong
>in section 3 [but I'm not sure].  If it really belongs in section 2,
>because it describes an architecture independent of the Internet
>Protocol, then perhaps this should be explicitly mentioned here.
>
>p8. In section 3.1, figure 2, what does the abbreviation TE mean?  Also,
>I gather that PLMN stands for Public Land Mobile Network, but this term
>is not properly introduced.  The "i.e." parentheticals in the Gn/Gp table
>entry are no help to me.
>
>p9. In section 5.3, Prefix Delegation, the second paragraph is mostly
>unintelligible to me.  The citation of RFC 3633, section 12.1, is
>confusing, because that document doesn't place any limitations on the
>delegating router, only the requesting router, which is contrary to what
>this draft states.  The sentences that follow in that paragraph therefore
>don't make sense to me.  Please clarify.
>
>p10. In section 6, the abbreviation "DS" is used, presumably to stand for
>'dual-stack,' but no proper introduction is given.  I think it would be
>better to eliminate some uses of it, particularly in figures 5, 6 and 7,
>and expand it fully everywhere else.
>
>p11. In section 6.4, the abbreviation IPv4v6 is introduced and used
>several places thereafter.  I can infer that this signals a special type
>of 3GPP bearer that transports both IPv4 and IPv6 at the same time, but I
>don't like this abbreviation.  If it's official 3GPP terminology, then
>please cite it and add it to the Terminology section.  Otherwise, please
>come up with a more descriptive term, e.g. "dual-stack IP" should work in
>a pinch, and use that instead.
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: <[email-masked]>
Date: Wed, 25 May 2011 06:18:24 +0000

Hi,

(the last mail escaped a bit early). Sorry! Well, now trying again...

>very much want to see a document with this information published in the

Good comments and good review is never bad! Thank you very much for your
comments. We'll try to update the draft accordingly. After working for
over ten years on these things, some of the terms and issues become a
second nature, and we might not have explained everything, which we
actually should.

Thanks for the review, James!

Cheers,

Jonne.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 25 May 2011 11:43:27 +0300

James,

Thanks for the review. Really appreciated! See my initial comments inline.

>   document describes the support for IPv6 in 3GPP network

Looks OK to me.

>   in commercially deployed networks by the end of 2010 is nearly non-

Yes. Cameron also pointed this out.

> p3. In section 2.1, Terminology, I think it would help if the abbreviations were all collected into one table and expanded once in each glossary subsection entry and in each top level section where…

Hmm.. OK to collect all abbreviations. Do you mean that each of these current entries in the terminology section would become a subsection of their own?

> p4. In section 2.1, Terminology, the definition of "Packet Data Network" introduces what seems to be a specialized term, 'packet domain network,' that goes undefined in this section.  Please clarif…

s/domain/core

Good catch. Packet core network means the operator internal network.

> p5. In section 2.1, Terminology, the definition of "Policy and Charging Control (PCC) framework" explains that it's used for QoS policy, which I think I might understand, but also for 'charging con…

Ok. But I do not want to go into too much details.. PCC is a beast of its own.. brrr..

> p6. In section 2.1, Terminology, the term "evolved packet core" is introduced and used in the document, but never defined.  Please clarify.

Oops :) Will add it.

> p7. I think section 2.2, The concept of APN, might more properly belong in section 3 [but I'm not sure].  If it really belongs in section 2, because it describes an architecture independent of the…

I have no strong opinion here. Section 2.2 could fit nicely between current Sections 3.1 and 3.2.

> p8. In section 3.1, figure 2, what does the abbreviation TE mean?  Also, I gather that PLMN stands for Public Land Mobile Network, but this term is not properly introduced.  The "i.e." parenthetica…

More stuff to terminology section.. TE is Terminal Equipment e.g. your laptop. MT would then be your modem.

> p9. In section 5.3, Prefix Delegation, the second paragraph is mostly unintelligible to me.  The citation of RFC 3633, section 12.1, is confusing, because that document doesn't place any limitation…

There was a long discussion on this in DHC WG. The restriction applies also to delegating router. When you delegate a prefix to a requesting router, then the delegating router must not advertise (in RAs) any of these prefixes on its downstream link towards requesting router.. which would be the case in 3GPP architecture. Thus all this prefix delegation work and description here.

> p10. In section 6, the abbreviation "DS" is used, presumably to stand for 'dual-stack,' but no proper introduction is given.  I think it would be better to eliminate some uses of it, particularly i…

Ok.

> p11. In section 6.4, the abbreviation IPv4v6 is introduced and used several places thereafter.  I can infer that this signals a special type of 3GPP bearer that transports both IPv4 and IPv6 at the…

Right, will add IPv4v6 to terminology section as it is formal 3GPP jargon.

> p12. Throughout, I think it would be better to use a hyphen when writing IPv4-only and IPv6-only.

Ack.

Thanks for the thorough review.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 May 2011 08:36:08 -0700 (PDT)

Jouni, James,

Please take a look at RFC 3316,
http://tools.ietf.org/html/rfc3316

it already defined so many of the terms and you can copy its structure.
Do not reinvent the wheel  :-).
Regards,

Behcet

> >> The working  group last call for this draft announced last week continues 
>for another week.  Please feel free to comment on it.
> > 
> > I am in the target audience  for this document, so my contributions will seem 
>more critical than constructive  and predominantly editorial in nature, mainly 
>because I'm not confident that my  knowledge of 3GPP protocols and technologies 
>is complete.
> > 
> >  Please do not interpret my criticisms as opposition to this draft.  I very  
>much want to see a document with this information published in the RFC  series.
> > 
> > ----
> > 
> > p3. In section 2.1, Terminology, I think it  would help if the abbreviations 
>were all collected into one table and expanded  once in each glossary subsection 
>entry and in each top level section where they  are used.  The terms in the 
>glossary subsection should be headed by  expanded abbreviations, and they should 
>be presented in alphabetical  order.
> 
> Hmm.. OK to collect all abbreviations. Do you mean that each of  these current 
>entries in the terminology section would become a subsection of  their own?
> 
> > 
>introduces what seems to be a specialized term, 'packet  domain network,' that 
>goes undefined in this section.  Please  clarify.
> 
> s/domain/core
> 
>Control (PCC) framework"  explains that it's used for QoS policy, which I think 
>I might understand, but  also for 'charging control' which is never defined.  It 
>also doesn't appear  to be inferable from context in the draft.  The dependent 
>clause "but  needed if dynamic policy and charging control by means of PCC rules 
>based on  user and services are desired" is therefore really not much use.  
>Please  clarify.
> 
> >  p7. I think section 2.2, The concept of APN, might more properly belong in  
>section 3 [but I'm not sure].  If it really belongs in section 2, because  it 
>describes an architecture independent of the Internet Protocol, then perhaps  
>this should be explicitly mentioned here.
> 
> > p8. In section 3.1, figure 2, what does the abbreviation TE mean?   Also, I 
>gather that PLMN stands for Public Land Mobile Network, but this term is  not 
>properly introduced.  The "i.e." parentheticals in the Gn/Gp table  entry are no 
>help to me.
> > 
> 
>unintelligible to me.  The citation of RFC 3633,  section 12.1, is confusing, 
>because that document doesn't place any limitations  on the delegating router, 
>only the requesting router, which is contrary to what  this draft states.  The 
>sentences that follow in that paragraph therefore  don't make sense to me.  
>Please clarify.
> 
> There was a long discussion  on this in DHC WG. The restriction applies also to 
>delegating router. When you  delegate a prefix to a requesting router, then the 
>delegating router must not  advertise (in RAs) any of these prefixes on its 
>downstream link towards  requesting router.. which would be the case in 3GPP 
>architecture. Thus all this  prefix delegation work and description here.
> 
> > 
>'dual-stack,'  but no proper introduction is given.  I think it would be better 
>to  eliminate some uses of it, particularly in figures 5, 6 and 7, and expand it  
>fully everywhere else.
> 
> Ok.
> 
> > 
> > p11. In section 6.4, the  abbreviation IPv4v6 is introduced and used several 
>places thereafter.  I  can infer that this signals a special type of 3GPP bearer 
>that transports both  IPv4 and IPv6 at the same time, but I don't like this 
>abbreviation.  If  it's official 3GPP terminology, then please cite it and add 
>it to the  Terminology section.  Otherwise, please come up with a more 
>descriptive  term, e.g. "dual-stack IP" should work in a pinch, and use that 
>instead.
> > 
>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 31 May 2011 17:09:27 +0200

Even though a little too late, here are a few additional comments on
I-D.ietf-v6ops-3gpp-eps-01. 

-- Section 6.2

* The section uses the term "S4-SGSN": Might be useful to briefly
explain what a S4-SGSN is (or cover it as part of the glossary).

-- Section 6.3

* Step 6: Might be useful to point out that the UE would ignore any
prefix received in PCO in an access accept as part of the PDP
establishment procedure (or directly refer to 3GPP 29.061:  "The Attach
Accept message will be sent along to the UE without the IPv6 prefix.",
"The UE shall ignore the IPv6 prefix if it receives one in the
message.")

-- Section 6.4

The current text states 
"If a network knows a mobile may do handovers between Release-8
 and pre-Release-8 networks (segment), network will only provide
 single stack bearers, even if the mobile host requests dual-stack
 bearers.  This can happen e.g. if an operator is using pre-
 Release-8 SGSNs in some parts of the network."

Shouldn't this be "Rel-9 SGSNs"?

-- Section 8.5

Similar to the comment above, the text references pre-Release-8
networks. Would it make sense to differentiate things a bit further
in the text - highlighting the fact (which the I-D already states
elsewhere), that v4v6 support only comes with Rel-9 for the SGSN?
Right now the reader might things a bit

This is the text I was referring to: 

"First, the visited network (S4-)SGSN does not 
 support the IPv6 PDP Context or
 IPv4v6 PDP Context types.  These should mostly concern pre-Release-8
 networks but there is no definitive rule as the deployed feature sets
 vary depending on implementations and licenses. "

-- Section 8.7

The text states: "If for some reason a SGSN does not understand the
requested PDP Type,
   then the PDP Type is handled as IPv4."

While this is "common understanding" it might make sense to point out
that 3GPP 24.008 is a bit ambiguous here. Other 3GPP docs, e.g.
23.975 handle this with a note. E.g.
"Note: The 3GPP specification TS 24.008 is not entirely unambiguous on
the treatment of unknown PDP types. 
Even if the information element coding for "PDP type" specifies that a
request for an "unknown PDP 
type" shall be treated as if it were a request for PDP type v4, the
error signalling elsewhere in the 
specification include the possibility to signal an error code "unknown
PDP address or PDP type".

Should we include something similar here?

A few nits that I found while reading:

--- section 8.7:

 s/respone/response

--- section 6.4:

"If a network knows a mobile will not be able to do handover to
       pre-Release-8 network (segment), it will provide mobile with
       dual-stack bearers on request"

 s/provide mobile/provide the mobile

-- section 8.6

heading: s/rat/RAT

Regards, Frank

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of jouni korhonen
> Sent: Wednesday, May 25, 2011 10:43 AM
> To: james woodyatt
> Cc: [email-masked] WG
> Subject: Re: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-01
> 
> James,
> 
> > I am in the target audience for this document, so my contributions
> will seem more critical than constructive and predominantly editorial
> in nature, mainly because I'm not confident that my knowledge of 3GPP
> abbreviations were all collected into one table and expanded once in
> each glossary subsection entry and in each top level section where
they
> are used.  The terms in the glossary subsection should be headed by
> expanded abbreviations, and they should be presented in alphabetical
> order.
> 
> Hmm.. OK to collect all abbreviations. Do you mean that each of these
> current entries in the terminology section would become a subsection
of
> their own?
> 
> >
> > p4. In section 2.1, Terminology, the definition of "Packet Data
> Network" introduces what seems to be a specialized term, 'packet
domain
> network,' that goes undefined in this section.  Please clarify.
> 
> s/domain/core
> 
> > p5. In section 2.1, Terminology, the definition of "Policy and
> Charging Control (PCC) framework" explains that it's used for QoS
> policy, which I think I might understand, but also for 'charging
> control' which is never defined.  It also doesn't appear to be
> inferable from context in the draft.  The dependent clause "but needed
> if dynamic policy and charging control by means of PCC rules based on
> user and services are desired" is therefore really not much use.
> Please clarify.
> 
> > p7. I think section 2.2, The concept of APN, might more properly
> belong in section 3 [but I'm not sure].  If it really belongs in
> section 2, because it describes an architecture independent of the
> Internet Protocol, then perhaps this should be explicitly mentioned
> here.
> 
> > p8. In section 3.1, figure 2, what does the abbreviation TE mean?
> Also, I gather that PLMN stands for Public Land Mobile Network, but
> this term is not properly introduced.  The "i.e." parentheticals in
the
> Gn/Gp table entry are no help to me.
> >
> 
> delegating router, only the requesting router, which is contrary to
> what this draft states.  The sentences that follow in that paragraph
> therefore don't make sense to me.  Please clarify.
> 
> There was a long discussion on this in DHC WG. The restriction applies
> also to delegating router. When you delegate a prefix to a requesting
> router, then the delegating router must not advertise (in RAs) any of
> these prefixes on its downstream link towards requesting router..
which
> would be the case in 3GPP architecture. Thus all this prefix
delegation
> work and description here.
> 
> >
> > p10. In section 6, the abbreviation "DS" is used, presumably to
stand
> for 'dual-stack,' but no proper introduction is given.  I think it
> would be better to eliminate some uses of it, particularly in figures
> 5, 6 and 7, and expand it fully everywhere else.
> 
> Ok.
> 
> >
> several places thereafter.  I can infer that this signals a special
> type of 3GPP bearer that transports both IPv4 and IPv6 at the same
> time, but I don't like this abbreviation.  If it's official 3GPP
> terminology, then please cite it and add it to the Terminology
section.
> Otherwise, please come up with a more descriptive term, e.g. "dual-
> stack IP" should work in a pinch, and use that instead.
> >
>

---

From: Jouni <[email-masked]>
Date: Tue, 31 May 2011 19:51:26 +0300

Hi Frank,

Thanks for the review. See my initial responses inline.

> I-D.ietf-v6ops-3gpp-eps-01. 

Not too late.. as I have not done a new version yet.

> explain what a S4-SGSN is (or cover it as part of the glossary).

Ack. Will add it.

> "The UE shall ignore the IPv6 prefix if it receives one in the

Good point. However, we do not mention PCOs in the whole document so far. I we do add text about PCOs, I would be tempted to write a bit more. For example the fact that DNS server IPv6 addresses get typically configured using PCOs.

> Shouldn't this be "Rel-9 SGSNs"?

No.. The assumption in the above text is that from Rel-8 onwards the SGSN is actually S4-SGSN. However, as the world has moved on this  does not really hold anymore in real life. There are SGSNs out there these days that are not S4-SGSNs and not Rel-9 SGSNs but still can do PDP Type IPv4v6.. sigh. I try to rewrite this to cover the current situation:

* Legacy Pre-rel-8 SGSN -> only single stack bearers
* Rel-8 S4-SGSN  -> dual stack bearers
* Rel-9 SGSN (without S4) -> dual stack bearers
* Pre-rel-9 SGSN with PDP Type IPv4v6 "patch" -> dual stack bearers

Ok, this was the story from the SGSN side.. then the PGW/GGSN side causes another "tweak" here. In a Rel-8 PGW also capable of running in Gn (GGSN) mode may not support PDP Type IPv4v6 in Gn until Rel-9 ;) So even if your SGSN is up to date, the Gn side on PGW may cause a hick-up.

> Right now the reader might things a bit

See above. Would the above list be detailed enough?

> While this is "common understanding" it might make sense to point out

And also based on field testing.

> 23.975 handle this with a note. E.g.

23.975 *cough*

> Should we include something similar here?

Isn't the above the same what the existing test says more or less. Also Section 8.7 says "The above respone/cause codes apply to Release-8 and onwards.  In pre-Release-8 networks used response/cause codes vary depending on the vendor, unfortunately." This is also based on field experience.

> s/provide mobile/provide the mobile

Ack. Thanks!

- Jouni