Subject: [netlmm] #86: DHCP is a mobility management protocol too (for Gap analysis)

From: netlmm <[email-masked]>
Date: Thu, 15 Jun 2006 21:20:25 -0000

#86: DHCP is a mobility management protocol too (for Gap analysis)
------------------------------------------+---------------------------------
 Reporter:  [email-masked]      |       Owner:  [email-masked]
     Type:  defect                        |      Status:  new                     
 Priority:  major                         |   Milestone:  milestone2              
Component:  draft-ietf-netlmm-nohost-req  |     Version:  1.0                     
 Keywords:  REQ draft                     |  
------------------------------------------+---------------------------------
 Fred Templin says:

 5) Section 9, "DHCP + IP forwarding table manipulation" should
 be listed as another item for the gap analysis, but I don't see
 a detailed analysis coming within the time remaining between now
 and Friday. Suggest adding a very short subsection such as:

   "9.6 DHCP + IP forwarding table manipulation"

    It has been suggested that using DHCP on mobile nodes, access
    routers and localized mobility agents can provide a framework
    for localized mobility management when the DHCP exchanges are
    also tied to IP forwarding table manipulations on routers.
    This method requires further investigation before a gap analysis
    can be determined. In one alternative, DHCP could be seen as an
    access method for the eventual NETLMM protocol design."

 Then (since the gap analysis is not complete) there should be
 no entry for this alternative under the "Summary" section.

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

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

---

From: netlmm <[email-masked]>
Date: Thu, 15 Jun 2006 21:27:58 -0000

#86: DHCP is a mobility management protocol too (for Gap analysis)
-------------------------------------------+--------------------------------
  Reporter:  [email-masked]      |       Owner:  [email-masked]
      Type:  defect                        |      Status:  closed                  
  Priority:  major                         |   Milestone:  milestone2              
 Component:  draft-ietf-netlmm-nohost-req  |     Version:  1.0                     
Resolution:  wontfix                       |    Keywords:  REQ draft               
-------------------------------------------+--------------------------------
Changes (by [email-masked]):

  * resolution:  => wontfix
  * status:  new => closed

Comment:

 The gap analysis is supposed to be for protocols that a) have in the past
 (i.e. not as part of the current NETLMM effort) been proposed for
 localized mobility management in IETF and b) there is was an existing
 (i.e. not currently ongoing) implementation and study of the protocol when
 the NETLMM effort started.

 From my browsing of draft-templin-autoconf-netlmm-dhcp-01.txt, it does not
 sound as if this solution can be accomplished without modifying the
 forwarding code on the access routers, and developing a new code for the
 LMA. So I don't see a gap analysis of this solution being relevant to this
 document.

 In addition, the gap analysis has become secondary to the purpose of this
 document, which is to define the goals of the NETLMM protocol. So I don't
 think adding additional material on other protocols will really help
 advance the primary purpose of the document. Finally, as noted by the
 suggestor, a complete gap analysis has not been done on this solution, so
 any text added now would probably not do justice to the technical details
 in any event.

 Recommendation: not to add any text on this.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 15 Jun 2006 14:35:50 -0700

James,

I am OK with the resolution, but I wish I could get you
to stop saying that the proposed DHCP solution requires
undue modifications to forwarding code since it really
doesn't; all thats happening is that the DHCP relay and
server are adding/deleting routes in the IP forwarding
table using standard mechanisms.

Also, as far as I can tell the AR and LMA are fair game
for modifications; at least that is my read from looking
at the MN-AR interface spec.

Am I somehow missing your point?

Fred
[email-masked] 

-----Original Message-----
From: netlmm [mailto:[email-masked]] 
Sent: Thursday, June 15, 2006 2:28 PM
To: [email-masked]
Subject: Re: [netlmm] #86: DHCP is a mobility management protocol too
(for Gapanalysis)

#86: DHCP is a mobility management protocol too (for Gap analysis)
-------------------------------------------+----------------------------
----
  Reporter:  [email-masked]      |       Owner:
[email-masked]
      Type:  defect                        |      Status:  closed

-------------------------------------------+----------------------------
----
Changes (by [email-masked]):

  * resolution:  => wontfix
  * status:  new => closed

Comment:

 The gap analysis is supposed to be for protocols that a) have in the
past
 (i.e. not as part of the current NETLMM effort) been proposed for
 localized mobility management in IETF and b) there is was an existing
 (i.e. not currently ongoing) implementation and study of the protocol
when
 the NETLMM effort started.

 From my browsing of draft-templin-autoconf-netlmm-dhcp-01.txt, it does
not
 sound as if this solution can be accomplished without modifying the
 forwarding code on the access routers, and developing a new code for
the
 LMA. So I don't see a gap analysis of this solution being relevant to
this
 document.

 In addition, the gap analysis has become secondary to the purpose of
this
 document, which is to define the goals of the NETLMM protocol. So I
don't
 think adding additional material on other protocols will really help
 advance the primary purpose of the document. Finally, as noted by the
 suggestor, a complete gap analysis has not been done on this solution,
so
 any text added now would probably not do justice to the technical
details
 in any event.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Jun 2006 15:18:12 -0700

jak>> According to Section 4.2 & 4.3 of 
draft-templin-autoconf-netlmm-dhcp-01.txt, the AR needs to make 
modifications to BOOTP and DHCP traffic - in part as a result of examining 
the traffic it is relaying - and inject host routes based on the IP 
addresses of hosts on its wireless interface. Similarly, the "MAP" (I assume 
this means a router configured to act as a MAP since MAP functionality is 
not part of the standard functionality on an IP router as far as I am aware) 
must synchronize its DHCP address allocations with other MAPs and take the 
IP address allocated as a result of a DHCPDISCOVER or BOOTP message and 
inject a host route bound to a tunnel interface (which it must set up?). In 
fact, Section 4.4 asserts that these functions are exclusive to this 
document, which means, to me, that they are not specified as standard 
functions for DHCP servers, DHCP relays, BOOTP agents, and IP routers.

jak>> Given that the document explictly states this, I take it to mean that 
I cannot just go out and set up a network with standard off the shelf gear 
and have this work, that is, somebody needs to write some code to glue these 
protocols together. Whether that code is part of the forwarding code or not 
isn't really the point.

jak>> As mentioned in the suggested resolution, the gap analysis was 
intended for protocols that were designed and implemented (even if only 
experimentally) when the NETLMM effort started. If we didn't make that 
restriction, new protocols could be brought in arbitrarily during the design 
of  the protocol and subject to gap analysis. The gap analysis was meant to 
motivate the need for new work, and it seems to me that draft-templin is 
that work. So it doesn't seem a candidate for gap analysis.

jak>> Regarding what becomes a WG item for NETLMM, we have a design team 
working on the LMA/AR protocol. A draft should be forthcoming shortly, 
please stay tuned. As is true of all IETF design team efforts, the WG will 
decide whether to accept that design as a WG draft.

jak>> There is also need for describing how the NETLMM protocol interfaces 
with subnet configuration on the MN, including with DHCP, and the WG will 
decide what the text for that should be, though it should go in the MN-AR 
interface document.

            jak

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 15 Jun 2006 16:04:18 -0700

Thanks for the follow-up James; I think I get your point
now. I will have a look at the design team work when it
comes out.

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, June 15, 2006 3:18 PM
To: Templin, Fred L; [email-masked]; [email-masked]
Subject: Re: [netlmm] #86: DHCP is a mobility management protocol too
(forGapanalysis)

jak>> According to Section 4.2 & 4.3 of 
draft-templin-autoconf-netlmm-dhcp-01.txt, the AR needs to make 
modifications to BOOTP and DHCP traffic - in part as a result of
examining 
the traffic it is relaying - and inject host routes based on the IP 
addresses of hosts on its wireless interface. Similarly, the "MAP" (I
assume 
this means a router configured to act as a MAP since MAP functionality
is 
not part of the standard functionality on an IP router as far as I am
aware) 
must synchronize its DHCP address allocations with other MAPs and take
the 
IP address allocated as a result of a DHCPDISCOVER or BOOTP message and 
inject a host route bound to a tunnel interface (which it must set up?).
In 
fact, Section 4.4 asserts that these functions are exclusive to this 
document, which means, to me, that they are not specified as standard 
functions for DHCP servers, DHCP relays, BOOTP agents, and IP routers.

jak>> Given that the document explictly states this, I take it to mean
that 
I cannot just go out and set up a network with standard off the shelf
gear 
and have this work, that is, somebody needs to write some code to glue
these 
protocols together. Whether that code is part of the forwarding code or
not 
isn't really the point.

jak>> As mentioned in the suggested resolution, the gap analysis was 
intended for protocols that were designed and implemented (even if only 
experimentally) when the NETLMM effort started. If we didn't make that 
restriction, new protocols could be brought in arbitrarily during the
design 
of  the protocol and subject to gap analysis. The gap analysis was meant
to 
motivate the need for new work, and it seems to me that draft-templin is

working on the LMA/AR protocol. A draft should be forthcoming shortly, 
please stay tuned. As is true of all IETF design team efforts, the WG
will 
decide whether to accept that design as a WG draft.

jak>> There is also need for describing how the NETLMM protocol
interfaces 
with subnet configuration on the MN, including with DHCP, and the WG
will 
decide what the text for that should be, though it should go in the
MN-AR 
interface document.

            jak