Subject: [MEXT] The usage of "HA lifetime" (RFC3775-update)

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 14 Mar 2008 00:36:56 +0900

Hi

In RFC3775, the HA can advertise the HA lifetime by
the Home Agent information option carried in RA.
However, this home agent lifetime is only available in this option.

When MR boots up from a foreign link, there are several ways to get HA  
address such as
DNS lookup, DHAAD (no HA lifetime field is defined in DHAAD message),  
etc.

How should MN manage these HAs in the home agent list?

When the HA lifetime is not available,
should MN set INFINITY value for the HA in the home agent list?

When MN obtains HA at the foreign link and then back to the home,
shall MN update the HA lifetime of that HA to the value specified in RA?

MN might lose the HA due to the HA lifetime expiration if it return  
home.
If it never returns home, MN can keep the HA address forever
This is not fair:-)

I need some clarification how we can use this HA lifetime.

regards,
ryuji

ps. Mobicom08 and Mobiarch08 CFP are attached below!!!!

-------------------------------------------------------------------------
                        CALL FOR PAPERS

                           MobiCom 2008
            The Fourteenth Annual International Conference
                on Mobile Computing and Networking

                        September 14-19, 2007
             	   San Francisco Bay Area, CA, USA
              http://www.sigmobile.org/mobicom/2008/
                    Sponsored by ACM SIGMOBILE
-------------------------------------------------------------------------
ACM MobiCom is the premier international conference dedicated to
addressing the challenges in the areas of mobile computing and
wireless and mobile networking.  It has served as an exciting
international forum since 1995, addressing networks, systems,
algorithms, and applications that support the symbiosis of mobile
computers and wireless networks. This year, we will continue
this tradition, but we especially encourage the submission of papers
in the experimental systems area.  This area has seen exciting
developments in recent years and explicit efforts will be taken to
represent it strongly at MobiCom this year.

Authors are invited to submit full papers, challenges papers, student
posters, and research demos and exhibits, presenting new research
related to the theory or practice of mobile computing and/or wireless
and mobile networking. All submissions must describe original research,
not published or currently under review for another conference or
journal. Areas of interest include, but are not limited to:

  * Operating system and middleware support for mobile computing and
    networking
  * Architectures, protocols, and algorithms to cope with mobility,
    limited bandwidth, limited power and/or intermittent connectivity
  * Fundamental understanding of mobile computing and wireless  
networking
  * Wireless and mobile techniques for delay tolerant, mobile ad hoc,
    and wireless sensor networks
  * Security, privacy, and trustworthiness of mobile and wireless  
systems
  * Wireless access technologies (e.g. mesh systems, PANs)
  * Integration and interworking of wired and wireless networks
  * Protocols exploiting novel technologies such as UWB, MIMO,
    directional antennas, and software radios
  * Techniques for dynamic spectrum use
  * Architectures, algorithms and protocols for cognitive wireless
    networks and their integration in the Internet
  * Modeling, measurement and simulation of mobile networks
  * Experimental test-beds for mobile/wireless networks
  * Performance evaluation of mobile and wireless networks, protocols,
    and systems
  * Next generation (beyond 802.11) wireless technologies and related
    systems and protocols

Submission Instructions
Detailed instructions on how and where to submit your paper can be
found at http://www.sigmobile.org/mobicom/2008/cfp.pdf

IMPORTANT DATES:
Abstracts submission due: March 7, 2008
Paper submission due: March 14, 2008
Notification of acceptance: June 19, 2008
Camera-ready version due: July 7, 2008

General Chair - [email-masked]:
J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC

Technical Co-Chairs - [email-masked]:
Raghupathy (Siva) Sivakumar, Georgia Tech
Peter Steenkiste, Carnegie Mellon University

FOR MORE INFORMATION: Please contact the General Chair or Program
Co-Chairs for more information.  For information on ACM SIGMOBILE and  
the
MobiCom series of conferences, see http://www.sigmobile.org/ or contact
[email-masked].

-------------------------------------------------------------------------
                          CALL FOR PAPERS

                         ACM MobiArch 2008
                   An ACM SIGCOMM 2008 Workshop
                 Seattle, WA, USA, August 22, 2008

               The 3rd ACM International Workshop on
           Mobility in the Evolving Internet Architecture
              Paper registration deadline: March 17, 2008
