Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Sri Gundavelli (sgundave)]

Tom:

Thanks! That sounds like some  interesting trick. But, let me make sure I 
understood this correctly.  So, the identifier space for the MN is encoded in 
the upper 64-bits. Now, the UE can use those bits to generate any Identifier 
from that space, and use it with the SIR prefix to form the 128 bit address.  
Bear with me, let me use an example

MN1 is assigned a prefix  2001:ABCD:CAFÉ:   / 48
MN2 is assigned a prefix  2001:ABCD:FOOD:  /48

The SIR Prefix for that ILA domain is  2001:DB8::/64

So, the SIR Addresses can be formed using the  16-bit identifier space left 
from the /48 prefix assignment? UE can form any identifier from bit space?

I can't figure out the scheme from this below text in 6.3.2. I think I am 
missing the context here. May be you guys discussed this before.



   To support /64 prefix assignment with ILA, the ILA identifier can be
   encoded in the the upper sixty-four bits of an address and the lower


   sixty-four bits are ignored by ILA. Since only a subset of bits are
   available, a level of indirection can be used so that ILA transforms
   the upper sixty four bits to contain both a locator and an index into
   a locator (ILA-N) specific table. The entry in the table provides the
   original sixty-four bit prefix so that ILA to SIR address
   transformation can be done.

-


From: Tom Herbert >
Date: Monday, February 5, 2018 at 9:13 PM
To: Sri Gundavelli >
Cc: Lorenzo Colitti >, 
"i...@ietf.org" >, 
dmm >
Subject: Re: [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



On Mon, Feb 5, 2018 at 9:07 PM, Sri Gundavelli (sgundave) 
> wrote:
> best practice is not to use singleton addresses, but always to provide a /64 
> prefix.

But, how does that work with ILA's approach of identifier management?  With the 
previously IETF recommended approaches in RFC5213 and even in 3GPP 
architecture, per RFC3315, the network assigned  a set of unique prefixes for 
each MN, allowed the MN to generate the identifiers.  Even CGA addressing 
worked with the per-MN prefix model.

But, with ILA there is no concept of prefix assignment. Will ILA network now 
generate a identifier block for each MN?  Is DHCPv6 the only approach?

Sri, see section 6.3.2. That describes encoding the identifier in the upper 
sixty-four bits and using an indirection table to accommodate network prefixes.

Tom

If that block is not summarizable, will it not result in mapping table size 
getting multiple many times?


Sri





From: dmm > on behalf of 
Lorenzo Colitti >
Date: Monday, February 5, 2018 at 8:52 PM
To: Tom Herbert >
Cc: "i...@ietf.org" 
>, dmm >
Subject: Re: [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert 
> wrote:
We like like to request that the dmm WG consider ILA as a candidate
protocol for the 3GPP "Study on User Plane Protocol in 5GC".

Echoing Tom's earlier comment about this: I think the address assignment 
sections (6.3 and 8.3) should be reworded to clarify that for general purpose 
hosts, best practice is not to use singleton addresses, but always to provide a 
/64 prefix.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Lorenzo Colitti]

On Tue, Feb 6, 2018 at 3:02 PM, Tom Herbert  wrote:

> On Tue, Feb 6, 2018 at 2:17 PM, Tom Herbert  wrote:
>>
>>> Section 8.3 provides the argument that singleton addresses are needed
>>> for privacy-sensitive communications. For practicality and probably scaling
>>> /64 is needed, however for strong privacy singleton addresses would be
>>> needed (to avoid resorting to NAT).
>>>
>>
>> You don't need singletons for privacy. You can just assign /64s that
>> change over time.
>>
>
> Yes, that seems to be the recommendation of RFC4914. However, neither that
> RFC nor anyone else that I can tell has been able to quantitatively
> describe the relationship between frequency of changing prefix and privacy.
> Any statements about this are qualitative in nature. By intuition, it might
> be believable that higher frequency should mean better privacy, but nobody
> can quantify that. So for a user where privacy is paramount, my example is
> a political dissident that is anonymously criticizing their government,
> there is no definitive answer to give then when they ask what frequency
> they need to ensure their privacy. Besides that, I believe that any
> frequency could be defeated with the postulated exploit below (if you see a
> flaw in this logic please let me know).
>

In general, any scheme that relies in changing singletons can be
implemented by changing /64 prefixes in the same way.

Your example of a dissident that is criticizing the government is not a
relevant one in the likely case that the government has the power to compel
the network operator to log all the singletons that the network assigns.


> Actually, there is one frequency where the privacy effects can be
> qualified: that is to use a different address per connection. This is
> effectively what stateful NAT provides and why law enforcement doesn't like
> it. With a large enough pool of users behind a NAT, flows sourced form the
> same device cannot be correlated by a third party in external network. This
> is strong privacy privacy in addressing (properties listed in 8.3). In lieu
> of telling the political dissident to find a provider using NAT, assigning
> addresses for singe use can provide it. Assigning a /64 to every flow won't
> scale, but singleton addresses could.
>

Saying that assigning unaggregatable singleton addresses to each flow would
scale is an extremely bold statement. Back-of-the-envelope says that with
100M devices and an average of 10 flows per device that last 5 minutes on
average you've got 1B entries and 3.3 milion flow updates per second. That
amount of state must be available within a reasonable time (line rate, or,
say, 1 RTT) to any border router that could conceivably receive a packet
for any one of those flows. I don't know what sort of hardware you'd be
able to run that on, nor who would want to make such a colossal
infrastructure investment even if it could be done.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Lorenzo Colitti]

On Tue, Feb 6, 2018 at 2:13 PM, Tom Herbert  wrote:

> But, with ILA there is no concept of prefix assignment. Will ILA network
>> now generate a identifier block for each MN?  Is DHCPv6 the only approach?
>>
>> Sri, see section 6.3.2. That describes encoding the identifier in the
> upper sixty-four bits and using an indirection table to accommodate network
> prefixes.
>

Hence the request: either make that the only text in section 6.3, or
clearly state that singleton addresses are not recommended by IETF best
practices. And more in general, assume that best practices are followed,
and explain how the proposed scheme will follow them. At the moment, this
scheme seems little more than an afterthought.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Sri Gundavelli (sgundave)]

> best practice is not to use singleton addresses, but always to provide a /64 
> prefix.

But, how does that work with ILA's approach of identifier management?  With the 
previously IETF recommended approaches in RFC5213 and even in 3GPP 
architecture, per RFC3315, the network assigned  a set of unique prefixes for 
each MN, allowed the MN to generate the identifiers.  Even CGA addressing 
worked with the per-MN prefix model.

But, with ILA there is no concept of prefix assignment. Will ILA network now 
generate a identifier block for each MN?  Is DHCPv6 the only approach?

If that block is not summarizable, will it not result in mapping table size 
getting multiple many times?


Sri





From: dmm > on behalf of 
Lorenzo Colitti >
Date: Monday, February 5, 2018 at 8:52 PM
To: Tom Herbert >
Cc: "i...@ietf.org" 
>, dmm >
Subject: Re: [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert 
> wrote:
We like like to request that the dmm WG consider ILA as a candidate
protocol for the 3GPP "Study on User Plane Protocol in 5GC".

Echoing Tom's earlier comment about this: I think the address assignment 
sections (6.3 and 8.3) should be reworded to clarify that for general purpose 
hosts, best practice is not to use singleton addresses, but always to provide a 
/64 prefix.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Topology definition in the current FPC draft

[Charlie Perkins]

Hello folks,

When I think of a network topology, I think of the nodes in the network 
and the links between them.  Right now in the FPC document, the 
definition of topology does not easily admit that interpretation.


I would like to modify the top-level Topology definition to be a set of 
"Topological Links", where each such Link has a local Interface, and a 
remote Interface, and some description about the communication channel 
between the the local and remote Interfaces.  Interesting attributes of 
the description might include:


- IP addresses

- tunnel type

- MTU

- available bandwidth

- etc.


Also in the current document there are features which are important for 
creating the topology and configuring the DPNs to realize the topology.  
This involves selection of appropriate DPNs based (roughly speaking) on 
the roles they play in the network. As a result, we should discuss 
Topology as a set of Links that are established at initial network 
configuration time, and infrequently modified as a consequence of 
network events.  For instance there might be a need for load balancing, 
or routing around damaged equipment.


FPC interface directives would include information about the addresses 
and other attributes of the communication channel, as well as enabling 
database references to both DPN endpoints of the Link as part of the 
Topological Link data.


Finally, it should be discussed whether the Topology reflects all 
communication channels configured on DPNs, or only communication 
channels between interfaces of Service Groups.  The latter is a close 
reformulation of what has been previously called a "DPN Group", and 
refers to a group of interfaces on a DPN that are organized together to 
fulfill some specific service need or service function.


Comments will be appreciated!

Thanks in advance,
Charlie P.


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Dino Farinacci]

