Subject: RE: [nemo] What kind of NEMO RO problem WG document we would like to see

From: "Fan Zhao" <[email-masked]>
Date: Sun, 14 Nov 2004 02:45:20 -0800 (PST)

Dear Pascal, 

Please see my comments in line. Thanks.

Sincerely,
fan

> 
> > Below is my vision about NEMO RO problem WG document:
> > 1. NEMO RO problem draft should be written in an abstract way rather
> than
> > solution-specific.
> > (from calos's email on the ML if I am not wrong.) 
> 
> Yes, I do not think we are in contradiction here, are we? This is why we
> moved solutions to appendix. Like the bibliography, it's a tentative for
> additional help and time saving to the reader.
>
That is a good move.
 
> > 2. It does not matter how many pages the problem statement part should
> > be, but it must be
> > to the core of the problem.
> 
> I'm not sure that there is A problem to be singled out. Otherwise,
> there's a lot of space between one liners and a book. One liners might
> tend to be opaque and books could cause endless controversies because
> there's always a sentence here or a word there that's not perfect, while
> the core content could be diluted. I tend to agree that a reasonably
> short text is what we need here to get a correct understanding and yet
> reach consensus: Facts, but no literature.
>
OK. I think we are almost there regarding to the NEMO RO problem.
NEMO RO problem has two parts, one is inherited from Mip6 RO problem, the 
other is due to the nested mobility levels. 
 
> > 3. The solution "space" analysis part must not just simply list the
> > previouly proposed solutions.
> 
> Looks nice, but what's the limit? The imagination of the WG, maybe? 
> 
> Basically, all the domains that we as a group could think off and was
> willing to share was more or less explored in the last 2-3 years, in the
> form of solution proposals, and somewhat discussed already on the ML;
> this gave us some ground for the pro/cons/tradeoffs/applicability
> discussion. This is why the solution space that we explore looks like
> the space of existing proposals made a bit more abstract. But that's a
> consequence, not a goal.
> 
> The taxonomy draft has been there for 2 years for the ML to comment and
> propose additions. We received help from academic, ISP and corporate
> people. If you see some space that was not covered please speak up. It
> will be added if there's a rough consensus that it makes any sense. But
> I do not see benefits in starting it all over.
>
My point is that because it is hard to say the solution space is
completely explored, then WG document should analyze the solution space 
rather than just listing. The analysis gives us a deep understanding on 
what is driving the solutions, which is easier to handle than the various 
forms of solutions. The results of analysis in return will help us to 
discover the new solutions.
   
> > 4. It should be able to analyze the complete solution space including
> the
> > proposed and the new ones. (The completeness should be assured in
> certain
> > level.)
> 
> The problem is that we do not not what's not invented yet. A WG doc is a
> state of the art and of the understanding of a WG at the time of its
> publication. Does not mean it's forever perfect. Does NOT aim at
> LIMITING the acceptable solution to a given space, either. But rather at
> helping the thought / creation process and saving newcomers time.
>
Agree. That is why I mean the completeness should be assured in a certain 
level. We can decide what level it is. But we have to prepare how to 
answer once outside reviewers ask about it.
  
> Long as it's a draft, we are ready to add novelty anytime. Thomas' draft
> showed us that we did not treat MANET in a fair enough fashion. Good! We
> are working together on improving things, we'll add MANET text in the
> next issue, and this started an interesting discussion on the comparison
> of LMM and MANET based approaches, as they seem to provide similar
> benefits.
> 
> > 5. The method to categorize the solution space must be able to make
> one
> > category not
> > intersect with any other category (mutual exclusive).
> 
> Yes, that would be nice. Making a single category achieves that. But
> might leave things out. I understand your proposition like let's make a
> document that shows the solution space of everything yet to be invented,
> and then partition it in non overlapping categories. There are names
> like GRAAL for that sort of things; the rest of us do what we can in the
> time frame we have.
> 
> I read your draft and I liked it very much. IMHO, it's a good start, we
> must keep it and build on it. The way I read it, I found it relevant as
> a foudation for a requirement draft more then a problem statement. We
> are not there already, since we did not recharter or anything. 
> 
I agree with you that it is too early to talk about the requirements.
But most pages are talking about the problem statement though.
 
> On the to-be-discussed side, some things were a bit cryptic to me, like
> the reason why you discuss the data-plane method thing, and why you want
> to formalize the nested NEMO in a PS draft. Also, I'm not sure we want
> to mix RO and multihoming (the DAG thing).
I am going through a learning procedure. Right now when I read my draft 
again, I also feel unsatisfied. I might be wrong about the statement of 
data-plane method. And the formalization things is not necessary in the 
ps. And then I want to make it sure I consider the various configurations 
(multihoming). 

> 
> > 6. The solution space analysis does not judge on the strength and
> > weakness of each solution.
> 
> We disagree here (I have to disagree somewhere ain't it true?). I see
> the PS/solution space draft as a tool, not as a limiting boundary (as
> opposed to the requirements will be specifying what we have to cover). I
> believe that the pro/cons/tradeoffs/applicability discussion is at the
> core of the value of that tool.
>
OK. My concern is that it tends to make the reader believe one is better 
than another. And since you have to know the details of solution, so it 
might be better to do it after we have the good understanding about the 
solution space. Also some qualfier could help make a fair and thorough 
evaluation.

> 
> > 7. The security analysis should be general rather than being solution-
> > specific. Also it should be easy to apply to each solution.
> 
> You might want to list of the threats in the world in a separate
> chapter, or maybe in an encyclopedia. But the problems to be addressed
> are inherent to the solution space. Examples in the nested nemo case:
> trust in MANET approach, MITM/Time-shifting attacks in MR-proxy, etc...
>
Yes, there might be some threats specific to the solution. Again, security
consideration is kind of evaluation too.
 
> 
> > 8. The solution space analysis part must focus on the core idea
> because
> > there could be an infinite number of solutions that are in the
> different
> > forms.
> 
> We did not find them all, then :) But yes, we tried to abstract things
> and leave the specifics to the solution drafts in reference and
> eventually appendix. The only solution that we really detail is Erik's
> text on proxy. The reason is that it's very educational. Again, this is
> a tool, not a book of law.
> 
I do not if you think the following is correct or not:
the Ro solution just 1) makes anchor point close to either MNN or CN 2) 
informs the anchor point of the full path information to either the 
Internet or a specific router.

> > We also have to think about the content of WG document.
> > 
> And word your thoughts to the ML :)
>
Ok, I will once the thread starts.
 
> Pascal

---

From: "Fan Zhao" <[email-masked]>
Date: Thu, 18 Nov 2004 13:48:06 -0800 (PST)

Hi Chan-Wah,

Thanks for your reply. Please see my reply bleow.

Sincerely,
fan

> Hello Fan,
> 
> Sorry for replying late.  See reponses in-line:
> 
> /rgds
> /cwng
> 
> On Sun, 2004-11-14 at 02:30 -0800, Fan Zhao wrote:
> > > It runs the risk of
> > > being in conflict with your point #4 above.  To strictly demand 
mutual
> > > exclusiveness will often leads to incompleteness.  
> > I do not understand why. Can you explain about it?
> > 
> 
> By strictly demanding mutual exclusivity, you are demanding the division
> of an area into two non-overlapping areas.  It runs a risk of having
> area not covered by the two areas.
>
Not necessarily. For example, your multi-homing draft and 
Watari & Thierry's nested_cn draft have done a very nice work in
the categorization. 
 
> > > To me, having mutual
> > > exclusive approach is only something that is preferable, but not of 
high
> > > priority.  Instead it is the completeness that we should try to 
achieve.
> > > (Your choice of words "should" in #4 and "must" in #5 seems to 
indicate
> > > you felt otherwise).
> > > 
> > Mutual exclusion avoids the duplication and redundency. Also it 
provides
> > the clear comparison and contrast between the different categories. 
The
> > completeness and mutual exclusion are independent and equally 
important.
> > 
> 
> I am not saying mutual exlcusivity is not good.  I like mutual
> exlusivity, but not at the expense of completeness is my point.
> 
> > > What advantages does mutual exclusive solution space partitioning 
gives
> > > us?
> > >
> > The ideal solution space partition should look like this:
> > 
> > Base on a certain criterion, the whole solution space is partitioned 
into 
> > for exmaple A and B. And based on another criterion, A is partitioned 
> > into for example, A1 and A2. B is partitioned into for example B1, B2 
and 
> > B3 based on the same or a different criterion. In this way it is easy 
to 
> > see the commonness and difference among the solutions and avoids the 
> > duplicated analysis.
> 
> AH ... your a and B do overlaps, don't they?  SO what you are proposing
> is this, suppose we come up wth 2 criteria, A and B, so you would
> partitioned the solution space into 4 quadrants: Q1: A & B, Q2: !A & B,
> Q3: A & !B,  and Q4: !A & !B.
> 
> Right?  Interesting proposal, seems to be along the line of the way we
> classify mutlihoming cases ...
> 
That could be a possible way given the appropriate criteria.
Actually what is in my mind right now is this kind of line of thinking:
1) From the NEMO RO problem described and analyzed before, we can
deduce what NEMO RO solution is expected to do (not solution specific)

For example, NEMO RO solution is expected to answer the following 
questions:
i) how to achieve the full binding information between 
Home_Address/Home_Network_Prefix and the point of attachment to a 
specific router (AR when CN is not under the same nested NEMO network and 
the first common MR when CN is under the same nested NEMO network.) 
ii) how to transfer this information from HA/MR to CN/CR/other
routers (other MR/AR) that is close to MNN/CN. 
iii) How to route the data packet based on the available full binding 
information.

(i and ii are usually closely related, so I combine them by a vector in 
my slides.)

2) The "approaches" are categorized based on i, ii, and iii described 
above. And the associated issues are analyzed.
 
i) includes a) Home_address/Home_network_prefix: 
		This kind of information is available to MR and HA.
		a1. MR/HA could register MNP with CN by a similar RR test.
			Possible issues: Strength: ...
					 Weakeness: scope ...
		a2. Registering HoA ...
            b) The information about the point of attachment
		b1. the point of attachment to AR
			c1. Each MR's CoA is attached to one payload thus 
                            a sequence of CoAs is formed. 
                            (like in RRH and PCH draft.)
			c2. Prefix delegation/remapping. (like in PD and
                            ND-proxy draft)
			c3. The extended Route Advertisement message.
			c4. Manet
			c5. MR sends the probing packet
			c6. include the parent MR's CoA in the BU 
                            packet (partial approach)
			c7. recursively proxy the child MR/MNN's RO 
                            message (like "MR as a proxy" in taxonomy 
                            draft) 
			c8. CN deduces from a sequence of BU packets or 
                            BC entries.
		b2. the point of attachment to MR	
		        Similar with the methods in b1 (maybe not 
                        including the last one c8).
		And the issues for each approach (from c1 to c8).

ii) includes 	a) from HA to CN/CR
		b) from HA to other_MR/AR
		c) from MR to CN/CR
		d) from MR to other_MR/AR
		And issues for each approach

iii) includes	a) IP-in-IP
			issues:
		b) routing header
			issues: may require the extension and the 
                                processing on each router
				either in the Internet or inside the 
                                nested NEMO
		c) Combination of a and b
			issues:

This might be incomplete and just want to show what I think.

In the original taxonomy draft, it seems to me it is going into the 
approach analysis part directly from the problem statement part. I feel 
there is a gap in between. It might be better to have a conclusion saying 
what the NEMO RO solution is expected to do given the problem statement 
and analysis we made, which is not only a natual result of problem 
statement and analysis, but also serves our purpose by making a PS draft: 
to show we understand the problem well and are able to solve it. After 
that we categorize the approach space based on that statement and analyze 
the possible issues.

In this way, I hope that even later the new approaches come out, it is 
easy to find the correct place in our categorization for them.

> > > An analysis should try to be as objective as possible.  That goes
> > > without saying.  But what is the use of an analysis if it does not
> > > points out the relative strength and weakness of each approach?  
> > 
> > The reasons I list this are 
> > 
> > 1) IMHO this might be the way going into the details of solution too 
> > much. Also since you have to have the detailed solution in mind, your 
> > analysis does not include the new solution, which voids the 
completeness. 
> > 
> Nope, given what you have defined in the solution space you are
> describing, an analysis should point out the strength and weakness of
> that solution space.  For instance, your solution space might be: 
> 
> a; require sending of BU with prefix to CN, 
> !a: does not require sending of BU to CN.
> 
> Then it should point out that (a) requires changes to CN, which is
> generally undesirable.
> 
> > 2) I do not see how your taxonomy draft can give a thorough 
evaulation 
> > without any formly defined qualifier. It could generate a lot of 
emails 
> > like "comments on the evaluation part". 
> > http://www1.ietf.org/mail-archive/web/nemo/current/msg01677.html
> > http://www1.ietf.org/mail-archive/web/nemo/current/msg01689.html
> > http://www1.ietf.org/mail-archive/web/nemo/current/msg01692.html
> > (Thierry and Pascal if I misunderstand your email, please correct me.)
> > 
> 
> No, we are not trying to evaluate solutions.  That's not the purpose of
> the solution space analysis.  It simply is an analysis to help whatever
> WG (new, or the re-chartered NEMO WG) that is going to develop and
> specify a standardized NEMO Extended Support.
> 
> > 3) As when I was writing this email, I recall the similar concerns 
> > expressed on the ML. 
> > (http://www1.ietf.org/mail-archive/web/nemo/current/msg01657.html,
> > http://www1.ietf.org/mail-archive/web/nemo/current/msg01681.html, Am 
I 
> > right, Alex?) 
> > I am not saying it is impossible that the evaluation can not be done 
> > nicely in a reasonable level of fairness and correctness. But at this 
> > point, as we have not understood the whole solution space, it might 
be 
> > too early to do it.  
> > 
> > > (I prefer to use the term 'approach' rather than 'solution', as the 
> > latter
> > > can often be interpreted as the 'solution described in
> > > draft-foo-bar-xx.txt').  
> > Do you mean "approach" is a kind of mechanism to solve the RO 
problem, 
> > right? As Thierry also suggests the term of "issue". My understanding 
> > about the differences between "issue" and "approach" is 
that "approach" 
> > tries to solve the whole NEMO RO problem while "issue" is related to 
only 
> > some part of problem. 
> > 
> 
> Nope, for me,  "approach" is a general way to solve a particular problem
> (like solve this problem using routing header), a "solution" is
> draft-xxx-xxxx that specifies details of an approach (like use Reverse
> Routing Header).  If you like, you can call "solution" a "proposal".
> 
> My understanding of what Thierry is concerned is the confusion of issues
> and problems.  He want to use "problems" to refer to problem with NEMO
> Basic Support that leads to the need for RO; and "issues" to refer to
> the potential problems that a particular RO approach might face.
> 
OK, that sounds good. It helps clarify a lot of confusions.

> /rgds
> /cwng