From m.spini@huawei.com Thu Aug 1 01:08:54 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12CD21F9BB6 for ; Thu, 1 Aug 2013 01:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+JsGWHFWETO for ; Thu, 1 Aug 2013 01:08:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9A621F9CA9 for ; Thu, 1 Aug 2013 01:08:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ49213; Thu, 01 Aug 2013 08:08:46 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 09:07:43 +0100 Received: from LHREML514-MBX.china.huawei.com ([10.201.4.201]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 09:07:54 +0100 From: Marco Spini To: "fmc@ietf.org" Thread-Topic: [fmc] Minutes of today's Bar BoF Thread-Index: AQHOjeNXUms+TGFEBUexB4rdqrJmYpl//NNg Date: Thu, 1 Aug 2013 08:07:53 +0000 Message-ID: <7E052B31D0F9724D8EEF82B41F410F6E2ED9396E@lhreml514-mbx> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.34.55] Content-Type: multipart/alternative; boundary="_000_7E052B31D0F9724D8EEF82B41F410F6E2ED9396Elhreml514mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [fmc] Minutes of today's Bar BoF X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:08:55 -0000 --_000_7E052B31D0F9724D8EEF82B41F410F6E2ED9396Elhreml514mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, >From the reading of the minutes I would add few clarifications to Sri's com= ment on EPC routed traffic. The IPv4 NAT and IPv6 prefix is a problem in c= ase of Non-seamless WLAN offloaded traffic, since this traffic does not rea= ch the 3GPP EPC , so the devices either fixed or mobile share the same IPv= 6 prefix. In case of EPC-routed, the traffic for s2b and s2c is tunneled, h= ence the UE can have a different IPv6prefixex or IPv4 Addresses, one known = to the PDN GW (the inner one) and consequently to the PCRF. However the loc= al address, if it is not know in PCEF, i.e. to the BNG, the PCEF will face = some binding problem, but this scenario can be solved using both local addr= ess and address assigned by PDG. The s2a scenario is a bit more complex dep= ending by rel-11 or rel-12 solution, so for time being I left out of discus= sion. Best Regard Marco Spini From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of Behce= t Sarikaya Sent: mercoled=EC 31 luglio 2013 13:44 To: fmc@ietf.org Cc: joel jaeggli; Dirk.von-Hugo@telekom.de Subject: [fmc] Minutes of today's Bar BoF Dear all, We had a very productive meeting today which was attended by 16 or so peopl= e. Please find attached the minutes. Our special thanks to Pete McCann for taking the notes in such an amazing d= etail. Regards, Dirk & Behcet --_000_7E052B31D0F9724D8EEF82B41F410F6E2ED9396Elhreml514mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 <= /p>

From the reading of the m= inutes I would add few clarifications to Sri’s comment on EPC routed = traffic.  The IPv4 NAT and IPv6 prefix is a problem in case of Non-seamless WLAN offloaded traffic, since this traffic does not reach the= 3GPP EPC , so the devices either fixed or mobile share the same  IPv6= prefix. In case of EPC-routed, the traffic for s2b and s2c is tunneled, he= nce the UE can have a different IPv6prefixex or IPv4 Addresses, one known to the PDN GW (the inner one) and consequentl= y to the PCRF. However the local address, if it is not know in PCEF, i.e. t= o the BNG, the PCEF will face some binding problem, but this scenario can b= e solved using both local address and address assigned by PDG. The s2a scenario is a bit more complex depend= ing by rel-11 or rel-12 solution, so for time being I left out of discussio= n.  

 <= /p>

Best Regard

Marco Spini

 <= /p>

 <= /p>

From: fmc-boun= ces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: mercoled=EC 31 luglio 2013 13:44
To: fmc@ietf.org
Cc: joel jaeggli; Dirk.von-Hugo@telekom.de
Subject: [fmc] Minutes of today's Bar BoF

 

Dear all,<= /p>

We had a very productive meeting today which was att= ended by 16 or so people.

Please find attached the minutes.

Our special thanks to= Pete McCann for taking the notes in such an amazing detail.

Regards,

Dirk & Behcet

--_000_7E052B31D0F9724D8EEF82B41F410F6E2ED9396Elhreml514mbx_-- From sarikaya2012@gmail.com Fri Aug 2 03:46:54 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A331D11E81B0 for ; Fri, 2 Aug 2013 03:46:54 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3maHzsjBdhg for ; Fri, 2 Aug 2013 03:46:53 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id DB6AD11E8251 for ; Fri, 2 Aug 2013 03:46:49 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id w10so328882lbi.21 for ; Fri, 02 Aug 2013 03:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=HBtDaxk736ObALfgTanBUvQWdxvNTS7mzG23X4YNtmg=; b=hTw0KzY8Fj6RA31NVKJVpRDo/Q/UO1TO8Wg+Jp0jvIpNGfaSC2wz8z1FMFn26MKD4o V6RpiSgimQ/xqJw9HnYFZb3v4bbbolwaO/+Kl4H9chVIcI63aQsKX7YjmJJybUfqmgNO Fc02hQ/8pDhRV89x5WaNzKRIWXqjeLmbEXm8LBCaPZZATmxA7GaIm4fkfq8G7Od1JC0I o+e0pF8qEdkaMip3ECOTiBkHPmimSc10r/0R9yvKBiyAt3TGpS5nvLe6oaab9CDN2fgX peFNPiIHTZDUKcscgHC1BepH1MH9bXjdyg/JQFu+ozqWSte8K5U/zcKKUp3mOSroxCdZ yrFg== MIME-Version: 1.0 X-Received: by 10.152.42.193 with SMTP id q1mr2725515lal.65.1375440408609; Fri, 02 Aug 2013 03:46:48 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Fri, 2 Aug 2013 03:46:48 -0700 (PDT) Date: Fri, 2 Aug 2013 05:46:48 -0500 Message-ID: From: Behcet Sarikaya To: "fmc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c36438f70b4f04e2f4ac4f Cc: John.Kaippallimalil@huawei.com, Marco Spini , Sri Gundavelli Subject: [fmc] Minutes of today's Bar BoF X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:46:54 -0000 --001a11c36438f70b4f04e2f4ac4f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Folks, let's take this discussion to the list: here is what has been exchanged so far: Hi Marco, Just to understand the scenario better=85 only to help frame the problem in terms that people in IETF can follow (it would be quite onerous to ask folks here to follow 3GPP, or BBF in detail.. ..). Considering the untrusted scenario, routed model (not shared prefix): untrusted (S2b) case with IPv6 and WLAN: 1) Host H1 authenticates to AP/BBF network and obtains IPv6 prefix A1 (per host prefix, not shared). 2) H1 sets up IPsec tunnel (IKE signaling, etc) to SEGW/ePDG, extracts source prefix A1 (and IMSI). (Note: BNG has no idea that IKE signaling is from H1.) 3) SEGW/ePDG uses Gxb, S9+, R to convey policy request to BNG (e.g. provide QoS, police flows X with src=3DA1). 4) BNG polices/handles QoS for flows with src=3DA1. Don=92t see the problem for above case. However, if the IP prefix A1 is shared by all hosts behind the RG, ePDG/BNG should base PCC handling on entire source address, e.g. src=3DA1:ID1 (obtained in IKE signaling). For trusted cases =96 bridged mode/shared link should not be a problem sinc= e the authenticator and policer are at BNG. Is it for routed model, trusted scenario that there is an issue (if so, could you outline a short sequence/prefix and node assumptions). Or something I=92ve completely missed =85 Thanks & Best Regards, John PS: Don=92t want to explain all of this on the fmc mailing list at this tim= e, since we cannot have a focused discussion. *From:* Marco Spini *Sent:* Thursday, August 01, 2013 8:01 AM *To:* Sri Gundavelli (sgundave); John Kaippallimalil; Behcet Sarikaya *Subject:* RE: [fmc] Minutes of today's Bar BoF Hi Sri, For the trusted scenario I agree with you. For EPC-routed the point is related to the PCC control, i.e. to the IP-CAN session which requires to associated an IP address and an identity. So the main problem is related to the capability of the BNG acting as PCEF to know the which is the actual IP address of the UE/device behind a RG with a IPv6 prefix delegation configuration to be able to start an IP-CAN session establishment with Device ID/IPv6 address. If this is not possible from PCC point of view, it is equivalent to the IPv4 NAT scenario. BR marco *From:* Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] *Sent:* gioved=EC 1 agosto 2013 14:49 *To:* John Kaippallimalil; Behcet Sarikaya; Marco Spini *Subject:* Re: [fmc] Minutes of today's Bar BoF Hi Marco, For the RG in the bridge mode (layer-2 link between the UE and the BNG), the link is indeed a shared link. However, the BNG clearly has the ability to unicast RA with the subscriber specific prefix. This is per RFC-6085, L2 unicast, L3 multicast. If the user is a EPC user, the TWAG function collocated with the BNG will any ways send unicast RA with the EPC provided prefix. For non-EPC users, the BNG can just do the same, unicast a prefix from the access network. In affect, the BNG builds a logical layer-2 links on a shared physical media. There are other options as well, leveraging NAT logging data. In any case, the burden is on the authors to explain the use-case clearly. This was indeed a clarifying question, which the presenter was not able to explain. Regards Sri PS: Bechet =96 This is OFFLIST discussion. *From: *John Kaippallimalil *Date: *Thursday, August 1, 2013 5:01 AM *To: *Behcet Sarikaya , Marco Spini < m.spini@huawei.com> *Cc: *Sri Gundavelli *Subject: *RE: [fmc] Minutes of today's Bar BoF Hi Behcet, OK =96 I think I understand (copying from TR-177): =93The main focus of TR-177 is on following scenarios: =A7 a subscriber having a routed RG. This RG can be connected to the access loop either directly or through a bridged RG. The routed RG acts as a Requesting Router (as per RFC 3633), and possibly embeds DHCPv6-based address allocation capabilities. =A7 a subscriber having a bridged RG, in which case the first hop router fo= r their hosts is the BNG. The subscriber hosts support DHCPv6 address allocation capabilities. In all cases SLAAC is supported to obtain link-local addresses and perform Duplicate Address Detection (DAD).=94 So, there is a case with a bridged RG =96 which then lends itself to a shar= ed IP link. BR, John --001a11c36438f70b4f04e2f4ac4f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Folks, let's take this discussion to the list:
here is what has been exchanged so far:

Hi Marco,

Just to understand the scena= rio better=85 only to help frame the problem in terms that people in IETF can follow (it would be quite onerous = to ask folks here to follow 3GPP, or BBF in detail.. ..).

=A0

Considering the untrusted sc= enario, routed model (not shared prefix): =A0untrusted (S2b) case with IPv6 and WLAN:

= 1)=A0=A0= =A0=A0=A0 Host H1 authenticates= to AP/BBF network and obtains IPv6 prefix A1 (per host prefix, not shared).

= 2)=A0=A0= =A0=A0=A0 H1 sets up IPsec tunn= el (IKE signaling, etc) to SEGW/ePDG, extracts source prefix A1 (and IMSI).
(Note: BNG has no idea that IKE signaling is from H1.)

= 3)=A0=A0= =A0=A0=A0 SEGW/ePDG uses Gxb, S= 9+, R to convey policy request to BNG (e.g. provide QoS, police flows X with src=3DA1).

= 4)=A0=A0= =A0=A0=A0 BNG polices/handles Q= oS for flows with src=3DA1.

=A0

Don=92t see the problem for = above case. However, if the IP prefix A1 is shared by all hosts behind the RG, ePDG/BNG should base PCC handling = on entire source address, e.g. src=3DA1:ID1 (obtained in IKE signaling).

For trusted cases =96 bridge= d mode/shared link should not be a problem since the authenticator and policer are at BNG.

=A0

Is it for routed model, trus= ted scenario that there is an issue (if so, could you outline a short sequence/prefix and node assumptions). Or something I=92ve completely missed =85

=A0

Thanks &

Best Regards,

John

=A0

PS: Don=92t want to explain = all of this on the fmc mailing list at this time, since we cannot have a focused discussion.

=A0

From: Marco Spini Sent: Thursday, August 01, 2013 8:01 AM
To: Sri Gundavelli (sgundave); John Kaippallimalil; Behcet Sarikaya<= br> Subject: RE: [fmc] Minutes of today's Bar BoF

=A0

Hi Sri,

=A0

For the trusted scenario I ag= ree with you. For EPC-routed the point is related to the PCC control, i.e. to the IP-CAN session which requi= res to associated an IP address and an identity. So the main problem is related= to the capability of the BNG acting =A0as PCEF to know the which is the actual IP address of the UE/device behind a RG with a IPv6 prefix delegation configuration to be able to start an IP-CAN session establishment with Devi= ce ID/IPv6 address. If this is not possible from PCC point of view, it is equivalent to the IPv4 NAT scenario.

=A0

BR

marco =A0

=A0

From: Sri Gundavelli = (sgundave) [mailto:sgundave@cisco.com= ]
Sent: gioved=EC 1 agosto 2013 14:49
To: John Kaippallimalil; Behcet Sarikaya; Marco Spini
Subject: Re: [fmc] Minutes of today's Bar BoF

=A0

Hi Marco,

=A0

For the RG in the bridge mode (layer= -2 link between the UE and the BNG), the link is indeed a shared link. However, the BNG clearly has the ability to unicast RA with the subscriber specific prefix. This is per RFC-6085, L2 unicast, L3 multicast. If the user is a EPC =A0user, the TWAG function collocated with the BNG will any ways send unicast RA with the EPC provided prefix. For non-EPC users, the BNG can just do the same, unicast a prefix from the access network. In affect, the BNG builds a logical layer-2= links on a shared physical media.=A0

=A0

There are other options as well, lev= eraging NAT logging data. In any case, the burden is on the authors to explain the use-case clearly. Thi= s was indeed a clarifying question, which the presenter was not able to expla= in.

=A0

=A0

Regards

Sri

PS:=A0Bechet =96 This is OFFLIST dis= cussion.

=A0

=A0

=A0

From: John Kaippallimalil <John.K= aippallimalil@huawei.com>
Date: Thursday, August 1, 2013 5:01 AM
To: Behcet Sarikaya <behcet.sarikaya@huawei.com>, Marco Spini <m.spini@huawei.com>
Cc: Sri Gundavelli <sgundav= e@cisco.com>
Subject: RE: [fmc] Minutes of today's Bar BoF

=A0

Hi Behcet,

OK =96 I think I understand (copying f= rom TR-177):

=93The main focus of TR= -177 is on following scenarios:

=A7=A0a subscriber having a routed = RG. This RG can be connected to the access loop either directly

or through a bridged RG. The routed RG acts as a Requesting Router (as per RFC 3633), and

possibly embeds DHCPv6-based address allocation capabilities.

=A7=A0a subscriber having a bridged= RG, in which case the first hop router for their hosts is the

BNG. The subscriber hosts support DHCPv6 address allocation capabilities.=

In all cases SLAAC is supported to obtain link-local addresses and perform Duplicate Address

Detection (DAD).=94<= /span>

=A0=

So, there is a case with a bridged RG = =96 which then lends itself to a shared IP link.

BR,=

John


--001a11c36438f70b4f04e2f4ac4f-- From sgundave@cisco.com Fri Aug 2 03:57:18 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9398411E828F for ; Fri, 2 Aug 2013 03:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B134lagYYdhy for ; Fri, 2 Aug 2013 03:57:13 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C20A411E8241 for ; Fri, 2 Aug 2013 03:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21068; q=dns/txt; s=iport; t=1375441032; x=1376650632; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gV9ygHvJm2dKWiyGMGyo6Vz+PEAMNSTbHcqDqPPP/pk=; b=e1QcRkYMSJWsH+7fVJ3GovIcC8CWC8hH6slMs/+fUlt5axSdBGr13jtd MRjVHUg+Jj6RA53jHzgv+UBuNfAfdQyea9vvPRxSp+1mSMnhKCsR5Ul+M AArJ9lSSNvvjEMA1FAuD9s2aHRrr0cswzpNvejCFWLKaMGwAUGR72WGvZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAJyP+1GtJV2a/2dsb2JhbABRCYJCRL9WgRwWdIIkAQEBBE4gCxACAQgRAwEBASgHIRABFAkIAgQOBR0Eh10DD7AiDYhejSeBMIEwEQYBgxl0A5V2gWmMJ4Ungxc X-IronPort-AV: E=Sophos;i="4.89,800,1367971200"; d="scan'208,217";a="242715235" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 02 Aug 2013 10:57:12 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r72AvCGH030068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 10:57:12 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.140]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 2 Aug 2013 05:57:11 -0500 From: "Sri Gundavelli (sgundave)" To: "" Thread-Topic: [fmc] Minutes of today's Bar BoF Thread-Index: AQHOj22e96qgMA9LS0ya0qkstQPblZmBvzhE Date: Fri, 2 Aug 2013 10:57:10 +0000 Message-ID: <5250DA23-DD2C-46EE-9C01-53832101B2DA@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5250DA23DD2C46EE9C0153832101B2DAciscocom_" MIME-Version: 1.0 Cc: "John.Kaippallimalil@huawei.com" , Marco Spini , "fmc@ietf.org" Subject: Re: [fmc] Minutes of today's Bar BoF X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:57:18 -0000 --_000_5250DA23DD2C46EE9C0153832101B2DAciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Behcet - Can you unsubscribe me from this list ? I dont remember subscribi= ng to this list. Sri Sent from my iPhone On Aug 2, 2013, at 12:47 PM, "Behcet Sarikaya" > wrote: Folks, let's take this discussion to the list: here is what has been exchanged so far: Hi Marco, Just to understand the scenario better=85 only to help frame the problem in= terms that people in IETF can follow (it would be quite onerous to ask fol= ks here to follow 3GPP, or BBF in detail.. ..). Considering the untrusted scenario, routed model (not shared prefix): untr= usted (S2b) case with IPv6 and WLAN: 1) Host H1 authenticates to AP/BBF network and obtains IPv6 prefix A1 = (per host prefix, not shared). 2) H1 sets up IPsec tunnel (IKE signaling, etc) to SEGW/ePDG, extracts= source prefix A1 (and IMSI). (Note: BNG has no idea that IKE signaling is from H1.) 3) SEGW/ePDG uses Gxb, S9+, R to convey policy request to BNG (e.g. pr= ovide QoS, police flows X with src=3DA1). 4) BNG polices/handles QoS for flows with src=3DA1. Don=92t see the problem for above case. However, if the IP prefix A1 is sha= red by all hosts behind the RG, ePDG/BNG should base PCC handling on entire= source address, e.g. src=3DA1:ID1 (obtained in IKE signaling). For trusted cases =96 bridged mode/shared link should not be a problem sinc= e the authenticator and policer are at BNG. Is it for routed model, trusted scenario that there is an issue (if so, cou= ld you outline a short sequence/prefix and node assumptions). Or something = I=92ve completely missed =85 Thanks & Best Regards, John PS: Don=92t want to explain all of this on the fmc mailing list at this tim= e, since we cannot have a focused discussion. From: Marco Spini Sent: Thursday, August 01, 2013 8:01 AM To: Sri Gundavelli (sgundave); John Kaippallimalil; Behcet Sarikaya Subject: RE: [fmc] Minutes of today's Bar BoF Hi Sri, For the trusted scenario I agree with you. For EPC-routed the point is rela= ted to the PCC control, i.e. to the IP-CAN session which requires to associ= ated an IP address and an identity. So the main problem is related to the c= apability of the BNG acting as PCEF to know the which is the actual IP add= ress of the UE/device behind a RG with a IPv6 prefix delegation configurati= on to be able to start an IP-CAN session establishment with Device ID/IPv6 = address. If this is not possible from PCC point of view, it is equivalent t= o the IPv4 NAT scenario. BR marco From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: gioved=EC 1 agosto 2013 14:49 To: John Kaippallimalil; Behcet Sarikaya; Marco Spini Subject: Re: [fmc] Minutes of today's Bar BoF Hi Marco, For the RG in the bridge mode (layer-2 link between the UE and the BNG), th= e link is indeed a shared link. However, the BNG clearly has the ability to= unicast RA with the subscriber specific prefix. This is per RFC-6085, L2 u= nicast, L3 multicast. If the user is a EPC user, the TWAG function colloca= ted with the BNG will any ways send unicast RA with the EPC provided prefix= . For non-EPC users, the BNG can just do the same, unicast a prefix from th= e access network. In affect, the BNG builds a logical layer-2 links on a sh= ared physical media. There are other options as well, leveraging NAT logging data. In any case, = the burden is on the authors to explain the use-case clearly. This was inde= ed a clarifying question, which the presenter was not able to explain. Regards Sri PS: Bechet =96 This is OFFLIST discussion. From: John Kaippallimalil > Date: Thursday, August 1, 2013 5:01 AM To: Behcet Sarikaya >, Marco Spini > Cc: Sri Gundavelli > Subject: RE: [fmc] Minutes of today's Bar BoF Hi Behcet, OK =96 I think I understand (copying from TR-177): =93The main focus of TR-177 is on following scenarios: =95 a subscriber having a routed RG. This RG can be connected to the access= loop either directly or through a bridged RG. The routed RG acts as a Requesting Router (as per = RFC 3633), and possibly embeds DHCPv6-based address allocation capabilities. =95 a subscriber having a bridged RG, in which case the first hop router fo= r their hosts is the BNG. The subscriber hosts support DHCPv6 address allocation capabilities. In all cases SLAAC is supported to obtain link-local addresses and perform = Duplicate Address Detection (DAD).=94 So, there is a case with a bridged RG =96 which then lends itself to a shar= ed IP link. BR, John --_000_5250DA23DD2C46EE9C0153832101B2DAciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Behcet - Can you unsubscribe me from this  list ? I dont remember= subscribing to this list.


Sri


Sent from my iPhone

On Aug 2, 2013, at 12:47 PM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:

Folks, let's take this discussion to the list:

here is what has been exchanged so far:

Hi Marco,

Just to understand the scena= rio better=85 only to help frame the problem in terms that people in IETF c= an follow (it would be quite onerous to ask folks here to follow 3GPP, or BBF in detail.. ..).

 

Considering the untrusted sc= enario, routed model (not shared prefix):  untrusted (S2b) case with I= Pv6 and WLAN:

= 1)&nb= sp;     Host H1 authenticates= to AP/BBF network and obtains IPv6 prefix A1 (per host prefix, not shared)= .

= 2)&nb= sp;     H1 sets up IPsec tunn= el (IKE signaling, etc) to SEGW/ePDG, extracts source prefix A1 (and IMSI).=
(Note: BNG has no idea that IKE signaling is from H1.)

= 3)&nb= sp;     SEGW/ePDG uses Gxb, S= 9+, R to convey policy request to BNG (e.g. provide QoS, police flows X= with src=3DA1).

= 4)&nb= sp;     BNG polices/handles Q= oS for flows with src=3DA1.

 

Don=92t see the problem for = above case. However, if the IP prefix A1 is shared by all hosts behind the = RG, ePDG/BNG should base PCC handling on entire source address, e.g. src=3DA1:ID1 (obtained in IKE signaling).

For trusted cases =96 bridge= d mode/shared link should not be a problem since the authenticator and poli= cer are at BNG.

 

Is it for routed model, trus= ted scenario that there is an issue (if so, could you outline a short seque= nce/prefix and node assumptions). Or something I=92ve completely missed =85

 

Thanks &

Best Regards,

John

 

PS: Don=92t want to explain = all of this on the fmc mailing list at this time, since we cannot have a fo= cused discussion.

 

From: Marco Spin= i
Sent: Thursday, August 01, 2013 8:01 AM
To: Sri Gundavelli (sgundave); John Kaippallimalil; Behcet Sarikaya<= br> Subject: RE: [fmc] Minutes of today's Bar BoF

 

Hi Sri,

 

For the trusted scenario I ag= ree with you. For EPC-routed the point is related to the PCC control, i.e. = to the IP-CAN session which requires to associated an IP address and an identity. So the main problem is related to the capability = of the BNG acting  as PCEF to know the which is the actual IP address = of the UE/device behind a RG with a IPv6 prefix delegation configuration to= be able to start an IP-CAN session establishment with Device ID/IPv6 address. If this is not possible from PCC point of vie= w, it is equivalent to the IPv4 NAT scenario.

 

BR

marco  

 

From: Sri Gundav= elli (sgundave) [mailto:sgundave@cisc= o.com]
Sent: gioved=EC 1 agosto 2013 14:49
To: John Kaippallimalil; Behcet Sarikaya; Marco Spini
Subject: Re: [fmc] Minutes of today's Bar BoF

 

Hi Marco,

 

For the RG in the bridge mode (layer= -2 link between the UE and the BNG), the link is indeed a shared link. Howe= ver, the BNG clearly has the ability to unicast RA with the subscriber specific prefix. This is per RFC-6085, L2 unicast, L3 multi= cast. If the user is a EPC  user, the TWAG function collocated with th= e BNG will any ways send unicast RA with the EPC provided prefix. For non-E= PC users, the BNG can just do the same, unicast a prefix from the access network. In affect, the BNG builds a logi= cal layer-2 links on a shared physical media. 

 

There are other options as well, lev= eraging NAT logging data. In any case, the burden is on the authors to expl= ain the use-case clearly. This was indeed a clarifying question, which the presenter was not able to explain.

 

 

Regards

Sri

PS: Bechet =96 This is OFFLIST = discussion.

 

 

 

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Thursday, August 1, 2013 5:01 AM
To: Behcet Sarikaya <behcet.sarikaya@huawei.com>, Marco Spini <m.spini@huawei.com>
Cc: Sri Gundavelli <sgundav= e@cisco.com>
Subject: RE: [fmc] Minutes of today's Bar BoF

 

Hi Behcet,

OK =96 I think I understand (copying f= rom TR-177):

=93The main focus of TR= -177 is on following scenarios:

=A7 a subscriber having a rout= ed RG. This RG can be connected to the access loop either directly

or through a bridged RG. The routed RG acts as a Requ= esting Router (as per RFC 3633), and

possibly embeds DHCPv6-based address allocation capab= ilities.

=A7 a subscriber having a brid= ged RG, in which case the first hop router for their hosts is the

BNG. The subscriber hosts support DHCPv6 address allo= cation capabilities.

In all cases SLAAC is supported to obtain link-local = addresses and perform Duplicate Address<= /span>

Detection (DAD).=94

 

So, there is a case with a bridged RG = =96 which then lends itself to a shared IP link.

BR,=

John


--_000_5250DA23DD2C46EE9C0153832101B2DAciscocom_-- From laurent.thiebaut@alcatel-lucent.com Fri Aug 2 04:12:05 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA0711E82B5 for ; Fri, 2 Aug 2013 04:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+JRRu6UpUmC for ; Fri, 2 Aug 2013 04:11:58 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 70F1711E82D8 for ; Fri, 2 Aug 2013 04:11:56 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r72BBkaS001703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Aug 2013 06:11:47 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r72BBi8e006265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 13:11:45 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 2 Aug 2013 13:11:45 +0200 From: "THIEBAUT, LAURENT (LAURENT)" To: "sarikaya@ieee.org" , "fmc@ietf.org" Thread-Topic: [fmc] Minutes of today's Bar BoF Thread-Index: AQHOj22eObpySKnbmkWwQ3k2YtPdVZmBv4/g Date: Fri, 2 Aug 2013 11:11:44 +0000 Message-ID: <669B2D5ED96A8E4E9FD34C91DFD815B0081665@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_669B2D5ED96A8E4E9FD34C91DFD815B0081665FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "John.Kaippallimalil@huawei.com" , Marco Spini , Sri Gundavelli Subject: Re: [fmc] Minutes of today's Bar BoF X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 11:12:05 -0000 --_000_669B2D5ED96A8E4E9FD34C91DFD815B0081665FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all 1) I do not fully understand the statement below For the trusted scenario I agree with you. For EPC-routed the point is rela= ted to the PCC control, i.e. to the IP-CAN session which requires to associ= ated an IP address and an identity. So the main problem is related to the c= apability of the BNG acting as PCEF to know the which is the actual IP add= ress of the UE/device behind a RG with a IPv6 prefix delegation configurati= on to be able to start an IP-CAN session establishment with Device ID/IPv6 = address. If this is not possible from PCC point of view, it is equivalent t= o the IPv4 NAT scenario. For EPC-routed, the BNG is not a PCEF (policy enforcement function), the P= CEF is in the PGW/PDN-GW 2) but I agree that the TWAG (entity of the fixed access that maps a Wir= eline IP session to a Wireless S2a EPC-routed connection to a PGW) shall be= able to associate an IPv6 address/prefix (of the mobile/UE) with an EPC-ro= uted/SAMOG/S2a session Actually in case of EPC-routed (S2a), the IP @ / Prefix of the UE is alloca= ted by the PGW, NOT by the RGW. In EPC-routed case, the UE is on a 'virtual' link of the PGW. Best Regards Laurent ALCATEL-LUCENT De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de Behce= t Sarikaya Envoy=E9 : vendredi 2 ao=FBt 2013 12:47 =C0 : fmc@ietf.org Cc : John.Kaippallimalil@huawei.com; Marco Spini; Sri Gundavelli Objet : [fmc] Minutes of today's Bar BoF Folks, let's take this discussion to the list: here is what has been exchanged so far: Hi Marco, Just to understand the scenario better... only to help frame the problem in= terms that people in IETF can follow (it would be quite onerous to ask fol= ks here to follow 3GPP, or BBF in detail.. ..). Considering the untrusted scenario, routed model (not shared prefix): untr= usted (S2b) case with IPv6 and WLAN: 1) Host H1 authenticates to AP/BBF network and obtains IPv6 prefix A1 = (per host prefix, not shared). 2) H1 sets up IPsec tunnel (IKE signaling, etc) to SEGW/ePDG, extracts= source prefix A1 (and IMSI). (Note: BNG has no idea that IKE signaling is from H1.) 3) SEGW/ePDG uses Gxb, S9+, R to convey policy request to BNG (e.g. pr= ovide QoS, police flows X with src=3DA1). 4) BNG polices/handles QoS for flows with src=3DA1. Don't see the problem for above case. However, if the IP prefix A1 is share= d by all hosts behind the RG, ePDG/BNG should base PCC handling on entire s= ource address, e.g. src=3DA1:ID1 (obtained in IKE signaling). For trusted cases - bridged mode/shared link should not be a problem since = the authenticator and policer are at BNG. Is it for routed model, trusted scenario that there is an issue (if so, cou= ld you outline a short sequence/prefix and node assumptions). Or something = I've completely missed ... Thanks & Best Regards, John PS: Don't want to explain all of this on the fmc mailing list at this time,= since we cannot have a focused discussion. From: Marco Spini Sent: Thursday, August 01, 2013 8:01 AM To: Sri Gundavelli (sgundave); John Kaippallimalil; Behcet Sarikaya Subject: RE: [fmc] Minutes of today's Bar BoF Hi Sri, For the trusted scenario I agree with you. For EPC-routed the point is rela= ted to the PCC control, i.e. to the IP-CAN session which requires to associ= ated an IP address and an identity. So the main problem is related to the c= apability of the BNG acting as PCEF to know the which is the actual IP add= ress of the UE/device behind a RG with a IPv6 prefix delegation configurati= on to be able to start an IP-CAN session establishment with Device ID/IPv6 = address. If this is not possible from PCC point of view, it is equivalent t= o the IPv4 NAT scenario. BR marco From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: gioved=EC 1 agosto 2013 14:49 To: John Kaippallimalil; Behcet Sarikaya; Marco Spini Subject: Re: [fmc] Minutes of today's Bar BoF Hi Marco, For the RG in the bridge mode (layer-2 link between the UE and the BNG), th= e link is indeed a shared link. However, the BNG clearly has the ability to= unicast RA with the subscriber specific prefix. This is per RFC-6085, L2 u= nicast, L3 multicast. If the user is a EPC user, the TWAG function colloca= ted with the BNG will any ways send unicast RA with the EPC provided prefix= . For non-EPC users, the BNG can just do the same, unicast a prefix from th= e access network. In affect, the BNG builds a logical layer-2 links on a sh= ared physical media. There are other options as well, leveraging NAT logging data. In any case, = the burden is on the authors to explain the use-case clearly. This was inde= ed a clarifying question, which the presenter was not able to explain. Regards Sri PS: Bechet - This is OFFLIST discussion. From: John Kaippallimalil > Date: Thursday, August 1, 2013 5:01 AM To: Behcet Sarikaya >, Marco Spini > Cc: Sri Gundavelli > Subject: RE: [fmc] Minutes of today's Bar BoF Hi Behcet, OK - I think I understand (copying from TR-177): "The main focus of TR-177 is on following scenarios: * a subscriber having a routed RG. This RG can be connected to the access l= oop either directly or through a bridged RG. The routed RG acts as a Requesting Router (as per = RFC 3633), and possibly embeds DHCPv6-based address allocation capabilities. * a subscriber having a bridged RG, in which case the first hop router for = their hosts is the BNG. The subscriber hosts support DHCPv6 address allocation capabilities. In all cases SLAAC is supported to obtain link-local addresses and perform = Duplicate Address Detection (DAD)." So, there is a case with a bridged RG - which then lends itself to a shared= IP link. BR, John --_000_669B2D5ED96A8E4E9FD34C91DFD815B0081665FR712WXCHMBA11zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

Hello all

1)   = ; I do not fully= understand the statement below

For the tr= usted scenario I agree with you. For EPC-routed the point is related to the= PCC control, i.e. to the IP-CAN session which requires to associated an IP address and an identity. So the main problem is related t= o the capability of the BNG acting  = ;as PCEF to know the which is the actual IP address of the UE/device= behind a RG with a IPv6 prefix delegation configuration to be able to star= t an IP-CAN session establishment with Device ID/IPv6 address. If this is not possible from PCC point of view, it= is equivalent to the IPv4 NAT scenario.

For EPC-routed, the BNG is not a PCEF (policy enforcement  = function), the PCEF is in the PGW/PDN-GW

 

2)   = ; but I agree th= at the TWAG (entity of the fixed access that maps a Wireline IP session to = a Wireless S2a EPC-routed connection to a PGW) shall be able to associate a= n IPv6 address/prefix (of the mobile/UE) with an EPC-routed/SAMOG/S2a session

Actually in case of EPC-routed (S2a), the IP @ / Prefix of th= e UE is allocated by the PGW, NOT by the RGW.

In EPC-routed case, the UE is on a ‘virtual’ link= of the PGW.

Best Regards

Laurent
ALCATEL-LUCENT

De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de Behcet Sarikaya
Envoy=E9 : vendredi 2 ao=FBt 2013 12:47
=C0 : fmc@ietf.org
Cc : John.Kaippallimalil@huawei.com; Marco Spini; Sri Gundavell= i
Objet : [fmc] Minutes of today's Bar BoF

 

Folks, let's take this discussion to the list:

here is what has been exchanged so far:

Hi Marco,

Just to understand the scenario better… on= ly to help frame the problem in terms that people in IETF can follow (it wo= uld be quite onerous to ask folks here to follow 3GPP, or BBF in detail.. ..).

 

Considering the untrusted scenario, routed model= (not shared prefix):  untrusted (S2b) case with IPv6 and WLAN:=

1)      Host H1 authenticates to AP/BBF network a= nd obtains IPv6 prefix A1 (per host prefix, not shared).<= /p>

2)      H1 sets up IPsec tunnel (IKE signaling, e= tc) to SEGW/ePDG, extracts source prefix A1 (and IMSI).
(Note: BNG has no idea that IKE signaling is from H1.)

3)      SEGW/ePDG uses Gxb, S9+, R to convey = policy request to BNG (e.g. provide QoS, police flows X with src=3DA1).

4)      BNG polices/handles QoS for flows with sr= c=3DA1.

 

Don’t see the problem for above case. Howe= ver, if the IP prefix A1 is shared by all hosts behind the RG, ePDG/BNG sho= uld base PCC handling on entire source address, e.g. src=3DA1:ID1 (obtained in IKE signaling).

For trusted cases – bridged mode/shared li= nk should not be a problem since the authenticator and policer are at BNG.<= /span>

 

Is it for routed model, trusted scenario that th= ere is an issue (if so, could you outline a short sequence/prefix and node = assumptions). Or something I’ve completely missed …=

 

Thanks &

Best Regards,

John

 

PS: Don’t want to explain all of this on t= he fmc mailing list at this time, since we cannot have a focused discussion= .

 

From: Marco Spini
Sent: Thursday, August 01, 2013 8:01 AM
To: Sri Gundavelli (sgundave); John Kaippallimalil; Behcet Sarikaya<= br> Subject: RE: [fmc] Minutes of today's Bar BoF

 

Hi Sri,

 

For the trusted scenario I agree with you. For E= PC-routed the point is related to the PCC control, i.e. to the IP-CAN sessi= on which requires to associated an IP address and an identity. So the main problem is related to the capability of the BNG acting  a= s PCEF to know the which is the actual IP address of the UE/device behind a= RG with a IPv6 prefix delegation configuration to be able to start an IP-C= AN session establishment with Device ID/IPv6 address. If this is not possible from PCC point of view, it is equ= ivalent to the IPv4 NAT scenario.

 

BR

marco  

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: gioved=EC 1 agosto 2013 14:49
To: John Kaippallimalil; Behcet Sarikaya; Marco Spini
Subject: Re: [fmc] Minutes of today's Bar BoF

 

Hi Marco,

 

For the RG in the bridge mode (layer-2 link betwee= n the UE and the BNG), the link is indeed a shared link. However, the BNG c= learly has the ability to unicast RA with the subscriber specific prefix. This is per RFC-6085, L2 unicast, L3 multicast. If the us= er is a EPC  user, the TWAG function collocated with the BNG will any = ways send unicast RA with the EPC provided prefix. For non-EPC users, the B= NG can just do the same, unicast a prefix from the access network. In affect, the BNG builds a logical layer-2 links= on a shared physical media. 

 

There are other options as well, leveraging NAT lo= gging data. In any case, the burden is on the authors to explain the use-ca= se clearly. This was indeed a clarifying question, which the presenter was not able to explain.

 

 

Regards

Sri

PS: Bechet – This is OFFLIST discussion= .

 

 

 

From: John Kaippallimalil <John.Kaippallimalil@huawei.com> Date: Thursday, August 1, 2013 5:01 AM
To: Behcet Sarikaya <behcet.sarikaya@huawei.com>, Marco Spini <m.spini@huawei.com>
Cc: Sri Gundavelli <sgundav= e@cisco.com>
Subject: RE: [fmc] Minutes of today's Bar BoF

 

Hi Behcet,

OK – I think I understand (copying from TR-1= 77):

“The main focus of TR-177 is = on following scenarios:

=A7 a su= bscriber having a routed RG. This RG can be connected to the access loop ei= ther directly

or through a bridged RG. The routed RG acts as a Requesting Router = (as per RFC 3633), and

possibly embeds DHCPv6-based address allocation capabilities.

=A7 a su= bscriber having a bridged RG, in which case the first hop router for their = hosts is the

BNG. The subscriber hosts support DHCPv6 address allocation capabil= ities.

In all cases SLAAC is supported to obtain link-local addresses and = perform Duplicate Address

Detection (DAD).”=

 

So, there is a case with a bridged RG – whic= h then lends itself to a shared IP link.

BR,

John

 

--_000_669B2D5ED96A8E4E9FD34C91DFD815B0081665FR712WXCHMBA11zeu_-- From joelja@bogus.com Sat Aug 3 07:13:41 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DBC21F9D0D for ; Sat, 3 Aug 2013 07:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4gG53DcGJY8 for ; Sat, 3 Aug 2013 07:13:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7213621F9D3A for ; Sat, 3 Aug 2013 07:13:39 -0700 (PDT) Received: from joels-MacBook-Air.local ([46.189.28.45]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r73EDT8K035069 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 3 Aug 2013 14:13:31 GMT (envelope-from joelja@bogus.com) Message-ID: <51FD1008.4060309@bogus.com> Date: Sat, 03 Aug 2013 16:13:28 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: sarikaya@ieee.org, "fmc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 03 Aug 2013 14:13:32 +0000 (UTC) Cc: "Dirk.von-Hugo@telekom.de" Subject: Re: [fmc] Minutes of today's Bar BoF X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 14:13:41 -0000 two things jump out at me... 1. Residential gateway -- home network -- fixed network edge router All of the hosts in home network connected to RG should be controlled by mobile network One policy system, apply to both mobile and fixed networks How do we get QoS constraints, policy from the mobile network? Imho in the general case it's no business of my provider's at all what equipment I attach to my home-network. 2. andrew's presentation diverges rather far from the stated problem. appart from the question of trust, there's an intense amount of singling going on if you're sending identity packet for every connection setup. On 7/31/13 1:43 PM, Behcet Sarikaya wrote: > Dear all, > > We had a very productive meeting today which was attended by 16 or so > people. > > Please find attached the minutes. > Our special thanks to Pete McCann for taking the notes in such an > amazing detail. > > Regards, > > Dirk & Behcet From sarikaya2012@gmail.com Sun Aug 4 15:17:05 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023B521E80AC for ; Sun, 4 Aug 2013 15:17:05 -0700 (PDT) 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=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIw+c4vbuddz for ; Sun, 4 Aug 2013 15:17:04 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DC90721E80A9 for ; Sun, 4 Aug 2013 15:17:03 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so1611270lbf.18 for ; Sun, 04 Aug 2013 15:17:02 -0700 (PDT) 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=gq1BxFCJm9CCeoZ47AkAjm+g1LwStV8ROjhEynl7mWk=; b=PxD34lIKFJhqEQnXlUr/bRqpoiJ//P4NOZ0trkT0j3tZTH29vweGTpWlx8vsJ7O7kc hWyRF5uOI0JX8OPfFzeeNmNvGuTLGfuA97c6Y1bmR9JYa7cD98QjBtPs4014LEAfn0nJ VKbLDbfHLZwpOhhqJ2bx47rNdv+/nKP60lkp43+Di++sr/Nlfl54T5Z453PN+ubadUu9 5Iho1vXLnDK/JxVudkt1dJ7VoCvh7a73zcNI3olmqyRH2RBk0pmSNsikmWZN8EQsm4gL RsH3M0r7UKpuU9yGP+9EHOGmBPZeCSlnC7Il78cwR0u7vhzhwap8Zlbde+SAkPpkynnl dEkQ== MIME-Version: 1.0 X-Received: by 10.112.188.165 with SMTP id gb5mr7584742lbc.38.1375654622605; Sun, 04 Aug 2013 15:17:02 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Sun, 4 Aug 2013 15:17:02 -0700 (PDT) In-Reply-To: <51FD1008.4060309@bogus.com> References: <51FD1008.4060309@bogus.com> Date: Sun, 4 Aug 2013 17:17:02 -0500 Message-ID: From: Behcet Sarikaya To: joel jaeggli Content-Type: multipart/alternative; boundary=001a11c36da21d34e804e3268db2 Cc: "fmc@ietf.org" , "Dirk.von-Hugo@telekom.de" Subject: Re: [fmc] Minutes of today's Bar BoF X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 22:17:05 -0000 --001a11c36da21d34e804e3268db2 Content-Type: text/plain; charset=ISO-8859-1 Hi Joel, My comments inline: Regards, Behcet On Sat, Aug 3, 2013 at 9:13 AM, joel jaeggli wrote: > two things jump out at me... > > 1. > > Residential gateway -- home network -- fixed network edge router > All of the hosts in home network connected to RG should be > controlled by mobile network > One policy system, apply to both mobile and fixed networks > How do we get QoS constraints, policy from the mobile network? > > A Diameter session is established by the edge router in fixed network with the policy server in mobile network and Diameter QoS protocol (RFC 5866) is used, details are described in 3GPP standards. Imho in the general case it's no business of my provider's at all what > equipment I attach to my home-network. > > Yes but within the limits of your contract with your provider. So there is QoS control in degrees that vary from provider to provider in different countries. > 2. andrew's presentation diverges rather far from the stated problem. > > appart from the question of trust, there's an intense amount of singling > going on if you're sending identity packet for every connection setup. > > I should let Andrew to reply to this point. > > On 7/31/13 1:43 PM, Behcet Sarikaya wrote: > > Dear all, > > > > We had a very productive meeting today which was attended by 16 or so > > people. > > > > Please find attached the minutes. > > Our special thanks to Pete McCann for taking the notes in such an > > amazing detail. > > > > Regards, > > > > Dirk & Behcet > > --001a11c36da21d34e804e3268db2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joel,

My comments inline:

Regards,

Behcet
On Sat, Aug 3, 2013 at 9:13 AM, joel jaeggli <joelja@bogus.com> wrote:
two things jump out at me...

1.

=A0 =A0 Residential gateway -- home network -- fixed network edge router =A0 =A0 All of the hosts in home network connected to RG should be
=A0 =A0 controlled by mobile network
=A0 =A0 One policy system, apply to both mobile and fixed networks
=A0 =A0 How do we get QoS constraints, policy from the mobile network?

A Diameter session is established by the edge router = in fixed network with the policy server in mobile network and Diameter QoS = protocol (RFC 5866) is used, details are described in 3GPP standards.

Imho in the general case it's no business of my provider's at all w= hat
equipment I attach to my home-network.


Yes but within the limits of your cont= ract with your provider.
So there is QoS control in degrees = that vary from provider to provider in different countries.
=A0
2. andrew's presentation diverges rather far from the stated problem.
appart from the question of trust, there's an intense amount of singlin= g
going on if you're sending identity packet for every connection setup.<= br>

I= should let Andrew to reply to this point.
=A0

On 7/31/13 1:43 PM, Behcet Sarikaya wrote:
> Dear all,
>
> We had a very productive meeting today which was attended by 16 or so<= br> > people.
>
> Please find attached the minutes.
> Our special thanks to Pete McCann for taking the notes in such an
> amazing detail.
>
> Regards,
>
> Dirk & Behcet


--001a11c36da21d34e804e3268db2-- From joelja@bogus.com Mon Aug 5 09:04:08 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DAE21F9F77 for ; Mon, 5 Aug 2013 09:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLa9dbg70x+b for ; Mon, 5 Aug 2013 09:04:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFE021F9DAF for ; Mon, 5 Aug 2013 09:04:08 -0700 (PDT) Received: from joels-MacBook-Air.local ([213.221.117.228]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r75G42Dt064067 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 16:04:04 GMT (envelope-from joelja@bogus.com) Message-ID: <51FFCCEC.5010400@bogus.com> Date: Mon, 05 Aug 2013 18:03:56 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <51FD1008.4060309@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 05 Aug 2013 16:04:05 +0000 (UTC) Cc: "fmc@ietf.org" , "Dirk.von-Hugo@telekom.de" Subject: Re: [fmc] Minutes of today's Bar BoF X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:04:09 -0000 On 8/5/13 12:17 AM, Behcet Sarikaya wrote: > Hi Joel, > > My comments inline: > > Regards, > > Behcet > > On Sat, Aug 3, 2013 at 9:13 AM, joel jaeggli > wrote: > > two things jump out at me... > > 1. > > Residential gateway -- home network -- fixed network edge router > All of the hosts in home network connected to RG should be > controlled by mobile network > One policy system, apply to both mobile and fixed networks > How do we get QoS constraints, policy from the mobile network? > > A Diameter session is established by the edge router in fixed network > with the policy server in mobile network and Diameter QoS protocol > (RFC 5866) is used, details are described in 3GPP standards. > > Imho in the general case it's no business of my provider's at all what > equipment I attach to my home-network. > > > Yes but within the limits of your contract with your provider. Which may be irrelevant if it's the thin-end of a wedge that may be privacy and security antagonistic to homenets and other small networks. Recall that a UE is applying a security policy on behalf of downstream networks and devices, Those networks may be peer-2-peer they may well have devices who default out other networks, be on other carriers, or which do not on fact use the internet. > So there is QoS control in degrees that vary from provider to provider > in different countries. > > > 2. andrew's presentation diverges rather far from the stated problem. > > appart from the question of trust, there's an intense amount of > singling > going on if you're sending identity packet for every connection setup. > > I should let Andrew to reply to this point. > > > > On 7/31/13 1:43 PM, Behcet Sarikaya wrote: > > Dear all, > > > > We had a very productive meeting today which was attended by 16 > or so > > people. > > > > Please find attached the minutes. > > Our special thanks to Pete McCann for taking the notes in such an > > amazing detail. > > > > Regards, > > > > Dirk & Behcet > > From sarikaya2012@gmail.com Wed Aug 7 15:05:05 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5258721E808E for ; Wed, 7 Aug 2013 15:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxu8vjyHurBG for ; Wed, 7 Aug 2013 15:05:04 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2016E21E80B3 for ; Wed, 7 Aug 2013 15:05:03 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id 13so1928350lba.20 for ; Wed, 07 Aug 2013 15:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=2pDXcCpLuvSL4vckkoLQCJCJz76ZCTkDmcBhNNR2lzc=; b=SAoJn2Ka49b+xHitJ6LVyZjkr32LLNAvFzqeNADDk4qHCdXRBj3scMNDsAwNviqE7R C3uPzZIaLKVtY/Gfw0/H+JPKeNscsd0IVWCXRTm5WRVUVTCC6cj6A51Hl4SJrB+eumvX KD1SepI8f/gD07qGYMI2lRaoRmi8oInjqGsS2XFbtOkY4A90WKsjzDTXOm/XV5Iadko8 M9p54LwbXL9N6++9hXIE1Le5JG8cJh8hRTzZUWPCmdy5FwqJuormyovNmDQCJcxc4t+A qAHxmJaYPTf16xAOHSvU7UlfSxBQVTqROBWWRdAK1yrdLOk3CTMc8ZKxzZKcBTSKCXjf pumw== MIME-Version: 1.0 X-Received: by 10.112.158.228 with SMTP id wx4mr1102634lbb.29.1375913102959; Wed, 07 Aug 2013 15:05:02 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Wed, 7 Aug 2013 15:05:02 -0700 (PDT) Date: Wed, 7 Aug 2013 17:05:02 -0500 Message-ID: From: Behcet Sarikaya To: "fmc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c383b0be6b8a04e362bba0 Subject: [fmc] Privacy Tutorial in Berlin X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 22:05:05 -0000 --001a11c383b0be6b8a04e362bba0 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Since privacy is mentioned as an issue especially in the address sharing solutions, it seems like recently held privacy tutorial in Berlin is very relevant. This tutorial is recorded and can be accessed here: http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF87_PRIVACY_TUTORIAL&chapter=part_1 The tutorial last about one and half hour, I am currently watching it. IAB also published an RFC, RFC6973 on Privacy Considerations. RFC 6973 is also very relevant and useful. It lists in its Section 7 provides guidance for document authors in the form of a questionnaire about a protocol being designed and in Section 8 a specific protocol, IETF presence protocol is taken as an example of the thinking that should go into the design of a protocol when considering privacy as a first principle. I think both the tutorial video and RFC 6973 are good material to check for us, they have come just in time when we needed them :-). Regards, Behcet --001a11c383b0be6b8a04e362bba0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Si= nce privacy is mentioned as an issue especially in the address sharing solu= tions, it seems like recently held privacy tutorial in Berlin is very relev= ant.

This tutorial is recorded and can be accessed here:

http://recordings.conf.meetech= o.com/Recordings/watch.jsp?recording=3DIETF87_PRIVACY_TUTORIAL&chapter= =3Dpart_1

The tutorial last about one and half hour, I am currently watchin= g it.

IAB also published an RFC, RFC6973 on Privacy Considerat= ions. RFC 6973 is also very relevant and useful. It lists in its Section 7 = provides guidance for document authors in the form of a questionnaire about a protocol being designed and in Section 8 a specifi= c protocol, IETF presence protocol is taken as an example of the thinking = that should go into the design of a protocol when considering privacy as a first principle.

I think both the tutorial video and RFC 69= 73 are good material to check for us, they have come just in time when we n= eeded them :-).

Regards,

Behcet
--001a11c383b0be6b8a04e362bba0-- From sarikaya2012@gmail.com Wed Aug 21 12:14:02 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763A21F9F26 for ; Wed, 21 Aug 2013 12:14:02 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo1CtHksKNaY for ; Wed, 21 Aug 2013 12:14:02 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9796221F9F2B for ; Wed, 21 Aug 2013 12:14:01 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id er20so674058lab.7 for ; Wed, 21 Aug 2013 12:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=+Jd6Eg4qL+Syl1DamsEItkSS0hoSrnZ4c+cBZUuPh+s=; b=O+BDusXQS4FNXXhlUOuQcNVvvAgQRa2OM953jlnzxNzW9Fz+naP+7NLUN9l/riqCKN CofboDjgD8lSjUEO1Y9BcemPSxV5QHUiwFh32yX8Q/Stb2pTQCF+mhV72zPqdqYR52gB HT3ICm4CD1RsbcS4JyXablBm8lcplB8xir+xMJGYz/Zn/6ZbHOKavzVu0VG0AX+zb4dD QbgO9HfMH61Fcw4R8Wo5w9z1rqmgwzm4BC0q8V4iaJ4Cr/o9dzIsaXw7slTwk9lvPNA5 o1bDlYRN8jclyGOmWC/KCnv9KYPwtau2coWONn0m4NHBJTLvmOHHD4oQh4oOpnn2eZ8j g+/Q== MIME-Version: 1.0 X-Received: by 10.152.22.198 with SMTP id g6mr7165202laf.5.1377112440330; Wed, 21 Aug 2013 12:14:00 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Wed, 21 Aug 2013 12:14:00 -0700 (PDT) Date: Wed, 21 Aug 2013 14:14:00 -0500 Message-ID: From: Behcet Sarikaya To: "fmc@ietf.org" Content-Type: multipart/alternative; boundary=089e0160bab0d25d8404e479f974 Cc: John.Kaippallimalil@huawei.com, Sri Gundavelli Subject: [fmc] Recalling mail from Friday August 2nd X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:14:02 -0000 --089e0160bab0d25d8404e479f974 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Folks, I would like to recall this mail on the list: http://www.ietf.org/mail-archive/web/fmc/current/msg00217.html based on this p.s. PS: Don=92t want to explain all of this on the fmc mailing list at this tim= e, since we cannot have a focused discussion. which I ignored. Regards, Behcet --089e0160bab0d25d8404e479f974 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Folks,

I would like = to recall this mail on the list:

http://www.ietf.org/mail-archive/we= b/fmc/current/msg00217.html

based on this p.s.
PS: Don=92= t want to explain all of this on the fmc mailing list at this time, since we cannot have a focused discussion.

= which I ignored.

Regards,

Behcet
--089e0160bab0d25d8404e479f974-- From sarikaya2012@gmail.com Tue Aug 27 11:24:49 2013 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B19411E81D5 for ; Tue, 27 Aug 2013 11:24:49 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMj0Zvui9Bkl for ; Tue, 27 Aug 2013 11:24:48 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 79AE211E8134 for ; Tue, 27 Aug 2013 11:24:48 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id p5so2887462lbi.22 for ; Tue, 27 Aug 2013 11:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=JySrakY05BSbNj26HRygb2U2Ya9YPUIH0uG3l6XO0GI=; b=RvBfePlZ1qnoO/zbEbexKIimj8obTwH9tKc0bF5JjBLYzTOck++SbD4aPdzZZ2KKS2 /e3RW2nAZaKD8ei7nOLd5+j9+HQygCHTX0gEYvbNf4AjSBbC6yx5sIiK6T1Rf2FlzBrd H47zBoo5/Paqej+tO0gWexqX4W0s3Q5OY7ct97w1t5JkGWMx7mGSrbz28b3zZe3DX/0L m6ysyeVjHRMEehQArhDT09uu4o5IjvniErT8PxxiAAMr5r2swfJ9if/hdfu0ShKXfmlE NpnxNDEson49CYcCA0LUde3J8qwFrGO58OU+pUubUH+3qvCA1usVQ/MeKQA2N7qeZHXh v2fA== MIME-Version: 1.0 X-Received: by 10.112.146.33 with SMTP id sz1mr18214520lbb.14.1377627887359; Tue, 27 Aug 2013 11:24:47 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Tue, 27 Aug 2013 11:24:47 -0700 (PDT) Date: Tue, 27 Aug 2013 13:24:47 -0500 Message-ID: From: Behcet Sarikaya To: "fmc@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3441d0dbd93504e4f1fc7d Cc: Mohamed Boucadair , "Dirk.von-Hugo@telekom.de" Subject: [fmc] Problem Statement X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 18:24:49 -0000 --047d7b3441d0dbd93504e4f1fc7d Content-Type: text/plain; charset=ISO-8859-1 Folks, As we discussed in Berlin meeting (IETF 87) it will be good to draft a document clarifying the issues we discussed in aps Bar BoF, i.e. problem statement draft. Med has kindly agreed to lead this activity and he suggested that the draft should be based on draft-boucadair-intarea-host-identifier-scenarios with the inclusion of the prefix sharing issue. If you would like to work on the problem statement, please send a mail to Med and cc to me and Dirk. Regards, Behcet --047d7b3441d0dbd93504e4f1fc7d Content-Type: text/html; charset=ISO-8859-1
Folks,

As we discussed in Berlin meeting (IETF 87) it will be good to draft a document clarifying the issues we discussed in aps Bar BoF, i.e. problem statement draft.

Med has kindly agreed to lead this activity and he suggested that the draft should be based on
draft-boucadair-intarea-host-identifier-scenarios
with the inclusion of the prefix sharing issue.

If you would like to work on the problem statement, please send a mail to Med and cc to me and Dirk.

Regards,

Behcet

--047d7b3441d0dbd93504e4f1fc7d--