Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated

From: <[email-masked]>
Date: Tue, 2 Dec 2008 13:05:50 +0200

Julien and Jouni,

Could you provide a pointer to 3GPP specs that define how these
AVPs are used in 3GPP?

I tried searching, but found nothing except 23.402, which only
mentions this draft in a single sentence. Presumably, the details 
of exactly which of the AVPs are used and how are in some Stage 3 
spec, but I can't seem to find it... 

Best regards,
Pasi

> -----Original Message-----
> From: ext [email-masked] 
> [mailto:[email-masked]] 
> Sent: 27 November, 2008 15:17
> To: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Korhonen Jouni (NSN - 
> FI/Espoo); [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [AAA-DOCTORS] New version of 
> draft-ietf-dime-mip6-integrated
> 
> Dear all,
> 
>  Thanks for your clarifications, I think I better understand
> your concern now. You are true
> that we are not defining a new Diameter application here and
> that finally we just add AVPs to Diameter EAP/NASREQ. In particular
> the MIP6-Agent-Info AVP of Type Grouped. From my point of view,
> this AVP makes sense from a Diameter point of view and I'm not
> really confortable to split it to ease Diameter/RADIUS translation.
> 
>  First, I'm not sure that the most common deployment case will have
> to translate between RADIUS-MIP6 and Diameter MIP6 integrated. As
> you know, 3GPP does not use RADIUS MIP6. It would be interesting
> to see if someone has a valid scenario.
> 
>  Second, Diameter NASREQ/EAP already have some Grouped AVPs. So
> the translation agent already have to cope with this. 
> 
>  SO, I think that your comment is really valid and that we could
> probably add a recommandation somewhere in RFC3588Bis but I'm not
> sure that this could be a MUST.
> 
>  Regards,
> 
>  Julien
> 
> > -----Message d'origine-----
> > De : Jari Arkko [mailto:[email-masked]] 
> > Envoyé : jeudi 27 novembre 2008 14:01
> > À : [email-masked]
> > Cc : [email-masked]; [email-masked]; BOURNELLE 
> > Julien RD-CORE-ISS; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Objet : Re: [AAA-DOCTORS] New version of 
> > draft-ietf-dime-mip6-integrated
> > 
> > What he said.
> > 
> > jari
> > 
> > [email-masked] wrote:
> > > Glen Zorn wrote:
> > >   
> > >>> Folks,
> > >>>
> > >>> Nothing in this thread so far has come to even close to 
> > answering my 
> > >>> main concern: specifying two similar solutions (and translation 
> > >>> between them) means more complexity and more work. Why is this 
> > >>> complexity and work needed?
> > >>>       
> > >> Which complexity and work would that be?  Translation 
> > between RADIUS 
> > >> and Diameter cannot be avoided, if that's the problem you see.
> > >>     
> > >
> > > We're clearly not on the same page here. Let me try to 
> > explain why I 
> > > believe why this is unnecessary complexity and work:
> > >
> > > Consider another draft that has been discussed in RADEXT:
> > > draft-aboba-radext-wlan. It would be possible to write a new 
> > > Internet-Draft that would define Diameter AVPs (in >255 range, 
> > > possibly using grouped AVPs and other Diameter-only features) for 
> > > exactly the same purpose.
> > >
> > > I am claiming this would be a very bad idea, because it 
> would mean 
> > > more complexity and more work, and with little benefits.
> > >
> > > When you're defining attributes for use in existing 
> > messages (no new 
> > > Diameter application or anything), IMHO it should be done 
> > in the 0-255 
> > > range, even if that means Diameter features like grouping 
> > need to be 
> > > avoided.
> > >
> > > If I understand your position right, you're saying it would 
> > be OK to 
> > > have two different numbers for e.g. the Allowed-Called-Station-Id 
> > > attribute?
> > >
> > >   
> > >>> So far, I have heard only explanations about how this 
> > situation came 
> > >>> to happen: somewhere down the line, two WGs ended up 
> > taking on the 
> > >>> work, and one of them (DIME) made decisions that made 
> > sense locally 
> > >>> (when considering only Diameter aspects), and their 
> draft came to 
> > >>> IESG first.
> > >>> Interestingly enough, the other WG (MEXT) has been working on a 
> > >>> RADIUS+Diameter solution (not a RADIUS-only solution!),
> > >>>       
> > >> Any work using RADIUS Attributes from the standard 
> > typespace may be 
> > >> trivially claimed to be a "RADIUS+Diameter solution" if no 
> > >> translation other than that specified in RFC 4005 & RFC 3588 is 
> > >> performed.
> > >>     
> > >
> > > Yes. And I think such solutions often make sense.
> > >
> > >   
> > >> In fact, however, draft-ietf-mip6-radius-06.txt (if that 
> > is what you 
> > >> are referring to) requires further translation: "MIP6-HA and
> > >> HOA-IPv6 must be translated between their RADIUS 
> representation of 
> > >> String to a Diameter Address format which requires that the 
> > >> AddressType field be set to 2 for IP6 (IP version 6)".
> > >>     
> > >
> > > That's a bad design choice in mip6-radius-06 that could be easily 
> > > fixed. If it used the same approach as was used for e.g.
> > > Framed-IP-Address, no translation (beyond copying) would 
> be needed.
> > >
> > >   
> > >> Furthermore, a pretty good case could be made that the draft in 
> > >> question is not only not a "RADIUS+Diameter solution", but 
> > not even a 
> > >> "RADIUS-only solution" due to the novel semantics it 
> > assigns to the 
> > >> Access-Accept message.
> > >>     
> > >
> > > The "novel semantics" probably refer to the "split 
> > scenario" (which is 
> > > indeed more complex, and could be in a separate document).
> > >
> > >   
> > >>> and if they had sent their document to IESG first, we 
> > probably would 
> > >>> not even consider publishing draft-ietf-dime-mip6-integrated.
> > >>>       
> > >> It didn't get to the IESG first because it's not ready for prime 
> > >> time.  I do find it interesting that a Security Area Director is 
> > >> ready to approve a document with such weak security properties, 
> > >> however.
> > >>     
> > >
> > > The "weak security properties" refer to the "split 
> scenario".  The 
> > > "integrated scenario" are ready for prime time, and are 
> > delayed only 
> > > by editorial decision to keep them in the same text file.
> > >
> > > Best regards,
> > > Pasi
> > >
> > >
> > >   
> > 
> > 
> 
_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: "jouni korhonen" <[email-masked]>
Date: Tue, 2 Dec 2008 14:17:47 +0200

