Subject: [netext] Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06

From: Basavaraj Patil <[email-masked]>
Date: Mon, 17 Mar 2014 17:48:30 -0400

Hello,

A few comments following my review of this I-D:

1. A lot of the 3GPP concepts are covered in this document. And there is
not enough explanation of things like the APN etc. I would recommend
referencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PDP
contexts etc.

2. It is not clear as to which EAP messages would include the attributes
such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would be easier
for implementers if it was clearly spelled out in a message flow.

3. The attributes to co-relate sessions when moving between 3/4G networks
and WiFi no doubt are useful. But I am not sure if this is sufficient to
enable seamless mobility between these disparate networks. Maybe it would
be useful to clarify that these attributes are required in the context of
an overall 3/4G<->WiFi mobility design.

4. The following statement in Sec 5.3 is not clear as to its intent and the
outcome : "For Multiple PDN Connections only, a Mobile Node uses this
attribute
   to indicate whether it wishes the connectivity type to be Non-
   Seamless WLAN Offload or EPC."

5. Lastly I am wondering if it is worth trying to solve multiple problems
such as APN indication, Mobility between networks and Simultaneous
connections to different APNs in this I-D. I see the APN indication and
simulatenous connections to different APNs as something that would be
required in WiFI networks. Maybe the I-D would be simplified if it did not
tackle the seamless mobility aspect and drop the associated attributes
proposed.

-Raj

-- 
Basavaraj Patil

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 18 Mar 2014 22:09:09 -0700

---------- Forwarded message ----------

On 3/17/14, 7:13 PM, "Koodli, Rajeev" <[email-masked]> wrote:

>
>Hi Raj,
>
>Thanks for the review. Responses inline:
>
>From: Basavaraj Patil <[email-masked]<mailto:[email-masked]>>
>Date: Monday, March 17, 2014 at 2:48 PM
>To: "[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>
>Cc:
>"[email-masked]<mailto:draft-iet
>[email-masked]>"
><[email-masked]<mailto:draft-iet
>[email-masked]>>
>Subject: Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06
>Resent-To: Rajeev Koodli
><[email-masked]<mailto:[email-masked]>>,
><[email-masked]<mailto:[email-masked]>>
>
>
>Hello,
>
>Rajeev> okay, good idea.
>Rajeev> we do specify that in statements such as "This attribute can be
>included in any of the EAP Request message that
>   are integrity protected, such as EAP-Response/AKA-Challenge.". Since
>these are just the attributes, it is up to the implementations to
>incorporate them in the appropriate EAP messages. However, perhaps it
>would be better to indicate specific EAP messages which can be used to
>carry the corresponding attributes. Will take a look.
>
>
>Rajeev> Right, the attribute itself is not sufficient, but is an enabler.
>
>
>4. The following statement in Sec 5.3 is not clear as to its intent and
>the outcome : "For Multiple PDN Connections only, a Mobile Node uses this
>attribute
>Rajeev> So, both Offload and EPC connectivity choices come into play only
>when multiple PDN connectivity is supported. (It is one or the other for
>single PDN connectivity)
>
>
>required in WiFI networks. Maybe the I-D would be simplified if it did
>not tackle the seamless mobility aspect and drop the associated
>attributes proposed.
>
>Rajeev> I assume by ³Mobility between networks² you mean the attribute
>AT_HANDOVER_SESSION_ID. This is an optional attribute which can be useful
>in determining the previous attachment of the UE. Other than that, there
>are no other attributes.
>
>Thanks.
>
>-Rajeev
>
>
>-Raj
>
>--
>Basavaraj Patil

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 20 Mar 2014 10:54:23 -0400

Thanks for your responses Rajeev. Please send an updated I-D. Also note
that there are editorial issues as well which I did not cover. You may want
to take care of them as well when you revise the I-D.

-Raj

On Mon, Mar 17, 2014 at 10:13 PM, Koodli, Rajeev <[email-masked]>wrote:

>   From: Basavaraj Patil <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <
> [email-masked]>
> Resent-To: Rajeev Koodli <[email-masked]>, <[email-masked]>
>
>
>  Hello,
>
> incorporate them in the appropriate EAP messages. However, perhaps it would
> be better to indicate specific EAP messages which can be used to carry the
> corresponding attributes. Will take a look.
>
>
>  3. The attributes to co-relate sessions when moving between 3/4G
> networks and WiFi no doubt are useful. But I am not sure if this is
> sufficient to enable seamless mobility between these disparate networks.
> Maybe it would be useful to clarify that these attributes are required in
> the context of an overall 3/4G<->WiFi mobility design.
>
>  Rajeev> So, both Offload and EPC connectivity choices come into play
> only when multiple PDN connectivity is supported. (It is one or the other
> for single PDN connectivity)
>
>
>  5. Lastly I am wondering if it is worth trying to solve multiple
> problems such as APN indication, Mobility between networks and Simultaneous
>  Rajeev> I assume by "Mobility between networks" you mean the attribute

-- 
Basavaraj Patil

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 20 Mar 2014 10:31:10 -0700

Okay. Where can I find the editorial issues? :)

-Rajeev

On Thu, Mar 20, 2014 at 7:54 AM, Basavaraj Patil <[email-masked]> wrote:

>>  1. A lot of the 3GPP concepts are covered in this document. And there
>> is not enough explanation of things like the APN etc. I would recommend
>>  2. It is not clear as to which EAP messages would include the
>> attributes such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would
>> be easier for implementers if it was clearly spelled out in a message flow.
>>
>> AT_HANDOVER_SESSION_ID. This is an optional attribute which can be
>> useful in determining the previous attachment of the UE. Other than that,
>> there are no other attributes.
>>
>>  Thanks.
>>
>>  -Rajeev
>>
>>
>>  -Raj
>>
>>  --
>> Basavaraj Patil
>>
>
>
>
> --
> Basavaraj Patil
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>
>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 20 Mar 2014 14:19:53 -0400

I was hoping you would catch then yourself :)

But I can send you a few that I noticed while reviewing it.

-Raj

On Thu, Mar 20, 2014 at 1:31 PM, Rajeev Koodli <[email-masked]>wrote:

> On Thu, Mar 20, 2014 at 7:54 AM, Basavaraj Patil <[email-masked]>wrote:
>
>>
>> On Mon, Mar 17, 2014 at 10:13 PM, Koodli, Rajeev <[email-masked]
>> > wrote:
>>
>>>
>>>  Hi Raj,
>>>
>>>  Rajeev> we do specify that in statements such as "This attribute can
>>> be included in any of the EAP Request message that
>>>  4. The following statement in Sec 5.3 is not clear as to its intent
>>> and the outcome : "For Multiple PDN Connections only, a Mobile Node uses
>>> this attribute

-- 
Basavaraj Patil