Subject: Re: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e Networks

From: Heejin Jang <[email-masked]>
Date: Fri, 08 Jun 2007 02:44:03 +0000 (GMT)

Hi, Frank

I agree with Rajeev.    
     
RFC4068 is not limited only to the shared link model because the p2p prefix allocation     
(per-MN prefix model) can be applied without any modification of RFC4068 in the point-to-point link.     
It can be done NCoA allocation via BAck & NAACK as you and Rajeev suggested, or     
PAR's Administrator may decide to manage a part of  IPv6 prefix pool of NAR for allocation if feasible.    
(I think that's not a waste of prefixes where the prefix is assigned "per MN" in the (IPv6) point-to-point link.:) )    
     
Some mention may need to be reflected in 4068-bis, for e.g., 1) RtSolPr & PrRtAdv exchanges,
2) Proxying NCoA with proxy neighbor cache entry in NARand 3) DAD check, some or all of these procedures
may be omitted in the point-to-point link.    

But I don't think it's a new model but a way of how the existing fmipv6 can be applied over the point-to-point link.         
     
- Regards, 
Heejin. 

------- Original Message -------
Sender : Rajeev Koodli<[email-masked]>
Date   : 2007-06-05 06:08
Title  : Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e Networks

Hi Frank,

May be we are going in circles here.. I have not seen why the current model cannot work for the scenario you have in mind. If there is an issue, the WG process is to bring it up and propose text. It&#8217;s more productive that way. I am willing to clarify in the bis version. Some more replies below..

1 "(AP-ID, AR-Info) tuple Contains an access router's L2 and IP  addresses, and
  prefix valid on the interface to which the  Access Point (identified by AP-ID) is attached.  
 The triplet  [Router's  L2 address, Router's IP address and Prefix] is called  "AR-Info"".
 
=> Here, prefix is AR's physical interface  prefix is used for NCoA formulation.
  As you know, this prefix  is useless for P-to-P link model.

Rajeev:> you could interpret it  that way, but you don&#8217;t have to. The point I am trying to make is that the  current model works for the scenario you are enumerating.
 
Frank=> don't you think the concept of the  perfix is too flexible that different people can have their own different  understanding?  In your draft, the prefix is definitely the prefix of  AR physical interface. I think there is not ambiguous.

Rajeev/2/:> First, it is not my draft; it is the WG document. Second, it is not clear to me why you would equate the prefix to physical interface. 4068 only says it is the prefix valid on the interface the MN is attaching to, and I am unable to see what&#8217;s the problem.

If you are trying to map it to ptp model, that&#8217;s fine. But, please don&#8217;t make assumptions which not intended, nor are necessary.

An AR may use per-mobile prefix and an aggregate prefix on the  interface. As I said, aggregate prefix could be what is advertised in  PrRtAdv. The MN can formulate a prospective NCoA using that, but receive a  different NCoA from NAR, based on the per-mobile prefix. 
 
Frank =>In fact,  this is not big different from our propsoal  in draft-xia-mipshop-fmip-ptp-00 

Rajeev:/2/> I am not proposing a new model above. Just showing how the existing model can be used.

I can imagine other ways to manage  the prefix. 
 
Frank => I  also have a revised document  which elaborating other alternatives, and we can cooperate  .

Rajeev:> If your question is will it work with per-mobile  prefix, yes. Either FBack or NAACK can provide the NCoA that the NAR wants  the MN to use. 
   
Frank => The exchange of RtSolPr and PrRtAdv is to formulate a new CoA while is useless  in p-t-p model.  It is a waste of air interface  resource.

Rajeev:/2/> That&#8217;s debatable, and is up to each technology that implements FMIP. 

Frank => P-to-P scenario is adopted by  WiMAX/3GPP2, while I have little idea about promising  deployment of shared link model.

Rajeev:/2/> Good.  RFC 4068 is not about shared link only. It&#8217;s your interpretation. 
 
IMHO, your simplified proposal can't solve the  proplem very well.
 
               Rajeev:/2/> You have not shown why my explanation on how the current model can work will not  work. As I suggested earlier, if there is any specific issue that needs to be addressed, it is productive to propose the issue and text. 

-Rajeev

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

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 8 Jun 2007 08:15:10 -0700 (PDT)

Hi Heejin,
  Have you seen this draft:
