Subject: Re: [DMM] vepc draft Rev. 04

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Jun 2015 14:25:34 -0500

Hi Matsushima-san,

On Fri, May 29, 2015 at 8:24 AM, Satoru Matsushima
<[email-masked]> wrote:
> Hi Behcet-san,
>
> On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya <[email-masked]>
> wrote:
>>
>> Hi Satoru,
>>
>> Thanks for your reply.
>>
>> Let me continue the discussion with your text in Section 3.2 where you
>> mention
>> vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
>> that defines FPCP Agent function and Client function.
>>
>> I don't understand how you could justify defining a new forwarding
>> policy configuration protocol to do this Agent/Client functionality?
>> Why not use similar Agent/Client models that are being defined rather
>> than defining a new protocol?
>> I think this point requires much stronger justification which I could
>> not see in Section 3.2.
>>
>
> The text just describes about a part of where FPCP may be applicable in
> vEPC.
>
>
>
>>
>> Are you that we have to to reinvent the wheel, rather than reusing
>> something that is already available? How are we going to reinvent that
>> wheel also remains to be seen, I think.
>>
>
> Point taken. Which kind of wheel do you have in mind?

 Please check this draft:
https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-02

Regards,

Behcet
> cheers,
> --satoru

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Jun 2015 17:35:41 +0200

Le 29/05/2015 20:21, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message-----
>> From: dmm [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Friday, May 29, 2015 10:59 AM
>> To: Satoru Matsushima
>> Cc: dmm
>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
>>
>> Le 29/05/2015 15:30, Satoru Matsushima a écrit :
>>> Ah OK. thanks.
>>> Slightly off-topic, I think that there is still chance for tethering
>>> with single /64 if it is allocated as a off-link prefix.
>>
>> Yes, there is still such a chance.  But it can not tether more than one
>> single subnet.  Connected vehicles need several subnets.
>
> How would it be if the vehicle received a single prefix, but it could be
> shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting
> be satisfied if it received a shorter prefix from which many /64s
> could be allocated?

Certainly yes.

Each vehicle needs such a shorter-than-64 prefix allocated to it.

For example, an automobile connecting to LTE receives a /62 from the 
operator and makes four /64s out of it: one for its CAN-entertainment, 
one for its CAN-safety, one for its WiFi and one for its Bluetooth.

This is a MUST.

Allocating a single /64 to a vehicle can not accommodate all these 
unbridgeable subnets.

Alex

>
> Thanks - Fred
> [email-masked]
>
>
>>
>> Alex
>>
>>>
>>> But yes, I agree with you.
>>>
>>> cheers,
>>> --satoru
>>>
>>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>      Hi,
>>>
>>>      In addition to what Behcet says.
>>>
>>>      I read the example below.  I think it is just an example, but just
>>>      to make sure.
>>>
>>>      Please - do not allocate /64s to end users in a cellular network.
>>>      Allocate at least /62s to end users.
>>>
>>>      This is to allow the smartphone to perform tethering (small network
>>>      of wifi devices connecting through the smartphone to the Internet).
>>>
>>>      The assumption of /64 to end user is not good at all.
>>>
>>>      (and yes, I agree that these /62s may be aggregated into a larger
>>>      prefix and advertised upstream as a single prefix instead of
>>>      multiple host-based routes).
>>>
>>>      Yours,
>>>
>>>      Alex Petrescu
>>>
>>>      Le 26/05/2015 22:34, Behcet Sarikaya a écrit :
>>>
>>>          Hi Satoru,
>>>
>>>          Thanks for your reply.
>>>
>>>          Let me continue the discussion with your text in Section 3.2
>>>          where you mention
>>>          On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima
>>>          <[email-masked]
>>>          <mailto:[email-masked]>> wrote:
>>>
>>>              Hi Bechet-san,
>>>
>>>              Thank you for your question.
>>>              In step (15), I meant that EPC-E advertises prefix including
>>>              UE assigned
>>>              prefixes.
>>>
>>>              For example, in the case of /64 prefixes assigned to UEs
>>>              from a /56 space,
>>>              that /56
>>>              is advertised by EPC-E to upstream routers. So the
>>>              advertised route isn't
>>>              host routes.
>>>
>>>              Depends on configuration policy, but one case is that the
>>>              source of that
>>>              advertised
>>>              /56 route might be statically configured in EPC-E.
>>>
>>>              Regards,
>>>              --satoru
>>>
>>>
>>>
>>>              On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya
>>>              <[email-masked] <mailto:[email-masked]>>
>>>              wrote:
>>>
>>>
>>>                     Hi Matsushima-san,
>>>
>>>                  I have a question on your draft:
>>>                  In Sec. 3.2, page 11, you say
>>>                  In step (15), the EPC-E advertises routes to upstream
>>>                  routers ...
>>>
>>>                  Are these routes static/host routes?
>>>
>>>                  Regards,
>>>
>>>                  Behcet
>>>
>>>
>>>
>>>
>>>          _______________________________________________
>>>          dmm mailing list
>>>          [email-masked] <mailto:[email-masked]>
>>>          https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>
>>>
>>>
>>>      _______________________________________________
>>>      dmm mailing list
>>>      [email-masked] <mailto:[email-masked]>
>>>      https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>
>>
>>
>> _______________________________________________
>> dmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmm

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jun 2015 03:42:15 +0000

Hi Alex,

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Wednesday, June 03, 2015 8:36 AM
> To: Templin, Fred L; Satoru Matsushima
> Cc: dmm

OK, that is good. Giving a mobile router something shorter than /64
should be no problem, at least up to practical limitations of the prefix
delegation authority's available prefix space. DHCPv6 PD provides all
that is needed to give out right-sized prefixes.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Jun 2015 16:08:38 +0200

> that is needed to give out right-sized prefixes.

I agree DHCP-PD provides the necessary tool.  But unfortunately the 
cellular operators have not deployed DHCPv6-PD (although yes there is 
some DHCP-non-PD in some IPv6/4G deployments).

The common thinking at operators and advisers is still that a /64 should 
be given to an User Equipment.

This must change: the 3GPP specs and operator deployments must give /62 
to UEs, and not /64.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jun 2015 15:10:14 +0000

Hi Alex,

> Sent: Thursday, June 04, 2015 7:09 AM

That is a pity, because DHCPv6 PD (along with IPv6 ND and BGP) are all
that are necessary for distributed mobility management.

> This must change: the 3GPP specs and operator deployments must give /62

Why not a /N instead of just a /62 or /64? N could be anything (62, 60, 56,
48, etc.) as long as it is a proper subset of the prefix space the operator has
available for delegation.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Jun 2015 18:42:51 +0200

Hi Fred,

Le 04/06/2015 17:10, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Thursday, June 04,
>> 2015 7:09 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm
>>>> -----Original Message----- From: Alexandru Petrescu
>>>> [mailto:[email-masked]] Sent: Wednesday, June
>>>> 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm
>>>>>> -----Original Message----- From: dmm
>>>>>> [mailto:[email-masked]] On Behalf Of Alexandru
>>>>>> Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru
>>>>>> Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 -
>>>>>> /62s to UE, not /64s
>>>>>>
>>>>>>> Ah OK. thanks. Slightly off-topic, I think that there is
>>>>>>> still chance for tethering with single /64 if it is
>>>>>>> allocated as a off-link prefix.
>>>>>>
>>>>>> Yes, there is still such a chance.  But it can not tether
>>>>>> more than one single subnet.  Connected vehicles need
>>>>>> several subnets.
>>>>>
>>>>> How would it be if the vehicle received a single prefix, but
>>>>> it could be shorter than /64 (e.g., /56, /48. etc.)? Would
>>>>> the vehicle subnetting be satisfied if it received a shorter
>>>>> prefix from which many /64s could be allocated?
>>>>
>>>> Certainly yes.
>>>>
>>>> For example, an automobile connecting to LTE receives a /62
>>>> from the operator and makes four /64s out of it: one for its
>>>> CAN-entertainment, one for its CAN-safety, one for its WiFi
>>>> and one for its Bluetooth.
>>>>
>>>> This is a MUST.
>>>>
>>>> Allocating a single /64 to a vehicle can not accommodate all
>>>> these unbridgeable subnets.
>>>
>>> OK, that is good. Giving a mobile router something shorter than
>>> /64 should be no problem, at least up to practical limitations
>>> of the prefix delegation authority's available prefix space.
>>> DHCPv6 PD provides all that is needed to give out right-sized
>>> prefixes.
>>
>> cellular operators have not deployed DHCPv6-PD (although yes there
>> is some DHCP-non-PD in some IPv6/4G deployments).
>
> That is a pity, because DHCPv6 PD (along with IPv6 ND and BGP) are
> all that are necessary for distributed mobility management.

I agree.  A dynamic routing protocol like BGP was demonstrated to
feature distributed mobility management on a wide geographical scale.

>> The common thinking at operators and advisers is still that a /64
>> should be given to an User Equipment.
>>
>> This must change: the 3GPP specs and operator deployments must
>> give /62 to UEs, and not /64.
>
> Why not a /N instead of just a /62 or /64? N could be anything (62,
> 60, 56, 48, etc.) as long as it is a proper subset of the prefix
> space the operator has available for delegation.

I agree that in general it's good to be more generic with the prefix length.

But in this particular case we are too generic if we just say '/N'.  The
readers will assume '/64' to be a good example of N, and that is not so.

We can't say 'non-/64' either, because it means too much.

We could say N between /48 and /63 in one bit steps.  But to be clear
that /64 is forbidden.

(I can imagine the pressure that may put on the operatos, but we may
also think there are enough of these addresses and that the pressure is
simply a misunderstanding.)

Alex

>
> Thanks - Fred [email-masked]
>
>> Alex
>>
>>>
>>> Thanks - Fred [email-masked]
>>>
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Thanks - Fred [email-masked]
>>>>>
>>>>>
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> cheers, --satoru
>>>>>>> <[email-masked]
>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I read the example below.  I think it is just an
>>>>>>> example, but just to make sure.
>>>>>>>
>>>>>>> Please - do not allocate /64s to end users in a cellular
>>>>>>> network. Allocate at least /62s to end users.
>>>>>>>
>>>>>>> This is to allow the smartphone to perform tethering
>>>>>>> (small network of wifi devices connecting through the
>>>>>>> smartphone to the Internet).
>>>>>>>
>>>>>>> (and yes, I agree that these /62s may be aggregated into
>>>>>>> a larger prefix and advertised upstream as a single
>>>>>>> prefix instead of multiple host-based routes).
>>>>>>>
>>>>>>> Yours,
>>>>>>>
>>>>>>> Alex Petrescu
>>>>>>>
>>>>>>> Let me continue the discussion with your text in Section
>>>>>>> 3.2 where you mention vEPC may utilizes Forwarding
>>>>>>> Policy Configuration Protocol (FPCP) that defines FPCP
>>>>>>> Agent function and Client function.
>>>>>>>
>>>>>>> I don't understand how you could justify defining a new
>>>>>>> forwarding policy configuration protocol to do this
>>>>>>> Agent/Client functionality? Why not use similar
>>>>>>> Agent/Client models that are being defined rather than
>>>>>>> defining a new protocol? I think this point requires
>>>>>>> much stronger justification which I could not see in
>>>>>>> Section 3.2.
>>>>>>>
>>>>>>> Are you that we have to to reinvent the wheel, rather
>>>>>>> than reusing something that is already available? How
>>>>>>> are we going to reinvent that wheel also remains to be
>>>>>>> seen, I think.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Behcet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thank you for your question. In step (15), I meant that
>>>>>>> EPC-E advertises prefix including UE assigned prefixes.
>>>>>>>
>>>>>>>  from a /56 space, that /56 is advertised by EPC-E to
>>>>>>> upstream routers. So the advertised route isn't host
>>>>>>> routes.
>>>>>>>
>>>>>>> source of that advertised /56 route might be statically
>>>>>>> configured in EPC-E.
>>>>>>>
>>>>>>> Regards, --satoru
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I have a question on your draft: In Sec. 3.2, page 11,
>>>>>>> you say In step (15), the EPC-E advertises routes to
>>>>>>> upstream routers ...
>>>>>>>
>>>>>>> _______________________________________________ dmm
>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>>> _______________________________________________ dmm
>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>> _______________________________________________ dmm
>>>>>> mailing list [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Jun 2015 17:08:00 +0000

Hi Alex,

> Sent: Monday, June 08, 2015 9:43 AM

What I was thinking was that users could pay for different classes of service.
Basic service could be a /64 (or /63 or /62). Premium service could be a /60.
Super-premium could be a /56, etc.

Point being that the mechanism should support any prefix delegation
size that the user has contracted with the service provider for; not
just a fixed one-size-fits-all size for all users.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Jun 2015 16:58:27 +0200

Fred,

Le 08/06/2015 19:08, Templin, Fred L a écrit :
[...]

>>>> The common thinking at operators and advisers is still that a
>>>> /64 should be given to an User Equipment.
>>>>
>>> Why not a /N instead of just a /62 or /64? N could be anything
>>> (62, 60, 56, 48, etc.) as long as it is a proper subset of the
>>> prefix space the operator has available for delegation.
>>
>> But in this particular case we are too generic if we just say '/N'.
>> The readers will assume '/64' to be a good example of N, and that
>> is not so.
>>
>> We could say N between /48 and /63 in one bit steps.  But to be
>> clear that /64 is forbidden.
>>
>> (I can imagine the pressure that may put on the operatos, but we
>> may also think there are enough of these addresses and that the
>> pressure is simply a misunderstanding.)
>
> What I was thinking was that users could pay for different classes of
> service. Basic service could be a /64 (or /63 or /62). Premium
> service could be a /60. Super-premium could be a /56, etc.

Well it looks like a good idea.  It is a bit new compared to IPv4 in
cellular networks (there is no concept of premium service delivery of
several IPv4 addresses per single device, and there is no StdsTrack PD
for DHCPv4).  Do you think cellular operators may create such new
payment schemes for classes of service in IPv6?  Or rather migrate the
existing IPv4 payment schemes from IPv4 - a one to one mapping between
concepts, modulo the address length being bigger?

> just a fixed one-size-fits-all size for all users.

I agree - the mechanism is there.

Why the cellular operators dont respond to DHCPv6 Prefix Delegation
requests from the User Equipments?

Alex

>>>>>>>>> Please - do not allocate /64s to end users in a
>>>>>>>>> cellular network. Allocate at least /62s to end
>>>>>>>>> users.
>>>>>>>>>
>>>>>>>>> (small network of wifi devices connecting through
>>>>>>>>> the smartphone to the Internet).
>>>>>>>>>
>>>>>>>>> (and yes, I agree that these /62s may be aggregated
>>>>>>>>> into a larger prefix and advertised upstream as a
>>>>>>>>> single prefix instead of multiple host-based
>>>>>>>>> routes).
>>>>>>>>>
>>>>>>>>> Yours,
>>>>>>>>>
>>>>>>>>> Alex Petrescu
>>>>>>>>>
>>>>>>>>> Let me continue the discussion with your text in
>>>>>>>>> Section 3.2 where you mention vEPC may utilizes
>>>>>>>>> Forwarding Policy Configuration Protocol (FPCP) that
>>>>>>>>> defines FPCP Agent function and Client function.
>>>>>>>>>
>>>>>>>>> I don't understand how you could justify defining a
>>>>>>>>> new forwarding policy configuration protocol to do
>>>>>>>>> this Agent/Client functionality? Why not use similar
>>>>>>>>> Agent/Client models that are being defined rather
>>>>>>>>> than defining a new protocol? I think this point
>>>>>>>>> requires much stronger justification which I could
>>>>>>>>> not see in Section 3.2.
>>>>>>>>>
>>>>>>>>> Are you that we have to to reinvent the wheel,
>>>>>>>>> rather than reusing something that is already
>>>>>>>>> available? How are we going to reinvent that wheel
>>>>>>>>> also remains to be seen, I think.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Behcet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you for your question. In step (15), I meant
>>>>>>>>> that EPC-E advertises prefix including UE assigned
>>>>>>>>> prefixes.
>>>>>>>>>
>>>>>>>>> For example, in the case of /64 prefixes assigned to
>>>>>>>>> UEs from a /56 space, that /56 is advertised by EPC-E
>>>>>>>>> to upstream routers. So the advertised route isn't
>>>>>>>>> host routes.
>>>>>>>>>
>>>>>>>>> Depends on configuration policy, but one case is that
>>>>>>>>> the source of that advertised /56 route might be
>>>>>>>>> statically configured in EPC-E.
>>>>>>>>>
>>>>>>>>> Regards, --satoru
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <[email-masked]
>>>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Matsushima-san,
>>>>>>>>>
>>>>>>>>> I have a question on your draft: In Sec. 3.2, page
>>>>>>>>> 11, you say In step (15), the EPC-E advertises routes
>>>>>>>>> to upstream routers ...
>>>>>>>>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 9 Jun 2015 16:26:00 +0000

Hi Alex,

> Sent: Tuesday, June 09, 2015 7:58 AM

I don't know much about the cellular operator business. I am confident
AERO would be a good fit for that environment, but I have been more
focused on enterprise networks, aviation networks, unmanned air
system networks, etc.

Taking aviation for example, I believe that airplanes will have many
onboard addressable devices and networks. So, a /56 (or possibly even
more) might be a natural prefix delegation unit for each airplane.

> I agree - the mechanism is there.

OK.

> requests from the User Equipments?

I don't know why - it is really easy to set up, and a natural way to get
an arbitrary-length prefix delegation to the UE.

Thanks - Fred

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 11 Jun 2015 09:02:40 -0700

> This must change: the 3GPP specs and operator deployments must give /62

I think we are not in the position to force operators or 3GPP to do 
anything, unfortunately. The best we can do is to make sure the 
protocols we work here in IETF are not prohibiting better deployments 
(see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here.

I know this is frustrating. For example some operators I know offer IPv6 
PD on their fixed side of business but have no plans for similar on the 
cellular side.. reasons are many. I assume that identofying a strong 
enough use case would be the key.

- Jouni

>>>>>> 3.2
>>>>>> forwarding
>>>>>>           Why not use similar Agent/Client models that are being
>>>>>> defined
>>>>>>           rather
>>>>>>           I think this point requires much stronger justification
>>>>>> which I
>>>>>>           could
>>>>>>           not see in Section 3.2.
>>>>>>
>>>>>> than reusing
>>>>>> UEs

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2015 18:19:28 +0200

> enough use case would be the key.

I would like to discuss these use cases.

Use cases of grouping devices under a unique cellular connection are 
very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things 
on Personal Area Networks.

All these devices need the cellular operator to deliver shorter-than-64 
prefixes to a SIM connection.

Alex

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 11 Jun 2015 09:46:56 -0700

Alexandru Petrescu wrote:
> >>>>>>> Slightly off-topic, I think that there is still chance for
> >>>>>>> tethering with single /64 if it is allocated as a off-link prefix.
> >>>>>>
> >>>>>> Yes, there is still such a chance.  But it can not tether more
> >>>>>> than one single subnet.  Connected vehicles need several subnets.
> >>>>>
> >>>>> How would it be if the vehicle received a single prefix, but it
> >>>>> could be shorter than /64 (e.g., /56, /48. etc.)? Would the
> >>>>> vehicle subnetting be satisfied if it received a shorter prefix
> >>>>> from which many /64s could be allocated?
> >>>>
> >>>> Certainly yes.
> >>>>
> >>>> For example, an automobile connecting to LTE receives a /62 from
> >>>> the operator and makes four /64s out of it: one for its
> >>>> CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its
> Bluetooth.
> >>>>
> >>>> This is a MUST.
> >>>>
> >>> should be no problem, at least up to practical limitations of the
> >>> prefix delegation authority's available prefix space. DHCPv6 PD
> >>> provides all that is needed to give out right-sized prefixes.
> >>
> >> This must change: the 3GPP specs and operator deployments must give
> >> /62 to UEs, and not /64.
> >
> > I know this is frustrating. For example some operators I know offer
> > IPv6 PD on their fixed side of business but have no plans for similar
> > on the cellular side.. reasons are many. I assume that identofying a
> > strong enough use case would be the key.
> 
> Use cases of grouping devices under a unique cellular connection are very
> numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on
> Personal Area Networks.
> 
> All these devices need the cellular operator to deliver shorter-than-64 prefixes
> to a SIM connection.

For lack of a better description, the cellular side of businesses suffer from "bell head:" thinking, where the UE is an application endpoint. Nothing more occurs to them, because that is the product they have always supported. A routing function implies higher aggregate data rates than they have built the system to handle. I have been in front of many of them holding up UE and saying, "this is a ROUTER, get over it", and got nothing but blank stares back. 

The first use case on the list should be a wireline alternative/backup link for consumer CPE routers, and home control or security systems. That is simpler to support because the UE doesn't move around, so they can scale the infrastructure to align with demand without too much concern about that shifting quickly. Once the fear of downstream subnets is removed, working on the truly mobile use cases will be an easier mental hurdle to overcome. 

Tony

...........

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jun 2015 16:53:29 +0000

Responding to two in one:

> From: dmm [mailto:[email-masked]] On Behalf Of Tony Hain
> Sent: Thursday, June 11, 2015 9:47 AM
> To: 'Alexandru Petrescu'; 'Jouni Korhonen'; [email-masked]

Yes, yes and yes. Also IPv6 airplanes.

> For lack of a better description, the cellular side of businesses suffer from "bell head:" thinking, where the UE is an application
> endpoint. Nothing more occurs to them, because that is the product they have always supported. A routing function implies higher
> aggregate data rates than they have built the system to handle. I have been in front of many of them holding up UE and saying, "this is
> a ROUTER, get over it", and got nothing but blank stares back.

Indeed. But, this is the ongoing dialogue that we need to continue no
matter how many blank stares we get.

Thanks - Fred

> The first use case on the list should be a wireline alternative/backup link for consumer CPE routers, and home control or security
> systems. That is simpler to support because the UE doesn't move around, so they can scale the infrastructure to align with demand
> without too much concern about that shifting quickly. Once the fear of downstream subnets is removed, working on the truly mobile
> use cases will be an easier mental hurdle to overcome.
> 
> Tony
> 
> ...........
>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 11 Jun 2015 12:21:52 -0700

For lack of a better description, the cellular side of businesses suffer
> from "bell head:" thinking, where the UE is an application endpoint.
> Nothing more occurs to them, because that is the product they have always
> supported. A routing function implies higher aggregate data rates than they
> have built the system to handle. I have been in front of many of them
> holding up UE and saying, "this is a ROUTER, get over it", and got nothing
> but blank stares back.
>
> The first use case on the list should be a wireline alternative/backup
> link for consumer CPE routers, and home control or security systems. That
> is simpler to support because the UE doesn't move around, so they can scale
> the infrastructure to align with demand without too much concern about that
> shifting quickly. Once the fear of downstream subnets is removed, working
> on the truly mobile use cases will be an easier mental hurdle to overcome.
>

Amen.

I know that such backup solutions with routed IPv4 networks were done for
enterprise access (not a standard but easily doable).

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2015 15:02:20 +0200

I was asked in private about this "SIM connection", I clarify below.

Le 11/06/2015 18:19, Alexandru Petrescu a écrit :
>>>>>>>> tethering
>>>>>> could be
>>>> prefix

I meant to say a device holding a single SIM card should be able to get 
a shorter-than-64 prefix from the cellular operator.

This is to distinguish from computers featuring multiple SIM cards, or 
automobiles featuring multiple SIMs (car's SIM, passengers' SIMs).

SIM stands for Subscriber Identification Module.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2015 15:03:24 +0200

Le 11/06/2015 18:53, Templin, Fred L a écrit :
>> -----Original Message----- From: dmm [mailto:[email-masked]]
>> On Behalf Of Tony Hain Sent: Thursday, June 11, 2015 9:47 AM To:
>> 'Alexandru Petrescu'; 'Jouni Korhonen'; [email-masked] Subject: Re:
>> [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
>>
>>>>>>> [mailto:[email-masked]] Sent: Wednesday,
>>>>>>> June 03, 2015 8:36 AM To: Templin, Fred L; Satoru
>>>>>>> Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04
>>>>>>> - /62s to UE, not /64s
>>>>>>>
>>>>>>>>> Petrescu Sent: Friday, May 29, 2015 10:59 AM To:
>>>>>>>>> Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc
>>>>>>>>> draft Rev. 04 - /62s to UE, not /64s
>>>>>>>>>
>>>>>>>>>> Ah OK. thanks. Slightly off-topic, I think that
>>>>>>>>>> there is still chance for tethering with single /64
>>>>>>>>>> if it is allocated as a off-link prefix.
>>>>>>>>>
>>>>>>>>> Yes, there is still such a chance.  But it can not
>>>>>>>>> tether more than one single subnet.  Connected
>>>>>>>>> vehicles need several subnets.
>>>>>>>>
>>>>>>>> How would it be if the vehicle received a single
>>>>>>>> prefix, but it could be shorter than /64 (e.g., /56,
>>>>>>>> /48. etc.)? Would the vehicle subnetting be satisfied
>>>>>>>> if it received a shorter prefix from which many /64s
>>>>>>>> could be allocated?
>>>>>>>
>>>>>>> Certainly yes.
>>>>>>>
>>>>>>> For example, an automobile connecting to LTE receives a
>>>>>>> /62 from the operator and makes four /64s out of it: one
>>>>>>> for its CAN-entertainment, one for its CAN-safety, one
>>>>>>> for its WiFi and one for its
>>> Bluetooth.
>>>>>>>
>>>>>>> This is a MUST.
>>>>>>>
>>>>>>> Allocating a single /64 to a vehicle can not accommodate
>>>>>>> all these unbridgeable subnets.
>>>>>>
>>>>>> OK, that is good. Giving a mobile router something shorter
>>>>>> than /64 should be no problem, at least up to practical
>>>>>> limitations of the prefix delegation authority's available
>>>>>> prefix space. DHCPv6 PD provides all that is needed to give
>>>>>> out right-sized prefixes.
>>>>>
>>>>> I agree DHCP-PD provides the necessary tool.  But
>>>>> unfortunately the cellular operators have not deployed
>>>>> DHCPv6-PD (although yes there is some DHCP-non-PD in some
>>>>> IPv6/4G deployments).
>>>>>
>>>>> This must change: the 3GPP specs and operator deployments
>>>>> must give /62 to UEs, and not /64.
>>>>
>>>> I think we are not in the position to force operators or 3GPP
>>>> to do anything, unfortunately. The best we can do is to make
>>>> sure the protocols we work here in IETF are not prohibiting
>>>> better deployments (see e.g. RFC6603 effort). 3GPP specs are
>>>> not the show stoppers here.
>>>>
>>>> I know this is frustrating. For example some operators I know
>>>> offer IPv6 PD on their fixed side of business but have no plans
>>>> for similar on the cellular side.. reasons are many. I assume
>>>> that identofying a strong enough use case would be the key.
>>>
>>> Use cases of grouping devices under a unique cellular connection
>>> are very numerous: IPv6 automobiles, IPv6 tethering smartphones,
>>> IPv6 Things on Personal Area Networks.
>

What is the use case when an airplane connects to a cellular operator?
They are supposed to be on sattelite often, I guess.

Alex

>
>>> All these devices need the cellular operator to deliver
>>> shorter-than-64 prefixes to a SIM connection.
>>
>> For lack of a better description, the cellular side of businesses
>> suffer from "bell head:" thinking, where the UE is an application
>> endpoint. Nothing more occurs to them, because that is the product
>> they have always supported. A routing function implies higher
>> aggregate data rates than they have built the system to handle. I
>> have been in front of many of them holding up UE and saying, "this
>> is a ROUTER, get over it", and got nothing but blank stares back.
>
> Indeed. But, this is the ongoing dialogue that we need to continue
> no matter how many blank stares we get.
>
>> The first use case on the list should be a wireline
>> alternative/backup link for consumer CPE routers, and home control
>> or security systems. That is simpler to support because the UE
>> doesn't move around, so they can scale the infrastructure to align
>> with demand without too much concern about that shifting quickly.
>> Once the fear of downstream subnets is removed, working on the
>> truly mobile use cases will be an easier mental hurdle to
>> overcome.
>>
>> Tony
>>
>> ...........
>>
>> _______________________________________________ dmm mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jun 2015 15:24:25 +0000

Hi Alex,

> Sent: Friday, June 12, 2015 6:03 AM
> To: Templin, Fred L; Tony Hain; 'Jouni Korhonen'; [email-masked]

Airplanes have lots of links - some satellite yes, but there are also
cellular link types such as this:

http://aircell.com/

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2015 17:53:26 +0200

Hi Fred,

> cellular link types such as this:

That is a cellular link on-board of a plane, I think.  Maybe it requires 
a shorter-than-64 prefix from the satellite operator...

But is there a use-case with plane that connects to a cellular network 
while taxiing ?  I.e. slow speed, spend 1hour on the tarmac, connect the 
plane to Verizon, give passengers free WiFi to smartphones so use 
Internet to announce safe landing.

This latter certainly requires a shorter-than-64 prefix from the 
cellular operator.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jun 2015 16:16:23 +0000

Hi Alex,

> Sent: Friday, June 12, 2015 8:53 AM

Last I checked, Gogo/Aircell is based on a cellular ground network and
gives passengers on board an Internet-capable WiFi service. Aircell also
offers satcom services including Inmarsat and Iridium, but I was referring
to the ground-based cellular network.

> Internet to announce safe landing.

My understanding is that passenger-domain communications are
only above 10Kft. However, Air Traffic Control domain has things
like gatelink WiFi, AEROMACS, etc. in the terminal and ground
domain area.

Think of aircraft as having (at least) three distinct communication
domains - Air Traffic Control (ATC), Airline Operations Control
(AOC) and Passenger In-flight Entertainment (PIES). Obviously,
the passenger domain needs to be kept separate from the
safety-of-flight-critical domains.

Thanks - Fred

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 25 Jun 2015 19:22:46 +0900

Hi Behcet,

Sorry for my late response.

As I looked over your dmm-for-wifi draft, I found two protocols to be used
to separate
control and data plane such as XMPP and OpenFlow.

It seems like you want to work on that protocols to be implemented in data
plane nodes.
OpenFlow is another forum controlled protocol so I don't touch it in the
IETF.
XMPP sounds nice. If you adopt XMPP with same model of
draft-ietf-l3vpn-end-system,
it almost same with using BGP like the vEPC draft.

But what I mentioned FPCP in vEPC is as a way to export mobility info to
BGP speaker
from control-plane nodes of mobility management.

And more, many parameters should be aligned for these nodes to utilizing
data-plane
network so that the config data model should also be defined in FPCP. I
think that's not
part of signaling protocol roles.

Thought?

Regards,
--satoru

On Wed, Jun 3, 2015 at 4:25 AM, Behcet Sarikaya <[email-masked]>
wrote:

> > On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya <[email-masked]
> >
> > wrote:
> >>
> >> Hi Satoru,
> >>
> >> Thanks for your reply.
> >>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 29 Jun 2015 11:24:09 -0500

Hi Satoru,

Thank you for your comments.
My replies inline.

Regards,

Behcet

> it almost same with using BGP like the vEPC draft.

Wait a minute, there is more.
It seems like you have not read Sections 4.2 and 4.3.
Yes, XMPP and OpenFlow are for Section 4.1 for switch control on
mobile backhaul.
This is related to a university project we were involved which used
public domain OpenFlow tools like OpenDayLight.

In route establishment, I am using Netconf or RPC protocol which you
missed big and that was one of the main additions in Rev. 02.
Please check it again.

> But what I mentioned FPCP in vEPC is as a way to export mobility info to BGP
> speaker

As I said in my mail before, I wonder why we need all those things?
Why do we need another client/server system maybe other than what i2rs
is defining?
I think this is a big question FPCP lovers should answer? My point is
that at least you should not need it in vEPC, I am saying that as
someone who supports vEPC :-)

> Thought?

Another main addition is Rev. 02 was Section 5 on multicast support
which you missed or not commented?

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 30 Jun 2015 17:21:28 +0900

Behcet,

On Tue, Jun 30, 2015 at 1:24 AM, Behcet Sarikaya <[email-masked]>
wrote:

-- snip --

> missed big and that was one of the main additions in Rev. 02.

Wow, thanks. I had overlooked it.
I had jumped to conclusions when I read section 4.1 that cover not only L2
but also L3 hand-over.
I couldn't imagine that each layer has different technique for hand-over.
Why is that?

I want to clarify one thing on your drat. Sec 4.3 in the draft mentions
that i2rs agent as netconf client but it is opposite
as far as I know. Am I wrong?

> BGP

AFAIK, FPCP design is alined with i2rs architecture so that it has the
data-model with yang schema based on its information model of data-plane
node abstraction (Marco's idea) but currently it's an appendix. The
information model would make clear what are the mobility specific things
that might augment i2rs model. If nothing, there's no need to define it,
yes. As a co-author of FPCP, you are welcome to review the parameters which
FPCP defined whether each of those are really needed or not.

> which you missed or not commented?

Cool.
Does mobile node really need multicast? Is there any document that justify
for that?

cheers,
--satoru