Some review comments on draft-matsushima-spring-dmm-srv6-mobile-uplane-03

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