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

[장희진 <[e-mail]>]

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<[e-mail]>
Date : 2007-06-09 00:15
Title : Re: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e Networks

Hi Heejin,
  Have you seen this draft:
http://tools.ietf.org/wg/mipshop/draft-xia-mipshop-fmip-ptp-00.txt" rel="nofollow">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 <[e-mail]>
To: Rajeev Koodli <[e-mail]>
Cc: "[e-mail]" <[e-mail]>rg>; "[e-mail]" <[e-mail]>
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.    

    

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<[e-mail]>

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/%7Erajeev" rel="nofollow">http://people.nokia.net/~rajeev

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng" rel="nofollow">https://www1.ietf.org/mailman/listinfo/16ng

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