in 3GPP 29.272, 29.273 and in 3gpp2 X.P0047..

---

From: <[email-masked]>
Date: Fri, 5 Dec 2008 14:06:54 +0200

Jouni,
 
Thanks for the pointers!
 
I took a look at these specs, and it seems they're using only some parts of draft-ietf-dime-mip6-integrated. None of these seem to describe a case where information about more than one Home Agent is sent (which would benefit from grouped AVPs), and neither use the MIP6-Home-Link-Prefix AVP. (29.273 Section 9.2.2 ABNF does allow more than one MIP6-Agent-Info AVP, but the text doesn't describe any other case than a single PDN GW.)
 
Do you know if e.g. 3GPP plans to add more semantics from dime-mip6-integrated to these specs? Or is dime-mip6-integrated actually describing more functionality than other SDOs are currently planning to use? 
 
Best regards,
Pasi

________________________________

	From: ext jouni korhonen [mailto:[email-masked]] 
	Sent: 02 December, 2008 14:18
	To: Eronen Pasi (Nokia-NRC/Helsinki)
	Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Korhonen Jouni (NSN - FI/Espoo); [email-masked]; [email-masked]
	Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated

		Julien and Jouni,

		Best regards,
		Pasi

---

From: jouni <[email-masked]>
Date: Sun, 7 Dec 2008 12:32:54 +0200

Pasi,

On Dec 5, 2008, at 2:06 PM, <[email-masked]> <[email-masked] 
 > wrote:

> Jouni,
>
> Thanks for the pointers!
>
> I took a look at these specs, and it seems they're using only some  
> parts of draft-ietf-dime-mip6-integrated.

Hopefully you  found the latest ones. At least those on 3GPP site that  
I found, were 1-2 meeting cycles behind  (checked this morning the  
official specs download pages). Anyway, other SDOs who picked up this  
standards track I-D, are still according to my limited knowledge  
completely align with the I-D (even if they may not use all possible  
features).

> None of these seem to describe a case where information about more  
> than one Home Agent is sent (which would benefit from grouped AVPs),  
> and neither use the MIP6-Home-Link-Prefix AVP. (29.273 Section 9.2.2  
> ABNF does allow more than one MIP6-Agent-Info AVP, but the text  
> doesn't describe any other case than a single PDN GW.)
>
> Do you know if e.g. 3GPP plans to add more semantics from dime-mip6- 
> integrated to these specs? Or is dime-mip6-integrated actually  
> describing more functionality than other SDOs are currently planning  
> to use?

I cannot say what other SDOs plan to do in the future. Current I-D  
describes more functionality what the above spec decided to use at the  
moment. However, whether they e.g. end up signaling one or more "agent  
infos" is allowed by current the I-D. That's up to their deployment  
view, which might not be the same for others in the future.

Cheers,
	Jouni

> Cc: [email-masked]; [email-masked]; [email-masked] 
> ; [email-masked]; Korhonen Jouni (NSN - FI/Espoo); [email-masked] 
> ; [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Dec 2008 10:31:35 +0100

Pasi, 

What is the way forward? Have all your questions been clarified, or do you expect more information from the document editors? 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of jouni
> Sent: Sunday, December 07, 2008 12:33 PM
> To: <[email-masked]>
> Cc: [email-masked] Chowdhury; 
> [email-masked]; [email-masked]; 
> julien.bournelle@orange-ftgroup.; [email-masked]
> On Dec 5, 2008, at 2:06 PM, <[email-masked]> 
> <[email-masked]  > wrote:
> 
> > Jouni,
> >
> > Thanks for the pointers!
> >
> Hopefully you  found the latest ones. At least those on 3GPP 
> site that I found, were 1-2 meeting cycles behind  (checked 
> this morning the official specs download pages). Anyway, 
> other SDOs who picked up this standards track I-D, are still 
> according to my limited knowledge completely align with the 
> I-D (even if they may not use all possible features).
> 
> I cannot say what other SDOs plan to do in the future. 
> Current I-D describes more functionality what the above spec 
> decided to use at the moment. However, whether they e.g. end 
> up signaling one or more "agent infos" is allowed by current 
> the I-D. That's up to their deployment view, which might not 
> be the same for others in the future.
> 
> Cheers,
> 	Jouni
> 
> 
> >
> > Best regards,
> > Pasi
> >
> > Cc: [email-masked]; 
> [email-masked]; [email-masked] 
> > > > > possibly using grouped AVPs and other Diameter-only 
> features)  
> > for
> > > > > have two different numbers for e.g. the 
> Allowed-Called-Station- 
> > Id
> > > > > attribute?
> > > > >
> > > > >
> > > > >> time.  I do find it interesting that a Security Area 
> Director  
> > is

---

From: <[email-masked]>
Date: Fri, 12 Dec 2008 12:29:16 +0200

Dan, Jari, Jouni & others,

The situation seems to be that the RADIUS work will be probably used
by different SDOs than the Diameter work, so (1) translation may not
be needed, and (2) translation may not be even possible, because the
documents have different semantics (this is the case for the latest
draft versions; and may continue to be the case if the SDOs using
RADIUS have slightly different requirements).

While these arguments are not really about the technical solutions but
the process of writing the documents, it seems the RADIUS parts are
considerably less mature (and the required semantics may still change), 
while 3GPP apparently already knows what semantics it needs.

I guess this could be a possible reason for leaving the MIP6-Agent-Info
AVP in the Diameter number space.

Jari, would this work for you?

Looking back at the emails, the following things (not related to
this RADIUS/Diameter topic) were still not handled in the -11 version:

- Describing the semantics of the MIP6-Home-Link-Prefix in request
  messages.

- If the message contains information about multiple HAs, which home
  agent(s) the prefix(es) in MIP6-Home-Link-Prefix AVP(s) belong to.
  (One way to solve this would be to move it inside the Grouped AVP;
  another way would be to prohibit its use if the message contains
  multiple HAs; other solutions may be possible)

- Clarifying the use of "realm" for MIP-Home-Agent-Host (the text
  proposed by Jouni on 2008-11-27 looks OK to me)

Best regards,
Pasi 

> From: ext Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: 11 December, 2008 11:32
> To: jouni; Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; 
> Korhonen Jouni (NSN - FI/Espoo); 
> What is the way forward? Have all your questions been 
> clarified, or do you expect more information from the 
> document editors? 
> 
> Dan
>  
> 
> > > > > > Internet-Draft that would define Diameter AVPs (in 
> >255 range,
> > > > > >>> Interestingly enough, the other WG (MEXT) has 
> been working  
> > > on a
> > > > > >> It didn't get to the IESG first because it's not 
> ready for  
> > > prime

---

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Dec 2008 13:47:35 +0200

Sorry, I have been fighting fires on many fronts and not been able to 
pay enough attention to this discussion. But yes, this does look reasonable.

Jari

[email-masked] wrote:
>>>> I took a look at these specs, and it seems they're using 
>>>>         
>> only some 
>>     
>>>> None of these seem to describe a case where information 
>>>>         
>> about more 
>>     
>>>> than one Home Agent is sent (which would benefit from 
>>>>         
>>> grouped AVPs), 
>>>       
>>>> and neither use the MIP6-Home-Link-Prefix AVP. (29.273 
>>>>         
>>> Section 9.2.2 
>>>       
>>>> Do you know if e.g. 3GPP plans to add more semantics from 
>>>>         
>>> dime-mip6- 
>>>       
>>>> describing more functionality than other SDOs are currently 
>>>>         
>>> planning 
>>>       
>>>> to use?
>>>>         
>>>> ; [email-masked]; Korhonen Jouni (NSN - FI/Espoo); 
>>>>         
>>> [email-masked] 
>>>       
>>>>> that finally we just add AVPs to Diameter EAP/NASREQ. In 
>>>>>           
>>> particular
>>>       
>>>>> really confortable to split it to ease Diameter/RADIUS 
>>>>>           
>>> translation.
>>>       
>>>>>  First, I'm not sure that the most common deployment case 
>>>>>           
>>> will have
>>>       
>>>>> to translate between RADIUS-MIP6 and Diameter MIP6 
>>>>>           
>> integrated. As
>>     
>>>>> probably add a recommandation somewhere in RFC3588Bis 
>>>>>           
>> but I'm not
>>     
>>>>>>>>> main concern: specifying two similar solutions (and  
>>>>>>>>>                   
>>>> translation
>>>>         
>>>>>>>>> between them) means more complexity and more work. 
>>>>>>>>>                   
>>> Why is this
>>>       
>>>>>>>> and Diameter cannot be avoided, if that's the 
>>>>>>>>                 
>>> problem you see.
>>>       
>>>>>>>> translation other than that specified in RFC 4005 & 
>>>>>>>>                 
>>> RFC 3588 is
>>>       
>>>>>>>> performed.
>>>>>>>>
>>>>>>>>                 
>>>>>>>> are referring to) requires further translation: 
>>>>>>>>                 
>> "MIP6-HA and
>>     
>>>>>>> That's a bad design choice in mip6-radius-06 that could be  
>>>>>>>               
>>>> easily
>>>>         
>>>>>>>> Furthermore, a pretty good case could be made that 
>>>>>>>>                 
>>> the draft in
>>>       
>>>>>>>>> not even consider publishing 
>>>>>>>>>                   
>>> draft-ietf-dime-mip6-integrated.
>>>       
>>>>>>>> ready to approve a document with such weak security 
>>>>>>>>                 
>>> properties,
>>>       
>>>>>>>> however.
>>>>>>>>
>>>>>>>>

---

From: jouni korhonen <[email-masked]>
Date: Mon, 15 Dec 2008 13:35:42 +0200

Pasi, all,

On Dec 12, 2008, at 12:29 PM, <[email-masked]> <[email-masked] 

> - Describing the semantics of the MIP6-Home-Link-Prefix in request

Would the following text in Section 4.2.4 work for you?

Old:

    The HAAA MAY act as a central entity managing prefixes for MNs.  In
    this case, the HAAA returns the prefix allocated for the MN and
    returns it the NAS.  The NAS/ASP uses then, for example, mechanisms
    described in [I-D.ietf-mip6-bootstrapping-integrated-dhc] to deliver
    the home link prefix to the MN.

New:

    The HAAA MAY act as a central entity managing prefixes for MNs.  In
    this case, the HAAA returns the prefix allocated for the MN and
    returns it the NAS.  The NAS/ASP uses then, for example, mechanisms
    described in [I-D.ietf-mip6-bootstrapping-integrated-dhc] to deliver
    the home link prefix to the MN. The NAS/ASP MAY propose a specific
    prefix allocation to the HAAA by including the MIP6-Home-Link-Prefix
    AVP in the request message. However, the HAAA is MAY override the
    prefix allocation hint proposed by the NAS/AAA and return a  
different
    prefix in the response message.

>  multiple HAs; other solutions may be possible)

Actually, I have a vague recollection that independent of number of the
HAs, there would be only one prefix. I cannot find anything to back up
this now, though.

Thus, we could move the MIP6-Home-Link-Prefix AVP inside the MIP6- 
Agent-Info
AVP (in that case, we could actually consider using the Framed-IPv6- 
Prefix
AVP instead of the MIP6-Home-Link-Prefix AVP). Or we could add text that
says using the MIP6-Home-Link-Prefix AVP when there are multiple HAs  
does
not make much sense.

>  proposed by Jouni on 2008-11-27 looks OK to me)

