[DMM] Questions and comments on draft-ietf-dmm-5g-uplane-analysis-00

[Sridhar Bhaskaran]

Dear authors of draft-ietf-dmm-5g-uplane-analysis-00,

Thank you for the draft.

I have the following questions for clarification and comments on 
draft-ietf-dmm-5g-uplane-analysis-00

Questions

1. Section 3.6 - could you elaborate on what you mean by

>>[GTP-U-6]:  Does not support to response ICMP PTB for Path MTU
   Discovery.

2. Section 4.1

>>These tunnels are available to be handled by other
   authorized functions through the control plane.

Could you elaborate on what you mean by "other" authorized functions? Right now 
only SMF is allows to setup / teardown tunnels via N4 at UPF.

3. Section 4.2 Arch-Req-3: Could you please clarify the following sentence? 
First part of sentence talks about multiple PDU sessions but end of the 
sentence talks about one PDU session. So its not clear to me which case this is 
talking about.

However
   it should be the multiple PDU sessions multihoming case where the
   destination gNB or UPF needs to maintain multiple tunnel states under
   the one PDU session to one UP tunnel architectural principle.


4. Section 4.2 - Arch-Req-5. I am not able to understand the following 
sentences. Could you clarify what you mean by "connecting them without extra 
anchor points"? Also what does "them" refer to here? Does it refer to UE or UPF?

In addition, deployment of multiple UPFs as anchors closed to UEs'
   site and connecting them without extra anchor points enable to make
   data path more efficient.


5. Section Arch-Req-5: Are the following statements an architectural 
requirement derived from 23.501 or an architectural requirement this draft is 
putting on 3GPP? Atleast the words " UP protocol shall support to aggregate 
several PDU sessions into a tunnel or shall be a session-less tunnel." Seems 
like this draft is putting a requirement on 3GPP.

It is expected that multiple UPFs with per session tunnel handling
   for a PDU session becomes complicated task more and more for a SMF by
   increasing number of UPFs, and UP protocol shall support to aggregate
   several PDU sessions into a tunnel or shall be a session-less tunnel.

Comments:
==
1. Section 4.1.1 - traffic detection based on UE IP address and SDF filters is 
missing in the below list

o  For IPv4 or IPv6 PDU Session type

  *  PDU Session

  *  QFI

  *  Application Identifier: The Application ID is an index to a set
 of application detection rules configured in UPF

2. Section 4.2 Arch-Req-2:

>> The 5G system requires IP connectivity for N3, N6, and N9 interfaces.

There is a specific case where IP connectivity on N6 is not mandatory. For 
Ethernet PDU sessions, the anchor UPF could use L2 switching on N6 side. You 
refer clause 5.6.10.2 of TS 23.501 especially the statements below

-   Configurations, where more than one PDU Session to the same DNN (e.g. 
for more than one UE) corresponds to the same N6 interface. In this case the 
UPF acting as PSA needs to be aware of MAC addresses used by the UE in the PDU 
Session in order to map down-link Ethernet frames received over N6 to the 
appropriate PDU Session. Forwarding behaviour of the UPF acting as PSA is 
managed by SMF as specified in clause 5.8.2.5.


3. Section 4.2 Arch-Req-3:

Multihoming is provided with Branching Point (BP) or Uplink
   Classifier (UL CL) which are functionalities of UPF.

ULCL is not used for multihoming. ULCL is used for traffic splitting towards a 
local DN. Only BP is used for multihoming case.

4. Section 5 is missing one evaluation aspect. GTP-U supports "End markers" to 
help RAN sequence the packets when there is a change of UPF during mobility 
procedures. So any user plane protocol that is to be evaluated need to support 
some mechanism to help the last downlink node on path (e.g gNB) to sequence the 
packets coming from multiple UPFs during mobility cases.

5. Section 5.7 - Need justification for the following statement:

However some means need to indicate a slice on the shared
   underlying networks of the UP over the wire.

What is broken or what is the issue if slice for transport is not indicated on 
the UP over the wire? What are the issues with providing a "network instance" 
(which could be mapped to a transport path) in the forwarding action rule of a 
PDU session?

What are the advantages of carrying slice information in every packet?

Regards
Sridhar Bhaskaran

 



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

Re: [DMM] BGP-based DMM for civil aviation

[Templin (US), Fred L]

Hi Erik,

Great questions. A MNP-bearing client locates candidate s-ASBRs either through a
static map (e.g., an “/etc/hosts” file) or via the DNS. The idea is to locate 
an s-ASBR
that is regionally “close” to the client. For example, a client in Seattle 
would want
to associate with an s-ASBR in the Pacific Northwest rather than one in Eastern
Europe (although it would still work – just with sub-optimal routes). Clients do
not locate Proxys, however; the Proxy is a transparent bump-in-the-wire on
the path to the s-ASBR.

About client associations with s-ASBRs, the mechanisms are not BGP-based but
instead use a mobile routing service like MIPv6, LISP or AERO. So, the s-ASBRs
shield the BGP routing system from mobility churn caused by clients moving
between data link attachment points.

About administrative boundaries, the assumption is that all s-ASBRs and
c-ASBRs would be deployed and managed by the Mobility Service Provider.
What may not have come across from the document, however is that all
*-ASBRs could live as VMs in the cloud and do not necessarily need to be
big-iron router or server hardware.

Thanks - Fred

From: Erik Kline [mailto:e...@loon.co]
Sent: Monday, January 07, 2019 2:26 PM
To: Templin (US), Fred L 
Cc: dmm@ietf.org; RTGWG 
Subject: Re: [DMM] BGP-based DMM for civil aviation

Fred,

Happy New Year.

I'm not currently tracking rtgwg, so perhaps this is already addressed in 
discussion of there.  (And perhaps I should move dmm@ to bcc...)

How does a MNP-bearing node (client) locate candidate s-ASBRs (similarly how 
does it locate a proxy)? And does the client try to form an eBGP session with 
the s-ASBR or use something else?

I was also not clear on where administrative boundaries are in the various 
diagrams (though I assumed at least that c-ASBRs are within the MSP-owners 
administrative domain).

Thanks,
-Erik

On Wed, 2 Jan 2019 at 12:37, Templin (US), Fred L 
mailto:fred.l.temp...@boeing.com>> wrote:
Hello, and Happy New Year,

We have articulated what is essentially a Distributed Mobility Management (DMM)
service for the next-generation civil aviation Aeronautical Telecommunications
Network with Internet Protocol Services (ATN/IPS):

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/

This work tracks the progress of the International Civil Aviation Organization
(ICAO), and is a working group item of the IETF RTGWG.

The way it works is that there is a hub-and-spokes BGP overlay routing service
that interconnects potentially many mobility anchor points. Each anchor point is
responsible for mobility management for a constituent set of mobile nodes
(e.g., aircraft), such that the system as a whole supports large-scale DMM.

We think this document is in the correct home in RTGWG, but I just thought
I would start out the year by sensitizing the DMM community. Any thoughts
or comments are welcome.

Thanks - Fred
___
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] BGP-based DMM for civil aviation

[Behcet Sarikaya]

Hi Erik,

Happy New Year to all!

Unrelated to your question below, I noticed an error in one of the pages of
loon.co:

https://loon.co/technology/

I think that commercial airplanes fly a bit above 10 km or mostly around
10km orbit while the above page shows way below 10km.

Regards,
Behcet

On Mon, Jan 7, 2019 at 4:26 PM Erik Kline  wrote:

> Fred,
>
> Happy New Year.
>
> I'm not currently tracking rtgwg, so perhaps this is already addressed in
> discussion of there.  (And perhaps I should move dmm@ to bcc...)
>
> How does a MNP-bearing node (client) locate candidate s-ASBRs (similarly
> how does it locate a proxy)? And does the client try to form an eBGP
> session with the s-ASBR or use something else?
>
> I was also not clear on where administrative boundaries are in the various
> diagrams (though I assumed at least that c-ASBRs are within the MSP-owners
> administrative domain).
>
> Thanks,
> -Erik
>
> On Wed, 2 Jan 2019 at 12:37, Templin (US), Fred L <
> fred.l.temp...@boeing.com> wrote:
>
>> Hello, and Happy New Year,
>>
>> We have articulated what is essentially a Distributed Mobility Management
>> (DMM)
>> service for the next-generation civil aviation Aeronautical
>> Telecommunications
>> Network with Internet Protocol Services (ATN/IPS):
>>
>> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/
>>
>> This work tracks the progress of the International Civil Aviation
>> Organization
>> (ICAO), and is a working group item of the IETF RTGWG.
>>
>> The way it works is that there is a hub-and-spokes BGP overlay routing
>> service
>> that interconnects potentially many mobility anchor points. Each anchor
>> point is
>> responsible for mobility management for a constituent set of mobile nodes
>> (e.g., aircraft), such that the system as a whole supports large-scale
>> DMM.
>>
>> We think this document is in the correct home in RTGWG, but I just thought
>> I would start out the year by sensitizing the DMM community. Any thoughts
>> or comments are welcome.
>>
>> Thanks - Fred
>> ___
>> 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