-------------------------------------------------------------------------

       http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/

Recent developments in wireless access technologies and mobile devices
are beginning to make widespread user, terminal and network mobility a
reality in the commercial Internet. At the same time, the Internet
architecture struggles to incorporate the functionality that will  
sustain
this increasingly more mobile and more dynamic Internet use. Efficient
mobility management and mobility optimizations, locator-identifier
splits, multihoming, security and related network operation and
management functions are still in the early stages of development. It  
is,
however, already clear that supporting widespread mobility poses to
significantly impact the original end-to-end design of the Internet.

At the same time, critical momentum is building to significantly revise
or even replace the current Internet architecture. Several substantial
Future Internet initiatives have started in Europe, the US and Asia, and
the topic is also actively being discussed in the vendor and network
operator communities. These Future Internet efforts offer the exciting
opportunity to design radically different approaches to supporting host
and network mobility and multihoming, and may eventually lead to an
internetwork architecture with significantly more advanced mobility
features than those that the piecemeal extensions of the current  
Internet
protocols result in.

MobiArch'08 welcomes submissions from both researchers and practitioners
that explore recent advances in architectures, protocols and emerging
technologies to enable mobility and multihoming in the Internet, as well
as concepts and designs to support widespread mobility and multihoming  
in
future internetworks.  Early results, position papers, systems and
measurement papers are particularly welcome.

TOPICS
MobiArch'08 covers all aspects related to mobility in the current and
future Internet, including, but not limited to:

  * Architectures and protocols for mobility support at all layers
    of the Internet protocol stack, as well as cross-layer approaches
  * Novel concepts to support widespread mobility and multihoming
    in a Future Internet
  * Routing and addressing issues (including locator/identifier
    splits) and their impact on the Internet architecture
  * Multihoming, including flow distribution and load-sharing for
    wireless and mobility
  * Performance evaluation, experimentation and modeling of
    Internet mobility
  * Models for mobility patterns and their experimental validation
  * New wireless technologies and services and their impact on the
    Internet architecture
  * Location management, positioning and data management for
    wireless and mobility
  * Accounting, access control, security and privacy issues and
    their impact on the Internet architecture
  * Social, economic, scalability and deployment issues

SUBMISSION GUIDELINES
Submissions must be no longer than six pages, including all figures and
references, must be in PDF format, and must follow the ACM formatting
guidelines (http://www.acm.org/sigs/publications/proceedings-templates).
Submissions that do not adhere to these requirements will be rejected
without further review.
Peer review is single-blind; the authors names and affiliations are to  
be
included on the submission. Submissions cannot be previously published  
or
be under concurrent review elsewhere. The submission of position papers
is encouraged; please clearly identify position papers as such when
submitting.
Papers may be submitted at http://edas.info/newPaper.php?c=6140

IMPORTANT DATES
  March 17, 2008        Registration of paper abstract
  March 24, 2008        Submissions due
  May 1, 2008           Notification of acceptance
  June 9, 2008          Camera ready version due
  August 22, 2008       Workshop date

TECHNICAL PROGRAM COMMITTEE
  Lars Eggert           (co-chair, Nokia Research Center, FI)
  Linda Doyle           (co-chair, Trinity College, IE)
  Rui Aguiar            (Universidade de Aveiro, PT)
  Bengt Ahlgren         (Swedish Institute of Computer Science, SE)
  Jari Arkko            (Ericsson, FI)
  Marcelo Bagnulo       (University Carlos III of Madrid, ES)
  Olivier Bonaventure   (Université Catholique de Louvain, BE)
  Wesley Eddy           (NASA/Verizon (US)
  Joseph Evans          (University of Kansas, US)
  Ted Faber             (USC Information Sciences Institute, US)
  Stephen Hailes        (University College London, UK)
  Roger Karrer          (T-Labs, DE)
  Rajeev Koodli         (Nokia Research Center, US)
  Donal O'Mahony        (Trinity College, IE)
  Jörg Ott              (Helsinki University of Technology, FI)
  Guru Parulkar         (Stanford University, US)
  Dipankar Raychaudhuri (Rutgers University, US)
  Dave Thaler           (Microsoft, US)
  Ryuji Wakikawa        (Keio University, JP)
  Klaus Wehrle          (RWTH Aachen University, DE)
  Lixia Zhang           (UCLA, US)

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 14 Mar 2008 14:44:52 +1100

I think this is a valid point but I don't know if 3775 is the right  
place to address it. Since DHAAD is the only mechanism defined in 3775  
there is no issue. Other RFCs that define other mechanisms need to  
address the missing information.

Hesham

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 17 Mar 2008 17:39:08 +0900

Hi Hesham

I guess this HA lifetime (Home Agent Information Option) might be
originally introduced for the management of home agents operated on  
the same link.
Indeed, all the description for this option are for the Home Agent  
operation in RFC3775.

We should clearly state that this option is used only for HA and not  
for MN.
The usage of the home agent information option can be limited to the HA.
We just need to add 1-2 lines for the better clarification of this.

what do you think?

regards
ryuji

On 2008/03/14, at 12:44, Hesham Soliman wrote:

> place to address it. Since DHAAD is the only mechanism defined in  
> 3775 there is no issue. Other RFCs that define other mechanisms need  
> to address the missing information.
>
> Hesham

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 20 Mar 2008 17:19:21 +0800

Hi,

Just saw this mail in my back-log. Comments inline. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of RYUJI WAKIKAWA
> Sent: Monday, March 17, 2008 4:39 PM
> To: Hesham Soliman
> Cc: [email-masked]
> Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update)
> 
> Hi Hesham
> 
> I guess this HA lifetime (Home Agent Information Option) 
> might be originally introduced for the management of home 
> agents operated on the same link.
> Indeed, all the description for this option are for the Home 
> Agent operation in RFC3775.
[Ben] Most likely, HAs on home link uses lifetime to compute preferences on
the avaliability of HAs, since 3775 states that HA will reply MN in the HA
list a number of prefered HAs.

> 
> We should clearly state that this option is used only for HA 
> and not for MN.
[Ben] Why limit for HA usage? You pointed out in your previous mail that
since MR/MN does not know HA lifetime, is it not better to also inform MR/MN
of HA's lifetime in the HA list to advert those issues you raised up? 

Regards,
Benjamin Lim

> >> In RFC3775, the HA can advertise the HA lifetime by the Home Agent 
> >> information option carried in RA.
> >> When MR boots up from a foreign link, there are several 
> ways to get 
> >> HA address such as DNS lookup, DHAAD (no HA lifetime field 
> is defined 
> >> in DHAAD message), etc.
> >>
> >> When the HA lifetime is not available, should MN set 
> INFINITY value 
> >> for the HA in the home agent list?
> >>
> >> shall MN update the HA lifetime of that HA to the value 
> specified in 
> >> RA?
> >>
> >> If it never returns home, MN can keep the HA address 
> forever This is 
> >> not fair:-)
> >>
> ---------------------------------------------------------------------
> >> ---- ACM MobiCom is the premier international conference 
> dedicated to 
> >> computers and wireless networks. This year, we will continue this 
> >> tradition, but we especially encourage the submission of papers in 
> >> the experimental systems area.  This area has seen exciting 
> >> and mobile networking. All submissions must describe original 
> >> research, not published or currently under review for another 
> >> conference or journal. Areas of interest include, but are 
> not limited 
> >> to:
> >>
> >> Abstracts submission due: March 7, 2008 Paper submission 
> due: March 
> >> 14, 2008 Notification of acceptance: June 19, 2008 Camera-ready 
> >> version due: July 7, 2008
> >>
> >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter 
> Steenkiste, Carnegie 
> >> Mellon University
> >>
> >> the MobiCom series of conferences, see 
> http://www.sigmobile.org/ or 
> >> contact [email-masked].
> >>
> >> 
> >> Recent developments in wireless access technologies and mobile 
> >> devices are beginning to make widespread user, terminal 
> and network 
> >> mobility a reality in the commercial Internet. At the same 
> time, the 
> >> Internet architecture struggles to incorporate the 
> functionality that 
> >> will sustain this increasingly more mobile and more 
> dynamic Internet 
> >> use.
> >> Efficient
> >> is, however, already clear that supporting widespread 
> mobility poses 
> >> to significantly impact the original end-to-end design of the 
> >> Internet.
> >>
> >> At the same time, critical momentum is building to significantly 
> >> revise or even replace the current Internet architecture. Several 
> >> substantial Future Internet initiatives have started in 
> Europe, the 
> >> US and Asia, and the topic is also actively being discussed in the 
> >> vendor and network operator communities. These Future Internet 
> >> efforts offer the exciting opportunity to design radically 
> different 
> >> approaches to supporting host and network mobility and 
> multihoming, 
> >> and may eventually lead to an internetwork architecture with 
> >> significantly more advanced mobility features than those that the 
> >> piecemeal extensions of the current Internet protocols result in.
> >>
> >> MobiArch'08 welcomes submissions from both researchers and 
> >> practitioners that explore recent advances in architectures, 
> >> protocols and emerging technologies to enable mobility and 
> >> multihoming in the Internet, as well as concepts and designs to 
> >> support widespread mobility and multihoming in future 
> internetworks.  
> >> Early results, position papers, systems and measurement papers are 
> >> particularly welcome.
> >>
> >> TOPICS
> >> Submissions must be no longer than six pages, including 
> all figures 
> >> and references, must be in PDF format, and must follow the ACM 
> >> formatting guidelines 
> >> (http://www.acm.org/sigs/publications/proceedings-templates
> >> ).
> >> Peer review is single-blind; the authors names and 
> affiliations are 
> >> to be included on the submission. Submissions cannot be previously 
> >> published or be under concurrent review elsewhere. The 
> submission of 
> >> position papers is encouraged; please clearly identify position 
> >> papers as such when submitting.

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 20 Mar 2008 10:16:51 +0000

Guys,

I am not sure I follow you.

My understanding of the HA advertising a Lifetime on a link is that it
allows nodes on the link to (1) discover the HA address (2) cache the
HA address for as long as the lifetime indicates. This makes sense *on
link* since end nodes may discover the HA capability but they may also
have no use for it for a while (e.g., until a handoff to a foreign
link).

If  this explanation is correct, I would argue that when the HA is
discovered from a foreign link e.g., using DHAAD, DNS, DHCP etc, the
HA address must be used immediately and thus should NOT be cached. In
other words the MN should discover the HA address when it needs it and
then either engage with it or forget about it.

Does this make sense?

George

On Thu, Mar 20, 2008 at 9:19 AM, Benjamin Lim
<[email-masked]> wrote:
>  > >> ----

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 20 Mar 2008 18:48:09 +0800

Hi George, 

Your explanation makes senses, but I think MN still need to cache HA list
for a while as 3775 states that MN could choose another HA in the list to
retry home registration if it fails to receive a BA for its initial home
registration (in section 11.4.1) But of course, MN should not cache
indefinitely.

My point in my previous response is that I disagree that HA lifetime should
be restricted to HAs only as you pointed out that MNs/MRs on home link would
need to use them also.

Regards,
Benjamin Lim 

> From: George Tsirtsis [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2008 6:17 PM
> To: Benjamin Lim
> Cc: RYUJI WAKIKAWA; [email-masked]
> My understanding of the HA advertising a Lifetime on a link 
> is that it allows nodes on the link to (1) discover the HA 
> address (2) cache the HA address for as long as the lifetime 
> indicates. This makes sense *on
> link* since end nodes may discover the HA capability but they 
> may also have no use for it for a while (e.g., until a 
> handoff to a foreign link).
> 
> If  this explanation is correct, I would argue that when the 
> HA is discovered from a foreign link e.g., using DHAAD, DNS, 
> DHCP etc, the HA address must be used immediately and thus 
> should NOT be cached. In other words the MN should discover 
> the HA address when it needs it and then either engage with 
> it or forget about it.
> 
> Does this make sense?
> 
> George
> 
> >  > From: [email-masked] [mailto:[email-masked]] On  > 
> > Behalf Of RYUJI WAKIKAWA  > Sent: Monday, March 17, 2008 4:39 PM  > 
> > To: Hesham Soliman  > Cc: [email-masked]  > Subject: Re: [MEXT] The 
> > usage of "HA lifetime" (RFC3775-update)  >  > Hi Hesham  >  
> > I guess 
> > this HA lifetime (Home Agent Information Option)  > might be 
> > originally introduced for the management of home  > agents 
> operated on 
> > the same link.
> >  > Indeed, all the description for this option are for the Home  > 
> >  [Ben] Most likely, HAs on home link uses lifetime to compute 
> > preferences on  the avaliability of HAs, since 3775 states that HA 
> > will reply MN in the HA  list a number of prefered HAs.
> >
> >
> >  >
> >  > We should clearly state that this option is used only 
> for HA  > and 
> > not for MN.
> >  > The usage of the home agent information option can be 
> limited  > to 
> > the HA.
> >  [Ben] Why limit for HA usage? You pointed out in your 
> previous mail 
> > that  since MR/MN does not know HA lifetime, is it not 
> better to also 
> > inform MR/MN  of HA's lifetime in the HA list to advert 
> those issues you raised up?
> >
> >  Regards,
> >  Benjamin Lim
> >
> >
> >
> >  > > I think this is a valid point but I don't know if 3775 is the 
> > right  > > place to address it. Since DHAAD is the only mechanism 
> > defined in  > > 3775 there is no issue. Other RFCs that 
> define other  
> > > mechanisms need  > > to address the missing information.
> >  > >
> >  > > Hesham
> >  > >> In RFC3775, the HA can advertise the HA lifetime by the Home 
> > Agent  > >> information option carried in RA.
> >  > >> When MR boots up from a foreign link, there are 
> several  > ways 
> > to get  > >> HA address such as DNS lookup, DHAAD (no HA lifetime 
> > field  > is defined  > >> in DHAAD message), etc.
> >  > >>
> > INFINITY 
> > value  > >> for the HA in the home agent list?
> >  > >>
> >  > >> When MN obtains HA at the foreign link and then back to the 
> > home,  > >> shall MN update the HA lifetime of that HA to 
> the value  > 
> > specified in  > >> RA?
> >  > >>
> >  > >> MN might lose the HA due to the HA lifetime 
> expiration if  > it 
> > return  > >> home.
> > forever 
> > This is  > >> not fair:-)  > >>  > >> I need some 
> clarification how we 
> > can use this HA lifetime.
> >  > >>
> >  > >> regards,
> >  > >> ryuji
> >  > >>
> >  > >> ---- ACM MobiCom is the premier international conference  > 
> > dedicated to  > >> addressing the challenges in the areas of mobile 
> > computing and  > >> wireless and mobile networking.  It has 
> served as 
> > an exciting  > >> international forum since 1995, 
> addressing networks, 
> > systems,  > >> algorithms, and applications that support 
> the symbiosis 
> > of mobile  > >> computers and wireless networks. This year, we will 
> > continue this  > >> tradition, but we especially encourage the 
> > submission of papers in  > >> the experimental systems area.  This 
> > area has seen exciting  > >> developments in recent years 
> and explicit 
> > efforts will be taken to  > >> represent it strongly at 
> MobiCom this 
> > year.
> >  > >>
> >  > >> Authors are invited to submit full papers, challenges 
>  > papers, 
> > student  > >> posters, and research demos and exhibits, 
> presenting new 
> > research  > >> related to the theory or practice of mobile 
> computing  
> > > and/or wireless  > >> and mobile networking. All submissions must 
> > describe original  > >> research, not published or currently under 
> > review for another  > >> conference or journal. Areas of interest 
> > include, but are  > not limited  > >> to:
> >  > >>
> >  > >> * Fundamental understanding of mobile computing and 
> wireless  > 
> > >> networking  > >> * Wireless and mobile techniques for delay 
> > tolerant, mobile ad hoc,
> > > >> systems  > >> * Wireless access technologies (e.g. 
> mesh systems, 
> > PANs)  > >> * Integration and interworking of wired and wireless 
> > networks  > >> * Protocols exploiting novel technologies 
> such as UWB, 
> > MIMO,
> >  > >> * Techniques for dynamic spectrum use  > >> * Architectures, 
> > algorithms and protocols for cognitive wireless
> >  > >> * Modeling, measurement and simulation of mobile 
> networks  > >> 
> > * Experimental test-beds for mobile/wireless networks  > >> * 
> > Performance evaluation of mobile and wireless networks,  > 
> protocols,
> >  > >>   and systems
> >  > >> Detailed instructions on how and where to submit your 
> paper can 
> > be  > >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf
> >  > >>
> >  > >> IMPORTANT DATES:
> >  > >> Abstracts submission due: March 7, 2008 Paper 
> submission  > due: 
> > March  > >> 14, 2008 Notification of acceptance: June 19, 2008 
> > Camera-ready  > >> version due: July 7, 2008  > >>  > >> 
> General Chair 
> > - [email-masked]:
> >  > >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC  > >>  > >> 
> >  > >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter  > 
> Steenkiste, 
> > Carnegie  > >> Mellon University  > >>  > >> FOR MORE INFORMATION: 
> > Please contact the General Chair or Program  > >> Co-Chairs 
> for more 
> > information.  For information on ACM  > SIGMOBILE and  > >> the 
> > MobiCom series of conferences, see  > 
> http://www.sigmobile.org/ or  > 
> > > >> devices are beginning to make widespread user, terminal  > and 
> > network  > >> mobility a reality in the commercial Internet. At the 
> > same  > time, the  > >> Internet architecture struggles to 
> incorporate 
> > the  > functionality that  > >> will sustain this increasingly more 
> > mobile and more  > dynamic Internet  > >> use.
> >  > >> Efficient
> >  > >> mobility management and mobility optimizations, 
> > locator-identifier  > >> splits, multihoming, security and related 
> > network operation and  > >> management functions are still in the 
> > early stages of  > development. It  > >> is, however, already clear 
> > that supporting widespread  > mobility poses  > >> to significantly 
> > impact the original end-to-end design of the  > >> Internet.
> >  > >>
> > > >> substantial Future Internet initiatives have started in  > 
> > Europe, the  > >> US and Asia, and the topic is also actively being 
> > discussed in the  > >> vendor and network operator 
> communities. These 
> > Future Internet  > >> efforts offer the exciting 
> opportunity to design 
> > radically  > different  > >> approaches to supporting host 
> and network 
> > mobility and  > multihoming,  > >> and may eventually lead to an 
> > internetwork architecture with  > >> significantly more advanced 
> > mobility features than those that the  > >> piecemeal extensions of 
> > the current Internet protocols result in.
> >  > >>
> >  > >> MobiArch'08 welcomes submissions from both 
> researchers and  > >> 
> > practitioners that explore recent advances in architectures,  > >> 
> > protocols and emerging technologies to enable mobility and  > >> 
> > multihoming in the Internet, as well as concepts and 
> designs to  > >> 
> > support widespread mobility and multihoming in future  > 
> > internetworks.
> >  > >> Early results, position papers, systems and 
> measurement papers 
> > are  > >> particularly welcome.
> >  > >>
> >  > >> TOPICS
> >  > >> MobiArch'08 covers all aspects related to mobility in the  > 
> > current and  > >> future Internet, including, but not limited to:
> >  > >>
> > >> SUBMISSION GUIDELINES  > >> Submissions must be no 
> longer than six 
> > pages, including  > all figures  > >> and references, must 
> be in PDF 
> > format, and must follow the ACM  > >> formatting guidelines  > >> 
> >  > >> Submissions that do not adhere to these requirements 
> will  > be 
> > rejected  > >> without further review.
> >  > >> Peer review is single-blind; the authors names and  > 
> > affiliations are  > >> to be included on the submission. 
> Submissions 
> > cannot be previously  > >> published or be under concurrent review 
> > elsewhere. The  > submission of  > >> position papers is 
> encouraged; 
> > please clearly identify position  > >> papers as such when 
> submitting.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Mar 2008 12:07:35 +0100

Benjamin Lim wrote:
> Hi George,
> 
> Your explanation makes senses, but I think MN still need to cache HA
> list for a while as 3775 states that MN could choose another HA in
> the list to retry home registration if it fails to receive a BA for
> its initial home registration (in section 11.4.1) But of course, MN
> should not cache indefinitely.

It's also the case for rfc3963 (NEMOv6) section 5.4.1 Error Processing,
if the BAck status 140 then the MR is supposed to send the BU to another
HA on the home link.

The way MR obtains the address of another HA is supposedly by DHAAD.
I'm not sure rfc5026 can dynamically provide the address of another HA
on the home link, realtime, because rfc5026 depends on the propagation
of DNS data.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 09:37:11 -0700

> should MN set INFINITY value for the HA in the home agent list?

Configurable on the mobile node.

> If it never returns home, MN can keep the HA address forever

Why does it matter? If the mobile node is not able to use its
currently configured home agent, it tries to discover a new
home agent again. In systems where home agents are dynamically
assigned based on factors like service selection, the mobile
node should be configured to bootstrap every time it wants to
start a MIPv6-based session.

I don't think any change is needed in RFC 3775.

Vijay