Hello folks,
Here are some comments from my reading of the draft
"matsushima-spring-dmm-srv6-mobile-uplane".
There are a lot of minor editorial revisions required, which I have
already provided under separate email.
As I mentioned in previous email to this mailing list, I think it is
important to describe previous efforts to provide a source-routing
solution for mobility management, and to suggest reasons why the SRv6
approach will find success despite the difficulties encountered by
earlier efforts.
Much of the flexibility and power of the mechanism derives from the
assumed existence of SRv6-capable routing nodes in the packet core, or
at minimum at the edges of the core. This is a reasonable assumption,
but it diverges a bit from previous architectural guidelines by which we
had attempted to minimize the mobility design impact on existing
networks. I hope that we can get some ideas about why such a new design
philosophy is more appropriate now than in previous years.
This document naturally relies on existing SRv6 documents for
terminology and understanding of the SRv6 operations. In particular,
reference is made to [I-D.filsfils-spring-srv6-network-programming],
which is a nontrivial document to read. I think it would be very nice
if most of the terminology were explained in at least some detail within
the mobile-uplane document in order to enable better progress within the
[dmm] group. Perhaps a lot of people in this group have not read the
SRv6 documents in any great detail, at least not up to this point in time.
As a general comment, I found it confusing about whether "legacy" means
IPv4, or "non-SRv6" IPv6. For instance, I am not sure about whether
"D::1" is IPv4 or IPv6 in the first paragraph of section 6.3.1. As a
related matter, I think that relying solely on terminology like S::1,
D::1, A2::1, A2::B2, and so on soon becomes confusing. More diagrams
would be nice.
The document states:
Existing mobile user-plane with IPv6 underlay is expected to be
widely deployed. Since IPv6 network should be interoperable with SRv6
endpoints accommodated on it, interworking with existing IPv6
network is out of scope of this document.
If I understand this correctly, it would be better to say that further
specification is not needed for interworking with existing IPv6
networks. That's different than saying the interworking mechanism is
out of scope. And yet perhaps there is anyway something to say about
whether firewalls would pass dataplane traffic carrying SRH (or why that
doesn't matter).
The following claim needs a citation, I think:
Mobile user-plane requires a rate-limit feature.
Previous work in [dmm] and earlier mobility management working groups in
the IETF have not placed this constraint in general for dataplane
traffic. Even for control plane traffic, mechanisms for rate limitation
have not been designed very often.
Regarding the mechanism in the draft for rate limiting:
In case of j bit length is zero in SID, the node should not do rate
limiting unless static configuration or control-plane sets the limit
rate associated to the SID.
It should also be allowed that rate limiting is not done when there has
not been any such rate-limit Locator provided.
The mobile-uplane document goes into some depth to explain how
interworking and anchoring work. To do this, there are various examples
with specific (example) addresses and named nodes. However, it is very
important that the mobile node is registered somehow with the
SRv6-capable nodes in the network. The knowledge about where the mobile
node is reachable in the access network has to be provided (in a secure
way). Maybe the specific registration control flow is reasonably kept
separate from the user-plane operations, but at minimum the document has
to describe exactly what is the assumed state of the network after the
registration is complete.
The document states:
A mobile network may be required to create a network slice that
represents a set of network resources and isolates those resources from
other slices.
The first clause seems to mean that the mobile network creates the
slice. Wouldn't the slice need to be created before the mobile
network exists?
Later in the same section:
While network slicing has been discussed in the IETF and other
standardization bodies, what functionalities are required for network
slicing in mobile user-plane is further study item and to be
discussed.
To me, this says that slicing is out of scope. Maybe the discussion
should be deleted. Anyway, I think that slicing won't affect the design
decisions for SRv6 mobility operations, regardless of how important
slicing is in real life.
The document states:
...... the mobile control-plane may
assume that one user-plane entity has one IPv6 address ...
I'm pretty sure this isn't true for IPv6 nodes.
Some of the text in section 8.2 repeats earlier text in section 6.2.
Section 8.3 describes the possibility of putting control features (e.g.
SID allocation) into a user-plane function. I think this is dangerous
and should be done very cautiously, if at all.
Section 8.4 describes a control-plane option that seems pretty clearly
out of scope for the draft. It should be deleted. Following that, the
stateless interworking discussion seems somewhat out of place. Maybe it
would be better located in the Introduction.
Not surprisingly, "Security Considerations" are TBD. And yet clearly
the security design of the protocols involved in the draft is going to
be of prime importance. I think it would be reasonable to expect that
the security design evolve alongside the rest of the protocols described
in the document, not added later. Or, perhaps, there is ongoing work in
other IETF working groups that can be referenced for this purpose. To
this point, the security design has to be well integrated not only with
the mobile-uplane design, but also with the control-plane design that
sets up the forwarding paths in the user plane. Since the control plane
design is out of scope, we are presented with an interesting logistical
problem.
Regards,
Charlie P.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
