Subject: Re: [5gangip] PS draft draft-hspab-5gangip-atticps-00.txt

From: <[email-masked]>
Date: Thu, 1 Feb 2018 11:40:20 +0000

Dear Dino, all,
ok!
what do you think of the following:
Motivation: Tunneling today is well established, but may create too much overhead and hide important information required for service-specific handling
Proposal: We think that an Id-Loc split approach could help here, but may create issues as e.g. missing anchor for charging, policy enforcement etc. - and needs additional measures to e.g. enable optimal route selection (as pointed out already by Arash: doesn't come automatically ...)
Work plan:
To investigate we choose well established GTP tunnel protocol by 3GPP
By documenting in first step 'GTP over IPv6' we can detect all features provided by GTP in order to include them in the additional measures for Id-Loc split approach
At the same time the requirements to chosen ID-Loc split approach have to be consolidated
Final goal should be to propose a complete framework for Id-Loc split protocol with all extensions to replace GTP
This can be compared then to GTP in terms of performance and effort etc.

The full list may be too much for an IETF project but shall aim at what could come out as benefit for 3GPP.
But we could just start with the first step which is what Alex proposed (document usage of GTP over IPv6 as I-D).

What do you think? 
Best Regards
Dirk 

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Mittwoch, 31. Januar 2018 23:52
To: [email-masked]
Cc: 5GANGIP <[email-masked]>; von Hugo, Dirk <[email-masked]>
Subject: Re: [5gangip] PS draft draft-hspab-5gangip-atticps-00.txt

My opinion is to select the problem with the lowest hanging fruit. Focus on that and push it to 3GPP. And do it ultra fast.

Dino

> On Jan 31, 2018, at 2:29 PM, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi all,
> 
> We got the feedback from our AD that we need to narrow down the problem scope and work on this narrower set for BOF proposal.
> 
> Please help us identify the narrow scope that you want to specifically work on. We can not solve all 5G problems in one shot.
> 
> We need everybody's opinon, please let us know what you think.
> 
> Regards,
> Dirk& Behcet
> 
> On Mon, Jan 29, 2018 at 2:39 PM, Behcet Sarikaya <[email-masked]> wrote:
> Hi all,
> Dirk and I submitted this PS draft. 
> We need this to be discussed and improved. Please read and comment.
> Also we are soliciting co-authors, please let us know.
> 
> Regards,
> Dirk & Behcet
> 
> 
> A new version of I-D, draft-hspab-5gangip-atticps-00.txt
> has been successfully submitted by Behcet Sarikaya and posted to the 
> IETF repository.
> 
> Name:           draft-hspab-5gangip-atticps
> Revision:       00
> Title:          IP Issues and Associated Gaps in Fifth Generation Wireless Networks
> Document date:  2018-01-28
> Group:          Individual Submission
> Pages:          7
> URL:            https://www.ietf.org/internet-drafts/draft-hspab-5gangip-atticps-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/
> Htmlized:       https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hspab-5gangip-atticps-00
> 
> 
> Abstract:
>    This document attempts to make the case for new work that need to be
>    developed to be used among various virtualized functions and the end
>    user which may be moving.  First a set of use cases on tunneling,
>    charging, mobility anchors are developed and then the steps of
>    proposed new work is described next.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip

---

From: Ca By <[email-masked]>
Date: Thu, 01 Feb 2018 14:51:26 +0000

On Thu, Feb 1, 2018 at 3:40 AM <[email-masked]> wrote:

> Motivation: Tunneling today is well established, but may create too much
> overhead and hide important information required for service-specific
> handling

I would be specific about what overhead you believe you can optimize. If
you are talking about bits of ip encapsulation, the cost you are saving a
network operator is near zero by removing x bytes per packet at busy hour.

If you are eliminating signalling and eliminate tracked state (not
reshuffling and renaming state stores), there may be something interesting.

> Proposal: We think that an Id-Loc split approach could help here, but may
> create

Would be good to say which principles you believe lead to id-loc split
being advantageous

issues as e.g. missing anchor for charging, policy enforcement etc. - and
> needs additional measures to e.g. enable optimal route selection (as
> pointed out already by Arash: doesn't come automatically ...)
> Work plan:
> By documenting in first step 'GTP over IPv6' we

This is already documented by 3gpp. Be specific why want to redocument it.

can detect all features provided by GTP in order to include them in the
> additional measures for Id-Loc split approach
> Final goal should be to propose a complete framework for Id-Loc split
> protocol with all extensions to replace GTP

Thanks for being specific in the goal to replace gtp. Please define the
metrics that will be used for comparison. This should include interop and
migration plan for existing networks.

> But we could just start with the first step which is what Alex proposed
> (document usage of GTP over IPv6 as I-D).
>
> What do you think?
> Best Regards
> Dirk
>
> My opinion is to select the problem with the lowest hanging fruit. Focus
> on that and push it to 3GPP. And do it ultra fast.
>
> Dino
>
> > We got the feedback from our AD that we need to narrow down the problem
> scope and work on this narrower set for BOF proposal.
> >
> > Please help us identify the narrow scope that you want to specifically
> work on. We can not solve all 5G problems in one shot.
> >
> > URL:
> https://www.ietf.org/internet-drafts/draft-hspab-5gangip-atticps-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/
> > Htmlized:
> https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hspab-5gangip-atticps-00
> >
> >
> > Abstract:

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 1 Feb 2018 09:27:59 -0600

Hi Cameron,

> migration plan for existing networks.
What do you think about having this point too:

Arashmid]

The choice of ID-LOC data path on its own cannot guarantee UE packets
reaching their optimal UPF.

IMO the way we map IDs to LOCs, ID-LOC mapping record constructs and the
way we distribute this info. is what allows packets from different UEs to
reach their respective optimal UPF.

I copied from Arash's previous mail?

Thanks,

Behcet

>> > URL:            https://www.ietf.org/internet-
>> drafts/draft-hspab-5gangip-atticps-00.txt

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Feb 2018 11:28:23 -0800

I think you are adding zero value with this proposal. Today GTP is used and the UE’s IP addresses are not in EPC routing, so you have ID/LOC split already.

The low-hanging fruit IMO that could be useful work items (of value0 are:

(1) Newer ID/Loc split mechanisms can give you shortest paths. And it doesn’t matter which transport you use. All of GTP, LISP. ILA, ILNP can be used.

(2) Then we spec out how you do the mapping control-plane.

Dino

> On Feb 1, 2018, at 3:40 AM, [email-masked] wrote:
> 
> Dear Dino, all,
> ok!

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Feb 2018 23:28:25 +0100

Le 01/02/2018 à 15:51, Ca By a écrit :
> 
> On Thu, Feb 1, 2018 at 3:40 AM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Dear Dino, all,
>     ok!
>     Motivation: Tunneling today is well established, but may create too
>     much overhead and hide important information required for
>     service-specific handling
> 
> 
> you are talking about bits of ip encapsulation, the cost you are saving 
> a network operator is near zero by removing x bytes per packet at busy 
> hour.
> 
>     Proposal: We think that an Id-Loc split approach could help here,
>     but may create 
> 
> 
>     issues as e.g. missing anchor for charging, policy enforcement etc.
>     - and needs additional measures to e.g. enable optimal route
>     selection (as pointed out already by Arash: doesn't come
>     automatically ...)
>     Work plan:

Maybe some clarifications could be made in an Internet Draft, 
clarification that cant be made into a 3GPP document.

Why would one think we should _not_ document GTP at IETF?

Alex

> 
>     can detect all features provided by GTP in order to include them in
>     the additional measures for Id-Loc split approach
>     Final goal should be to propose a complete framework for Id-Loc
>     split protocol with all extensions to replace GTP
> metrics that will be used for comparison. This should include interop 
> and migration plan for existing networks.
> 
> 
>     But we could just start with the first step which is what Alex
>     proposed (document usage of GTP over IPv6 as I-D).
> 
>     What do you think?
>     Best Regards
>     Dirk
> 
>     From: Dino Farinacci [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     To: [email-masked] <mailto:[email-masked]>
>     Cc: 5GANGIP <[email-masked] <mailto:[email-masked]>>; von Hugo,
>     Dirk <[email-masked] <mailto:[email-masked]>>
>     My opinion is to select the problem with the lowest hanging fruit.
>     Focus on that and push it to 3GPP. And do it ultra fast.
> 
>     Dino
> 
>      > On Jan 31, 2018, at 2:29 PM, Behcet Sarikaya
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      > Hi all,
>      >
>      > We got the feedback from our AD that we need to narrow down the
>     problem scope and work on this narrower set for BOF proposal.
>      >
>      > Please help us identify the narrow scope that you want to
>     specifically work on. We can not solve all 5G problems in one shot.
>      >
>      > On Mon, Jan 29, 2018 at 2:39 PM, Behcet Sarikaya
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      > Hi all,
>      > submission until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>      >
>      > The IETF Secretariat
>      >
>      >
>      >
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 2 Feb 2018 08:08:28 +0000

+1

by the way, an amusing use of tunnels i like is that if i roam my european
data service into a country that blocs various IP services (may be for
perfectly good reasons) I can (for example) continue to post pictures on
facebook in beijing, because a) its obvious I am from another country and
b) the local provider is making a shed load of moeny out of me and c) it'd
be really quite hard for them to selectively block what i can and can't
reach compared with a native IP level device in that region - this is a
feature from everyone's point of view, despite the hideous inefficiecncy of
the route when i actually want to use a local service:)