Ok great.

Cheers,
	Jouni

---

From: <[email-masked]>
Date: Mon, 15 Dec 2008 18:34:11 +0100

Hi Jouni, All,

See comments below.

> De : [email-masked] 
> [mailto:[email-masked]] De la part de jouni korhonen
> Envoyé : lundi 15 décembre 2008 12:36
> À : <[email-masked]>
> Cc : [email-masked]; [email-masked]; 
> BOURNELLE Julien RD-CORE-ISS; [email-masked]
> On Dec 12, 2008, at 12:29 PM, <[email-masked]> 
> > considerably less mature (and the required semantics may still 
> > change), while 3GPP apparently already knows what semantics 
> it needs.
> >
> > I guess this could be a possible reason for leaving the MIP6-Agent- 
> > Info AVP in the Diameter number space.
> >
> > Looking back at the emails, the following things (not 
> related to this 
> > RADIUS/Diameter topic) were still not handled in the -11 version:
> >
>     prefix allocation hint proposed by the NAS/AAA and return 
> a different

Proposed editorial correction if the basis is ok:

New (modified):

    The HAAA MAY act as a central entity managing prefixes for MNs.  In
    this case, the HAAA returns to the NAS the prefix allocated to the MN.
    The NAS/ASP delivers then the home link prefix to the MN using e.g. mechanisms
    described in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. The NAS/ASP MAY propose to the HAAA a specific
    prefix to allocate to the MN by including the MIP6-Home-Link-Prefix
    AVP in the request message. However, the HAAA MAY override the
    prefix allocation hint proposed by the NAS/ASP and return a different
    prefix in the response message.
> Actually, I have a vague recollection that independent of 
> number of the HAs, there would be only one prefix. I cannot 
> find anything to back up this now, though.

Question: in which situation would we have multiple (distinct) HAs in the response?

> 
> Thus, we could move the MIP6-Home-Link-Prefix AVP inside the 
> MIP6- Agent-Info AVP (in that case, we could actually 
> consider using the Framed-IPv6- Prefix AVP instead of the 
> MIP6-Home-Link-Prefix AVP). Or we could add text that says 
> using the MIP6-Home-Link-Prefix AVP when there are multiple 
> HAs does not make much sense.

Is there a specific reason to let anyway the prefix information outside the MIP6-Agent-Info Grouped AVP?
Is it foreseen to receive (in the response from the AAA) the prefix witout the Home agent info?
If not, I think it is a reason good enough to find all the required AVP in the same grouped AVP..

BR,

Lionel
  
> >> Cc: [email-masked]; [email-masked]; Korhonen 
> >> Jouni (NSN - FI/Espoo); julien.bournelle@orange-ftgroup.; 
> >> [email-masked]
> clarified, or 
> >> do you expect more information from the document editors?
> >>
> >> Dan
> >>
> >>
> [email-masked]; 
> >>> [email-masked]; julien.bournelle@orange-ftgroup.; 
> >>> [email-masked]
> >>> Hopefully you  found the latest ones. At least those on 3GPP site 
> >>> that I found, were 1-2 meeting cycles behind  (checked 
> this morning 
> >>> the official specs download pages). Anyway, other SDOs 
> who picked up 
> >>> this standards track I-D, are still according to my limited 
> >>> knowledge completely align with the I-D (even if they may not use 
> >>> all possible features).
> >>>
> >>> Current I-D describes more functionality what the above 
> spec decided 
> >>> to use at the moment. However, whether they e.g. end up signaling 
> >>> one or more "agent infos" is allowed by current the I-D. 
> That's up 
> >>> to their deployment view, which might not be the same for 
> others in 
> >>> the future.
> >>>
> >>> Cheers,
> >>> 	Jouni
> >>>
> >>>
> >>>>
> >>>> Best regards,
> >>>> Pasi
> >>>>
> FI/Espoo); 
> >>>>> [email-masked]; [email-masked]; 
> >>>>> Thanks for your clarifications, I think I better 
> understand your 
> >>>>> concern now. You are true that we are not defining a 
> new Diameter 
> >>>>> application here and that finally we just add AVPs to Diameter 
> >>>>> EAP/NASREQ. In
> >>> particular
> >>>>> Second, Diameter NASREQ/EAP already have some Grouped 
> AVPs. So the 
> >>>>> translation agent already have to cope with this.
> >>>>>
> >>>>>> De : Jari Arkko [mailto:[email-masked]] Envoyé : 
> jeudi 27 
> >>>>>> novembre 2008 14:01 À : [email-masked] Cc : 
> >>>>>> [email-masked]; [email-masked]; BOURNELLE Julien 
> >>>>>> RD-CORE-ISS; [email-masked]; 
> Objet : Re: 
> >>>>>> [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated
> >>>>>>
> >>>>>> What he said.
> >>>>>>
> >>>>>> jari
> >>>>>>

---

From: jouni <[email-masked]>
Date: Mon, 15 Dec 2008 21:30:26 +0200

Hi Lionel,

On Dec 15, 2008, at 7:34 PM, <[email-masked]> <[email-masked] 

[snip]

>    described in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. The  
> NAS/ASP MAY propose to the HAAA a specific

Works for me.

> Question: in which situation would we have multiple (distinct) HAs  

e.g. when you receive HA information from both home and visited  
networks. That
usecase is described in the I-D.

> AVP in the same grouped AVP..

I am also leaning towards to this solution i.e. including prefix  
information inside the
grouped AVP.

Cheers,
	Jouni

---

From: Tina TSOU <[email-masked]>
Date: Tue, 16 Dec 2008 10:08:58 +0800

Hi all,
Some comments are below.

1) Section 4.2.1, when the MIP-home-agent-host AVP (w/o the MIP-home-agent-address AVP) is returned, does the NAS need to notify Diameter server if it gets a new home agent address via DNS from MIP-home-agent-host AVP?
In a certain case (e.g. PMIP-MIP interaction), it may be necessary to get the same HA/LMA to guarantee session continuity.

