From nobody Mon Nov 3 09:52:00 2014 Return-Path: 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 A6AA01A1BE4; Mon, 3 Nov 2014 09:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no 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 RcYffD8XcWQd; Mon, 3 Nov 2014 09:51:54 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D0C1A6F38; Mon, 3 Nov 2014 09:51:51 -0800 (PST) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0Md5N6-1XT8RL0lhS-00IDGh; Mon, 03 Nov 2014 18:51:13 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_B1E229C3-838E-4B49-A944-DEE31057DE29" From: Alper Yegin In-Reply-To: <01FE63842C181246BBE4CF183BD159B449036DFF@nkgeml504-mbx.china.huawei.com> Date: Mon, 3 Nov 2014 19:50:58 +0200 Message-Id: <383C8250-658B-47B9-B836-052ADFD82E79@yegin.org> References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com> <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com> <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com> <01FE63842C181246BBE4CF183BD159B4490350AD@nkgeml504-mbx.china.huawei.com> <31246_1413972312_54478158_31246_662_1_81C77F07008CA24F9783A98CFD706F71142BD145@PEXCVZYM12.corporate.adroot.infra.ftgroup> <01FE63842C181246BBE4CF183BD159B449036DFF@nkgeml504-mbx.china.huawei.com> To: Xueli X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:K1TwgwzCbgYVWv5LaoUJnAQftBjFakIwlRDz90gzyml tmKAF28Ka1SVuxm+QG5q0TtZU7m3qXjc+Jyz3Ya+OEupqGat6U iLf6CRc/in7KYS6jMTUALLo+zfrpzjxQJN+znncq0TLVcqiV1s 7txoLYJEFH781wcCgcSpZ9XRHAsX4KAEmHtWirVzU1GDhUc8YV vvSCUxAJmgx2tdTxpgZWp6+1byK+UQOqMnTxpeTogFqzYyfQPy 9VmZlmJzHfhwOsegGCndL99scHnHFvQr1ZYPEhXR4TaSe4YeoM NhYF0HNR+heWORvo1QtF2hFqwGP03fZTo9i7tkrldx95WX+I62 94egu0pt/DAoeSQ/ibtV3Rurs24E6p/rT6UrkW1sVK5pJsH1Nd 5wbRPf39C1x0A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/mif/ZU2tO-_p4FBvM_RY1xLXfSBWE-U Cc: "mif@ietf.org" , "dmm@ietf.org" , HOMENET Working Group Subject: Re: [mif] =?windows-1252?q?=3D=3FWindows-1252=3FQ=3FRE=3A=5F=5Bhomene?= =?windows-1252?q?t=5D=5FFwd=3A=5FNew=5FLiaison=5FStatement=2C_=5F=22Broad?= =?windows-1252?q?band=5FFor=3F=3D_um_Work_on_=93Hybrid_Access_for_Broadba?= =?windows-1252?q?nd_Networks=94_=28WT-348=29=22?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 17:51:56 -0000 --Apple-Mail=_B1E229C3-838E-4B49-A944-DEE31057DE29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Li, Few comments on the lhwxz-hybrid-access draft: - Even tough the driving use case involves heterogeneous access = networks, the design can be used with homogeneous access networks as = well. It'd be good to acknowledge that, so that the readers don't assume = the applicability is limited to heterogeneous deployments only. - "Hosts in the customer site may connect to the Internet through the = CPE, the 3G/4G network, or both. " You mean, "CPE may be connected to the Internet through DSL, 3G/4G, or = both" - Figure 4 seems to refer to a case where the host is exposed to two = different prefixes. Is this in scope for BBF? I though they wanted to = limit the use case to the one that hides the "duality" from the host. = I.e., host has single prefix/IP address. - "Additionally, the available paths may have different characteristics = in terms of bandwidth, delay, MTU, etc. "cost" as well. Alper On Oct 28, 2014, at 5:59 AM, Xueli wrote: > Hello Pierrick > =20 > First of all, thanks a lot for agree with the big picture depicture = and architecture.. > I am fine to split the architecture considerations and solution design = in two different documents. > And I updated the architecture draft (No specific solution there) in = the new version, I hope it makes sense for you. > = http://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-arch= itecture-01.txt > Do you mind to share more about the solution about DMM proposal. > Which exact issues it is really solving? > =20 > Best Regards > Li > =20 > From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com]=20 > Sent: Wednesday, October 22, 2014 6:05 PM > To: Xueli; Ted Lemon; STARK, BARBARA H > Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org > Subject: RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum = Work on =93Hybrid Access for Broadband Networks=94 (WT-348)" > =20 > Hi Li, > =20 > 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. =20 > =20 > BR, > Pierrick =20 > =20 > De : Xueli [mailto:xueli@huawei.com]=20 > Envoy=E9 : mercredi 22 octobre 2014 11:48 > =C0 : Ted Lemon; STARK, BARBARA H > Cc : HOMENET Working Group; mif@ietf.org > Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum = Work on =93Hybrid Access for Broadband Networks=94 (WT-348)" > =20 > Hello > =20 > 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 > > =20 > 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 =20 > 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. > =20 > 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. > =20 > Best Regards > Li Xue on the co-authors behalf > =20 > =20 > -----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 =93Hybrid Access for Broadband Networks=94 (WT-348)" > =20 > On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H 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. > =20 > Thanks. I couldn't really tell what was being proposed from the = Liaison statement, so this information is helpful. > =20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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 --Apple-Mail=_B1E229C3-838E-4B49-A944-DEE31057DE29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Li,

Few comments on the = lhwxz-hybrid-access draft:

- Even tough the = driving use case involves heterogeneous access networks, the design can = be used with homogeneous access networks as well. It'd be good to = acknowledge that, so that the readers don't assume the applicability is = limited to heterogeneous deployments = only.

-  "Hosts in the = customer site may connect to the Internet through the CPE, the 3G/4G network, or = both. "

You mean, "CPE may be = connected to the Internet through DSL, 3G/4G, or = both"

- Figure 4 seems to refer to a case where = the host is exposed to two different prefixes. Is this in scope for BBF? = I though they wanted to limit the use case to the one that hides the = "duality" from the host. I.e., host has single prefix/IP = address.

- "Additionally, the = available paths may have different characteristics in terms of bandwidth, delay, MTU, = etc.

"cost" as = well.

Alper




On Oct 28, 2014, at 5:59 AM, Xueli = wrote:

Hello = Pierrick
 
First of all, = thanks a lot for agree with the big picture depicture and = architecture..
I am fine to split the architecture considerations = and solution design in two different = documents.
And I updated the architecture draft (No specific = solution there) in the new version, I hope it makes sense for = you.
Do you mind to = share more about the solution about DMM = proposal.
Which exact issues it is really = solving?
 
Best = Regards
Li
 pierrick.seite@orange.com [mailto:pierrick.seite@orange= .com] 
Sent: Wednesday, October 22, 2014 = 6:05 PM
To: Xueli; Ted Lemon; STARK, = BARBARA H
Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org
Subject: RE: [homenet] Fwd: New = Liaison Statement, "Broadband Forum Work on =93Hybrid Access for = Broadband Networks=94 (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=E9 : mercredi 22 octobre 2014 = 11:48
=C0 : Ted Lemon; STARK, BARBARA = H
Cc : HOMENET Working Group; mif@ietf.org
Objet : RE: [homenet] Fwd: New = Liaison Statement, "Broadband Forum Work on =93Hybrid Access for = Broadband Networks=94 (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
<image001.jpg>
 
Right now, we have two individual = drafts, one for architecture and requirements, and the other one is for = an optional solution.
The draft ( ; ) proposes = the architecture and gap analysis.
Now the authors = have invited Orange to join this architecture work. We will send out the = new version of these drafts soon.
Best = Regards
 -----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 =93Hybrid Access for Broadband Networks=94 (WT-348)"
 
> 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
______________________________________________________________=
___________________________________________________________
 
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
, "dmm@ietf.org" , HOMENET Working Group Subject: Re: [mif] =?utf-8?b?PT9XaW5kb3dzLTEyNTI/UT9SRTpfW2hvbWVuZXRdX0Z3ZDpf?= =?utf-8?q?New=5FLiaison=5FStatement=2C_=5F=22Broadband=5FFor=3F=3D_um_Wor?= =?utf-8?q?k_on_=E2=80=9CHybrid_Access_for_Broadband_Networks=E2=80=9D_=28?= =?utf-8?q?WT-348=29=22?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 09:34:45 -0000 --_000_01FE63842C181246BBE4CF183BD159B449039314nkgeml504mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWxwZXINCg0KVGhhbmtzIGZvciByZXZpZXdpbmcgdGhlIGRyYWZ0IGFuZCBuaWNlIGNv bW1lbnRzLg0KDQpQbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW4gbGluZS4NCg0KQmVzdCBSZWdhcmRz DQpMaQ0KDQpGcm9tOiBBbHBlciBZZWdpbiBbbWFpbHRvOmFscGVyLnllZ2luQHllZ2luLm9yZ10N ClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA0LCAyMDE0IDE6NTEgQU0NClRvOiBYdWVsaQ0KQ2M6 IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb207IFRlZCBMZW1vbjsgU1RBUkssIEJBUkJBUkEgSDsg SE9NRU5FVCBXb3JraW5nIEdyb3VwOyBtaWZAaWV0Zi5vcmc7IGRtbUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFttaWZdID0/V2luZG93cy0xMjUyP1E/UkU6X1tob21lbmV0XV9Gd2Q6X05ld19MaWFp c29uX1N0YXRlbWVudCwgXyJCcm9hZGJhbmRfRm9yPz0gdW0gV29yayBvbiDigJxIeWJyaWQgQWNj ZXNzIGZvciBCcm9hZGJhbmQgTmV0d29ya3PigJ0gKFdULTM0OCkiDQoNCkhlbGxvIExpLA0KDQpG ZXcgY29tbWVudHMgb24gdGhlIGxod3h6LWh5YnJpZC1hY2Nlc3MgZHJhZnQ6DQoNCi0gRXZlbiB0 b3VnaCB0aGUgZHJpdmluZyB1c2UgY2FzZSBpbnZvbHZlcyBoZXRlcm9nZW5lb3VzIGFjY2VzcyBu ZXR3b3JrcywgdGhlIGRlc2lnbiBjYW4gYmUgdXNlZCB3aXRoIGhvbW9nZW5lb3VzIGFjY2VzcyBu ZXR3b3JrcyBhcyB3ZWxsLiBJdCdkIGJlIGdvb2QgdG8gYWNrbm93bGVkZ2UgdGhhdCwgc28gdGhh dCB0aGUgcmVhZGVycyBkb24ndCBhc3N1bWUgdGhlIGFwcGxpY2FiaWxpdHkgaXMgbGltaXRlZCB0 byBoZXRlcm9nZW5lb3VzIGRlcGxveW1lbnRzIG9ubHkuDQpbeHVlbGldIEdvb2QgY29tbWVudC4g 4pi6IEkgd2lsbCBhZGQgb25lIHNlbnRlbmNlIHRvIGFja25vd2xlZGdlIHRoYXQgdGhlIGRlc2ln biBjYW4gYmUgdXNlZCBmb3IgdGhlIGhvbW9nZW5lb3VzIGFjY2VzcyBuZXR3b3JrcyBhcyB3ZWxs Lg0KDQotICAiSG9zdHMgaW4gdGhlIGN1c3RvbWVyIHNpdGUgbWF5IGNvbm5lY3QgdG8gdGhlIElu dGVybmV0IHRocm91Z2ggdGhlIENQRSwgdGhlIDNHLzRHIG5ldHdvcmssIG9yIGJvdGguICINCg0K WW91IG1lYW4sICJDUEUgbWF5IGJlIGNvbm5lY3RlZCB0byB0aGUgSW50ZXJuZXQgdGhyb3VnaCBE U0wsIDNHLzRHLCBvciBib3RoIg0KDQpbeHVlbGldIFRoaXMgc2VudGVuY2UgeW91IG1lbnRpb25l ZCBtZWFucyB0aGUg4oCcSE9TVOKAnSBtYXkgYmUgY29ubmVjdGVkIHRvIHRoZSBpbnRlcm5ldCB0 aHJvdWdoIERTTCwgM0cvNEcuLiByYXRoZXIgdGhhbiB0aGUg4oCcQ1BF4oCdLi4NClRoaXMgaG9z dCBpcyB0aGUgc21hcnRwaG9uZSwgd2hpY2ggaXMgdGhlIFNFQ09ORCBIT1NUIGZyb20gdGhlIHRv cCBzaG93biBpbiB0aGUgZmlndXJlIDEuDQpUaGlzIHNtYXJ0cGhvbmUgaGF2ZSB0d28gaW50ZXJm YWNlcywgb25lIGlzIGNlbGx1bGFyIGNvbm5lY3RpbmcgdG8gdGhlIGVOQiwgb25lIGlzIHdpZmkg Y29ubmVjdGluZyB0byB0aGUgaG9tZSByZXNpZGVudGlhbCBnYXRld2F5Lg0KVGhpcyBzbWFydHBo b25lIHdpdGggdHdvIGNvbm5lY3Rpb25zIGlzIG91dCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVu dC4NCkluIGh5YnJpZCBhY2Nlc3Mgd2UgY29uc2lkZXIgaXMg4oCcSW4gbW9zdCBjYXNlcyB0aGUg bWFqb3JpdHkgb2YgdGhlDQogICBob3N0cyBjb25uZWN0cyB0byB0aGUgSW50ZXJuZXQgdGhyb3Vn aCB0aGUgQ1BFIG9ubHnigJ0NCg0KcHM6IEkgcmVjZWl2ZWQgb25lIGNvbW1lbnQgaW4gdGhlIGxp c3Qgc2FpZCwgdGhlIHNtYXJ0cGhvbmUgY2FuIGhhdmUgY2VsbHVhcit3aWZpIGZvciBoaWdoZXIg YmFuZHdpZHRoLg0KSSBwbGFubmVkIHRvIGNsYXJpZmllZCB0aGUgZXhpc3RpbmcgY2FzZSB3ZSBo YXZlIGF0IGhvbWUgbm93LCB0aGVuIGNsYXJpZnkgdGhlIHNjb3BlIG9mIHRoZSB0b3BpYy4NCg0K RG8gSSBjbGFyaWZ5IHRoaXM/ICBJZiB5b3UgaGF2ZSBiZXR0ZXIgc3VnZ2VzdGlvbiwgSSBjYW4g cmV2aXNlIGl0Lg0KDQotIEZpZ3VyZSA0IHNlZW1zIHRvIHJlZmVyIHRvIGEgY2FzZSB3aGVyZSB0 aGUgaG9zdCBpcyBleHBvc2VkIHRvIHR3byBkaWZmZXJlbnQgcHJlZml4ZXMuIElzIHRoaXMgaW4g c2NvcGUgZm9yIEJCRj8gSSB0aG91Z2ggdGhleSB3YW50ZWQgdG8gbGltaXQgdGhlIHVzZSBjYXNl IHRvIHRoZSBvbmUgdGhhdCBoaWRlcyB0aGUgImR1YWxpdHkiIGZyb20gdGhlIGhvc3QuIEkuZS4s IGhvc3QgaGFzIHNpbmdsZSBwcmVmaXgvSVAgYWRkcmVzcy4NClt4dWVsaV0gSW4gQkJGIGJvdGgg SVB2NCBhbmQgSVB2NiBhcmUgY29uc2lkZXJlZC4NCkluIHRoZSBmaWd1cmUgNCB3aGljaCBpcyBv bmUgcG9zc2liaWxpdHkgdG8gcmVzb2x2ZSB0aGUgZG93bnN0cmVhbSB0cmFmZmljIGRpc3RyaWJ1 dGlvbiB3aXRob3V0IEJHVy4uDQpBcyB5b3Ugc2FpZCwgdGhlIEJCRiBtYXkgcHJlZmVyIHRvIGxp bWl0IHRoZSB1c2UgdG8gdGhlIG9uZSB0aGF0IGhpZGVzIHRoZSDigJxkdWFsaXR54oCdIGZyb20g dGhlIGhvc3QuDQpJdCBtYXkgYmUgb3V0IHRoZSBzY29wZSBmb3IgbGF0ZXIgc29sdXRpb25zIGRl c2lnbi4NCkkgY2xhcmlmaWVkIGFsbCB0aGUgY2FzZSB3aGljaCBjYW4gd29yay4gV2UgbWF5IGNv bnNpZGVyIHRoZSBzY2VuYXJpbyB3aXRoIEJHVyB0byB3b3JrIHRvZ2V0aGVyIHdpdGggQ1BFDQoN Ci0gIkFkZGl0aW9uYWxseSwgdGhlIGF2YWlsYWJsZSBwYXRocyBtYXkgaGF2ZSBkaWZmZXJlbnQg Y2hhcmFjdGVyaXN0aWNzIGluIHRlcm1zIG9mIGJhbmR3aWR0aCwgZGVsYXksIE1UVSwgZXRjLg0K DQoiY29zdCIgYXMgd2VsbC4NClt4dWVsaV0gd2hhdCBpcyB0aGUgbWVhbmluZyBvZiBDT1NUIGhl cmU/IFRoZSBwcmlvcml0eSBvZiBEU0wgb3IgTFRFPw0KDQpBbHBlcg0KDQoNCg0KDQpPbiBPY3Qg MjgsIDIwMTQsIGF0IDU6NTkgQU0sIFh1ZWxpIHdyb3RlOg0KDQoNCkhlbGxvIFBpZXJyaWNrDQoN CkZpcnN0IG9mIGFsbCwgdGhhbmtzIGEgbG90IGZvciBhZ3JlZSB3aXRoIHRoZSBiaWcgcGljdHVy ZSBkZXBpY3R1cmUgYW5kIGFyY2hpdGVjdHVyZS4uDQpJIGFtIGZpbmUgdG8gc3BsaXQgdGhlIGFy Y2hpdGVjdHVyZSBjb25zaWRlcmF0aW9ucyBhbmQgc29sdXRpb24gZGVzaWduIGluIHR3byBkaWZm ZXJlbnQgZG9jdW1lbnRzLg0KQW5kIEkgdXBkYXRlZCB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0IChO byBzcGVjaWZpYyBzb2x1dGlvbiB0aGVyZSkgaW4gdGhlIG5ldyB2ZXJzaW9uLCBJIGhvcGUgaXQg bWFrZXMgc2Vuc2UgZm9yIHlvdS4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWxod3h6LWh5YnJpZC1hY2Nlc3MtbmV0d29yay1hcmNoaXRlY3R1cmUtMDEudHh0DQpE byB5b3UgbWluZCB0byBzaGFyZSBtb3JlIGFib3V0IHRoZSBzb2x1dGlvbiBhYm91dCBETU0gcHJv cG9zYWwuDQpXaGljaCBleGFjdCBpc3N1ZXMgaXQgaXMgcmVhbGx5IHNvbHZpbmc/DQoNCkJlc3Qg UmVnYXJkcw0KTGkNCg0KRnJvbTogcGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbTxtYWlsdG86cGll cnJpY2suc2VpdGVAb3JhbmdlLmNvbT4gW21haWx0bzpwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29t XQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIyLCAyMDE0IDY6MDUgUE0NClRvOiBYdWVsaTsg VGVkIExlbW9uOyBTVEFSSywgQkFSQkFSQSBIDQpDYzogSE9NRU5FVCBXb3JraW5nIEdyb3VwOyBt aWZAaWV0Zi5vcmc8bWFpbHRvOm1pZkBpZXRmLm9yZz47IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1t QGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtob21lbmV0XSBGd2Q6IE5ldyBMaWFpc29uIFN0YXRl bWVudCwgIkJyb2FkYmFuZCBGb3J1bSBXb3JrIG9uIOKAnEh5YnJpZCBBY2Nlc3MgZm9yIEJyb2Fk YmFuZCBOZXR3b3Jrc+KAnSAoV1QtMzQ4KSINCg0KSGkgTGksDQoNCkFyY2hpdGVjdHVyZSBjb25z aWRlcmF0aW9ucyBhbmQgc29sdXRpb24gZGVzaWduIGFyZSB0d28gZGlmZmVyZW50IHRoaW5ncywg d2hpY2ggc2hvdWxkIG5vdCBiZSBhZGRyZXNzZWQgaW4gdGhlIHNhbWUgSS1ELiBQZW9wbGUgbWF5 IGFncmVlIHdpdGggdGhlIGJpZyBwaWN0dXJlIGRlcGljdHVyZSBhbmQgYXJjaGl0ZWN0dXJlIGJ1 dCBub3QgYWdyZWUgd2l0aCBnb2luZyBvbiBleHRlbnNpb25zIHRvIHRoZSBHUkUgcHJvdG9jb2wg dG8gYWRkcmVzcyB0aGUgaXNzdWUuIEJUVywgSSB0aGluayB0aGF0IGdvaW5nIGZvciBleHRlbnNp b25zIHRvIEdSRSBoZWFkZXIgdG8gYWRkcmVzcyB0aGUgaHlicmlkIGFjY2VzcyB1c2UtY2FzZSBp cyBub3QgdGhlIHJpZ2h0IHdheS4gQWN0dWFsbHksIElFVEYgc29sdXRpb25zIGFscmVhZHkgZXhp c3QgKFJGQyAgNDkwOCApIGFuZCwgbW9yZW92ZXIsIHRoZXJlIGlzIG9uZ29pbmcgZWZmb3J0IGlu IERNTSB0byB1cGRhdGUgUkZDIDQ5MDggdG8gbWVldCBoeWJyaWQgYWNjZXNzIHJlcXVpcmVtZW50 cy4NCg0KQlIsDQpQaWVycmljaw0KDQpEZSA6IFh1ZWxpIFttYWlsdG86eHVlbGlAaHVhd2VpLmNv bV0NCkVudm95w6kgOiBtZXJjcmVkaSAyMiBvY3RvYnJlIDIwMTQgMTE6NDgNCsOAIDogVGVkIExl bW9uOyBTVEFSSywgQkFSQkFSQSBIDQpDYyA6IEhPTUVORVQgV29ya2luZyBHcm91cDsgbWlmQGll dGYub3JnPG1haWx0bzptaWZAaWV0Zi5vcmc+DQpPYmpldCA6IFJFOiBbaG9tZW5ldF0gRndkOiBO ZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJCcm9hZGJhbmQgRm9ydW0gV29yayBvbiDigJxIeWJyaWQg QWNjZXNzIGZvciBCcm9hZGJhbmQgTmV0d29ya3PigJ0gKFdULTM0OCkiDQoNCkhlbGxvDQoNClRo YW5rcyBCYXJiYXJhIHRvIHNlbmQgdGhpcyBsaWFpc29uIG91dC4NCkh5YnJpZCBBY2Nlc3MgbmV0 d29yayBpcyB0aGF0IFJlc2lkZW50aWFsIGdhdGV3YXkgKFJHLCBvciBDUEUpIGlzIGV4dGVuZGVk IHdpdGggbW9yZSB0aGFuIHR3byBhY2Nlc3MgbGluZXMNCihlLmcuIERTTCArIExURSkgaW4gb3Jk ZXIgdG8gcHJvdmlkZSBoaWdoZXIgYmFuZHdpZHRoIGZvciB0aGUgY3VzdG9tZXJzLiBUaGUgc2Nl bmFyaW8gYW5kIGFyY2hpdGVjdHVyZSBhcmUgc2hvd24gYXMgZm9sbG93cw0KPGltYWdlMDAxLmpw Zz4NCg0KUmlnaHQgbm93LCB3ZSBoYXZlIHR3byBpbmRpdmlkdWFsIGRyYWZ0cywgb25lIGZvciBh cmNoaXRlY3R1cmUgYW5kIHJlcXVpcmVtZW50cywgYW5kIHRoZSBvdGhlciBvbmUgaXMgZm9yIGFu IG9wdGlvbmFsIHNvbHV0aW9uLg0KVGhlIGRyYWZ0IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1saHd4ei1oeWJyaWQtYWNjZXNzLW5ldHdvcmstYXJjaGl0ZWN0dXJlLTAwIDsgKSBw cm9wb3NlcyB0aGUgYXJjaGl0ZWN0dXJlIGFuZCBnYXAgYW5hbHlzaXMuDQpUaGUgc29sdXRpb24g ZHJhZnQgcHJvcG9zZXMgb25lIG9wdGlvbiBmb3IgdGhlIHNvbHV0aW9ucywgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaGVpbGV5bGktZ3JlLW5vdGlmaWNhdGlvbnMtMDANCldlIGRp ZCBub3QgY29tYmluZSB0aGVtIGFzIG9uZSBkcmFmdCwgYmVjYXVzZSB3ZSBiZWxpZXZlIHRoZXJl IG1heSBiZSBvdGhlciBjYW5kaWRhdGVzLCBhbmQgd2Ugd291bGQgbGlrZSB0byBoYXZlIGZ1cnRo ZXIgZGlzY3Vzc2lvbnMgaW4gdGhlIHJlbGF0ZWQgZ3JvdXBzIGFuZCBJRVRGLg0KV2UgdXNlZCB0 byBwcmVzZW50IGl0IGluIEhvbWVuZXQgaW4gVG9yb250by4NCg0KTm93IHRoZSBhdXRob3JzIGhh dmUgaW52aXRlZCBPcmFuZ2UgdG8gam9pbiB0aGlzIGFyY2hpdGVjdHVyZSB3b3JrLiBXZSB3aWxs IHNlbmQgb3V0IHRoZSBuZXcgdmVyc2lvbiBvZiB0aGVzZSBkcmFmdHMgc29vbi4NCldlIGFyZSBn bGFkIHRvIGludml0ZSB0aGUgZXhwZXJ0cyBmb3IgY29tbWVudHMuDQoNCkJlc3QgUmVnYXJkcw0K TGkgWHVlIG9uIHRoZSBjby1hdXRob3JzIGJlaGFsZg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBob21lbmV0IFttYWlsdG86aG9tZW5ldC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgVGVkIExlbW9uDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjIsIDIwMTQg MzowNSBBTQ0KVG86IFNUQVJLLCBCQVJCQVJBIEgNCkNjOiBIT01FTkVUIFdvcmtpbmcgR3JvdXAN ClN1YmplY3Q6IFJlOiBbaG9tZW5ldF0gRndkOiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJCcm9h ZGJhbmQgRm9ydW0gV29yayBvbiDigJxIeWJyaWQgQWNjZXNzIGZvciBCcm9hZGJhbmQgTmV0d29y a3PigJ0gKFdULTM0OCkiDQoNCk9uIE9jdCAyMSwgMjAxNCwgYXQgMjo1NSBQTSwgU1RBUkssIEJB UkJBUkEgSCA8YnM3NjUyQGF0dC5jb208bWFpbHRvOmJzNzY1MkBhdHQuY29tPj4gd3JvdGU6DQo+ IEZZSS4gSSBtYWRlIHN1cmUgdGhleSB3ZXJlIGF3YXJlIG9mIElFVEYgbWlmIGFuZCBob21lbmV0 IGFjdGl2aXRpZXMgaW4gdGhpcyBhcmVhLiBJIGludGVuZCB0byB0cnkgdG8gcHJldmVudCBoYXZp bmcgdG8gdHJhY2sgZWZmb3J0cyB0aGF0IHRyeSB0byBkbyB0aGUgc2FtZSB0aGluZyBpbiB0d28g ZGlmZmVyZW50IHdheXMuIEJ1dCBzb21lIG9mIHRoZSBCQkYgZWZmb3J0IG1heSBiZSBmb2N1c2Vk IG9uIHdoYXQgY2FuIGJlIGRvbmUgYXJvdW5kICJib25kaW5nIiBvZiBtdWx0aXBsZSBpbnRlcmZh Y2VzIHRoYXQgYXJlIHVuZGVyIHRoZSBjb250cm9sIG9mIGEgc2luZ2xlIHNlcnZpY2UgcHJvdmlk ZXIuIEkgZG9uJ3Qgc2VlIHRoaXMgaW4gbWlmIG9yIGhvbWVuZXQuDQoNClRoYW5rcy4gICBJIGNv dWxkbid0IHJlYWxseSB0ZWxsIHdoYXQgd2FzIGJlaW5nIHByb3Bvc2VkIGZyb20gdGhlIExpYWlz b24gc3RhdGVtZW50LCBzbyB0aGlzIGluZm9ybWF0aW9uIGlzIGhlbHBmdWwuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpob21lbmV0IG1haWxpbmcg bGlzdA0KaG9tZW5ldEBpZXRmLm9yZzxtYWlsdG86aG9tZW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5ldA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp Lg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptaWYgbWFpbGluZyBsaXN0DQptaWZAaWV0Zi5v cmc8bWFpbHRvOm1pZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWlmDQoNCg== --_000_01FE63842C181246BBE4CF183BD159B449039314nkgeml504mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly8xMDIvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjIgNyA0IDkgMiAy IDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3Nl LTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1 bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47 DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBcOTg4NFw4QkJFXDY4M0NcNUYwRiBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyIsInNlcmlmIjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5h bWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28t c3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBcOTg4NFw4QkJFXDY4M0NcNUYwRiBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgXDk4ODRcOEJCRVw2ODNDXDVGMEYi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUy MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl IiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOy13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTst d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIEFscGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgcmV2aWV3aW5nIHRoZSBkcmFmdCBhbmQg bmljZSBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNl IHNlZSBteSByZXBsaWVzIGluIGxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkJlc3QgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+TGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWxwZXIgWWVnaW4gW21haWx0bzphbHBl ci55ZWdpbkB5ZWdpbi5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIg MDQsIDIwMTQgMTo1MSBBTTxicj4NCjxiPlRvOjwvYj4gWHVlbGk8YnI+DQo8Yj5DYzo8L2I+IHBp ZXJyaWNrLnNlaXRlQG9yYW5nZS5jb207IFRlZCBMZW1vbjsgU1RBUkssIEJBUkJBUkEgSDsgSE9N RU5FVCBXb3JraW5nIEdyb3VwOyBtaWZAaWV0Zi5vcmc7IGRtbUBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW21pZl0gPT9XaW5kb3dzLTEyNTI/UT9SRTpfW2hvbWVuZXRdX0Z3ZDpf TmV3X0xpYWlzb25fU3RhdGVtZW50LCBfJnF1b3Q7QnJvYWRiYW5kX0Zvcj89IHVtIFdvcmsgb24g 4oCcSHlicmlkIEFjY2VzcyBmb3IgQnJvYWRiYW5kIE5ldHdvcmtz4oCdIChXVC0zNDgpJnF1b3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8gTGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RmV3IGNvbW1lbnRzIG9uIHRoZSBsaHd4ei1o eWJyaWQtYWNjZXNzIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+LSBFdmVuIHRvdWdoIHRoZSBkcml2aW5nIHVzZSBjYXNlIGludm9sdmVzIGhl dGVyb2dlbmVvdXMgYWNjZXNzIG5ldHdvcmtzLCB0aGUgZGVzaWduIGNhbiBiZSB1c2VkIHdpdGgg aG9tb2dlbmVvdXMgYWNjZXNzIG5ldHdvcmtzIGFzIHdlbGwuIEl0J2QgYmUgZ29vZCB0byBhY2tu b3dsZWRnZSB0aGF0LCBzbyB0aGF0IHRoZSByZWFkZXJzIGRvbid0IGFzc3VtZSB0aGUgYXBwbGlj YWJpbGl0eQ0KIGlzIGxpbWl0ZWQgdG8gaGV0ZXJvZ2VuZW91cyBkZXBsb3ltZW50cyBvbmx5Ljwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5beHVlbGldIEdvb2QgY29tbWVudC4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPko8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4gSSB3aWxsIGFkZCBvbmUgc2VudGVuY2UgdG8gYWNrbm93bGVkZ2UgdGhh dCB0aGUgZGVzaWduIGNhbiBiZSB1c2VkIGZvcg0KIHRoZSBob21vZ2VuZW91cyBhY2Nlc3MgbmV0 d29ya3MgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPi0mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVy Ij4mbmJzcDsmcXVvdDtIb3N0cyBpbiB0aGUgY3VzdG9tZXIgc2l0ZSBtYXkgY29ubmVjdCB0byB0 aGUgSW50ZXJuZXQgdGhyb3VnaCB0aGUmbmJzcDtDUEUsIHRoZSAzRy80RyBuZXR3b3JrLCBvciBi b3RoLjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZxdW90Ozwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WW91IG1lYW4sICZxdW90O0NQRSBtYXkg YmUgY29ubmVjdGVkIHRvIHRoZSBJbnRlcm5ldCB0aHJvdWdoIERTTCwgM0cvNEcsIG9yIGJvdGgm cXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5beHVlbGldIFRoaXMgc2VudGVuY2UgeW91IG1lbnRpb25lZCBtZWFucyB0aGUg 4oCcSE9TVOKAnSBtYXkgYmUgY29ubmVjdGVkIHRvIHRoZSBpbnRlcm5ldCB0aHJvdWdoIERTTCwg M0cvNEcuLiByYXRoZXIgdGhhbiB0aGUg4oCcQ1BF4oCdLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaG9zdCBpcyB0aGUgc21hcnRwaG9uZSwgd2hpY2gg aXMgdGhlIFNFQ09ORCBIT1NUIGZyb20gdGhlIHRvcCBzaG93biBpbiB0aGUgZmlndXJlIDEuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIHNtYXJ0cGhvbmUg aGF2ZSB0d28gaW50ZXJmYWNlcywgb25lIGlzIGNlbGx1bGFyIGNvbm5lY3RpbmcgdG8gdGhlIGVO Qiwgb25lIGlzIHdpZmkgY29ubmVjdGluZyB0byB0aGUgaG9tZSByZXNpZGVudGlhbCBnYXRld2F5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBzbWFydHBo b25lIHdpdGggdHdvIGNvbm5lY3Rpb25zIGlzIG91dCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JbiBoeWJyaWQgYWNjZXNzIHdlIGNvbnNpZGVyIGlzIOKAnDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 U2ltU3VuIj5JbiBtb3N0IGNhc2VzDQogdGhlIG1ham9yaXR5IG9mIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOyZuYnNwOyBob3N0cyBj b25uZWN0cyB0byB0aGUgSW50ZXJuZXQgdGhyb3VnaCB0aGUgQ1BFIG9ubHk8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJ08L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cHM6IEkgcmVjZWl2ZWQgb25lIGNvbW1lbnQgaW4g dGhlIGxpc3Qgc2FpZCwgdGhlIHNtYXJ0cGhvbmUgY2FuIGhhdmUgY2VsbHVhciYjNDM7d2lmaSBm b3IgaGlnaGVyIGJhbmR3aWR0aC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSBwbGFubmVkIHRvIGNsYXJpZmllZCB0aGUgZXhpc3RpbmcgY2FzZSB3ZSBoYXZl IGF0IGhvbWUgbm93LCB0aGVuIGNsYXJpZnkgdGhlIHNjb3BlIG9mIHRoZSB0b3BpYy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG8gSSBjbGFyaWZ5IHRoaXM/ICZuYnNwO0lm IHlvdSBoYXZlIGJldHRlciBzdWdnZXN0aW9uLCBJIGNhbiByZXZpc2UgaXQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIEZpZ3VyZSA0IHNlZW1zIHRv IHJlZmVyIHRvIGEgY2FzZSB3aGVyZSB0aGUgaG9zdCBpcyBleHBvc2VkIHRvIHR3byBkaWZmZXJl bnQgcHJlZml4ZXMuIElzIHRoaXMgaW4gc2NvcGUgZm9yIEJCRj8gSSB0aG91Z2ggdGhleSB3YW50 ZWQgdG8gbGltaXQgdGhlIHVzZSBjYXNlIHRvIHRoZSBvbmUgdGhhdCBoaWRlcyB0aGUgJnF1b3Q7 ZHVhbGl0eSZxdW90OyBmcm9tIHRoZSBob3N0LiBJLmUuLCBob3N0DQogaGFzIHNpbmdsZSBwcmVm aXgvSVAgYWRkcmVzcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W3h1ZWxpXSBJbiBCQkYgYm90aCBJUHY0IGFuZCBJ UHY2IGFyZSBjb25zaWRlcmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JbiB0aGUgZmlndXJlIDQgd2hpY2ggaXMgb25lIHBvc3NpYmlsaXR5IHRvIHJlc29s dmUgdGhlIGRvd25zdHJlYW0gdHJhZmZpYyBkaXN0cmlidXRpb24gd2l0aG91dCBCR1cuLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyB5b3Ugc2FpZCwgdGhl IEJCRiBtYXkgcHJlZmVyIHRvIGxpbWl0IHRoZSB1c2UgdG8gdGhlIG9uZSB0aGF0IGhpZGVzIHRo ZSDigJxkdWFsaXR54oCdIGZyb20gdGhlIGhvc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JdCBtYXkgYmUgb3V0IHRoZSBzY29wZSBmb3IgbGF0ZXIgc29sdXRp b25zIGRlc2lnbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg Y2xhcmlmaWVkIGFsbCB0aGUgY2FzZSB3aGljaCBjYW4gd29yay4gV2UgbWF5IGNvbnNpZGVyIHRo ZSBzY2VuYXJpbyB3aXRoIEJHVyB0byB3b3JrIHRvZ2V0aGVyIHdpdGggQ1BFPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tICZxdW90Ozwvc3Bhbj48c3Bh biBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPkFkZGl0aW9uYWxseSwgdGhlIGF2YWls YWJsZSBwYXRocyBtYXkgaGF2ZSBkaWZmZXJlbnQmbmJzcDtjaGFyYWN0ZXJpc3RpY3MgaW4gdGVy bXMgb2YgYmFuZHdpZHRoLCBkZWxheSwgTVRVLCBldGMuPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mcXVvdDtjb3N0JnF1b3Q7IGFzIHdlbGwuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlt4dWVsaV0gd2hhdCBpcyB0 aGUgbWVhbmluZyBvZiBDT1NUIGhlcmU/IFRoZSBwcmlvcml0eSBvZiBEU0wgb3IgTFRFPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxwZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+T24gT2N0IDI4LCAyMDE0LCBhdCA1OjU5IEFNLCBYdWVsaSB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6 aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIFBpZXJyaWNrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlk ZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpcnN0IG9m IGFsbCwgdGhhbmtzIGEgbG90IGZvciBhZ3JlZSB3aXRoIHRoZSBiaWcgcGljdHVyZSBkZXBpY3R1 cmUgYW5kIGFyY2hpdGVjdHVyZS4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IGFtIGZpbmUgdG8gc3BsaXQgdGhlIGFyY2hpdGVjdHVyZSBjb25zaWRlcmF0aW9ucyBhbmQgc29s dXRpb24gZGVzaWduIGluIHR3byBkaWZmZXJlbnQNCiBkb2N1bWVudHMuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BbmQgSSB1cGRhdGVkIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQg KE5vIHNwZWNpZmljIHNvbHV0aW9uIHRoZXJlKSBpbiB0aGUgbmV3IHZlcnNpb24sIEkNCiBob3Bl IGl0IG1ha2VzIHNlbnNlIGZvciB5b3UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFw aCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGh3eHotaHlicmlkLWFjY2Vz cy1uZXR3b3JrLWFyY2hpdGVjdHVyZS0wMS50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWxod3h6LWh5YnJpZC1hY2Nlc3MtbmV0d29yay1hcmNoaXRlY3R1cmUt MDEudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EbyB5 b3UgbWluZCB0byBzaGFyZSBtb3JlIGFib3V0IHRoZSBzb2x1dGlvbiBhYm91dCBETU0gcHJvcG9z YWwuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWdu Omp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGljaCBleGFjdCBpc3N1ZXMg aXQgaXMgcmVhbGx5IHNvbHZpbmc/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxp Z246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkczwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXIt aWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM5OTMzNjYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY207Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRv OnBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20iPnBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb208L2E+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlttYWlsdG86 cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbV08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgT2N0b2JlciAyMiwgMjAxNCA2 OjA1IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5YdWVsaTsgVGVkIExlbW9uOyBTVEFSSywgQkFSQkFSQSBIPGJyPg0KPGI+ Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5I T01FTkVUIFdvcmtpbmcgR3JvdXA7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmciPm1pZkBpZXRmLm9yZzwv YT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6 IFtob21lbmV0XSBGd2Q6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgJnF1b3Q7QnJvYWRiYW5kIEZv cnVtIFdvcmsgb24g4oCcSHlicmlkIEFjY2VzcyBmb3IgQnJvYWRiYW5kIE5ldHdvcmtz4oCdIChX VC0zNDgpJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h bGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTGksPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1q dXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dy YXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFyY2hpdGVjdHVyZSBjb25zaWRlcmF0aW9ucyBhbmQgc29sdXRpb24gZGVzaWduIGFyZSB0 d28gZGlmZmVyZW50IHRoaW5ncywgd2hpY2ggc2hvdWxkDQogbm90IGJlIGFkZHJlc3NlZCBpbiB0 aGUgc2FtZSBJLUQuIFBlb3BsZSBtYXkgYWdyZWUgd2l0aCB0aGUgYmlnIHBpY3R1cmUgZGVwaWN0 dXJlIGFuZCBhcmNoaXRlY3R1cmUgYnV0IG5vdCBhZ3JlZSB3aXRoIGdvaW5nIG9uIGV4dGVuc2lv bnMgdG8gdGhlIEdSRSBwcm90b2NvbCB0byBhZGRyZXNzIHRoZSBpc3N1ZS4gQlRXLCBJIHRoaW5r IHRoYXQgZ29pbmcgZm9yIGV4dGVuc2lvbnMgdG8gR1JFIGhlYWRlciB0byBhZGRyZXNzIHRoZSBo eWJyaWQgYWNjZXNzDQogdXNlLWNhc2UgaXMgbm90IHRoZSByaWdodCB3YXkuIEFjdHVhbGx5LCBJ RVRGIHNvbHV0aW9ucyBhbHJlYWR5IGV4aXN0IChSRkMgJm5ic3A7NDkwOCApIGFuZCwgbW9yZW92 ZXIsIHRoZXJlIGlzIG9uZ29pbmcgZWZmb3J0IGluIERNTSB0byB1cGRhdGUgUkZDIDQ5MDggdG8g bWVldCBoeWJyaWQgYWNjZXNzIHJlcXVpcmVtZW50cy4gJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5 OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBo Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkJSLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGln bjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGllcnJpY2sgJm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3Rp Znk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0O2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjppbml0 aWFsIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItd2lkdGg6aW5pdGlh bDtib3JkZXItY29sb3I6aW5pdGlhbCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+WHVlbGkNCiBbbWFpbHRvOnh1ZWxpQGh1YXdlaS5jb21dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPkVudm95w6kmbmJz cDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5t ZXJjcmVkaSAyMiBvY3RvYnJlIDIwMTQgMTE6NDg8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRlZCBMZW1vbjsgU1RB UkssIEJBUkJBUkEgSDxicj4NCjxiPkNjJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SE9NRU5FVCBXb3JraW5nIEdyb3VwOzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 bWlmQGlldGYub3JnIj5taWZAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogW2hvbWVu ZXRdIEZ3ZDogTmV3IExpYWlzb24gU3RhdGVtZW50LCAmcXVvdDtCcm9hZGJhbmQgRm9ydW0gV29y ayBvbiDigJxIeWJyaWQgQWNjZXNzIGZvciBCcm9hZGJhbmQgTmV0d29ya3PigJ0gKFdULTM0OCkm cXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQt anVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkhlbGxvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBo Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpq dXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rcyBCYXJiYXJhIHRvIHNlbmQgdGhpcyBsaWFpc29u IG91dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkh5YnJpZCBBY2Nlc3MgbmV0d29yayBp cyB0aGF0IFJlc2lkZW50aWFsIGdhdGV3YXkgKFJHLCBvciBDUEUpIGlzIGV4dGVuZGVkIHdpdGgg bW9yZSB0aGFuIHR3byBhY2Nlc3MNCiBsaW5lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5Omlu dGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ KGUuZy4gRFNMICYjNDM7IExURSkgaW4gb3JkZXIgdG8gcHJvdmlkZSBoaWdoZXIgYmFuZHdpZHRo IGZvciB0aGUgY3VzdG9tZXJzLiBUaGUgc2NlbmFyaW8gYW5kIGFyY2hpdGVjdHVyZQ0KIGFyZSBz aG93biBhcyBmb2xsb3dzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBo Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbHQ7aW1hZ2UwMDEu anBnJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0 ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5SaWdodCBub3csIHdlIGhhdmUgdHdvIGluZGl2aWR1YWwgZHJhZnRzLCBv bmUgZm9yIGFyY2hpdGVjdHVyZSBhbmQgcmVxdWlyZW1lbnRzLCBhbmQgdGhlIG90aGVyIG9uZSBp cw0KIGZvciBhbiBvcHRpb25hbCBzb2x1dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlRoZSBkcmFmdCAoPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGh3 eHotaHlicmlkLWFjY2Vzcy1uZXR3b3JrLWFyY2hpdGVjdHVyZS0wMCI+aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbGh3eHotaHlicmlkLWFjY2Vzcy1uZXR3b3JrLWFyY2hpdGVjdHVy ZS0wMDwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ Ow0KICkgcHJvcG9zZXMgdGhlIGFyY2hpdGVjdHVyZSBhbmQgZ2FwIGFuYWx5c2lzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1 c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHNvbHV0aW9uIGRyYWZ0IHByb3Bvc2VzIG9uZSBvcHRp b24gZm9yIHRoZSBzb2x1dGlvbnMsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhl aWxleWxpLWdyZS1ub3RpZmljYXRpb25zLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1oZWlsZXlsaS1ncmUtbm90aWZpY2F0aW9ucy0wMDwvYT48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1 c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5XZSBkaWQgbm90IGNvbWJpbmUgdGhlbSBhcyBvbmUgZHJhZnQsIGJlY2F1c2Ugd2Ug YmVsaWV2ZSB0aGVyZSBtYXkgYmUgb3RoZXIgY2FuZGlkYXRlcywgYW5kIHdlIHdvdWxkDQogbGlr ZSB0byBoYXZlIGZ1cnRoZXIgZGlzY3Vzc2lvbnMgaW4gdGhlIHJlbGF0ZWQgZ3JvdXBzIGFuZCBJ RVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2UgdXNlZCB0byBwcmVzZW50IGl0IGlu IEhvbWVuZXQgaW4gVG9yb250by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVv Z3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFs aWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Tm93IHRoZSBhdXRob3JzIGhhdmUgaW52aXRlZCBP cmFuZ2UgdG8gam9pbiB0aGlzIGFyY2hpdGVjdHVyZSB3b3JrLiBXZSB3aWxsIHNlbmQgb3V0IHRo ZSBuZXcgdmVyc2lvbg0KIG9mIHRoZXNlIGRyYWZ0cyBzb29uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1q dXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+V2UgYXJlIGdsYWQgdG8gaW52aXRlIHRoZSBleHBlcnRzIGZvciBjb21tZW50cy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h bGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+QmVzdCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dy YXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5MaSBYdWUgb24g dGhlIGNvLWF1dGhvcnMgYmVoYWxmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRl b2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h bGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlm eTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206IGhvbWVuZXQgW21haWx0bzpob21lbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBUZWQgTGVtb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3Jh cGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6IFdlZG5l c2RheSwgT2N0b2JlciAyMiwgMjAxNCAzOjA1IEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6 aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5UbzogU1RBUkssIEJBUkJBUkEgSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlk ZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2M6IEhP TUVORVQgV29ya2luZyBHcm91cDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9n cmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDog UmU6IFtob21lbmV0XSBGd2Q6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgJnF1b3Q7QnJvYWRiYW5k IEZvcnVtIFdvcmsgb248c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oCc PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkh5YnJpZA0K IEFjY2VzcyBmb3IgQnJvYWRiYW5kIE5ldHdvcmtzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+4oCdPC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ KFdULTM0OCkmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1 c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gT2N0IDIxLCAyMDE0LCBhdCAyOjU1IFBNLCBTVEFSSywg QkFSQkFSQSBIICZsdDs8YSBocmVmPSJtYWlsdG86YnM3NjUyQGF0dC5jb20iPmJzNzY1MkBhdHQu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dy YXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IEZZSS4g SSBtYWRlIHN1cmUgdGhleSB3ZXJlIGF3YXJlIG9mIElFVEYgbWlmIGFuZCBob21lbmV0IGFjdGl2 aXRpZXMgaW4gdGhpcyBhcmVhLiBJIGludGVuZCB0byB0cnkgdG8NCiBwcmV2ZW50IGhhdmluZyB0 byB0cmFjayBlZmZvcnRzIHRoYXQgdHJ5IHRvIGRvIHRoZSBzYW1lIHRoaW5nIGluIHR3byBkaWZm ZXJlbnQgd2F5cy4gQnV0IHNvbWUgb2YgdGhlIEJCRiBlZmZvcnQgbWF5IGJlIGZvY3VzZWQgb24g d2hhdCBjYW4gYmUgZG9uZSBhcm91bmQgJnF1b3Q7Ym9uZGluZyZxdW90OyBvZiBtdWx0aXBsZSBp bnRlcmZhY2VzIHRoYXQgYXJlIHVuZGVyIHRoZSBjb250cm9sIG9mIGEgc2luZ2xlIHNlcnZpY2Ug cHJvdmlkZXIuIEkgZG9uJ3Qgc2VlDQogdGhpcyBpbiBtaWYgb3IgaG9tZW5ldC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVy LWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhh bmtzLiZuYnNwOyZuYnNwOyBJIGNvdWxkbid0IHJlYWxseSB0ZWxsIHdoYXQgd2FzIGJlaW5nIHBy b3Bvc2VkIGZyb20gdGhlIExpYWlzb24gc3RhdGVtZW50LCBzbyB0aGlzIGluZm9ybWF0aW9uDQog aXMgaGVscGZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3Rp Znk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmhvbWVuZXQgbWFpbGluZyBsaXN0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt YWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86aG9tZW5ldEBpZXRm Lm9yZyI+aG9tZW5ldEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRl ci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5ldCI+PHNw YW4gbGFuZz0iRlIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5l dDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJGUiI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+ T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi PklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoYW5rIHlvdS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KbWlmIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmci Pm1pZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21pZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t aWY8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_01FE63842C181246BBE4CF183BD159B449039314nkgeml504mbxchi_-- From nobody Mon Nov 10 17:08:47 2014 Return-Path: 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 E96341A1BC8 for ; Mon, 10 Nov 2014 17:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 HwL7lQqpIjTO for ; Mon, 10 Nov 2014 17:08:43 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4F01A1AAD for ; Mon, 10 Nov 2014 17:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12882; q=dns/txt; s=iport; t=1415668124; x=1416877724; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CnHmBV8k95mJkKBZZdVIP2Ts1bENcgBvzRlah231vy8=; b=ZOhw3/WGrsgd8EmclIj1mHmJCJHiKn0b3Hd2TfyaVvvVdc1u7TkPQu4q ItZGSRN1jvIrDSyAaunhsbntsBbPlPrGu6n1F8qhZeXEX0OEgSjZ4mkbg yOdjroulCsywackLoIzpZi6oJndOVutNf8Auk4vQSwM7DKmEVuzoX+QKr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAGJgYVStJV2b/2dsb2JhbABcgkhGVFkEu1qOOIFuh08CgR8WAQEBAQF9hAIBAQEELUwQAgEIEQMBAigHIREUCQgCBAENBRuIEQMSDcYxDYZTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF45cghUTEQYBhEsFkjGEU4UPghKBcY1+hnGDemyBSIEDAQEB X-IronPort-AV: E=Sophos; i="5.07,356,1413244800"; d="scan'208,217"; a="95288408" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 11 Nov 2014 01:08:43 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sAB18g94018516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 01:08:42 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.32]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 19:08:42 -0600 From: "Sri Gundavelli (sgundave)" To: "'STARK, BARBARA H'" , Hui Deng Thread-Topic: Follow up with BBF proposal Thread-Index: AQHP/UwID8Bhv/YxaE+5ucazw5UALQ== Date: Tue, 11 Nov 2014 01:08:41 +0000 Message-ID: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> In-Reply-To: <005401cff509$3719eb30$a54dc190$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.69.71] Content-Type: multipart/alternative; boundary="_000_D0869CBD177FDFsgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/jKO4Beii3NED5idt1R7TLwxxLO8 Cc: Brian Haberman , "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 01:08:46 -0000 --_000_D0869CBD177FDFsgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hui, The BBF requirement as presented in the BBF documents and as interpreted in= draft-seite and draft-lhwxz is about enabling a CPE device to attach to mu= ltiple access network and perform flow management. However, I look at it, I= see this this is a mobility requirement and is really not in the scope of = MIF WG. The BBF requirement in question is all about flow switching or flow= splitting across access systems. I'm not sure why this work belongs MIF an= d not DMM which is chartered to handle all mobility use-cases. We have disc= ussed this specific use-case of flow splitting during MIF formation and exp= licitly disallowed MIF WG from taking up such work. The following is the qu= ote from the MIF chartered text. Also, the MIF WG was primarily looking at = issues for a host attached to multiple access networks, but the hybrid acce= ss is about a CPE attached to multiple networks. I really think this work s= hould be done in DMM and we did present the requirements in the last IETF m= eeting. http://datatracker.ietf.org/wg/mif/charter/ No work will be done to enable traffic flows to move from one interface to = another. The group recognizes existing work on mechanisms that require peer= or network support for moving traffic flows such as RFC 5206, RFC 4980 and= the use of multiple care-of addresses in Mobile IPv6. This group does not = work on or impact such mechanisms. Future work in this area requires rechar= tering the working group or asking other, specialized working groups (such = as DHC or 6MAN) to deal with specific issues. Regards Sri From: Hui Deng > Date: Friday, October 31, 2014 4:50 AM To: Sri Gundavelli >, 'Xueli'= >, "pierrick.seite@orange.com" >, 'Ted Lemon' >, "'STARK, BARBARA H'" >, = 'Alexandru Petrescu' > Cc: "mif@ietf.org" > Subject: Follow up with BBF proposal Hi everybody I am recommending that Xue Li could help to put down the slide for the prob= lem statement from BBF. And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly to me= et together during IETF meeting to discuss by adding s thelide about how today solutions meet the requireme= nt or there are some gap still, and whether that problem should be solvable= in IETF. Chairs will talk with AD whether MIF or somewhere else will consider to dis= cuss those issues during the f2f session. Best regards, -Hui --_000_D0869CBD177FDFsgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Hui,

The BBF requirement as presented in the BBF documents and as interpret= ed in draft-seite and draft-lhwxz is about enabling a CPE device to at= tach to multiple access network and perform flow management. However, I loo= k at it, I see this this is a mobility requirement and is really not in the scope of MIF WG. The BBF requirement = in question is all about flow switching or flow splitting across access sys= tems. I'm not sure why this work belongs MIF and not DMM which is chartered= to handle all mobility use-cases. We have discussed this specific use-case of flow splitting during MIF form= ation and explicitly disallowed MIF WG from taking up such work. The follow= ing is the quote from the MIF chartered text. Also, the MIF WG was primaril= y looking at issues for a host attached to multiple access networks, but the hybrid access is about a CPE attached= to multiple networks. I really think this work should be done in DMM and w= e did present the requirements in the last IETF meeting.

No work will be done to enable traffic flows to move from one inter= face to another. The group recognizes existing work on mechanisms that requ= ire peer or network support for moving traffic flows such as RFC 5206, RFC = 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mecha= nisms. Future work in this area requires rechartering the working group or = asking other, specialized working groups (such as DHC or 6MAN) to deal with= specific issues.




Regards
Sri

From: Hui Deng <denghui@chinamobile.com>
Date: Friday, October 31, 2014 4:50= AM
To: Sri Gundavelli <sgundave@cisco.com>, 'Xueli' <xueli@huawei.com>, "pierrick.seite@orange.com" <pierrick.seite@orange.com= >, 'Ted Lemon' <Ted.Lemo= n@nominum.com>, "'STARK, BARBARA H'" <bs7652@att.com>, 'Alexandru Petrescu' <alexandru.petrescu@gmail.com&g= t;
Cc: "mif@ietf.org" <mif@ietf.= org>
Subject: Follow up with BBF proposa= l

Hi ever= ybody

&n= bsp;

I am re= commending that Xue Li could help to put down the slide for the problem sta= tement from BBF.

&n= bsp;

And MIP= /NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly to meet toge= ther during IETF meeting

to disc= uss by adding s thelide about how today solutions meet the requirement or t= here are some gap still, and whether that problem should be solvable in IET= F.

&n= bsp;

Chairs = will talk with AD whether MIF or somewhere else will consider to discuss th= ose issues during the f2f session.

&n= bsp;

Best re= gards,

&n= bsp;

-Hui

 --_000_D0869CBD177FDFsgundaveciscocom_-- From nobody Mon Nov 10 18:00:15 2014 Return-Path: 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 B54351AD3FD for ; Mon, 10 Nov 2014 18:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 xwsEWTWqY_zW for ; Mon, 10 Nov 2014 18:00:01 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9081AD3F7 for ; Mon, 10 Nov 2014 18:00:01 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id E662CDA01AE for ; Tue, 11 Nov 2014 02:04:27 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 609C853E07E; Mon, 10 Nov 2014 17:59:30 -0800 (PST) Received: from nat64.meeting.ietf.org (31.130.238.216) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 10 Nov 2014 17:59:30 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 10 Nov 2014 15:59:23 -1000 Content-Transfer-Encoding: quoted-printable Message-ID: <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> To: "Sri Gundavelli (sgundave)" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.216] Archived-At: http://mailarchive.ietf.org/arch/msg/mif/UxjRN8Oa_PzWrTbjaohXYIai0cw Cc: Brian Haberman , "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:00:04 -0000 On Nov 10, 2014, at 3:08 PM, Sri Gundavelli (sgundave) = wrote: > The BBF requirement as presented in the BBF documents and as = interpreted in draft-seite and draft-lhwxz is about enabling a CPE = device to attach to multiple access network and perform flow management. = However, I look at it, I see this this is a mobility requirement and is = really not in the scope of MIF WG. The BBF requirement in question is = all about flow switching or flow splitting across access systems. I'm = not sure why this work belongs MIF and not DMM which is chartered to = handle all mobility use-cases. We have discussed this specific use-case = of flow splitting during MIF formation and explicitly disallowed MIF WG = from taking up such work. The following is the quote from the MIF = chartered text. Also, the MIF WG was primarily looking at issues for a = host attached to multiple access networks, but the hybrid access is = about a CPE attached to multiple networks. I really think this work = should be done in DMM and we did present the requirements in the last = IETF meeting. It's not at all clear that the way the problem is currently framed is = even correct. I am skeptical that this is a flow splitting/flow = switching problem. I agree that if it is, it doesn't belong in MIF. = But I think it's worthwhile to discuss in MIF, and I think it's also = germane to what homenet is doing. If this does actually require flow = splitting and/or switching, that's going to have some pretty nasty = implications on the home network, so it would be nice to see if there's = a better way to approach the problem. From nobody Mon Nov 10 18:22:45 2014 Return-Path: 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 677331AD44E for ; Mon, 10 Nov 2014 18:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 j_p56FcSbYzN for ; Mon, 10 Nov 2014 18:22:40 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C141AD44A for ; Mon, 10 Nov 2014 18:22:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3057; q=dns/txt; s=iport; t=1415672560; x=1416882160; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7/r3cWEjvAAVesDa2GAKoVlyu1lU33v2yXyjwhM8CbY=; b=B2l4ceJTNOEhEyp7ywlHbxpT994BmtQ6N1tiVHa3AZi/ZAOpvchQeDOi oeHzuhk/4WpaVYcoPqa2HeOzqWwOOBNPq+nDVvSnjGiUIyg/giOb2TCB5 hIXXiFXuP95qzymEXgc4yt7nu2SV6xegHWdSzMX1IQeM10S2VNTaUZxy+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAB1yYVStJV2Y/2dsb2JhbABSCoMOgS0E008CgRwWAQEBAQF9hAMBAQQ6MQcHEAIBCBgeEDIlAgQOBRuIJsx/AQEBAQEBAQEBAQEBAQEBAQEBARmQOVwHhEsFkjGLdJZgg3psgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,357,1413244800"; d="scan'208";a="95354001" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 11 Nov 2014 02:22:40 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sAB2MdvF021868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 02:22:39 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.32]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 20:22:39 -0600 From: "Sri Gundavelli (sgundave)" To: Ted Lemon Thread-Topic: Follow up with BBF proposal Thread-Index: AQHP/VZdDGqgD4+1QES0VCAdxLmWww== Date: Tue, 11 Nov 2014 02:22:39 +0000 Message-ID: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> In-Reply-To: <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.69.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F2B8BB6013E1A4BA8182B937D078E55@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/_QSo6HwhELgGQVftP8gO6HjdP78 Cc: Brian Haberman , "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:22:42 -0000 Hi Ted, Having a discussion in MIF WG sounds reasonable to me. Regarding homenet relation, I'm not sure it belongs to that WG either. The focus of the homenet is on ingress networks and for realizing simplified configurations and that has no relation to access selection on egress paths. FWIW, this work is very much related to what the MIP working group have been doing for many years. Sure, the device in case of BBF is a fixed device, but the fundamental requirements are about access selection, flow mobility and policy exchange. The flow mobility / MCOA work in MIP working groups have done significant amount of work in this area and the expertise is in that group. If the reason for steering this work away from DMM is due the belief that we will apply only MIP-based solution, I'd say the group will certainly do that, but the WG may also agree to additional solution/protocol mechanisms. Also, IETF is in no position to pick one protocol/solution for this requirement. It is probably reasonable for IETF to identify a set of solutions and present analysis on each of the solutions and that can be the basis for the BBF to review and pick one or more solutions. But, either way I believe the expertise around this topic is in DMM WG and not in homenet or in MIF WG's. Regards Sri =20 On 11/10/14 5:59 PM, "Ted Lemon" wrote: >On Nov 10, 2014, at 3:08 PM, Sri Gundavelli (sgundave) > wrote: >> The BBF requirement as presented in the BBF documents and as >>interpreted in draft-seite and draft-lhwxz is about enabling a CPE >>device to attach to multiple access network and perform flow management. >>However, I look at it, I see this this is a mobility requirement and is >>really not in the scope of MIF WG. The BBF requirement in question is >>all about flow switching or flow splitting across access systems. I'm >>not sure why this work belongs MIF and not DMM which is chartered to >>handle all mobility use-cases. We have discussed this specific use-case >>of flow splitting during MIF formation and explicitly disallowed MIF WG >>from taking up such work. The following is the quote from the MIF >>chartered text. Also, the MIF WG was primarily looking at issues for a >>host attached to multiple access networks, but the hybrid access is >>about a CPE attached to multiple networks. I really think this work >>should be done in DMM and we did present the requirements in the last >>IETF meeting. > >It's not at all clear that the way the problem is currently framed is >even correct. I am skeptical that this is a flow splitting/flow >switching problem. I agree that if it is, it doesn't belong in MIF. >But I think it's worthwhile to discuss in MIF, and I think it's also >germane to what homenet is doing. If this does actually require flow >splitting and/or switching, that's going to have some pretty nasty >implications on the home network, so it would be nice to see if there's a >better way to approach the problem. > From nobody Mon Nov 10 18:35:06 2014 Return-Path: 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 2FB751AD47B for ; Mon, 10 Nov 2014 18:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no 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 IyCgvAmk068P for ; Mon, 10 Nov 2014 18:35:03 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 8F6291AD478 for ; Mon, 10 Nov 2014 18:35:02 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee2546175d534d-13615; Tue, 11 Nov 2014 10:35:01 +0800 (CST) X-RM-TRANSID: 2ee2546175d534d-13615 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[31.133.163.238]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea546175ce1d8-6b8ca; Tue, 11 Nov 2014 10:35:01 +0800 (CST) X-RM-TRANSID: 2eea546175ce1d8-6b8ca From: "Hui Deng" To: "'Sri Gundavelli \(sgundave\)'" , "'Ted Lemon'" References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> In-Reply-To: Date: Mon, 10 Nov 2014 16:34:57 -1000 Message-ID: <002c01cffd58$18276ca0$487645e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP/VZdDGqgD4+1QES0VCAdxLmWw5xatOjw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mif/OqmX1Om7dYGu260Fso_8dVGLY_w Cc: 'Brian Haberman' , mif@ietf.org Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:35:05 -0000 Hi Sri, Current MIF charter prevent MIF from working on flow switch which is = mostly mobile ip/dmm based solution,=20 but it doesn't disallow MIF to work on flow split and per packet = delivery. This is the key point that PS should explain the clearly. -Hui -----Original Message----- From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]=20 Sent: Monday, November 10, 2014 4:23 PM To: Ted Lemon Cc: STARK, BARBARA H; Hui Deng; mif@ietf.org; Brian Haberman; Jouni = Korhonen; pierrick.seite@orange.com; Dapeng Liu Subject: Re: Follow up with BBF proposal Hi Ted, Having a discussion in MIF WG sounds reasonable to me. Regarding homenet relation, I'm not sure it belongs to that WG either. = The focus of the homenet is on ingress networks and for realizing = simplified configurations and that has no relation to access selection = on egress paths. FWIW, this work is very much related to what the MIP = working group have been doing for many years. Sure, the device in case = of BBF is a fixed device, but the fundamental requirements are about = access selection, flow mobility and policy exchange. The flow mobility / = MCOA work in MIP working groups have done significant amount of work in = this area and the expertise is in that group. If the reason for steering this work away from DMM is due the belief = that we will apply only MIP-based solution, I'd say the group will = certainly do that, but the WG may also agree to additional = solution/protocol mechanisms. Also, IETF is in no position to pick one = protocol/solution for this requirement. It is probably reasonable for = IETF to identify a set of solutions and present analysis on each of the = solutions and that can be the basis for the BBF to review and pick one = or more solutions. But, either way I believe the expertise around this = topic is in DMM WG and not in homenet or in MIF WG's. Regards Sri =20 On 11/10/14 5:59 PM, "Ted Lemon" wrote: >On Nov 10, 2014, at 3:08 PM, Sri Gundavelli (sgundave)=20 > wrote: >> The BBF requirement as presented in the BBF documents and as=20 >>interpreted in draft-seite and draft-lhwxz is about enabling a CPE=20 >>device to attach to multiple access network and perform flow = management. >>However, I look at it, I see this this is a mobility requirement and=20 >>is really not in the scope of MIF WG. The BBF requirement in question=20 >>is all about flow switching or flow splitting across access systems.=20 >>I'm not sure why this work belongs MIF and not DMM which is chartered=20 >>to handle all mobility use-cases. We have discussed this specific=20 >>use-case of flow splitting during MIF formation and explicitly=20 >>disallowed MIF WG from taking up such work. The following is the quote = >>from the MIF chartered text. Also, the MIF WG was primarily looking at = >>issues for a host attached to multiple access networks, but the hybrid = >>access is about a CPE attached to multiple networks. I really think=20 >>this work should be done in DMM and we did present the requirements in = >>the last IETF meeting. > >It's not at all clear that the way the problem is currently framed is >even correct. I am skeptical that this is a flow splitting/flow >switching problem. I agree that if it is, it doesn't belong in MIF. >But I think it's worthwhile to discuss in MIF, and I think it's also >germane to what homenet is doing. If this does actually require flow >splitting and/or switching, that's going to have some pretty nasty=20 >implications on the home network, so it would be nice to see if there's = >a better way to approach the problem. > From nobody Mon Nov 10 18:45:00 2014 Return-Path: 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 BD2AC1AD498 for ; Mon, 10 Nov 2014 18:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 8WPCra1vbiAG for ; Mon, 10 Nov 2014 18:44:56 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5411AD493 for ; Mon, 10 Nov 2014 18:44:55 -0800 (PST) Received: from [10.119.8.5] ([205.164.56.60]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0MbQsU-1XXSX71G0C-00Ipip; Tue, 11 Nov 2014 03:44:48 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_44B0DBFD-ABF5-4C0D-ADB9-B7D8DD6E0E43" From: Alper Yegin In-Reply-To: Date: Tue, 11 Nov 2014 04:44:41 +0200 Message-Id: <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> To: Sri Gundavelli (sgundave) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:6ubuwWsrJZnfDVb9Vh0F77H6xThO0NN0BAmN+AWNmlp ky8NzAWhDoyI8wDh2Oq62F1dPUoYICUYF/hnf/pJecDABVrbt8 GTMZ2wJELLAnLtKUxXTt0654j69BtVZnVAhCMPsBtbOWStRD2T FlhjoTYQDbueHzSrdNs3JVJu3fpRN23kzX0ryB3h/VcallxBni phRt5EyKTaW7Zl4JidFPHyqoXjXTXKSy0txlE4KmCGxQPJKc4A mm8s17GXWM7c9Rop+tDGuw9/cCmHnZeUASU8x4HmSSAMBtkzF7 9pPdT03RVcsVUa3/a8JxvMR5TvHYjF6RFIWdNs8HYD4+hY6LXZ KNrrtQbR/JkHvPeF1hdMjHO76UsU7Sk1XnGxMVhWYkK9cRc9lR Z22hgKBA5ngCw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/mif/G_ZKHMEKZXRucWjU33czlMUCh7Q Cc: Brian Haberman , "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:44:58 -0000 --Apple-Mail=_44B0DBFD-ABF5-4C0D-ADB9-B7D8DD6E0E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii MIF focuses on the following issues, and the issue BBF is bringing up is = a totally separate issue. It's about how two links can be aggregated for capacity and reliability = boost. So, I agree with Sri that this is not a MIF WG issue. The MIF problem statement document [RFC6418] enumerates the problems = into 3 categories: 1. Lack of consistent and distinctive management of configuration = elements, associated with different networks. 2. Inappropriate mixed use of configuration elements, associated with = different networks, in the course of a particular network activity / = connection. 3. Use of a particular network, not consistent with the intent of the = scenario / involved parties, leading to connectivity failure and / or = other undesired consequences. Alper On Nov 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote: > Hi Hui, >=20 > The BBF requirement as presented in the BBF documents and as = interpreted in draft-seite and draft-lhwxz is about enabling a CPE = device to attach to multiple access network and perform flow management. = However, I look at it, I see this this is a mobility requirement and is = really not in the scope of MIF WG. The BBF requirement in question is = all about flow switching or flow splitting across access systems. I'm = not sure why this work belongs MIF and not DMM which is chartered to = handle all mobility use-cases. We have discussed this specific use-case = of flow splitting during MIF formation and explicitly disallowed MIF WG = from taking up such work. The following is the quote from the MIF = chartered text. Also, the MIF WG was primarily looking at issues for a = host attached to multiple access networks, but the hybrid access is = about a CPE attached to multiple networks. I really think this work = should be done in DMM and we did present the requirements in the last = IETF meeting. >=20 >=20 > http://datatracker.ietf.org/wg/mif/charter/ >=20 > No work will be done to enable traffic flows to move from one = interface to another. The group recognizes existing work on mechanisms = that require peer or network support for moving traffic flows such as = RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile = IPv6. This group does not work on or impact such mechanisms. Future work = in this area requires rechartering the working group or asking other, = specialized working groups (such as DHC or 6MAN) to deal with specific = issues. >=20 >=20 >=20 >=20 > Regards > Sri >=20 > From: Hui Deng > Date: Friday, October 31, 2014 4:50 AM > To: Sri Gundavelli , 'Xueli' , = "pierrick.seite@orange.com" , 'Ted Lemon' = , "'STARK, BARBARA H'" , = 'Alexandru Petrescu' > Cc: "mif@ietf.org" > Subject: Follow up with BBF proposal >=20 > Hi everybody > =20 > I am recommending that Xue Li could help to put down the slide for the = problem statement from BBF. > =20 > And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly = to meet together during IETF meeting > to discuss by adding s thelide about how today solutions meet the = requirement or there are some gap still, and whether that problem should = be solvable in IETF. > =20 > Chairs will talk with AD whether MIF or somewhere else will consider = to discuss those issues during the f2f session. > =20 > Best regards, > =20 > -Hui > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail=_44B0DBFD-ABF5-4C0D-ADB9-B7D8DD6E0E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The MIF problem statement document = [RFC6418] enumerates the problems into 3 = categories:
  1. Lack of consistent and distinctive = management of configuration elements, associated with different = networks.
  2. Inappropriate mixed use of = configuration elements, associated with different networks, in the = course of a particular network activity / connection.

Alper



On Nov = 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote:

Hi Hui,

The BBF requirement as presented in the BBF documents and as = interpreted in draft-seite and draft-lhwxz is about enabling a CPE = device to attach to multiple access network and perform flow management. = However, I look at it, I see this this is a mobility requirement and is really not in the scope of MIF WG. The BBF = requirement in question is all about flow switching or flow splitting = across access systems. I'm not sure why this work belongs MIF and not = DMM which is chartered to handle all mobility use-cases. We have discussed this specific use-case of flow splitting during MIF = formation and explicitly disallowed MIF WG from taking up such work. The = following is the quote from the MIF chartered text. Also, the MIF WG was = primarily looking at issues for a host attached to multiple access networks, but the hybrid access is about a CPE = attached to multiple networks. I really think this work should be done = in DMM and we did present the requirements in the last IETF = meeting.



No work will be done to enable traffic flows to move from one = interface to another. The group recognizes existing work on mechanisms = that require peer or network support for moving traffic flows such as = RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such = mechanisms. Future work in this area requires rechartering the working = group or asking other, specialized working groups (such as DHC or 6MAN) = to deal with specific issues.




Regards
Sri

From: Hui Deng <denghui@chinamobile.com> Date: Friday, October 31, 2014 = 4:50 AM
To: Sri Gundavelli <sgundave@cisco.com>, 'Xueli' = <xueli@huawei.com>, "pierrick.seite@orange.com" <pierrick.seite@orange.com>= ;, 'Ted Lemon' <Ted.Lemon@nominum.com>, = "'STARK, BARBARA H'" <bs7652@att.com>, 'Alexandru = Petrescu' <alexandru.petrescu@gmail.com<= /a>>
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Follow up with BBF = proposal

Hi everybody
 
I am = recommending that Xue Li could help to put down the slide for the = problem statement from BBF.
 
And = MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly to = meet together during IETF meeting
to = discuss by adding s thelide about how today solutions meet the = requirement or there are some gap still, and whether that problem should = be solvable in IETF.
 
Chairs = will talk with AD whether MIF or somewhere else will consider to discuss = those issues during the f2f session.
 
Best = regards,
 
-Hui
_______________________________________________
mif mailing = list
mif@ietf.org
https://www.ietf.org/mail= man/listinfo/mif

