Hi Pete, So, those are two requirements:
REQ-xx: Assess why MIP6 and derivatives could not be part of the DMM solution. REQ-yy: Assess how the MIP6 and derivative solutions could be dynamically instantiated and subsequently revoked in DMM environments. Could we please capture this? Thanks. -Rajeev On 5/18/12 7:36 AM, "Peter McCann" <[email protected]> wrote: > Hi, > > I think MIP6 and derivatives could very well be a part of the solution. > However, we need to place them into scenarios where the anchors are > allocated dynamically on an as-needed basis and garbage collected when > they are no longer needed. This may introduce some new requirements. > > -Pete > > Rajeev Koodli wrote: >> >> Hi Jouni, All, >> >> Sorry if this has been captured before.. >> >> Shouldn't there be a very basic requirement that should first outline >> why MIP6 and derivatives could not be deployed in scenarios suitable for >> DMM? I reckon this assumes a clear description of what DMM is exists. >> >> Thanks. >> >> -Rajeev >> >> >> >> On 5/17/12 4:56 PM, "jouni korhonen" <[email protected]> wrote: >> >>> >>> Few comments/questions here: >>> >>> On May 7, 2012, at 8:58 PM, h chan wrote: >>> >>>> REQ-2: Transparency to Upper Layers The DMM solutions SHALL enable >>>> transparency above the IP layer. Such transparency is needed for the >>>> application flows that cannot cope with a change of IP address and >>>> when mobile hosts or entire mobile networks change their point of >>>> attachment to the Internet, but SHOULD NOT be taken as the default >>>> behavior. >>> >>> "SHALL enable" but "SHOULD NOT be taken as the default behavior" seem >>> to conflict. So, what is really meant here? Does this mean something >>> like "MUST implement, SHOULD use" type of solution? Or can one leave >>> transparency completely away if the applications/hosts just don't care >>> whether IP changes or not? >>> >>>> >>>> REQ-2M (Motivation for REQ-2) >>>> The goal of this requirement is to >>>> enable more efficient use of network resources and more efficient >>>> routing by not invoking mobility support when there is no such need. >>> >>> Does this still mean the mobility support must be implement even if it >>> is not used? >>> >>>> >>>> RELEVANT problem: PS5: Wasting resources to support mobile nodes not >>>> needing mobility support IP mobility support is not always required. >>>> For example, some applications do not need a stable IP address during >>>> handover, i.e. IP session continuity. Sometimes, the entire >>>> application session runs while the terminal does not change the point >>>> of attachment. In these situations that do not require IP mobility >>>> support, network resources are wasted when mobility context is set up. >>>> Network resources are also wasted when the via routes are set up for >>>> many MNs that do not require IP mobility support. >>>> >>>> OTHER related problem O-PS1: Mobility signaling overhead with >>>> peer-to-peer communication While mobility management enables a mobile >>>> host to be reachable, the hosts may then communicate directly so that >>>> the mobility support is no longer needed. Taking the need of mobility >>>> support as the default behavior will waste network resources. O-PS2: >>>> Lack of user-centricity Centralized deployment compared with >>>> distributed mobility management may be less capable to support >>>> user-centricity. Example in the lack of user-centricity is to provide >>>> mobility support to all mobile nodes by default regardless of whether >>>> the user needs it or not. >>> >>> I have issues to parse O-PS2.. the motivation makes sense though but >>> the title "lack of user-centricity" is somewhat confusing.. what >>> does forced/always-on mobility support has to do with user centricity? >>> >>> - Jouni >>> >>> >>>> >>>> (The above has been drafted with contributions, inputs and >>>> discussions from various people. Additional contributions and >>>> comments are most welcome.) >>>> >>>> H Anthony Chan >>>> >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> _______________________________________________ >>> dmm mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