http://tools.ietf.org/wg/mipshop/draft-xia-mipshop-fmip-ptp-00.txt which was presented in Prague?

4068bis needs a lot of changes in order to support per-mobile prefix model. We've been in contact with Rajeev on this. It has been interrupted because I think Rajeev is traveling.

A solution is expected to emerge soon.

Regards,

Behcet
----- Original Message ----
From: Heejin Jang <[email-masked]>
To: Rajeev Koodli <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Thursday, June 7, 2007 9:44:03 PM
Subject: Re: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e Networks

Hi, Frank

I agree with Rajeev.    

- Regards, 

Heejin. 

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

Date   : 2007-06-05 06:08

Hi Frank,

 

 

-Rajeev

-- 

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: 장희진 <[email-masked]>
Date: Mon, 11 Jun 2007 02:01:35 +0000 (GMT)

Hi Behcet.

I've read that draft. But it does not describe any problem except
prefix assignment in fmip/point-to-point link which can be solved in a way as
Rajeev suggested.

As Rajeev said in the following email, I think that you need
to clarify why the current model cannot work with the point-to-point model,
and which issues in rfc4068 need to be resolved.

In my understanding, the following issues are those things,
but I'm not sure it deserves to be a new document.

Some or all of these procedures may be omitted in the point-to-point
link.

1) RtSolPr & PrRtAdv exchanges

2) Proxying NCoA with proxy neighbor cache entry in NAR

3) DAD check

-Regards,

Heejin.

------- Original Message -------
Sender : Behcet Sarikaya<[email-masked]>
Date : 2007-06-09 00:15
Title : Re: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over
IEEE802.16e Networks

Hi Heejin,

Regards,

Behcet

----- Original Message ----
From: Heejin Jang <[email-masked]>
To: Rajeev Koodli
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Thursday, June 7, 2007 9:44:03 PM
Subject: Re: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e Networks

Hi, Frank

I agree with Rajeev.

(I think that's not a waste of prefixes where the prefix is assigned "per MN" in the (IPv6)
point-to-point link.:) )

- Regards,

Heejin.

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

Date   : 2007-06-05 06:08

Hi Frank,

May be we are going in circles here.. I have not seen why
the current model cannot work for the scenario you have in mind. If there is an issue, the WG process is to bring it up and propose text. It&#8217;s more productive that way. I am willing to clarify in the bis version. Some more replies below..

Rajeev:> you could interpret it  that way, but you don&#8217;t have to. The point I am trying to make is that
the  current model works for the scenario you are enumerating.

An AR may use per-mobile prefix and an aggregate prefix on the  interface. As I said, aggregate prefix could be
what is advertised in  PrRtAdv. The MN can formulate a prospective NCoA using that, but receive a  different NCoA from NAR, based on the per-mobile prefix.

Frank => The exchange of RtSolPr and PrRtAdv is to formulate a new CoA while is useless  in p-t-p
model.  It is a waste of air interface  resource.

-Rajeev

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 Jun 2007 08:44:20 -0700 (PDT)

Hi Heejin,
  First of all, ptp link behaviour is different and needs to be specified. The situation is similar to PMIP6 where MN gets assigned an address from the home network prefix and PMIP6 is currently supporting only per-MN prefix model. 
  So it is not an implementation issue.
  My additional comments inline.

Regards,

Behcet
----- Original Message ----
From: 장희진 <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Sunday, June 10, 2007 9:01:35 PM
Subject: Re: Re: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e Networks

Hi Behcet.

Rajeev suggested.

[behcet] It is true that in the draft (we now have a new version) we concentrated on different techniques with which an NCoA can be assigned to MN in per-MN prefix model.
It is also true that depending on the technique selected, there needs to be additional changes made in 4068bis. 
At this point we would like to know the procedure, the document editor can do these changes, we can do it as well.

link.    

3) DAD check

[behcet] yes, these are the places in 4068bis that needs some revision.

-Regards, 

Heejin.

 

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

 IEEE802.16e Networks

Hi Heejin,

Regards,

Behcet
----- Original Message ----
From: Heejin Jang <[email-masked]>
To: Rajeev Koodli

Hi, Frank

I agree with Rajeev.    

 point-to-point link.:) )    

- Regards, 

Heejin. 

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

Date   : 2007-06-05 06:08

Hi Frank,

 

 

-Rajeev

--