= --Apple-Mail=_44B0DBFD-ABF5-4C0D-ADB9-B7D8DD6E0E43-- From nobody Mon Nov 10 19:21:01 2014 Return-Path: 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 5ACE91AD4C8 for ; Mon, 10 Nov 2014 19:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.156 X-Spam-Level: * X-Spam-Status: No, score=1.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] 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 BPm3G4JkOaxO for ; Mon, 10 Nov 2014 19:20:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4DF1AD4C1 for ; Mon, 10 Nov 2014 19:20:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLM33521; Tue, 11 Nov 2014 03:20:54 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Nov 2014 03:20:52 +0000 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.168]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 11 Nov 2014 11:20:48 +0800 From: Xueli To: Alper Yegin , Sri Gundavelli Thread-Topic: [mif] Follow up with BBF proposal Thread-Index: AQHP9QlLyow++51hHk+/AgjyPF8J1JxaJ+GAgAAa0oCAAI+3wA== Date: Tue, 11 Nov 2014 03:20:47 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B44903A41B@nkgeml504-mbx.china.huawei.com> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> In-Reply-To: <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.236] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B44903A41Bnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mif/_IxqEgHCMKTTiLZK2ddDwlyZgp0 Cc: Brian Haberman , "mif@ietf.org" Subject: [mif] =?gb2312?b?tPC4tDogIEZvbGxvdyB1cCB3aXRoIEJCRiBwcm9wb3NhbA==?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:20:59 -0000 --_000_01FE63842C181246BBE4CF183BD159B44903A41Bnkgeml504mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8NCg0KVGhlIE1JRiBjaGFydGVyIHNheXMgbGlrZToNCiIgVGhlIHB1cnBvc2Ugb2YgdGhl IE1JRiB3b3JraW5nIGdyb3VwIGlzIHRvIGRlc2NyaWJlIHRoZSBhcmNoaXRlY3R1cmUgZGV0YWls aW5nIGhvdyBkZXZpY2VzIGF0dGFjaCB0byBhbmQgb3BlcmF0ZSBpbiBtdWx0aXBsZSBuZXR3b3Jr cy4iDQpJIHRoaW5rIG15IHByZXNlbnRhdGlvbiBjbGVhbmx5IGZpdHMgdGhpcyBzdGF0ZW1lbnQu Li4NCg0KQmVzdCBSZWdhcmRzDQpYVUVMSQ0KDQoNCreivP7IyzogbWlmIFttYWlsdG86bWlmLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gQWxwZXIgWWVnaW4NCreiy83KsbzkOiAyMDE0xOoxMdTCMTHI 1SAxMDo0NQ0KytW8/sjLOiBTcmkgR3VuZGF2ZWxsaQ0Ks63LzTogQnJpYW4gSGFiZXJtYW47IG1p ZkBpZXRmLm9yZw0K1vfM4jogUmU6IFttaWZdIEZvbGxvdyB1cCB3aXRoIEJCRiBwcm9wb3NhbA0K DQpNSUYgZm9jdXNlcyBvbiB0aGUgZm9sbG93aW5nIGlzc3VlcywgYW5kIHRoZSBpc3N1ZSBCQkYg aXMgYnJpbmdpbmcgdXAgaXMgYSB0b3RhbGx5ICBzZXBhcmF0ZSBpc3N1ZS4NCkl0J3MgYWJvdXQg aG93IHR3byBsaW5rcyBjYW4gYmUgYWdncmVnYXRlZCBmb3IgY2FwYWNpdHkgYW5kIHJlbGlhYmls aXR5IGJvb3N0Lg0KDQpTbywgSSBhZ3JlZSB3aXRoIFNyaSB0aGF0IHRoaXMgaXMgbm90IGEgTUlG IFdHIGlzc3VlLg0KDQpUaGUgTUlGIHByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50IFtSRkM2NDE4 PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NDE4Pl0gZW51bWVyYXRlcyB0aGUgcHJv YmxlbXMgaW50byAzIGNhdGVnb3JpZXM6DQogIDEuIExhY2sgb2YgY29uc2lzdGVudCBhbmQgZGlz dGluY3RpdmUgbWFuYWdlbWVudCBvZiBjb25maWd1cmF0aW9uIGVsZW1lbnRzLCBhc3NvY2lhdGVk IHdpdGggZGlmZmVyZW50IG5ldHdvcmtzLg0KICAyLiBJbmFwcHJvcHJpYXRlIG1peGVkIHVzZSBv ZiBjb25maWd1cmF0aW9uIGVsZW1lbnRzLCBhc3NvY2lhdGVkIHdpdGggZGlmZmVyZW50IG5ldHdv cmtzLCBpbiB0aGUgY291cnNlIG9mIGEgcGFydGljdWxhciBuZXR3b3JrIGFjdGl2aXR5IC8gY29u bmVjdGlvbi4NCiAgMy4gVXNlIG9mIGEgcGFydGljdWxhciBuZXR3b3JrLCBub3QgY29uc2lzdGVu dCB3aXRoIHRoZSBpbnRlbnQgb2YgdGhlIHNjZW5hcmlvIC8gaW52b2x2ZWQgcGFydGllcywgbGVh ZGluZyB0byBjb25uZWN0aXZpdHkgZmFpbHVyZSBhbmQgLyBvciBvdGhlciB1bmRlc2lyZWQgY29u c2VxdWVuY2VzLg0KDQpBbHBlcg0KDQoNCg0KDQpPbiBOb3YgMTEsIDIwMTQsIGF0IDM6MDggQU0s IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6DQoNCg0KSGkgSHVpLA0KDQpUaGUgQkJG IHJlcXVpcmVtZW50IGFzIHByZXNlbnRlZCBpbiB0aGUgQkJGIGRvY3VtZW50cyBhbmQgYXMgaW50 ZXJwcmV0ZWQgaW4gZHJhZnQtc2VpdGUgYW5kIGRyYWZ0LWxod3h6IGlzIGFib3V0IGVuYWJsaW5n IGEgQ1BFIGRldmljZSB0byBhdHRhY2ggdG8gbXVsdGlwbGUgYWNjZXNzIG5ldHdvcmsgYW5kIHBl cmZvcm0gZmxvdyBtYW5hZ2VtZW50LiBIb3dldmVyLCBJIGxvb2sgYXQgaXQsIEkgc2VlIHRoaXMg dGhpcyBpcyBhIG1vYmlsaXR5IHJlcXVpcmVtZW50IGFuZCBpcyByZWFsbHkgbm90IGluIHRoZSBz Y29wZSBvZiBNSUYgV0cuIFRoZSBCQkYgcmVxdWlyZW1lbnQgaW4gcXVlc3Rpb24gaXMgYWxsIGFi b3V0IGZsb3cgc3dpdGNoaW5nIG9yIGZsb3cgc3BsaXR0aW5nIGFjcm9zcyBhY2Nlc3Mgc3lzdGVt cy4gSSdtIG5vdCBzdXJlIHdoeSB0aGlzIHdvcmsgYmVsb25ncyBNSUYgYW5kIG5vdCBETU0gd2hp Y2ggaXMgY2hhcnRlcmVkIHRvIGhhbmRsZSBhbGwgbW9iaWxpdHkgdXNlLWNhc2VzLiBXZSBoYXZl IGRpc2N1c3NlZCB0aGlzIHNwZWNpZmljIHVzZS1jYXNlIG9mIGZsb3cgc3BsaXR0aW5nIGR1cmlu ZyBNSUYgZm9ybWF0aW9uIGFuZCBleHBsaWNpdGx5IGRpc2FsbG93ZWQgTUlGIFdHIGZyb20gdGFr aW5nIHVwIHN1Y2ggd29yay4gVGhlIGZvbGxvd2luZyBpcyB0aGUgcXVvdGUgZnJvbSB0aGUgTUlG IGNoYXJ0ZXJlZCB0ZXh0LiBBbHNvLCB0aGUgTUlGIFdHIHdhcyBwcmltYXJpbHkgbG9va2luZyBh dCBpc3N1ZXMgZm9yIGEgaG9zdCBhdHRhY2hlZCB0byBtdWx0aXBsZSBhY2Nlc3MgbmV0d29ya3Ms IGJ1dCB0aGUgaHlicmlkIGFjY2VzcyBpcyBhYm91dCBhIENQRSBhdHRhY2hlZCB0byBtdWx0aXBs ZSBuZXR3b3Jrcy4gSSByZWFsbHkgdGhpbmsgdGhpcyB3b3JrIHNob3VsZCBiZSBkb25lIGluIERN TSBhbmQgd2UgZGlkIHByZXNlbnQgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGUgbGFzdCBJRVRGIG1l ZXRpbmcuDQoNCg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL21pZi9jaGFydGVyLw0K DQpObyB3b3JrIHdpbGwgYmUgZG9uZSB0byBlbmFibGUgdHJhZmZpYyBmbG93cyB0byBtb3ZlIGZy b20gb25lIGludGVyZmFjZSB0byBhbm90aGVyLiBUaGUgZ3JvdXAgcmVjb2duaXplcyBleGlzdGlu ZyB3b3JrIG9uIG1lY2hhbmlzbXMgdGhhdCByZXF1aXJlIHBlZXIgb3IgbmV0d29yayBzdXBwb3J0 IGZvciBtb3ZpbmcgdHJhZmZpYyBmbG93cyBzdWNoIGFzIFJGQyA1MjA2LCBSRkMgNDk4MCBhbmQg dGhlIHVzZSBvZiBtdWx0aXBsZSBjYXJlLW9mIGFkZHJlc3NlcyBpbiBNb2JpbGUgSVB2Ni4gVGhp cyBncm91cCBkb2VzIG5vdCB3b3JrIG9uIG9yIGltcGFjdCBzdWNoIG1lY2hhbmlzbXMuIEZ1dHVy ZSB3b3JrIGluIHRoaXMgYXJlYSByZXF1aXJlcyByZWNoYXJ0ZXJpbmcgdGhlIHdvcmtpbmcgZ3Jv dXAgb3IgYXNraW5nIG90aGVyLCBzcGVjaWFsaXplZCB3b3JraW5nIGdyb3VwcyAoc3VjaCBhcyBE SEMgb3IgNk1BTikgdG8gZGVhbCB3aXRoIHNwZWNpZmljIGlzc3Vlcy4NCg0KDQoNCg0KUmVnYXJk cw0KU3JpDQoNCkZyb206IEh1aSBEZW5nIDxkZW5naHVpQGNoaW5hbW9iaWxlLmNvbTxtYWlsdG86 ZGVuZ2h1aUBjaGluYW1vYmlsZS5jb20+Pg0KRGF0ZTogRnJpZGF5LCBPY3RvYmVyIDMxLCAyMDE0 IDQ6NTAgQU0NClRvOiBTcmkgR3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPG1haWx0bzpz Z3VuZGF2ZUBjaXNjby5jb20+PiwgJ1h1ZWxpJyA8eHVlbGlAaHVhd2VpLmNvbTxtYWlsdG86eHVl bGlAaHVhd2VpLmNvbT4+LCAicGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbTxtYWlsdG86cGllcnJp Y2suc2VpdGVAb3JhbmdlLmNvbT4iIDxwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPG1haWx0bzpw aWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPj4sICdUZWQgTGVtb24nIDxUZWQuTGVtb25Abm9taW51 bS5jb208bWFpbHRvOlRlZC5MZW1vbkBub21pbnVtLmNvbT4+LCAiJ1NUQVJLLCBCQVJCQVJBIEgn IiA8YnM3NjUyQGF0dC5jb208bWFpbHRvOmJzNzY1MkBhdHQuY29tPj4sICdBbGV4YW5kcnUgUGV0 cmVzY3UnIDxhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPG1haWx0bzphbGV4YW5kcnUucGV0 cmVzY3VAZ21haWwuY29tPj4NCkNjOiAibWlmQGlldGYub3JnPG1haWx0bzptaWZAaWV0Zi5vcmc+ IiA8bWlmQGlldGYub3JnPG1haWx0bzptaWZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogRm9sbG93IHVw IHdpdGggQkJGIHByb3Bvc2FsDQoNCkhpIGV2ZXJ5Ym9keQ0KDQpJIGFtIHJlY29tbWVuZGluZyB0 aGF0IFh1ZSBMaSBjb3VsZCBoZWxwIHRvIHB1dCBkb3duIHRoZSBzbGlkZSBmb3IgdGhlIHByb2Js ZW0gc3RhdGVtZW50IGZyb20gQkJGLg0KDQpBbmQgTUlQL05FTU8gcHJvcG9uZW50cyAoUGllcnJp Y2ssIEFsZXgsIFNyaSkgYW5kIFh1ZSBMaSBjb3VsZCBraW5kbHkgdG8gbWVldCB0b2dldGhlciBk dXJpbmcgSUVURiBtZWV0aW5nDQp0byBkaXNjdXNzIGJ5IGFkZGluZyBzIHRoZWxpZGUgYWJvdXQg aG93IHRvZGF5IHNvbHV0aW9ucyBtZWV0IHRoZSByZXF1aXJlbWVudCBvciB0aGVyZSBhcmUgc29t ZSBnYXAgc3RpbGwsIGFuZCB3aGV0aGVyIHRoYXQgcHJvYmxlbSBzaG91bGQgYmUgc29sdmFibGUg aW4gSUVURi4NCg0KQ2hhaXJzIHdpbGwgdGFsayB3aXRoIEFEIHdoZXRoZXIgTUlGIG9yIHNvbWV3 aGVyZSBlbHNlIHdpbGwgY29uc2lkZXIgdG8gZGlzY3VzcyB0aG9zZSBpc3N1ZXMgZHVyaW5nIHRo ZSBmMmYgc2Vzc2lvbi4NCg0KQmVzdCByZWdhcmRzLA0KDQotSHVpDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWlmIG1haWxpbmcgbGlzdA0KbWlmQGll dGYub3JnPG1haWx0bzptaWZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21pZg0KDQo= --_000_01FE63842C181246BBE4CF183BD159B44903A41Bnkgeml504mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hello

 

The MIF charter says like:=

" The purpose of the MIF working group is to describe the architecture = detailing how devices attach to and operate in multiple networks."
I think my presentation cleanly fits this statement... <= /span>

 

Best Regards<= /p>

XUELI

&n= bsp;

&n= bsp;

=B7=A2=BC=FE=C8=CB: mif [mailto:mif-bounces@ietf.org] =B4=FA=B1=ED = Alper Yegin
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA11=D4=C2= 11=C8=D5 10:45
=CA=D5=BC=FE=C8=CB: Sri Gundavelli
=B3=AD=CB=CD: Brian Haberman; mif@ietf.org
=D6=F7=CC=E2: Re: [mif] Follow up with BBF proposal

 

MIF focuses on the following is= sues, and the issue BBF is bringing up is a totally  separate issue.

It's about how two links can be= aggregated for capacity and reliability boost.

 

So, I agree with Sri that this = is not a MIF WG issue.

 

The MIF problem statement document [RFC6418] e= numerates the problems into 3 categories:

  1. Lack of consistent and distinctive management of c= onfiguration elements, associated with different networks.

  2. Inappropriate mixed use of configuration elements,= associated with different networks, in the course of a particular network = activity / connection.

  3. Use of a particular network, not consistent with t= he intent of the scenario / involved parties, leading to connectivity failu= re and / or other undesired consequences.

 

Alper

 

 

 

 

On Nov 11, 2014, at 3:08 AM, Sr= i Gundavelli (sgundave) wrote:



Hi Hui,

&nbs= p;

The BBF r= equirement as presented in the BBF documents and as interpreted in draft-se= ite and draft-lhwxz is about enabling a CPE device to attach to multip= le access network and perform flow management. However, I look at it, I see this this is a mobility requirement and is re= ally not in the scope of MIF WG. The BBF requirement in question is all abo= ut flow switching or flow splitting across access systems. I'm not sure why= this work belongs MIF and not DMM which is chartered to handle all mobility use-cases. We have discussed thi= s specific use-case of flow splitting during MIF formation and explicitly d= isallowed MIF WG from taking up such work. The following is the quote from = the MIF chartered text. Also, the MIF WG was primarily looking at issues for a host attached to multiple acc= ess networks, but the hybrid access is about a CPE attached to multiple net= works. I really think this work should be done in DMM and we did present th= e requirements in the last IETF meeting.

&nbs= p;

&nbs= p;

&nbs= p;

No wor= k will be done to enable traffic flows to move from one interface to anothe= r. The group recognizes existing work on mechanisms that require peer or ne= twork support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mo= bile IPv6. This group does not work on or impact such mechanisms. Future wo= rk in this area requires rechartering the working group or asking other, sp= ecialized working groups (such as DHC or 6MAN) to deal with specific issues.

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

Regards

Sri<= /o:p>

&nbs= p;

From: Hui = Deng <denghui@chinamobile.com= >
Date: Friday, October 31, 2014 4:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, 'Xueli' <xueli@= huawei.com>, "pier= rick.seite@orange.com" <pierrick.seite@orange.com>, 'Ted Lemon' <Ted.Lemon@nominum= .com>, "'STARK, BARBARA H'" <bs7652@att.com>, 'Alexandru Petrescu' <alexandru.petrescu@gmail.com>
Cc: "mif@ietf.org" <= ;mif@ietf.org>
Subject: Follow up with BBF proposal

&nbs= p;

Hi ever= ybody

 <= /span>

I am re= commending that Xue Li could help to put down the slide for the problem sta= tement from BBF.

 <= /span>

And MIP= /NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly to meet toge= ther during IETF meeting<= o:p>

to disc= uss by adding s thelide about how today solutions meet the requirement or t= here are some gap still, and whether that problem should be solvable in IET= F.

 <= /span>

Chairs = will talk with AD whether MIF or somewhere else will consider to discuss th= ose issues during the f2f session.

 <= /span>

Best re= gards,<= /p>

 <= /span>

-Hui

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/= mailman/listinfo/mif

 

--_000_01FE63842C181246BBE4CF183BD159B44903A41Bnkgeml504mbxchi_-- From nobody Mon Nov 10 19:45:50 2014 Return-Path: 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 23A291AD530 for ; Mon, 10 Nov 2014 19:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 o8aOmNCP8gK4 for ; Mon, 10 Nov 2014 19:45:43 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFFC91AD52B for ; Mon, 10 Nov 2014 19:45:43 -0800 (PST) Received: from [10.119.8.5] ([205.164.56.60]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0MKaY5-1XpPJ23uLf-001zSI; Tue, 11 Nov 2014 04:45:41 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_81598AB2-9839-47EE-B592-B7C589DFB09B" From: Alper Yegin In-Reply-To: <01FE63842C181246BBE4CF183BD159B44903A41B@nkgeml504-mbx.china.huawei.com> Date: Tue, 11 Nov 2014 05:45:35 +0200 Message-Id: <9ED11710-4F49-4602-84E2-49B9E17B1FE1@yegin.org> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <01FE63842C181246BBE4CF183BD159B44903A41B@nkgeml504-mbx.china.huawei.com> To: Xueli X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:0oZZg3wsxttnt9JC58NznQC4iAb0I1HCNQoDLHMNwKg FiGM3OyiNXPBvxrBnrIPtNXjkzJVPxWr1TgA972laHS06jJFlf V+m7DEYyqyt4Ld/Dw38t6n9u1bMfxB/Ou6rigdl5dFO3Y5fkFc Fm+qAlHN4AO5LfTW+N3ARl5eDazC6BAkW4MitrhQb4nUicavN8 uxAmUswIf8vQlJ8GVlGZ3l8o57qH1+wnrbAK2MkT8cxNcQGe26 yDiDfP19I+UCTIhmzm1UQ0jdVi8O9Rk4jrh64dMboUR0ImkqPb QP+x/SUNCBWY9YafyehoZYS1UxNprpmjDtig7yCLrFWVkByE6R UO+ZGSjR3VPAQHyUs3FxsTj+SuKw/Ye5FQKCze0bCFzPZMTlSu cD/0TJ9nitLzw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/mif/3Lf13vFLLY2cTrqWSXKcxXySSjU Cc: Brian Haberman , "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:45:47 -0000 --Apple-Mail=_81598AB2-9839-47EE-B592-B7C589DFB09B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Xueli, That's one of the general statements in the charter. And it covers so = many areas, obviously MIF is not chartered to deal with. For example, discovery of networks, selection of networks, = authentication, accounting, host configuration, traffic management, = mobility, etc. etc. The statements I pulled form the charter pin-points the exact scope of = MIF. Anything else is outside the scope, currently. Alper On Nov 11, 2014, at 5:20 AM, Xueli wrote: > Hello > =20 > The MIF charter says like: > " The purpose of the MIF working group is to describe the architecture = detailing how devices attach to and operate in multiple networks." > I think my presentation cleanly fits this statement... > =20 > Best Regards > XUELI > =20 > =20 > =B7=A2=BC=FE=C8=CB: mif [mailto:mif-bounces@ietf.org] =B4=FA=B1=ED = Alper Yegin > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA11=D4=C211=C8=D5 10:45 > =CA=D5=BC=FE=C8=CB: Sri Gundavelli > =B3=AD=CB=CD: Brian Haberman; mif@ietf.org > =D6=F7=CC=E2: Re: [mif] Follow up with BBF proposal > =20 > MIF focuses on the following issues, and the issue BBF is bringing up = is a totally separate issue. > It's about how two links can be aggregated for capacity and = reliability boost. > =20 > So, I agree with Sri that this is not a MIF WG issue. > =20 > The MIF problem statement document [RFC6418] enumerates the problems = into 3 categories: > 1. Lack of consistent and distinctive management of configuration = elements, associated with different networks. > 2. Inappropriate mixed use of configuration elements, associated = with different networks, in the course of a particular network activity = / connection. > 3. Use of a particular network, not consistent with the intent of = the scenario / involved parties, leading to connectivity failure and / = or other undesired consequences. > =20 > Alper > =20 > =20 > =20 > =20 > On Nov 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote: >=20 >=20 > Hi Hui, > =20 > The BBF requirement as presented in the BBF documents and as = interpreted in draft-seite and draft-lhwxz is about enabling a CPE = device to attach to multiple access network and perform flow management. = However, I look at it, I see this this is a mobility requirement and is = really not in the scope of MIF WG. The BBF requirement in question is = all about flow switching or flow splitting across access systems. I'm = not sure why this work belongs MIF and not DMM which is chartered to = handle all mobility use-cases. We have discussed this specific use-case = of flow splitting during MIF formation and explicitly disallowed MIF WG = from taking up such work. The following is the quote from the MIF = chartered text. Also, the MIF WG was primarily looking at issues for a = host attached to multiple access networks, but the hybrid access is = about a CPE attached to multiple networks. I really think this work = should be done in DMM and we did present the requirements in the last = IETF meeting. > =20 > =20 > http://datatracker.ietf.org/wg/mif/charter/ > =20 > No work will be done to enable traffic flows to move from one = interface to another. The group recognizes existing work on mechanisms = that require peer or network support for moving traffic flows such as = RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile = IPv6. This group does not work on or impact such mechanisms. Future work = in this area requires rechartering the working group or asking other, = specialized working groups (such as DHC or 6MAN) to deal with specific = issues. > =20 > =20 > =20 > =20 > Regards > Sri > =20 > From: Hui Deng > Date: Friday, October 31, 2014 4:50 AM > To: Sri Gundavelli , 'Xueli' , = "pierrick.seite@orange.com" , 'Ted Lemon' = , "'STARK, BARBARA H'" , = 'Alexandru Petrescu' > Cc: "mif@ietf.org" > Subject: Follow up with BBF proposal > =20 > Hi everybody > =20 > I am recommending that Xue Li could help to put down the slide for the = problem statement from BBF. > =20 > And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly = to meet together during IETF meeting > to discuss by adding s thelide about how today solutions meet the = requirement or there are some gap still, and whether that problem should = be solvable in IETF. > =20 > Chairs will talk with AD whether MIF or somewhere else will consider = to discuss those issues during the f2f session. > =20 > Best regards, > =20 > -Hui > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail=_81598AB2-9839-47EE-B592-B7C589DFB09B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Xueli,

That's one of the = general statements in the charter. And it covers so many areas, = obviously MIF is not chartered to deal with.
For example, = discovery of networks, selection of networks, authentication, = accounting, host configuration, traffic management, mobility, etc. = etc.
The statements I pulled form the charter pin-points the = exact scope of MIF. Anything else is outside the scope, = currently.

Alper


On Nov 11, 2014, at 5:20 AM, Xueli wrote:

Hello
 
The MIF charter says = like:
" The purpose of the = MIF working group is to describe the architecture detailing how devices = attach to and operate in multiple networks."
I think my = presentation cleanly fits this statement...
 
Best = Regards
XUELI
 
 
=B7=A2=BC=FE=C8= =CB: mif = [mailto:mif-bounces@ietf.org] =B4=FA=B1=ED Alper = Yegin
: 2014=C4=EA11=D4=C211=C8=D5 10:45
=CA=D5=BC=FE= =C8=CB: Sri = Gundavelli
=B3=AD=CB=CD: Brian = Haberman; mif@ietf.org
=D6=F7=CC=E2: Re: [mif] Follow up with = BBF proposal
 
MIF focuses on = the following issues, and the issue BBF is bringing up is a totally =  separate issue.
It's about how = two links can be aggregated for capacity and reliability = boost.
 
So, I agree = with Sri that this is not a MIF WG = issue.
 
The MIF problem = statement document [RFC6418] enumerates the problems into 3 = categories:
  1. Lack of consistent and distinctive management of = configuration elements, associated with different = networks.
  2. Inappropriate mixed use of configuration elements, = associated with different networks, in the course of a particular = network activity / connection.
  3. Use of a = particular network, not consistent with the intent of the scenario / = involved parties, leading to connectivity failure and / or other = undesired consequences.
Alper
 
 
On Nov 11, = 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote:


Hi Hui,
 
The BBF requirement as presented in the BBF documents and as = interpreted in draft-seite and draft-lhwxz is about enabling a CPE = device to attach to multiple access network and perform flow management. = However, I look at it, I see this this is a mobility requirement and is = really not in the scope of MIF WG. The BBF requirement in question is = all about flow switching or flow splitting across access systems. I'm = not sure why this work belongs MIF and not DMM which is chartered to = handle all mobility use-cases. We have discussed this specific use-case = of flow splitting during MIF formation and explicitly disallowed MIF WG = from taking up such work. The following is the quote from the MIF = chartered text. Also, the MIF WG was primarily looking at issues for a = host attached to multiple access networks, but the hybrid access is = about a CPE attached to multiple networks. I really think this work = should be done in DMM and we did present the requirements in the last = IETF meeting.
No work = will be done to enable traffic flows to move from one interface to = another. The group recognizes existing work on mechanisms that require = peer or network support for moving traffic flows such as RFC 5206, RFC = 4980 and the use of multiple care-of addresses in Mobile IPv6. This = group does not work on or impact such mechanisms. Future work in this = area requires rechartering the working group or asking other, = specialized working groups (such as DHC or 6MAN) to deal with specific = issues.
-Hui_______________________________________________
mif = mailing list
mif@ietf.org
In-Reply-To: <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> Date: Mon, 10 Nov 2014 17:46:56 -1000 Message-Id: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/mif/X3M0C3dOZL8tgd8mpZkDz8aBSL0 Cc: Brian Haberman , "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:47:06 -0000 --Apple-Mail=_4C1F50A2-701D-4769-BDBD-3843C3D1EED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The MIF problem statement describes a particular set of problems on = Multiple Interface networks. If we wrote a problem statement (anywhere = in the IETF) for "hybrid access networks", that would be a different = problem=85 That problem is not covered in any WG's current charter, and = it is up to the ADs to decide whether to charter any work related to = that problem, and if so where. In the meantime, would it be possible for us to have a technical = discussion of the BBF Hybrid Access problem? It would be good to = discuss what the problem actually is and how existing IETF protocols = might apply to that problem. Ideally we would do this without: (1) = having some unbounded political discussion about where to charter work = that we haven't even agreed that we need to do yet, or (2) trying to = specify new solutions to the problem, at least until we understand how = existing solutions do/don't apply? Margaret On Nov 10, 2014, at 4:44 PM, Alper Yegin wrote: > MIF focuses on the following issues, and the issue BBF is bringing up = is a totally separate issue. > It's about how two links can be aggregated for capacity and = reliability boost. >=20 > So, I agree with Sri that this is not a MIF WG issue. >=20 > The MIF problem statement document [RFC6418] enumerates the problems = into 3 categories: > 1. Lack of consistent and distinctive management of configuration = elements, associated with different networks. > 2. Inappropriate mixed use of configuration elements, associated = with different networks, in the course of a particular network activity = / connection. > 3. Use of a particular network, not consistent with the intent of = the scenario / involved parties, leading to connectivity failure and / = or other undesired consequences. >=20 > Alper >=20 >=20 >=20 >=20 > On Nov 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote: >=20 >> Hi Hui, >>=20 >> The BBF requirement as presented in the BBF documents and as = interpreted in draft-seite and draft-lhwxz is about enabling a CPE = device to attach to multiple access network and perform flow management. = However, I look at it, I see this this is a mobility requirement and is = really not in the scope of MIF WG. The BBF requirement in question is = all about flow switching or flow splitting across access systems. I'm = not sure why this work belongs MIF and not DMM which is chartered to = handle all mobility use-cases. We have discussed this specific use-case = of flow splitting during MIF formation and explicitly disallowed MIF WG = from taking up such work. The following is the quote from the MIF = chartered text. Also, the MIF WG was primarily looking at issues for a = host attached to multiple access networks, but the hybrid access is = about a CPE attached to multiple networks. I really think this work = should be done in DMM and we did present the requirements in the last = IETF meeting. >>=20 >>=20 >> http://datatracker.ietf.org/wg/mif/charter/ >>=20 >> No work will be done to enable traffic flows to move from one = interface to another. The group recognizes existing work on mechanisms = that require peer or network support for moving traffic flows such as = RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile = IPv6. This group does not work on or impact such mechanisms. Future work = in this area requires rechartering the working group or asking other, = specialized working groups (such as DHC or 6MAN) to deal with specific = issues. >>=20 >>=20 >>=20 >>=20 >> Regards >> Sri >>=20 >> From: Hui Deng >> Date: Friday, October 31, 2014 4:50 AM >> To: Sri Gundavelli , 'Xueli' , = "pierrick.seite@orange.com" , 'Ted Lemon' = , "'STARK, BARBARA H'" , = 'Alexandru Petrescu' >> Cc: "mif@ietf.org" >> Subject: Follow up with BBF proposal >>=20 >> Hi everybody >> =20 >> I am recommending that Xue Li could help to put down the slide for = the problem statement from BBF. >> =20 >> And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly = to meet together during IETF meeting >> to discuss by adding s thelide about how today solutions meet the = requirement or there are some gap still, and whether that problem should = be solvable in IETF. >> =20 >> Chairs will talk with AD whether MIF or somewhere else will consider = to discuss those issues during the f2f session. >> =20 >> Best regards, >> =20 >> -Hui >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail=_4C1F50A2-701D-4769-BDBD-3843C3D1EED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252





MIF focuses on the = following issues, and the issue BBF is bringing up is a totally =  separate issue.
It's about how two links can be = aggregated for capacity and reliability = boost.

So, I agree with Sri that this is not a = MIF WG issue.

The MIF problem statement document = [RFC6418] enumerates the problems into 3 = categories:
  1. Lack of consistent and distinctive = management of configuration elements, associated with different = networks.
  2. Inappropriate mixed use of = configuration elements, associated with different networks, in the = course of a particular network activity / connection.

Alper



On Nov = 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote:

Hi Hui,

The BBF requirement as presented in the BBF documents and as = interpreted in draft-seite and draft-lhwxz is about enabling a CPE = device to attach to multiple access network and perform flow management. = However, I look at it, I see this this is a mobility requirement and is really not in the scope of MIF WG. The BBF = requirement in question is all about flow switching or flow splitting = across access systems. I'm not sure why this work belongs MIF and not = DMM which is chartered to handle all mobility use-cases. We have discussed this specific use-case of flow splitting during MIF = formation and explicitly disallowed MIF WG from taking up such work. The = following is the quote from the MIF chartered text. Also, the MIF WG was = primarily looking at issues for a host attached to multiple access networks, but the hybrid access is about a CPE = attached to multiple networks. I really think this work should be done = in DMM and we did present the requirements in the last IETF = meeting.



No work will be done to enable traffic flows to move from one = interface to another. The group recognizes existing work on mechanisms = that require peer or network support for moving traffic flows such as = RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such = mechanisms. Future work in this area requires rechartering the working = group or asking other, specialized working groups (such as DHC or 6MAN) = to deal with specific issues.




Regards
Sri

From: Hui Deng <denghui@chinamobile.com> Date: Friday, October 31, 2014 = 4:50 AM
To: Sri Gundavelli <sgundave@cisco.com>, 'Xueli' = <xueli@huawei.com>, "pierrick.seite@orange.com" <pierrick.seite@orange.com>= ;, 'Ted Lemon' <Ted.Lemon@nominum.com>, = "'STARK, BARBARA H'" <bs7652@att.com>, 'Alexandru = Petrescu' <alexandru.petrescu@gmail.com<= /a>>
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Follow up with BBF = proposal

Hi everybody
 
I am = recommending that Xue Li could help to put down the slide for the = problem statement from BBF.
 
And = MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly to = meet together during IETF meeting
to = discuss by adding s thelide about how today solutions meet the = requirement or there are some gap still, and whether that problem should = be solvable in IETF.
 
Chairs = will talk with AD whether MIF or somewhere else will consider to discuss = those issues during the f2f session.
 
Best = regards,
 
-Hui
_______________________________________________
mif mailing = list
mif@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mif

_____________= __________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mail= man/listinfo/mif

= --Apple-Mail=_4C1F50A2-701D-4769-BDBD-3843C3D1EED2-- From nobody Mon Nov 10 19:52:55 2014 Return-Path: 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 B90751AD539 for ; Mon, 10 Nov 2014 19:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no 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 7PSjkjxhQDJP for ; Mon, 10 Nov 2014 19:52:46 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id D20A11AD537 for ; Mon, 10 Nov 2014 19:52:45 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.7]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec5461880c429-034b2; Tue, 11 Nov 2014 11:52:44 +0800 (CST) X-RM-TRANSID: 2eec5461880c429-034b2 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[31.133.163.238]) by rmsmtp-syy-appsvr04-12004 (RichMail) with SMTP id 2ee454618807e51-6ea66; Tue, 11 Nov 2014 11:52:44 +0800 (CST) X-RM-TRANSID: 2ee454618807e51-6ea66 From: "Hui Deng" To: "'Alper Yegin'" , "'Xueli'" References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <01FE63842C181246BBE4CF183BD159B44903A41B@nkgeml504-mbx.china.huawei.com> <9ED11710-4F49-4602-84E2-49B9E17B1FE1@yegin.org> In-Reply-To: <9ED11710-4F49-4602-84E2-49B9E17B1FE1@yegin.org> Date: Mon, 10 Nov 2014 17:52:41 -1000 Message-ID: <001a01cffd62$f38b9ff0$daa2dfd0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01CFFD0F.21DF8FF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/9Yf3fZOGMJUgnS5+YXrefpUYkUAAAJhFw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mif/H2MiJkdr41UnC97mb1jtZ0NoVgs Cc: 'Brian Haberman' , mif@ietf.org Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:52:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01CFFD0F.21DF8FF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Alper, =20 This work hasn=E2=80=99t been clarified where it should belong to, = presenting in MIF doesn=E2=80=99t prevent going to any other working = group. Let=E2=80=99s focus on the problem and gap analysis other than where is = the place to discuss it. =20 Thanks =20 -Hui =20 From: mif [mailto:mif-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Monday, November 10, 2014 5:46 PM To: Xueli Cc: Brian Haberman; mif@ietf.org Subject: Re: [mif] Follow up with BBF proposal =20 Hi Xueli, =20 That's one of the general statements in the charter. And it covers so = many areas, obviously MIF is not chartered to deal with. For example, discovery of networks, selection of networks, = authentication, accounting, host configuration, traffic management, = mobility, etc. etc. The statements I pulled form the charter pin-points the exact scope of = MIF. Anything else is outside the scope, currently. =20 Alper =20 =20 On Nov 11, 2014, at 5:20 AM, Xueli wrote: Hello =20 The MIF charter says like: " The purpose of the MIF working group is to describe the architecture = detailing how devices attach to and operate in multiple networks." I think my presentation cleanly fits this statement... =20 Best Regards XUELI =20 =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: mif [mailto:mif-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Alper Yegin =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2014=E5=B9=B411=E6=9C=8811=E6=97=A5 10:45 =E6=94=B6=E4=BB=B6=E4=BA=BA: Sri Gundavelli =E6=8A=84=E9=80=81: Brian Haberman; mif@ietf.org =E4=B8=BB=E9=A2=98: Re: [mif] Follow up with BBF proposal =20 MIF focuses on the following issues, and the issue BBF is bringing up is = a totally separate issue. It's about how two links can be aggregated for capacity and reliability = boost. =20 So, I agree with Sri that this is not a MIF WG issue. =20 The MIF problem statement document [ = RFC6418] enumerates the problems = into 3 categories: 1. Lack of consistent and distinctive management of configuration = elements, associated with different networks. 2. Inappropriate mixed use of configuration elements, associated with = different networks, in the course of a particular network activity / = connection. 3. Use of a particular network, not consistent with the intent of the = scenario / involved parties, leading to connectivity failure and / or = other undesired consequences. =20 Alper =20 =20 =20 =20 On Nov 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote: Hi Hui, =20 The BBF requirement as presented in the BBF documents and as interpreted = in draft-seite and draft-lhwxz is about enabling a CPE device to attach = to multiple access network and perform flow management. However, I look = at it, I see this this is a mobility requirement and is really not in = the scope of MIF WG. The BBF requirement in question is all about flow = switching or flow splitting across access systems. I'm not sure why this = work belongs MIF and not DMM which is chartered to handle all mobility = use-cases. We have discussed this specific use-case of flow splitting = during MIF formation and explicitly disallowed MIF WG from taking up = such work. The following is the quote from the MIF chartered text. Also, = the MIF WG was primarily looking at issues for a host attached to = multiple access networks, but the hybrid access is about a CPE attached = to multiple networks. I really think this work should be done in DMM and = we did present the requirements in the last IETF meeting. =20 =20 http://datatracker.ietf.org/wg/mif/charter/ =20 No work will be done to enable traffic flows to move from one interface = to another. The group recognizes existing work on mechanisms that = require peer or network support for moving traffic flows such as RFC = 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. = This group does not work on or impact such mechanisms. Future work in = this area requires rechartering the working group or asking other, = specialized working groups (such as DHC or 6MAN) to deal with specific = issues. =20 =20 =20 =20 Regards Sri =20 From: Hui Deng Date: Friday, October 31, 2014 4:50 AM To: Sri Gundavelli , 'Xueli' , = "pierrick.seite@orange.com" , 'Ted Lemon' = , "'STARK, BARBARA H'" , = 'Alexandru Petrescu' Cc: "mif@ietf.org" Subject: Follow up with BBF proposal =20 Hi everybody =20 I am recommending that Xue Li could help to put down the slide for the = problem statement from BBF. =20 And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly to = meet together during IETF meeting to discuss by adding s thelide about how today solutions meet the = requirement or there are some gap still, and whether that problem should = be solvable in IETF. =20 Chairs will talk with AD whether MIF or somewhere else will consider to = discuss those issues during the f2f session. =20 Best regards, =20 -Hui _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif =20 ------=_NextPart_000_001B_01CFFD0F.21DF8FF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 

This work hasn=E2=80=99t been clarified where it should belong to, = presenting in MIF doesn=E2=80=99t prevent going to any other working = group.

Let=E2=80=99s focus on the problem and gap analysis other than where = is the place to discuss it.

 

Thanks

 

-Hui

 

From:= mif = [mailto:mif-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Monday, November 10, 2014 5:46 PM
To: = Xueli
Cc: Brian Haberman; mif@ietf.org
Subject: Re: = [mif] Follow up with BBF proposal

 

Hi = Xueli,

 

That's one of the general = statements in the charter. And it covers so many areas, obviously MIF is = not chartered to deal with.

For example, discovery of networks, = selection of networks, authentication, accounting, host configuration, = traffic management, mobility, etc. = etc.

The statements I pulled form the charter pin-points the = exact scope of MIF. Anything else is outside the scope, = currently.

 

Alper

 

 

On Nov 11, 2014, at 5:20 AM, Xueli = wrote:



Hello<= /o:p>

 =

The MIF = charter says like:

" The = purpose of the MIF working group is to describe the architecture = detailing how devices attach to and operate in multiple = networks."
I think my = presentation cleanly fits this statement...

 =

Best = Regards

XUELI<= /o:p>

 =

 =

=E5=8F=91=E4=BB=B6=E4=BA=BA: mif [mailto:mif-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Alper Yegin
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B411=E6=9C=8811=E6=97=A5 10:45
=E6=94=B6=E4=BB=B6=E4=BA=BA: Sri = Gundavelli
=E6=8A=84=E9=80=81: Brian Haberman; mif@ietf.org
=E4=B8=BB=E9=A2= =98: Re: [mif] Follow up = with BBF proposal=

 =

MIF = focuses on the following issues, and the issue BBF is bringing up is a = totally  separate issue.

It's about = how two links can be aggregated for capacity and reliability = boost.

 =

So, I = agree with Sri that this is not a MIF WG = issue.

 =

The MIF = problem statement document [RFC6418] enumerates the problems into = 3 categories:=

  1. = Lack of consistent and distinctive management of configuration elements, = associated with different networks.=

  2. = Inappropriate mixed use of configuration elements, associated with = different networks, in the course of a particular network activity / = connection.=

  3. Use = of a particular network, not consistent with the intent of the scenario = / involved parties, leading to connectivity failure and / or other = undesired consequences.=

 =

Alper=

 =

 =

 =

 =

On Nov 11, = 2014, at 3:08 AM, Sri Gundavelli (sgundave) = wrote:



Hi Hui,=

 =

The BBF requirement as presented in the BBF documents and as = interpreted in draft-seite and draft-lhwxz is about enabling a CPE = device to attach to multiple access network and perform flow management. = However, I look at it, I see this this is a mobility requirement and is = really not in the scope of MIF WG. The BBF requirement in question is = all about flow switching or flow splitting across access systems. I'm = not sure why this work belongs MIF and not DMM which is chartered to = handle all mobility use-cases. We have discussed this specific use-case = of flow splitting during MIF formation and explicitly disallowed MIF WG = from taking up such work. The following is the quote from the MIF = chartered text. Also, the MIF WG was primarily looking at issues for a = host attached to multiple access networks, but the hybrid access is = about a CPE attached to multiple networks. I really think this work = should be done in DMM and we did present the requirements in the last = IETF meeting.=

 =

 =

 =

No work will be done to enable traffic flows to move from one interface = to another. The group recognizes existing work on mechanisms that = require peer or network support for moving traffic flows such as RFC = 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. = This group does not work on or impact such mechanisms. Future work in = this area requires rechartering the working group or asking other, = specialized working groups (such as DHC or 6MAN) to deal with specific = issues.=

 =

 =

 =

 =

Regards=

Sri=

 =

From: Hui Deng <denghui@chinamobile.com>Date: Friday, = October 31, 2014 4:50 AM
To: Sri Gundavelli <sgundave@cisco.com>, 'Xueli' = <xueli@huawei.com>, = "pierrick.seite@orange.com&q= uot; <pierrick.seite@orange.com&g= t;, 'Ted Lemon' <Ted.Lemon@nominum.com>, = "'STARK, BARBARA H'" <bs7652@att.com>, 'Alexandru = Petrescu' <alexandru.petrescu@gmail.com= >
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Follow up with BBF = proposal=

 =

Hi everybody=

 =

I am recommending that Xue Li could help to put down the slide for = the problem statement from BBF.=

 =

And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly = to meet together during IETF meeting=

to discuss by adding s thelide about how today solutions meet the = requirement or there are some gap still, and whether that problem should = be solvable in IETF.=

 =

Chairs will talk with AD whether MIF or somewhere else will consider = to discuss those issues during the f2f session.=

 =

Best regards,=

 =

-Hui=

_______________________________________________
mif = mailing list
mif@ietf.org
https://www.ietf.org/m= ailman/listinfo/mif=

 

------=_NextPart_000_001B_01CFFD0F.21DF8FF0-- From nobody Mon Nov 10 19:59:17 2014 Return-Path: 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 992651AD544 for ; Mon, 10 Nov 2014 19:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 kN-YR4tiu8Yw for ; Mon, 10 Nov 2014 19:59:11 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC481AD53D for ; Mon, 10 Nov 2014 19:59:10 -0800 (PST) Received: from [10.119.8.5] ([205.164.56.60]) by mrelay.perfora.net (node=mreueus003) with ESMTP (Nemesis) id 0LrLMg-1Y06Ly0j9A-0137uY; Tue, 11 Nov 2014 04:59:08 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C3F30CCA-7960-41B6-B395-80140AB76028" From: Alper Yegin In-Reply-To: <001a01cffd62$f38b9ff0$daa2dfd0$@com> Date: Tue, 11 Nov 2014 05:59:01 +0200 Message-Id: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <01FE63842C181246BBE4CF183BD159B44903A41B@nkgeml504-mbx.china.huawei.com> <9ED11710-4F49-4602-84E2-49B9E17B1FE1@yegin.org> <001a01cffd62$f38b9ff0$daa2dfd0$@com> To: "Hui Deng" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:DZcke3eEaQYch5H/Z7XUvklA3v+o4RBhddMU8WK6J5k KzJlfdhPyg1oPh4TtKTlOXH0FFixWPoJHC7g5RzU+U50xsHN6m SBK0sELiphwshy4McUBub/1uAzl0kpS92TAX6ouEL8E7waoNqL 6CoJGTmF0rtIR2IrfkPkeBTlnwA65PLlCAppvJcqKT6fre5Ugf l7dRFoVw4rTVJYUIZXaAvy9Yk62pK13pa6jS+URU4Pw8z9cUPz JsvwpUd0342MaH9cRBluCtTFy/e/zTyyswx0c97dR+k3eMH/2U w3e0z9QSph52ePQKADzYYpx1kB6GfEHKVJMtQI9SQWLslTRiyn A3HLYkgHfcjURdZskKYAxefL4ags4w8pGQqYDlUfRn8vSbwiNV a+jXNxzNhdCJg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/mif/8pB65APBnS-0_v9ImLXzk0Xvqv8 Cc: 'Brian Haberman' , mif@ietf.org Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:59:15 -0000 --Apple-Mail=_C3F30CCA-7960-41B6-B395-80140AB76028 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sure.=20 I was just reacting to the assumption that anything that mentions 2 = interfaces automatically falls under the MIF scope :-) Also, before this work gets on a long journey thru the IETF system, = people should be aware that Mobile IP WGs did a lot of work for this = space and have solutions. FYI. Alper On Nov 11, 2014, at 5:52 AM, Hui Deng wrote: > Hi Alper, > =20 > This work hasn=E2=80=99t been clarified where it should belong to, = presenting in MIF doesn=E2=80=99t prevent going to any other working = group. > Let=E2=80=99s focus on the problem and gap analysis other than where = is the place to discuss it. > =20 > Thanks > =20 > -Hui > =20 > From: mif [mailto:mif-bounces@ietf.org] On Behalf Of Alper Yegin > Sent: Monday, November 10, 2014 5:46 PM > To: Xueli > Cc: Brian Haberman; mif@ietf.org > Subject: Re: [mif] Follow up with BBF proposal > =20 > Hi Xueli, > =20 > That's one of the general statements in the charter. And it covers so = many areas, obviously MIF is not chartered to deal with. > For example, discovery of networks, selection of networks, = authentication, accounting, host configuration, traffic management, = mobility, etc. etc. > The statements I pulled form the charter pin-points the exact scope of = MIF. Anything else is outside the scope, currently. > =20 > Alper > =20 > =20 > On Nov 11, 2014, at 5:20 AM, Xueli wrote: >=20 >=20 > Hello > =20 > The MIF charter says like: > " The purpose of the MIF working group is to describe the architecture = detailing how devices attach to and operate in multiple networks." > I think my presentation cleanly fits this statement... > =20 > Best Regards > XUELI > =20 > =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: mif [mailto:mif-bounces@ietf.org] =E4=BB=A3= =E8=A1=A8 Alper Yegin > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B411=E6=9C=8811=E6=97=A5= 10:45 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Sri Gundavelli > =E6=8A=84=E9=80=81: Brian Haberman; mif@ietf.org > =E4=B8=BB=E9=A2=98: Re: [mif] Follow up with BBF proposal > =20 > MIF focuses on the following issues, and the issue BBF is bringing up = is a totally separate issue. > It's about how two links can be aggregated for capacity and = reliability boost. > =20 > So, I agree with Sri that this is not a MIF WG issue. > =20 > The MIF problem statement document [RFC6418] enumerates the problems = into 3 categories: > 1. Lack of consistent and distinctive management of configuration = elements, associated with different networks. > 2. Inappropriate mixed use of configuration elements, associated = with different networks, in the course of a particular network activity = / connection. > 3. Use of a particular network, not consistent with the intent of = the scenario / involved parties, leading to connectivity failure and / = or other undesired consequences. > =20 > Alper > =20 > =20 > =20 > =20 > On Nov 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote: >=20 >=20 >=20 > Hi Hui, > =20 > The BBF requirement as presented in the BBF documents and as = interpreted in draft-seite and draft-lhwxz is about enabling a CPE = device to attach to multiple access network and perform flow management. = However, I look at it, I see this this is a mobility requirement and is = really not in the scope of MIF WG. The BBF requirement in question is = all about flow switching or flow splitting across access systems. I'm = not sure why this work belongs MIF and not DMM which is chartered to = handle all mobility use-cases. We have discussed this specific use-case = of flow splitting during MIF formation and explicitly disallowed MIF WG = from taking up such work. The following is the quote from the MIF = chartered text. Also, the MIF WG was primarily looking at issues for a = host attached to multiple access networks, but the hybrid access is = about a CPE attached to multiple networks. I really think this work = should be done in DMM and we did present the requirements in the last = IETF meeting. > =20 > =20 > http://datatracker.ietf.org/wg/mif/charter/ > =20 > No work will be done to enable traffic flows to move from one = interface to another. The group recognizes existing work on mechanisms = that require peer or network support for moving traffic flows such as = RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile = IPv6. This group does not work on or impact such mechanisms. Future work = in this area requires rechartering the working group or asking other, = specialized working groups (such as DHC or 6MAN) to deal with specific = issues. > =20 > =20 > =20 > =20 > Regards > Sri > =20 > From: Hui Deng > Date: Friday, October 31, 2014 4:50 AM > To: Sri Gundavelli , 'Xueli' , = "pierrick.seite@orange.com" , 'Ted Lemon' = , "'STARK, BARBARA H'" , = 'Alexandru Petrescu' > Cc: "mif@ietf.org" > Subject: Follow up with BBF proposal > =20 > Hi everybody > =20 > I am recommending that Xue Li could help to put down the slide for the = problem statement from BBF. > =20 > And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly = to meet together during IETF meeting > to discuss by adding s thelide about how today solutions meet the = requirement or there are some gap still, and whether that problem should = be solvable in IETF. > =20 > Chairs will talk with AD whether MIF or somewhere else will consider = to discuss those issues during the f2f session. > =20 > Best regards, > =20 > -Hui > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail=_C3F30CCA-7960-41B6-B395-80140AB76028 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sure. 

I was just reacting = to the assumption that anything that mentions 2 interfaces automatically = falls under the MIF scope :-)
Also, before this work gets on a = long journey thru the IETF system, people should be aware that Mobile IP = WGs did a lot of work for this space and have = solutions.

FYI.

Alper






On Nov 11, 2014, at 5:52 AM, Hui Deng = wrote:

Hi Alper,
This work hasn=E2=80=99t been clarified where it = should belong to, presenting in MIF doesn=E2=80=99t prevent going to any = other working group.
Let=E2=80=99s focus on the problem and gap analysis = other than where is the place to discuss it.
Thanks
-Hui
 
 mif = [mailto:mif-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Monday, November 10, 2014 = 5:46 PM
To: Xueli
Cc: Brian Haberman; mif@ietf.org
Subject: Re: [mif] Follow up with = BBF proposal
 
Hi Xueli,
 
That's one of the general statements in the = charter. And it covers so many areas, obviously MIF is not chartered to = deal with.
For example, discovery of networks, selection of = networks, authentication, accounting, host configuration, traffic = management, mobility, etc. etc.
The statements I pulled form the charter = pin-points the exact scope of MIF. Anything else is outside the scope, = currently.
 
Alper
 
 
On Nov 11, 2014, at 5:20 AM, Xueli = wrote:


Hello
 
The MIF charter says = like:
"The purpose of the MIF = working group is to describe the architecture detailing how devices = attach to and operate in multiple networks."
I think my presentation cleanly fits this = statement...
 
Best Regards
XUELI
: mif [ =E4=BB=A3=E8=A1=A8 Alper Yegin
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B411=E6=9C=8811=E6=97=A5 10:45
=E6=94=B6=E4=BB=B6=E4=BA=BA: Sri = Gundavelli
=E6=8A=84=E9=80=81: Brian = Haberman; mif@ietf.org
=E4=B8=BB=E9=A2=98: Re: [mif] Follow = up with BBF proposalMIF focuses on the following issues, and the issue BBF is = bringing up is a totally  separate = issue.
It's about how two links can be aggregated for capacity = and reliability boost.
So, I agree with Sri that this is not a MIF WG = issue.
 



 The BBF requirement as presented in the BBF = documents and as interpreted in draft-seite and draft-lhwxz is = about enabling a CPE device to attach to multiple access network and = perform flow management. However, I look at it, I see this this is a = mobility requirement and is really not in the scope of MIF WG. The BBF = requirement in question is all about flow switching or flow splitting = across access systems. I'm not sure why this work belongs MIF and not = DMM which is chartered to handle all mobility use-cases. We have = discussed this specific use-case of flow splitting during MIF formation = and explicitly disallowed MIF WG from taking up such work. The following = is the quote from the MIF chartered text. Also, the MIF WG was primarily = looking at issues for a host attached to multiple access networks, but = the hybrid access is about a CPE attached to multiple networks. I really = think this work should be done in DMM and we did present the = requirements in the last IETF meeting.  
 No work will be done to enable traffic flows = to move from one interface to another. The group recognizes existing = work on mechanisms that require peer or network support for moving = traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of = addresses in Mobile IPv6. This group does not work on or impact such = mechanisms. Future work in this area requires rechartering the working = group or asking other, specialized working groups (such as DHC or 6MAN) = to deal with specific issues.    RegardsSri 

=
= --Apple-Mail=_C3F30CCA-7960-41B6-B395-80140AB76028-- From nobody Mon Nov 10 20:08:52 2014 Return-Path: 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 2B5F51A8845 for ; Mon, 10 Nov 2014 20:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 AINO2mrJj-ks for ; Mon, 10 Nov 2014 20:08:45 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F40F1A88AB for ; Mon, 10 Nov 2014 20:08:45 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id m15so10767808wgh.7 for ; Mon, 10 Nov 2014 20:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=0u2I9ymdArlhta6w8TD5fusTy3bPDuESF8a90g6JKK4=; b=EGmfXxRQe73iKZ3RzgllayuU+JDU5oByi1neL3SQdYlfx3zuGktJniit0ybQ0UGN+A Usw5soazmQ/wT8qwQBBJzKn0oaKXpRS2zxYwzqZH/iBxsolmFDBV8ftWpwQgZniz07WT 8+RlRhg0D8WCR1HeZhgS55kkGWUu515dgqKVaDgrO+k9Fb7pm8wLLsFH3nPxxfMBnoKE j3iYJK7X590heeMZG1WgdtFPA0Tvl/uC3WhwHzQfqQNlNkjmlZqXgVumcL3U7AtrQNft tAnAUBt1u4SfKXztFO4icpITKnu4sa+xGLNUyPGeRv0CmwfhuXcXPfYcUTYncq7TS1Y2 c7hg== X-Received: by 10.180.73.212 with SMTP id n20mr36086705wiv.59.1415678923325; Mon, 10 Nov 2014 20:08:43 -0800 (PST) Received: from t2001067c0370015255c29f06eb7715c8.eduroam.v6.meeting.ietf.org (t2001067c0370015255c29f06eb7715c8.eduroam.v6.meeting.ietf.org. [2001:67c:370:152:55c2:9f06:eb77:15c8]) by mx.google.com with ESMTPSA id g16sm14618484wjq.20.2014.11.10.20.08.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 20:08:42 -0800 (PST) From: Margaret Wasserman Content-Type: multipart/alternative; boundary="Apple-Mail=_30650F28-B0E4-4CFF-A33C-25AF5D02C0B4" Message-Id: <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Mon, 10 Nov 2014 18:08:37 -1000 References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> To: "mif@ietf.org List" In-Reply-To: <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/mif/7XKGPZTTuQZZnEEDbImovm6br9w Subject: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 04:08:47 -0000 --Apple-Mail=_30650F28-B0E4-4CFF-A33C-25AF5D02C0B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Let me see if I can start a technical discussion here... If you have an ISP today that has two different access networks = available, such as one 3GPP network and one DSL network, how do(es) the = gateway box(es) (connected to both networks) decide where it should send = each packet it receives? I think there are several possible cases here; (1) There is one gateway attached to both outbound networks. This has = two sub-cases: (1.1) Hosts behind the single gateway have separate addresses on the two = attached networks. In that case, the gateway is constrained to send = packets over the outgoing network that uses the address prefix that = matches the source address, or the packets will be thrown away by = ingress filters on the other side. So, the network choice is made by = the hosts. (1.2) Hosts behind the gateway have only one address each. This has two = sub-cases: (1.2.1) The gateway has separate addresses on the two networks, and does = some sort of translation from internal to external addresses in the = prefix of the "right" outgoing link. (1.2.2) The gateway has only one IP address that is somehow shared = across the two links. (2) There are two gateways, each attached to a single outbound network. = In this case, hosts will always have separate addresses for the two = networks, and will need to make a decision about which outbound network = to use.=20 Cases 1.1 and 2 are essentially the same from a host standpoint, in that = the host needs to make a network choice. This is a problem we have = discussed in MIF -- What sort of information does/should the host need = to make that choice, and how is that information communicated to the = host? =20 Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for = multi-homing. The IETF generally prefers to avoid recommending = solutions that use NAT, but do we have a better answer? Case 1.2.2 becomes a layer 2 problem and is probably outside the scope = of the IETF. Are there cases that I am missing here? Margaret --Apple-Mail=_30650F28-B0E4-4CFF-A33C-25AF5D02C0B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

(1.2.2) The gateway has only one IP = address that is somehow shared across the two = links.

(2)  There are two gateways, each = attached to a single outbound network.  In this case, hosts will = always have separate addresses for the two networks, and will need to = make a decision about which outbound network to = use. 

Cases 1.1 and 2 are essentially the = same from a host standpoint, in that the host needs to make a network = choice.  This is a problem we have discussed in MIF -- What sort of = information does/should the host need to make that choice, and how is = that information communicated to the host? =  

Case 1.2.1 is a typical case of how NAT = (or NPTv6) can be used for multi-homing.  The IETF generally = prefers to avoid recommending solutions that use NAT, but do we have a = better answer?

Case 1.2.2 becomes a layer 2 = problem and is probably outside the scope of the = IETF.

Are there cases that I am missing = here?

Margaret





= --Apple-Mail=_30650F28-B0E4-4CFF-A33C-25AF5D02C0B4-- From nobody Mon Nov 10 20:30:20 2014 Return-Path: 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 30B671ACE91 for ; Mon, 10 Nov 2014 20:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] 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 9054IZFoS_Eg for ; Mon, 10 Nov 2014 20:30:16 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB9A1A88F0 for ; Mon, 10 Nov 2014 20:30:16 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E15D82009E; Mon, 10 Nov 2014 23:32:16 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D253F637F4; Mon, 10 Nov 2014 23:30:14 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B99BA637EA; Mon, 10 Nov 2014 23:30:14 -0500 (EST) From: Michael Richardson To: Margaret Wasserman In-Reply-To: <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/mif/dcFgJz_mqnz6HFl_YF1wUvPYNKY Cc: "mif@ietf.org List" Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 04:30:19 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Margaret Wasserman wrote: > Let me see if I can start a technical discussion here... > If you have an ISP today that has two different access networks > available, such as one 3GPP network and one DSL network, how do(es) t= he > gateway box(es) (connected to both networks) decide where it should > send each packet it receives? I think there are several possible cas= es > here; These scenarios are all in the homenet architecture document, btw. Can you tell me if this is IPv4+NAPT or IPv6? (The IPv4 case without NAPT = is mostly the same as IPv6) > (1.2) Hosts behind the gateway have only one address each. This has > two sub-cases: > (1.2.1) The gateway has separate addresses on the two networks, and > does some sort of translation from internal to external addresses in > the prefix of the "right" outgoing link. NAPT. > (1.2.2) The gateway has only one IP address that is somehow shared > across the two links. MPPE or equivalent. Can you tell me if in your scenarios, the operator of the two access networ= ks is the same?=20 > (2) There are two gateways, each attached to a single outbound networ= k. > In this case, hosts will always have separate addresses for the two > networks, and will need to make a decision about which outbound netwo= rk > to use. As you say, this is a kind of MIF with multi-provisioning domains, and if the host can decide the right choice of source address, the rest is "solved" by homenet already. > Cases 1.1 and 2 are essentially the same from a host standpoint, in > that the host needs to make a network choice. This is a problem we > have discussed in MIF -- What sort of information does/should the host > need to make that choice, and how is that information communicated to > the host? Yes, I agree. > Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for > multi-homing. The IETF generally prefers to avoid recommending > solutions that use NAT, but do we have a better answer? > Case 1.2.2 becomes a layer 2 problem and is probably outside the scope > of the IETF. > Are there cases that I am missing here? I am trying to think whether embedding a second layer of the problem in the scenario changes anything significantly. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGGQ04CLcPvd0N1lAQKPnggAmCvgYNmARy0HgjOgAzSkQkGIZdDt6pn2 DXhESsFQrkKsqUUy3NE9NT0tHeIU7AMZhmQL4TNIjKPDJ383D9eOQwoYBgqcCMR/ GtvKdnb6R854NeGfaDdgwrSUagj0Nsq2PO2IJfWo2L5RDDhBtoKIrlr3evz31hoJ DRda/c7EpXr1s5M9+BIQTrgpXHCIWbmVLEO8Ap9dOk0K2GQOcU48pmgXLvfYyJAN bsPQXflKDd9pkUrREBddaYPHCIKBPGYZXuVpD3sKZGu9RdX8dXWIJVx6yClWIxd4 pDS5DEL9ib6nE5OAoc0xGdbkofM/9Bt8Xi/oxCWD1xhysmYZxhib3w== =Exxv -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 10 21:04:57 2014 Return-Path: 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 000551AD520 for ; Mon, 10 Nov 2014 21:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 jQ6IG5-VqJLi for ; Mon, 10 Nov 2014 21:04:39 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E86D1AD564 for ; Mon, 10 Nov 2014 21:04:39 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 71C1BDA01AA for ; Tue, 11 Nov 2014 05:09:07 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 38E1A53E07E; Mon, 10 Nov 2014 21:04:09 -0800 (PST) Received: from nat64.meeting.ietf.org (31.130.238.135) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 10 Nov 2014 21:04:08 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <28162.1415680214@sandelman.ca> Date: Mon, 10 Nov 2014 19:04:04 -1000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> <28162.1415680214@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.135] Archived-At: http://mailarchive.ietf.org/arch/msg/mif/MIExTw30eIi2cFqn3EF5EqZm1i8 Cc: "mif@ietf.org List" Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 05:04:47 -0000 On Nov 10, 2014, at 6:30 PM, Michael Richardson = wrote: > As you say, this is a kind of MIF with multi-provisioning domains, and > if the host can decide the right choice of source address, the rest is > "solved" by homenet already. Not to rain on your parade, but at the moment with a total of one RFC, = homenet isn't solving anything. Hopefully that will change, but I = object to referring to that as a fait accompli. From nobody Mon Nov 10 22:12:42 2014 Return-Path: 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 1A3E41ACDC6 for ; Mon, 10 Nov 2014 21:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] 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 2GHNkqcRLHy1 for ; Mon, 10 Nov 2014 21:43:46 -0800 (PST) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960321ACD85 for ; Mon, 10 Nov 2014 21:43:46 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id x3so6859985qcv.4 for ; Mon, 10 Nov 2014 21:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5FbUgrBQLs9kCobTGwY1ecoGKfq5yZorRsudYP+j0Eo=; b=DNtxt4Vp0uBIfEv3i9zFy1GeTTnCnzUmox5m1EEtqWoMGy3PpL5lqJ01SdGjRKafwo WT17BkYc3Z/87SQaa4br/TZ3+p2rk88PFjQHpAtWkTBj4DSTaVD91qUsQejW7od8er5/ mysv1enEIQvHm5nGnnVcDwEgBmAr2hEdIke4mYEY2vZkg1F4/vSiOafhd04QoA+zQEjC 68tmm1k5xWbAv3Y4Yy2TvQ3cSgy01jXStMsQGYDgrYzLI7SIPNYUNwKTKcd8UFOsapev ddVYIlyOvg8BCj+wGPE42pfXfLdZK/dUGV+3jaFenCgagQY+ayznquVFrRiZM5iYeEDx wEdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5FbUgrBQLs9kCobTGwY1ecoGKfq5yZorRsudYP+j0Eo=; b=jCIp46l3fNb+ImeNWxwy6d7Z4W9vbQT+2FPAlE7TCwHgCcvHkDhAC77GPZQ+fMYb9m a5mEKx5UOCCHEBVYLoJcqyH1VUnsQCocUtZxXnsavv4CUYGj99qu0n24rnu7BWagIpH3 NVMmOfDUF7wn2I+seoC/PPcIBwwjOJAMhdoSlaTRL1CurpQoXEhLA1vL4yRuYTXjroiV 5ZLpuC16OpI1vQeAcKkszrFxQq6+dvqocpEu2Us7s3cwa4QpGcvdw3KqYssDWvrrq4tV aoFkGvVScy+lKUQxf4Vk570Xy2Tb75w/pjibGjf646Re/0GXCmyXAbaMY/plzhm2AJSc xKbg== X-Gm-Message-State: ALoCoQnNUIWoKANQh8sULFl8XawOO7IEdMJ7sU1wyLTSWfo4VcWwn4Nz9e5SXR/+J2ZmkzaeX1hc X-Received: by 10.229.115.7 with SMTP id g7mr50014960qcq.2.1415684625728; Mon, 10 Nov 2014 21:43:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.247.196 with HTTP; Mon, 10 Nov 2014 21:43:25 -0800 (PST) In-Reply-To: <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> From: Erik Kline Date: Mon, 10 Nov 2014 19:43:25 -1000 Message-ID: To: Margaret Wasserman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/5jloZ6r0oo60Z2XHsqaHq6zbHaM X-Mailman-Approved-At: Mon, 10 Nov 2014 22:12:40 -0800 Cc: "mif@ietf.org List" Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 05:43:48 -0000 > (1.1) Hosts behind the single gateway have separate addresses on the two > attached networks. In that case, the gateway is constrained to send packets > over the outgoing network that uses the address prefix that matches the > source address, or the packets will be thrown away by ingress filters on the > other side. So, the network choice is made by the hosts. I'm not sure this a given. If both networks are run by the same operator, it's entirely possible that there might not be any BCP38 internally. (...maybe even desirable?...) From nobody Mon Nov 10 22:20:53 2014 Return-Path: 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 E5C0D1A1A19 for ; Mon, 10 Nov 2014 22:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_25=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 l4l4EwrQAey2 for ; Mon, 10 Nov 2014 22:20:37 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B651ACD87 for ; Mon, 10 Nov 2014 22:20:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAB6KUhE032316; Tue, 11 Nov 2014 07:20:30 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1ADB6200D1F; Tue, 11 Nov 2014 07:20:47 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0A75A2007F2; Tue, 11 Nov 2014 07:20:47 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.23]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAB6JxVH029613; Tue, 11 Nov 2014 07:20:28 +0100 Message-ID: <5461AA8E.8060007@gmail.com> Date: Tue, 11 Nov 2014 07:19:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Alper Yegin , Hui Deng References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <01FE63842C181246BBE4CF183BD159B44903A41B@nkgeml504-mbx.china.huawei.com> <9ED11710-4F49-4602-84E2-49B9E17B1FE1@yegin.org> <001a01cffd62$f38b9ff0$daa2dfd0$@com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mif/RGwYNCrePE4tHvTrgaCcBYG9QnA Cc: 'Brian Haberman' , mif@ietf.org Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 06:20:45 -0000 Le 11/11/2014 04:59, Alper Yegin a écrit : > Sure. > > I was just reacting to the assumption that anything that mentions 2 > interfaces automatically falls under the MIF scope :-) > Also, before this work gets on a long journey thru the IETF system, > people should be aware that Mobile IP WGs did a lot of work for this > space and have solutions. Sure, but here the reqs are different. Actually I'd go as far as to say that MIP WG did in the past a lot of work without requirements, including the flow-based management schemes. Alex > > FYI. > > Alper > > > > > > > On Nov 11, 2014, at 5:52 AM, Hui Deng wrote: > >> Hi Alper, >> This work hasn’t been clarified where it should belong to, presenting >> in MIF doesn’t prevent going to any other working group. >> Let’s focus on the problem and gap analysis other than where is the >> place to discuss it. >> Thanks >> -Hui >> *From:*mif [mailto:mif-bounces@ietf.org]*On Behalf Of*Alper Yegin >> *Sent:*Monday, November 10, 2014 5:46 PM >> *To:*Xueli >> *Cc:*Brian Haberman; mif@ietf.org >> *Subject:*Re: [mif] Follow up with BBF proposal >> Hi Xueli, >> That's one of the general statements in the charter. And it covers so >> many areas, obviously MIF is not chartered to deal with. >> For example, discovery of networks, selection of networks, >> authentication, accounting, host configuration, traffic management, >> mobility, etc. etc. >> The statements I pulled form the charter pin-points the exact scope of >> MIF. Anything else is outside the scope, currently. >> Alper >> On Nov 11, 2014, at 5:20 AM, Xueli wrote: >> >> >> Hello >> The MIF charter says like: >> */"/**/The purpose of the MIF working group is to describe the >> architecture detailing how devices attach to and operate in multiple >> networks." >> /*I think my presentation cleanly fits this statement... >> Best Regards >> XUELI >> *å‘件人:*mif [mailto:mif-bounces@ietf.org]*代表*Alper Yegin >> *å‘é€æ—¶é—´:*2014å¹´11月11æ—¥10:45 >> *收件人:*Sri Gundavelli >> *抄é€:*Brian Haberman;mif@ietf.org >> *主题:*Re: [mif] Follow up with BBF proposal >> MIF focuses on the following issues, and the issue BBF is bringing up >> is a totally separate issue. >> It's about how two links can be aggregated for capacity and >> reliability boost. >> So, I agree with Sri that this is not a MIF WG issue. >> The MIF problem statement document [RFC6418 >> ] enumerates the problems into 3 >> categories: >> 1. Lack of consistent and distinctive management of configuration >> elements, associated with different networks. >> 2. Inappropriate mixed use of configuration elements, associated >> with different networks, in the course of a particular network >> activity / connection. >> 3. Use of a particular network, not consistent with the intent of >> the scenario / involved parties, leading to connectivity failure and / >> or other undesired consequences. >> Alper >> On Nov 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote: >> >> >> >> Hi Hui, >> The BBF requirement as presented in the BBF documents and as >> interpreted in draft-seite and draft-lhwxz is about enabling a CPE >> device to attach to multiple access network and perform flow >> management. However, I look at it, I see this this is a mobility >> requirement and is really not in the scope of MIF WG. The BBF >> requirement in question is all about flow switching or flow splitting >> across access systems. I'm not sure why this work belongs MIF and not >> DMM which is chartered to handle all mobility use-cases. We have >> discussed this specific use-case of flow splitting during MIF >> formation and explicitly disallowed MIF WG from taking up such work. >> The following is the quote from the MIF chartered text. Also, the MIF >> WG was primarily looking at issues for a host attached to multiple >> access networks, but the hybrid access is about a CPE attached to >> multiple networks. I really think this work should be done in DMM and >> we did present the requirements in the last IETF meeting. >> *http://datatracker.ietf.org/wg/mif/charter/* >> *No work will be done to enable traffic flows to move from one >> interface to another. The group recognizes existing work on mechanisms >> that require peer or network support for moving traffic flows such as >> RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile >> IPv6. This group does not work on or impact such mechanisms. Future >> work in this area requires rechartering the working group or asking >> other, specialized working groups (such as DHC or 6MAN) to deal with >> specific issues.* >> Regards >> Sri >> *From:*Hui Deng > >> *Date:*Friday, October 31, 2014 4:50 AM >> *To:*Sri Gundavelli >, >> 'Xueli' >, >> "pierrick.seite@orange.com " >> >, 'Ted >> Lemon' >, >> "'STARK, BARBARA H'" >, >> 'Alexandru Petrescu' > > >> *Cc:*"mif@ietf.org " > > >> *Subject:*Follow up with BBF proposal >> Hi everybody >> I am recommending that Xue Li could help to put down the slide for the >> problem statement from BBF. >> And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly >> to meet together during IETF meeting >> to discuss by adding s thelide about how today solutions meet the >> requirement or there are some gap still, and whether that problem >> should be solvable in IETF. >> Chairs will talk with AD whether MIF or somewhere else will consider >> to discuss those issues during the f2f session. >> Best regards, >> -Hui >> _______________________________________________ >> 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 > From nobody Mon Nov 10 22:26:44 2014 Return-Path: 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 83F2F1A6F6F for ; Mon, 10 Nov 2014 22:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 sBct-mBY1w6u for ; Mon, 10 Nov 2014 22:26:40 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2921AD079 for ; Mon, 10 Nov 2014 22:26:38 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAB6QaMu003082 for ; Tue, 11 Nov 2014 07:26:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7D1F1200E8C for ; Tue, 11 Nov 2014 07:26:52 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7552C2007F2 for ; Tue, 11 Nov 2014 07:26:52 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.23]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAB6QQ2b015603 for ; Tue, 11 Nov 2014 07:26:35 +0100 Message-ID: <5461AC11.8070600@gmail.com> Date: Tue, 11 Nov 2014 07:26:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mif@ietf.org References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> In-Reply-To: <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mif/Gl3LH07pqbiVWXl_RM_6A72DwoE Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 06:26:42 -0000 Le 11/11/2014 05:08, Margaret Wasserman a écrit : > > > Let me see if I can start a technical discussion here... > > If you have an ISP today that has two different access networks > available, such as one 3GPP network and one DSL network, how do(es) the > gateway box(es) (connected to both networks) decide where it should send > each packet it receives? I think there are several possible cases here; > > (1) There is one gateway attached to both outbound networks. This has > two sub-cases: > > (1.1) Hosts behind the single gateway have separate addresses on the two > attached networks. In that case, the gateway is constrained to send > packets over the outgoing network that uses the address prefix that > matches the source address, or the packets will be thrown away by > ingress filters on the other side. So, the network choice is made by > the hosts. > > (1.2) Hosts behind the gateway have only one address each. This has two > sub-cases: > > (1.2.1) The gateway has separate addresses on the two networks, and does > some sort of translation from internal to external addresses in the > prefix of the "right" outgoing link. I agree with most points above. > > (1.2.2) The gateway has only one IP address that is somehow shared > across the two links. I think this is hardly possible, in the context of this CPE scenario. Even though operators recently are able to control both cellular and DSL offerings to end users they really have distinct networks for each. 'Distinct' in that they are very remote one from another in terms of IP hops - makes it hard to have a common IP address shared across two egress links of CPE. Unless of course we speak tunnels. > (2) There are two gateways, each attached to a single outbound network. > In this case, hosts will always have separate addresses for the two > networks, and will need to make a decision about which outbound network > to use. This is a difficult case as well but here I think we talk one single CPE with multiple egress interfaces. I think we need to clarify this. > Cases 1.1 and 2 are essentially the same from a host standpoint, in that > the host needs to make a network choice. This is a problem we have > discussed in MIF -- What sort of information does/should the host need > to make that choice, and how is that information communicated to the host? And, alternatively, how does the host make such choices and communicate them to the network. And, alt2, how does the CPE make choices and communicate them to its upper gateways. > > Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for > multi-homing. The IETF generally prefers to avoid recommending > solutions that use NAT, but do we have a better answer? Yes tunnelling. Alex > > Case 1.2.2 becomes a layer 2 problem and is probably outside the scope > of the IETF. > > Are there cases that I am missing here? > > Margaret > > > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Tue Nov 11 01:19:04 2014 Return-Path: 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 29DBC1A6F96 for ; Tue, 11 Nov 2014 01:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 uLvNN5RBWTxT for ; Tue, 11 Nov 2014 01:18:46 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120BF1A1B75 for ; Tue, 11 Nov 2014 01:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3229; q=dns/txt; s=iport; t=1415697526; x=1416907126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7gOBn4hFMJn3hqY1kitezc1T3RjchG5qqMlLlzvhvNI=; b=Juxcwd4cmneq96+om3RvCEaaaKUCtcS4KYump1X9oL+SzP82wkivhkGR wbiBaQ88Jse3ejU3PWkhPOR0Se+1KSss/dZV2pByFOHD+XyJiG4+/1IAm FHRCZZVvSxt1ZPiLSgVInPFUqwMNsjo5l+DY2dsAInWw0+cXzDLwoQ56P Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAE7UYVStJV2Z/2dsb2JhbABSCoMOgS0E01ECgR0WAQEBAQF9hAIBAQEDAToxBwcFBwQCAQgRBAEBHwkHMhQJCAIEAQ0FG4gdCcxlAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5A4XAcGhEUBBJIxi3SWYIN6bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,359,1413244800"; d="scan'208";a="371134178" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 11 Nov 2014 09:18:39 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAB9IcLS014230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 09:18:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.32]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 03:18:38 -0600 From: "Sri Gundavelli (sgundave)" To: Hui Deng , "'Ted Lemon'" Thread-Topic: Follow up with BBF proposal Thread-Index: AQHP/ZB6Wa/8PQlUKkaI0q2EH9MMrA== Date: Tue, 11 Nov 2014 09:18:38 +0000 Message-ID: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> <002c01cffd58$18276ca0$487645e0$@com> In-Reply-To: <002c01cffd58$18276ca0$487645e0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.114.240] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/VgjsCJ_gQIFoiFxMP2keY5HWFo4 Cc: 'Brian Haberman' , "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:18:50 -0000 (We have started the technical discussion, but I do want to respond to this) Hi Hui, > Current MIF charter prevent MIF from working on flow switch which is >mostly mobile ip/dmm based solution, but it doesn't disallow MIF to work >on flow split and per packet delivery. You are saying the charter disallows splitting of flows across two access networks, but it allows splitting of a single flow ? What is the logic here ? So, this requirement does not match the prior work because the flow policy is different ? That's the only reason why we should look at this as a different problem from the work that was done in the past ? Per-packet load balancing is probably not explicitly stated as transport group was never in favor of splitting a single flow across two access links with different transmission properties (latency, packet loss and jitter) as that will result in peers requiring to deal with re-odering/buffering issues. General recommendation was not to split a single flow, and so the MIP WG always kept the flow definition at the granularity of a flow-level and not at a packet level. But, in any case that's just a policy that is exchanged between two peers. Regards Sri On 11/10/14 6:34 PM, "Hui Deng" wrote: >Hi Sri, > >Current MIF charter prevent MIF from working on flow switch which is >mostly mobile ip/dmm based solution, >but it doesn't disallow MIF to work on flow split and per packet >delivery. This is the key point that PS should explain the clearly. > >-Hui > >-----Original Message----- >From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] >Sent: Monday, November 10, 2014 4:23 PM >To: Ted Lemon >Cc: STARK, BARBARA H; Hui Deng; mif@ietf.org; Brian Haberman; Jouni >Korhonen; pierrick.seite@orange.com; Dapeng Liu >Subject: Re: Follow up with BBF proposal > >Hi Ted, > >Having a discussion in MIF WG sounds reasonable to me. > >Regarding homenet relation, I'm not sure it belongs to that WG either. >The focus of the homenet is on ingress networks and for realizing >simplified configurations and that has no relation to access selection on >egress paths. FWIW, this work is very much related to what the MIP >working group have been doing for many years. Sure, the device in case of >BBF is a fixed device, but the fundamental requirements are about access >selection, flow mobility and policy exchange. The flow mobility / MCOA >work in MIP working groups have done significant amount of work in this >area and the expertise is in that group. > >If the reason for steering this work away from DMM is due the belief that >we will apply only MIP-based solution, I'd say the group will certainly >do that, but the WG may also agree to additional solution/protocol >mechanisms. Also, IETF is in no position to pick one protocol/solution >for this requirement. It is probably reasonable for IETF to identify a >set of solutions and present analysis on each of the solutions and that >can be the basis for the BBF to review and pick one or more solutions. >But, either way I believe the expertise around this topic is in DMM WG >and not in homenet or in MIF WG's. > >Regards >Sri From nobody Tue Nov 11 01:19:09 2014 Return-Path: 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 B7EE11A888D for ; Tue, 11 Nov 2014 01:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 YyGG0kZ33XPR for ; Tue, 11 Nov 2014 01:18:46 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB5D1A1BDF for ; Tue, 11 Nov 2014 01:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25951; q=dns/txt; s=iport; t=1415697526; x=1416907126; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2ORustIuY90QWwFoN2jXDv/Z3b6GKfaEONtYTiSlE18=; b=Lm/abpLLSgcobo9GiLhs2Al9UPhMrcTKwdji+nCvEzPK4IX0CcIDlGC7 OLJ3qohaJqbBQIpjOcc/yNYvrS0+AwBJMfLO6zgHi8vyL68XozxwhH0vf 3UCM9n1Zgumxll52Dn5kELuqJuE5csM9ak3mGCKxHhecnQ5wTDlKkzcWD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACfTYVStJA2G/2dsb2JhbABcgkhGgS0E01ECgR0WAQEBAQF9hAIBAQEDAWcXCwIBCBEDAQIhBwchERQJCAIEARIbiBEDCQnGBA2GUwEBAQEBAQQBAQEBAQEBARqOW4IoFwGESwWSMYlighKBNINPimyGcYN6bIFIgQMBAQE X-IronPort-AV: E=Sophos; i="5.07,359,1413244800"; d="scan'208,217"; a="95422029" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 11 Nov 2014 09:18:45 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAB9IiJd002879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 09:18:44 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.32]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 03:18:44 -0600 From: "Sri Gundavelli (sgundave)" To: Margaret Wasserman , "mif@ietf.org List" Thread-Topic: [mif] Hybrid Access Problem Thread-Index: AQHP/ZB9mXHfbIfmP0WSyzs1ET1AQA== Date: Tue, 11 Nov 2014 09:18:44 +0000 Message-ID: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> In-Reply-To: <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.114.240] Content-Type: multipart/alternative; boundary="_000_D087026C178115sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/2sC2OYjEOiwvuHA5z7Lr_bPMubc Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:18:51 -0000 --_000_D087026C178115sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > If you have an ISP today that has two different access networks available= , such as one 3GPP network and one DSL network, how do(es) the gateway box(= es) (connected to both networks) decide where it should send each packet it= receives? I think there are several possible cases here; The IP address/prefix that is given to the PDN connection of the mobile no= de is topologically anchored on the PGW and the IP traffic that is routed= on the 3GPP link is ONLY the traffic using the source address/prefixes ass= ociated with that PDN connection. All the functions in the 3GPP network inc= luding QoS, charging ..etc is only for that IP address/prefix. For the case where the mobile node is a mobile router, we have specified su= pport for prefix delegation in 3GPP Rel-12, where the mobile router can obt= ain a set of delegated prefixes for its ingress networks. But even those de= legated prefixes and the IP address/prefix on the primary PDN connection MU= ST be part of a single aggregate block and that aggregate block is again to= pologically anchored on the PGW. So, the IP traffic that is routed and seen= on the 3GPP link is only the traffic associated with that PDN connection. For all other cases such as where the IP prefixes in the ingress network be= hind the mobile router not belonging to the 3GPP network, either those pac= kets must NAT/PAT translated, or carried over an overlay tunnel (GRE/UDP) = path. In the later case the ingress prefixes are hidden from the transport = network and so the 3GPP network does not care about those prefixes. It neve= r sees them. Now, if we map this to NEMO use-case, it is exactly the case of a mobile ro= uter connected to two access networks; The ingress prefixes behind the mobi= le router are prefixes anchored on the mobility anchor (HA/LMA/PGW) and the= traffic from the ingress network is tunneled to the anchor. An overlay tun= nel path is set up between the MR and the HA and the overlay topology is hi= dden from the transport network. Please see inline Regards Sri From: Margaret Wasserman > Date: Monday, November 10, 2014 8:08 PM To: "mif@ietf.org List" > Subject: [mif] Hybrid Access Problem Let me see if I can start a technical discussion here... If you have an ISP today that has two different access networks available, = such as one 3GPP network and one DSL network, how do(es) the gateway box(es= ) (connected to both networks) decide where it should send each packet it r= eceives? I think there are several possible cases here; [Sri] Not sure, I followed the below conclusions or the assumptions. But, I= will try. (1) There is one gateway attached to both outbound networks. This has two = sub-cases: [Sri] Ok (1.1) Hosts behind the single gateway have separate addresses on the two at= tached networks. In that case, the gateway is constrained to send packets = over the outgoing network that uses the address prefix that matches the sou= rce address, or the packets will be thrown away by ingress filters on the o= ther side. So, the network choice is made by the hosts. [Sri] Hosts can have addresses belonging to the access network, or they can= be from the anchor in the home network. For the later case, there can be a= n overlay topology. The gateway can potentially tunnel the packet to an anc= hor (Ex: BNG) and in that case the ingress side network prefixes are hidden= from the transport network. (1.2) Hosts behind the gateway have only one address each. This has two su= b-cases: [Sri] The gateway can include multiple prefixes in the RA sent on the ingre= ss link and so the hosts CAN have multiple IP addresses/prefixes. (1.2.1) The gateway has separate addresses on the two networks, and does so= me sort of translation from internal to external addresses in the prefix of= the "right" outgoing link. [Sri] Translation is one option for the case where the addresses are privat= e address relevant only on that link. Tunneling is another option when the = addresses belong to a remote gateway. There is also the third option, where= the ingress prefixes are from the access network and there is normal routi= ng. (1.2.2) The gateway has only one IP address that is somehow shared across t= he two links. [Sri] Not sure, how its possible. The IP address given for the LTE connecti= on cannot be the IP address given on the DSL link. The connection is tied = to a IMSI and that cannot be on two different gateways. (2) There are two gateways, each attached to a single outbound network. I= n this case, hosts will always have separate addresses for the two networks= , and will need to make a decision about which outbound network to use. [Sri] Not sure, how the host with a single interface is attached to two gat= eways simultaneously ? Is the host again another router ? Cases 1.1 and 2 are essentially the same from a host standpoint, in that th= e host needs to make a network choice. This is a problem we have discussed= in MIF -- What sort of information does/should the host need to make that = choice, and how is that information communicated to the host? [Sri] This is nothing to with the host. Its about the addressing and the ow= nership of the addressing that is enabled on that link. This is a network d= ecision and not a host decision. Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for multi-ho= ming. The IETF generally prefers to avoid recommending solutions that use = NAT, but do we have a better answer? [Sri] NAT is an option, but there are other modes. 1. Allocate prefixes from a remote anchor and set up tunneling to that a= nchor 2. Enable routing for the ingress prefixes in the transport network; Mak= e them routable in the transport network (Ex: Rel-12 3GPP PD Work). Case 1.2.2 becomes a layer 2 problem and is probably outside the scope of t= he IETF. Are there cases that I am missing here? [Sri] Not sure I agree with the conclusions. Margaret --_000_D087026C178115sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
> If you have an ISP today that has two different access networks a= vailable, such as one 3GPP network and one DSL network, how do(es) the gate= way box(es) (connected to both networks) decide where it should send each p= acket it receives?  I think there are several possible cases here;

The IP address/prefix that is given to the  PDN connection of the mobi= le node  is topologically anchored on the PGW  and the IP traffic= that is routed on the 3GPP link is ONLY the traffic using the source addre= ss/prefixes associated with that PDN connection. All the functions in the 3GPP network including QoS, charging ..etc is onl= y for that IP address/prefix.

For the case where the mobile node is a mobile router, we have specified su= pport for prefix delegation in 3GPP Rel-12, where the mobile router can obt= ain a set of delegated prefixes for its ingress networks. But even those de= legated prefixes and the IP address/prefix on the primary PDN connection MUST be part of a single aggregate block and= that aggregate block is again topologically anchored on the PGW. So, the I= P traffic that is routed and seen on the 3GPP link is only the traffic asso= ciated with that PDN connection.

For all other cases such as where the IP prefixes in the ingress network be= hind the mobile router not belonging to the 3GPP network,  either thos= e packets must NAT/PAT translated, or carried over an overlay tunnel  = (GRE/UDP) path. In the later case the ingress prefixes are hidden from the transport network and so the 3GPP network doe= s not care about those prefixes. It never sees them.

Now, if we map this to NEMO use-case, it is exactly the case of a mobile ro= uter connected to two access networks; The ingress prefixes behind the mobi= le router are prefixes anchored on the mobility anchor (HA/LMA/PGW) and the= traffic from the ingress network is tunneled to the anchor. An overlay tunnel path is set up between t= he MR and the HA and the overlay topology is hidden from the transport netw= ork. 

Please see inline 


Regards
Sri


From: Margaret Wasserman <margaretw42@gmail.com>
Date: Monday, November 10, 2014 8:0= 8 PM
To: "mif@ietf.org List" <mif@= ietf.org>
Subject: [mif] Hybrid Access Proble= m



Let me see if I can start a technical discussion here...

If you have an ISP today that has two different access networks availa= ble, such as one 3GPP network and one DSL network, how do(es) the gateway b= ox(es) (connected to both networks) decide where it should send each packet= it receives?  I think there are several possible cases here;

[Sri] Not sure, I followed the below conclusions= or the assumptions. But, I will try.


(1) There is one gateway attached to both outbound networks.  Thi= s has two sub-cases:

[Sri] Ok

(1.1) Hosts behind the single gateway have separate addresses on the t= wo attached networks.  In that case, the gateway is constrained to sen= d packets over the outgoing network that uses the address prefix that match= es the source address, or the packets will be thrown away by ingress filters on the other side.  So, the ne= twork choice is made by the hosts.

[Sri] Hosts can have addresses belonging to the = access network, or they can be from the anchor in the home network. For the= later case, there can= be an overlay topology. The gateway can potentially tunnel the packet to an anchor (Ex: BNG) and in that case the = ingress side network prefixes are hidden from the transport network. <= /b>


(1.2) Hosts behind the gateway have only one address each.  This = has two sub-cases:

[Sri] The gateway can include multiple prefixes = in the RA sent on the ingress link and so the hosts CAN have multiple IP ad= dresses/prefixes.


(1.2.1) The gateway has separate addresses on the two networks, and do= es some sort of translation from internal to external addresses in the pref= ix of the "right" outgoing link.

[Sri] Translation is one option for the case where = the addresses are private address relevant only on that link. Tunneling is = another option when the addresses belong to a remote gateway. There is also the third option, where the ingress prefix= es are from the access network and there is normal routing.


(1.2.2) The gateway has only one IP address that is somehow shared acr= oss the two links.

[Sri] Not sure, how its possible. The IP address= given for the LTE connection cannot be the  IP address given on the D= SL link. The connectio= n is tied to a IMSI and that cannot be on two different gateways.


(2)  There are two gateways, each attached to a single outbound n= etwork.  In this case, hosts will always have separate addresses for t= he two networks, and will need to make a decision about which outbound netw= ork to use. 

[Sri] Not sure, how the host with a single inter= face is attached to two gateways simultaneously ? Is the host again another= router ?


Cases 1.1 and 2 are essentially the same from a host standpoint, in th= at the host needs to make a network choice.  This is a problem we have= discussed in MIF -- What sort of information does/should the host need to = make that choice, and how is that information communicated to the host?  

[Sri] This = is nothing to with the host. Its about the addressing and the ownership of = the addressing that is enabled on that link. This is a network decision and= not  a host decision.


Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for mul= ti-homing.  The IETF generally prefers to avoid recommending solutions= that use NAT, but do we have a better answer?

[Sri] NAT i= s an option, but there are other modes.
  1. Allocate prefixes from a remote anchor and s= et up tunneling to that anchor
  2. <= b>Enable routing for the ingress prefixes in the transport network; Make th= em routable in the transport network (Ex: Rel-12 3GPP PD Work). 

Case 1.2.2 becomes a layer 2 problem a= nd is probably outside the scope of the IETF.


Are there cases that I am missing here?

[Sri] Not sure I agree with the conclusions= .


Margaret





 --_000_D087026C178115sgundaveciscocom_-- From nobody Tue Nov 11 01:31:52 2014 Return-Path: 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 BD50F1A8842 for ; Tue, 11 Nov 2014 01:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 OOm7JEYiUjc4 for ; Tue, 11 Nov 2014 01:31:49 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE81D1A1AE7 for ; Tue, 11 Nov 2014 01:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27544; q=dns/txt; s=iport; t=1415698309; x=1416907909; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=QDdbQ37TCV8wU7gtpRjx32Q8KHIJvhW+asbI/DJrMyU=; b=mTh/93EUzQ2PwspWMaUReXVAGVQqMbRAEd7QY0HI/PZr5qf6G6kOORai mXW40lpt7M7uRM02usUCT2OWjSXW4NpHd2/zQLUlejPTekY+0PJQ1Oqlh sx1n2IF/LU7T4HdjIf/y6hAa7vLaAiSHyIXkhuX6XO1j2KOMa3MBFXzBh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAKzWYVStJV2d/2dsb2JhbABcgkhGgS0E01UCgR0WAQEBAQF9hAIBAQEDAWcXCwIBCBEDAQIhBwchERQJCAIEARIbiBEDCQnGFg2GUwEBAQEBAQQBAQEBAQEBARqOW4IoFwGESwWSMYlighKBNINPgzKHOoZxg3psgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,359,1413244800"; d="scan'208,217";a="368032293" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 11 Nov 2014 09:31:47 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sAB9VlDY031637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 09:31:47 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.32]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 03:31:47 -0600 From: "Sri Gundavelli (sgundave)" To: Margaret Wasserman , "mif@ietf.org List" Thread-Topic: [mif] Hybrid Access Problem Thread-Index: AQHP/ZJQEA3V2dgbh0aFolra0LRo0g== Date: Tue, 11 Nov 2014 09:31:46 +0000 Message-ID: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.114.240] Content-Type: multipart/alternative; boundary="_000_D087175617823Asgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/PkvUyya-XNJpFBVu2zQWEs9Ddpg Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:31:51 -0000 --_000_D087175617823Asgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Typo .. Read Rel-10 .not Rel-12 =85 From: Sri Gundavelli > Date: Tuesday, November 11, 2014 1:18 AM To: Margaret Wasserman = >, "mif@ietf.org List" > Subject: Re: [mif] Hybrid Access Problem > If you have an ISP today that has two different access networks available= , such as one 3GPP network and one DSL network, how do(es) the gateway box(= es) (connected to both networks) decide where it should send each packet it= receives? I think there are several possible cases here; The IP address/prefix that is given to the PDN connection of the mobile no= de is topologically anchored on the PGW and the IP traffic that is routed= on the 3GPP link is ONLY the traffic using the source address/prefixes ass= ociated with that PDN connection. All the functions in the 3GPP network inc= luding QoS, charging ..etc is only for that IP address/prefix. For the case where the mobile node is a mobile router, we have specified su= pport for prefix delegation in 3GPP Rel-12, where the mobile router can obt= ain a set of delegated prefixes for its ingress networks. But even those de= legated prefixes and the IP address/prefix on the primary PDN connection MU= ST be part of a single aggregate block and that aggregate block is again to= pologically anchored on the PGW. So, the IP traffic that is routed and seen= on the 3GPP link is only the traffic associated with that PDN connection. For all other cases such as where the IP prefixes in the ingress network be= hind the mobile router not belonging to the 3GPP network, either those pac= kets must NAT/PAT translated, or carried over an overlay tunnel (GRE/UDP) = path. In the later case the ingress prefixes are hidden from the transport = network and so the 3GPP network does not care about those prefixes. It neve= r sees them. Now, if we map this to NEMO use-case, it is exactly the case of a mobile ro= uter connected to two access networks; The ingress prefixes behind the mobi= le router are prefixes anchored on the mobility anchor (HA/LMA/PGW) and the= traffic from the ingress network is tunneled to the anchor. An overlay tun= nel path is set up between the MR and the HA and the overlay topology is hi= dden from the transport network. Please see inline Regards Sri From: Margaret Wasserman > Date: Monday, November 10, 2014 8:08 PM To: "mif@ietf.org List" > Subject: [mif] Hybrid Access Problem Let me see if I can start a technical discussion here... If you have an ISP today that has two different access networks available, = such as one 3GPP network and one DSL network, how do(es) the gateway box(es= ) (connected to both networks) decide where it should send each packet it r= eceives? I think there are several possible cases here; [Sri] Not sure, I followed the below conclusions or the assumptions. But, I= will try. (1) There is one gateway attached to both outbound networks. This has two = sub-cases: [Sri] Ok (1.1) Hosts behind the single gateway have separate addresses on the two at= tached networks. In that case, the gateway is constrained to send packets = over the outgoing network that uses the address prefix that matches the sou= rce address, or the packets will be thrown away by ingress filters on the o= ther side. So, the network choice is made by the hosts. [Sri] Hosts can have addresses belonging to the access network, or they can= be from the anchor in the home network. For the later case, there can be a= n overlay topology. The gateway can potentially tunnel the packet to an anc= hor (Ex: BNG) and in that case the ingress side network prefixes are hidden= from the transport network. (1.2) Hosts behind the gateway have only one address each. This has two su= b-cases: [Sri] The gateway can include multiple prefixes in the RA sent on the ingre= ss link and so the hosts CAN have multiple IP addresses/prefixes. (1.2.1) The gateway has separate addresses on the two networks, and does so= me sort of translation from internal to external addresses in the prefix of= the "right" outgoing link. [Sri] Translation is one option for the case where the addresses are privat= e address relevant only on that link. Tunneling is another option when the = addresses belong to a remote gateway. There is also the third option, where= the ingress prefixes are from the access network and there is normal routi= ng. (1.2.2) The gateway has only one IP address that is somehow shared across t= he two links. [Sri] Not sure, how its possible. The IP address given for the LTE connecti= on cannot be the IP address given on the DSL link. The connection is tied = to a IMSI and that cannot be on two different gateways. (2) There are two gateways, each attached to a single outbound network. I= n this case, hosts will always have separate addresses for the two networks= , and will need to make a decision about which outbound network to use. [Sri] Not sure, how the host with a single interface is attached to two gat= eways simultaneously ? Is the host again another router ? Cases 1.1 and 2 are essentially the same from a host standpoint, in that th= e host needs to make a network choice. This is a problem we have discussed= in MIF -- What sort of information does/should the host need to make that = choice, and how is that information communicated to the host? [Sri] This is nothing to with the host. Its about the addressing and the ow= nership of the addressing that is enabled on that link. This is a network d= ecision and not a host decision. Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for multi-ho= ming. The IETF generally prefers to avoid recommending solutions that use = NAT, but do we have a better answer? [Sri] NAT is an option, but there are other modes. 1. Allocate prefixes from a remote anchor and set up tunneling to that a= nchor 2. Enable routing for the ingress prefixes in the transport network; Mak= e them routable in the transport network (Ex: Rel-12 3GPP PD Work). Case 1.2.2 becomes a layer 2 problem and is probably outside the scope of t= he IETF. Are there cases that I am missing here? [Sri] Not sure I agree with the conclusions. Margaret --_000_D087175617823Asgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <77B22F8B1C414448B67AEB7D7C878110@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Typo .. Read Rel-10 .not Rel-12 =85 

From: Sri Gundavelli <sgundave@cisco.com>
Date: Tuesday, November 11, 2014 1:= 18 AM
To: Margaret Wasserman <margaretw42@gmail.com>, "mif@ietf.org List" <mif@ietf.org>
Subject: Re: [mif] Hybrid Access Pr= oblem

> If you have an ISP today that has two different access networks a= vailable, such as one 3GPP network and one DSL network, how do(es) the gate= way box(es) (connected to both networks) decide where it should send each p= acket it receives?  I think there are several possible cases here;

The IP address/prefix that is given to the  PDN connection of the mobi= le node  is topologically anchored on the PGW  and the IP traffic= that is routed on the 3GPP link is ONLY the traffic using the source addre= ss/prefixes associated with that PDN connection. All the functions in the 3GPP network including QoS, charging ..etc is onl= y for that IP address/prefix.

For the case where the mobile node is a mobile router, we have specified su= pport for prefix delegation in 3GPP Rel-12, where the mobile router can obt= ain a set of delegated prefixes for its ingress networks. But even those de= legated prefixes and the IP address/prefix on the primary PDN connection MUST be part of a single aggregate block and= that aggregate block is again topologically anchored on the PGW. So, the I= P traffic that is routed and seen on the 3GPP link is only the traffic asso= ciated with that PDN connection.

For all other cases such as where the IP prefixes in the ingress network be= hind the mobile router not belonging to the 3GPP network,  either thos= e packets must NAT/PAT translated, or carried over an overlay tunnel  = (GRE/UDP) path. In the later case the ingress prefixes are hidden from the transport network and so the 3GPP network doe= s not care about those prefixes. It never sees them.

Now, if we map this to NEMO use-case, it is exactly the case of a mobile ro= uter connected to two access networks; The ingress prefixes behind the mobi= le router are prefixes anchored on the mobility anchor (HA/LMA/PGW) and the= traffic from the ingress network is tunneled to the anchor. An overlay tunnel path is set up between t= he MR and the HA and the overlay topology is hidden from the transport netw= ork. 

Please see inline 


Regards
Sri


From: Margaret Wasserman <margaretw42@gmail.com>
Date: Monday, November 10, 2014 8:0= 8 PM
To: "mif@ietf.org List" <mif@= ietf.org>
Subject: [mif] Hybrid Access Proble= m



Let me see if I can start a technical discussion here...

If you have an ISP today that has two different access networks availa= ble, such as one 3GPP network and one DSL network, how do(es) the gateway b= ox(es) (connected to both networks) decide where it should send each packet= it receives?  I think there are several possible cases here;

[Sri] Not sure, I followed the below conclusions= or the assumptions. But, I will try.


(1) There is one gateway attached to both outbound networks.  Thi= s has two sub-cases:

[Sri] Ok

(1.1) Hosts behind the single gateway have separate addresses on the t= wo attached networks.  In that case, the gateway is constrained to sen= d packets over the outgoing network that uses the address prefix that match= es the source address, or the packets will be thrown away by ingress filters on the other side.  So, the ne= twork choice is made by the hosts.

[Sri] Hosts can have addresses belonging to the = access network, or they can be from the anchor in the home network. For the= later case, there can= be an overlay topology. The gateway can potentially tunnel the packet to an anchor (Ex: BNG) and in that case the = ingress side network prefixes are hidden from the transport network. <= /b>


(1.2) Hosts behind the gateway have only one address each.  This = has two sub-cases:

[Sri] The gateway can include multiple prefixes = in the RA sent on the ingress link and so the hosts CAN have multiple IP ad= dresses/prefixes.


(1.2.1) The gateway has separate addresses on the two networks, and do= es some sort of translation from internal to external addresses in the pref= ix of the "right" outgoing link.

[Sri] Translation is one option for the case where = the addresses are private address relevant only on that link. Tunneling is = another option when the addresses belong to a remote gateway. There is also the third option, where the ingress prefix= es are from the access network and there is normal routing.


(1.2.2) The gateway has only one IP address that is somehow shared acr= oss the two links.

[Sri] Not sure, how its possible. The IP address= given for the LTE connection cannot be the  IP address given on the D= SL link. The connectio= n is tied to a IMSI and that cannot be on two different gateways.


(2)  There are two gateways, each attached to a single outbound n= etwork.  In this case, hosts will always have separate addresses for t= he two networks, and will need to make a decision about which outbound netw= ork to use. 

[Sri] Not sure, how the host with a single inter= face is attached to two gateways simultaneously ? Is the host again another= router ?


Cases 1.1 and 2 are essentially the same from a host standpoint, in th= at the host needs to make a network choice.  This is a problem we have= discussed in MIF -- What sort of information does/should the host need to = make that choice, and how is that information communicated to the host?  

[Sri] This = is nothing to with the host. Its about the addressing and the ownership of = the addressing that is enabled on that link. This is a network decision and= not  a host decision.


Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for mul= ti-homing.  The IETF generally prefers to avoid recommending solutions= that use NAT, but do we have a better answer?

[Sri] NAT i= s an option, but there are other modes.
  1. Allocate prefixes from a remote anchor and s= et up tunneling to that anchor
  2. <= b>Enable routing for the ingress prefixes in the transport network; Make th= em routable in the transport network (Ex: Rel-12 3GPP PD Work). 

Case 1.2.2 becomes a layer 2 problem a= nd is probably outside the scope of the IETF.


Are there cases that I am missing here?

[Sri] Not sure I agree with the conclusions= .


Margaret





 --_000_D087175617823Asgundaveciscocom_-- From nobody Tue Nov 11 01:46:45 2014 Return-Path: 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 1526A1A8979 for ; Tue, 11 Nov 2014 01:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no 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 h_KyHp1b6VFe for ; Tue, 11 Nov 2014 01:46:40 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id 1BB2D1A888D for ; Tue, 11 Nov 2014 01:46:39 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec5461dafe9a1-0ba2f; Tue, 11 Nov 2014 17:46:38 +0800 (CST) X-RM-TRANSID: 2eec5461dafe9a1-0ba2f X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[31.133.140.80]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee35461dafaca7-7a3ec; Tue, 11 Nov 2014 17:46:38 +0800 (CST) X-RM-TRANSID: 2ee35461dafaca7-7a3ec From: "Hui Deng" To: "'Sri Gundavelli \(sgundave\)'" , "'Ted Lemon'" References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> <002c01cffd58$18276ca0$487645e0$@com> In-Reply-To: Date: Mon, 10 Nov 2014 23:46:34 -1000 Message-ID: <002601cffd94$647833a0$2d689ae0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP/ZB6Wa/8PQlUKkaI0q2EH9MMrJxbLH3w Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mif/cf5u6BtoorR2VB-4kX8EKQwGq88 Cc: 'Brian Haberman' , mif@ietf.org Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:46:42 -0000 Hi Sri, Inline =3D=3D> please, trimed. > Current MIF charter prevent MIF from working on flow switch which is=20 >mostly mobile ip/dmm based solution, but it doesn't disallow MIF to=20 >work on flow split and per packet delivery. You are saying the charter disallows splitting of flows across two = access networks, but it allows splitting of a single flow ? What is the = logic here ? So, this requirement does not match the prior work because = the flow policy is different ? That's the only reason why we should look = at this as a different problem from the work that was done in the past ? =3D=3D> MIF was chartered to avoid the duplicate work with Mobile IP/DMM = stuff, the work is outside of Mobile IP/DMM could be done by anywhere = including MIF which is decided by AD, does this make sense? Per-packet load balancing is probably not explicitly stated as transport = group was never in favor of splitting a single flow across two access = links with different transmission properties (latency, packet loss and jitter) as that will result in peers requiring to deal with = re-odering/buffering issues. General recommendation was not to split a = single flow, and so the MIP WG always kept the flow definition at the = granularity of a flow-level and not at a packet level. But, in any case = that's just a policy that is exchanged between two peers. =3D=3D>We will see what's the requirement from BBF, and could that be = allowed to be done by IETF. Thanks for the discussion -Hui From nobody Tue Nov 11 08:07:59 2014 Return-Path: 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 174721A8BC5 for ; Tue, 11 Nov 2014 08:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 SjU19b5Ixd3D for ; Tue, 11 Nov 2014 08:07:54 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B111A8BB5 for ; Tue, 11 Nov 2014 08:07:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sABG7o1s027088 for ; Tue, 11 Nov 2014 17:07:50 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A37A200E6B for ; Tue, 11 Nov 2014 17:08:07 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 322F3200DF3 for ; Tue, 11 Nov 2014 17:08:07 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.131]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sABG7OLu021881 for ; Tue, 11 Nov 2014 17:07:49 +0100 Message-ID: <5462343B.7040705@gmail.com> Date: Tue, 11 Nov 2014 17:07:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mif@ietf.org References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> <002c01cffd58$18276ca0$487645e0$@com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mif/3aoV9Q1WzLcKW2T9Aj_ykUNTLS4 Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 16:07:57 -0000 Le 11/11/2014 10:18, Sri Gundavelli (sgundave) a écrit : > (We have started the technical discussion, but I do want to respond to > this) > > > Hi Hui, > >> Current MIF charter prevent MIF from working on flow switch which is >> mostly mobile ip/dmm based solution, but it doesn't disallow MIF to work >> on flow split and per packet delivery. > > > You are saying the charter disallows splitting of flows across two access > networks, but it allows splitting of a single flow ? What is the logic > here ? So, this requirement does not match the prior work because the > flow policy is different ? That's the only reason why we should look at > this as a different problem from the work that was done in the past ? > > Per-packet load balancing is probably not explicitly stated as transport > group was never in favor of splitting a single flow across two access > links with different transmission properties (latency, packet loss and > jitter) as that will result in peers requiring to deal with > re-odering/buffering issues. General recommendation was not to split a > single flow, and so the MIP WG always kept the flow definition at the > granularity of a flow-level and not at a packet level. That was then. Again, the MIP work with flows has nothing to do with what we try do here. When the transport are tells problems may arise with reordering it's because the MIP WG did not reply that (1) applications may deal with reordering and (2) the HA may deal with reordering. Also, transport area may be well aware that this kind of per-packet splitting across links happens on a routinely at intermediary routers: two successive traceroutes rarely show same sequence. Alex But, in any case > that's just a policy that is exchanged between two peers. > > > Regards > Sri > > > > On 11/10/14 6:34 PM, "Hui Deng" wrote: > >> Hi Sri, >> >> Current MIF charter prevent MIF from working on flow switch which is >> mostly mobile ip/dmm based solution, >> but it doesn't disallow MIF to work on flow split and per packet >> delivery. This is the key point that PS should explain the clearly. >> >> -Hui >> >> -----Original Message----- >> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] >> Sent: Monday, November 10, 2014 4:23 PM >> To: Ted Lemon >> Cc: STARK, BARBARA H; Hui Deng; mif@ietf.org; Brian Haberman; Jouni >> Korhonen; pierrick.seite@orange.com; Dapeng Liu >> Subject: Re: Follow up with BBF proposal >> >> Hi Ted, >> >> Having a discussion in MIF WG sounds reasonable to me. >> >> Regarding homenet relation, I'm not sure it belongs to that WG either. >> The focus of the homenet is on ingress networks and for realizing >> simplified configurations and that has no relation to access selection on >> egress paths. FWIW, this work is very much related to what the MIP >> working group have been doing for many years. Sure, the device in case of >> BBF is a fixed device, but the fundamental requirements are about access >> selection, flow mobility and policy exchange. The flow mobility / MCOA >> work in MIP working groups have done significant amount of work in this >> area and the expertise is in that group. >> >> If the reason for steering this work away from DMM is due the belief that >> we will apply only MIP-based solution, I'd say the group will certainly >> do that, but the WG may also agree to additional solution/protocol >> mechanisms. Also, IETF is in no position to pick one protocol/solution >> for this requirement. It is probably reasonable for IETF to identify a >> set of solutions and present analysis on each of the solutions and that >> can be the basis for the BBF to review and pick one or more solutions. >> But, either way I believe the expertise around this topic is in DMM WG >> and not in homenet or in MIF WG's. >> >> Regards >> Sri > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Tue Nov 11 11:22:26 2014 Return-Path: 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 E61ED1A6FB1 for ; Tue, 11 Nov 2014 11:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 Ueo8w3FoRFVo for ; Tue, 11 Nov 2014 11:22:20 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379211A1AE0 for ; Tue, 11 Nov 2014 11:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59964; q=dns/txt; s=iport; t=1415733740; x=1416943340; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8K4E3SjibUREz29oNEOZAoeYiVR5Y9XZvRWJKtqmwdU=; b=LyZgLzM0nnRS5/bk5JB+6+XgttwxJsrRPcyaoTdLDgqcTLbi22cRWWkT 8mira1v84v17lqocKQv6emLvEcnNIXQMKXFRh70UFyonTbpyXC9yJiT+y Naqes+mLM4lYzL5PTKGVC5O3yGlskziXbtHtHCxosxEzXAXaCaF0pqQD5 E=; X-Files: 98EFB856-22C0-4936-9BD6-7F7497C8397F.jpg : 22112 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAK5hYlStJV2Q/2dsb2JhbABSCoJIRlRZBIVixjgBCYdPAoEYFgEBAQEBfYQCAQEBAwEBAQECIgY+AwQMBwQCAQgRBAEBBgEBAQoOBwcCBRABCQUBCxQJCAIEAREBBggNiBEDCQkNyDQNhkIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI5bgV0xBwkXCgEEAoRFAQSQDoIjg2uFd4ISgTSDT4psgmeECoFdgh1sgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="jpg'145?scan'145,208,217,145";a="95616605" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 11 Nov 2014 19:22:09 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sABJM9jR026306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 19:22:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.32]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 13:22:08 -0600 From: "Sri Gundavelli (sgundave)" To: Alexandru Petrescu , "mif@ietf.org" Thread-Topic: [mif] Follow up with BBF proposal Thread-Index: AQHP/eTIQDioOUOX6EGBs9InNToOww== Date: Tue, 11 Nov 2014 19:22:08 +0000 Message-ID: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> <002c01cffd58$18276ca0$487645e0$@com> <5462343B.7040705@gmail.com> In-Reply-To: <5462343B.7040705@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.95.112] Content-Type: multipart/related; boundary="_004_D0877F0D1782C4sgundaveciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/dZCND6q-ttigvAMEzpMoR9CSYTw Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:22:25 -0000 --_004_D0877F0D1782C4sgundaveciscocom_ Content-Type: multipart/alternative; boundary="_000_D0877F0D1782C4sgundaveciscocom_" --_000_D0877F0D1782C4sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Also, transport area may be well aware that this kind of per-packet splitting across links happens on a routinely at intermediary routers: two successive traceroutes rarely show same sequence. Sure. Applications can deal with it, or they may suffer. Traffic load balan= cing in internet has always been there. But, there is a fundamental differe= nce between splitting a flow between two redundant paths connected over hig= h-speed links in the internet core, to splitting the same flow across two a= ccess two access-links to which a mobile node is attached. Can we split a a= udio flow on satellite access and DSL link and say its an application probl= em ? Is it not a network design problem and should it not be avoided ? > Again, the MIP work with flows has nothing to do with what we try do here= . Please state some technical reasons. What we did in the past is the following. [cid:98EFB856-22C0-4936-9BD6-7F7497C8397F] Application Preferred Access Type Second Preference Third Preference HTTP BLUE RED IPSec RED BLUE SSH - SIP / RTP BLUE 1.) Ability to allow a mobile router to perform connection management; - Single Access Attach =96 Attach to the "best" available access network - Multi Access Attach =96 Attach to all available access networks 2.) Ability for the mobile router to register multiple care-of address with= the anchor (MCOA Work which we did for 3 years) 3.) Ability to request IPv4 and/or IPv6 mobile network prefixes for the in= gress network from the anchor 4.) Ability to establish multiple tunnel paths to the anchor to realize mul= ti-path overlay topology from the mobile network to the anchor; So, to real= ize a bigger data pipe for the traffic associated with the mobile network p= refixes 5.) Ability to negotiate a traffic flow policy on application basis; Most = preferred access to least preferred access on application basis and ability= switch the flows based on the path availability 6.) Ability to perform heart-beats for path management and to re-evaluate t= he flow policy 7.) Ability to support IPv4/IPv6 transport network, or IPv4/IPv6 mobile net= works 8.) Ability to perform NAT translation on the "transport" network 9.) The anchor that is here is the HA/LMA/BNG/PGW/ which is used in Wi-Fi, = LTE and Cable MSO accounts is the subscriber management function. There is = charging, policy, infrastructure that is supported and deployed in todays n= etworks. Now, if I fix the MR and nail the MR to a wall, what aspects of the above d= o not work ? Can the MR cannot be a CPE in home with LTE and DOCSIS access = ? What is missing here ? Is it the per-packet load balancing ? Is there an= y thing more ? --> If you can summarize your answer for the above 9 points and just state = it below it will help. Regards Sri On 11/11/14 8:07 AM, "Alexandru Petrescu" > wrote: Le 11/11/2014 10:18, Sri Gundavelli (sgundave) a =E9crit : (We have started the technical discussion, but I do want to respond to this) Hi Hui, Current MIF charter prevent MIF from working on flow switch which is mostly mobile ip/dmm based solution, but it doesn't disallow MIF to work on flow split and per packet delivery. You are saying the charter disallows splitting of flows across two access networks, but it allows splitting of a single flow ? What is the logic here ? So, this requirement does not match the prior work because the flow policy is different ? That's the only reason why we should look at this as a different problem from the work that was done in the past ? Per-packet load balancing is probably not explicitly stated as transport group was never in favor of splitting a single flow across two access links with different transmission properties (latency, packet loss and jitter) as that will result in peers requiring to deal with re-odering/buffering issues. General recommendation was not to split a single flow, and so the MIP WG always kept the flow definition at the granularity of a flow-level and not at a packet level. That was then. Again, the MIP work with flows has nothing to do with what we try do here. When the transport are tells problems may arise with reordering it's because the MIP WG did not reply that (1) applications may deal with reordering and (2) the HA may deal with reordering. Also, transport area may be well aware that this kind of per-packet splitting across links happens on a routinely at intermediary routers: two successive traceroutes rarely show same sequence. Alex But, in any case that's just a policy that is exchanged between two peers. Regards Sri On 11/10/14 6:34 PM, "Hui Deng" > wrote: Hi Sri, Current MIF charter prevent MIF from working on flow switch which is mostly mobile ip/dmm based solution, but it doesn't disallow MIF to work on flow split and per packet delivery. This is the key point that PS should explain the clearly. -Hui -----Original Message----- From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Monday, November 10, 2014 4:23 PM To: Ted Lemon Cc: STARK, BARBARA H; Hui Deng; mif@ietf.org; Brian Ha= berman; Jouni Korhonen; pierrick.seite@orange.com; Dape= ng Liu Subject: Re: Follow up with BBF proposal Hi Ted, Having a discussion in MIF WG sounds reasonable to me. Regarding homenet relation, I'm not sure it belongs to that WG either. The focus of the homenet is on ingress networks and for realizing simplified configurations and that has no relation to access selection on egress paths. FWIW, this work is very much related to what the MIP working group have been doing for many years. Sure, the device in case of BBF is a fixed device, but the fundamental requirements are about access selection, flow mobility and policy exchange. The flow mobility / MCOA work in MIP working groups have done significant amount of work in this area and the expertise is in that group. If the reason for steering this work away from DMM is due the belief that we will apply only MIP-based solution, I'd say the group will certainly do that, but the WG may also agree to additional solution/protocol mechanisms. Also, IETF is in no position to pick one protocol/solution for this requirement. It is probably reasonable for IETF to identify a set of solutions and present analysis on each of the solutions and that can be the basis for the BBF to review and pick one or more solutions. But, either way I believe the expertise around this topic is in DMM WG and not in homenet or in MIF WG's. Regards Sri _______________________________________________ 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 --_000_D0877F0D1782C4sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <91E73B04492B8F4FA0674F67B5BD4F52@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

> Also, transport area may be well = aware that this kind of per-packet
splitting across links happens on a ro= utinely at intermediary routers:
two successive traceroutes rarely show= same sequence.

Sure. Applications can deal with it, or the= y may suffer. Traffic load balancing in internet has always been there.&nbs= p;But, there is a fundamental difference between splitting a flow between t= wo redundant paths connected over high-speed links in the internet core, to splitting the same flow across two access t= wo access-links to which a mobile node is attached. Can we split a audio fl= ow on satellite access and DSL link and say its an application problem ? Is= it not a network design problem and should it not be avoided ?


> Again, the MIP work with flo= ws has nothing to do with what we try do here.

Please state some technical reasons.=


What we did in the past is the following.




Application

Preferred Access Type

Second Preference

Third Preference

HTTP

BLUE

RED

<DROP>

IPSec

RED

BLUE

<DROP>

SSH

<DROP>

 <DROP&= gt;

-

SIP / RTP

BLUE

<DROP>

<DROP>

1.) Ability to allow a mobile router to per= form connection management;

- Single Access Attach =96 Attach to the &q= uot;best" available access network
- Multi Access Attach =96 Attach to all ava= ilable access networks

2.) Ability for the mobile router to regist= er multiple care-of address with the anchor (MCOA Work which we did for 3 y= ears) 

3.)  Ability to request IPv4 and/or IP= v6 mobile network prefixes for the ingress network from the anchor

4.) Ability to establish multiple tunnel pa= ths to the anchor to realize multi-path overlay topology from the mobile ne= twork to the anchor; So, to realize a bigger data pipe for the traffic asso= ciated with the mobile network prefixes

5.) Ability to negotiate a traffic flo= w policy on application basis;  Most preferred access to least preferr= ed access on application basis and ability switch the flows based on the pa= th availability

6.) Ability to perform heart-beats for path= management and to re-evaluate the flow policy

7.) Ability to support IPv4/IPv6 transport = network, or IPv4/IPv6 mobile networks

8.) Ability to perform NAT translation on t= he "transport" network

9.) The anchor that is here is the HA/LMA/B= NG/PGW/ which is used in Wi-Fi, LTE and Cable MSO accounts is the subscribe= r management function. There is charging, policy, infrastructure that is su= pported and deployed in todays networks.


Now, if I fix the MR and nail the MR to a w= all, what aspects of the above do not work ? Can the MR cannot be a CPE in = home with LTE and DOCSIS access ? What is missing here ?  Is it the per-packet load balancing ? Is there any thing more ?

--> If you can summarize your answer for= the above 9 points and just state it below it will help. <= /div>




Regards
Sri



On 11/11/14 8:07 AM, "Alexandru P= etrescu" <alexandru= .petrescu@gmail.com> wrote:

Le 11/11/2014 10:18, Sri Gundavelli (sgundave) a =E9crit :
(We have started the technical discussion, but I do want to respond to=
this)


Hi Hui,

Current MIF charter prevent MIF from working on flow switch which is
mostly mobile ip/dmm based solution, but it doesn't disallow MIF to wo= rk
on flow split and per packet delivery.


You are saying the charter disallows splitting of flows across two acc= ess
networks, but it allows splitting of a single flow ? What is the logic=
here ?  So, this requirement does not match the prior work b= ecause the
flow policy is different ? That's the only reason why we should look a= t
this as a different problem from the work that was done in the past ?<= /div>

