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. > > 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). 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. > 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. FPC has integrated that function into the model I think. > > 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. 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 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? 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. > > 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. 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. > > 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. 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. > > 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. 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 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