2) Section 4.2.5, 
Case 1, a request message contains, 
    LOCAL-bit  HA-Info  
      1          -      
and the answer message contains,
      1         H-HA + L-HA
while, how does the NAS identify in which MIP6-Agent-Info AVP the H-HA presents?

case 2, a request message contains, (allocated by NAS)
    LOCAL-bit  HA-Info  
      1         L-HA1
and the answer message contains, (allocated by visited network)
      1         L-HA2
or the answer message contains, (allocated by home network and visited network)
      1         H-HA + L-HA2
while, does it mean 'two L-HA can be used' or 'only L-HA2 can be used' by the NAS? 
or is this case allowed?

Wish you a joyful greeting season! :D

B. R.
Tina
  ----- Original Message ----- 
  From: jouni 
  To: <[email-masked]> 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Tuesday, December 16, 2008 3:30 AM
  Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated

  Hi Lionel,

  [snip]

  Works for me.

  Cheers,
  Jouni

---

From: Tina TSOU <[email-masked]>
Date: Tue, 16 Dec 2008 12:07:33 +0800

Hi all,
For my previous 2nd comment, I re-considered it, I made comments to myself. (Sorry;)

B. R.
Tina
  ----- Original Message ----- 
  From: Tina TSOU 
  To: [email-masked] ; jouni 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Tuesday, December 16, 2008 10:08 AM
  Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated

  Hi all,
  Some comments are below.

  2) Section 4.2.5, 

  case 2, a request message contains, (allocated by NAS)
      LOCAL-bit  HA-Info  
        1         L-HA1
  and the answer message contains, (allocated by visited network)
        1         L-HA2
  [Tina: When looking at Figure2 and 4 again, I think NAS could be co-located with VAAA in this scenario.]

  or the answer message contains, (allocated by home network and visited network)
        1         H-HA + L-HA2
  while, does it mean 'two L-HA can be used' or 'only L-HA2 can be used' by the NAS? 
  or is this case allowed?
  [Tina: When looking at second paragraph in section 5.3 again,
  "Whether the NAS/ASP then offers a locally assigned HA or the Diameter

     server assigned HA to the MN is, in this example, based on the local

     ASP policy."

  My comment above is perhaps be out of scope, or it could be solve in some other document.]

  B. R.
  Tina
    ----- Original Message ----- 
    From: jouni 
    To: <[email-masked]> 
    Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
    Sent: Tuesday, December 16, 2008 3:30 AM
    Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated

    Hi Lionel,

    [snip]

    Works for me.

    Cheers,
    Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 16 Dec 2008 08:13:09 +0200

