Re: [netlmm] #58: IGP solution problems are not accurate.

[Pekka Savola <[e-mail]>]

On Tue, 23 May 2006, netlmm-tracker wrote:
> The description here comes from studying Ref. 25 in the REQ document:
>
>  "Mobile VPN Network Configuration Alternatives", IP Unplugged,
>            http://www.ipunplugged.com/pdf/Network-blueprints_A.pdf.
>
> A reference should be added in this document. Note that this solution
> requires no additional protocol.
>
> As to the accuracy of the problems cited, the problems written up in the
> text come from a reading of the above document. The thread Pekka is
> speaking about might be a solution to the NETLMM protocol problem, but it
> is not an existing solution since it requires additional protocol work.
> This text is speaking about problems with existing solutions, not about
> how they could be modified. As such, I think the current text in the
> document requires no modification, if, of course, the interpertation of
> the problems with the solution in the above document is correct.
>
> [from the other mail]
>
> Added references and the following qualifier after the list of 
> problems:
>
> Note that these considerations apply to the protocol described in [14] in
>  which an IGP is used without any changes.

There is a serious misunderstanding here, but I think we have a bigger 
problem as well.

1) what's the goal of describing existing solutions?

I'm not sure if I understood the purpose of evaluating different 
solution alternatives.  I thought the goal was two-fold: a) to show 
what approaches have been taken in the past (and why they might not 
work as-is), and b) to allow evaluating what is the best starting 
point for NETLMM protocol work.

You seem to be saying that b) is not the intent.  Is there going to be 
another draft on solution evaluation?  Or how will the solution 
approach be chosen?  If there is no written-up discussion of 
alternatives, it's probably difficult to make an informed decision..

It'd seem ridiculous to design a new protocol from scratch if existing 
protocols could do the job with a couple of modifications or 
enhancements...

2) misunderstanding about the use of OSPF

What I referred to were 'additional mechanism' and 'additional 
components.... a function to redistribute [host joins a link] 
information using the routing protocol'.

This does not require a new protocol, or protocol modification. 
This can be achieved using local implementation only, and this is 
exactly what has been done in the reference.  Its pages 12-13 state:

   "The Roaming Gateway needs to interact with the OSPF router in order
    to initiate router updates in the internal routing hierarchy when
    users move amongst the internal networks."

I assume that this is exactly the function I was referring to.

The text is factually incorrect and it doesn't portray existing IGP 
solutions very well.

That's understandable in a way -- because the ipUnplugged reference is 
also factually incorrect. It doesn't describe the existing and 
deployed routing protocol scalability mechanisms very well, just 
assuming all updates are flooded to every router.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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