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

From: netlmm-tracker <[email-masked]>
Date: Tue, 23 May 2006 12:30:21 -0000

#58: IGP solution problems are not accurate.
-----------------------------------------+----------------------------------
 Reporter:  [email-masked]     |       Owner:  [email-masked]
     Type:  defect                       |      Status:  new                     
 Priority:  major                        |   Milestone:  milestone2              
Component:  draft-ietf-netlmm-nohost-ps  |     Version:  1.0                     
 Keywords:  PS draft                     |  
-----------------------------------------+----------------------------------
 Pekka Savola writes:

 4) Solution 3 (IGP host routes) problems are not accurate

 As pointed out in the previous thread, in Section 4, the Solution 3
 problems are not real problems.  A routing table is required at AR but
 it need to include much more than information about the current MNs
 connected to the AR.  IGP flooding is not an issue with proper area
 design.

 However, solution 3 still would require additional components, at least a
 function to redistribute "CN joins the link, it has IP address X"
 information to the MAP/LMA using the routing protocol.   But this function
 is required in any case.

 Similar arguments apply to section 4.0, last point 3) in advantages to
 creating a new solution.

-- 
Ticket URL: <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/58>
netlmm <http://tools.ietf.org/wg/netlmm/>

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

---

From: netlmm-tracker <[email-masked]>
Date: Tue, 23 May 2006 12:37:15 -0000

#58: IGP solution problems are not accurate.
------------------------------------------+---------------------------------
  Reporter:  [email-masked]     |       Owner:  [email-masked]
      Type:  defect                       |      Status:  assigned                
  Priority:  major                        |   Milestone:  milestone2              
 Component:  draft-ietf-netlmm-nohost-ps  |     Version:  1.0                     
Resolution:                               |    Keywords:  PS draft                
------------------------------------------+---------------------------------
Changes (by [email-masked]):

  * status:  new => assigned

Comment:

 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: netlmm-tracker <[email-masked]>
Date: Wed, 24 May 2006 09:57:42 -0000

#58: IGP solution problems are not accurate.
------------------------------------------+---------------------------------
  Reporter:  [email-masked]     |       Owner:  [email-masked]
      Type:  defect                       |      Status:  closed                  
  Priority:  major                        |   Milestone:  milestone2              
 Component:  draft-ietf-netlmm-nohost-ps  |     Version:  1.0                     
Resolution:  fixed                        |    Keywords:  PS draft                
------------------------------------------+---------------------------------
Changes (by [email-masked]):

  * resolution:  => fixed
  * status:  assigned => closed

Comment:

 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.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 May 2006 11:26:49 +0300 (EEST)

On Tue, 23 May 2006, netlmm-tracker wrote:
> [from the other mail]

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 May 2006 02:26:16 -0700

> 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.
>

The gap analysis was done long before the WG was formed. The original goal 
of the gap analysis was to describe existing solutions and illustrate how 
they did not satisfy the goals for localized mobility management in general, 
as motivation for forming the WG. When the WG was formed, the document was 
repurposed to instead describe the goals for the NETLMM protocol rather than 
for localized mobility management in general. The gap analysis was therefore 
a bit superfluous. At the Dallas meeting, we debated removing the gap 
analysis entirely, but decided instead to move it to an appendix for 
historical reasons.

> 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..
>

The solution approach is embodied in the NETLMM architecture, which is 
described in the charter and also in the PS document (again, put into the PS 
document as a result of the Dallas meeting). Unless we come up against some 
insurmountable technical problem with that architecture (such as occured 
with using IPsec in SEND), the WG will develop a protocol that matches that 
architecture. The NETLMM protocol design team, which has been hard at work 
since January doing the protocol design, met last week in Italy in a face to 
face meeting to finalize the design. It will be published shortly.

> protocols could do the job with a couple of modifications or 

"A couple of modifications or enhancements" opens up a big territory. The 
point of the gap analysis was to describe what can be done with *no* 
modifications or enhancements.

> 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:
>

I took from your email review of the PS document (which you referenced in 
your review of the REQ document) that the enhancement needed was some 
protocol to distribute the the mobile node movement information from the 
access router to the OSPF router on the Internet end of the tunnel. 
Specifically the following comment:

Since this is exactly what the NETLMM protocol is intended to do, it sounded 
to me like the OSPF tunneling solution would be another data plane option in 
addition to the others that have been discussed. It might need a document 
describing how to configure and use that information, but that is likely to 
be true of the others as well.

But your comment brings up a point. NETLMM is intended to have a 
configurable data plane, i.e. not bake in a certain kind of tunnel like 
Mobile IP does. We currently don't have a goal listed for this. Would it 
perhaps be a good idea to formalize this as another goal?

> 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.
>

