Re: [Dime] Review of draft-korhonen-dime-pmip6-03.txt

[<[e-mail]>]

It seems this never reached the Dime mailing list for some
reason.. resending it.

Cheers,
	JOuni


-------

 From: Jouni Korhonen <[e-mail]>
 Date: August 8, 2008 10:26:49 AM GMT+03:00
 To: "Tschofenig, Hannes (NSN - FI/Espoo)" 
[e-mail]>
 Cc: <[e-mail]>
 Subject: Re: [Dime] Review of draft-korhonen-dime-pmip6-03.txt


 Hi Hannes,

 Thanks for a review. See some replies inline.

 On Aug 7, 2008, at 1:37 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> A few review comments.
>
> In the abstract you write:
>
> "
> Rather than defining a completely new set of
>    attributes or a new Diameter application this specification  
> leverages
>    the work that has already been done for the Mobile IPv6
>    bootstrapping.
> "
>
> This sentence is somewhat misleading since you define a Diameter
> application.

 Ok. Actually we got two interfaces (as you note later). The other
 defines an application and the other one does not. I need to clarify
 the text above.

> Figure 1 is helpful but I think you could point out that you are
> actually describing two  different "interfaces" in this document. I
> initially did not got that point since you  referred also to the
> Diameter Mobile IPv6 boostrapping work where we separated them into 2
> documents.
>
> Hence, I would enhance the figure with something like:
>
>
>    +--------+
>    | HAAA & | Diameter +-----+
>    | Policy |<--(1)--->| LMA |
>    | Profile|          +-----+
>    +--------+             | <--- LMA-Address
>         ^                 |
>         |               // \\
>     +---|------------- //---\\----------------+
>    (    |  IPv4/IPv6  //     \\ Proxy Mobile IPv6
>    (    |   Network  //       \\               )
>     +---|-----------//---------\\-------------+
>         |          //           \\
>     Diameter      // <- Tunnel1  \\ <- Tunnel2
>       (2)        //               \\
>         |        |- MAG-Address1   |- MAG-Address2
>         |     +----+             +----+
>         +---->|MAG1|             |MAG2|
>               +----+             +----+
>                  |                 |
>                  |                 |
>                [MN1]             [MN2]
>
>
>   Legend:
>
>     (1): LMA <-> HAAA interaction is described
>          in Section 6
>     (2): MAG <-> HAAA interaction is described
>          in Section 5

 OK.

> * I was also lacking sementic of the PMIP6-DHCP-Address AVP a bit.
> How does the information flow look like?

 The AAA may return a DHCP (4 or 6) server address to the MAG. THis
 would be useful in deployments where the MAG implements a DHCP Relay.
 So the MAG receives the DHCP Server address over the MAG-AAA  
 interface,
 and uses the server address for *this* subscriber/realm when relaying
 DHCP requests.

> *  MIP6-Agent-Info AVP
>
> The description currently does not provide enough information why  
> this
> AVP is needed.
> What happens when an entity receives this AVP?
> Why would one send it?

 This is one way of doing dynamic LMA discovery. So the AAA knows which
 LMA to assign for the authenticating subscriber. MAG uses 
 it to figure
 out the LMA where to send subsequent PBUs..

> I also wonder whether it wouldn't make sense to create a new AVP  
> if the
> semantic is sufficiently different.

 The behavior from AAA interface point of view is equivalent to
 integrated bootstrapping.. just that the HA/LMA information is
 not passed to the MN but used by MAG.

 I agree we should define new AVPs inside the MIP6-Agent-Info
 dedicated for the LMA address. We have talked this offline
 with some folks.

> * MAG-to-HAAA:
>
> You might want to make it explicit in the text that you do not  
> define a
> new Diameter  application for this interface. The LMA to HAAA section
> starts very similar but defines a new

 OK.

> Diameter application. Both sections say "This document re-uses the
> Diameter NASREQ [6] and the EAP [7]
> applications". While this is correct the outcome is very different.
>
> I would also shorten the subject header a bit. Something like
> "MAG-to-HAAA Interface" and "LMA-to-HAAA Inferface" should be
> sufficient.

 OK.

> The following text seems a bit fuzzy to me:
>
> "
>    The Diameter response messages MAY contain Framed-IPv6-Prefix  
> and/or
>    Framed-IPv4-Address AVPs.  For example a local Diameter proxy  
> MAY add
>    those in order to advertise locally available prefixes and  
> addresses
>    as well [16].  It is also possible that PMIPv6 mobility support is
>    not allowed for a subscription.  In this case, a MAG may still
>    provide normal IP connectivity to the MN using, for example, local
>    address pools.
> "
>
> What is the semantic of the Framed-IPv6-Prefix in relationship to the
> other
> addresses being defined in this document?

 I am not sure if this is valid anymore but the originally the reason
 was the following:

 It was discussed whether it would make sense to allow PMIP-based  
 mobility
 for some prefixes and for some not. So the prefixes with mobility  
 would be
 signaled using PMIP specific AVPs where as prefixes without  
 mobility would
 use Framed-IPv6-Prefix AVPs. MAG/NAS could then treat prefixes  
 differently
 (note that how the MN would know the difference is not solved yet..  
 there
 has been RA/RS based proposals around).

> * LMA-to-MAG
>
> The text at the beginning of the sentence is repeated again in  
> Section
> 6.2.
>
>
> You write:
>
> "
> The identity SHOULD be the same as
>    used on the MAG to HAAA interface, but in a case those identities
>    differ the HAAA MUST have a mechanism of mapping the MN  
> identity used
>    on the MAG to HAAA interface to the identity used on the LMA to  
> HAAA
>    interface.
> "
>
> In what cases are they different?

 One example.. the MN authenticates (over the MAG-AAA interface) using
 some EAP-method that provides identity hiding. So the identity the
 MAG/NAS puts into the User-Name AVP for the access authentication
 could be then different from what gets used in a PBU as the MN-ID.
 The LMA would use the identity taken from the PBU MN-ID when  
 communicating
 with the AAA over the LMA-AAA interface. So the identities could  
 potentially
 be different and the AAA must be able to map them as one internally  
 in that
 case. If some deployment uses the same identity in all cases & places,
 fine.. but that must not restrict the flexibility of the AAA  
 interfaces.

>
> You write:
> "
>    If the PBU contains the MN interface identifier option, the  
> Calling-
>    Station-Id AVP SHOULD be included in the request message  
> containing
>    the received interface identifier.  Furthermore, if the PBU  
> contains
>    the Service Selection mobility option [18], the Called-Station- 
> Id AVP
>    SHOULD be included in the request message containing the received
>    service identifier.
> "
>
> Why do you overload the Called-Station-Id?
> Are those the only two cases, i.e., is it MUST contain either  
> interface
> id or service identifier?

 Oops. Yes. Good catch. For the services we  should use the same AVP
 that is now defined for the mip6-split document (i.e. the Service- 
 Selection
 AVP).

>
> In the introduction you say that this is only used for authorization,
> see:
> "
> A new Diameter application is needed for the LMA to HAAA interface
>    when authorizing Proxy Binding Updates and subscriber's mobility
>    service session.
> "
>
> Does this mean that you set the request to 'authorize-only'?

 Yes. Good catch again.

> * AVP Occurrence Table section
>
> I would define separate AVP flag tables for the two interfaces and  
> for
> the commands.
>
> For example, in Section 6.2 you define this new application; do you
> expect certain AVPs to be understood by the receiving end?
>

 Yeah. These tables need work.

 Cheers,
 	Jouni

> Ciao
> Hannes
>
_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime