Hi Sri, Hi all,
Agree with Sri that the discussions were kept on a high level.
Please note that the following draft tried to provide the work items that were
discussed
http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-03.txt
I thought that we had agreed on these work items,
Hi Sri,
Thanks for your explanation!
I think I agree with most of your explanatory text.
The gateway selection comes in place for both situations that you described,
where the gateway is the access CPA/DPA mentioned in your example. Each time
that the MN changes its point of attachment a
Hi Jouni, Hi all,
Sorry for not being able to attend the telco.
I have checked the updated charter. It looks good, but I have some comments:
Comment_1:
Not sure which of the mentioned milestones incorporate traffic steering after
re-anchoring.
Is it the milestone Forwarding path and
Hi John, Hi Alper,
Yes, that was the intention of having that text about “anchor re-selection” in
the paragraph!
Of course, the “anchor re-selection” should apply to an ongoing session!
Best regards,
Georgios
PS. I am afraid that I cannot attend the telco!
Hi,
In this email I am repeting the comment that I had today on the mike:
The current version of the draft is not using the requirements defined in the
requirements draft to identify the gaps on existing mobility protocols.
In my opinion it is important to use these requirements in order
Hi Seil,
What is the issue with Section 4.7?
Do we need to modify it, or is a requirement related multicast excluded from
what the DMM WG needs to focus on?
Best regards,
Georgios
Van: dmm-boun...@ietf.org [dmm-boun...@ietf.org] namens Seil Jeon
Dear all,
As I already mentioned during previous email discussions, I think that
draft-zuniga-dmm-gap-analysis-02 [1], describes well several
mobility protocols considered for gap analysis and it describes a clear
identification of their limitations!
Therefore I am in favour of adopting this
Hi all,
I also agree that the DMM solution should somehow consider muticast deployment.
However, I do not thnk that the DMM WG is the right WG to provide the multicast
based DMM solution!
One alternative solution will be to have a multicast requirement that
emphasizes the need of having
Hi Behcet, Hi all,
Regarding the cloud like architecture use case, the requirement that could be
used for this purpose can be the following one:
The DMM solution MAY have the ability to be applied in virtualized and/or
cloud like archietctures.
Motivation:
Currently, there is a trend
Hi Marco,
Thanks for the answers!
I think that the draft is valuable. In particular, this draft can provide the
basis for the work on gap analysis!
Best regards,
Georgios
Van: Marco Liebsch [marco.lieb...@neclab.eu]
Verzonden: zondag 4 november 2012
Hi Anthony,
Regarding your question, yes, the framework should allow the possibility that
data traffic and signaling take different paths!
Best regards,
Georgios
Van: h chan [h.anthony.c...@huawei.com]
Verzonden: maandag 5 november 2012 15:06
To:
Hi Behcet,
I would like to mention that I find this draft useful due to the following
reasons.
Currently, there is a trend to implement more and more functions of a mobile
communication network in software, e.g., for signal and protocol processing.
This enables the use of cloud computing
Dear all,
I also agree with Behcet that the impact of cloud networks in DMM should also
be included!
Best regards,
Georgios
-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
Behcet Sarikaya
Sent: donderdag 20 september 2012 18:19
To: Jouni
Hi Jouni, Hi all,
After discussing this issue with Carlos Jesús Bernardos and Juan Carlos Zuniga,
we concluded that the following set of possible technologies could be included
in the Gap analysis draft:
= Shim6: Level 3 Multihoming Shim Protocol for IPv6
14 matches
Mail list logo
