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

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<rajeev.koodli@nokia.com>
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 