Subject: [netext] Review of I-D: draft-ietf-netext-access-network-option

From: <[email-masked]>
Date: Mon, 23 Jan 2012 17:48:17 +0000

Please find my review comments for Rev 4 of the I-D
(draft-ietf-netext-access-network-option) below:

1. The abstract can be improved to make it more relevant for a reader
   who does not know anything about Proxy MIP6.

2. In Intro section:
"In many deployments there is a need for the local mobility anchor to
   provide differentiated services and policing to ...
"

What deployments are you refering to here? Deployments that have PMIP6
entities like MAG and LMA or is it applicable to any deployment?

3. I-D states: ",the geo-location of the mobile node known to the
mobile access gateway..."

How does the MAG know the geo-location of the MN? It is misleading
since the accuracy could be less accurate if it is not coming from the
MN itself.

4. In figure 1, is the geo-location info shown that of the MAG or is
it that of the AP?

5. ANDSF and PCC have no explanations in the terminology section. It
does not help one not familiar with 3GPP standards what these entities
are.

6. The network-identifier suboption gives an example of the network
name being an SSID. Would this indicate the operator ID in the case of
cellular networks? Would it carry something like the MCC+MNC ?

7. SSIDs can be quite easily spoofed. Hence how useful is it to carry
SSID info to the LMA. As stated in the I-D, the LMA may cause a change
to the traffic based on such information. If the SSID is spoofed this
could be detrimental to the traffic/service.

8. Sec 3.1.2:
"This sub-option can be used for carrying the Geo-location of the network
to
   which the mobile node is attached, as known to the mobile access
   gateway. "

How does the MAG know the geo-location of an AP or base-station?

9. Are you reusing the format of the geo-location suboption as shown
in Fig 5?

10. Can you give an example of the operator identifier specified in
3.1.3?

11. The comment in Sec 4.1:
" The specific details on
      how the mobile access gateway obtains these information elements
      are access technology and deployment specific, and is out-side the
      scope of this document.
"

IMO, how the MAG gets these details is fairly relevant and cannot be
out-of-scope of this I-D.

12. Provide a reference to Sec 6 for : "If the protocol configuration
variable,
      EnableANISubOptNetworkIdentifier..."

13. Sec 4.1:
"If the mobile access gateway had any of the Access Network
   Information mobility option included the Proxy Binding Update sent to
   a local mobility anchor, then the Proxy Binding Acknowledgement
   received from the local mobility anchor is also expected to contain
   the Access Network Information mobility option with the specific sub-
   options.  If the mobile access gateway receives a Proxy Binding
   Acknowledgement with a successful Status Value but without an Access
   Network Information mobility option, then the mobile access gateway
   SHOULD log the event and based on its local policy MAY proceed to
   terminate the mobility session.  In this case the mobile access
   gateway knows the local mobility anchor does not understand the
   Access Network Information mobility option and therefore MAY consider
   it as a misconfiguration of the Proxy Mobile IPv6 domain.
"

A MAG is associated with different LMAs. Hence it is possible that not
all LMAs support the ANI option(s). Hence does the above behavior make
sense?

14. Sec 4.2 does not explain what the LMA MUST do if it does not
understand the ANI option.

-Basavaraj

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 24 Jan 2012 11:57:37 -0800

Hi Raj:

Thanks for the review. Please see inline.

>    who does not know anything about Proxy MIP6.

Ok. Can reword it.

> entities like MAG and LMA or is it applicable to any deployment?

The reference is related to WLAN-EPC integrated (SPWIFI) architectures. We
can qualify that.

> since the accuracy could be less accurate if it is not coming from the

Well, MN is an unmanaged entity, but its always the best source. But, as in
most radio networks this is really the association of the mobile to an
access point and the location info is derived based on that relation. Also,
as in cellular networks, there is also the triangulation schemes, based on
the users movement between AP's and is source for deriving that information.
The information related to the location is moved between AP's and the
controller over CAPWAP.

> 4. In figure 1, is the geo-location info shown that of the MAG or is

Its the location of the AP, available at the MAG. This could have been
delivered over CAPWAP, or over DHCP Option 82 from AP to controller, or
static information configured on the MAG. We can clarify.

> does not help one not familiar with 3GPP standards what these entities

Ok. We can clarify.

> cellular networks? Would it carry something like the MCC+MNC ?

We have specific sub-types defined on the semantics of the identifier. But,
sure it could be a VPLMN Id/MCC. We can clarify that.

> could be detrimental to the traffic/service.

SSID information is coming to the LMA from a trusted source. There is a
secure relation between MAG and LMA, between MAG and AP. Based on the
security in the access network, the SSID information cannot be spoofed. The
EAP messages that the MAG receives are received on a specific VLAN Id and
which can map to a specific SSID, or this information can be embedded the AP
in the DHCP option 82.

> How does the MAG know the geo-location of an AP or base-station?

It is statically configured information, sent over CAPWAP from AP to the
MAG/controller, or send as information element in DHCP Option 82.

> 9. Are you reusing the format of the geo-location suboption as shown

Yes. This is a standard format of the GEO location, in mobility option
encoding.

> 10. Can you give an example of the operator identifier specified in

provider1.example.com

> out-of-scope of this I-D.

At the minimum this information can always be static information elements on
the IE, which may be sufficient from this spec perspective.

Additionally, we can add specific references to WLAN based access
architectures and how that is tied to the north bound PMIP signaling.
Generally, SPWIFI architectures has other protocol elements from the end to
end solution perspective, specifically, CAPWAP based architectures are quite
dominant and we may have allow room for integrating the two.

>       EnableANISubOptNetworkIdentifier..."

Ok.

> all LMAs support the ANI option(s). Hence does the above behavior make

Typically, its a domain wide parameter, as with many other parameters that
we have defined.

> understand the ANI option.

It should skip like with any other option. Will clarify this.

Thanks for the review. Will take care of these comments.

Regards
Sri

> 
> -Basavaraj
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext