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

[<[e-mail]>]

 Hi Jouni, All,

See comments below.

> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] De la part de jouni korhonen
> Envoyé : lundi 15 décembre 2008 12:36
> À : <[e-mail]>
> Cc : [e-mail]; [e-mail]; 
> BOURNELLE Julien RD-CORE-ISS; [e-mail]
> Objet : Re: [AAA-DOCTORS] New version of 
> draft-ietf-dime-mip6-integrated
> 
> 
> Pasi, all,
> 
> 
> On Dec 12, 2008, at 12:29 PM, <[e-mail]> 
> <[e-mail]  > wrote:
> 
> > 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.
> 
> 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.

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.
> 
> 
> >
> > - 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)
> 
> 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
  
> 
> >
> >
> > - Clarifying the use of "realm" for MIP-Home-Agent-Host (the text  
> > proposed by Jouni on 2008-11-27 looks OK to me)
> 
> Ok great.
> 
> Cheers,
> 	Jouni
> 
> 
> >
> >
> > Best regards,
> > Pasi
> >
> >> -----Original Message-----
> >> From: ext Romascanu, Dan (Dan) [mailto:[e-mail]]
> >> Sent: 11 December, 2008 11:32
> >> To: jouni; Eronen Pasi (Nokia-NRC/Helsinki)
> >> Cc: [e-mail]; [e-mail]; Korhonen 
> >> Jouni (NSN - FI/Espoo); julien.bournelle@orange-ftgroup.; 
> >> [e-mail]
> >> Subject: RE: [AAA-DOCTORS] New version of 
> >> draft-ietf-dime-mip6-integrated
> >>
> >> Pasi,
> >>
> >> What is the way forward? Have all your questions been 
> clarified, or 
> >> do you expect more information from the document editors?
> >>
> >> Dan
> >>
> >>
> >>> -----Original Message-----
> >>> From: [e-mail]
> >>> [mailto:[e-mail]] On Behalf Of jouni
> >>> Sent: Sunday, December 07, 2008 12:33 PM
> >>> To: <[e-mail]>
> >>> Cc: [e-mail] Chowdhury; 
> [e-mail]; 
> >>> [e-mail]; julien.bournelle@orange-ftgroup.; 
> >>> [e-mail]
> >>> Subject: Re: [AAA-DOCTORS] New version of 
> >>> draft-ietf-dime-mip6-integrated
> >>>
> >>> Pasi,
> >>>
> >>> On Dec 5, 2008, at 2:06 PM, <[e-mail]> 
> >>> <[e-mail]  > 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
> >>>
> >>>
> >>>>
> >>>> Best regards,
> >>>> Pasi
> >>>>
> >>>> From: ext jouni korhonen [mailto:[e-mail]]
> >>>> Sent: 02 December, 2008 14:18
> >>>> To: Eronen Pasi (Nokia-NRC/Helsinki)
> >>>> Cc: [e-mail];
> >>> [e-mail]; [e-mail]
> >>>> ; [e-mail]; Korhonen Jouni (NSN - FI/Espoo);
> >>> [e-mail]
> >>>> ; [e-mail]
> >>>> Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6- 
> >>>> integrated
> >>>>
> >>>> in 3GPP 29.272, 29.273 and in 3gpp2 X.P0047..
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Dec 2, 2008 at 1:05 PM, <[e-mail]> wrote:
> >>>> 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 [e-mail]
> >>>>> [mailto:[e-mail]]
> >>>>> Sent: 27 November, 2008 15:17
> >>>>> To: [e-mail]; Eronen Pasi (Nokia-NRC/Helsinki)
> >>>>> Cc: [e-mail]; [e-mail]; 
> >>>>> [e-mail]; Korhonen Jouni (NSN - 
> FI/Espoo); 
> >>>>> [e-mail]; [e-mail]; 
> >>>>> [e-mail]
> >>>>> 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:[e-mail]] Envoyé : 
> jeudi 27 
> >>>>>> novembre 2008 14:01 À : [e-mail] Cc : 
> >>>>>> [e-mail]; [e-mail]; BOURNELLE Julien 
> >>>>>> RD-CORE-ISS; [e-mail]; 
> >>>>>> [e-mail]; [e-mail]; 
> >>>>>> [e-mail]; [e-mail] 
> Objet : Re: 
> >>>>>> [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated
> >>>>>>
> >>>>>> What he said.
> >>>>>>
> >>>>>> jari
> >>>>>>
> >>>>>> [e-mail] 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/aaa-doctors
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> AAA-DOCTORS mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/aaa-doctors
> >>>
> >>
> 
> _______________________________________________
> AAA-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aaa-doctors
> 
_______________________________________________
AAA-DOCTORS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/aaa-doctors