Ah! Well, since I was working from the IP Unplugged document, it isn't 
suprising if it is incorrect. I don't claim to be an expert in OSPF routing 
configuration.

I'll remove the text. Thanx very much for pointing this out.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 31 May 2006 01:18:48 -0700

Hi Pekka,

So I found this Web page on the Cisco Web site which seems to describe the 
same solution as the IP Unplugged paper:

http://www.cisco.com/en/US/tech/tk722/tk721/technologies_white_paper09186a00800a3ca5.shtml

The discussion in this white paper cites the problems mentioned in the PS 
draft and the REQ gap analysis.

Do we need to inform Cisco that their Web site is inaccurate or can I keep 
this text in the drafts?

            jak

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Pekka Savola" <[email-masked]>; <[email-masked]>
Sent: Monday, May 29, 2006 2:26 AM
Subject: Re: [netlmm] #58: IGP solution problems are not accurate.

>> 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.
>>
>
>
> they did not satisfy the goals for localized mobility management in 
> general, as motivation for forming the WG. When the WG was formed, the 
> document was repurposed to instead describe the goals for the NETLMM 
> protocol rather than for localized mobility management in general. The gap 
> analysis was therefore a bit superfluous. At the Dallas meeting, we 
> debated removing the gap analysis entirely, but decided instead to move it 
> to an appendix for historical reasons.
>
>
> described in the charter and also in the PS document (again, put into the 
> PS document as a result of the Dallas meeting). Unless we come up against 
> some insurmountable technical problem with that architecture (such as 
> occured with using IPsec in SEND), the WG will develop a protocol that 
> matches that architecture. The NETLMM protocol design team, which has been 
> hard at work since January doing the protocol design, met last week in 
> Italy in a face to face meeting to finalize the design. It will be 
> published shortly.
>
> Since this is exactly what the NETLMM protocol is intended to do, it 
> sounded to me like the OSPF tunneling solution would be another data plane 
> option in addition to the others that have been discussed. It might need a 
> document describing how to configure and use that information, but that is 
> likely to be true of the others as well.
>
> suprising if it is incorrect. I don't claim to be an expert in OSPF 
> routing configuration.
>

---

From: netlmm-tracker <[email-masked]>
Date: Wed, 31 May 2006 08:19:57 -0000

Type:  defect                       |      Status:  reopened                

  * resolution:  fixed =>
  * status:  closed => reopened

Comment:

 Reopened, awaiting Pekka Savola's comment about validity of Cisco's
 recommened host route solution for mobility.

-- 
Ticket URL: <http://tools.ietf.org/wg/netlmm/trac/ticket/58>
netlmm <http://tools.ietf.org/wg/netlmm/>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 31 May 2006 14:28:31 +0300 (EEST)

Hi,

> Do we need to inform Cisco that their Web site is inaccurate or can I keep 

That's a good (more detailed) reference though it's probably almost 10 
years old.  I don't think it's incorrect as it's written, but assumes 
a scenario which is different from NETLMM as recently discussed.  The 
biggest difference seems to be that the solution is in fact using "IP 
subnet emulation", so that proxy-ARP is required to ensure 
connectivity with the "home" prefix is not disturbed when the mobile 
node moves to some other part of the network.  This requires that the 
router in charge of A.B.C.0/24 knows host routes of roaming users 
inside A.B.C.0/24, but not necessarily other host routes.  Note that 
such much more limited amount of flooding might be acceptable from the 
scalability point of view.

The document also makes an assumption that such mobility host routes 
would be advertised in OSPF as external type 5 LSAs.  While that's 
typical way to redistribute information from other routing protocols, 
the decision how to advertise host routes (based on DHCP or whatever 
information) is ultimately implementation's decision, and one could 
possibly use e.g. type 2 or 3 LSAs as well if different flooding and 
summarization behaviour is desirable.

I think it would be a good idea to ask an OSPF expert to walk through 
the OSPF configuration with the stated requirements in mind to see 
whether a solution (or which kind) would be applicable. For example, 
Acee Lindem (OSPF WG co-chair) might be a good bet if he'd have time 
for this.

> ----- Original Message ----- From: "James Kempf" <[email-masked]>
>> analysis was therefore a bit superfluous. At the Dallas meeting, we debated 
>> removing the gap analysis entirely, but decided instead to move it to an 
>> appendix for historical reasons.
>> 
>>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 31 May 2006 05:13:15 -0700

I think for purposes of these drafts, it isn't important that this solution 
be mentioned as an existing solution, since, as Vijay has pointed out to me 
in private email, it very likely isn't deployed very widely. Most enterprise 
networks don't deploy any mobility mangement, except perhaps the proprietary 
WLAN switch solutions discussed in 2). From your comments below, it seems 
like it would be a very limited option.

I think I'd like to just take the text out of the PS and REQ drafts. I do 
think that the possibility of combining NETLMM and OSPF/IS-IS stub subnet 
routing is an interesting one, and should be kept in mind while reviewing 
the base protocol. If it looks like a good proposition, perhaps we can 
perhaps get a draft on it, with someone who is an OSPF expert as co-author.

Again, thanx for your detailed analysis.

            jak

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 31, 2006 4:28 AM
Subject: Re: [netlmm] #58: IGP solution problems are not accurate.

>> So I found this Web page on the Cisco Web site which seems to describe 
>> the same solution as the IP Unplugged paper:
>>
>> Do we need to inform Cisco that their Web site is inaccurate or can I 
>> keep this text in the drafts?
>
> years old.  I don't think it's incorrect as it's written, but assumes a 
> scenario which is different from NETLMM as recently discussed.  The 
> subnet emulation", so that proxy-ARP is required to ensure connectivity 
> with the "home" prefix is not disturbed when the mobile node moves to some 
> other part of the network.  This requires that the router in charge of 
> A.B.C.0/24 knows host routes of roaming users inside A.B.C.0/24, but not 
> necessarily other host routes.  Note that such much more limited amount of 
> flooding might be acceptable from the scalability point of view.
>
> The document also makes an assumption that such mobility host routes would 
> be advertised in OSPF as external type 5 LSAs.  While that's typical way 
> to redistribute information from other routing protocols, the decision how 
> to advertise host routes (based on DHCP or whatever information) is 
> ultimately implementation's decision, and one could possibly use e.g. type 
> 2 or 3 LSAs as well if different flooding and summarization behaviour is 
> desirable.
>
> I think it would be a good idea to ask an OSPF expert to walk through the 
> OSPF configuration with the stated requirements in mind to see whether a 
> solution (or which kind) would be applicable. For example, Acee Lindem 
> (OSPF WG co-chair) might be a good bet if he'd have time for this.
>
>>>> work as-is), and b) to allow evaluating what is the best starting point 
>>>> for NETLMM protocol work.
>>>>
>>>
>>>
>>> The gap analysis was done long before the WG was formed. The original 
>>> goal of the gap analysis was to describe existing solutions and 
>>> illustrate how they did not satisfy the goals for localized mobility 
>>> management in general, as motivation for forming the WG. When the WG was 
>>> formed, the document was repurposed to instead describe the goals for 
>>> the NETLMM protocol rather than for localized mobility management in 
>>> general. The gap analysis was therefore a bit superfluous. At the Dallas 
>>> meeting, we debated removing the gap analysis entirely, but decided 
>>> instead to move it to an appendix for historical reasons.
>>>
>>>
>>> described in the charter and also in the PS document (again, put into 
>>> the PS document as a result of the Dallas meeting). Unless we come up 
>>> against some insurmountable technical problem with that architecture 
>>> (such as occured with using IPsec in SEND), the WG will develop a 
>>> protocol that matches that architecture. The NETLMM protocol design 
>>> team, which has been hard at work since January doing the protocol 
>>> design, met last week in Italy in a face to face meeting to finalize the 
>>> design. It will be published shortly.
>>>
>>> "A couple of modifications or enhancements" opens up a big territory. 
>>> The point of the gap analysis was to describe what can be done with *no* 
>>>> 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:
>>>>
>>> I took from your email review of the PS document (which you referenced 
>>> in your review of the REQ document) that the enhancement needed was some 
>>> sounded to me like the OSPF tunneling solution would be another data 
>>> plane option in addition to the others that have been discussed. It 
>>> might need a document describing how to configure and use that 
>>> information, but that is likely to be true of the others as well.
>>>

---

From: netlmm-tracker <[email-masked]>
Date: Wed, 31 May 2006 12:16:25 -0000

* resolution:  => fixed
  * status:  reopened => closed

Comment:

 Remove this text from both the PS and REQ drafts since although this may
 be an existing solution, it is not likely to be widely deployed. It has
 been around for more than 10 years so the lack of deployment suggests it
 isn't really a viable option.

 Combining routing with NETLMM is, however, an interesting possiblity and
 it should be kept in mind when the base protocol is under review.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 May 2006 16:41:55 +0300

Hi James,

So you seem to have converged on what to write for the
document. Good. But I just wanted to comment on the
general principle:

> ... (snip) ...

Its possible that there are documents out there that
either do not take into account all possibilities or
address slightly different scenario than what we
are addressing. Based on Pekka's e-mail the latter
appears to be the case here. But either way, we
should write our documents with the best knowledge
we have -- if we think <X>, the existence of someone's
document that does not agree with <X> should not
prevent us from saying what we want.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 31 May 2006 15:35:10 -0700

OK, thanx. 

        jak