Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

[Dino Farinacci]

Note that I presented LISP to CT4 in August. They were kind enough to give me a 
slot without a WI being ready. 

They asked me to provide a proposal about how a IETF control-plane 
(specifically LISP) could be used to help manage the AMF, SMF, PCF, AUSF, and 
UDM functions. They were intrigue about using a different kind of control plane 
versus a Restful management plane that many of their “N interface” designs are 
based on. 

Maybe this WG should devote time to solving control plane issues in mobile 
networks. And I can say that the LISP WG would be enthusiastic to work with 
DMM. 

CT4 was not really interested in solving any data plane issues because they 
think many of the IETF proposals are no different, or not different enough from 
GTP. That was my interpretation. 

Cheers,
Dino

> On Nov 21, 2018, at 7:16 AM, Behcet Sarikaya  wrote:
> 
> 
> 
>> On Wed, Nov 14, 2018 at 3:53 PM David Allan I  
>> wrote:
>> HI
>> 
>>  
>> 
>> AFAIK 3GPP CT4 is looking for work it can adopt, and has indicated that it 
>> wishes to perform the analysis itself. When they were directed to this 
>> document in the recent IETF DMM liaison, it  resulted in a liaison reply 
>> clearly indicated they would define their own criteria.
>> 
>> https://datatracker.ietf.org/liaison/1590/
>> 
>>  
>> 
>> However in the draft it states in the introduction: “However we believe that 
>> to provide adequate information for 3GPP, we need to clearly understand what 
>> the current user plane protocol is in Release 15, and architectural 
>> requirements for the user plane.” And in the conclusion “Our conclusion here 
>> is that we suggest the UP protocol study work in 3GPP takes into account the 
>> evaluation aspects described in Section 5.”, there is more, but I do not 
>> feel a need to be pedantic about it.
>> 
>>  
>> 
>> So the purpose of this draft seems to explicitly be to do work for 3GPP that 
>> they have explicitly said they DO NOT WANT.
>> 
>>  
>> 
>> At the same time I do not see anything in the charter that suggests we 
>> should be doing this work either.  It would appear to have little to do with 
>> DMM’s chartered direction.
>> 
>>  
>> 
>> As such I am opposed to adoption of the draft.
>> 
>>  
>> 
> 
> +1
> 
> I had raised similar issues before.
> 
> BTW no offense to Shunsuke.
> 
> and no offense to my friend Sri :-)
> 
> Behcet 
>> Cheers
>> 
>> Dave
>> 
>>  
>> 
>>  
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Support for draft-hmm-dmm-5g-uplane-analysis

[Dino Farinacci]

I support making this draft a WG document. 

Cheers,
Dino

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

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Dino Farinacci]

> I understand your point, but there is no guarantee for a precise QoS without 
> using some sort of encapsulation being it GTP, RSVP, etc. Even with tunnels, 
> there is no guarantee that all nodes along the path have the same hardware 
> capability and can provide the same QoS treatment.  

There is existing hardware where the encapsulator copies inner QoS to outer 
QoS. All routers along the path just process the outer QoS, no changes to or 
new processing requirements for them.

> For example, the code points in routers need to be configured to correctly 
> handle the EXP bits in MPLS labels. But there is no guarantee that all 
> routers can support all values. The EXP values get mapped to code points but 
> the mapping is not always one to one.  3-bit EXPs can map to 4 code points on 
> those routers with less capable H/W.

That is a completely different matter. The discussion is about remarking. And 
if one remarks to what the path cannot support, well things don’t work as 
expected.

> Slicing is almost the same. It allows user traffic to be mapped to what the 
> operator provides.
> I agree with you that network should not touch/change original header bits. 
> GTP or any other encapsulation easily allow for this. The question is whether 
> we can provide for this without using encapsulation. IPv6 might be the 
> answer. But as Tom pointed out, flow labels can still change in the middle. 
> Is there any room for improvement. SIDs might present an opportunity.

Not if they are encapsulated and routers don’t touch packets inside.

Dino

> 
> 
> 
> 
> 
>> -Original Message-
>> From: Dino Farinacci [mailto:farina...@gmail.com]
>> Sent: 07 September 2018 13:08
>> To: Arashmid Akhavain 
>> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
>> dmm 
>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>> 
>> I think you’ll still have the PHB re-marking issues I mentioned in previous
>> emails. The question is, should the network touch/change any header bits of
>> the packet the source has built. The answer should probably be no.
>> 
>> Having said that, GTP did it the right way, even though it cost in header
>> length.
>> 
>> Dino
>> 
>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain
>>  wrote:
>>> 
>>> Correct, flow labels can change along the path. That's why I like the 
>>> slicing
>> concept.
>>> UEs can request services with different attributes, operators control how
>> service request are mapped into slices. I should look into the air side of 
>> the
>> business and see what happens there.
>>> 
>>> 
>>> 
>>>> -Original Message-
>>>> From: Tom Herbert [mailto:t...@quantonium.net]
>>>> Sent: 07 September 2018 11:13
>>>> To: Arashmid Akhavain 
>>>> Cc: Dino Farinacci ;
>>>> ta-miyas...@kddi-research.jp; dmm 
>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>>>> 
>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>>>>  wrote:
>>>>> 
>>>>> 
>>>>>> -Original Message-
>>>>>> From: Dino Farinacci [mailto:farina...@gmail.com]
>>>>>> Sent: 06 September 2018 18:59
>>>>>> To: Arashmid Akhavain 
>>>>>> Cc: Tom Herbert ; ta-miyasaka@kddi-
>> research.jp;
>>>>>> dmm 
>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-
>> 01
>>>>>> 
>>>>>>> Dino brought up a good point. Here is my two cents worth:
>>>>>> 
>>>>>> Not sure which point.
>>>>>> 
>>>>>>> As it was explained by Sridhar,  each UE can have multiple
>>>>>>> contexts. For
>>>>>> example, today some operators provide Data and VoLTE service to
>>>>>> their customers. These two services are represented by separate GTP
>>>>>> tunnels in the core with each tunnel tied up to a particular QoS.
>>>>>>> 
>>>>>>> IPv4 didn't fit the bill when GTP work was under way as it
>>>>>>> couldn't uniquely identify multiple UE
>>>>>> 
>>>>>> There is no reason why it shouldn’t. And IPv6, for this use-case
>>>>>> doesn’t add anything new other than a 28 bit
>>>>>> traffic-class/flow-label that can provide more bits for “new
>> functionality”.
>>>>> 
>>>>> 
>>>>> [Arashmid]  And that'

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Dino Farinacci]

I think you’ll still have the PHB re-marking issues I mentioned in previous 
emails. The question is, should the network touch/change any header bits of the 
packet the source has built. The answer should probably be no.

Having said that, GTP did it the right way, even though it cost in header 
length.

Dino

> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain  
> wrote:
> 
> Correct, flow labels can change along the path. That's why I like the slicing 
> concept.
> UEs can request services with different attributes, operators control how 
> service request are mapped into slices. I should look into the air side of 
> the business and see what happens there.
> 
> 
> 
>> -Original Message-
>> From: Tom Herbert [mailto:t...@quantonium.net]
>> Sent: 07 September 2018 11:13
>> To: Arashmid Akhavain 
>> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp;
>> dmm 
>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>> 
>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>>  wrote:
>>> 
>>> 
>>>> -Original Message-
>>>> From: Dino Farinacci [mailto:farina...@gmail.com]
>>>> Sent: 06 September 2018 18:59
>>>> To: Arashmid Akhavain 
>>>> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
>>>> dmm 
>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>>>> 
>>>>> Dino brought up a good point. Here is my two cents worth:
>>>> 
>>>> Not sure which point.
>>>> 
>>>>> As it was explained by Sridhar,  each UE can have multiple
>>>>> contexts. For
>>>> example, today some operators provide Data and VoLTE service to their
>>>> customers. These two services are represented by separate GTP tunnels
>>>> in the core with each tunnel tied up to a particular QoS.
>>>>> 
>>>>> IPv4 didn't fit the bill when GTP work was under way as it couldn't
>>>>> uniquely identify multiple UE
>>>> 
>>>> There is no reason why it shouldn’t. And IPv6, for this use-case
>>>> doesn’t add anything new other than a 28 bit traffic-class/flow-label
>>>> that can provide more bits for “new functionality”.
>>> 
>>> 
>>> [Arashmid]  And that's what I meant. Having a flow label is handy. We
>>> can perhaps use it to identify different UE sessions.
>>> 
>> Careful if you use the flow label to identify flows. It should be considered
>> "soft identification" since it might not always be correct (it can be 
>> changed en
>> route, isn't protected by any checksum, anyone can set it however they want,
>> etc.). It's useful for things like ECMP that don't require 100% accuracy in
>> identifying flow. The flow label was briefly considered for holding VNIs in
>> network virtualization, but we talked them out of that.
>> 
>> Tom
>> 
>>>> 
>>>>> sessions/context/bearer. So, GTP and TEID did the job. But I agree
>>>>> with
>>>> Dino that IPv6 is much more versatile and is definitely worth looking
>>>> at as an alternative.
>>>> 
>>>> That is not what I said. I said “IP could have solved this problem”. And 
>>>> “IP”
>>>> means either IPv4 or IPv6, or both at the same time.
>>> 
>>> 
>>> [Arashmid]
>>> How would we employ IPv4 to distinguish between different UE sessions.
>> TOS?
>>> Or you mean using encapsulation?
>>> 
>>>> 
>>>>> A factor worth considering though is that the use of GTP and TEID
>>>>> in mobile
>>>> core allows operators to deal with QoS on their own terms. The
>>>> tunnels with specific operator-controlled QoS are established by the
>>>> control plane between eNB, SGW, and PGW. UEs or applications sitting
>>>> in the UEs have no say in this. Well at least till the packet exits 
>>>> operator's
>> network.
>>>> 
>>>> The problem with one header, is that if you re-mark (known as PHB
>>>> markign in the ole days) you lose the original value. Encapsulation
>>>> is useful here because you can map the inner to outer and anywhere
>>>> along the path you can PHB remark on the outer header. And then the
>>>> destination can see the orignal source’s ToS/QoS/TC/flow-label whatever.
>>> 
>>> 
>>> [Arashmid] Yes, I agree. The original value is lost with PHB.
>>> Encapsulation certainly makes things easier 

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Dino Farinacci]

> Behcet,
> 
> I was thinking if TEID is need then that can be encoded in a locator
> easily enough.
> 
> Tom

Not if a locator is a PGW that is shared by many UEs. 

3GPP wants per bearer awareness so they need a specific ID, that could have 
been the UE’s IP address. And with IPv6 it can be unique and not the issue that 
Sridhar brought up.

If ILA was in use, just use the ILA-ID for this purpose.

Dino

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

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Dino Farinacci]

> Sridhar,
> 
> Couldn't the TEID be encoded in the outer IP address of an
> encpasulation or network overlay in a similar way that VNIs are
> encoded in IP addresses in virtual networking?
> 
> Tom

There are lots of ways to do it. The point is, was an additional 32 bits 
necessary solely for this purpose. 

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

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Dino Farinacci]

Sridhar,

> [SB] Lets say we only use UE IP address and no TEID. How will you identify 
> the bearer context the packet belongs? One UE may use multiple radio bearers 
> / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these are 
> IP level markings which could be changed by any on path routers. In order to 
> uniquely identify the bearer / qos flow a particular packet for a UE belongs, 
> GTPU uses TEID. 
> 
> Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are 
> not always unique. The same IP pools can be shared across multiple PDNs / DNs 
> as long as these PDNs / DNs are separate autonomous networks. So just relying 
> on UE IP address alone will result in wrong context identification for the 
> uplink traffic. There is a clear one to one mapping of Radio bearer to the 
> EPS bearer / QoS flow required all the way upto the anchor node for charging 
> and QoS treatment. This comes from the requirements in stage 2 documents (c.f 
> section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for 5G). 
> 
> There are also requirements to support non-IP protocols like Ethernet PDU and 
> Unstructured PDU types in 5G.

Then you have proven there is a lot of simplication opportunity. That is, use 
the IP header for charging, and for ethernet serivce encapsulate that at the UE 
so the eNodeB has a common and single way of classifying packets.

> 
> >> 
> > >>> How can packets be sent if the session is not setup. If the session is 
> > >>> not setup, the encapsulator should have no state. And packets should be 
> > >>> dropped locally and not go far to get an error back. This sounds 
> > >>> architecturally broken.
> > 
> > [Sridhar] The purpose of GTP-U error indication is to signal in band to the 
> > sender that a GTP-U tunnel endpoint (TEID) at the receiving side is lost 
> > for any reason. "No session exist" does not mean Session 
> 
> What does lost mean? You mean the path from encapsulator to decapsulator is 
> not working? And since we are in a packet network, that path can be restored 
> quite quickly.
> 
> [SB] Lost here means - the "context" at the receiving entity is deleted. For 
> e.g due to administrative reasons, gNB or eNB removes the radio bearers and 
> correspondingly the GTPU context. If gNB or eNB loses a context for known 
> reasons, there could be signaling from gNB / eNB to AMF/MME and corresponding 
> removal of PDU session / EPS bearer at the core network. But if the context 
> is removed due to administrative reasons or unforeseen local errors, 
> signaling from gNB / eNB to AMF / MME may not happen. Hence the GTPU error 
> indication is an inband error detection mechanism.
> 
> Note TEID identifies a context at the receiving side. So all GTPU error 
> indication tells is that the receiver is not able to identify any context for 
> the received TEID.

Right, you are using “sessions” or “connections” at a packet layer. That is the 
fundamental problem. Why can't this 3GPP network be more like an IP network? 
You know that most of the critical traffic is IP traffic, even voice these days.

It looks like the dmm WG should propose a slice that is called an IP slice 
where we just do good ole datagram routing over it. Do charging with packet 
counters and strive to make the 3GPP network like an ethernet (or wifi 
network). 

I would like to hear arguments why this can’t be done. It is definitely a good 
place to start for 5G IMO. You do this and we can give users IP mobility from 
3GPP to wifi more seamlessly.

IMO, if 3GPP does not solve the 3GPP to wifi mobility problem, it has failed to 
solve real world problems.

> > is not setup. "No session exist" scenario after a session setup can happen 
> > due to local error conditions, bearers released for administrative reasons 
> > etc.
> 
> So at the encapsulator, do you choose another decapsultor? Note that tunnels 
> *usually* stay up since the topology that realizes the tunnel is robust and 
> redundant.
> 
> >> 
> > >>> You should explain in summary form the model the control-plane uses. 
> > >>> Does it use TCP for reliability, does it use multicast, is it like a 
> > >>> routing protocol, is it like a management protocol. What are the 
> > >>> failure modes, the state/bandwidth tradeoffs.
> > 
> > [Sridhar] Explaining all these in IETF draft is simply reproducing what is 
> > already there in TS 29.244. A reference to TS 29.244 should be enough. See 
> > section 6.4 of TS 29.244 for reliable delivery of PFCP messages.
> 
> Just pointing people to drafts doesn’t help in understanding. It requires 
> people to go off, put in a lot of time where the odds are their question will 
> not be answered.
> 
> [SB] TS 29.244 is not a draft but rather a full fledged technical 
> specification. The issue with repeating content from elsewhere instead of 
> just pointing is the risk of providing inaccurate information in IETF draft.

My point is that if you would simply summarize here in email, a lot of people 

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Dino Farinacci]

> Dear Dino,
> 
> Some clarifications on your comments

I am going to use general terms here so we don’t get hung up in IETF and/or 
3GPP terminology. Which doesn’t make things clear to anyone really. So we can 
stay on point.

> >>> It was never clear to me and no one could ever explain exactly why a TEID 
> >>> is needed. I presumed for accounting reasons. But if there was a 
> >>> one-to-one mapping between tunnel and user, why couldn’t the inner 
> >>> addresses be used for accounting?
> 
> [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a tunnel and 
> hence consequently a bearer. Once the bearer context is identified the QoS 
> and charging policy applicable to the bearer is applied. So the purpose of 
> TEID is not just for accounting. Its for QoS treatment, charging and bearer 
> context identification.

You told me what a TEID is but you didn’t say why you need to use it versus 
using the destination IP address for the tunnel.

> In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU session 
> whereas the QFI carried in GTPU extension header identifies the flow. So in 
> 5G TEID + QFI is used for QoS treatment and charging.

When a packet is encapsulated in a tunnel, a packet has 4 addresses, which 
tells us (1) the UE, (2) the destination it is talking to, (3) the 
encapsualting node, and (4) the decapsulating node.

So again, why use more space in the packet, when you have sufficient 
information to identify a user, and therefore their packet policy?

>> 
> >>> How can packets be sent if the session is not setup. If the session is 
> >>> not setup, the encapsulator should have no state. And packets should be 
> >>> dropped locally and not go far to get an error back. This sounds 
> >>> architecturally broken.
> 
> [Sridhar] The purpose of GTP-U error indication is to signal in band to the 
> sender that a GTP-U tunnel endpoint (TEID) at the receiving side is lost for 
> any reason. "No session exist" does not mean Session 

What does lost mean? You mean the path from encapsulator to decapsulator is not 
working? And since we are in a packet network, that path can be restored quite 
quickly.

> is not setup. "No session exist" scenario after a session setup can happen 
> due to local error conditions, bearers released for administrative reasons 
> etc.

So at the encapsulator, do you choose another decapsultor? Note that tunnels 
*usually* stay up since the topology that realizes the tunnel is robust and 
redundant.

>> 
> >>> You should explain in summary form the model the control-plane uses. Does 
> >>> it use TCP for reliability, does it use multicast, is it like a routing 
> >>> protocol, is it like a management protocol. What are the failure modes, 
> >>> the state/bandwidth tradeoffs.
> 
> [Sridhar] Explaining all these in IETF draft is simply reproducing what is 
> already there in TS 29.244. A reference to TS 29.244 should be enough. See 
> section 6.4 of TS 29.244 for reliable delivery of PFCP messages.

Just pointing people to drafts doesn’t help in understanding. It requires 
people to go off, put in a lot of time where the odds are their question will 
not be answered.

The points I’m trying to make is not “what it is” you are designing but “why 
you did what you did” in the design. That is rarely in the specs.

Dino

> 
> Thanks
> Sridhar
> 3GPP CT4 Delegate

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

Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00

[Dino Farinacci]

If you want it to be direct, specific, and self documenting, I’d suggest 
“Address Replacement Function”. Then verbalize it by saying casually “ARFing 
the packet”. 

Dino

> On Mar 23, 2018, at 10:36 AM, Tom Herbert  wrote:
> 
> On Tue, Mar 20, 2018 at 4:53 AM, Sri Gundavelli (sgundave)
>  wrote:
>> 
>> ILA-NAT-GW, or Locator-Rewrite Function ,,,should all work I guess.
>> 
> Sri,
> 
> I still like the term 'address transformation'. The difference between
> transformation and translation is that no information is lost in
> transformation (pointed out by Mark Smith on ila list) whereas
> translations may be imperfect. A transformation is always reversible
> and must be reversed before delivery to the final destination.
> 
> Tom
> 
>> Sri
>> 
>> 
>> 
>> 
>>> On 3/20/18, 4:42 AM, "Marco Liebsch"  wrote:
>>> 
>>> What about naming it nicely locator re-writing? Which is what it does and
>>> community reacts differently
>>> on certain terms such as NAT..
>>> 
>>> marco
>>> 
>>> -Original Message-
>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
>>> (sgundave)
>>> Sent: Dienstag, 20. März 2018 12:40
>>> To: Tom Herbert; Lyle Bertz
>>> Cc: dmm
>>> Subject: Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00
>>> 
>>> But, in any case, NAT is not such a bad word, its just that it pushed
>>> IPv6 deployments out by 20 years.
>>> 
>>> Sri
>>> 
>>> On 3/20/18, 4:37 AM, "dmm on behalf of Sri Gundavelli (sgundave)"
>>>  wrote:
>>> 
 Tom:
 
> ILA is not NAT! :-)
 
 As seen from the end point, I agree ILA is not NAT. But, that the
 function that is needed at two places where you do translation of the
 addresses from SIR to LOCATOR, or LOCATOR to SIR is a NAT function, and
 you have a mapping state similar to NAT state. That¹s a NAT :-)
 
 
 Sri
 
 On 3/20/18, 4:29 AM, "dmm on behalf of Tom Herbert"
  wrote:
 
> On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz 
> wrote:
>> We'll be quite time constrained during this session so I thought I
>> would ask  a couple of simple questions which I hope have already
>> been addressed in  previous e-mails:
>> 
>> 1. Figures 14 & 15 are described as options and do not include an SMF.
>> However, Figures 16 & 17 do.  It is a bit confusing.  Are 14 & 15
>> incorrect  or is an option to skip the SMF?  If correct, how does one
>> do any policy in  those figures?
>> 
>> 2.  ILA appears to be super NAT'g (more than 1 NAT) but it is
>> unclear how  policy works.  I am not sure that in its current state
>> the proposed ILA  design addresses in Section 3.  Although it is
>> noted that not all functions  are supported at a specific UPF it is
>> unclear that policy, lawful intercept,  etc.. is supported at all.
>> Will this be section be updated?
>> 
> Hi Lyle,
> 
> ILA is not NAT! :-) It is an address transformation process that is
> always undone before the packet is received so that receiver sees
> original packet. In this manner ILA is really just an efficient
> mechanism of creating network overlays. In this manner additional
> functionality (policy, lawful intercept, etc.) can be higher layers
> independent of the actual overlay mechanism.
> 
> Tom
> 
>> 3. Will a feature support comparison be made for each solution with
>> the UPF  functions to ensure coverage?
>> 
>> 4.  Will MFA be proposed as an option (
>> 
>> draft-gundavelli-dmm-mfa-00
>> 
>> )?
>> 
>> Thanks!
>> 
>> Lyle
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
 
 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm
>>> 
>>> ___
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

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

Re: [DMM] User Plane Protocol Study in 3GPP

[Dino Farinacci]

That sounds like you want to do IPv4 over IPv6. Do you think carriers will 
build an IPv6-only NGC at this point in time?

Dino

> On Mar 20, 2018, at 6:33 PM, Satoru Matsushima <satoru.matsush...@gmail.com> 
> wrote:
> 
> Next header type maybe?
> Interestingly GTP-U doesn’t have it.
> 
> Sent from my iPhone
> 
> 2018/03/20 18:17、Dino Farinacci <farina...@gmail.com>のメール:
> 
>> How? Please summarize in one sentence and don’t me to a draft.
>> 
>> Dino
>> 
>>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima 
>>> <satoru.matsush...@gmail.com> wrote:
>>> 
>>> Yes , supports IPv4 PDU with minimum effort.
>>> 
>>> Sent from my iPhone
>>> 
>>> 2018/03/20 16:47、Lyle Bertz <lyleb551...@gmail.com>のメール:
>>> 
>>>> I did not get to ask but I know your presentation talks about IPv6 but is 
>>>> there a requirement to support IPv4 mobile or dual stack?
>>>> 
>>>> Lyle
>>> 
>>> ___
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>> 

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

Re: [DMM] User Plane Protocol Study in 3GPP

[Dino Farinacci]

How? Please summarize in one sentence and don’t me to a draft.

Dino

> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima  
> wrote:
> 
> Yes , supports IPv4 PDU with minimum effort.
> 
> Sent from my iPhone
> 
> 2018/03/20 16:47、Lyle Bertz のメール:
> 
>> I did not get to ask but I know your presentation talks about IPv6 but is 
>> there a requirement to support IPv4 mobile or dual stack?
>> 
>> Lyle
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

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

Re: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Dino Farinacci]

> 2. For traditional mode (basic mode), could you please elaborate on the MTU 
> overhead being less than GTPU? GTPU encap MTU overhead = 20 octets outer IPv4 
> header + 8 octets UDP header + 12 octets GTPU header + Extension header for 
> QFI. SRv6 encap MTU overhead = 40 octets IPv6 header + EH for carrying QFI 
> (this part is not clear - see my next question). In your blog 
> https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/
>  I noticed in Fig.1 the MPLS / TE headers included in calculation. So does 
> the MTU overhead saving talked about for SRv6 assume that underlay TE 
> technologies are replaced? It is not clear from the draft. If there are any 
> other drafts that provide a clear calculation on the MTU savings, could you 
> please point to them?

And to add LISP for comparison:

LISP encap = 20 octets outer IPv4 header + 8 octets UDP header + 8 octets LISP 
header.

Dino

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

Re: [DMM] IETF101 - Call for agenda items

[Dino Farinacci]

Some more info.

> Topic Name: LISP 
> Presenter: Dino Farinacci 
> Time: 20 minutes
> Draft Reference:  TBP ??? 

Topic Name: LISP for the Mobile Network 
Draft Reference: draft-farinacci-lisp-mobile-network-01/02

Dino

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

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

[Dino Farinacci]

> AERO uses IPv6 Neighbor Discovery as its control-plane. Surely that is the 
> most mature?

Yes when used in a layer-2 subnet. Uses in a wider scope it has NHRP 
properties. 

If you remember we had something called LISP-EMACS (thanks John Curran) which 
we “ARPed a Map-Request over a layer 3 multicast fabric” to resolve mappings. 

Dino
___
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]

The other authors can comment but to me ILSR and LISP are the same thing. 

ILSR is an architecture that can use the LISP protocol set. 

Dino

> On Feb 6, 2018, at 10:03 PM, Bogineni, Kalyani 
> <kalyani.bogin...@verizonwireless.com> wrote:
> 
> Dino:
> 
> This paper does describe the architecture. This information in a section 
> would help and also explain what is different between
> LISP and ILSR. Figure 3 shows SMF for ILSR, AMF+, Nsmf+, Namf+, and ILSR4. 
> You can explain what the '+' means and what the
> new functionalities in SMF for ILSR are and what ILSR4 is (is it a variant of 
> N4/Sx - PFCP in 29.244).
> 
> Kalyani
> 
> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com] 
> Sent: Monday, February 5, 2018 9:44 PM
> To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>
> Cc: Tom Herbert <t...@quantonium.net>; i...@ietf.org; dmm <dmm@ietf.org>; Sri 
> Gundavelli (sgundave) <sgund...@cisco.com>
> Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for 
> draft-herbert-ila-mobile-00.txt
> 
>> 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.
> 
> This whitepaper (attached below) indicates how 
> draft-farinacci-lisp-mobile-network fits into the 5G architecture. First of 
> all, do you agree with it? And if so, do you think that information be put in 
> a new section?
> 
> Dino
> 

___
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

[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" <farina...@gmail.com> 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)
>>> <sgund...@cisco.com> 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"
>>> <kalyani.bogin...@verizonwireless.com> 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 <kalyani.bogin...@verizonwireless.com>
>>>> Cc: Tom Herbert <t...@quantonium.net>; i...@ietf.org; dmm <dmm@ietf.org>;
>>>> Sri Gundavelli (sgundave) <sgund...@cisco.com>
>>>> 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
>>>>> <kalyani.bogin...@verizonwireless.com> 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) <sgund...@cisco.com> 
> 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"
> <kalyani.bogin...@verizonwireless.com> 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 <kalyani.bogin...@verizonwireless.com>
>> Cc: Tom Herbert <t...@quantonium.net>; i...@ietf.org; dmm <dmm@ietf.org>;
>> Sri Gundavelli (sgundave) <sgund...@cisco.com>
>> 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
>>> <kalyani.bogin...@verizonwireless.com> 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] [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] [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Dino Farinacci]

One thing to add. LISP has a more mature control-plane mapping system. ILA has 
a recent proposal for its control-plane.

Dino

> On Feb 1, 2018, at 3:33 PM, Sri Gundavelli (sgundave) <sgund...@cisco.com> 
> wrote:
> 
> 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" <farina...@gmail.com> 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://datatracker.ietf.org/doc/draft-farinacci-lisp-mobile-network/
>> 
>> Dino
>> 
> 

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

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

[Dino Farinacci]

> 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://datatracker.ietf.org/doc/draft-farinacci-lisp-mobile-network/

Dino

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