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

[John Kaippallimalil <[e-mail]>]

David,
I do not see anything at all in TS29.892 about GTP being problematic on N9.

Also, even in 4G - PDN connection QoS was indicated to transport networks (potentially cross domain) by mapping DSCP  in IP/GTP-U to MPLS label. 

Slicing may need more details between 5G/transport networks (-- still to be determined in CT4)
There are slice friendly proposals - like TN aware mobility for 5G (https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/ ) and ACTN (RFC 8453) that allow dynamic negotiation of capabilities and mappings across application/transport domain. 
These can work with many transports (MPLS, SRv6, ..) and are independent of the user plane protocol (GTP-U, SRv6, ILA, ..)

Best Regards,
John



-----Original Message-----
From: dmm [mailto:[e-mail]] On Behalf Of d.lake=[e-mail]
Sent: Friday, November 16, 2018 4:52 AM
To: Sridhar Bhaskaran <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

In TS 29.892:

5.2.1	IP Connectivity for N9 and Network Slicing
The N9 interface requires IP connectivity between UPFs. IP networking issues may affect the user plane of 3GPP system. The data path between UPFs may consist of various links and IP routing nodes so that multiple paths may be available for the N9 interface. The bandwidth, latency and reliability of those paths may differ. 
The 5GC supports the concept of network slicing. The Network Instance ID supported over N4 enables to provide information to the UPF about the network slice of the PDU session (see subclause 5.6.12 of 3GPP TS 23.501, which indicates that the Network Instance ID can be selected based on the S-NSSAI of the PDU session). The UPFs need to have information on the transport network slice to allow the user plane packet of PDU sessions of 5GC network slices to be sent via appropriate transport networks.  There is no one to one mapping between 5GC slices and transport network slices, i.e. several 5GC slices may use the same transport network slice.
NOTE:	How network slicing is supported in transport networks is out of scope of 3GPP.
It is proposed to study the following aspects: 
-	whether there is a requirement to pass information about the network slice or the required QoS for the data path in the user plane packets.



Implication here is that we require IP interconnectivity between the domains and information derived from the label "The UPFs need to have information on the transport network slice."   That implies some knowledge or correlation of GTP between the two sides of the N9 interface.   So if a UPF has GTP knowledge from inside its domain and needs to cross domain, we have to be careful that there is separation of the GTP address plane (which is only 32-bit wide).

TS 29.892 is quite "light" on details at the moment.

David

-----Original Message-----
From: Sridhar Bhaskaran <[e-mail]>
Sent: 16 November 2018 08:17
To: Lake, David (PG/R - Elec Electronic Eng) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

Hi David Lake,

Could you please clarify what is your reference for the following statement?

>> The CT4 study for future user-plane makes it clear ***that for cross-domain connections GTP is problematic on N9**** and alternatives could be considered.

Regards
Sridhar Bhaskaran
 
-----Original Message-----
From: dmm [mailto:[e-mail]] On Behalf Of d.lake=[e-mail]
Sent: Thursday, November 15, 2018 3:09 PM
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

Dave

I agree with you.  In Rel 15 it is clear that the user plane protocol on both N3 and N9 is GTP.

The CT4 study for future user-plane makes it clear that for cross-domain connections GTP is problematic on N9 and alternatives could be considered.

The timeframe is Rel 16 and the working document is TR 29.892.   

So far there are TWO candidate protocols in the document:

1) GTP
2) SRv6

However, this is a working document and there is plenty of scope to add other candidates in advance of the adoption of the output of CT4 (not sure what date that is - my guess would be sometime round the end of 2019?)

So I think IN SCOPE for DMM is suggesting, detailing, explaining new User Plane candidate protocols.

OUT OF SCOPE of the DMM is deciding which of those protocols makes it into Rel 16.

Surely there are more than 2 candidate protocols we could consider for N3 and N9!?

David

-----Original Message-----
From: dmm <[e-mail]> On Behalf Of Shunsuke Homma
Sent: 15 November 2018 09:19
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

Hi Dave,

Thank you for reviewing our draft and sending your thought for the adoption...

When I reviewed the charter I couldn't find any text to make the draft to be out of scope. Could you please elaborate it with the text in the charter?

Best regards,

Shunsuke


On 2018/11/15 6:52, 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.
> 
> Cheers
> 
> Dave
> 
> 
> 
> _______________________________________________
> dmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm
> 


--
----------------------------------
Shunsuke Homma
<[e-mail]>
TEL: [phone]
FAX: [phone]

NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------

_______________________________________________
dmm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dmm