On Thu, Feb 1, 2018 at 7:28 PM, Dino Farinacci <[email-masked]> wrote:

> I think you are adding zero value with this proposal. Today GTP is used
> and the UE’s IP addresses are not in EPC routing, so you have ID/LOC split
> already.
>
> (1) Newer ID/Loc split mechanisms can give you shortest paths. And it
> doesn’t matter which transport you use. All of GTP, LISP. ILA, ILNP can be
> used.
>
> > Proposal: We think that an Id-Loc split approach could help here, but
> may create issues as e.g. missing anchor for charging, policy enforcement
> etc. - and needs additional measures to e.g. enable optimal route selection
> (as pointed out already by Arash: doesn't come automatically ...)
> > Work plan:
> > By documenting in first step 'GTP over IPv6' we can detect all features
> provided by GTP in order to include them in the additional measures for
> Id-Loc split approach
> > Cc: 5GANGIP <[email-masked]>; von Hugo, Dirk <[email-masked]
> >
> tools.ietf.org.

---

From: David Allan I <[email-masked]>
Date: Fri, 2 Feb 2018 13:59:53 +0000

Hi Alexandre,

You wrote:

<snipped>

Maybe some clarifications could be made in an Internet Draft, clarification that cant be made into a 3GPP document.

DA> If this is informational, like RFCs 6459 which appears to be purely tutorial, and/or addresses some unfulfilled gap in understanding, then perhaps. If it is any sort of attempt at a normative document, and therefore claiming change control on the protocol I cannot see that ending well.  
As 3GPP documents are public, and simply participating on this list likely demonstrates a minimum level of literacy and ability to access the internet where these documents are available, what do we think is missing that the IETF should be stepping in to address?

In the interest of full disclosure, I do not attend 3GPP, I am simply familiar with inter-SDO dynamics, and have endured a few turf wars in my time.

My 2 cents 
Dave

> Thanks for being specific in the goal to replace gtp. Please define 
> the metrics that will be used for comparison. This should include 
> interop and migration plan for existing networks.
> 
>

---

From: <[email-masked]>
Date: Fri, 2 Feb 2018 15:22:19 +0000

Dear all
Thanks! I fully agree that our GTP draft would only be informational - as pointed out in the BoF idea on the list one outcome should be to identify features which should be covered by the Id-Loc approach extensions ...
Best Regards
Dirk 
-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Freitag, 2. Februar 2018 15:00
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [5gangip] PS draft draft-hspab-5gangip-atticps-00.txt

Hi Alexandre,

You wrote:

<snipped>

My 2 cents
Dave

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 2 Feb 2018 10:26:59 -0800

Exactly right. You keep your identity no matter where and how you are connected to the network. 

Dino

> On Feb 2, 2018, at 7:22 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Dear all

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 4 Feb 2018 18:47:30 +0100

Le 02/02/2018 à 14:59, David Allan I a écrit :
> DA> If this is informational,

I think yes, informational.

It would be INFORMATIONAL at IETF.

If it existed, I wonder how would 3GPP qualify it in _their_ terms(?).

> like RFCs 6459 which appears to be purely tutorial, and/or addresses
> some unfulfilled gap in understanding, then perhaps. If it is any
> sort of attempt at a normative document, and therefore claiming
> change control on the protocol I cannot see that ending well.

Well.  I see the current situation to not be well.

> As 3GPP documents are public,

Last time I downloaded a 3GPP document it was a ZIP document.  I did not 
have a ZIP reader on my computer.  When installing one I was told about 
patents on it, something like jpeg-vs-png.

Then, it was a Word document.  That again, same thing.

This is why I would like to ask you: what do you mean by 'public'?

Is it as 'public' as downloading an Internet Draft?

> and simply participating on this list
> likely demonstrates a minimum level of literacy and ability to access
> the internet where these documents are available, what do we think is
> missing that the IETF should be stepping in to address?

The answer to that question would be better once there is an idea of 
what Internet Draft titled "GTP" can look like.

> In the interest of full disclosure, I do not attend 3GPP, I am simply
> familiar with inter-SDO dynamics, and have endured a few turf wars in
> my time.

Thank you for the disclosure.

It is good that on this list there are people who do not attend 3GPP, 
and people who attend 3GPP, and people who can liaise between SDOs.

For my part, I do not attend 3GPP.

Alex

> 
> My 2 cents Dave
> 
>> 
>> can detect all features provided by GTP in order to include them
>> in the additional measures for Id-Loc split approach At the same
>> time the requirements to chosen ID-Loc split approach have to be
>> consolidated Final goal should be to propose a complete framework
>> for Id-Loc split protocol with all extensions to replace GTP This
>> can be compared then to GTP in terms of performance and effort
>> etc.
>> 
>> 
>> Thanks for being specific in the goal to replace gtp. Please
>> define the metrics that will be used for comparison. This should
>> include interop and migration plan for existing networks.
>> 
>> 
>> The full list may be too much for an IETF project but shall aim at 
>> what could come out as benefit for 3GPP. But we could just start
>> with the first step which is what Alex proposed (document usage of
>> GTP over IPv6 as I-D).
>> 
>> What do you think? Best Regards Dirk
>> 
>> -----Original Message----- From: Dino Farinacci
>> [mailto:[email-masked] <mailto:[email-masked]>] Sent:
>> Mittwoch, 31. Januar 2018 23:52 To: [email-masked]
>> <mailto:[email-masked]> Cc: 5GANGIP <[email-masked]
>> <mailto:[email-masked]>>; von Hugo, Dirk
>> <[email-masked] <mailto:[email-masked]>> 
>>> Regards, Dirk& Behcet
>>> Hi all, Dirk and I submitted this PS draft. We need this to be
>>> discussed and improved. Please read and comment. Also we are
>>> soliciting co-authors, please let us know.
>>> 
>>> Regards, Dirk & Behcet
>>> 
>>> 
>>> A new version of I-D, draft-hspab-5gangip-atticps-00.txt has been
>>> successfully submitted by Behcet Sarikaya and posted to the IETF
>>> repository.
>>> 
>>> Name:           draft-hspab-5gangip-atticps Revision:       00 
>>> Title:          IP Issues and Associated Gaps in Fifth
>>> Generation
>> Wireless Networks
>>> Document date:  2018-01-28 Group:          Individual Submission 
>>> Pages:          7 URL:
>>> Abstract: This document attempts to make the case for new work
>>> that need
>> to be
>>> user which may be moving.  First a set of use cases on
>>> tunneling, charging, mobility anchors are developed and then the
>>> steps of proposed new work is described next.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time
>>> of submission until the htmlized version and diff are available
>>> at
>>> _______________________________________________ 5gangip mailing
>>> list [email-masked] <mailto:[email-masked]> 
>> _______________________________________________ 5gangip mailing
>> list [email-masked] <mailto:[email-masked]> 
>> _______________________________________________ 5gangip mailing
>> list [email-masked] 
> _______________________________________________ 5gangip mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>