> With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that
> these are IP packets. But, we should note that there is interworking
> needed with the 3GPP authentication infrastructure, and the protocol
> specific control plane. Note that these protocols are not doing MN
> identity establishment. May be I could be wrong here on the assumptions
> you have around LISP MN capabilities, but to me MN is a standard 3GPP UE
> with no special capabilities such as MIPv6/LISP MN stack.

The draft draft-ietf-lisp-mn proposes LISP on the UE. That is not what we are 
proposing for the 3GPP 5G architecture. The draft 
draft-farinacci-lisp-mobile-network proposes LISP in the eNodeB/UPF and pGW. 

Enclosed is a pointer to the presntation I gave in the LISP WG and 5gangip in 
Singapore.

Dino

https://www.dropbox.com/s/scmc6eeqyzwme5o/lisp-mobile-network-ietf-sin.pdf



___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Sri Gundavelli (sgundave)]

> The UPF sends IP packets. The UPF is part of the NGC core, right? So the
>packets from the UPF get to a map-resolver and map-server via IP. It’s
>pretty simple. At least it should be.

Sure, that LISP control plane packet is an IP packet. But, every message
that is going between CP and UP will be named and numbered in 3GPP specs,
and so said in my first mail that its probably a new interface specific to
LISP.

With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that
these are IP packets. But, we should note that there is interworking
needed with the 3GPP authentication infrastructure, and the protocol
specific control plane. Note that these protocols are not doing MN
identity establishment. May be I could be wrong here on the assumptions
you have around LISP MN capabilities, but to me MN is a standard 3GPP UE
with no special capabilities such as MIPv6/LISP MN stack.



Sri
  
 




On 2/5/18, 6:52 PM, "Dino Farinacci"  wrote:

>> Sure, but I assume the mapping table/DB is some where else in some
>>central
>> location and not on the UPF?
>
>True.
>
>> The question is how does the UPF fetch that entry and if the interface
>>for
>> that query is built on some 3GPP interface, or its internal to LISP with
>> no bearing on the access technology.
>
>The UPF sends IP packets. The UPF is part of the NGC core, right? So the
>packets from the UPF get to a map-resolver and map-server via IP. It’s
>pretty simple. At least it should be.
>
>Dino
>
>> 
>> Sri
>> 
>> 
>> 
>> On 2/5/18, 6:42 PM, "Dino Farinacci"  wrote:
>> 
>>> I don’t know what you mean. If you put the xTR function on an UPF, then
>>> by LISP spec definition, Map-Request, Map-Reply, and Map-Register
>>> functionality is part of the UPF.
>>> 
>>> Dino
>>> 
 On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave)
  wrote:
 
 I suspect there might be a need for a new interface.
 
 Assuming the LISP mapping system stays in the control plane, next to
 SMF/AMF, and the xTR functions on the UPF, there needs to be probably
a
 new interface along the lines of the N4, for managing the LISP MAP
 operations (Reg/Req/Reply/Notify..).  But, off course if the mapping
 system stays in the user-plane, may be there is just interworking with
 the
 3GPP authentication interfaces.
 
 Sri
 
 
 
 
 
 
 
 
 
 
 
 
 
 On 2/5/18, 5:15 PM, "Bogineni, Kalyani"
  wrote:
 
> Dino:
> 
> Please look at 3GPP TS 23.501 to understand the architecture of NGC.
>We
> tried to explain that in the White paper.
> TS 23.502 has the procedures for the NGC. TS 23.503 specifies the
> policy
> and charging control framework for NGC.
> CT4 has a technical report on protocol aspects for NGC in TR 29.891.
> 
> Your draft needs to describe how it fits in the 5G architecture,
>right
> now it only addresses 4G.
> 
> Kalyani
> 
> 
> 
> -Original Message-
> From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino Farinacci
> Sent: Monday, February 5, 2018 7:32 PM
> To: Bogineni, Kalyani 
> Cc: Tom Herbert ; i...@ietf.org; dmm
>;
> Sri Gundavelli (sgundave) 
> Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for
> draft-herbert-ila-mobile-00.txt
> 
>> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani
>>  wrote:
>> 
>> Dino:
>> 
>> Can you add a section to show how this proposal would fit in 5G
>> architecture?
> 
> Can you be more specific in what you¹d like to see in the new
>section?
> 
> There are references throughout the draft where you see eNodeB and
>pGW
> that UPF functionality could be at the same network mode location.
> 
> Dino
> ___
> ila mailing list
> i...@ietf.org
> 
> 
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>ma
> n_
> 
> 
>listinfo_ila=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=
>Id
> iS
> 
> 
>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=zf1KfRu
>4n
> UF
> 
> 
>sUT8IJVExPygA_iAC-h4BErkY_CE2ugM=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X
>6l
> pS
> iBvg=
 
>>> 
>> 
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Dino Farinacci]

> Sure, but I assume the mapping table/DB is some where else in some central
> location and not on the UPF?

True.

> The question is how does the UPF fetch that entry and if the interface for
> that query is built on some 3GPP interface, or its internal to LISP with
> no bearing on the access technology.

The UPF sends IP packets. The UPF is part of the NGC core, right? So the 
packets from the UPF get to a map-resolver and map-server via IP. It’s pretty 
simple. At least it should be.

Dino

> 
> Sri
> 
> 
> 
> On 2/5/18, 6:42 PM, "Dino Farinacci"  wrote:
> 
>> I don’t know what you mean. If you put the xTR function on an UPF, then
>> by LISP spec definition, Map-Request, Map-Reply, and Map-Register
>> functionality is part of the UPF.
>> 
>> Dino
>> 
>>> On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave)
>>>  wrote:
>>> 
>>> I suspect there might be a need for a new interface.
>>> 
>>> Assuming the LISP mapping system stays in the control plane, next to
>>> SMF/AMF, and the xTR functions on the UPF, there needs to be probably a
>>> new interface along the lines of the N4, for managing the LISP MAP
>>> operations (Reg/Req/Reply/Notify..).  But, off course if the mapping
>>> system stays in the user-plane, may be there is just interworking with
>>> the
>>> 3GPP authentication interfaces.
>>> 
>>> Sri
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 2/5/18, 5:15 PM, "Bogineni, Kalyani"
>>>  wrote:
>>> 
 Dino:
 
 Please look at 3GPP TS 23.501 to understand the architecture of NGC. We
 tried to explain that in the White paper.
 TS 23.502 has the procedures for the NGC. TS 23.503 specifies the
 policy
 and charging control framework for NGC.
 CT4 has a technical report on protocol aspects for NGC in TR 29.891.
 
 Your draft needs to describe how it fits in the 5G architecture, right
 now it only addresses 4G.
 
 Kalyani
 
 
 
 -Original Message-
 From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino Farinacci
 Sent: Monday, February 5, 2018 7:32 PM
 To: Bogineni, Kalyani 
 Cc: Tom Herbert ; i...@ietf.org; dmm ;
 Sri Gundavelli (sgundave) 
 Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for
 draft-herbert-ila-mobile-00.txt
 
> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani
>  wrote:
> 
> Dino:
> 
> Can you add a section to show how this proposal would fit in 5G
> architecture? 
 
 Can you be more specific in what you¹d like to see in the new section?
 
 There are references throughout the draft where you see eNodeB and pGW
 that UPF functionality could be at the same network mode location.
 
 Dino
 ___
 ila mailing list
 i...@ietf.org
 
 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
 n_
 
 listinfo_ila=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Id
 iS
 
 ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=zf1KfRu4n
 UF
 
 sUT8IJVExPygA_iAC-h4BErkY_CE2ugM=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X6l
 pS
 iBvg=
>>> 
>> 
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Sri Gundavelli (sgundave)]

Sure, but I assume the mapping table/DB is some where else in some central
location and not on the UPF?

The question is how does the UPF fetch that entry and if the interface for
that query is built on some 3GPP interface, or its internal to LISP with
no bearing on the access technology.

Sri



On 2/5/18, 6:42 PM, "Dino Farinacci"  wrote:

>I don’t know what you mean. If you put the xTR function on an UPF, then
>by LISP spec definition, Map-Request, Map-Reply, and Map-Register
>functionality is part of the UPF.
>
>Dino
>
>> On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave)
>> wrote:
>> 
>> I suspect there might be a need for a new interface.
>> 
>> Assuming the LISP mapping system stays in the control plane, next to
>> SMF/AMF, and the xTR functions on the UPF, there needs to be probably a
>> new interface along the lines of the N4, for managing the LISP MAP
>> operations (Reg/Req/Reply/Notify..).  But, off course if the mapping
>> system stays in the user-plane, may be there is just interworking with
>>the
>> 3GPP authentication interfaces.
>> 
>> Sri
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 2/5/18, 5:15 PM, "Bogineni, Kalyani"
>>  wrote:
>> 
>>> Dino:
>>> 
>>> Please look at 3GPP TS 23.501 to understand the architecture of NGC. We
>>> tried to explain that in the White paper.
>>> TS 23.502 has the procedures for the NGC. TS 23.503 specifies the
>>>policy
>>> and charging control framework for NGC.
>>> CT4 has a technical report on protocol aspects for NGC in TR 29.891.
>>> 
>>> Your draft needs to describe how it fits in the 5G architecture, right
>>> now it only addresses 4G.
>>> 
>>> Kalyani
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino Farinacci
>>> Sent: Monday, February 5, 2018 7:32 PM
>>> To: Bogineni, Kalyani 
>>> Cc: Tom Herbert ; i...@ietf.org; dmm ;
>>> Sri Gundavelli (sgundave) 
>>> Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for
>>> draft-herbert-ila-mobile-00.txt
>>> 
 On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani
  wrote:
 
 Dino:
 
 Can you add a section to show how this proposal would fit in 5G
 architecture? 
>>> 
>>> Can you be more specific in what you¹d like to see in the new section?
>>> 
>>> There are references throughout the draft where you see eNodeB and pGW
>>> that UPF functionality could be at the same network mode location.
>>> 
>>> Dino
>>> ___
>>> ila mailing list
>>> i...@ietf.org
>>> 
>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
>>>n_
>>> 
>>>listinfo_ila=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Id
>>>iS
>>> 
>>>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=zf1KfRu4n
>>>UF
>>> 
>>>sUT8IJVExPygA_iAC-h4BErkY_CE2ugM=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X6l
>>>pS
>>> iBvg=
>> 
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Dino Farinacci]

I don’t know what you mean. If you put the xTR function on an UPF, then by LISP 
spec definition, Map-Request, Map-Reply, and Map-Register functionality is part 
of the UPF.

Dino

> On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave)  
> wrote:
> 
> I suspect there might be a need for a new interface.
> 
> Assuming the LISP mapping system stays in the control plane, next to
> SMF/AMF, and the xTR functions on the UPF, there needs to be probably a
> new interface along the lines of the N4, for managing the LISP MAP
> operations (Reg/Req/Reply/Notify..).  But, off course if the mapping
> system stays in the user-plane, may be there is just interworking with the
> 3GPP authentication interfaces.
> 
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 2/5/18, 5:15 PM, "Bogineni, Kalyani"
>  wrote:
> 
>> Dino:
>> 
>> Please look at 3GPP TS 23.501 to understand the architecture of NGC. We
>> tried to explain that in the White paper.
>> TS 23.502 has the procedures for the NGC. TS 23.503 specifies the policy
>> and charging control framework for NGC.
>> CT4 has a technical report on protocol aspects for NGC in TR 29.891.
>> 
>> Your draft needs to describe how it fits in the 5G architecture, right
>> now it only addresses 4G.
>> 
>> Kalyani
>> 
>> 
>> 
>> -Original Message-
>> From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino Farinacci
>> Sent: Monday, February 5, 2018 7:32 PM
>> To: Bogineni, Kalyani 
>> Cc: Tom Herbert ; i...@ietf.org; dmm ;
>> Sri Gundavelli (sgundave) 
>> Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for
>> draft-herbert-ila-mobile-00.txt
>> 
>>> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani
>>>  wrote:
>>> 
>>> Dino:
>>> 
>>> Can you add a section to show how this proposal would fit in 5G
>>> architecture? 
>> 
>> Can you be more specific in what you¹d like to see in the new section?
>> 
>> There are references throughout the draft where you see eNodeB and pGW
>> that UPF functionality could be at the same network mode location.
>> 
>> Dino
>> ___
>> ila mailing list
>> i...@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>> listinfo_ila=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiS
>> ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=zf1KfRu4nUF
>> sUT8IJVExPygA_iAC-h4BErkY_CE2ugM=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X6lpS
>> iBvg=
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Sri Gundavelli (sgundave)]