Per-packet load balancing is probably not explicitly stated as transpo= rt
group was never in favor of splitting a single flow across two access<= /div>
links with different transmission properties (latency, packet loss and=
jitter) as that will result in peers requiring to deal with
re-odering/buffering issues.  General recommendation was not= to split a
single flow, and so the MIP WG always kept the flow definition at the<= /div>
granularity of a flow-level and not at a packet level.

That was then.

Again, the MIP work with flows has nothing to do with what we try do h= ere.

When the transport are tells problems may arise with reordering it's <= /div>
because the MIP WG did not reply that (1) applications may deal with <= /div>
reordering and (2) the HA may deal with reordering.

Also, transport area may be well aware that this kind of per-packet
splitting across links happens on a routinely at intermediary routers:=
two successive traceroutes rarely show same sequence.

Alex


  But, in any case
that's just a policy that is exchanged between two peers.


Regards
Sri



On 11/10/14 6:34 PM, "Hui Deng" <denghui@chinamobile.com> wrote:

Hi Sri,

Current MIF charter prevent MIF from working on flow switch which is
mostly mobile ip/dmm based solution,
but it doesn't disallow MIF to work on flow split and per packet
delivery. This is the key point that PS should explain the clearly.

-Hui

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Monday, November 10, 2014 4:23 PM
To: Ted Lemon
Cc: STARK, BARBARA H; Hui Deng; mif@ie= tf.org; Brian Haberman; Jouni
Korhonen; pierrick.seite@= orange.com; Dapeng Liu
Subject: Re: Follow up with BBF proposal

Hi Ted,

Having a discussion in MIF WG sounds reasonable to me.

Regarding homenet relation, I'm not sure it belongs to that WG either.=
The focus of the homenet is on ingress networks and for realizing
simplified configurations and that has no relation to access selection= on
egress paths. FWIW, this work is very much related to what the MIP
working group have been doing for many years. Sure, the device in case= of
BBF is a fixed device, but the fundamental requirements are about acce= ss
selection, flow mobility and policy exchange. The flow mobility / MCOA=
work in MIP working groups have done significant amount of work in thi= s
area and the expertise is in that group.

If the reason for steering this work away from DMM is due the belief t= hat
we will apply only MIP-based solution, I'd say the group will certainl= y
do that, but the WG may also agree to additional solution/protocol
mechanisms. Also, IETF is in no position to pick one protocol/solution=
for this requirement. It is probably reasonable for IETF to identify a=
set of solutions and present analysis on each of the solutions and tha= t
can be the basis for the BBF to review and pick one or more solutions.=
But, either way I believe the expertise around this topic is in DMM WG=
and not in homenet or in MIF WG's.

Regards
Sri

_______________________________________________
mif mailing list



_______________________________________________
mif mailing list

--_000_D0877F0D1782C4sgundaveciscocom_-- --_004_D0877F0D1782C4sgundaveciscocom_ Content-Type: image/jpeg; name="98EFB856-22C0-4936-9BD6-7F7497C8397F.jpg" Content-Description: 98EFB856-22C0-4936-9BD6-7F7497C8397F.jpg Content-Disposition: inline; filename="98EFB856-22C0-4936-9BD6-7F7497C8397F.jpg"; size=22112; creation-date="Tue, 11 Nov 2014 19:22:07 GMT"; modification-date="Tue, 11 Nov 2014 19:22:07 GMT" Content-ID: <98EFB856-22C0-4936-9BD6-7F7497C8397F> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdC IFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAA AADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFj cHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAA ABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAAD TAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJD AAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAA AAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAA AA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBo dHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcg Q29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENv bmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAA ABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAK AA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUA mgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEy ATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMC DAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMh Ay0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4E jASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3 BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDII RghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqY Cq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUAN Wg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBh EH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT 5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReu F9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9oc AhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCY IMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZcl xyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2 K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIx SjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDec N9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+ oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXe RiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN 3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYP VlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1f D19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/ aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfBy S3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyB fOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuH n4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLj k02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6f HZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1 q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm4 0blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZG xsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnU y9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj 4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozz GfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t////2wBDAAICAgIC AQICAgICAgIDAwYEAwMDAwcFBQQGCAcICAgHCAgJCg0LCQkMCggICw8LDA0ODg4OCQsQEQ8OEQ0O Dg7/2wBDAQICAgMDAwYEBAYOCQgJDg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg7/wAARCACaAjUDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAEC AwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0Kx wRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ 2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QA tREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaH iImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq 8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9/KKK+Qv2rbi4t/EfwDNvPNAW8U67uMblc48F+I2HT0IB +oFAH17RX4nfAn4U/tD/AAv/AGJbb9p7wVeeD/DFrD8EdE1O28IeHtW1DVZPGjxS2mp3l3qEV1EI YL6exhntUFvHI4e8kKzLtXdhftD/ABo/ab8cfsT+A/iHL4R+In/CovEXiq18aW1xpVlYRTx2EviG 0g0HQ51juRJtktF+2PIBKz3V1aRhkjSTaAfudRX4qfGfV9T1Wz+I3xKg1DULP/hMvC/xmu4IIbkh IodK0vT9CtXUqcMGTSVuFbnDXDFSQcnf8KeEPjx+yz+zXqH7StsnhTw74AsbLwvf+JPhv4Iu73XR rOkRRyx6tfO2orH9mv8Ay7uO4zCypixCyO+XdgD9jKK/B34teOPjVYftE/AHxT8Z7i21/wAWal4B 0PXfDvgy7tNS02S91i98WA3Ol6PJZ3NvHBqdpYXdhbvLKJnaKLEilJZnr2/9vvx54w+EH7dnw0+O PhAz6pc/Dr4ealqMvh43Dxw6oL+/tdFRW2g5KS6lDKAVOTFjg4IAP1zor8JPDfxM+LX7OX7DPgn4 aW3xfg+HUXhm3+IM0fibUNEi1M+MNe0jxBPbWmhA3CuE+0AyybY/37BAEZcHPoGg/Hv4m6R/wU21 rTrb4hx+G/Hfif4m+B4/EPwJk8NpeSy2upeFtMGq3Yuivnotmsckm6NkjhNmxnDi4QUAfs3RX4aW vxr+I/w5/Z++HnibwlqcXhdNe+F/wg0vxL4kgtbRYfDOn3cniUz3iC6Bs7bc8cFuJbhTChuFJGQt fqb+y3438bfEf9gH4ZeNfiJcaRfeLtU0xpLy/wBLgeK21BFmkSC7RWRMCeFYpjtUJmQ7Bs20Ae/U UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAfB+k/t5eCdX+I2veD4PB+sp4o0b46QfDC/sWulGxLi6urW31dXKANbvJZzqYx8yu hUnG1m6rxV+3j+zX4b+FGreMbbxpe+J9J07XbHSrk6Tol3IXF3dyWyXkG6JRdWYaC5P2m3MkcnkO kbSSFEbjvFX7B3hXxT8XPhB4/l8Wiy8Z+BPitq3jFdRi0NSdSsNQ1m51ZtJk/ehgI5J1VJ9zBf3z CIGYheO8L/8ABPq+8HfCjWPD+hfGDTodVtYNBtfBmszeCzLNpkGka2NXiF6GvSb13aOGMiJrWFdh dYQ0j7gD6fu/2sv2erHTL+6u/iRYW62Xh298QXcTadd+fFY2eonS7iQxeVv3LehrcRbfMd1IRWwa cv7V/wCz4/jH4h6CvxIsG1PwRpl/qPiJRp935cVvp67r5oJfK2XbW/SVLZpWRvlYBuK+ctU/4J2+ CtT/AGtLn4st461qG/uPifZeLpLD7K7w/YYZXv7jRRunKi2uNVc37HaVDAKI9w82pNQ/YLk1bS9X 0DUfi2ZvB9jofjSw8A6enhZUuNCm8UrOLya6nFz/AKcsX2iYRxhIOGG5iVBAB634P/bQ+CXjf4pW Gi6Jr8k+ja1ZaPJ4R1P+z7wT6/caheataGKGzaATrHCdJkd52XyhG+9mRF3thftBftev8Dfj1qXg m3+HMfi5NJ+HE3jvWL6XxXbaWYrCG6a2kjgjmQ+fPkAqgZd2cA5wDe8bfsi6b4r/AG8fB/7ROneN Lnw38Q/Cdjoun+Hp4dM86KCztZdQGpW0sZlCSx31tfmHO1ZLdoVdHbcyHqPGn7LXw/8AiR+33YfG v4h6T4R8eabZeAv+EZtPCviLwxBqEEE32/7WL9ZJiyrIAWiAEeQGY7+StAGbp/7bP7N9/dapYyeN 9TsNa0vQNN1rVNKuPDGpG5tYdRSzezhwkDLLcyfb7ZVt4WklZnYBSUfb534y/b2+Hem/EvSdE8AW Vp470q4+GWseO7zW7m6vNOtra1sI5NtuMWUp85popYpVk8o2xikVw0wWBuz+Jn7Jtn8RfCHxDtX8 Yrp2ra58VtL+IeiXUmlPJDpd3YWGm2SW8scdxE9xE62EhYpLAwFxhSDGGbjI/wBiKOP4Mah4UX4j W8M198JvEvge4uLbwwsMCza5qCX8t9HCLj5UidSqwl2dwQXnZ9zMAfQ+i/tE/BvxH+0NP8JtG8Yr ffEiDUL2xu/Dy6Xdrd2j2aJJPJOrRDybcrLH5dxJthmMiCJ5CwB9rr4/8I/sva94W/4Ka+Kv2mX+ K39o6z4nS507XdB/4RpYrSTSBFbrp1rC3nl47i3e3V5Llt4n3uoihBBH2BQAUUUUAFFFFABRRRQA UUUUAFFFFAGXrlzqtl4K1i80LS4dc1uCxll0/TZbwWqXk6oTHC0xVhEHYBS+1tuc4OMV8tfB79p7 VviH4vksfGvw2h+GdhN411LwTpNy3iQapJqGuaeLl7m1EcNuBHGI7K8dZpHVW8nGMugP1zXxzP8A sueJNO8E2qeC/ipYaD4tsPjXrHxL0zVNQ8J/brWN9SGoxyWEtsLqNpEWHUZU81ZUJZQwVegANu7/ AG3f2XLG78NRXfxXsYRr1pDeadOdHvzB9ml1CbTUuJpRBst4PtkEkDSzMiI2zeyiRC3QQftafs7T /G/Xfh2/xO0qw8U6M+ppqUeo2d1Z2kD6ZGZb+M3c0S25eCIGV0WQsIgZMbPmr5p07/gnvHp/7F/i 34Qn4tyXR1vwbpfhz+2pPC6iSEWXiLU9bM/lC5AbzP7R8nYGUL5O/J3bF7rxV+xJpXjHQrvSNW8f 3cOl3vjPxn4gv1stHWOaSPxJpt/YNAjtKwWS3W93rKysH8oAxqG4APVvD37UXw18da18MIvh3eXH iux8XeLJfD0009pc6ZcaVImiXmsJJLa3UKTbZIbWPZlVDrOsisyjnV8e/HrT/A/7Zfwd+DH/AAhv jDV9R8d3Vwj6/HYSR6PpSR2d5cosl0U8uS5lNnIFtkO4IryMVAQSeFeAP2I7bw4ukyeMPHOmeKrm PxI2oav/AGX4cm0tdSs/+EYvPD6Whc3s06ybb2Wc3Bmc9I41iRU2e1Wf7OHgzw1ovwH0D4fyT+Ef CPww8WXevWOlTTXGpPdm5stTtpITcXEzSr+81J5t7GT7mwAAgqAfQ9FFFABXJ+JfGugeFVjTU7iR 7yRN8VnbpvlZc4zjgKODyxAOCBkiujvL2z07Tpby/u7aytIwPMmnkCIuTgZJ4HJxXxPrWpSax4x1 XVJXaR7m6dwT2XOEX6BQqj2ArWnDmepy4rEOmlbdn0CPjT4aaCcjTdeikWMmNZYY8SNjhcq7YyeM kYHevHtZ+IHizWr55H1e702DdmO20+VoFjHpuUhm+rHr0A6VxlFdEacUebUxNSas2bkfifxPDcLK niXxDvU5G/UpXX8VZiD+Ir1jw18Ymg05rbxTb3F3OuPKu7OJAZB3DqSoB914PoMc+F0U5QTIp15w d0z7L8P+M/DviZ2i0q/DXaLue1mQxygdyAfvAcZK5AyOea6mvh/Q55rbxxos9vOlrcJfxeXM77VQ lwvzH+7gkH1BIr7grlqQ5Werha7qRd+gUUUVmdQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABX5+ftb3GoXnx1vNNulvItH0T9nT4geItHkS7ZY/wC1Vj06yEwj BH76G2vLlFc5IW8kC4y2f0Drl9W8F+Gdc+JHhPxfqWlrN4m8Mtc/2LqCTSRS263MXlXER2MBJFIo QtE+5C8UMm3fFGygH4o/s2+OIdC/Yv0+P4V/Fr9njTfjFryeBNLa+8E6Tc3et6fBe6zp9hfPq0V/ cSxzyj7YqsUSI+Y8h+QlCvrOq/tLfFnR/BOi6D47/aJtfhRp2j+LPHuk3vxMu/Alrfy+ILrQtRit 9OsJLZIxAsk8MtxI0VuiTTG0CQsrFi36+0UAfiR8Qv21/jLov7YXxU0Hwz8SGn0u38M+PIbfQtT8 L6dp0ugXui6Ct9YXUNoxmvcSSwTur30my5QylLaNYgT79+zz8f8Axl40vvF1lrP7SumeOPBtl4m8 GLo3j5fAcNrHqN7qiFr/AMMqkarGr7lgUMQbi1+3BZWZlGP0Z8WeFtB8c/CzxN4K8U2H9qeGfEGl XGl6vZ+c8X2m1uImhmj3xsrruR2G5WDDOQQea3IokhtY4YhtjjUKgznAAwOtAH5b/tkX/gmy/bts x+0Glrd/Bt/hVK3gWy8Wazdab4SuPEy3k5uxcz2kUsqXwsvINuxjfGJDEPNwR8M/EKX4q/Fvwdae NvDPwha6fRv2YbK5n0Txj4h1W88Q6Parrus2serae5Ft9qvPs8K3YaYRs6BPLL5Cyf0ZUUAfgBpf iX4bj/gqFr174v8AjR8CvEXhOy0H4f3Gm6/8Vl1OTUtctxpMDS3unFLqNIbiUASyGZZT5rxFxwd3 6x/s4Ti08RftKeG7fU5b7w3oHxj1GPSBKwItFu7DTtUu4Vb+4t9f3uAfu52jhQB794k8T6J4S8NP q2vXy2VrvWKJQjSS3ErcLFFGoLySMeFRAWPYV8jaVod/4nm1fwR4K8OQaB4Xk1u+1PVdHnupJ7WG 7vbqS8uZtXnDlrid5Z5HGmwybFDBZZFTZGvm47M4YdqEVzTe0V+vb/h30Z9LkXDNfME605ezox+K b203ttd6rqldpNpyV+l+IvjjT/GPii3h0K8lv/D9lGfKuUjZbe6mLMryRMRiZAF2CRcrnzAD1rz2 voHVPg9o9j8Nb64tH1HWPF8cPmyarMQbi9KLxBsUBEiA+WOGNVVP4QMsW+fQQyhlIIIyCO9etgJV ZUI+1SUutv6/z9XufH5/SwsMdNYVt0+je+2vbrtorqzaWy/Lzx78Xvi14T/aY8ZaBaeIPEcnh/4W +KpPFnihmzIdR0C7m04w2QORkRxXN+wBzgWyj3HrnwB+IXimX4y6JF8Q/Gtz5Gt/Cu08Tiz1a/VE hmvdUvZVChiP9XA0MXHRY1FfY154Q8J6hda7PqHhfw7fT63ZLZazJcabFI2o26hgsM5KnzYwHcBH yAGbjk1z/iD4SfCnxZf2N14p+GXw98S3NlaJaWc2q+HbW6e3gQkpEhkjJWNSThRgDJ4rqo3gop62 /HRx/Llfqm92efVrQnGSta/+al+fMvRpbI+OtP8A2gNfm/4KgSTSav4k/wCFR3euSeBbWzfRLldK F3GgK363pXyGle9WazEYbdgBuR0434Q/GP4rv+0B8Avh1451rWtQHiHWdU1rTtYRz5OqaSbO+xZ3 DHlp7e5jU45Gxojn1/RNPBXg2PwZB4cTwl4ZTw9Ddi7h0tdLhFrHOJvPEqxbdgkEv7zcBnf82c80 +Hwf4Rt5dAe38LeHIH0NpG0Ro9NiU6aZFKyG3wv7ourENsxkEg5zUUYODjd3t+N7P7+a79HyqyCd aD5rR3Wnlul+DS9Vfc6I42nOMd819EfDH4i6ZeeH9F8NaxPPY6tIjppNxdMpt9WjRmwLeVSVeRFG 14iRKpQkrtwx+d2VnQoqGVmGAg6sT2/Gvojxb8H7TV9KurvQ20+01i7VH1axvImfTNZlUDEk8a4a K4yAVuoSsqkKTvCha8/Np4mEIyoJOz1XdeX9ffs/pOEqGW1q84Y6bgmrRktk77v+tdm4354+20V8 xeGfiP4j8Ha7J4b8WWOu6lbW0RkmtLv/AEjWdOhHBmRkGNUsx/z3iHnoMCWMsSR9G6Vq2l674dtN X0XULPVdLuoxJbXdrKJIpVPdWHBrlwOY0sSvd0kt091/X/AdnoetnfDmLyySdRc0HtJaxfbXv181 rG8Wm9Ciiiu88AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPN/hP44u/iJ8GU8UXtjb6dO2t6tYCGByy7LPU 7qzRsnnLLbqx92OOK9Ir5/8A2Yef2PtPb+/4m8Qv/wB9a7qB/rX0BQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFNd0jheSR1jjVSzMxwFA6kn0oBK46vMvHHxN0zwo91plgltrHiWK2+0zW0 l0tvbadD/wA/N7cHK20PBwSC74IRHIOOA8X/ABauNXSDTfA013Fp17K0FtrVnbLcXmrOv3otKgf5 ZcfxXcuLeIc5fnbq+B/hDFbLa6n4wtrZ5I7n7baaBHcNc29vcHn7VdTP819e8DM0nyoQBGq43N4N bMauIm6WE17y6L07+W99LJq7X3mD4cw2XUli830/lp/albvs0r6NXTVndxlyxlyHhvwZ4o+I3iVP FXiLU9UtNPkRlXVjC9neXMLfeh06Andp1ow4MzE3Uw6tGoU19KaPo2leH/DVno2iafaaVpVrHst7 W2jCRxjrwB3JySepJJPNaVFd2By2nhk2tZPdvd/1/wAO29TxM94kxOZNQfu04/DBaJdtrXer6JK7 UVGOiK89134Y+Ftd1OW9eK60y8lctNLYyBPMJ6kqwZck8kgAknkmvQqK9FNrY+cnCMlZo8N1j4MW SeHJDoOoX0uqI25BfyqUkXunyIu09CDg9Md8jxDU9F1jRZ2j1bS77TyDjfNERGT/ALLj5W/AmvuG itY1mtzlqYKEttD4MgDXVwsNor3czHCxwKZHY+gAySa7uw+GnjLUNJN4mmLaJkbIruURTOPUIemP 9rafQGvriim676IzjgIrdniPgr4VT6Zr1vrHiKa2lnt2EltZwEsquOQ7sQMkHkADGQDk17dRRWUp OT1OynSjTVkc54n8J6F4v0KOx1yzM3kyiazuYZGhubOUdJYJUIeKQf3lIPUdCRXzlquj+NPhL4ku 9fs9Qil0qaTzLvWfsx+w3nqdVtoh+4l/6iFsuO80W1Rn6woIBBB5Bry8dllPEPnT5ZrZr9e/52uk 1dn1WScT4jARdGa9pRe8Ht52vez67NXSbTcVbz/wb8RNI8Wy/wBnSRSaH4mjt1nm0i6lRneI9J4J FJS5tzkYljJXkBtrZUegV8/+Mfg1GI/7Q8DRQ24huGuxoDXLWsUc5+9PYToN1hcHJyUBhkyRJGdx eqPhL4w3OlSXOk+PzdfZ7Aql3rFzaLb3embuFGp26ZWJTj5byHdbSYJzHwDyUczqYeapYxWfSXR+ vbz26tpK1/WxfDOHx9J4rJ5cyXxU38cfRatq+yu3qkpTlzW+jqKjilinto54JI5oZFDxyIwZXUjI II6gjvUle6fCNNOzCiiigQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRSEhULMQqgZ JJ4FeR678YvD+nzyW+jW83iKdTjzYpBHbZ9PMIJb2KKyn1qoxb2IqVYwV5M9dor5kuPjN4rknLWm n+HrWMniOaGWYr/wISJn/vkVB/wuPxpkfuPDBHf/AEGb/wCPVfsZHN9epH1FRXz7pnxsuVkRNb0C OWP+OfT58N+ET8f+RK9k0DxNonifTGutGvUuQmBNEwKSwk9A6HkdDg9DjgmplCUdzanXhPZm9RRR UGwUUUUAFFFFABRRRQAUUUUAFFFFAHz/APsv8/sX6A39/Wdaf/vrWL0/1r6Ar5D+Gms/Fj4ZfB6x 8ER/s8fEXxCun3l666kuveH7eO4E13NOGVDqLMoxLjnnjJA6DvP+FofGRvufsy+MF/66+L9EH/oN 01AH0BRXz/8A8LJ+N7fc/Zu1Rf8Arr440wf+gs1H/Cwvj033P2d7Zf8Arr8QbMf+gxNQB7VrGvaH 4e0xL3X9Z0nQ7N5REk+oXaW8bOQSFDOQC2FY464B9K5z/haHw0/6KJ4G/wDB9bf/ABdfkn/wUS1j 4geJ9K+CVr8Q/hbo3hHTota1CS1dfEseq+dJ9kAIKCFAmAfvZPXFfnH/AGDof/QG0r/wET/CvhuI +N6eU4pUJUnLRO97b38vI/NuLPEalkeNWFlQc3yp3vbdvyfY/qI/4Wh8NP8Aoongb/wfW3/xdH/C 0Php/wBFE8Df+D62/wDi6/l3/sHQ/wDoDaV/4CJ/hSHQ9CVCzaPpKqBkk2iYH6V4P/EU6P8A0Dv/ AMCX+R8z/wARqof9Aj/8CX+R/UT/AMLQ+Gn/AEUTwN/4Prb/AOLo/wCFofDT/oongb/wfW3/AMXX 8uSaP4dlRmj0vRZFHUrbRkD9KauleGmiZ103Q2RfvMLeMgfXin/xFGl/0DP/AMC/4BX/ABGij/0C S/8AAl/kf1H/APC0Php/0UTwN/4Prb/4uj/haHw0/wCiieBv/B9bf/F1/Leul+GnkCJp2hO56Ktv GSf0qx/YOh/9AbSv/ARP8KH4pUlvhn/4F/wBPxpoLfCP/wACX+R/UR/wtD4af9FE8Df+D62/+Lo/ 4Wh8NP8Aoongb/wfW3/xdfy7/wBg6H/0BtK/8BE/wo/sHQ/+gNpX/gIn+FL/AIinR/6B3/4Ev8hf 8Rqw/wD0Cv8A8CX+R/VJovijwz4kNz/wjviLQtf+z7ftH9nX8dx5W7O3dsY7c7Wxnrg+lbtfiL/w TNsbGx/bq+JAsrO1s9/gOLf5ESpuxfLjOBzjJ/Ov1t8Z/Emy8PXd3o2jRWuteJ4bb7Rcwy3Qt7PS ocE/aL64OVt4sAkDBd8HYrYJH3uXZ3RxOAhjJLlUum73ennsfsnB9avxFhaVbDUneabtfZJ2u3ok vN2R1niXxTofhHw5/aeu3n2aFpBDbwxxtLPdSt92GGJQXlkbsigk/ga+c9Y1Pxd8VPFtx4fXS4Gt oJALjw7NNv0/TuhD6xNGcXE2MMNOhYr081ypDLZ8M+E/EnxA8R/8JNf6tqkFnNGUfxPJA1peXcLf eg0qBsnT7NhgGds3Ew5yBskr6P0TQ9H8N+GLTRdB0610vS7ZdsNvbptUZOST3LEkksckkkkknNc/ LiMy+L3KX4y/4H4dua6a/UXUy/hvSFquK768sH5bNNfKd7X9m1KEuc8IeBNN8KPcahJcT654nu4l S/1u8VfOlVfuxIqgLDAv8MMYCr1wWJY9xRRXu0aMKUFCCsv6/q/U+DxmNr4uq6taXNJ/0klsklok tEtErBRRRWpyhRRRQAUUUUAFFFFABRRRQAUUUUAFcb4t8DaL4ujtri6N1pmuWYb+zta09xHeWe77 wViCGRuN0Tho3x8ymuyorOtRhVg4zV0dOExlfC1VVoycZLqvx+T2a2a0Z8kxzeNfgtraQPFpv/CO zTbY4Q32fRL1mPSFmJ/sq6Yn/VOTaSscK0TMcfRfhXxnoni+xum02S4ttRs3EepaVexGG8sJCMhJ ojyueoYZVxyrMMGukurW2vdOns7y3gu7SeMxzQTRh0kQjBVlPBBHBBr5x8VfCTVPD19a678P5dSl hsEItLC2uVTUdMTOSljNL8ksGeTY3OYTxsaIgCvCdDE5frR9+n/L1Xp/Xyu3I+7WOy3iFcuMao4n pPaMn/e7Pz8272UaZ9K181ftC/tS+A/2bbnwbb+MdB8b+IbzxMLttPt/DlnbzMiWvkea8hnniUDN zEAASTk8YBNb3gj4y2uoCDTPGD2mn3rXIs4dYiieCzuLj/n3mjk/eWN3yP8AR5vvZHlvJnj8/f8A gqH/AMlU/Zz/AOwf4k/9C0enmOdxhltXFYdpuKvZ/r/Wu60PzXjvD5hw5gq9WpT96CbV78rt93zW jT0aTuj1j/h538Gf+iYfHf8A8FWl/wDywo/4ed/Bn/omHx3/APBVpf8A8sK/HSmu6xwvI3CqCT9B X5X/AMROzP8A59w+6X/yR/OK8ZM4f/Lqn90v/kj9jf8Ah538Gf8AomHx3/8ABVpf/wAsKP8Ah538 Gf8AomHx3/8ABVpf/wAsK/FLRPFOi+IvBj6/pVxJPpi78yNCyH5PvfKRmp9B8RaV4l8Jw65pNw02 mylgsrxmP7pKtkNgjkGuip4h51T5uehFcrs9JaPs/e30enkddXxW4hpc3PhoLlfK7xno9dH72j0e nkz9pv8Ah538Gf8AomHx3/8ABVpf/wAsKP8Ah538Gf8AomHx3/8ABVpf/wAsK/Efwt448NeM1vT4 ev2vPshUThoXjK7s7ThgMg7T+VdbU4jxGzihUdOrRjGS3TUk/u5iMV4tZ/hqrpVsPCMlunGSa67O R+xf/Dzv4M/9Ew+O/wD4KtL/APlhX03+z5+0p4I/aQ8M+KtS8HaL4w8Pv4f1COzvrPxFaQQzEyRC VJE8iaVChBYcsGBQ5UDaT/OzX6rf8Evv+Rf+PP8A2HNN/wDSRq+i4R40xma450K0Ipcreid9Ld2+ 59XwL4hZhnWZPDV4RUeVvRO+jXdvufqtRRRX6YfsIUUUUAFZOua1Y+HvCt5rGpOyWlugLBBlnJIV UUd2ZiAPcirl9fWWmaVPfahdQWVnCu6WeZwiIOnJPvxXzd8S/H2j+KtD0/StFi1OVYNRW4kupYRF E6CKVcAMwfO51PKDpn0q4QcmYV6ypxfcwtf+JPirXrmQRXs2g6eT8lrYSFHA7Fphhy3+6VX2PU8H Lmecy3DPcTE5MkzF3J9SxySaKK7EktjxJzlJ3bLZ1DUzo82nf2rqo06VdsloLyTyWXOSpTO3BxyM cjg8VUoopk3CiiigAqWCe5tLv7RZ3l7YXG0p51pcPC5U4ypZCCQcDjpwPSoqKANmDxJ4mtplkh8T eIw6nK+Zqc0ij/gLsVP0IxXpfhf4v6laX8Vt4saK+09mAbUEiEcsGf4nVcKyjvtCkAZw1eN1HKgl i8p3aKORgkkipuMaEgM4X+IgEnb3xjvUuCe5rCtODumffFFZGhanpOreGLW60S8jvdPCBEdScrtA G1geVYdwQCO4orhZ7yd1c16KKKBhRRRQAUUUUAFFFQ3Ewt9PnuCNwijZyM4zgZoAmor5T8BfEj9p b4jfAzwX8QNH+GnwN0zSPE2hWesWNve/EDUmnhhuoEnRJAuk7d4VwDgkZBwT1rrPt/7U7f8AMp/s /wAP/c2apJ/7YLQB9AUV8/8A2j9qdv8AmFfs/wAP/cV1ST/23Wj/AIynbv8As/w/hqkn/wATQB8V f8FQf+Rd+A3/AGHdS/8ASQV+VFfod/wUJj+L62XwTPxJu/hvPYnWNQ+xr4atbuOQP9lGd5nkYFcd MAHNfnjX4J4lf8jdf4F+bP5i8X/+R6v8EfzkFYPikA/DLxGCAQdLuMg/9cmrerN1mzl1HwhqunwN Gs11Zywxs5IUMyFQTjPGTXwuGko1oN9GvzPzXBzUMRCTeia/M+K/BfiSbwT8MfGdheXCwvrGhJd6 Vtfq7O0Hy5/i+bJHpGT2rQ8N6ZcaT+zr8YNMvVj+1W5tFlC8gNuJx07fzr0K9+COqX+lfD2Ce50V 30hDBrBMsmJofP8AMCx/J83DSD5tvJFdRdfDbW59D+KVsl3pQk8S3aTWJMj4jCsWIk+Tg89t1fre L4hy2UpShUV5zjKX/blSKX/kqcvmfuuO4qyicpTp1VzVKkJS/wC4dWEY2/7ci5fM+drtPAV18PNF 0rw74d8TL8Q7iG28ucFhG8vy72ALnKt820qo7HgV9waFFqEHgrR4dWcS6rHZRLeOG3bpQgDnPf5s 815f4l+F02v/AAS8MaTHd21n4r0OzgjtL9HYJvRFVl3Bd2wlcggZBAOOoPp+hJrEfhGwj8QNZSay kQW6ktHZonYcbgWVTyMEjHBJHOM18nxNm9HHYWn7Od2pSupNylrazTf2Wlt0Z8NxjnuHzLBUvZTb cZzupScpK9rOLf2Glt0ZrUUUV8SfnR9Z/sXaxeaH+1D40kstdm0WbUvDEOnqNOsxdancs11uEFnG fkWd9vEkgKIqyMR8uR+wPgz4TJ9jtLvxfYWtvZQ3P2yy8LxXDXMEU5IP2q+mb5r+9JAJkkyiEDYC VEh/Jr9hLSb7X/2pPiJpdlpnhzV9ng2Kaey1aJgl4n2xR5YlXJhcEKySBW2sOnOR+sHhzxpq+g3V xp1zFruu6bZKGvtLv036/oqE4DMqk/b7b0mjLPx1lOcf09wPwnSx2R4fEwnzyS+B9Pef5vp8LdtX K0Y/2h4b8aV8DwlhcFSh7O6lea3fvS+6y0vrJK9uWLm5e+0Vn6Vq2ma5oFtquj39rqWnXC7obi3k Do46HkdwcgjqCCDWhX0E4ShJxkrNHvxkpK6egUUUVIwooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKhuLi3tLGa6u54ba2hQvLNK4RI1AyWYngADuaaTbsgbsed+N/hlovjAz38LJo3iOS2+zvq CWyTR3cP/PvdwN8l1Acn5H5XJKMjfNX4+fty6D4w0nx18INI1yC+Sw0Sy1nyVe8W6tIkuG04J9lm dvPMTGB8QzAvCVIDuhQj9WPEfxQuL+O3tfCZns7K8JS01X7GZ7vUSOo060ODKPW4l2wLkN+8XOPy 4/b50DUdA8Z/BCbV9L0+0vtWt9dm3yXL3eor5Z0wE3N0W2yu/mL8iqEi8sLGdpJPmcY8JU8Nk2Ix uIl7OfK7R6y6arpZ7+atK3unicZcZ16vC2My6cfa0uTR9YNbOLaenl/K2oNc0mfB9QXX/ILuf+uT fyNT0yRBJA8bEhWUqcdea/laLs0fxZB2kmfJnw5b4mD9n+UeHY/CLaBm4yb4y/aO+/7px64qSz8S nw5/wT6thDL5d9qM09lb9cjfNJvPHTCBsHsSK+hvDXg3TPC3w7fwzp89/NYN5mZLh1aX95nPIUDv xxXM2vwj8NW1t4UgN5rdxb+H7h7iyhlnj2yO8gkJkwgzggdMcDBzzX6HU4ky+tXqSqRtH2qmrLWS ipW5vNtpfNn6rV4uyvEYqrKtC0PbKorRs5KKnbm823FejZ89fDrxJ4d8M/HfwymhXN0+m6ppcNlq 3nqy7btzyQCSMbwnPQBmwcV9r1yPjHwVpHjfw9b6dqsl7bLBci4hns5FSVHAI4JUjBB9PT0rq41K QIhd5CqgF2xlvc4714HEebYfMpU68E1OzUk3fbZ3sr6O23RHy/FmeYXNpUsTTi41LOMk3zbP3XzW V9HbZWsh9fod/wAE9vEnxG0Oz+NcXgn4Z2/ju1l1fT2uZ5PEsOnGBxasAu142LZHORivzxr9Vv8A gl9/yL/x5/7Dmm/+kjV7nhr/AMjd/wCB/mj6Twg/5Hr/AMEvzifa3/Cwfj3/ANG8WX4fEK0/+M0f 8LB+PX/Ru9p/4cG0/wDjVfQFFfvZ/Tp8/wD/AAsL48/9G7W/4fECz/8AjVH/AAsP48f9G7Q/+HAs v/jdfQFFAHxl4x8YfELxH4sj0nxv4C/4QC1srWO6s7dddh1EXryNKjOTGoCmMRgAH/no1cxX1v48 8DweMdGtzHOtlq9nuNpcMuUIbG6Nx/dbavI5BAPIyrfKV/Y3el6/faXfokd7aTGKZUbcucAggkAl SCCCQOCOK66Uk1Y8bGU5Ko5PZlWiiitTkI5iRaykEghDgj6V+dfhz9of4u6N8FfBuoRx+E/EGi6X 4N8J6l4iutaFy+p6g+rX01nII5FkCKw8sSb3U4IIw24FP0XIBBBAIPUGuSXwB4DTSG09PBPhFLBr a2tmtl0eARGG1kMltHt2Y2QuzPGvRGJK4JzSirTT6afhf/M0Uo8ji+p8C237Snxq8O+BjaT/APCG eK/El14n8WzrdT2c3kw2OkXCxiyISVBG7s/yzudsUKqzrIxY16XffHf413MnjfXNB0b4aW3hrT/E ug+HdHsdTiu2vjd6l/ZLu1xJHL5flRpfyDKLksFOMKQ/05f/AAl+Feq2l3Bqnw08AajBdaq2rXUd 14etZFmvWGGunDIQ0xHBkPzEdTXRP4U8LyR3ayeG9AkW61CHUboNp8RE91D5fk3D/L80qeTDtc/M vlJgjaMKjHlUed3skvutf71deuu7ZVSpFt8qtq/xd193/A2PgnVf2tfitpofRI/Cvgq98TaFJrkn iC5SC4Sx1KPTNQjtDHbFph9kaQPuMszyrH8uVbdx9D/s9+L/ABz4u1P41N401jStTi0v4iXun6LD axGOSztESIxxOPYMOepbeST29Xv/AIZ/DjVWtDqnw/8ABWom11OTU7b7TodvJ5N5I2+S5XchxMzA M0g+YkZJzW5pvhnw5o/iTWtZ0jQNF0vV9YkSTV760so4p790BVGmdQGkKgkAsTgE4opXS97V2a+d 4u/lomrfPqwqzg1aCtrf5a6fin/wyNuiiiqMTqPCreP1m1L/AIQNXYny/wC0OE25+bZ9/jON2cc4 257UV9C/CZEX4FaU6wxRO81yXKIF3kXEihjjqcKOTzxRXNKrrsepRwt4J8zPR6KKKwPQCiiigAoo ooAKzNbfy/Bmryf3bKU/khrTrC8Uv5fwy8Ryf3dLuD+UTUAeYfs0p5f/AATk/Z/j/u/DfQx+WnQV 7ZXjv7OyeX/wT++Bcf8Ad+Huij8rCCvYqACiiigD5j/aY/Zl0b9pTwv4OstS8X694Nu/DmpS3drd adbwzCUSwmJ43SVT/skEEYweuePk7/h2BoX/AEXPxr/4I7L/AOJr9TaK83F5NgcVPnr0Yye12k2e Rjsgy3G1PaYihGcrWu4pux+WX/DsDQv+i5+Nf/BHZf8AxNH/AA7A0L/oufjX/wAEdl/8TX6m0Vy/ 6s5T/wBA0P8AwFHF/qfkf/QJD/wFf5H5Zf8ADsDQv+i5+Nf/AAR2X/xNH/DsDQv+i5+Nf/BHZf8A xNfqbRR/qzlP/QND/wABQf6n5H/0CQ/8BX+R+WX/AA7A0L/oufjX/wAEdl/8TR/w7A0L/oufjX/w R2X/AMTX6m0Uf6s5T/0DQ/8AAUH+p+R/9AkP/AV/kfll/wAOwNC/6Ln41/8ABHZf/E0f8OwNC/6L n41/8Edl/wDE1+ptFH+rOU/9A0P/AAFB/qfkf/QJD/wFf5Hxz+zd+x5oP7OvxT8S+L7Tx54j8Z6r q2lR6aFv7SC3igiWXzSQI1yzFgvJPAB4OePqLxH4U0jxPa2/9oRzwX9qxew1KzlMN3ZOf4opByue 6nKsOGDDiukor28BFYJRWG9zl2tpY9mhgMNRoKhTglBbJLTvt6nzhqdn4k8BeI59ZuL210ySZ90/ iOG2I0rUT0A1S2T/AI95eg+1xfL3baAIz6x4b8b2etakuj6lav4f8TiHzTptxKHFxH/z2tpR8txD yPmXkZG5UJxXbMqvGyOoZWGCCMgivFvEnwwEGmsfCttb3OlrN9oPhue4aCKGXk+dYTr89jOMnGz9 2ckbV3F6+shjsJmMVTxS5J7KS2+fRej93ZJ00nfilh6+FblR96PVf1+e/dSb09qorwfw58SLzSVu bPxI+o6pplkQt5ez2gi1TSM9BqFsnDR8HF1CDEwBJCgFz7jbXVte6dBeWdxBd2k0YkhnhkDpIpGQ ysOCCO4rxsxyrEYKVqi0ezWz/pa2dnZp7NHdhcZTrq8Xr26k9FFFeadQUUUUAFFFFABRRRQAUUUU AFFFFABRVS/v7HS9HudR1K8tdPsLeMyT3NzKI44lHVmY8Ae5rxDxH8SNT1a6t9M8MxanpdteqTaT RWYk1bU06FrO2kwsMXrdXO1B2VgQ1enl2U4jGy/dqyW7ey/pa2V3bXZM5MVjKVBe89e3U9H8S+N9 M8P3i6ZDFca34jkiMsOk2JUy7P8AnrKzELBEO8khVeMDJwD45DB4q+KGpx3LS6dqGmJIHjuXjZ9C syDwbeNtranOD0mk2wKcFFJBB6rw18Kkks2k8WxQfY5pRPJoEFw88U8n/PS/uH/eX0v+/iJeAEO0 NXtSqqRKiKqIowqqMAD0Fey8dg8sXLhVz1P53svT/gab3c4uy4Vh6+L1re7Hsv1/q/kmrnMeHPCG k+G5Lm7hNzqWt3YAvtYv3Et3dY6BnwAqDtGgVF/hUVk+OvhT8L/ihDpkfxK+HPgX4gpprSNpy+JN Ct9QFoZAokMXnI2zdsTO3Gdoz0Fd/RXzNfEVK83OpK7f9f8ADdj1qdOFOPLFWR8/f8Mm/stf9G3/ AAJ/8IPTv/jNH/DJv7LX/Rt/wJ/8IPTv/jNfQNFYlnz9/wAMm/stf9G3/An/AMIPTv8A4zR/wyb+ y1/0bf8AAn/wg9O/+M19A0UAfP3/AAyb+y1/0bf8Cf8Awg9O/wDjNH/DJv7LX/Rt/wACf/CD07/4 zX0DRQB8/f8ADJv7LX/Rt/wJ/wDCD07/AOM16Z4H+Gvw7+GWg3mlfDjwH4O8A6Zd3H2i6tPDujQa fFPLtC+Y6wooZtqqMkZwAK7WigAooooAKKKKACvKPHvw1XxNfHWdHngsdb2BZlmyIboAYG4gEq4H AYA5AAIOAV9Xopxk07oipTjNWkfFuoeEPFelzFL3w3rAOM7re3NymPXdFuA/HB9qyI9P1Oaby4NK 1a4l/wCecVjK7fkFzX3TRW3t32OJ5fG+jPhG5tbyyv2tb+yvdPuQofyrqBonKnowDAHHBGfUEdqh r7U8Q+F9E8UaattrFmsxjyYJ0OyWEnqVYcjoMjocDINeMap8FNQjlZtD1u1uoyfli1CMxso95EBD H6IK0jWT3Oergpxfu6o8Sorv7j4XeOYJCi6PDeY/jtr2LafpvZT+YFV1+GvjtmwfDkyD1N7bf0kq +ePc5/Y1P5X9xxFFerWPwc8V3MiG9vNF0yFurCR55E+qBVU/g9egWPwY8Mw6Wyahd6rqF6wH+kLP 5IjPfYi8Y/39596l1Yo1hhKsuh801r6FoOp+JfEUel6TEXmODNMVzHbIf43Pp1wOrEYHt9E23we8 IQ3Ie4bV79B/yymu9i/nGFP616Jpmlabo2lrZaVY2un2oOfLgjCgnux9Scck8molXXQ2p4CTfvMb o+l2uieF7DSLIMLa0gWJC2NzYHLNjqxOST3JNFaVFcx6iSSsgooryr4w+PNS+HXwz0DW9KtLG9ub /wAceHNBkS7DFFh1LWrLT5nG0g71juXZecbguQRkEGeq0V+Svhb/AIKNeIh8WpYvEvh7wR4z8NWs Xiu88S6L4EW7k8Q+D7DQmucXt8kzG2aOdYIwoMkJzcJt3n5D9FfHT9tnwf8ADb9n74ta54L0q88Z +L/DN02laFaKqSWetX66OmszvG0Uhc21pZOLi4dhGAEKKxdlyAfcFFfFI/aa8VXf7SPgDwzpmi+G rrwtq82h2GqXwErSQahfeH9f1q5t0YSYBjisdIcBlJ2XrE5JUr8p+CP+Chfxa8WfBTxT4m0bQfgp 8Rr3RPhXH8QNYt/CtxqMa+H44Ly3F7pd+0wMa3bWjXckJSQkSWrBomjKuwB+wVZOv2E2q+Bda0u3 kjinvLCa3jd87VZ0ZQTjnGTX5+fEz9tLxZpPxK8Q6f8ADjw14d1zwg/ivQ/Cfh3xRJYahqyT393o 11rd7MLTTVluLqOK1/s+JIYkRvMuJHaQIhFd18d/2o/F3w4/4JP+D/2gfAXhvwr478Sa7Do0ttpl pNdT2N0L4Iz/AGdikU7DDHZvjR+m5AcrQB9U/DXwxdeCf2c/AHgy+uLe6vdA8N2Ol3E9vny5Ht7e OJmXIB2koSMgHFdtX53+Ff29/DetfGz9oJn02PxH8LfCMvh218BXvhW3a81Lxfd6o81qbe3UyCKV zewyQR7Sigo5ZgASNXX/ANu3RLHxF4GvPDfww+KPjHR77TfFa+KvDekaDHN4k8PajoUmm+db3ERu VgjVI7qcufMfext1iLGRVcA++6K+JG/bA0JvFun61baloMvwpm8Y/ZbnXpdPuInt9FPgNvFQu8Fy zOcLnMa4jYp5e9d59W+Af7S3gL9oiw8Tf8Inp3irw7rGgrYTalo3iK1hhvI7a/thdWVziGWVPLmi LEKXEimN1dEYYoA+haKKKACiiigAooooAKKKKACiiigAoqhqup2ei+GNS1jUZJItPsLWS5unjheV ljjUuxCICzHAPyqCT0AJryD4Y/tG/Bv4yeNNW8P/AA28XS+JdV0tZTqMS6Le26WrRPGksUkk0KIs yNNGGiLeYN2SuAcAHt1FFFAHLeI/COleJDbXMzXWm61aA/YNYsHEV3aE9Qr4IZDxujcMjY+ZTXiU i+KPhhrbzbtM0+xnmy8wVotC1JmPWRRuOmXLE/fG63djz8zAL7trfirQPDuueFtN1rUY7G+8Saqd K0WJo3Y3d0LW4uzECoIU+TazvlsD92RnJAPAeOvjl8G/AXxS0P4eePPHPh/RfE+vwI9ppN3udmhl mFtHJNhSsEMkzCFJJiiPIdiktxXuZdndTDx9lVXPTf2X+j6em19VaVmuDFYCNR88Hyy7/wCf9eW2 h2nhrxhpniR7izRLnStetVBvtHvlCXVsD0bAJDxn+GRCyN2Y811deFeJfhdPYJb3ng5Z5bSzYyWm kpd+Rc6cT1bTrk58nPe2k3W78LhBnMvhj4qCFJLLxjKqw28ogl1r7Mbb7NIfuxX8B5tJT2fmCTqr jcq114jJKeIpuvgHzLrH7S+XX01fROVmzClj5U5ezxKs+/R/1/w9rpHuFRyyxQW0k00kcMKKWeR2 CqoHUknoKerKyBlIZSMgg5BFfK/xS8RXmrfES70nznGk6dIEigBwryAAtIw7sGJUZ6BeMZOfm4Qc nY9CvWVONz6Kg8V+F7q8W3tvEugXFwxwsUWoRMxP0DZrybxD8ZfKvpLbwxY291Ghx9uvNxST/djU glfRiw+mMGvAiAylWAZT1BHBpa3VGKPOnjpyVloerD4yeL96lrXw4R/EBaSjP/kWvTfC3xS0XXA1 vqpg8P36ruAnuB5Mo77XOOe+08+m7BI+XKKp0oszhi6kXvc+7ba6tby0W4s7mC7gb7skMgdT+I4q evhvSdY1Dw/raappVybS6TlznCSqP4ZB/Ep9D06jBAI+zbzXNN0vwedc1q6g0bT0gWWeS8kEYiyB wxPfJxjqTxWLoSclGKu3t3PRoYpTi29LGvXB+J/H2m6Dez6XYwnXfEUcPnSWEMyxpaR4z511M3yW 8WATuc5IB2q5GK888Q+P9d1/VY9F8P2us6RFcx74La2hUa1fxnjzAkny2Fuf+e9xhzyFRW2k7nhn 4V2sNnBJ4pisbiJJvtEOgWjO9hDNnPnTM/7y9uM4JmmzyAVRTyfoqOT4fBwVXHy32gt362e3o11X MpLlfFPHVK8nDDr1l0/r/gaNO5x9hpniv4kazbatNdwz2Ucgkt9WntCNNtSOh0+0k5uZB2vLgbQf mjQgla9v8O+FNG8MW1x/Z0U019dMHv8AUbuUzXd44/illblsdhwqjhQBxXSUVw5jndbEx9nFclNb RX67X77JX1STbOjC4CFJ8796Xd/p/V7aXCiiivFO8KKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigArivHvgTSPiJ4Q0vRdaudStbWw8R6TrsL2MiI 7XGm6hb6hArFlYeW0tsiuAAShYBlJDDtaKAPD/AXhf4UfCH4B+I/htB4q0u88OaHPqGo+JF8Q6na vJZR6pd3V/J9rwEWOFjcTBN6jMajJbBY+O2P7An7N1t+whpnwA1Dwq/iPw7pdtqkekeINXitZ9b0 6XUWZprqG48gIs6/ugj+WQBBCGDbOfhX9sb4I/Ha8+Jn7ZnxV+Efhjxhrt7rsGkeFNU8ODS7m4t/ Euhz6TZh7qxhjTM95aXijDoSFRrhSOGVuh8UeH/2s/G37UX7SvhbWH+MTaVq1h460yPSRZ3jaBfa HLpMcfh8WUrhdPhuTK0XNu0ly7vdLcBFU4AP0C8G/st/C/wl4f8ACcPhnUPEg0zRfFUHifSwt5A8 bSxeHP8AhHYIciL5rdbHYQB85kUOXILKfWfAPw18N/D39mLwp8JNMW61bwnoPh6DQoBqvlyy3VtF CIf3+1FR2ZR82FUEk8AcV+Mtjf8A7ZXww+EXwsg+EHhP42+I/CfhrwJoHjm40TX9M1WG4kvLG2h8 P6l4TETxhgjfNqKQFNrbDLEjAq49l0/w7+034O/aq8FeFtX8T/tQeJ/Gmian4Js9A1KzeW58E6ro ws4V8TXGqTsGhaZphqrH7U32tW+w/Z8gigD6h8NfscfBn4dfssfDr4E+EPGvjjwXqPh/xJc+KPC3 iOx1izh8RtfYlSecE2/k3Ci3u2tnVrdl8lkDDcFeu58UfDD4F+Af2UvhL8NfFHi+w+H3gPwTqukX Ph+TVNbtbI3c2mOk0Ucsk42y+YUzKFCs25iCuc1+Yfin4RftZ2/7M/wB8Z+Edd+PevfFe+8OeLdW 8dXPiG/vn1bSbWVNP83SdLkkt5v7NvJ4rdo7UMgPmlmB3Bdv3D+0b4A8W/FTxz+x4nw6tLzTrKHW b+6n1bxh4Lutcg0e3fw/diNtTtLmSKQSOWWH/SZEcTuu7LjaQC94G/YT+Bvhv9nHTPCng3xX4/fS F0nSE0TxDbaxaSXdtJp2r3+s2eowSrb+W04udSmOWR4mjWJfL4JbP8afsg/B3w54O8M3uqfHr4q/ CnUxqWuwX/i2HxVpun3vii98SG3S8S7kntDDJNJ9mgWFIY49hjQoodEZfFLP9mr4y/B24/4V/wDC b4hfGG7tvhz8CNS1DwgdLYaXoPiDxffX2rzET2qj7G5SSaJorVyVjTyd5dRluO+F3ww+LnxB8T/A XUPHOo/tH3Xhrwt8Z7K7sU8QtrVvc2qL4VuJ7ya5fUFFxNbHUIYYBNNGkateXltCTHKCwB9taR+y Z8BNb+G+nRaHc6prXw6vpo9QsbCz1lJ9OurNvCX/AAiqQRzqpke2bTSGDiUyGUhxJt+Su9+An7PH hT9nzwhquk+G/EXi/wAUNfR2cDXfiCS08yG3tIBBbwIlpb28QVV3MXMZkkeR2kdyRj85fBS/tG6f 8cv2RbJNP/alsvhfZ+DfCMPxotILK6ht4dVFtL9iWBJlEwiWby/7UFqPKEQQTjfvFfsvQAUUUUAF FFFABRRRQAUUUUAFFFfPnxP+IHirSP2wPgZ8N/DUkNlZa/b69rviG7ZUd3stMtIo1tkV1ODJdahZ uXBDBIHUffJAB9B1+Zlt8F/jh4R0nxV4j034fXfiK+t/2tr34g22hWOv2MF1q+gz2jWwmheWZYRI DLv8meSIkREHaSueF+Df7Vfx10r9jKT45/Evw/8AHDx5B/wh+nXdtper+E9D0DRNVvb+/sLaI2F5 bySXL8XLGPzokSRCzNsO0D28ftn+ObxofBGjfs+tqnx7bxnrfhxvBn/Cc28WnsdK0+31GaePU2t8 MJIb20WNGgQ+ZKysUVC5APkK6/Yx+N3ir4AeKL/xR8Mprb4k6f8ADvVW8EQw+L7YtpniKfxjq+qw PBPHOgWdLae1dLhtgAkZCVJkQe0+MP2Ufi1f/H34ifErwNpP/CKfFPWviZ4hOj+MxryxPZaFd+Dp bK0kYRyFhENVED+WI2lVkD7NozXtWs/tozaB+2Hpfws1b4YRWCXtlIZJD4wtbrU7C8TQ31hre6tb VJoYF2o0AZrre7qZEieHbK1/4NftX+OPizYQWUvwLPh/xfqHhjwz4w0TSIvGcF1Fe+HtYu/Ikvmu DBGIpbaNLiZrZlLSCJVU7nwoB8q/s/fstfHzwfo3go/8I3qvwv8AsnjTTb97K9v9MvbfRrmHwZrO mXWsx2lvdSpL5t7d2avmdprlozLJHEC2PVPit8PP2odX+J3wX+HPifwfJ8fPhvaXFpq3xL+IOhf2 J4dvPEdxa6rLd6dpslnPcborG0Ihmk8re054QxkybvrzxD428RWH/BRn4XfD61vY4/Cus+AfEWq6 haGBC0lzaXmix28m8jcu1bu4G0EA7+QSq4/PrwD8ef2m/il4B8P6xpvxf8PeCbzTf2c7D4g6iNQ8 JWk9jqmovqGpxyC5c7Xgt3iskB8oqVyXXoVYA/XiuO8T+CdK8TSR3rPPpWvQxNFbatZhROiHrG4Y FZYj3ikDIfTOCPyPj/bB/af+IHxu1F/hZY+INU1RtD8A6vofgTTfAn9paM665p8F3fx6lq6oGsYo w7lJpHTIVsBgG2fph8FPGXirxJqXxl8N+MZ7a/1bwX8SL7Rbe/hRUF1ZS29rqlluRVUK8VtqMFux /iaAuTlzW+HxNWhUU6crNf180+qejM6tKFSPLJXR4/4x1/x18ILS20C3aKy03UCyQLbSYsXVSufs bOxeylO4AwOWi5HlSKc45tZ3uh9qlNw00+JJGnJMhJHVyeS3rmvq34meC/8AhMPBaiFYZL+zDtFF Mu5J0YDfERz12qRweVA6EmvlJWDIrKcqRkGvax2ZwxsYzdNKprzNfa7P17/5WS8CeEnQm48149F2 /r+u7WvmP4Za+3jeP43+E/EXjjUob6D4k6hp+mi11cW99aW0aW7xxQEHeqjLdB0LV9OVwkPwt+GN v8Tj42g+HPgSDxmZ2nOvR6BbLqBlYFWk+0BPM3EEgtuyQTXl2fO29mmvvcXf8GvmWpJQt1un9yat +P4H56jXPiPa/si/AzxBY+PfHniTxJ4u8dXWn6rHqXjg6XHcwW6aqEjW58tltx+5iLFUJcxqOpzX 3/8ACcakPgLoY1gzf2p+9+0pL4m/t1kbzXO37ZsTzRjGPlG0fL2q/qnwy+G+t+B7LwxrXw+8Eav4 bs7hrmz0m90K2mtLeVi5aRImQorkyOSwAJ3t6mtzw94Z8N+EfC0GheE/D+ieGNEhZmh0/SbGO0t4 yzFmKxxqFBJJJwOSc1ULpSv1f6JW/r/MK01Npr+tX/nY2JWjS2kaVgkQUl2LYAGOTntXoHw8s/F/ xQtotd1LUrgJY3Jig12/iVpIAFUj7BaMuyOTawzdTB3OTtXB+XgiAQQeQa+wvh7bxW3wa8PiK3S3 8y0WVtv/AC0Lclz7tnP48cYrvwuaSwcJOnFc0tLvWy66efnpbdPoqOEVeolJ6Lp3/r7+zNPw/wCG dF8MaVJa6RaeUZpPNurmWRpbi7k7yTSsS8jn+8xJxx0AFb9FFeLWrVKs3OpJtvq9We/CEYRUYqyC iiisygooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK8o8cfCy18Y/H j4S/EGLUl0rWfBV7qAfdamYajp99ZSW9zZEiRfL3SrZziTDEG0VduHJHq9FAHyx4b/Yt/Z08J+F5 dC0Twh4ni0F7eC3GlXXj7Xbuzjjgu4LyIRwTXrxx7Z7aFwUUHClc7WZT0PjH9lT4C+PLfWF8TeBp bmbU/Elz4ivLyz17ULG7a+ubGPT7l0nt50ljjmtYo4pIEZYnCgshPNfQ1FAHzDd/sgfAldfl1zw/ 4SuPDGvRQt/ZRsdd1FNN02f+yhpCzxactytoGFmqQnEQ3qi7iSARF8Iv2RPhF8J/gVpPhG303Udd 1NLDQodX1u61rUGmvptHlS5tGjElzI1rbrcoZhaROIRvZCrKSD9R0UAeOfFr4A/Cf44poB+Jfhm4 1q50T7SNKvbLWb3TLu1W5i8q4jWezmik8qVAFeMsUcAZBwMcH4s/Yz/Zt8b6v4dvPEfw5a4/sPwv aeF9PtbTxDqVnaf2TaStLBZS28FwkM8Ku7HbKj7uA2QAB9P0UAcH4Z+GPgTwb8UPGPjLwx4et9G8 ReKYbCHXLiCaTZcR2MBt7RFiLGOJY4mKgRqoPfJ5rL+F3w1T4cWHjmWfWZPEOu+LPGWoeJNX1B7f yA73DqlvCse9gFt7OG0tQQfnFvvIBcgeoUUAFeH+J/g+t7q89/4bvbexMzl3sblSIlY8ko6glR/s 7SOeCBgV7hRVRk47GdSlGorSPlm8+Efi2y0S5vC+lXkkK7hbWcskkkg7hdyLyBzjknGByRXmJBDs rAqysVZSMFSOoI7H2r70ryT4tabp3/CBS6n9gsv7S8xV+1+Qvm7cHjfjOPbNb06rbszz8ThYwjzR PmapoLe5umlFrbXN0Yk3y+TEz+WucbmwDgZ7nisvRHabxTBHKzSxmUAo5yCM+hr7y0zT7DTdIjt9 OsbPT7fG7yraFY1yRycKAM1pUnyo5sPR9q7XsfJ3hjwNrniXV4UFndWOmbh597NEUUL32ZHzt1Ax kA9cV9dW1vDZ6db2ltGIreCNY4kHRVUYA/IVPRXLOo5HrUMPGktAoooqDcKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/9k= --_004_D0877F0D1782C4sgundaveciscocom_-- From nobody Tue Nov 11 11:39:48 2014 Return-Path: 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 51E551A8856 for ; Tue, 11 Nov 2014 11:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] 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 15BryHpfRN6L for ; Tue, 11 Nov 2014 11:39:36 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4017C1A8858 for ; Tue, 11 Nov 2014 11:39:36 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DF61C20098 for ; Tue, 11 Nov 2014 14:41:38 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id AAF69637F4; Tue, 11 Nov 2014 14:39:34 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 955C9637EA for ; Tue, 11 Nov 2014 14:39:34 -0500 (EST) From: Michael Richardson To: "mif\@ietf.org List" In-Reply-To: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> <28162.1415680214@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/mif/XOH-8z-eQg1NEaroZ3WJDG__Qcs Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:39:46 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: mcr> As you say, this is a kind of MIF with multi-provisioning domains,= and mcr> if the host can decide the right choice of source address, the res= t is mcr> "solved" by homenet already. > Not to rain on your parade, but at the moment with a total of one RFC, > homenet isn't solving anything. Hopefully that will change, but I > object to referring to that as a fait accompli. Well, there is the air-quotes around "solved". The situation is that the problem of picking the right exit router given source IP is well explained in homenet, I think that there is running code that implements if automatically, and we have documents that explain how to do things in various stages of preperation.. They could probably be WG LC'= ed almost immediately. So while perhaps homenet is lost; it seems that the AD for Homenet and MIF ought to be able to clearly say which WG should solve this problem, if it makes sense that it should be solved only once. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGJl84CLcPvd0N1lAQINjAf/RY02K1dLHKn7z4sgEDBAyOYdGz+GFxSR s6SEyWth4uD5xgvDvfYD8oiQWhhfManPo45RxiMJLUg2M0Xa8ihM52gDj2xQ7u9Y lm+DIs78cbIN+1QQm4MpuO2mMiNZFBXxAFVJBUARzDoXBovjpb2hnMsa1cr0qHO/ 4CZyLPJQKa9CTuVY9b3W2x1aDmWLHYX4aFFBgtZddXRgPDThx967IjSpVnDd4/F1 c08WuHOxXUi+zqerhVMEsRLDkbH2JrA1dDOlTfnDucX90RB57FW7XJ3hsxzmq69u 3IBe6VrtIjXwdM/Z36pxguXhaclfCEx1ihy40TeedtrORlDDsx+gNw== =6xuE -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 11 12:16:15 2014 Return-Path: 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 694421A1ABA for ; Tue, 11 Nov 2014 12:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 cdgeZquha5cb for ; Tue, 11 Nov 2014 12:15:59 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477661A90B5 for ; Tue, 11 Nov 2014 12:15:03 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 894AFDA01A9 for ; Tue, 11 Nov 2014 20:14:33 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 157E253E07E; Tue, 11 Nov 2014 12:14:33 -0800 (PST) Received: from dhcp-8fde.meeting.ietf.org (31.133.143.222) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 11 Nov 2014 12:14:21 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Tue, 11 Nov 2014 10:14:14 -1000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> <002c01cffd58$18276ca0$487645e0$@com> <5462343B.7040705@gmail.com> To: "Sri Gundavelli (sgundave)" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.133.143.222] Archived-At: http://mailarchive.ietf.org/arch/msg/mif/qFeeccJlpv53nfTUWWiV2S64Arc Cc: "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:16:04 -0000 On Nov 11, 2014, at 9:22 AM, Sri Gundavelli (sgundave) = wrote: > Can we split a audio flow on satellite access and DSL link and say its = an application problem ? Is it not a network design problem and should = it not be avoided ? This is precisely why I question whether the proposed architecture is = actually the right thing. From nobody Tue Nov 11 15:32:20 2014 Return-Path: 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 1098D1A6FE6 for ; Tue, 11 Nov 2014 15:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 c2TkpLrIAki0 for ; Tue, 11 Nov 2014 15:32:15 -0800 (PST) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450F71A6FE1 for ; Tue, 11 Nov 2014 15:32:15 -0800 (PST) Received: by mail-yh0-f46.google.com with SMTP id t59so463424yho.5 for ; Tue, 11 Nov 2014 15:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0y/tc2DBWGgmWEvJM1vSLA1uytLS1iubQ0/uxxxNTsM=; b=QPcuZ/LgqVqmfTCjrOLlwtQV8FVFRLyXXAQyOn486pVdKkyK3l5BrwI7B1wGNAUtoz 5wPD/xVdrzsFPI5I9u1wHc5MCBBeGpfsPBwXVvrcu6cw5UOM4ydn4bwjDQeRsSXcr+oO WtbqABjJQXPES98eEnO9m6tAygCAVdISdJgNJsyR5BMMCBf130lelW9IyMLgZ2pQbA9a SPhEvtauuQC67u2c81fwQroOA6yQYKHGh2omzUE8fBZjllWXCNYk5ux94Sg0aHFLg5Zl ZiNdi9/Vk3mM/hBCgDUHM0NFnHZD4PQ6WALMHT4Yny+ZCKjthV1ASk4P5PdTwBTKHelw qUjQ== MIME-Version: 1.0 X-Received: by 10.236.60.195 with SMTP id u43mr267627yhc.142.1415748734474; Tue, 11 Nov 2014 15:32:14 -0800 (PST) Received: by 10.170.71.198 with HTTP; Tue, 11 Nov 2014 15:32:14 -0800 (PST) In-Reply-To: <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> Date: Tue, 11 Nov 2014 17:32:14 -0600 Message-ID: From: Behcet Sarikaya To: Margaret Wasserman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/8ERGu9LnQrjB7g-GChGf_np6tJs Cc: "mif@ietf.org List" Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 23:32:17 -0000 On Mon, Nov 10, 2014 at 10:08 PM, Margaret Wasserman wrote: > > > Let me see if I can start a technical discussion here... > > If you have an ISP today that has two different access networks available, > such as one 3GPP network and one DSL network, how do(es) the gateway box(es) > (connected to both networks) decide where it should send each packet it > receives? I think there are several possible cases here; > > (1) There is one gateway attached to both outbound networks. This has two > sub-cases: > > (1.1) Hosts behind the single gateway have separate addresses on the two > attached networks. In that case, the gateway is constrained to send packets > over the outgoing network that uses the address prefix that matches the > source address, or the packets will be thrown away by ingress filters on the > other side. So, the network choice is made by the hosts. > This case is not valid because both attached networks belong to the same operator. Also the hosts do not get separate addresses from the attached networks, I think. > (1.2) Hosts behind the gateway have only one address each. This has two > sub-cases: > > (1.2.1) The gateway has separate addresses on the two networks, and does > some sort of translation from internal to external addresses in the prefix > of the "right" outgoing link. > Yes, I think this is the case. > (1.2.2) The gateway has only one IP address that is somehow shared across > the two links. > > (2) There are two gateways, each attached to a single outbound network. In > this case, hosts will always have separate addresses for the two networks, > and will need to make a decision about which outbound network to use. > > Cases 1.1 and 2 are essentially the same from a host standpoint, in that the > host needs to make a network choice. This is a problem we have discussed in > MIF -- What sort of information does/should the host need to make that > choice, and how is that information communicated to the host? > > Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for > multi-homing. The IETF generally prefers to avoid recommending solutions > that use NAT, but do we have a better answer? > This could be the case. I want to also say here that CPE here is not a mobile router. There might be mobile routers that are connected to two networks but not in this case, I think. Regards, Behcet > Case 1.2.2 becomes a layer 2 problem and is probably outside the scope of > the IETF. > > Are there cases that I am missing here? > > Margaret > > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Tue Nov 11 18:19:43 2014 Return-Path: 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 C68FB1A90C8 for ; Tue, 11 Nov 2014 18:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.428 X-Spam-Level: ** X-Spam-Status: No, score=2.428 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no 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 rFsUhIaU8F5D for ; Tue, 11 Nov 2014 18:19:39 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id 5A0B81A902E for ; Tue, 11 Nov 2014 18:19:38 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.7]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea5462c3b7595-e19c3; Wed, 12 Nov 2014 10:19:37 +0800 (CST) X-RM-TRANSID: 2eea5462c3b7595-e19c3 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[31.133.163.238]) by rmsmtp-syy-appsvr04-12004 (RichMail) with SMTP id 2ee45462c3b6d5c-890ee; Wed, 12 Nov 2014 10:19:37 +0800 (CST) X-RM-TRANSID: 2ee45462c3b6d5c-890ee From: "Hui Deng" To: Date: Tue, 11 Nov 2014 16:19:35 -1000 Message-ID: <005701cffe1f$1c54bb30$54fe3190$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01CFFDCB.4AA8AB30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/+Hxpi9do/EbBDSDmCeNk2Zycokw== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mif/27Drrre8APrIQN_UgyypE9Pfdtc Cc: david.sinicrope@ericsson.com Subject: [mif] BBF liason work X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 02:19:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0058_01CFFDCB.4AA8AB30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello all, =20 Our AD has posted this liaison before, so we are going to discuss it = tomorrow during f2f meeting. http://datatracker.ietf.org/liaison/1355/ if you are interested in this, feel free to read it. =20 Best regards, =20 -Hui ------=_NextPart_000_0058_01CFFDCB.4AA8AB30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello = all,

 

Our AD has posted this liaison before, so we are going to = discuss it tomorrow during f2f meeting.

http://datatracker.iet= f.org/liaison/1355/

if you are interested in this, feel free to read = it.

 

Best regards,

 

-Hui

------=_NextPart_000_0058_01CFFDCB.4AA8AB30-- From nobody Tue Nov 11 21:12:57 2014 Return-Path: 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 B7EEC1ACD8D for ; Tue, 11 Nov 2014 21:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 aAHdAB1U91me for ; Tue, 11 Nov 2014 21:12:40 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155541A8831 for ; Tue, 11 Nov 2014 21:12:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAC5CY4B031577; Wed, 12 Nov 2014 06:12:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4B149200EB5; Wed, 12 Nov 2014 06:12:52 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 33373200BEF; Wed, 12 Nov 2014 06:12:52 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.19]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAC5CD0G025712; Wed, 12 Nov 2014 06:12:33 +0100 Message-ID: <5462EC2C.400@gmail.com> Date: Wed, 12 Nov 2014 06:12:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ted Lemon , "Sri Gundavelli (sgundave)" References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> <002c01cffd58$18276ca0$487645e0$@com> <5462343B.7040705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mif/ERu4RPqJxsJACzwnRKcJuuBDKgM Cc: "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 05:12:44 -0000 Le 11/11/2014 21:14, Ted Lemon a écrit : > On Nov 11, 2014, at 9:22 AM, Sri Gundavelli (sgundave) > wrote: >> Can we split a audio flow on satellite access and DSL link and say >> its an application problem ? HEre we talk DSL and cellular (not satellite). The link characteristics are very different. >> Is it not a network design problem and should it not be avoided ? As long as an IP addressing architecture is designed to deal with it ok it is not something to be avoided. Is multihoming something to be avoided? > This is precisely why I question whether the proposed architecture > is actually the right thing. Well, I dont know which part of the architecture is under doubt, but the presentation tomorrow will clarify maybe some parts of it. Alex > > From nobody Tue Nov 11 21:33:05 2014 Return-Path: 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 9C3FD1A8961 for ; Tue, 11 Nov 2014 21:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 xk5nqISBbyGW for ; Tue, 11 Nov 2014 21:33:00 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6CB1A8749 for ; Tue, 11 Nov 2014 21:33:00 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAC5Wt0A010916; Wed, 12 Nov 2014 06:32:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 422E4200FC5; Wed, 12 Nov 2014 06:33:13 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 34371200CE8; Wed, 12 Nov 2014 06:33:13 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.19]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAC5WbJZ002135; Wed, 12 Nov 2014 06:32:54 +0100 Message-ID: <5462F0F5.1010200@gmail.com> Date: Wed, 12 Nov 2014 06:32:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> <002c01cffd58$18276ca0$487645e0$@com> <5462343B.7040705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mif/g-GjG7ZKv_XmmymsQHSrPUkx0QA Cc: "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 05:33:04 -0000 Le 11/11/2014 20:22, Sri Gundavelli (sgundave) a écrit : > > > Also, transport area may be well aware that this kind of per-packet > splitting across links happens on a routinely at intermediary routers: > two successive traceroutes rarely show same sequence. > > *Sure. Applications can deal with it, or they may suffer. Traffic load > balancing in internet has always been there. But, there is a fundamental > difference between splitting a flow between two redundant paths > connected over high-speed links in the internet core, to splitting the > same flow across two access two access-links to which a mobile node is > attached. Can we split a audio flow on satellite access and DSL link and > say its an application problem ? Is it not a network design problem and > should it not be avoided ?* > > > > Again, the MIP work with flows has nothing to do with what we try do > here. > > *Please state some technical reasons.* Where should I start? Which (P)MIP document should I talk about? (for reminder, please see our discussion in MIP4 about this a few years back) > *What we did in the past is the following.* [bitmap diagram of MR and HA skipped] That figure is good on paper, but it does not augment bandwidth by itself. It's just a way to show that both MR's connections are up at the same time. They are not used to augment bandwidth. There's only one default route that is used and it points to only one tunnel interface which in turn is bound to one single physical interface. Incoming packets may arrive on both interfaces but outgoing packets only go one interface. I guess transport area will not be happy either to know that for one single application the outgoing packets always take a different path that incoming packets - assymmetry. > *1.) Ability to allow a mobile router to perform connection management;* > * > * > *- Single Access Attach – Attach to the "best" available access network* I agree this is a feature and is highly needed for mobiles. But 'best' means 'best first L2 hop' actually. Here we talk a different thing. > *- Multi Access Attach – Attach to all available access networks* 'Attach' is one thing, 'use' is another thing. A mobile may be attached by many interfaces at the same time (ppp up, eth0 up, iwconfig up - all up) but the default route points to only one tunnel interface which in turn is linked to only one physical interface. That's where bandwidth augmentation is not present. > *2.) Ability for the mobile router to register multiple care-of address > with the anchor (MCOA Work which we did for 3 years) * Yes, but that's just registering the addresses. It doesnt tell how to augment bandwidth, how to use simultaneously several such interfaces. > *3.) Ability to request IPv4 and/or IPv6 mobile network prefixes for > the ingress network from the anchor* Yes. > *4.) Ability to establish multiple tunnel paths to the anchor to realize > multi-path overlay topology from the mobile network to the anchor; So, > to realize a bigger data pipe for the traffic associated with the mobile > network prefixes* No, that 'so' is your 'so'. There is no implementation that exhibits that bigger data pipe. > *5.) Ability to negotiate a traffic flow policy on application basis; > Most preferred access to least preferred access on application basis > and ability switch the flows based on the path availability* No, MIP has no ability to exchange such flow policy. > *6.) Ability to perform heart-beats for path management and to > re-evaluate the flow policy* Sorry - which heartbeats? There are no heartbeats in MIP. > *7.) Ability to support IPv4/IPv6 transport network, or IPv4/IPv6 mobile > networks* What do you mean by 'mobile network'? > *8.) Ability to perform NAT translation on the "transport" network* I dont know what NAT translation means. > * > * > *9.) The anchor that is here is the HA/LMA/BNG/PGW/ which is used in > Wi-Fi, LTE and Cable MSO accounts is the subscriber management function. > There is charging, policy, infrastructure that is supported and deployed > in todays networks.* Sri - I disagree. Neither PMIP nor MIP are used in these networks. I dont know why you claim so. > *Now, if I fix the MR and nail the MR to a wall, what aspects of the > above do not work ? Can the MR cannot be a CPE in home with LTE and > DOCSIS access ? **What is missing here ? Is it the per-packet load > balancing ? Is there any thing more ?* Yes. > *--> If you can summarize your answer for the above 9 points and just > state it below it will help. * Sri - you posted a feature list which is vaguely related to a list of RFCs. It is a commercial advertisement for one particular router platform. We can talk commercial advertisements if you wish, I have another such feature list ready to post. Alex > > > > > Regards > Sri > > > > On 11/11/14 8:07 AM, "Alexandru Petrescu" > wrote: > > Le 11/11/2014 10:18, Sri Gundavelli (sgundave) a écrit : > > (We have started the technical discussion, but I do want to > respond to > this) > > > Hi Hui, > > Current MIF charter prevent MIF from working on flow switch > which is > mostly mobile ip/dmm based solution, but it doesn't disallow > MIF to work > on flow split and per packet delivery. > > > > You are saying the charter disallows splitting of flows across > two access > networks, but it allows splitting of a single flow ? What is the > logic > here ? So, this requirement does not match the prior work > because the > flow policy is different ? That's the only reason why we should > look at > this as a different problem from the work that was done in the > past ? > > Per-packet load balancing is probably not explicitly stated as > transport > group was never in favor of splitting a single flow across two > access > links with different transmission properties (latency, packet > loss and > jitter) as that will result in peers requiring to deal with > re-odering/buffering issues. General recommendation was not to > split a > single flow, and so the MIP WG always kept the flow definition > at the > granularity of a flow-level and not at a packet level. > > > That was then. > > Again, the MIP work with flows has nothing to do with what we try do > here. > > When the transport are tells problems may arise with reordering it's > because the MIP WG did not reply that (1) applications may deal with > reordering and (2) the HA may deal with reordering. > > Also, transport area may be well aware that this kind of per-packet > splitting across links happens on a routinely at intermediary routers: > two successive traceroutes rarely show same sequence. > > Alex > > > But, in any case > > that's just a policy that is exchanged between two peers. > > > Regards > Sri > > > > On 11/10/14 6:34 PM, "Hui Deng" > wrote: > > Hi Sri, > > Current MIF charter prevent MIF from working on flow switch > which is > mostly mobile ip/dmm based solution, > but it doesn't disallow MIF to work on flow split and per packet > delivery. This is the key point that PS should explain the > clearly. > > -Hui > > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] > Sent: Monday, November 10, 2014 4:23 PM > To: Ted Lemon > Cc: STARK, BARBARA H; Hui Deng; mif@ietf.org > ; Brian Haberman; Jouni > Korhonen; pierrick.seite@orange.com > ; Dapeng Liu > Subject: Re: Follow up with BBF proposal > > Hi Ted, > > Having a discussion in MIF WG sounds reasonable to me. > > Regarding homenet relation, I'm not sure it belongs to that > WG either. > The focus of the homenet is on ingress networks and for > realizing > simplified configurations and that has no relation to access > selection on > egress paths. FWIW, this work is very much related to what > the MIP > working group have been doing for many years. Sure, the > device in case of > BBF is a fixed device, but the fundamental requirements are > about access > selection, flow mobility and policy exchange. The flow > mobility / MCOA > work in MIP working groups have done significant amount of > work in this > area and the expertise is in that group. > > If the reason for steering this work away from DMM is due > the belief that > we will apply only MIP-based solution, I'd say the group > will certainly > do that, but the WG may also agree to additional > solution/protocol > mechanisms. Also, IETF is in no position to pick one > protocol/solution > for this requirement. It is probably reasonable for IETF to > identify a > set of solutions and present analysis on each of the > solutions and that > can be the basis for the BBF to review and pick one or more > solutions. > But, either way I believe the expertise around this topic is > in DMM WG > and not in homenet or in MIF WG's. > > Regards > Sri > > > _______________________________________________ > 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 > From nobody Wed Nov 12 05:20:28 2014 Return-Path: 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 1B9831A89B3 for ; Wed, 12 Nov 2014 05:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 WnzJExy-_xlm for ; Wed, 12 Nov 2014 05:20:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98EA1A8999 for ; Wed, 12 Nov 2014 05:20:19 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id DC6472DC21A; Wed, 12 Nov 2014 14:20:17 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6C34035C0E0; Wed, 12 Nov 2014 14:19:59 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 14:19:59 +0100 From: To: Alexandru Petrescu , Alper Yegin , Hui Deng Thread-Topic: [mif] Follow up with BBF proposal Thread-Index: AQHP/WH+akyhQW6lOkCvA5RZIDqYuZxaulqAgAABxYCAACdiAIACDGiA Date: Wed, 12 Nov 2014 13:19:58 +0000 Message-ID: <17959_1415798417_54635E8F_17959_1_1_81C77F07008CA24F9783A98CFD706F71142CF2F6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <01FE63842C181246BBE4CF183BD159B44903A41B@nkgeml504-mbx.china.huawei.com> <9ED11710-4F49-4602-84E2-49B9E17B1FE1@yegin.org> <001a01cffd62$f38b9ff0$daa2dfd0$@com> <5461AA8E.8060007@gmail.com> In-Reply-To: <5461AA8E.8060007@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.5.145424 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/o2VA9YsShrdQVW50iC_61mzPTzY Cc: 'Brian Haberman' , "mif@ietf.org" Subject: Re: [mif] Follow up with BBF proposal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 13:20:25 -0000 SGkgQWxleCwNCg0KQWN0dWFsbHksIElNSE8sIEJCRiBhbmQgTkVNTyB1c2UtY2FzZXMgaGF2ZSBz aW1pbGFyIHJlcXVpcmVtZW50cy4gSW4g4oCcSHlicmlkIEFjY2VzcyBmb3IgQnJvYWRiYW5kIE5l dHdvcmtz4oCdIChxdW90aW5nIHRoZSBCQkYgbGlhaXNvbiksIHRoZSBDUEUgaXMgYXR0YWNoZWQg dG8gbXVsdGlwbGUgYWNjZXNzIG5ldHdvcmtzIChlLmcuIERTTCwgTFRFKTsgYW5kIHRoZSB0ZXJt aW5hbCBpcyBjb25uZWN0ZWQgdG8gdGhlIENQRSB2aWEgYSBzaW5nbGUgaW50ZXJmYWNlIChpLmUu IGluZ3Jlc3MgaW50ZXJmYWNlKSwgZS5nLiBXaS1GaSAuIFRoZSBwcm9ibGVtIGlzIHRvIGRpc3Ry aWJ1dGUgdGhlIHRyYWZmaWMgb24gdGhlIGRpZmZlcmVudCBhY2Nlc3MgbmV0d29ya3MsIGJ1dCB3 ZSBkbyBub3QgdG91Y2ggdGhlIHRlcm1pbmFsOyBhbmQgdGhlcmUgc2hvdWxkIGJlIG5vIHNwZWNp ZmljIHJlcXVpcmVtZW50IG9uIHRoZSBob21lIG5ldHdvcmsuIFRyYWZmaWMgZGlzdHJpYnV0aW9u IHNjaGVtZXMgY2FuIGJlIGRvbmUgZWl0aGVyIG9uIGEgcGFja2V0IGJhc2lzIG9yIG9uIGFuIElQ IGZsb3cgYmFzaXMsIHdoaWNoIGlzIHR5cGljYWxseSBhbiBJUCBmbG93IG1vYmlsaXR5IHVzZS1j YXNlLiBTbywgSU1VLCB0aGUgImh5YnJpZCBhY2Nlc3MiIHVzZS1jYXNlICBpcyBhIG11bHRpaG9t ZWQgbW9iaWxlIHJvdXRlciBzY2VuYXJpbywgYXMgZGVzY3JpYmVkIGluIFJGQyA0OTgwLg0KDQpB bnl3YXksIGFzIHlvdSBzYWlkLCBpdCBpcyB3b3J0aCB0byByZW1pbmQgdGhhdCBhIGxvdCBvZiB3 b3JrIGhhcyBiZWVuIGRvbmUgaW4gdGhlIHBhc3QsIHJlZ2FyZGluZyBJUCBmbG93IG1hbmFnZW1l bnQsIG9mIGNvdXJzZSwgYnV0IGV2ZW4gd2l0aCByZXNwZWN0IHRvIHRoZSBCQkYgdXNlLWNhc2U6 IFJGQyA0OTA4IChNdWx0aWhvbWluZyBmb3IgU21hbGwtU2NhbGUgRml4ZWQgTmV0d29ya3MgVXNp bmcgTW9iaWxlIElQIGFuZCBOZXR3b3JrIE1vYmlsaXR5IChORU1PKSkuDQoNCkJSLA0KUGllcnJp Y2sNCg0KPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPkRlwqA6IG1pZiBbbWFpbHRvOm1p Zi1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEFsZXhhbmRydSBQZXRyZXNjdQ0KPkVu dm95w6nCoDogbWFyZGkgMTEgbm92ZW1icmUgMjAxNCAwNzoyMA0KPsOAwqA6IEFscGVyIFllZ2lu OyBIdWkgRGVuZw0KPkNjwqA6ICdCcmlhbiBIYWJlcm1hbic7IG1pZkBpZXRmLm9yZw0KPk9iamV0 wqA6IFJlOiBbbWlmXSBGb2xsb3cgdXAgd2l0aCBCQkYgcHJvcG9zYWwNCj4NCj5MZSAxMS8xMS8y MDE0IDA0OjU5LCBBbHBlciBZZWdpbiBhIMOpY3JpdCA6DQo+PiBTdXJlLg0KPj4NCj4+IEkgd2Fz IGp1c3QgcmVhY3RpbmcgdG8gdGhlIGFzc3VtcHRpb24gdGhhdCBhbnl0aGluZyB0aGF0IG1lbnRp b25zIDINCj4+IGludGVyZmFjZXMgYXV0b21hdGljYWxseSBmYWxscyB1bmRlciB0aGUgTUlGIHNj b3BlIDotKSBBbHNvLCBiZWZvcmUNCj4+IHRoaXMgd29yayBnZXRzIG9uIGEgbG9uZyBqb3VybmV5 IHRocnUgdGhlIElFVEYgc3lzdGVtLCBwZW9wbGUgc2hvdWxkDQo+PiBiZSBhd2FyZSB0aGF0IE1v YmlsZSBJUCBXR3MgZGlkIGEgbG90IG9mIHdvcmsgZm9yIHRoaXMgc3BhY2UgYW5kIGhhdmUNCj4+ IHNvbHV0aW9ucy4NCj4NCj5TdXJlLCBidXQgaGVyZSB0aGUgcmVxcyBhcmUgZGlmZmVyZW50Lg0K Pg0KPkFjdHVhbGx5IEknZCBnbyBhcyBmYXIgYXMgdG8gc2F5IHRoYXQgTUlQIFdHIGRpZCBpbiB0 aGUgcGFzdCBhIGxvdCBvZiB3b3JrIHdpdGhvdXQNCj5yZXF1aXJlbWVudHMsIGluY2x1ZGluZyB0 aGUgZmxvdy1iYXNlZCBtYW5hZ2VtZW50IHNjaGVtZXMuDQo+DQo+QWxleA0KPg0KPg0KPj4NCj4+ IEZZSS4NCj4+DQo+PiBBbHBlcg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gT24gTm92IDEx LCAyMDE0LCBhdCA1OjUyIEFNLCBIdWkgRGVuZyB3cm90ZToNCj4+DQo+Pj4gSGkgQWxwZXIsDQo+ Pj4gVGhpcyB3b3JrIGhhc27igJl0IGJlZW4gY2xhcmlmaWVkIHdoZXJlIGl0IHNob3VsZCBiZWxv bmcgdG8sIHByZXNlbnRpbmcNCj4+PiBpbiBNSUYgZG9lc27igJl0IHByZXZlbnQgZ29pbmcgdG8g YW55IG90aGVyIHdvcmtpbmcgZ3JvdXAuDQo+Pj4gTGV04oCZcyBmb2N1cyBvbiB0aGUgcHJvYmxl bSBhbmQgZ2FwIGFuYWx5c2lzIG90aGVyIHRoYW4gd2hlcmUgaXMgdGhlDQo+Pj4gcGxhY2UgdG8g ZGlzY3VzcyBpdC4NCj4+PiBUaGFua3MNCj4+PiAtSHVpDQo+Pj4gKkZyb206Km1pZiBbbWFpbHRv Om1pZi1ib3VuY2VzQGlldGYub3JnXSpPbiBCZWhhbGYgT2YqQWxwZXIgWWVnaW4NCj4+PiAqU2Vu dDoqTW9uZGF5LCBOb3ZlbWJlciAxMCwgMjAxNCA1OjQ2IFBNICpUbzoqWHVlbGkgKkNjOipCcmlh bg0KPj4+IEhhYmVybWFuOyBtaWZAaWV0Zi5vcmcgPG1haWx0bzptaWZAaWV0Zi5vcmc+DQo+Pj4g KlN1YmplY3Q6KlJlOiBbbWlmXSBGb2xsb3cgdXAgd2l0aCBCQkYgcHJvcG9zYWwgSGkgWHVlbGks IFRoYXQncyBvbmUNCj4+PiBvZiB0aGUgZ2VuZXJhbCBzdGF0ZW1lbnRzIGluIHRoZSBjaGFydGVy LiBBbmQgaXQgY292ZXJzIHNvIG1hbnkNCj4+PiBhcmVhcywgb2J2aW91c2x5IE1JRiBpcyBub3Qg Y2hhcnRlcmVkIHRvIGRlYWwgd2l0aC4NCj4+PiBGb3IgZXhhbXBsZSwgZGlzY292ZXJ5IG9mIG5l dHdvcmtzLCBzZWxlY3Rpb24gb2YgbmV0d29ya3MsDQo+Pj4gYXV0aGVudGljYXRpb24sIGFjY291 bnRpbmcsIGhvc3QgY29uZmlndXJhdGlvbiwgdHJhZmZpYyBtYW5hZ2VtZW50LA0KPj4+IG1vYmls aXR5LCBldGMuIGV0Yy4NCj4+PiBUaGUgc3RhdGVtZW50cyBJIHB1bGxlZCBmb3JtIHRoZSBjaGFy dGVyIHBpbi1wb2ludHMgdGhlIGV4YWN0IHNjb3BlDQo+Pj4gb2YgTUlGLiBBbnl0aGluZyBlbHNl IGlzIG91dHNpZGUgdGhlIHNjb3BlLCBjdXJyZW50bHkuDQo+Pj4gQWxwZXINCj4+PiBPbiBOb3Yg MTEsIDIwMTQsIGF0IDU6MjAgQU0sIFh1ZWxpIHdyb3RlOg0KPj4+DQo+Pj4NCj4+PiBIZWxsbw0K Pj4+IFRoZSBNSUYgY2hhcnRlciBzYXlzIGxpa2U6DQo+Pj4gKi8iLyoqL1RoZSBwdXJwb3NlIG9m IHRoZSBNSUYgd29ya2luZyBncm91cCBpcyB0byBkZXNjcmliZSB0aGUNCj4+PiBhcmNoaXRlY3R1 cmUgZGV0YWlsaW5nIGhvdyBkZXZpY2VzIGF0dGFjaCB0byBhbmQgb3BlcmF0ZSBpbiBtdWx0aXBs ZQ0KPj4+IG5ldHdvcmtzLiINCj4+PiAvKkkgdGhpbmsgbXkgcHJlc2VudGF0aW9uIGNsZWFubHkg Zml0cyB0aGlzIHN0YXRlbWVudC4uLg0KPj4+IEJlc3QgUmVnYXJkcw0KPj4+IFhVRUxJDQo+Pj4g KuWPkeS7tuS6ujoqbWlmIFttYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmddKuS7o+ihqCpBbHBl ciBZZWdpbg0KPj4+ICrlj5HpgIHml7bpl7Q6KjIwMTTlubQxMeaciDEx5pelMTA6NDUNCj4+PiAq 5pS25Lu25Lq6OipTcmkgR3VuZGF2ZWxsaQ0KPj4+ICrmioTpgIE6KkJyaWFuIEhhYmVybWFuO21p ZkBpZXRmLm9yZyA8bWFpbHRvOm1pZkBpZXRmLm9yZz4NCj4+PiAq5Li76aKYOipSZTogW21pZl0g Rm9sbG93IHVwIHdpdGggQkJGIHByb3Bvc2FsIE1JRiBmb2N1c2VzIG9uIHRoZQ0KPj4+IGZvbGxv d2luZyBpc3N1ZXMsIGFuZCB0aGUgaXNzdWUgQkJGIGlzIGJyaW5naW5nIHVwIGlzIGEgdG90YWxs eQ0KPj4+IHNlcGFyYXRlIGlzc3VlLg0KPj4+IEl0J3MgYWJvdXQgaG93IHR3byBsaW5rcyBjYW4g YmUgYWdncmVnYXRlZCBmb3IgY2FwYWNpdHkgYW5kDQo+Pj4gcmVsaWFiaWxpdHkgYm9vc3QuDQo+ Pj4gU28sIEkgYWdyZWUgd2l0aCBTcmkgdGhhdCB0aGlzIGlzIG5vdCBhIE1JRiBXRyBpc3N1ZS4N Cj4+PiBUaGUgTUlGIHByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50IFtSRkM2NDE4DQo+Pj4gPGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NDE4Pl0gZW51bWVyYXRlcyB0aGUgcHJvYmxl bXMgaW50byAzDQo+Pj4gY2F0ZWdvcmllczoNCj4+PiAgIDEuIExhY2sgb2YgY29uc2lzdGVudCBh bmQgZGlzdGluY3RpdmUgbWFuYWdlbWVudCBvZiBjb25maWd1cmF0aW9uDQo+Pj4gZWxlbWVudHMs IGFzc29jaWF0ZWQgd2l0aCBkaWZmZXJlbnQgbmV0d29ya3MuDQo+Pj4gICAyLiBJbmFwcHJvcHJp YXRlIG1peGVkIHVzZSBvZiBjb25maWd1cmF0aW9uIGVsZW1lbnRzLCBhc3NvY2lhdGVkDQo+Pj4g d2l0aCBkaWZmZXJlbnQgbmV0d29ya3MsIGluIHRoZSBjb3Vyc2Ugb2YgYSBwYXJ0aWN1bGFyIG5l dHdvcmsNCj4+PiBhY3Rpdml0eSAvIGNvbm5lY3Rpb24uDQo+Pj4gICAzLiBVc2Ugb2YgYSBwYXJ0 aWN1bGFyIG5ldHdvcmssIG5vdCBjb25zaXN0ZW50IHdpdGggdGhlIGludGVudCBvZg0KPj4+IHRo ZSBzY2VuYXJpbyAvIGludm9sdmVkIHBhcnRpZXMsIGxlYWRpbmcgdG8gY29ubmVjdGl2aXR5IGZh aWx1cmUgYW5kDQo+Pj4gLyBvciBvdGhlciB1bmRlc2lyZWQgY29uc2VxdWVuY2VzLg0KPj4+IEFs cGVyDQo+Pj4gT24gTm92IDExLCAyMDE0LCBhdCAzOjA4IEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1 bmRhdmUpIHdyb3RlOg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IEhpIEh1aSwNCj4+PiBUaGUgQkJGIHJl cXVpcmVtZW50IGFzIHByZXNlbnRlZCBpbiB0aGUgQkJGIGRvY3VtZW50cyBhbmQgYXMNCj4+PiBp bnRlcnByZXRlZCBpbiBkcmFmdC1zZWl0ZSBhbmQgZHJhZnQtbGh3eHogaXMgYWJvdXQgZW5hYmxp bmcgYSBDUEUNCj4+PiBkZXZpY2UgdG8gYXR0YWNoIHRvIG11bHRpcGxlIGFjY2VzcyBuZXR3b3Jr IGFuZCBwZXJmb3JtIGZsb3cNCj4+PiBtYW5hZ2VtZW50LiBIb3dldmVyLCBJIGxvb2sgYXQgaXQs IEkgc2VlIHRoaXMgdGhpcyBpcyBhIG1vYmlsaXR5DQo+Pj4gcmVxdWlyZW1lbnQgYW5kIGlzIHJl YWxseSBub3QgaW4gdGhlIHNjb3BlIG9mIE1JRiBXRy4gVGhlIEJCRg0KPj4+IHJlcXVpcmVtZW50 IGluIHF1ZXN0aW9uIGlzIGFsbCBhYm91dCBmbG93IHN3aXRjaGluZyBvciBmbG93IHNwbGl0dGlu Zw0KPj4+IGFjcm9zcyBhY2Nlc3Mgc3lzdGVtcy4gSSdtIG5vdCBzdXJlIHdoeSB0aGlzIHdvcmsg YmVsb25ncyBNSUYgYW5kIG5vdA0KPj4+IERNTSB3aGljaCBpcyBjaGFydGVyZWQgdG8gaGFuZGxl IGFsbCBtb2JpbGl0eSB1c2UtY2FzZXMuIFdlIGhhdmUNCj4+PiBkaXNjdXNzZWQgdGhpcyBzcGVj aWZpYyB1c2UtY2FzZSBvZiBmbG93IHNwbGl0dGluZyBkdXJpbmcgTUlGDQo+Pj4gZm9ybWF0aW9u IGFuZCBleHBsaWNpdGx5IGRpc2FsbG93ZWQgTUlGIFdHIGZyb20gdGFraW5nIHVwIHN1Y2ggd29y ay4NCj4+PiBUaGUgZm9sbG93aW5nIGlzIHRoZSBxdW90ZSBmcm9tIHRoZSBNSUYgY2hhcnRlcmVk IHRleHQuIEFsc28sIHRoZSBNSUYNCj4+PiBXRyB3YXMgcHJpbWFyaWx5IGxvb2tpbmcgYXQgaXNz dWVzIGZvciBhIGhvc3QgYXR0YWNoZWQgdG8gbXVsdGlwbGUNCj4+PiBhY2Nlc3MgbmV0d29ya3Ms IGJ1dCB0aGUgaHlicmlkIGFjY2VzcyBpcyBhYm91dCBhIENQRSBhdHRhY2hlZCB0bw0KPj4+IG11 bHRpcGxlIG5ldHdvcmtzLiBJIHJlYWxseSB0aGluayB0aGlzIHdvcmsgc2hvdWxkIGJlIGRvbmUg aW4gRE1NIGFuZA0KPj4+IHdlIGRpZCBwcmVzZW50IHRoZSByZXF1aXJlbWVudHMgaW4gdGhlIGxh c3QgSUVURiBtZWV0aW5nLg0KPj4+ICpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvbWlm L2NoYXJ0ZXIvKg0KPj4+ICpObyB3b3JrIHdpbGwgYmUgZG9uZSB0byBlbmFibGUgdHJhZmZpYyBm bG93cyB0byBtb3ZlIGZyb20gb25lDQo+Pj4gaW50ZXJmYWNlIHRvIGFub3RoZXIuIFRoZSBncm91 cCByZWNvZ25pemVzIGV4aXN0aW5nIHdvcmsgb24NCj4+PiBtZWNoYW5pc21zIHRoYXQgcmVxdWly ZSBwZWVyIG9yIG5ldHdvcmsgc3VwcG9ydCBmb3IgbW92aW5nIHRyYWZmaWMNCj4+PiBmbG93cyBz dWNoIGFzIFJGQyA1MjA2LCBSRkMgNDk4MCBhbmQgdGhlIHVzZSBvZiBtdWx0aXBsZSBjYXJlLW9m DQo+Pj4gYWRkcmVzc2VzIGluIE1vYmlsZSBJUHY2LiBUaGlzIGdyb3VwIGRvZXMgbm90IHdvcmsg b24gb3IgaW1wYWN0IHN1Y2gNCj4+PiBtZWNoYW5pc21zLiBGdXR1cmUgd29yayBpbiB0aGlzIGFy ZWEgcmVxdWlyZXMgcmVjaGFydGVyaW5nIHRoZQ0KPj4+IHdvcmtpbmcgZ3JvdXAgb3IgYXNraW5n IG90aGVyLCBzcGVjaWFsaXplZCB3b3JraW5nIGdyb3VwcyAoc3VjaCBhcw0KPj4+IERIQyBvciA2 TUFOKSB0byBkZWFsIHdpdGggc3BlY2lmaWMgaXNzdWVzLiogUmVnYXJkcyBTcmkgKkZyb206Kkh1 aQ0KPj4+IERlbmcgPGRlbmdodWlAY2hpbmFtb2JpbGUuY29tIDxtYWlsdG86ZGVuZ2h1aUBjaGlu YW1vYmlsZS5jb20+Pg0KPj4+ICpEYXRlOipGcmlkYXksIE9jdG9iZXIgMzEsIDIwMTQgNDo1MCBB TSAqVG86KlNyaSBHdW5kYXZlbGxpDQo+Pj4gPHNndW5kYXZlQGNpc2NvLmNvbSA8bWFpbHRvOnNn dW5kYXZlQGNpc2NvLmNvbT4+LCAnWHVlbGknDQo+Pj4gPHh1ZWxpQGh1YXdlaS5jb20gPG1haWx0 bzp4dWVsaUBodWF3ZWkuY29tPj4sDQo+Pj4gInBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20gPG1h aWx0bzpwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPiINCj4+PiA8cGllcnJpY2suc2VpdGVAb3Jh bmdlLmNvbSA8bWFpbHRvOnBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20+PiwgJ1RlZA0KPj4+IExl bW9uJyA8VGVkLkxlbW9uQG5vbWludW0uY29tDQo+PG1haWx0bzpUZWQuTGVtb25Abm9taW51bS5j b20+PiwNCj4+PiAiJ1NUQVJLLCBCQVJCQVJBIEgnIiA8YnM3NjUyQGF0dC5jb20gPG1haWx0bzpi czc2NTJAYXR0LmNvbT4+LA0KPj4+ICdBbGV4YW5kcnUgUGV0cmVzY3UnIDxhbGV4YW5kcnUucGV0 cmVzY3VAZ21haWwuY29tDQo+Pj4gPG1haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29t Pj4NCj4+PiAqQ2M6KiJtaWZAaWV0Zi5vcmcgPG1haWx0bzptaWZAaWV0Zi5vcmc+IiA8bWlmQGll dGYub3JnDQo+Pj4gPG1haWx0bzptaWZAaWV0Zi5vcmc+PiAqU3ViamVjdDoqRm9sbG93IHVwIHdp dGggQkJGIHByb3Bvc2FsIEhpDQo+Pj4gZXZlcnlib2R5IEkgYW0gcmVjb21tZW5kaW5nIHRoYXQg WHVlIExpIGNvdWxkIGhlbHAgdG8gcHV0IGRvd24gdGhlDQo+Pj4gc2xpZGUgZm9yIHRoZSBwcm9i bGVtIHN0YXRlbWVudCBmcm9tIEJCRi4NCj4+PiBBbmQgTUlQL05FTU8gcHJvcG9uZW50cyAoUGll cnJpY2ssIEFsZXgsIFNyaSkgYW5kIFh1ZSBMaSBjb3VsZCBraW5kbHkNCj4+PiB0byBtZWV0IHRv Z2V0aGVyIGR1cmluZyBJRVRGIG1lZXRpbmcgdG8gZGlzY3VzcyBieSBhZGRpbmcgcyB0aGVsaWRl DQo+Pj4gYWJvdXQgaG93IHRvZGF5IHNvbHV0aW9ucyBtZWV0IHRoZSByZXF1aXJlbWVudCBvciB0 aGVyZSBhcmUgc29tZSBnYXANCj4+PiBzdGlsbCwgYW5kIHdoZXRoZXIgdGhhdCBwcm9ibGVtIHNo b3VsZCBiZSBzb2x2YWJsZSBpbiBJRVRGLg0KPj4+IENoYWlycyB3aWxsIHRhbGsgd2l0aCBBRCB3 aGV0aGVyIE1JRiBvciBzb21ld2hlcmUgZWxzZSB3aWxsIGNvbnNpZGVyDQo+Pj4gdG8gZGlzY3Vz cyB0aG9zZSBpc3N1ZXMgZHVyaW5nIHRoZSBmMmYgc2Vzc2lvbi4NCj4+PiBCZXN0IHJlZ2FyZHMs DQo+Pj4gLUh1aQ0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4gbWlmIG1haWxpbmcgbGlzdA0KPj4+IG1pZkBpZXRmLm9yZyA8bWFpbHRvOm1p ZkBpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21p Zg0KPj4+DQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gbWlmIG1haWxpbmcgbGlzdA0KPj4gbWlmQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZg0KPj4NCj4NCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm1pZiBtYWlsaW5n IGxpc3QNCj5taWZAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21pZg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Nov 12 09:27:10 2014 Return-Path: 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 9A6F21A8F3D for ; Wed, 12 Nov 2014 09:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 hJ6TnBAqU2hs for ; Wed, 12 Nov 2014 09:26:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804CC1A8F3C for ; Wed, 12 Nov 2014 09:26:14 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id AC1A22AC6C7; Wed, 12 Nov 2014 18:26:12 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 83798C80A7; Wed, 12 Nov 2014 18:26:12 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 18:26:12 +0100 From: To: "sarikaya@ieee.org" , Margaret Wasserman Thread-Topic: [mif] Hybrid Access Problem Thread-Index: AQHP/WU8NajwoT6MckSiciaeuEgsY5xcA+QAgAEqZMA= Date: Wed, 12 Nov 2014 17:26:11 +0000 Message-ID: <25452_1415813172_54639834_25452_15270_1_81C77F07008CA24F9783A98CFD706F71142CF5DF@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.12.65124 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/nmqRT3klZsA3Wfbh-2pDrAEY0pU Cc: "mif@ietf.org List" Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:27:02 -0000 Hi, >-----Message d'origine----- >De=A0: mif [mailto:mif-bounces@ietf.org] De la part de Behcet Sarikaya >Envoy=E9=A0: mercredi 12 novembre 2014 00:32 >=C0=A0: Margaret Wasserman >Cc=A0: mif@ietf.org List >Objet=A0: Re: [mif] Hybrid Access Problem > >On Mon, Nov 10, 2014 at 10:08 PM, Margaret Wasserman > wrote: >> >> >> Let me see if I can start a technical discussion here... >> >> If you have an ISP today=20 "today" is the keyword here. I'll try to clarify what we can do, today, to = meet the BBF requirement on "hybrid access" that has two different access networks >> available, such as one 3GPP network and one DSL network, how do(es) >> the gateway box(es) (connected to both networks) decide where it >> should send each packet it receives? I think there are several >> possible cases here; >> >> (1) There is one gateway=20 Ok, let's talk about CPE here to avoid confusion with a traffic anchoring g= ateway (e.g. P-GW, Broadband Network Gateway (BNG), or even, "aggregation g= ateway", which is sometimes used in some hybrid access architecture) attached to both outbound networks. This has >> two >> sub-cases: >> >> (1.1) Hosts behind the single gateway have separate addresses on the >> two attached networks. In that case, the gateway is constrained to >> send packets over the outgoing network that uses the address prefix >> that matches the source address, or the packets will be thrown away by >> ingress filters on the other side. So, the network choice is made by the >hosts. >> > >This case is not valid because both attached networks belong to the same >operator. Also the hosts do not get separate addresses from the attached >networks, I think. > Actually, this is a valid use-case. The point is not to know if access netw= orks are operated but how the addresses, on the egress interface of the CPE= , are allocated. Sri has well explained this on a previous email. Taking th= e example of 4G cellular and DSL egress interfaces, the CPE obtains address= es/prefix on both the cellular and the DSL accesses, respectively topically= anchored at the PGW and the BNG. Then these prefixes are delegated to the = host, possibly with prefix coloring information. Then, the host can select the source IP address according the network selec= ted (e.g depending on the application, the host may select a specific egres= s interface). This behavior should rely on advanced source address selectio= n mechanisms, that are not available today (AFAIK). So, today, most hybrid = access implementations are going for the approach described in 1.2.1 case. >> (1.2) Hosts behind the gateway have only one address each. This has >> two >> sub-cases: >> >> (1.2.1) The gateway has separate addresses on the two networks, and >> does some sort of translation from internal to external addresses in >> the prefix of the "right" outgoing link. >> > Exactly, this is what we have today with IPv4; NPTv6 would allow same behav= ior on IPv6 network >Yes, I think this is the case. > >> (1.2.2) The gateway has only one IP address that is somehow shared >> across the two links. >> Exactly. This scenario has been discussed in 3GPP, relying on PMIP (RFC5213= ) to share a same IP address, or prefix, across more the egress interfaces = of the CPE. >> (2) There are two gateways, each attached to a single outbound >> network. In this case, hosts will always have separate addresses for >> the two networks, and will need to make a decision about which outbound >network to use. >> This is a valid use-case, but it does not meet the BBF requirement. Only CP= E with more than one outbound interfaces (e.g. LTE, DSL) is in the scope of= the BBF liaison, i.e. only case 1). >> Cases 1.1 and 2 are essentially the same from a host standpoint, in >> that the host needs to make a network choice.=20=20 Exactly. Basically we have two scenarios regarding traffic steering decisio= n: it is either the host or the CPE which makes the decision to forward the= traffic on the most appropriate egress interface. Today, BBF puts the deci= sion making process on the CPE. This is a problem we >> have discussed in MIF -- What sort of information does/should the host >> need to make that choice, and how is that information communicated to the >host? >> >> Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for >> multi-homing. The IETF generally prefers to avoid recommending >> solutions that use NAT, but do we have a better answer? >> > This is what it is implemented with IPv4, and, today, we do not have better= answer for IPv6. >This could be the case. > >I want to also say here that CPE here is not a mobile router. >There might be mobile routers that are connected to two networks but not in >this case, I think. > I'm not sure to understand this. Multihomed CPE is a router with more than = one egress interfaces and the problem is to distribute the traffic over the= se interfaces; this is one of the scenarios that NEMO protocol can address.= .. >Regards, > >Behcet >> Case 1.2.2 becomes a layer 2 problem and is probably outside the scope >> of the IETF. >> Actually, case 1.2.2 is not necessarily a L2 problem, this is typically a P= MIP uses-case where a host (here a CPE) obtains the same IP address/prefix = while connecting to different access networks Pierrick >> Are there cases that I am missing here? >> >> Margaret >> >> >> >> >> >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Wed Nov 12 11:24:55 2014 Return-Path: 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 22AF01ACF6E for ; Wed, 12 Nov 2014 11:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 BtuCXT4K51m5 for ; Wed, 12 Nov 2014 11:24:47 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4D71ACF66 for ; Wed, 12 Nov 2014 11:24:45 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id a41so1409086yho.26 for ; Wed, 12 Nov 2014 11:24:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=3HQaINFS30eCxfvtb3Sfg7axO3POspROq5Xn0KGPFXE=; b=raZg+S80d2H+yZrOlFu7fIp9Mi8QoRGd/eaFL39NK5f/JuNTkIfjgIdx6Z/LCzdpxT t9CenU43uz9itA6Orchlheqzh3+OfXpXsI61fQeF75vIiPc196Av8vrT/WltfoQ+g/p3 6zpccHURVmvbAWeZJYRbMDmYZNzAsCgdi/t/QQV+ty/gKvZ/amr48bQ8XWuyLjD2uMr5 T5L+IK0az+sVuKW/zbSInTapt95xGRSbAZGGDPjRrM9160fGmLUj+HYHmy4oSrikitZJ IXcogyU4imwiFdKRJ7AaYDSSQUl7AKvpOhqxoAEa69opJ7kOJSWcQu15wrNTrDptVz2Z IPwA== MIME-Version: 1.0 X-Received: by 10.170.116.17 with SMTP id i17mr16215242ykb.52.1415820284793; Wed, 12 Nov 2014 11:24:44 -0800 (PST) Received: by 10.170.71.198 with HTTP; Wed, 12 Nov 2014 11:24:44 -0800 (PST) In-Reply-To: <25452_1415813172_54639834_25452_15270_1_81C77F07008CA24F9783A98CFD706F71142CF5DF@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <005401cff509$3719eb30$a54dc190$@com> <1BC71728-94D7-48A3-B01D-0645DF8314F3@yegin.org> <8C1BB9C8-4F4E-4316-8ADA-8F8633EC40E9@gmail.com> <25452_1415813172_54639834_25452_15270_1_81C77F07008CA24F9783A98CFD706F71142CF5DF@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Wed, 12 Nov 2014 13:24:44 -0600 Message-ID: From: Behcet Sarikaya To: Pierrick Seite Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mif/ZJ_RUEhr0nbxl-gL5HQx_op5g7U Cc: "mif@ietf.org List" Subject: Re: [mif] Hybrid Access Problem X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:24:49 -0000 On Wed, Nov 12, 2014 at 11:26 AM, wrote: > Hi, > >>-----Message d'origine----- >>De : mif [mailto:mif-bounces@ietf.org] De la part de Behcet Sarikaya >>Envoy=C3=A9 : mercredi 12 novembre 2014 00:32 >>=C3=80 : Margaret Wasserman >>Cc : mif@ietf.org List >>Objet : Re: [mif] Hybrid Access Problem >> >>On Mon, Nov 10, 2014 at 10:08 PM, Margaret Wasserman >> wrote: >>> >>> >>> Let me see if I can start a technical discussion here... >>> >>> If you have an ISP today > > "today" is the keyword here. I'll try to clarify what we can do, today, t= o meet the BBF requirement on "hybrid access" > > that has two different access networks >>> available, such as one 3GPP network and one DSL network, how do(es) >>> the gateway box(es) (connected to both networks) decide where it >>> should send each packet it receives? I think there are several >>> possible cases here; >>> >>> (1) There is one gateway > > Ok, let's talk about CPE here to avoid confusion with a traffic anchoring= gateway (e.g. P-GW, Broadband Network Gateway (BNG), or even, "aggregation= gateway", which is sometimes used in some hybrid access architecture) > > attached to both outbound networks. This has >>> two >>> sub-cases: >>> >>> (1.1) Hosts behind the single gateway have separate addresses on the >>> two attached networks. In that case, the gateway is constrained to >>> send packets over the outgoing network that uses the address prefix >>> that matches the source address, or the packets will be thrown away by >>> ingress filters on the other side. So, the network choice is made by t= he >>hosts. >>> >> >>This case is not valid because both attached networks belong to the same >>operator. Also the hosts do not get separate addresses from the attached >>networks, I think. >> > > Actually, this is a valid use-case. The point is not to know if access ne= tworks are operated but how the addresses, on the egress interface of the C= PE, are allocated. Sri has well explained this on a previous email. Taking = the example of 4G cellular and DSL egress interfaces, the CPE obtains addre= sses/prefix on both the cellular and the DSL accesses, respectively topical= ly anchored at the PGW and the BNG. Then these prefixes are delegated to th= e host, possibly with prefix coloring information. > Then, the host can select the source IP address according the network sel= ected (e.g depending on the application, the host may select a specific egr= ess interface). This behavior should rely on advanced source address select= ion mechanisms, that are not available today (AFAIK). So, today, most hybri= d access implementations are going for the approach described in 1.2.1 case= . > [behcet] eNodeB sees CPE as a UE. For CPE, the address/prefix it gets is just another interface for the WAN side. I don't agree with the delegation part. If that were the case, you mean that the host must be SHIM-aware? >>> (1.2) Hosts behind the gateway have only one address each. This has >>> two >>> sub-cases: >>> >>> (1.2.1) The gateway has separate addresses on the two networks, and >>> does some sort of translation from internal to external addresses in >>> the prefix of the "right" outgoing link. >>> >> > > Exactly, this is what we have today with IPv4; NPTv6 would allow same beh= avior on IPv6 network > >>Yes, I think this is the case. >> >>> (1.2.2) The gateway has only one IP address that is somehow shared >>> across the two links. >>> > > Exactly. This scenario has been discussed in 3GPP, relying on PMIP (RFC52= 13) to share a same IP address, or prefix, across more the egress interface= s of the CPE. > [behcet] Where is 3GPP? To my knowledge BBF hybrid access has not yet reached 3GPP. >>> (2) There are two gateways, each attached to a single outbound >>> network. In this case, hosts will always have separate addresses for >>> the two networks, and will need to make a decision about which outbound >>network to use. >>> > > This is a valid use-case, but it does not meet the BBF requirement. Only = CPE with more than one outbound interfaces (e.g. LTE, DSL) is in the scope = of the BBF liaison, i.e. only case 1). > >>> Cases 1.1 and 2 are essentially the same from a host standpoint, in >>> that the host needs to make a network choice. > > Exactly. Basically we have two scenarios regarding traffic steering decis= ion: it is either the host or the CPE which makes the decision to forward t= he traffic on the most appropriate egress interface. Today, BBF puts the de= cision making process on the CPE. > > This is a problem we >>> have discussed in MIF -- What sort of information does/should the host >>> need to make that choice, and how is that information communicated to t= he >>host? >>> >>> Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for >>> multi-homing. The IETF generally prefers to avoid recommending >>> solutions that use NAT, but do we have a better answer? >>> >> > > This is what it is implemented with IPv4, and, today, we do not have bett= er answer for IPv6. > >>This could be the case. >> >>I want to also say here that CPE here is not a mobile router. >>There might be mobile routers that are connected to two networks but not = in >>this case, I think. >> > > I'm not sure to understand this. Multihomed CPE is a router with more tha= n one egress interfaces and the problem is to distribute the traffic over t= hese interfaces; this is one of the scenarios that NEMO protocol can addres= s... > [behcet] Well, this reminds me the hammer and nail story. Sorry no offence to anyone. Regards, Behcet >>Regards, >> >>Behcet >>> Case 1.2.2 becomes a layer 2 problem and is probably outside the scope >>> of the IETF. >>> > > Actually, case 1.2.2 is not necessarily a L2 problem, this is typically a= PMIP uses-case where a host (here a CPE) obtains the same IP address/prefi= x while connecting to different access networks > > Pierrick > >>> Are there cases that I am missing here? >>> >>> Margaret >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > From nobody Wed Nov 12 22:57:37 2014 Return-Path: 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 6452E1A1BDD for ; Wed, 12 Nov 2014 22:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 vnPw2KOia7W0 for ; Wed, 12 Nov 2014 22:57:34 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6619A1A1BCF for ; Wed, 12 Nov 2014 22:57:34 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq12so3997241vcb.9 for ; Wed, 12 Nov 2014 22:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vJKT6msuzeWkV6BHltmotDsRjD8keV3GEejf8w0TQoE=; b=bmnn2vgrmmqweXWy34DEIRqEdxJsX7owh6AKvnpFyKJKRRZQB7UG1cs88IcUsK0t+l 4e7JPp7xm+GIPjvpBRIlo3eMqOHwqILrKM7vZQeBKyb76PHgWgtUENbdvmXILZ6pgwv8 9DeLlo0122zbshfR4WLfPxPpfE1Iw2vDBzqLmc2TjwJVW2E0cV6suVdq4IWrUEH8RIdB 28ufIfC09Tv0/2g1YQ2ZReAnIVdKLW0bn2aKiTmdwMYFwmGnqgJsPvBA8pPoCffLBzE8 gVxTdGvf5w+mgD4PdCDSr0e5UO7s3c0EYjC/UHDauNzZWNLx5XvNbHmnU0n4jjQCGd/k LYqA== MIME-Version: 1.0 X-Received: by 10.52.246.132 with SMTP id xw4mr318993vdc.20.1415861853623; Wed, 12 Nov 2014 22:57:33 -0800 (PST) Received: by 10.220.140.74 with HTTP; Wed, 12 Nov 2014 22:57:33 -0800 (PST) Date: Wed, 12 Nov 2014 20:57:33 -1000 Message-ID: From: Hui Deng To: MIF Mailing List , "mif-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a1133e616d61bc70507b806e1 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/AwSW5GPMirpiIeXqQ0aNgerEfhU Subject: [mif] BBF Interests X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 06:57:35 -0000 --001a1133e616d61bc70507b806e1 Content-Type: text/plain; charset=UTF-8 Hello all, Just a remindness that the chairs call for interest volunteer for BBF, thanks a lot -Hui --001a1133e616d61bc70507b806e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,
=C2=A0
Just a remindne= ss that the chairs call for interest volunteer for BBF,
thanks a= lot
=C2=A0
-Hui
--001a1133e616d61bc70507b806e1--