Hi Tricci:
Thank you for reminding us such an important aspect, the
compatibility is a very important feature for the DMM of course. If the
DMM supports the compatibility, it will help the DMM to be deployed in the
real world. So ,basically, I agree the "SHOULD" should be change to
"SHALL".
Thanks for your suggestion.
BR
Luowen
[email protected]
发件人: [email protected]
2012/06/08 14:16
收件人
h chan <[email protected]>
抄送
"[email protected]" <[email protected]>
主题
Re: [DMM] draft requirement REQ-4: compatibility
Dear Anthony and LuoWen,
Sorry for jumping in late to this discussion. If I have missed some prior
discussion and repeat the same question, please forgive me.
I agree with Anthony's view that, "“Other mobility protocols” can only
refer to the existing mobility protocols that are already deployed. It
cannot refer to “future protocols” or “any protocol in the literature
which has not been deployed in the same environment in which dmm is being
deployed. "
However, when I refer to the current writing of the REQ#4:
>>>>>
REQ4: Compatibility
The DMM solution SHOULD be able to work between trusted administrative
domains when allowed by the security measures deployed between these
domains. Furthermore, the DMM solution SHOULD preserve backwards
compatibility with existing network deployment and end hosts. For
example, depending on the environment in which dmm is deployed, the dmm
solutions may need to be compatible with other existing mobility protocols
that are deployed in that environment or may need to be interoperable with
the network or the mobile hosts/routers that do not support the dmm
enabling protocol.
Motivation: The motivation of this requirement is to allow inter-domain
operation if desired and to preserve backwards compatibility so that the
existing networks and hosts are not affected and do not break.
>>>>>
First question to ask is that, why the backward compatibility with
existing network deployment and end hosts is "optional", and not
"mandatory"? Wouldn't the compatibility with the existing deployment be
the "fundamental" requirement? Hence, the "SHOULD" needs to be changed to
"SHALL".
Secondly, IMHO, compatibility has two aspects:
(1) backward compatible with existing deployment that has been discussed
above, but also
(2) no impact with the mobile host but still able to enable the DMM
solution at the network
I don't believe that we are proposing the DMM solution requirement that
must require the mobile node's support, correct?
If we can agree on these two above fundamental sentiment, then, I would
like to suggest a friendly amendment to REQ4 as follows:
>>>>>
REQ4: Compatibility
The DMM solution SHOULD be able to work between trusted administrative
domains when allowed by the security measures deployed between these
domains. Furthermore, the DMM solution SHALL preserve backwards
compatibility with existing network deployment and end hosts. For
example, depending on the environment in which dmm is deployed, the dmm
solutions SHALL BE compatible with other existing mobility protocols that
are deployed in that environment or SHOULD BE interoperable with the
network or the mobile hosts/routers that do not support the dmm enabling
protocol. In addition, it SHOULD BE feasible to enable DMM network
solution without the necessity to impact the existing mobile hosts.
Motivation: The motivation of this requirement is to allow inter-domain
operation if desired and to preserve backwards compatibility so that the
existing networks and hosts are not affected and do not break.
>>>>>
Hoping that you can accept these changes. Thanks in advance.
Tricci
h chan <[email protected]>
Sent by: [email protected]
06/07/2012 09:41 PM
To
"[email protected]" <[email protected]>
cc
"[email protected]" <[email protected]>, "[email protected]"
<[email protected]>, Peter McCann <[email protected]>
Subject
Re: [DMM] draft requirement REQ-4: compatibility
Luowen,
I understand that we earlier had a list of at least 3 requirements bundled
inside this REQ-4. We are now adding a 4th and possibly 5th into this list
regarding inter-domain. So I try to simplify 3 of them by examining the
end result: whether existing network deployment and end hosts will break.
What the dmm solution needs to do will then depend on the environment in
which it is deployed.
“Other mobility protocols” can only refer to the existing mobility
protocols that are already deployed. It cannot refer to “future protocols
” or “any protocol in the literature which has not been deployed in the
same environment in which dmm is being deployed.
If you want to be more specific, I suggest to append an explanatory
sentence to explain the requirement rather than adding more requirements
to the list.
H Anthony Chan
From: [email protected] [mailto:[email protected]]
Sent: Thursday, June 07, 2012 8:21 PM
To: h chan
Cc: [email protected]; [email protected]; jouni korhonen; Peter McCann
Subject: 答复: RE: Re: [DMM] draft requirement REQ-4: compatibility
Hi Antony,
Yes, I agree, the DMM solution shall be compatibile with the exsiting
network deployments. But only say "Existing network deployment and end
hosts also SHOULD NOT break" or "the DMM solution SHOULD preserve
backwards compatibility with existing network deployment and end hosts"
may not be very specific.
how about
The DMM solution SHOULD enable working between trusted administrative
domains when allowed by the security measures deployed between these
domains. Furthermore, the DMM solution SHOULD preserve backwards
compatibility with existing network deployment and end hosts that do not
support the DMM enabling protocol.
And put those description such as "The DMM solutions SHALL support
existing network deployment with IPv6 (e.g. existing IPv6 address
assignment), be compatible with other mobility protocols, and be
interoperable with the network or the mobile hosts/routers that do not
support the DMM enabling protocol so that the existing network deployments
and end hosts are not broken." into the motivation, e.g
Motivation: The motivation of this requirement is to ensure the DMM
solutions to support existing network deployment with IPv6 (e.g. existing
IPv6 address assignment), to be compatible with other mobility protocols,
and to be interoperable with the network or the mobile hosts/routers that
do not support the DMM enabling protocol, so that the existing network
deployments and end hosts are not broken.
Does it make sense?
BR
Luowen
h chan <[email protected]>
2012/06/08 07:13
收件人
"[email protected]" <[email protected]>
抄送
"[email protected]" <[email protected]>, "[email protected]"
<[email protected]>, jouni korhonen <[email protected]>, Peter
McCann <[email protected]>
主题
RE: Re: [DMM] draft requirement REQ-4: compatibility
Luo,
I think “existing network deployments which are not DMM enablded” are
included in “existing network deployments.
The end result is the compatibility with existing network deployment and
end hosts. So whatever the dmm solution needs to do to ensure such
compatibility. Do you agree?
H Anthony Chan
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, June 06, 2012 1:15 AM
To: h chan
Cc: [email protected]; [email protected]; jouni korhonen; Peter McCann
Subject: 答复: Re: [DMM] draft requirement REQ-4: compatibility
Hi Anthony:
It seems the REQ-4 is changed a lot. Interworking between trusted
administrative domains is good to me, and the interworking with existing
network deployments which are not DMM enablded is also very important. I
believe we have already have consistency about this. So, how about
mergering this two parts as following ?
---------------------------------------------------------------------------------
The DMM solutions SHALL support existing network deployment with IPv6
(e.g. existing IPv6 address assignment), be compatible with other mobility
protocols, and be interoperable with the network or the mobile
hosts/routers that do not support the DMM enabling protocol so that the
existing network deployments and end hosts are not broken. Furthermore,
the DMM solution MUST NOT break when being deployed between trusted
administrative domains and SHOULD allow inter-working with the security
measures deployed between these domains.
---------------------------------------------------------------------------------
Hope this make sense.
BR
Luowen
h chan <[email protected]>
发件人: [email protected]
2012/06/06 01:26
收件人
"[email protected]" <[email protected]>, Peter McCann <[email protected]>,
jouni korhonen <[email protected]>
抄送
主题
Re: [DMM] draft requirement REQ-4: compatibility
Replacing REQ-4 with the following:
REQ-4: compatibility
The DMM solution MUST NOT break when being deployed between trusted
administrative domains and SHOULD allow inter-working with the security
measures deployed between these domains. Existing network deployment and
end hosts also SHOULD NOT break.
H Anthony Chan
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of h
chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: [email protected]
Subject: Re: [DMM] draft requirement REQ-4: compatibility
An attempt to clean up the text for REQ-4:
REQ-4: compatibility
The DMM solutions SHALL support existing network deployment with IPv6
(e.g. existing IPv6 address assignment), be compatible with other mobility
protocols, and be interoperable with the network or the mobile
hosts/routers that do not support the DMM enabling protocol so that the
existing network deployments and end hosts are not broken.
REQ-4M (Motivation for REQ-4)
Motivation: The motivation of this requirement is not to break existing
network deployments and end hosts.
OTHER related problem
O-PS3: Complicated deployment with too many variants and extensions of MIP
Deployment is complicated with many variants and extensions of MIP. When
introducing new functions which may add to the complicity, existing
solutions are more vulnerable to break.
H Anthony Chan
-----Original Message-----
From: Peter McCann
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email protected]
Subject: RE: [DMM] draft requirement REQ-4: compatibility
Hi, Jouni,
jouni korhonen wrote:
>
> On May 7, 2012, at 9:04 PM, h chan wrote:
>
>> REQ-4: compatibility
>> The DMM solutions SHALL support existing network deployment with
>> IPv6
>> (e.g. existing IPv6 address assignment), be compatible with other
>> mobility protocols, and be interoperable with the network or the
>> mobile hosts/routers that do not support the DMM enabling protocol so
>> that the existing network deployments are unaffected.
>>
>> REQ-4M (Motivation for REQ-4)
>> Motivation: The motivation of this requirement is to be able to work
>> with network architectures of both hierarchical networks and flattened
>> networks, so that the mobility management protocol possesses enough
>> flexibility to support different networks, and so that the existing
>> networks and hosts are not affected and do not break.
>
> Isn't the motivation just "SHALL not break existing network
> deployments and end hosts" ?
> Either the network or the host may not have any idea of the solutions
> developed in DMM.
I think that's a reasonable simplification. We need a strategy for
backwards compatibility.
-Pete
> - JOuni
>
>>
>> OTHER related problem O-PS3: Complicated deployment with too many
>> variants and extensions of MIP Deployment is complicated with many
>> variants and extensions of
> MIP. When introducing new functions which may add to the complicity,
> existing solutions are more vulnerable to break.
>>
>> (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
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail
(and any attachment transmitted herewith) is privileged and confidential
and is intended for the exclusive use of the addressee(s). If you are not
an intended recipient, any disclosure, reproduction, distribution or other
dissemination or use of the information contained is strictly prohibited.
If you have received this mail in error, please delete it and notify us
immediately.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
