Subject: Re: [Mipshop] Changes in draft-ietf-mipshop-fh80216e-03

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 15 Sep 2007 11:02:20 -0700 (PDT)

Hi Jim,
  Nice to see you back in IETF 
If you take a look at our draft:
http://tools.ietf.org/wg/mipshop/draft-xia-mipshop-fmip-ptp-01.txt
it is explained there.
  Regarding prefix management, we should separate it from prefix delegation (DHCP PD, AAA PD, etc. on how NAR gets prefixes). PD could be out of scope but prefix management has to be in scope. Any protocol that assigns addresses like PMIP and FMIP has to address prefix management issues including transferring prefixes between PAR and NAR.
  It seems that despite his somewhat negative language, Rajeev agrees with this and I am sure we are going to reach consensus and move towards a good solution, I am optimistic.
  Regards,

Behcet

----- Original Message ----
From: James Kempf <[email-masked]>
To: Rajeev Koodli <[email-masked]>; Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Friday, September 14, 2007 5:05:52 PM
Subject: Re: [Mipshop] Changes in draft-ietf-mipshop-fh80216e-03

Behcet,

Is that your understanding as well? Or is there more involved in your 
opinion?

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Behcet Sarikaya" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 14, 2007 1:38 PM
Subject: Re: [Mipshop] Changes in draft-ietf-mipshop-fh80216e-03

On 9/14/07 1:29 PM, "ext James Kempf" <[email-masked]> wrote:

> So I'm just wondering if it would be possible to write a document "FMIP 
> for
> PtP Links" and have that be a WG draft for cases where this is important?
> Are there issues with the base protocol or can this be handled by an
> extension?
>

The base protocol can handle per-MN prefixes (see the section on it). The
base protocol does not specify how an access network manages prefix
assignment (/64, /48 etc.).

-Rajeev

>             jak
>
>
> ----- Original Message -----
> From: "Rajeev Koodli" <[email-masked]>
> To: "Behcet Sarikaya" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, September 14, 2007 11:57 AM
> Subject: Re: [Mipshop] Changes in draft-ietf-mipshop-fh80216e-03
>
>
>
> Behcet,
>
> You didn't say why the text in 4068bis won't work for p2p links.
>
> It is your characterization that FMIP is meant for shared links. It is not
> exactly accurate.
>
> -Rajeev
>
>
>
> On 9/14/07 11:23 AM, "ext Behcet Sarikaya" <[email-masked]> 
> wrote:
>
>
>
> Rajeev,
>   I respectfully disagree. Let's agree to disagree.
> My suggestion is to keep 4068 as FMIP for shared link operation and to
> develop a new protocol for PtP operation.
>   Let's take the example of PMIP6, PMIP6 design from the beginning was 
> made
> for PtP links (BTW without any consideration of prefix management). Shared
> links will be considered in a later time.
>   Such an approach is well worth doing because the applications we are
> envisioning require PtP link operation.
>   Do you think that FMIP has less dependence on the type of link than 
> PMIP?
>
>
> Regards,
>
> Behcet
> ----- Original Message ----
> From: Rajeev Koodli <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Sent: Thursday, September 13, 2007 11:42:43 AM
> Subject: Re: [Mipshop] Changes in draft-ietf-mipshop-fh80216e-03
>
> Re: [Mipshop] Changes in draft-ietf-mipshop-fh80216e-03
> Behcet,
>
>
> On 9/13/07 8:28 AM, "ext Behcet Sarikaya" <[email-masked]> 
> wrote:
>
>
>
> Your statement that 4068 would work on PtP links is wrong, we have shown 
> in
> many occasions (two Mipshop presentations, email exchanges, etc.) that 
> 4068
> has a fundamental assumption of the shared links.
>
> Rajeev:> You may have made presentations, but the above statements are
> incorrect. The baseline FMIP can work without assuming shared or p2p 
> links,
> and this is documented in the latest version of 4068bis.
>
> How you do prefix management is another issue.
>
> -Rajeev
>
>
>

-- 

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

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

---

From: Rajeev Koodli <[email-masked]>
Date: Sat, 15 Sep 2007 17:10:02 -0700

Behcet,

On 9/15/07 11:02 AM, "ext Behcet Sarikaya" <[email-masked]> wrote:

>   Regarding prefix management, we should separate it from prefix delegation
> (DHCP PD, AAA PD, etc. on how NAR gets prefixes). PD could be out of scope but
> prefix management has to be in scope. Any protocol that assigns addresses like
> PMIP and FMIP has to address prefix management issues including transferring
> prefixes between PAR and NAR.
> 
> Rajeev:> doesn¹t your ID show how FMIP already handles this as a baseline?
> 
> 
>   It seems that despite his somewhat negative language, Rajeev agrees with
> this and I am 
> 
> Rajeev:>  ³not agreeing to what you say² != ³negative language² :-)
>  
> sure we are going to reach consensus and move towards a good solution, I am
> optimistic.
>   
> Rajeev:> I too want to move forward, we are re-hashing for a while now..
> 
> -Rajeev
> 
> 
> Regards,
> 
> Behcet
> 

-- 
http://people.nokia.net/~rajeev

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Sep 2007 13:05:41 -0700

>  Nice to see you back in IETF

Well thanx but it is only temporary. I am interested in seeing FMIP finally 
go to standards track RFC, since I've been working on it for 6 years.

> http://tools.ietf.org/wg/mipshop/draft-xia-mipshop-fmip-ptp-01.txt

I skimmed part of the draft. It seems a mixture of a problem statement 
combined with some suggested solutions. The problem statement convinced me 
there is work to be done, though I think it might have been stated more 
clearly. The first solution had a suggestion to set some flags in the 
PrRtAdv which don't exist, namely the 'A' and 'L' flag. These flags are in 
the FBU. At that point, I stopped reading.

> (DHCP PD, AAA PD, etc. on how NAR gets prefixes). PD could be out
> of scope but prefix management has to be in scope. Any protocol that 
> assigns addresses like PMIP and FMIP has to address prefix management
 > issues including transferring prefixes between PAR and NAR.
> this and I am sure we are going to reach consensus and move towards a
> good solution, I am optimistic.

Mmmm, I'm not sure whether Rajeev agrees or not. I think he agrees there is 
a problem, I'm not sure he believes its the same problem as you.

In any event, it seems like there are at least four people (you and your 
co-author, Rajeev, and myself) who agree that there is a problem. Can we 
decouple that from advancing the FMIP draft? Even if the solution requires 
additional flags or adding other fields to existing FMIP signaling, these 
could be part of an enhancement that would be relevent only to PtP systems. 
It seems to me that getting the IETF mobility management solutions to 
support these types of systems is currently ongoing (e.g. PMIP) so it might 
make more sense to co-ordinate any solution for FMIP with those efforts. If 
these solutions are done in isolation, there's a risk that interoperability 
might suffer. Meanwhile, the base FMIP protocol seems to work fine for 
standard shared link style systems, it's been implemented a number of times, 
so why not send it to RFC?

Vijay, Stefano, do you think it might make sense to start a WG draft on this 
problem? Possibly a more clearly written problem statement to start?

                    jak

---

From: Frank Xia <[email-masked]>
Date: Mon, 17 Sep 2007 16:09:33 -0500

Hi Jemse

Please see my inline comments

BR
Frank
----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Behcet Sarikaya" <[email-masked]>; "Rajeev Koodli" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 17, 2007 3:05 PM
Subject: Re: [Mipshop] Changes in draft-ietf-mipshop-fh80216e-03

> go to standards track RFC, since I've been working on it for 6 years.

Frank=>I also think current FMIP document is ready to move forward. 
We can do enhancement based on the spec and p2p special requirements.
 
> the FBU. At that point, I stopped reading.
Frank=>The problem and solution were presented in IETF68 and IETF69 meeting.
Presentations are available in http://www3.ietf.org/proceedings/07mar/slides/mipshop-3/sld1.htm 
and http://www3.ietf.org/proceedings/07jul/slides/mipshop-2/sld1.htm.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 12:03:14 -0700

Hello,

I don't think we need to make any further changes to 4068bis or 
draft-ietf-mipshop-fh80216e-03.txt to handle prefix assignment for 
point-to-point links. Both of them already require assigning a unique 
prefix for each mobile node. So in that sense they already work for both 
shared links and p2p links.

What we need now is a mechanism to get the unique prefix for the MN from 
the NAR to the PAR. draft-xia-mipshop-fmip-ptp-01.txt describes this 
problem and provides three different solutions. The working group needs 
to take a decision if it wants to adopt this draft. I haven't seen this 
so far.

Even if we decide to take this draft on, we may have to wait for a 
couple of months since we need to finish up with some of the documents 
in the charter currently.

Vijay

James Kempf wrote:
> Well thanx but it is only temporary. I am interested in seeing FMIP 
> finally go to standards track RFC, since I've been working on it for 6 
> years.
> 
> combined with some suggested solutions. The problem statement convinced 
> me there is work to be done, though I think it might have been stated 
> more clearly. The first solution had a suggestion to set some flags in 
> the PrRtAdv which don't exist, namely the 'A' and 'L' flag. These flags 
> are in the FBU. At that point, I stopped reading.
> 
>>  Regarding prefix management, we should separate it from prefix 
>> delegation (DHCP PD, AAA PD, etc. on how NAR gets prefixes). PD could 
>> be out
>>  It seems that despite his somewhat negative language, Rajeev agrees 
>> with this and I am sure we are going to reach consensus and move 
>> towards a
> Mmmm, I'm not sure whether Rajeev agrees or not. I think he agrees there 
> is a problem, I'm not sure he believes its the same problem as you.
> 
> decouple that from advancing the FMIP draft? Even if the solution 
> requires additional flags or adding other fields to existing FMIP 
> signaling, these could be part of an enhancement that would be relevent 
> only to PtP systems. It seems to me that getting the IETF mobility 
> management solutions to support these types of systems is currently 
> ongoing (e.g. PMIP) so it might make more sense to co-ordinate any 
> solution for FMIP with those efforts. If these solutions are done in 
> isolation, there's a risk that interoperability might suffer. Meanwhile, 
> the base FMIP protocol seems to work fine for standard shared link style 
> systems, it's been implemented a number of times, so why not send it to 
> RFC?
> 
> Vijay, Stefano, do you think it might make sense to start a WG draft on 
> this problem? Possibly a more clearly written problem statement to start?
> 
>                    jak
> 
> 
>