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

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 4 Mar 2008 11:01:36 +0800

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