Re: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Tue, 28 October 2014 16:23 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381961A8AF5 for <mif@ietfa.amsl.com>; Tue, 28 Oct 2014 09:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.21
X-Spam-Level:
X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqTuiLN06SsY for <mif@ietfa.amsl.com>; Tue, 28 Oct 2014 09:23:42 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCC41A903A for <mif@ietf.org>; Tue, 28 Oct 2014 09:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=94170; q=dns/txt; s=iport; t=1414513349; x=1415722949; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=aJ3cmTzhuRWHfVJQCyAZqKq+4moSPssPVu2gnvXw2n8=; b=TtzpuXWHfoZr9UZv2ze3uIqx7anTdMYiMYNaGX53Lj1DeGAT+2N6xs/q a07LHMjP4vy4+UqFpjjgydbH6tCVVkAY8ATllklOqsuQEcqVSHU3oyRs4 ve/tEnhpPE0Xd3xxy5BNJvtfTEVt8+UXluVI8LUltHViIvkQOwsYhpMqT E=;
X-Files: image001.jpg : 9036
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwFAMjBT1StJA2E/2dsb2JhbABTCYJIRlRYBIMCyUmBZgELhndUAhuBARYBAQEBAX2EAgEBAQMBAQEBAhUJAggBPQMLBQcGAQgRAQIBAQEGAQEBCg4BAgQDAgQVAQwCAQsUAwMDCAIEAQ0EAQYDBQ2IHQkNtFqVFgEBAQEBAQEBAQEBAQEBAQEBAQEBAReNO4JsBwkCASQHAgcKDQQGAQIEgnGBVAWPbYIeghKBUAFnGYFeTIRQgTE8gw0FihSHI4IOJoFEbAGBR4EDAQEB
X-IronPort-AV: E=Sophos;i="5.04,803,1406592000"; d="jpg'145?scan'145,208,217,145";a="367189381"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP; 28 Oct 2014 16:22:28 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9SGMSSf006423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 16:22:28 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.11]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 11:22:28 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: "pierrick.seite@orange.com" <pierrick.seite@orange.com>, Hui Deng <denghui@chinamobile.com>, 'Xueli' <xueli@huawei.com>, 'Ted Lemon' <Ted.Lemon@nominum.com>, "'STARK, BARBARA H'" <bs7652@att.com>
Thread-Topic: [mif] [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)"
Thread-Index: AQHP8stdnRToXh1GeE2zpzhQgodzDA==
Date: Tue, 28 Oct 2014 16:22:27 +0000
Message-ID: <D0750F35.174DCF%sgundave@cisco.com>
In-Reply-To: <1692_1414509591_544FB416_1692_1096_1_81C77F07008CA24F9783A98CFD706F71142C02AD@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.218]
Content-Type: multipart/mixed; boundary="_004_D0750F35174DCFsgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/0n-cGFcD1FKbOzZOAd3fHWTozOc
Cc: "mif@ietf.org" <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)"
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Oct 2014 16:23:50 -0000

Hi Hui,

Adding to what Pierrick said.

The IP Flow Mobility support in MIP protocols have the traffic flow policy at the granularity of the flow level. The IETF Transport group in general is not in favor of performing per-packet load balancing; If the links in question have different characteristics then it will kill the application performance; will result in requiring large buffer to handle packet re-ordering. But, if need be, we can turn-on such per-packet load balancing capability, but I'm not sure why any would do that. Some text from MIP specs.



   Most IP devices support the two alternative traffic load-balancing
   schemes, Per-flow and Per-packet load balancing.  These load
   balancing schemes allow the forwarding device to evenly distribute
   traffic based on the criteria of per-packet or on a per-flow basis,
   across all the available equal-cost links through which a destination
   can be reached.  The default forwarding behavior of Per-flow load
   balancing will ensure a given flow always takes the same path and
   will eliminate any packet re-ordering issues and that is critical for
   delay sensitive traffic.  Whereas the per-destination load balancing
   scheme leverages all the paths much more affectively, but with the
   potential issue of packet re-ordering on the receiver end.  A host
   can choose to enable any of these approaches.


Regards
Sri



From: "pierrick.seite@orange.com<mailto:pierrick.seite@orange.com>" <pierrick.seite@orange.com<mailto:pierrick.seite@orange.com>>
Date: Tuesday, October 28, 2014 8:19 AM
To: Hui Deng <denghui@chinamobile.com<mailto:denghui@chinamobile.com>>, Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>, 'Xueli' <xueli@huawei.com<mailto:xueli@huawei.com>>, 'Ted Lemon' <Ted.Lemon@nominum.com<mailto:Ted.Lemon@nominum.com>>, "'STARK, BARBARA H'" <bs7652@att.com<mailto:bs7652@att.com>>
Cc: "mif@ietf.org<mailto:mif@ietf.org>" <mif@ietf.org<mailto: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)"

Hi Hui,

Thus current way to use MIP is to bind an IP flow to one path. However, MIP deals only with path establishment and flow policy negotiations but not on traffic management.  So, once multiple overlay tunnels are established, nothing prevent to split one flow on theses paths. 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

Pierrick

De : Hui Deng [mailto:denghui@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<mailto: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-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, October 28, 2014 10:41 PM
To: Xueli; pierrick.seite@orange.com<mailto:pierrick.seite@orange.com>; Ted Lemon; STARK, BARBARA H
Cc: mif@ietf.org<mailto: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 <xueli@huawei.com<mailto:xueli@huawei.com>>
Date: Monday, October 27, 2014 9:04 PM
To: Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>, "pierrick.seite@orange.com<mailto:pierrick.seite@orange.com>" <pierrick.seite@orange.com<mailto:pierrick.seite@orange.com>>, Ted Lemon <Ted.Lemon@nominum.com<mailto:Ted.Lemon@nominum.com>>, "STARK, BARBARA H" <bs7652@att.com<mailto:bs7652@att.com>>
Cc: HOMENET Working Group <homenet@ietf.org<mailto:homenet@ietf.org>>, "mif@ietf.org<mailto:mif@ietf.org>" <mif@ietf.org<mailto:mif@ietf.org>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@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:sgundave@cisco.com]
Sent: Wednesday, October 22, 2014 6:56 PM
To: pierrick.seite@orange.com<mailto:pierrick.seite@orange.com>; Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; mif@ietf.org<mailto:mif@ietf.org>; dmm@ietf.org<mailto:dmm@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.seite@orange.com<mailto:pierrick.seite@orange.com>" <pierrick.seite@orange.com<mailto:pierrick.seite@orange.com>>
Date: Wednesday, October 22, 2014 3:05 AM
To: Xueli <xueli@huawei.com<mailto:xueli@huawei.com>>, Ted Lemon <Ted.Lemon@nominum.com<mailto:Ted.Lemon@nominum.com>>, "STARK, BARBARA H" <bs7652@att.com<mailto:bs7652@att.com>>
Cc: HOMENET Working Group <homenet@ietf.org<mailto:homenet@ietf.org>>, "mif@ietf.org<mailto:mif@ietf.org>" <mif@ietf.org<mailto:mif@ietf.org>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@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:xueli@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-bounces@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 <bs7652@att.com<mailto:bs7652@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

homenet@ietf.org<mailto:homenet@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.