Subject: [DMM] Some review comments on draft-matsushima-spring-dmm-srv6-mobile-uplane-03

From: Charlie Perkins <[email-masked]>
Date: Tue, 28 Nov 2017 14:25:07 -0800

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.

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 29 Nov 2017 23:43:15 -0800

Thank you Charlie, for your comments.

> [...]

> 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.

I at least know that source routing isn’t new technique. RSVP, MPLS with RSVP/CR-LDP and routing header in IPv6. Many of them were developed from 20+ years ago.
We can see one successful deployment of source routing is MPLS traffic engineering. But yes I couldn’t see it in mobility management. I don’t know why but you may know it. So please tell me what the difference. I can expect that source routing in end-to-end basis would be rejected by operators for some reasons. But both MPLS and network based mobility management are not in end-to-end source routing. I couldn’t understand the difference for the reason of the success and the fail. 

> 
> 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.

You’re right. As I mentioned in the meeting in Singapore, I’d seek more better way to explain SRv6 in mobile. So far I had followed the notion of SRv6 illustration in the network programming draft. Borrowing some text in the network-programming draft would be an easy way.

> 
> 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.

Those represent 128bits of IPv6 source address, destination address and segment IDs. I suppose that the reader in the IETF can understand that. If not, yes need to improve it that introduce diagrams looks a good idea.

> 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).

Correct. Thank you.
Though I put the sentence of “IPv6 underlay is expected to be widely deployed.” But actually I didn’t see any of the case where IPv6 network as mobile user-plane transport layer. If someone know that, please let me know btw.

> 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.

FPC has integrated that function into the model I think.

> It should also be allowed that rate limiting is not done when there has not been any such rate-limit Locator provided.

Correct. But it seems too obvious for me.

> 
> 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.

Right, this is an user-plane document that assumes control-plane manages mobility and it puts forwarding entries for end-to-end connectivity into usr-plane node.
It should be noted in the document, agreed.

> 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?

The issue here looks that luck of definition for what the mobile network is.
More precisely this means that some networks in an administration domain may be required to create a network slice that is used as one or multiple mobile networks.

> 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.

I think I was trying to say here is that definition of network slicing has been still unclear but in this document, one segment ID or a set of segment ID represent a network slice as a set of network resources.

> I'm pretty sure this isn't true for IPv6 nodes.

I think it is true. I haven’t seen any document of which _mobile_ control-plane has the notion of node of user-plane in addition to just endpoint address of tunnel in its protocol. 

> 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.

As far as I know Rel-14 in 3GPP allows to do it. We need some reference here.

> 
> Section 8.4 describes a control-plane option that seems pretty clearly out of scope for the draft.

Yes it would be better to pass that to another document, then should be deleted. 

>  It should be deleted. Following that, the stateless interworking discussion seems somewhat out of place.  Maybe it would be better located in the Introduction.

I couldn’t find right place to it. How do you think which paragraph/sentence place to which section?

> 
> 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.

Thank you, it looks make sense. I’d appreciate your contribution here.

Best regards,
--satoru

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 30 Nov 2017 00:07:23 -0800

Hello Satoru,

Follow-up on a couple of details below...

> Thank you Charlie, for your comments.

You're more than welcome!

> Those represent 128bits of IPv6 source address, destination address and segment IDs. I suppose that the reader in the IETF can understand that. If not, yes need to improve it that introduce diagram…

The addresses do indeed look like IPv6 example addresses.  But somewhere 
in the nearby text, there is reference to an IPv4 address as well.  So I 
was not really sure.

> Correct. But it seems too obvious for me.

It's obvious to me also.  But to 2,000 readers, it won't be obvious to 
every one of them.

> I think it is true. I haven’t seen any document of which _mobile_ control-plane has the notion of node of user-plane in addition to just endpoint address of tunnel in its protocol.

All IPv6 nodes have link-local and multicast addresses in addition to 
their "normal" addresses.  Plus, in general, it has to be allowed for 
mobile nodes to have multiple addresses.  I also strongly suspect that 
the active forwarding nodes will often require multiple addresses, 
especially if SDN is involved.  Or network overlays, or NFV.

Regards,
Charlie P.