Subject: Re: [Dime] MIP6 NAS-HAAA issue #1

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Apr 2007 14:52:21 +0200

Hi Jouni,

a grouped AVP is also OK for me.

Ciao
Hannes

[email-masked] wrote:
> About the issue #1 presented during the Dime WG meeting. If
> the ASP/NAS needs to send or the MSA needs to return more than
> one HA information the current AVP formulation does not work.
> This is because we have defined AVP counts as "at most one".
> Furthermore, if we are about to allow "zero or more" AVPs we
> need to have a way to group HA address, FQDN, home link prefix
> etc together. For that purpose a grouped AVP would be OK.
>
> So the question is (also related to the issue #2) whether 
> "zero or more" HAs must be supported. At least the recent
> discussion in MIP6 list points to this direction.
>
> Anyway, my personal opinion is that defining a grouped AVP
> does-no-harm anyway. Below is one proposal for a grouped AVP:
>
>   MIP6-Info ::= < AVP Header: 297 >
>                 [ MIP6-Home-Agent-Address ]
>                 [ MIP6-Home-Agent-FQDN ]
>                 [ MIP6-Home-Link-Prefix ]
>                 [ MIP6-Home-Address ]
>                 ...
>
> Any opinions?
>
> Cheers,
> 	Jouni
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>   

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 27 Apr 2007 11:50:36 -0700

Hi Jouni,

I have no problem with the general idea of grouped AVP, only a few notes
regarding the construct:

1) calling the AVP MIP6-Info may be a bit problematic, basically you are
putting the entire MIP6 application info into one grouped AVP? Will we then
be able to define this group AVP in a way that any possible AVP people come
up with to support MIP6 can easily be integrated in this AVP? If yes, then
no problem. 

Right now, I can have an idea about a couple of things that can be MIP6-info
related AVPs and are not shown below. Just call it MIP6_HA_info (leave HOA
out of it, IMO) or call it MIP6_ADDR_info and leave HOA in.

2) Not debating whether or not we should send multiple HA info together, The
suggested construct does not show how many HAs there are in the AVP. I would
guess you would need something to indicate that.

Hope this helps,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: Thursday, March 22, 2007 5:38 AM
To: [email-masked]
Subject: [Dime] MIP6 NAS-HAAA issue #1

Any opinions?

Cheers,
	Jouni

---

From: <[email-masked]>
Date: Fri, 27 Apr 2007 22:41:43 +0200

Hi Madjid, 

> From: Madjid Nakhjiri [mailto:[email-masked]] 
> Sent: 27. huhtikuuta 2007 21:51
> To: Korhonen, Jouni /TeliaSonera Finland Oyj; [email-masked]
> Subject: RE: [Dime] MIP6 NAS-HAAA issue #1
> 
> Hi Jouni,
> 
> I have no problem with the general idea of grouped AVP, only 
> a few notes regarding the construct:

Good.

> 1) calling the AVP MIP6-Info may be a bit problematic, 
> basically you are putting the entire MIP6 application info 
> into one grouped AVP? Will we then be able to define this 
> group AVP in a way that any possible AVP people come up with 
> to support MIP6 can easily be integrated in this AVP? If yes, 
> then no problem. 

Right.. if extending the MIP6-Info is desired we could define
it as:

   MIP6-Info ::= < AVP Header: xyz >
                 [ MIP6-Home-Agent-Address ]
                 [ MIP6-Home-Agent-FQDN ]
                 [ MIP6-Home-Link-Prefix ]
                 [ MIP6-Home-Address ]
                *[ AVP ]

> Right now, I can have an idea about a couple of things that 
> can be MIP6-info related AVPs and are not shown below. Just 
> call it MIP6_HA_info (leave HOA out of it, IMO) or call it 
> MIP6_ADDR_info and leave HOA in.

There is definitely a lot of stuff that could be put in.. e.g.
in a case when the NAS is co-located with MAG. I am open to
extend the coverage but I am not sure if it is in scope of the
ID.

> 2) Not debating whether or not we should send multiple HA 
> info together, The suggested construct does not show how many 
> HAs there are in the AVP. I would guess you would need 
> something to indicate that.

It is always at most one HA per grouped AVP. If more HAs
are needed, the message just needs to include multiple
grouped MIP6-Info AVPs.

Cheers,
	Jouni

> the ASP/NAS needs to send or the MSA needs to return more 
> than one HA information the current AVP formulation does not work.
> need to have a way to group HA address, FQDN, home link 
> prefix etc together. For that purpose a grouped AVP would be OK.
>

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 30 Apr 2007 12:51:58 -0700

Hi Jouni,

It is ok to extend the grouped AVP with *[AVP], I guess, but my point was
since we will have a Diameter Mobile IPv6 application (at least for split
case), it is easier to call the attribute what it is: MIP6_Addresses without
expanding its scope rather than including everything that is related to that
application into one AVP. I may need to send Mobile IP6 attributes in an
uplink message TO the server, then what? 

 As you said your ID scope is confined and you don't want to and should not
deal with all future Mobile IP6 related attributes that may be defined
later.

As far as multiple HA and multiple grouped AVPs, I guess that is fine. Is
there a need to indicate how many HA s are included in the message and
whether there is a preference on which one to pick?

R,

Madjid

-----Original Message-----

Sent: Friday, April 27, 2007 1:42 PM
To: [email-masked]; [email-masked]
Subject: RE: [Dime] MIP6 NAS-HAAA issue #1

Hi Madjid, 

Good.

Cheers,
	Jouni