Subject: RE: Issue 13: Omission of prefix options - summary

From: "Bound, Jim" <[email-masked]>
Date: Thu, 6 Nov 2003 12:51:09 -0500

Tbis discussion should go to mipshop IMO.

Of course I do not have an issue with other docs extending ND options.  

But I don't believe this is needed and would like to see clear what problem is this solving.  It does not help with MD but I do not think this WG is the place to disuss MD issues but mipshop.

/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of JinHyeock Choi
> Sent: Thursday, November 06, 2003 4:10 AM
> To: Soliman Hesham; [email-masked]
> Cc: Tim Hartrick
> Subject: Re: Issue 13: Omission of prefix options - summary
> 
> 
> Dear Hesham
> 
> I disagree. 
> 
> IMO, Complete bit (or code) is an essential building block for an 
> efficient MD scheme and we'd better resolve this issue this time. 
> 
> It is IPv6 WG where we can define a complte bit, i.e. alter a 
> RA message format, though it may be done in DNA to specify detailed 
> MD procedure based on complete bit. .
> 
> I think we agreed that it's necessary to make it clearer that 
> the prefixes 
> are not omitted and LinkID scheme can't do this job. LinkID and 
> Complete bit is similar but not exactly the same. I'll 
> elaborate this in 
> detail below.   
> 
> I think, when we update ND, we'd better add this feature to RFC 2461,
> lest there should be one more update later.   
>   
> Kindly find my in line comments
> 
> Hesham Soliman wrote: 
> > Just a quick summary on this issue. It seems that there is
> > an agreement that there is a problem. However, it is not clear what 
> > the solution should be. It seems like we agree that a 
> "Complete" bit 
> > is better than a new code. There is also conflicting opinions on 
> > whether the new LinkID would be better than both (Complete 
> bit or new 
> > code).
> 
> The problem is: The omission of the prefixes makes it 
> difficult for a mobile 
> node to check whether the prefix of the current IP address is 
> supported in 
> the current link. 
> 
> Allow me delve into detail a little.
> 
> In some cases, with LinkID, an MN can detect link change but can't 
> check the validity of current CoA correctly. Here is an example. 
> 
> Assume a router has two interfaces and two access points are attached 
> to the each interfaces as below.
> 
>                                 +---------+
>                                  |               |         
>                       +-----+  Router  +-----+
>                        |         |                |         |  A::, 
>               A::     |        +----------+        |  B::
>                        |                                    |
>                 +---+---+                    +---+---+
>                 |   AP1   |                      |   AP2  |
>                 +-------+                     +-------+
> 
>                      A::1
>                 +---+---+                    
>                 |  MN    |                     
>                 +-------+                      
> 
> 
> The left interface advertise the prefix A:: and the right 
> interface advertises 
> the prefix A:: and prefix A:: and B::. Then two interface 
> should advertise 
> the different LinkIDs. 
> 
> Assume there is an MN in the left link with CoA, A::1. When it moves 
> to the right link and receives an RA with LinkID (and without 
> prefix A::), 
> it will  mistake that it can't use it's current CoA any 
> longer and perform 
> unnecessary handoff. 
> 
> Multi-link subnet makes matters complex and I wonder we can safely 
> ignore the above as the pathological exception. Otherwise, we should 
> tighten the multi-link subnet protocol to avoid such an accident. 
> 
> > In any case, since several people (including those who
> > brought up the issue) seem to agree that the issue is 
> > best addressed in DNA. And since there is no compelling
> > reason for adding this into 2461 Vs introducing a solution
> > in a new spec, I'd like to suggest that we close this 
> > issue and let DNA (or IPv6) handle this issue separately. 
> 
> I am afraid I gave a wrong impression. 
> 
> I meant that, we will deinfe MD solution with detailed operational 
> procedure in DNA WG.  But I think it would be IPv6 WG where 
> we adefine a new bit in RA message. 
> 
> Complete bit by itself is not sufficient for efficient MD. We 
> also needs to 
> specify the operational procedure for complete bit (complete RA). For 
> example, operation description like
> 
> 'An MN SHOULD interpret a different complete RA as a movement 
> indication but SHOULD NOT interpret a lack of complete RA as one. 
> 
> I meant that, we will specify such an operational procedures 
> in DNA WG.
> 
> IMO, though complete bit is not sufficient for efficient MD, 
> it's necessary 
> for efficient MD. It will be difficult for us to design a 
> efficient MD procedure 
> without completeness indication, complete bit. 
> 
> > So, in the current document, nothing needs to be done about
> > this issue (unless there are strong objections).
> 
> I wish, when we update RFC 2461, we also add this feature, 
> complete bit, 
> into Neighbor Discovery. Otherwise I am afraid we may have to 
> update ND 
> once more later.  
>  
> > Hesham
> > 
> > PS: To save emails, I'll assume silence means there is
> > no objections.
> 
> I hope my reply is fast enough so that I will not be counted 
> as one of silent those in favor. :-) 
> 
> Thanks for your kind consideration
> 
> Best regards
> 
> JinHyeock  D ûÂŠŠx®‹™¨ŠxŠË¦þz×®š)²Ú¶+EêzË†Û³ÿÃ
> z×®j)jŠËúŠ›
> 
 D� ���x �������x%��b���z���)��ڶ+�E�z�l��i����
bz���j)fj��b��?���

---

From: Greg Daley <[email-masked]>
Date: Fri, 07 Nov 2003 09:02:12 +1100

Hi Jim,

Bound, Jim wrote:
 >But I don't believe this is needed and would like to see clear what 
 >problem is this solving.  It does not help with MD but I do not think 
 >this WG is the place to disuss MD issues but mipshop.
 >
 >/jim

Mipshop has a very restricted charter which doesn't
cover these issues.

The DNA BoF is currently looking at these issues,
as a generic attempt to tighten up the Network Attachment
strategies for wireless hosts.

This is similar to  what Mobile IP requires, but has
broader applicability. For example, with some systems
MobileIP signalling may be unnecessary, but
detection of network change is.

The issues are: does it need to be done?
If so, where and when?

where is the venue (IPv6, DNA, Mipshop....)

The when is whether it is applicable to 2461bis.

Greg

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------