Hi, All
>>> | "PS2: Divergence from other evolutionary trends in network
>>> | architecture
>>> |
>>> | Centralized mobility management can become non-optimal with
>>> a
>>> | flat network architecture."
>>> |
>>> | o What are the "other"? I would consider removing PS2 if we cannot
>>> |name those.
>>>
>>> I think "other" here refers to the distributed nature of delivering
>>> network services/content today (e.g. multiple data centers, CDNs
etc.).
>>> It's not only the mobile that moves around these days, but your
>>> "correspondent" node as well.
>>>
>>
>> Exactly. Here, we refer to distribution of content delivery, i.e. CDN.
Probably, one of the main motivation for distributing mobility management
:-) IMHO, if we should keep only one PS, it would be PS#2 :-)
>Maybe we need to then say something about it like
> "Divergence from other evolutionary trends in network
> architectures such as distribution of content delivery" ?
[Luowen] Maybe "other" just means another kind of network architecture
evolution trends. I interpret the "other" just as the "flatten network".
> | "REQ2: Transparency to Upper Layers when needed
> |
> | DMM solutions MUST provide transparent mobility support
> |above the IP layer when needed. Such transparency is needed,
> |for.."
> |
> | o Doesn't the "when needed" make the earlier MUST conditional? At
> |least I understand it so. If that is the case we probably could just
say:
> | "DMM solutions SHOULD provide transparent mobility support above
> |the IP layer." ?
> I know we should not be talking implementation, but since I got inspired
just now, this is the way I parse the former:
> procedure dmmXYZ (in: mobility_support_required, out: mobility_support)
{
> mobility_support = false;
> ...
> if (mobility_support_required==true) then mobility_support=true;
> ...
> }
[Luowen] I interpret this logic as the network support mobility, and
depends on applications on each individual mobile node to choose use the
mobility or not. I think it reasonable, and whether to choose use mobility
support or not is applications' decision.
> Your proposal does not capture the conditionality of mobility support
for different hosts, applications, and even different sessions of the same
app. I read it more like
> // set to 0 for disabling mobility support
> #define MOBILITY_SUPPORT 1
[Luowen] I interpret this logic as the operator could have some kind of
global configuration to decide whether to provide mobility support to all
its subscribers or not. It may provide, then #define MOBILITY_SUPPORT 1
,otherwise #define MOBILITY_SUPPORT 0. I think it reasonable, some
operator may only provide fixed/nomadic access service.
>> |I would need to implement the "mobility stack" whatever support
function
>> |anyway even if none of my application care about it.
>>
>> If you are absolutely sure that none of your apps needs mobility
support, and none will ever need it in the future, then there's no reason
to implement it, sure. But if there's a chance one app may need it and 100
won't, then perhaps you get to implement it. The difference is that, if
you do implement that "mobility stack", with conditional support you run
that code for one app only (and route the respective packets accordingly),
while with today's approach you do the same for 101 apps.
> Fair reasoning. However, what is the "mobility stack" here then? Is it
something we today understand as a MIP enabled stack or could it be
something more generic? What I mean here is that we should be very
cautious with MN side impacts not to freak out less mobility cautious
people. If the "mobility stack" could be beneficial also outside mobility
use cases that would be awesome.
[Luowen] Hi Jouni, what do you mean "What I mean here is that we should be
very cautious with MN side impacts not to freak out less mobility cautious
people" ? The applicaions on the mobile node doesn't need to understand
what is the mobility (i.e. the application developer doesn't need to
understand), and it seems to let an ordinary user to understand the
mobilty concept is impossible. As per my understanding, the application
only care to bind to an IP@ which can survive longer than itself.
BR
Luowen
jouni korhonen <[email protected]>
发件人: [email protected]
2012/11/15 18:56
收件人
Konstantinos Pentikousis <[email protected]>
抄送
"[email protected]" <[email protected]>
主题
Re: [DMM] comments on draft-ietf-dmm-requirements-02
Hi,
On Nov 14, 2012, at 8:28 PM, Konstantinos Pentikousis wrote:
> Hi Jouni, all,
>
> |Maybe we need to then say something about it like
> | "Divergence from other evolutionary trends in network
> | architectures such as distribution of content delivery" ?
>
> Sounds good to me.
Good.
> |No (without smile). But that is another trend to opposite direction
> |and we should have a sufficient argument for our assertion here imho.
What
> |is so fundamentally resource consuming in "mobility context" handling
> |that it requires distribution? Is it just a combination of all
> |functions in one place (that has little to do with mobility per se)?
>
> I think scalability here refers to the "hub-and-spoke" nature of the
routing fabric as introduced by a "centralized" mobility anchor. You may
have valid technical and/or operational reasons for adopting a
hub-and-spoke model, that's ok. But maybe others may want an alternative
model which aims for different optimalities, and for those the
hub-and-spoke model is not, well, "scalable".
>
> SDN, well the OpenFlow flavor of it anyway, is "logically centralized"
wrt network control, not how packets move around. SDN can do hub-and-spoke
as well as other routing fabrics. Information-centric networking, another
major trend, is definitely not pointing towards the merits of the current
type of centralization... So I think PS3 is valid.
PS3 says "centralized route management".. I would be far more comfortable
if PS3 says "centralized tunnel management" which is more concretely what
we do today as per hub-and-spoke type tunneled traffic deployments.
> |I would need to implement the "mobility stack" whatever support
function
> |anyway even if none of my application care about it.
>
> If you are absolutely sure that none of your apps needs mobility
support, and none will ever need it in the future, then there's no reason
to implement it, sure. But if there's a chance one app may need it and 100
won't, then perhaps you get to implement it. The difference is that, if
you do implement that "mobility stack", with conditional support you run
that code for one app only (and route the respective packets accordingly),
while with today's approach you do the same for 101 apps.
Fair reasoning. However, what is the "mobility stack" here then? Is it
something we today understand as a MIP enabled stack or could it be
something more generic? What I mean here is that we should be very
cautious with MN side impacts not to freak out less mobility cautious
people. If the "mobility stack" could be beneficial also outside mobility
use cases that would be awesome.
- Jouni
>
> Best Regards,
>
> Kostas
>
>
>
>
>
>
>
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
