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

[Behcet Sarikaya]

On Wed, Sep 5, 2018 at 3:56 AM Sridhar Bhaskaran <
sridhar.bhaska...@gmail.com> wrote:

> Dear Dino,
>
> Some clarifications on your comments
>
> >>> 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.
>
> 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.
>
> >>> 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 is not setup.
> "No session exist" scenario after a session setup can happen due to local
> error conditions, bearers released for administrative reasons etc.
>
> >>> 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.
>
>
I checked in IETF IANA UDP assignments,

pfcp 8805 udp Destination Port number for PFCP [Kimmo_Kymalainen

] [Kimmo_Kymalainen

] 2017-05-08
 for packet forwarding control protocol. What is PFCP, is it GTP-U?

Behcet

> Thanks
> Sridhar
> 3GPP CT4 Delegate
> ___
> 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] 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

[DMM] Comments on SRv6-mobile-userplane-02

[Flinck, Hannu (Nokia - FI/Espoo)]

Hello

The draft SRv6-mobile-userplane seems to use the term "anchor"  or "anchoring" 
quite a lot, but what exactly is meant is much unclear. It looks to me that the 
meaning changes during the progression of the text, or depends on the context. 
As it appears to be such key term of the draft I would recommend that you 
define it somewhere in this document.

In details:

On page 7 you talk about "anchoring SID" and "next anchoring point". In the 
traditional mobility settings there is one anchoring point. So, I do not know 
what is "next anchoring point".

Then on page 17 you mention "anchoring functionality". What is this 
functionality exactly? Has it something to do with mobility anchors as in 
"Distributed Mobility Anchoring" and/or "Proxy Mobile IPv6 extensions for 
Distributed Mobility Management" drafts that also talk about mobility anchors?

Finally, the last sentence of the draft " It's notable that SRv6's network 
programming nature allows a flexible
and dynamic anchor placement."  Given all the options of the anchoring in this 
draft, I do not know that this means? Flexible mobility anchor placement? Next 
anchor  placement? Anchoring SID placement maybe?

What do you mean by saying "All control-plane protocols are expected to 
leverage these function type-codes to signal each function" ?  Does it mean 
that all control planes need to be implemented to use these function types? Or 
carry them or what exactly?

Best regards
Hannu


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

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

[Sridhar Bhaskaran]

Dear Dino,

Some clarifications on your comments

>>> 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.

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.

>>> 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 is not setup. "No
session exist" scenario after a session setup can happen due to local error
conditions, bearers released for administrative reasons etc.

>>> 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.

Thanks
Sridhar
3GPP CT4 Delegate
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm