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

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 14 Sep 2007 11:23:06 -0700 (PDT)

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

-- 

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

Behcet

----- Original Message ----

From: Heejin Jang <[email-masked]>

To: [email-masked]

Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]

Sent: Thursday, September 13, 2007 4:09:48 AM

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

Hi, folks.     

As announced last week, new version of draft-ietf-mipshop-fh80216e was submitted    

(draft-ietf-mipshop-fh80216e-03). 

So far it has been updated twice (-02 and -03) to reflect the review results from 16ng WG, 

and, FYI, I summarized main changes as follows.    

'(*)' is the parts which were updated in recent version (-03).    

----------------------------------------------------------------------------------------------------------------    

* Reviewrs

- Yoshihiro Ohba (IEEE 802.21 liaison)

- Jinhyeock Choi (WiMAX & 16ng expert)

- Jonne Soininen (NETLMM WG chair)

1. Deletion of Section 3 (Deployment Architecture)

- Some statements in Sec 3 may be incorrect for point-to-point link

and the draft is fine without this section, so the section was removed.

2. Use the latest IEEE 802.21 message

- Use a Link_Detected primitive instead of a New_BS_Found

- Use a Handover_commit primitive instead of a Link_Switch

- Use a Handover_imminent primitive instead of a Link_Going_Down (*) 

3. Reqire scanning before a Link_Detected trigger

-  Inclusion of a particular BSID in MOB_NBR-ADV does not mean that the target BS

is within MN's radio coverage, so it is modified that  BS's reachability is checked through 

scanning, before the trigger of a Link_Detected. 

4. Description for the goal of the draft was added in Section 1 (Introduction) for the sake 

of clarity. (*)

5. The paragraph specific to WiMAX was removed (*)

- There were several comments that WiMAX is an architecture specified for 802.16e with

its specific architecture and it should not be regarded as a general case in the context, 

so we decided to remove it. 

6. Section for prefix management has been added. (*)

- This is consideration in case that 802.16 may work on point-to-point link model.

7. In Section 6, numbers were added in the pictures of the scenario examples for 

mapping with the description. 

8. Some technically minor/editorial changes. (*)

- Best regards, 

Heejin Jang.

_______________________________________________

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: Fri, 14 Sep 2007 11:57:49 -0700

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:

>   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.
>>   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.
>>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Sep 2007 13:29:39 -0700

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?

            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.

-Rajeev

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

-Rajeev

-- 

--------------------------------------------------------------------------------

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 14 Sep 2007 13:38:28 -0700

> Are there issues with the base protocol or can this be handled by an

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Sep 2007 15:05:52 -0700

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

-Rajeev

--