Hi Pierrick, I agree fully. Just one comment:
Le 28/10/2014 16:19, pierrick.se...@orange.com a écrit :
Hi Hui,
Thus current way to use MIP is to bind an IP flow to one path.
However, MIP deals only with path establishment
MIP deals with single path establishments, and not simultaneous paths
establishments.
MIP sets up a tunnel on the MR and HA that has a single HoA and may have
multiple CoA. MIP can not set multiple tunnels, each with its own HoA
and CoA, and can not set more than 2 addresses per one tunnel.
Probably most importantly, when using MIP one still uses one single
default route towards one single of these tunnel interfaces at a time.
Application-independent bandwidth augmentation would need a default
route to be used towards multiple tunnels, maybe in a round-robin
fashion for each outgoing IP packet (independent of application).
and flow policy negotiations but not on traffic management.
I agree.
So, once multiple overlay tunnels are established, nothing prevent
to split one flow on theses paths.
I agree, but currently MIP does not tell how to establish multiple
tunnels. It does not even tell to which of these tunnels to set the
default route.
Here, the problem would be on the control of packet distribution:
decide how to split traffic, deal with reordering and buffering…
which are orthogonal, and tricky, problems to the path establishment,
i.e. orthogonal problems to MIP
I fully agree.
Alex
Pierrick
*De :*Hui Deng [mailto:deng...@chinamobile.com] *Envoyé :* mardi 28
octobre 2014 16:10 *À :* 'Sri Gundavelli (sgundave)'; 'Xueli'; SEITE
Pierrick IMT/OLN; 'Ted Lemon'; 'STARK, BARBARA H' *Cc :* mif@ietf.org
*Objet :* RE: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement,
"Broadband For um Work on ³Hybrid Access for Broadband Networks²
(WT-348)"
Hi Sri,
Could you split one session into two different path?
Thanks
-Hui
*From:*mif [mailto:mif-boun...@ietf.org] *On Behalf Of *Sri
Gundavelli (sgundave) *Sent:* Tuesday, October 28, 2014 10:41 PM
*To:* Xueli; pierrick.se...@orange.com; Ted Lemon; STARK, BARBARA H
*Cc:* mif@ietf.org *Subject:* Re: [mif] [DMM] RE: [homenet] Fwd: New
Liaison Statement, "Broadband For um Work on ³Hybrid Access for
Broadband Networks² (WT-348)"
*** Trimming the CC list to include only the MIF WG; Removed DMM and
homenet lists.
HI Li,
To you question on the Problem Statement that the MIP technologies
have addressed, I'd say its the following.
In general, all the Mobile IP class of protocols have support for
access-link bonding. The ability for the anchor and the access
gateway (or the anchor and the mobile node) to establish multiple
overlay tunnels paths over different access networks, and to
negotiate Application-to-Access routing policy is present in those
technologies.
Let me know if you believe this does not meet the requirement.
Flow-1
|
|Flow-2
| |
| |Flow-3 _----_
| | | CoA-1 _( )_ Tunnel-1
| | | .---=======( Wi-Fi )========\ Flow-1
| | | | (_ _) \
| | | | '----' \
| | | +=====+ _----_ \ +=====+ _----_
| | '-| | CoA-2 _( )_ Tunnel-2 \ | | _( )_ --
| '---| MN |---====( LTE )=========-----| HA |-( Internet )--
'-----| | (_ _) Flow-3 / | | (_ _) --
+=====+ '----' / +=====+ '----'
| | _----_ /
HoA-1--' | CoA-3 _( )_ Tunnel-3 /
.------====( CDMA )========/ Flow-2
(_ _)
'----'
Regards
Sri
*From: *Xueli <xu...@huawei.com <mailto:xu...@huawei.com>> *Date:
*Monday, October 27, 2014 9:04 PM *To: *Sri Gundavelli
<sgund...@cisco.com <mailto:sgund...@cisco.com>>,
"pierrick.se...@orange.com <mailto:pierrick.se...@orange.com>"
<pierrick.se...@orange.com <mailto:pierrick.se...@orange.com>>, Ted
Lemon <ted.le...@nominum.com <mailto:ted.le...@nominum.com>>,
"STARK, BARBARA H" <bs7...@att.com <mailto:bs7...@att.com>> *Cc:
*HOMENET Working Group <home...@ietf.org <mailto:home...@ietf.org>>,
"mif@ietf.org <mailto:mif@ietf.org>" <mif@ietf.org
<mailto:mif@ietf.org>>, "d...@ietf.org <mailto:d...@ietf.org>"
<d...@ietf.org <mailto:d...@ietf.org>> *Subject: *RE: [DMM] RE:
[homenet] Fwd: New Liaison Statement, "Broadband For um Work on
³Hybrid Access for Broadband Networks² (WT-348)"
Hello Sri
Thanks for the comments. Just some clarification for the cross
email.
A new version about the architecture is uploaded..
http://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-architecture-01.txt
There are some new requirements about the hybrid access topic, such
as bonding, traffic policy distribution etc.
Do you mind to share more additional technologies about the existing
protocols solution for hybrid access.
Which exact issues it is really solving, in order to evaluate if the
existing solutions properly solve this use case?
Best Regards
Li
*From:*Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] *Sent:*
Wednesday, October 22, 2014 6:56 PM *To:* pierrick.se...@orange.com
<mailto:pierrick.se...@orange.com>; Xueli; Ted Lemon; STARK, BARBARA
H *Cc:* HOMENET Working Group; mif@ietf.org <mailto:mif@ietf.org>;
d...@ietf.org <mailto:d...@ietf.org> *Subject:* Re: [DMM] RE:
[homenet] Fwd: New Liaison Statement, "Broadband For um Work on
³Hybrid Access for Broadband Networks² (WT-348)"
<We probably should not be cross posting the mail to three WG
mailers, but I will respond to this one last email>
Hi Li,
While the term "hybrid-access" sounds fresh and new, but its
important to understand that this is largely a use-case around
mobile networks. Per my comments in the last HOMENET meeting,
mobility working groups have defined solutions for this multi-access
use-case. There are clearly mechanisms that allow network entities to
negotiate flow policies and switch traffic on application basis. The
access can be LTE, WLAN, SatRAN, Fixed line ..etc, but the negotiated
policies allow the peers to agree on binding a flow to a given
access. Wearing cisco vendor hat, we have deployed solutions for this
use-case for the last decade. So, I agree with the BBF use-case and I
think we should probably draft a BCP-type solution document,
explaining BBF on the tools that are available for addressing this
issue. If there are minor gaps, we should certainly propose
extensions to the protocols.
As pierrick, I'm also not in favor of defining a control protocol
for GRE as its not needed. GRE is a use-plane protocol and the
semantics that are present in the header are only designed to be used
for adding meta-data related to the IP flows in that tunnel header.
There are no semantics for defining a new signaling layer in a
user-plane protocol. GRE was always used in conjunction with a
signaling protocol and that signaling protocol is IPsec, MIP, PMIP
..and so on. However, you design that control protocol, it will
exactly smell and feel like existing protocols. The aspect around
subscriber identity, authorization, access policy, Traffic flow
template definition …all of this has to be modeled and in the process
we will end up reinventing every thing that we defined over the last
many years, but it will have a new title, "GRE-CP".
Regards
Sri
*From: *"pierrick.se...@orange.com
<mailto:pierrick.se...@orange.com>" <pierrick.se...@orange.com
<mailto:pierrick.se...@orange.com>> *Date: *Wednesday, October 22,
2014 3:05 AM *To: *Xueli <xu...@huawei.com
<mailto:xu...@huawei.com>>, Ted Lemon <ted.le...@nominum.com
<mailto:ted.le...@nominum.com>>, "STARK, BARBARA H" <bs7...@att.com
<mailto:bs7...@att.com>> *Cc: *HOMENET Working Group
<home...@ietf.org <mailto:home...@ietf.org>>, "mif@ietf.org
<mailto:mif@ietf.org>" <mif@ietf.org <mailto:mif@ietf.org>>,
"d...@ietf.org <mailto:d...@ietf.org>" <d...@ietf.org
<mailto:d...@ietf.org>> *Subject: *[DMM]
=?Windows-1252?Q?RE:_[homenet]_Fwd:_New_Liaison_Statement,
_"Broadband_For?= um Work on “Hybrid Access for Broadband Networks”
(WT-348)"
Hi Li,
Architecture considerations and solution design are two different
things, which should not be addressed in the same I-D. People may
agree with the big picture depicture and architecture but not agree
with going on extensions to the GRE protocol to address the issue.
BTW, I think that going for extensions to GRE header to address the
hybrid access use-case is not the right way. Actually, IETF
solutions already exist (RFC 4908 ) and, moreover, there is ongoing
effort in DMM to update RFC 4908 to meet hybrid access requirements.
BR,
Pierrick
*De :*Xueli [mailto:xu...@huawei.com] *Envoyé :* mercredi 22 octobre
2014 11:48 *À :* Ted Lemon; STARK, BARBARA H *Cc :* HOMENET Working
Group; mif@ietf.org <mailto:mif@ietf.org> *Objet :* RE: [homenet]
Fwd: New Liaison Statement, "Broadband Forum Work on “Hybrid Access
for Broadband Networks” (WT-348)"
Hello
Thanks Barbara to send this liaison out.
Hybrid Access network is that Residential gateway (RG, or CPE) is
extended with more than two access lines
(e.g. DSL + LTE) in order to provide higher bandwidth for the
customers. The scenario and architecture are shown as follows
cid:image002.jpg@01CF9A07.BF8CD480
Right now, we have two individual drafts, one for architecture and
requirements, and the other one is for an optional solution.
The draft
(http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architecture-00
; ) proposes the architecture and gap analysis.
The solution draft proposes one option for the solutions,
http://tools.ietf.org/html/draft-heileyli-gre-notifications-00
We did not combine them as one draft, because we believe there may
be other candidates, and we would like to have further discussions
in the related groups and IETF.
We used to present it in Homenet in Toronto.
Now the authors have invited Orange to join this architecture work.
We will send out the new version of these drafts soon.
We are glad to invite the experts for comments.
Best Regards
Li Xue on the co-authors behalf
-----Original Message-----
From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Ted
Lemon
Sent: Wednesday, October 22, 2014 3:05 AM
To: STARK, BARBARA H
Cc: HOMENET Working Group
Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum
Work on “Hybrid Access for Broadband Networks”(WT-348)"
On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H <bs7...@att.com
<mailto:bs7...@att.com>> wrote:
FYI. I made sure they were aware of IETF mif and homenet
activities in this area. I intend to try to prevent having to track
efforts that try to do the same thing in two different ways. But
some of the BBF effort may be focused on what
can be done around "bonding" of multiple interfaces that are under
the control of a single service provider. I don't see this in mif or
homenet.
Thanks. I couldn't really tell what was being proposed from the
Liaison statement, so this information is helpful.
_______________________________________________
homenet mailing list
home...@ietf.org <mailto:home...@ietf.org>
https://www.ietf.org/mailman/listinfo/homenet
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous
avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without
authorisation.
If you have received this email in error, please notify the sender
and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that
have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler a l'expediteur et le
detruire ainsi que les pieces jointes. Les messages electroniques
etant susceptibles d'alteration, Orange decline toute responsabilite
si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law; they should not
be distributed, used or copied without authorisation. If you have
received this email in error, please notify the sender and delete
this message and its attachments. As emails may be altered, Orange
is not liable for messages that have been modified, changed or
falsified. Thank you.
_______________________________________________ mif mailing list
mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
