Le 04/09/2018 à 18:42, Dino Farinacci a écrit :
Folks, I sent comment to the authors and they asked me to forward them
to the WG list.
I also attended 3GPP/CT4 a couple of weeks ago and can report on it in
Bangkok. Maybe Satoru can as well. There were two IETF-related
presentations given.
Thanks,
Dino
Begin forwarded message:
*From: *Dino Farinacci <[email protected] <mailto:[email protected]>>
*Subject: **My comments to draft-hmm-dmm-5g-uplane-analysis-01 *
*Date: *August 30, 2018 at 4:17:09 PM PDT
*To: *Dan Voyer <[email protected] <mailto:[email protected]>>,
Satoru Matsushima <[email protected]
<mailto:[email protected]>>,
[email protected]
<mailto:[email protected]>
*Cc: *Shunsuke Homma <[email protected]
<mailto:[email protected]>>, [email protected]
<mailto:[email protected]>, Dino Farinacci
<[email protected] <mailto:[email protected]>>
Your draft text comes first and is indented and my comments follow.
Cheers,
Dino
In this section you should make it very clear where the tunnel
terminates. It is not clear from the diagram on the N3 interface if it
terminates on the eNodeB or the UE.
Even if it says it terminates at UE it must say what is the 'UE' for them.
Because some people may think 'UE' is the smartphone, but others can
think it is the modem in the smartphone.
A typical smartphone has many processors and only some of them can be
easily verifiable in a straightforward manner (open source, root access,
etc.)
If the GTP-U terminates to a point that is hardly verifiable by average
readers then its interest is very limited.
Alex
Dan made this point verbally to me about unidirectional versus
bidirectional tunnels. I don’t know if it matters because it all comes
down to the amount of state that a router uses to terminate the
tunnel. In cisco routers, we also used one “virtual interface” (called
an idb) to support a tunnel. And we used it and all the accounting
associated with it for both input and output counters, addressing,
encap/decap functions, etc.
Dan made the comment that if tunnels were bidirectional, you reduce
the tunnel state in half. That is only if an implementation used two
data structues for different TEID values. But that would be a poor
implementation where you could store a rec_teid and send_teid in one
data structure not duplicating other parts of the data structure.
All tunneling protocols should “copy inner to outer” fields like TOS,
flow label, and TTL to outer header. That needs to be done by default
and then later if there is marking policy, it happens at boundaries
only in the outer header.
This won’t be an issue with IPv6/SRv6 but if one wants to preserve the
original host values, and there is a rewrite at the boundaries, you
will lose the information. People need to decide if this is a hard
requirement.
It just doesn’t matter. Link layer CRCs are very good these days and
does a good job protecting bit errors and bad actor corruption of
packet data.
SRv6 will have this problem too. With just 1 SID can still put an
user’s MTU sized packet over the effective path MTU.
If this is the case, then the ECMP algorithm in GTP is broken. No
packets should be reordered. So why are they?
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?
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.
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.
You should state if a UP/CP pair that is self contained with a slice.
Or is there a CP that operates each UP in each slice. And how much
fault isolation and resource reservation is obtained by slicing. I
hope its more like containers than VRFs. ;-)
What I got from the CT4 meeting is that the LISP mapping system can be
put in a box above and you could combine SMF, AMF, and PCF functions
just in the mapping database data structure. I think more of those
compoents could be combined, but I don’t understand what they all do
yet. LOL. ;-)
Note a holistic architecture would have the N6 interface terminate on
a top-of-rack router in the DN data-center.
So I think you need a CP equivalent to this document. Because the
complexity, even though present here in the UP, is order of magnitude
more in the CP and the costs of scale, security, and manageability is
in the control-plane. Have you consider doing this?
Like I mentiioned to Satoru in West Palm Beach, without a level of
indirection in routing, how do you scale the mobility part with SRv6?
That is if you carry host routes, that can only scale so far, and it
forces you to scope the host routes to small domains. That means, your
mobility is limited within that domain. That tradeoff needs to be
characterized. And I think most importantly what users need and want
is mobility across WiFi and 3GPP based data-links. That is a problem
that really needs to be solved since the RAN RF frequencies are just
going to get more jammed with billions of IoT devices coming online.
That means smaller cells, that means IP address changes, so IP address
mobility is a huge problem coming that needs to be solved.
Payment systems will be on phones. Payment systems will need to be
secure. Payment identity will be hash of your public-key, your network
address will need to be the same, that means you can change the IP
address of a system when it roams ANYWHERE.
Some things to think about.
Cheers,
Dino
Begin forwarded message:
*From: *Dino Farinacci <[email protected] <mailto:[email protected]>>
*Subject: **My comments to draft-hmm-dmm-5g-uplane-analysis-01 *
*Date: *August 30, 2018 at 4:17:09 PM PDT
*To: *Dan Voyer <[email protected] <mailto:[email protected]>>,
Satoru Matsushima <[email protected]
<mailto:[email protected]>>,
[email protected]
<mailto:[email protected]>
*Cc: *Shunsuke Homma <[email protected]
<mailto:[email protected]>>, [email protected]
<mailto:[email protected]>, Dino Farinacci
<[email protected] <mailto:[email protected]>>
Your draft text comes first and is indented and my comments follow.
Cheers,
Dino
In this section you should make it very clear where the tunnel
terminates. It is not clear from the diagram on the N3 interface if it
terminates on the eNodeB or the UE.
Dan made this point verbally to me about unidirectional versus
bidirectional tunnels. I don’t know if it matters because it all comes
down to the amount of state that a router uses to terminate the
tunnel. In cisco routers, we also used one “virtual interface” (called
an idb) to support a tunnel. And we used it and all the accounting
associated with it for both input and output counters, addressing,
encap/decap functions, etc.
Dan made the comment that if tunnels were bidirectional, you reduce
the tunnel state in half. That is only if an implementation used two
data structues for different TEID values. But that would be a poor
implementation where you could store a rec_teid and send_teid in one
data structure not duplicating other parts of the data structure.
All tunneling protocols should “copy inner to outer” fields like TOS,
flow label, and TTL to outer header. That needs to be done by default
and then later if there is marking policy, it happens at boundaries
only in the outer header.
This won’t be an issue with IPv6/SRv6 but if one wants to preserve the
original host values, and there is a rewrite at the boundaries, you
will lose the information. People need to decide if this is a hard
requirement.
It just doesn’t matter. Link layer CRCs are very good these days and
does a good job protecting bit errors and bad actor corruption of
packet data.
SRv6 will have this problem too. With just 1 SID can still put an
user’s MTU sized packet over the effective path MTU.
If this is the case, then the ECMP algorithm in GTP is broken. No
packets should be reordered. So why are they?
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?
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.
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.
You should state if a UP/CP pair that is self contained with a slice.
Or is there a CP that operates each UP in each slice. And how much
fault isolation and resource reservation is obtained by slicing. I
hope its more like containers than VRFs. ;-)
What I got from the CT4 meeting is that the LISP mapping system can be
put in a box above and you could combine SMF, AMF, and PCF functions
just in the mapping database data structure. I think more of those
compoents could be combined, but I don’t understand what they all do
yet. LOL. ;-)
Note a holistic architecture would have the N6 interface terminate on
a top-of-rack router in the DN data-center.
So I think you need a CP equivalent to this document. Because the
complexity, even though present here in the UP, is order of magnitude
more in the CP and the costs of scale, security, and manageability is
in the control-plane. Have you consider doing this?
Like I mentiioned to Satoru in West Palm Beach, without a level of
indirection in routing, how do you scale the mobility part with SRv6?
That is if you carry host routes, that can only scale so far, and it
forces you to scope the host routes to small domains. That means, your
mobility is limited within that domain. That tradeoff needs to be
characterized. And I think most importantly what users need and want
is mobility across WiFi and 3GPP based data-links. That is a problem
that really needs to be solved since the RAN RF frequencies are just
going to get more jammed with billions of IoT devices coming online.
That means smaller cells, that means IP address changes, so IP address
mobility is a huge problem coming that needs to be solved.
Payment systems will be on phones. Payment systems will need to be
secure. Payment identity will be hash of your public-key, your network
address will need to be the same, that means you can change the IP
address of a system when it roams ANYWHERE.
Some things to think about.
Cheers,
Dino
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