Tina,

Few comments inline:

On Dec 16, 2008, at 4:08 AM, Tina TSOU wrote:

> Hi all,
> Some comments are below.
>
> 1) Section 4.2.1, when the MIP-home-agent-host AVP (w/o the MIP-home- 
> agent-address AVP) is returned, does the NAS need to notify Diameter  
> server if it gets a new home agent address via DNS from MIP-home- 
> agent-host AVP?
> In a certain case (e.g. PMIP-MIP interaction), it may be necessary  
> to get the same HA/LMA to guarantee session continuity.

This matter is not in scope of this document. The problem is  
interesting and important though. There was a recent I-D in NetLMM to  
discuss stuff around LMA discovery and the issue you brought up. See http://tools.ietf.org/html/draft-korhonen-netlmm-lma-discovery-00

> while, how does the NAS identify in which MIP6-Agent-Info AVP the H- 

Using the MIP-Home-Agent-Host AVP. The text has been word smithed to  
be slightly more accurate during the IESG discussion (that's what Pasi  
referred 2008-11-27 text being OK).

> while, does it mean 'two L-HA can be used' or 'only L-HA2 can be  

hmm? Ok, saw your followup mail on this.

Cheers,
	Jouni

> Cc: [email-masked] ; [email-masked] ; [email-masked] 
>  ; [email-masked] ;[email-masked]
> Korhonen
> site

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 19:41:50 +0200

Jouni Korhonen wrote:

>     The HAAA MAY act as a central entity managing prefixes for MNs.
>     In this case, the HAAA returns the prefix allocated for the MN
>     and returns it the NAS.  The NAS/ASP uses then, for example,
>     mechanisms described in
>     [I-D.ietf-mip6-bootstrapping-integrated-dhc] to deliver the home
>     link prefix to the MN.
> 
> New:
> 
>     The HAAA MAY act as a central entity managing prefixes for MNs.
>     In this case, the HAAA returns the prefix allocated for the MN
>     and returns it the NAS.  The NAS/ASP uses then, for example,
>     mechanisms described in
>     [I-D.ietf-mip6-bootstrapping-integrated-dhc] to deliver the home
>     link prefix to the MN. The NAS/ASP MAY propose a specific prefix
>     allocation to the HAAA by including the MIP6-Home-Link-Prefix
>     AVP in the request message. However, the HAAA is MAY override
>     the prefix allocation hint proposed by the NAS/AAA and return a
>     different prefix in the response message.

Both this and Lionel's slightly edited version look OK to me.

> Actually, I have a vague recollection that independent of number of
> the HAs, there would be only one prefix. I cannot find anything to
> back up this now, though.
> 
> Agent-Info AVP (in that case, we could actually consider using the
> Framed-IPv6- Prefix AVP instead of the MIP6-Home-Link-Prefix
> AVP). Or we could add text that says using the MIP6-Home-Link-Prefix
> AVP when there are multiple HAs does not make much sense.

I slightly prefer moving it inside the grouped AVP.

Best regards,
Pasi

---

From: jouni korhonen <[email-masked]>
Date: Tue, 30 Dec 2008 12:25:16 +0200

Hi Pasi, all,

According to my notes we have now converged to a common understanding  
on this I-D. I have prepared an update of the I-D that includes all  
comments. See the following link for the diff (PDF) that summarizes  
changes since the -10 that was submitted to the IESG: http://www.tschofenig.priv.at/svn/draft-ietf-dime-mip6-integrated/dime-mip6-integrated-10-to-12-diff.pdf

Does this revision match others' idea of the agreed on changes?

Cheers,
	Jouni

On Dec 18, 2008, at 7:41 PM, <[email-masked]> <[email-masked]