Subject: Re: [netlmm] draft-ietf-netlmm-mn-ar-if-03.txt

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 4 Mar 2008 10:16:30 -0500

Hi, Mohanna,

I think the whole idea behind the HI is that the MAG might
have some information from L2 that would allow it to fill
in an intelligent value there.  This may or may not require
modifications to the host at L2; however, the host would
still be unmodified at L3.  If a given technology wants
to implement PMIP with some special L2 signaling I think
that should be allowed.

-Pete

Mohana Jeyatharan wrote:
> Hi Pete,
> 
> Thanks for your replies. As you said since shared links are not
> considered due to some shortfalls detail analysis of how to solve
> issues when shared links are used need not be considered in this
> document.   
> 
> I have final one comment. In the attach sub-function MAG_GET_HI
> subfunction, it is described that HI status is given to MAG. My
> question is, can an unmodified host provide such information? It
> definitely needs some protocol changes/software chnages. Or are you
> saying that L2 changes does not fall into the cateogory of unmodified
> host. Because from how I understand unmodified host means no software
> changes.      
> 
> Thanks.
> BR,
> Mohana
> 
> -----Original Message-----
> From: McCann Peter-A001034 [mailto:[email-masked]]
> Sent: Friday, February 29, 2008 11:32 PM
> To: Mohana Jeyatharan
> Cc: [email-masked]
> Subject: RE: [netlmm] draft-ietf-netlmm-mn-ar-if-03.txt
> 
> Hi, Mohana,
> 
> Mohana Jeyatharan wrote:
>> Hi Pete,
>> 
>> I read your draft(considerable amount). I have a smal question in
>> section 4.2. Correct me if I am wrong.
>> I can understand your explanations about issues when two nodes are
>> physically sharing the same link but cannot have a direct
>> communication(different prefix). Then you explain that when neighbour
>> discovery is used, they may be able to directly communicate(I guess
>> via L2 address).
> 
> The point of ND is to find out the link layer address associated with
> a given IP address.  So yes, if the interface is used on a shared
> link the MNs might be able to communicate directly.  
> 
>> But, the point I am a bit confused with is when you say that suppose
>> the two nodes moves away from the same physical link then they cannot
>> communicate. But, what I feel is when they move the neighbour caches
>> may not have each others update and packets will be routed vis
>> default 
> 
>> routers. I guess your case will happen, if you assume that neighbour
>> caches are not updated frequently. This problem may happen
>> even in normal node mobility. This is my small comment
> 
> If the nodes had been communicating directly, they will have each
> other's link layer addresses in the cache.  The failure will occur
> when they move off the same link; the link layer addresses will no
> longer be reachable.  I guess you are saying this is temporary and
> should be taken care of by NUD.    
> 
> In any case, the document clearly states that it is only intended to
> run over a point-to-point link.  I think we should keep this
> restriction and leave the shared link issues to a later document.  
> 
> -Pete
> 
>> BR,
>> Mohana
>> 
>> 
>> McCann Peter-A001034 wrote:
>>> I have just submitted a new version of draft-ietf-netlmm-mn-ar-if,
>>> which you can find here: 
>>> 
>>>
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-03.txt
>>> 
>>> Soon I expect there will be an HTML diff from -02 at this location:
>>> 
>>> 
> http://tools.ietf.org/wg/netlmm/draft-ietf-netlmm-mn-ar-if/draft-ietf-
>>> ne tlmm-mn-ar-if-03-from-02.diff.html
>>> 
>>> Major changes:
>>> 
>>> * Modified description of step REP1 of MAG_GET_MN_ID sub-function
>>>   to state that PBU/PBACK exchange must complete before RA is sent.
>>>   I think this is necessary to get the right HNP into the RA.
>>> 
>>> * Added a MAG_GET_HI sub-function with advice on how to populate
>>>   ATT, MNIID, and HI fields of the PBU.
>>> 
>>> * Added a straw-man Security Considerations section.
>>> 
>>> Comments and suggestions welcome.
>>> 
>>> -Pete
>>> _______________________________________________
>>> netlmm mailing list
>>> [email-masked]
>>> http://www.ietf.org/mailman/listinfo/netlmm
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm