Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 1 Aug 2006 16:01:17 -0700

I assume that dynamic GFA scheme is completely optional.  As long as GFA is known in the Visited Domain (by some mechanism), it can be advertised by the FA in the CoA field.

Kent 

> -----Original Message-----
> From: Tsirtsis, George [mailto:[email-masked]] 
> Sent: Tuesday, August 01, 2006 7:17 AM
> To: Eva Fogelström; Jari Arkko
> Cc: [email-masked]
> Subject: RE: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt
> 
> 
> 
> ________________________________________
> From: Eva Fogelström [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 7:39 AM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt
> 
> Hi Jari,
> 
> Comments inline.
> 
> Jari Arkko wrote: 
> Eva and others,
> 
> I have performed my AD review on this draft. Overall, its 
> ready for publication as Experimental. However, there are two 
> technical issues and a few other nits that I would like to 
> discuss before submission to the IESG.
> 
>   
>    A domain that supports regional registrations SHOULD also be
>    backwards compatible.
> 
>    If a FA only advertises an all-ones care-of address (i.e. 
> for dynamic
>    GFA assignment), it will not be backwards compatible with 
> [RFC3344],
>    since the MNs and HAs will also be required to support the regional
>    registration extensions defined in this document.
>     
> 
> This seems to suggest a model where those who employ this 
> mechanism may end up preventing regular Mobile IP clients 
> from getting service. I do not see why we would have to make 
> this so. I wonder if it would be better to require both a 
> regular address and gateway address (possibly all-ones) to be 
> advertised? You could still require that mobile nodes 
> compliant to reg-tunnel use dynamic assignment.
>   
> Yes. I believe the original intention was to support FAs with 
> private addresses in regional registrations. However, unless 
> someone has a real need for this feature, we can skip it and 
> instead make it so that regular MIP4 clients can always get 
> service, according to your suggestion. Comments? 
> 
> GT> Is this really about private addresses? Or is it about 
> dynamic GFA assignment? I think dynamic GFA assignment is 
> purely defined in this document so cleaning it out might be a 
> good idea. We can define dynamic GFAs in a separate draft if 
> there is still interest.
> 
> George  
> 
> --
> Mip4 mailing list: [email-masked]
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 1 Aug 2006 19:02:02 -0700

It is not clear that dynamic GFAs is entirely optional, at least from the mobile's perspective. For static GFA the MN must somehow know the GFA address (presumably from the FAA) before it can send the registration request message. If the FAA includes an all 1s GFA address then, I suppose the mobile must use the dynamic GFA procedure....does it have a choice?

BTW, In my earlier e-mail I misspoke. I DID NOT mean to say that the dynamic GFA model should be removed from the draft. The draft implies that a multiple level hierarchy (multiple hierarchical GFAs) can be supported but it does not provide any details. It is this part that I think should be removed from this version of the spec. 

George

> From: Kent Leung (kleung) [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 7:01 PM
> To: Tsirtsis, George; Eva Fogelström; Jari Arkko
> Cc: [email-masked]
> I assume that dynamic GFA scheme is completely optional.  As long as GFA
> is known in the Visited Domain (by some mechanism), it can be advertised
> by the FA in the CoA field.
> 
> Kent
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Aug 2006 07:36:39 +0300

>It is not clear that dynamic GFAs is entirely optional, at least from the mobile's perspective. For static GFA the MN must somehow know the GFA address (presumably from the FAA) before it can send t…
I think that was part of what I objected to -- if the FAs are allowed to
announce
only an all 1s GFA address then it seems that it does not have a choice.
But I
fail to see why this is necessary.

--Jari

---

From: Eva Fogelström <[email-masked]>
Date: Wed, 02 Aug 2006 08:55:47 +0200

Ok. Let me clarify this. Jari's objection was that if an FA is allowed 
to announce an all-ones GFA address only, the MN has no choice but to go 
along with that, i.e. the MN cannot make a regular MIP4 home 
registration. True.

I believe this was discussed on the list a couple of years ago (2002), 
when the draft was in WG last call. The idea was that an all-ones 
address indicates dynamic GFA in the case of home registration, and 
allows for privately addressed FAs in the case of regional registrations 
(in which case the FA address itself is not advertised).

As I said, I don't mind taking out this type of support for private FA 
addresses, letting the FA advertise its c/o address to support regular 
MIP4 home registrations, according to Jari's suggestion. So, unless 
someone objects, I suggest I do exactly that.

Eva

---

From: Eva Fogelström <[email-masked]>
Date: Wed, 02 Aug 2006 09:00:59 +0200

Hi George,

Comments inline.

>It is not clear that dynamic GFAs is entirely optional, at least from the mobile's perspective. For static GFA the MN must somehow know the GFA address (presumably from the FAA) before it can send t…
See my previous email.

>BTW, In my earlier e-mail I misspoke. I DID NOT mean to say that the dynamic GFA model should be removed from the draft. The draft implies that a multiple level hierarchy (multiple hierarchical GFAs…
The multiple levels of hierarchy was already removed in an earlier 
version of the draft. I'll clarify the text.

Eva

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 2 Aug 2006 05:01:09 -0700

Eva,

Sounds good but if you remove the all 1s address, then the FA will not be able to instruct the mobile that dynamic GFA  can or should be used. Is this true or are you going to try to do this some other way?

Since you are making some changes I also have one more suggestion. According to the draft, the mobile first registers with the HA using regular registrations (+some extensions) and then uses regional registrations to the GFA if it handoffs within the area covered by the local GFA. The draft does not currently require the mobile to register with the GFA until it hands off. This creates the following issues which is a bit strange. Once the mobile hands-off and uses regional registration, the GFA can define a Lifetime that is equal to or smaller than the Lifetime defined by the HA. This makes sense but the strange thing is that the GFA can not impose its desired lifetime for regional registrations until the mobile hands-off in its region.

I think this can be trivially fixed by requiring that the mobile uses regional registration immediately after normal registration when a GFA is present, and even if the mobile does not hand-off. 

Thoughts?

George

________________________________

From: Eva Fogelström [mailto:[email-masked]] 
Sent: Wednesday, August 02, 2006 2:56 AM
To: Jari Arkko; Tsirtsis, George
Cc: Kent Leung (kleung); [email-masked]
Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

Ok. Let me clarify this. Jari's objection was that if an FA is allowed to announce an all-ones GFA address only, the MN has no choice but to go along with that, i.e. the MN cannot make a regular MIP4 home registration. True.

I believe this was discussed on the list a couple of years ago (2002), when the draft was in WG last call. The idea was that an all-ones address indicates dynamic GFA in the case of home registration, and allows for privately addressed FAs in the case of regional registrations (in which case the FA address itself is not advertised).

As I said, I don't mind taking out this type of support for private FA addresses, letting the FA advertise its c/o address to support regular MIP4 home registrations, according to Jari's suggestion. So, unless someone objects, I suggest I do exactly that.

Eva

Jari Arkko wrote:

Tsirtsis, George wrote:

	    

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Aug 2006 15:09:21 +0300

Tsirtsis, George wrote:

> Eva,
>
>  
>
> Sounds good but if you remove the all 1s address, then the FA will not
> be able to instruct the mobile that dynamic GFA  can or should be
> used. Is this true or are you going to try to do this some other way?
>
I don't think that was the proposal. The proposal was to prohibit the
all 1s address to be the ONLY
address you provide. You can still provide the all 1s address, as long
as there is another address
that MNs without support for this spec can use.

--Jari

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 2 Aug 2006 05:19:32 -0700

Ok I see. Thanks.
George 

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Wednesday, August 02, 2006 8:09 AM
> To: Tsirtsis, George
> Cc: Eva Fogelström; [email-masked]; Kent Leung (kleung)

---

From: Eva Fogelström <[email-masked]>
Date: Wed, 02 Aug 2006 16:59:14 +0200

Hi George,

Comments inline.

> used. Is this true or are you going to try to do this some other way?
Jari already replied to this.

>  
>
> Since you are making some changes I also have one more suggestion. 
> According to the draft, the mobile first registers with the HA using 
> regular registrations (+some extensions) and then uses regional 
> registrations to the GFA if it handoffs within the area covered by the 
> local GFA. The draft does not currently require the mobile to register 
> with the GFA until it hands off. This creates the following issues 
> which is a bit strange. Once the mobile hands-off and uses regional 
> registration, the GFA can define a Lifetime that is equal to or 
> smaller than the Lifetime defined by the HA. This makes sense but the 
> strange thing is that the GFA can not impose its desired lifetime for 
> regional registrations until the mobile hands-off in its region.
>
>  
>
> I think this can be trivially fixed by requiring that the mobile uses 
> regional registration immediately after normal registration when a GFA 
> is present, and even if the mobile does not hand-off.
>
>  
>
> Thoughts?
>
> George
>

I'm not sure I follow. When the MN does a home registration with its HA, 
the GFA acts as foreign agent towards the HA. The registration request 
goes as follows: MN-FA-GFA-HA. Ok?

The GFA is a foreign agent, as defined in RFC3344, with some additions. 
In my understanding, this means that if the GFA does not approve of the 
lifetime in the registration request when it receives it, it can simply 
deny the home registration with error code 69 (requested lifetime too long).

Moreover, the FA advertises the lifetime it is willing to allow for a 
registration. And the FA can also deny a registration.

In case of co-located care-of address, the FA is bypassed in the home 
registration. However, the registration request still goes through the 
GFA, so the GFA can deny it.

What's the problem?

Eva

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 2 Aug 2006 08:07:30 -0700

In line...

From: Eva Fogelström [mailto:[email-masked]] 
Sent: Wednesday, August 02, 2006 10:59 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent Leung (kleung); [email-masked]
Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

Hi George,
...

Thoughts?

George

I'm not sure I follow. When the MN does a home registration with its HA, the GFA acts as foreign agent towards the HA. The registration request goes as follows: MN-FA-GFA-HA. Ok?

GT> Yes

The GFA is a foreign agent, as defined in RFC3344, with some additions. In my understanding, this means that if the GFA does not approve of the lifetime in the registration request when it receives it, it can simply deny the home registration with error code 69 (requested lifetime too long).

GT> Yes, but what you describe would result in the lower Lifetime be forced to the Home Agent too, which is not ideal. What I am looking for here is separation of the refresh requirements imposed by the Home and the Foreign domains. The GFA should be able to require a Lifetime that is different (i.e., lower) than the lifetime required by the HA, without affecting what the HA requires. Note that your draft already allows for that but the mobile has to first perform a handoff. At that point the GFA can return a Lifetime that is independent from the lifetime returned by the HA. Is this clearer?

George

---

From: Eva Fogelström <[email-masked]>
Date: Thu, 03 Aug 2006 09:11:10 +0200

Hi George,

I understand what you want to do, but I don't understand the motivation 
for it. In particular, I don't understand why being able to define a 
separate lifetime at the GFA (compared to the HA) would motivate a 
mandatory double registration (home + regional registration) each time 
the MN registers with its HA.

Eva

Tsirtsis, George wrote:

> In line...
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Eva Fogelström [mailto:[email-masked]]
> *Sent:* Wednesday, August 02, 2006 10:59 AM
> *To:* Tsirtsis, George
> *Cc:* Jari Arkko; Kent Leung (kleung); [email-masked]
> *Subject:* Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt
>
>  
>
> Hi George,
> ...
>
> I'm not sure I follow. When the MN does a home registration with its 
> HA, the GFA acts as foreign agent towards the HA. The registration 
> request goes as follows: MN-FA-GFA-HA. Ok?
>
> GT> Yes
>
>
> The GFA is a foreign agent, as defined in RFC3344, with some 
> additions. In my understanding, this means that if the GFA does not 
> approve of the lifetime in the registration request when it receives 
> it, it can simply deny the home registration with error code 69 
> (requested lifetime too long).
>
> GT> Yes, but what you describe would result in the lower Lifetime be 
> forced to the Home Agent too, which is not ideal. What I am looking 
> for here is separation of the refresh requirements imposed by the Home 
> and the Foreign domains. The GFA should be able to require a Lifetime 
> that is different (i.e., lower) than the lifetime required by the HA, 
> without affecting what the HA requires. Note that your draft already 
> allows for that but the mobile has to first perform a handoff. At that 
> point the GFA can return a Lifetime that is independent from the 
> lifetime returned by the HA. Is this clearer?
>
> George
>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 3 Aug 2006 03:36:36 -0700

The reason I think the GFA should be able to have a different lifetime than the HA is because I anticipate regional registration to be deployed in the context of roaming between domains/operators. i.e., a mobile has an HA in its home operator. When it moves to another operator it uses a GFA for local mobility management. The GFA is provided by the local operator and has its own requirements. It is typically in the industry that each domain/operator has control over its own infrastructure and does not depend on configuration in a third operator (unless absolutely necessary). Such refresh lifetimes is one such parameter that they can control.

I will also reiterate that your draft supports this concept already, since the GFA can impose its own lifetime *after* a handoff takes place. All I am saying is that if the GFA needs to impose its own lifetime it should be able to impose it immediately.

As to the solution I suggested, it is just one solution. Another, possibly better solution, would be to define a GFA-Lifetime extension which the GFA can include in the Registration Reply during the initial MN-FA-GFA-HA registration. This does what I am suggesting without requiring a regional registration with the GFA. 

George

From: Eva Fogelström [mailto:[email-masked]] 
Sent: Thursday, August 03, 2006 3:11 AM
To: Tsirtsis, George
Cc: Jari Arkko; Kent Leung (kleung); [email-masked]
Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-reg-tunnel-02.txt

Hi George,

I understand what you want to do, but I don't understand the motivation for it. In particular, I don't understand why being able to define a separate lifetime at the GFA (compared to the HA) would motivate a mandatory double registration (home + regional registration) each time the MN registers with its HA.

Eva

Tsirtsis, George wrote:

In line...

Hi George,
...

Thoughts?

George

GT> Yes

George