Hi, Please see inline > > > > Sure, I know your question. In my mind, we can use this mid-session > > redirection associated with bulk-re-registration. > [Ahmad] > Well, that still does not solve the issue of making > administrative maintenance which does not depend on this > protocol to rely on sort of a random time of when the > mobility session lifetime expires. Imagine having a 500,000 > session on the LMA which spread across few MAGs, it is a nightmare! Right, bulk-re-registration method is only auxiliary method to mitigate the network overhead, but which is unavoidable when a large amount of mobility sessions expire during a short period. Especially in the case that rfLMA suddenly crashes or the path between rfLMA and MAG fails, all related mobility sessions will be redirected to a new LMA even if this scenario belongs to LMA reliability other than load balance. > > > Therefore, the LMA can perform redirection per MAG. > [Ahmad] > WOW! > > You think that the BULK registration is for re-registering > all the mobile node sessions on the MAG? > I better check that draft? It is still bulk re-registration but not bulk registration, rfLMA must share all mobility sessions of the MAG with r2LMA before taking administrative maintenance. the sharing depends on possible context transfer and other coordination management between the rfLMA and the r2LMA. > > > > In such > > case, the operation time will be short. > > In addtion, LMA can notify MAG the maintenance operation by > > out-of-band means. > [Ahmad] > That is a very GOOD idea. Then this feature is NOT needed. > If the LMA is GOING to provide this information out-of-band, > then the LMA can provide the MAG with the new LMA IP address? Right? > Mission Accomplished. Sure, but out-of-band mean is another vague method and out of scope. > > > > > The path failure is another scenario describe how to > redirect mobility > > sessions. > [Ahmad] > Let us address one usecase at a time. "draft-wakikawa-netext-lma-reliability" is one case. BR Jinwei
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.