I suspect there might be a need for a new interface.

Assuming the LISP mapping system stays in the control plane, next to
SMF/AMF, and the xTR functions on the UPF, there needs to be probably a
new interface along the lines of the N4, for managing the LISP MAP
operations (Reg/Req/Reply/Notify..).  But, off course if the mapping
system stays in the user-plane, may be there is just interworking with the
3GPP authentication interfaces.

Sri







  





On 2/5/18, 5:15 PM, "Bogineni, Kalyani"
 wrote:

>Dino:
>
>Please look at 3GPP TS 23.501 to understand the architecture of NGC. We
>tried to explain that in the White paper.
>TS 23.502 has the procedures for the NGC. TS 23.503 specifies the policy
>and charging control framework for NGC.
>CT4 has a technical report on protocol aspects for NGC in TR 29.891.
>
>Your draft needs to describe how it fits in the 5G architecture, right
>now it only addresses 4G.
>
>Kalyani
>
>
>
>-Original Message-
>From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino Farinacci
>Sent: Monday, February 5, 2018 7:32 PM
>To: Bogineni, Kalyani 
>Cc: Tom Herbert ; i...@ietf.org; dmm ;
>Sri Gundavelli (sgundave) 
>Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for
>draft-herbert-ila-mobile-00.txt
>
>> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani
>> wrote:
>> 
>> Dino:
>> 
>> Can you add a section to show how this proposal would fit in 5G
>>architecture? 
>
>Can you be more specific in what you¹d like to see in the new section?
>
>There are references throughout the draft where you see eNodeB and pGW
>that UPF functionality could be at the same network mode location.
>
>Dino
>___
>ila mailing list
>i...@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_ila=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiS
>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=zf1KfRu4nUF
>sUT8IJVExPygA_iAC-h4BErkY_CE2ugM=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X6lpS
>iBvg=

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Dino:

Please look at 3GPP TS 23.501 to understand the architecture of NGC. We tried 
to explain that in the White paper.
TS 23.502 has the procedures for the NGC. TS 23.503 specifies the policy and 
charging control framework for NGC.
CT4 has a technical report on protocol aspects for NGC in TR 29.891.

Your draft needs to describe how it fits in the 5G architecture, right now it 
only addresses 4G.

Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino Farinacci
Sent: Monday, February 5, 2018 7:32 PM
To: Bogineni, Kalyani 
Cc: Tom Herbert ; i...@ietf.org; dmm ; Sri 
Gundavelli (sgundave) 
Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani 
>  wrote:
> 
> Dino:
> 
> Can you add a section to show how this proposal would fit in 5G architecture? 

Can you be more specific in what you’d like to see in the new section?

There are references throughout the draft where you see eNodeB and pGW that UPF 
functionality could be at the same network mode location. 

Dino
___
ila mailing list
i...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=zf1KfRu4nUFsUT8IJVExPygA_iAC-h4BErkY_CE2ugM=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X6lpSiBvg=
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Dino Farinacci]

> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani 
>  wrote:
> 
> Dino:
> 
> Can you add a section to show how this proposal would fit in 5G architecture? 

Can you be more specific in what you’d like to see in the new section?

There are references throughout the draft where you see eNodeB and pGW that UPF 
functionality could be at the same network mode location. 

Dino
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Dino:

Can you add a section to show how this proposal would fit in 5G architecture? 

Kalyani

-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, February 1, 2018 6:34 PM
To: Dino Farinacci 
Cc: i...@ietf.org; Tom Herbert ; dmm 
Subject: [E] Re: [Ila] [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Thank you Dino. 

WG -  Same comments for this draft. LISP is another LOC-ID proposal, with many 
common attributes (if I  may say, like two twins) shared with ILA; some 
differences in how the Locator (COA) and identifier (HOA) spaces are 
defined/used/managed, and with one key difference of tunneling vs translation. 
Please review.


Regards
Sri

On 2/1/18, 2:59 PM, "Dino Farinacci"  wrote:

>> ILA is one of the proposals on the table. This is not an adoption 
>>call at  this time, but asking the WG to review and open up some 
>>discussions that  will help IETF understand the problem/solutions, and 
>>pick the right
>> solution(s) for this problem statement. If there is interest and if 
>>the  work is in scope for the group, we will issue an adoption call at 
>>some  point in future. Please review.
>
>I just got on the dmm list. Here is another proposal:
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.o
>rg_doc_draft-2Dfarinacci-2Dlisp-2Dmobile-2Dnetwork_=DwICAg=udBTRvFv
>XC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_Y
>SwXBDiaofh47oilzaXYRYETcBynUdpT=0FPXpkwcIr_nXgnH3elSoIO0UbXQVCs2mAT1a
>FmeI30=GsKsl3A6sbXWSegMimugCGCWIdJey5Gt4pq_z6Ql1oA=
>
>Dino
>

___
ila mailing list
i...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=0FPXpkwcIr_nXgnH3elSoIO0UbXQVCs2mAT1aFmeI30=c4jMVkWkS0nBsE4QFXON2NvUrA6Z4vZu0xTCtvI3hf4=

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Fred:

Can you add a section to show how this proposal will work in 5G architecture?

Kalyani

-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, February 2, 2018 11:00 AM
To: Templin, Fred L ; Dino Farinacci 
; Tom Herbert 
Cc: i...@ietf.org; dmm 
Subject: [E] Re: [Ila] [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Thank you Fred. 
 
There is a reason for mobile architectures shifting towards CP-UP split 
architecture (Ref: DMM WG documents + 3GPP CUPS), and the stated goal of 
further simplification in the mobile user plane (Reference: 3GPP CT4 Study item 
and 3GPP Liaison statement to DMM). Now, it will be good if we can explain how 
each of these protocols (ILA, LISP, AERO ..) address those key objectives 
around mobile user-plane optimization, else there is no reason for the WG to 
consider that specific protocol option. So, please do include this text in the 
I-D, and/or explain to the WG on how its addressing these issues.

WG - Please review AERO specs, along with the other proposals.




Sri



On 2/2/18, 7:40 AM, "Templin, Fred L"  wrote:

>Hi, please add AERO to the list:
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.o
>rg_doc_draft-2Dtemplin-2Daerolink_=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3
>mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilza
>XYRYETcBynUdpT=sCHryEZFtc7CtEHHHDax7-Ae9uuwPgGWuYf9-O1T12w=HIFgnfSr
>nLv7H1FRiA_sivkZ6tqIQkBDmLgnGi9logQ=
>
>AERO does IPv6 ND over tunnels, and supports mobility via dynamic 
>neighbor cache updates the same as any IPv6 link. Use cases include 
>(but are not limited to):
>
>- Enterprise mobile devices (cellphones, tablets, etc. as mobile 
>networks)
>- civil aviation networks (airplanes as mobile networks)
>- Unmanned Air Systems (drones as mobile networks)
>
>AERO has been discussed in this forum several years back, and has 
>continued to mature since that time. Maybe now is the time to start 
>talking about it again.
>
>Thanks - Fred
>

___
ila mailing list
i...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=sCHryEZFtc7CtEHHHDax7-Ae9uuwPgGWuYf9-O1T12w=rVisbGTQdyRNwu8W6zgFJawofONn9JBd1ixzyMqefrQ=

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm