Re: [DMM] Questions about SRv6 mobile user-plane
Hi Tom, Thank you, first of all, for your interest! Yes, SID list can be reduced in some cases. I agree it should be restricted to the minimum necessary. I think ILA and SRv6 share a common view, while SRv6 allows more flexible functions. Regarding RFC8200, attacks can be and should be prevented in another way. If under agreement, header insertion, which could make network more efficient, should be allowed. I hope ILA and SRv6 converge. Miya@a co-author of SRv6 mobile data plane On Sat, Jan 27, 2018 at 2:13 AM, Tom Herbert wrote: > Hello, > > I am working on a comparison between ILA and SRv6 for the mobile > user-plane. I have some questions/comments about SRv6 and particularly on > the example use cases that were depicted in the slides that were presented > in IETF100: > > https://datatracker.ietf.org/meeting/100/materials/slides- > 100-dmm-srv6-for-mobile-user-plane/ > > - It's clear from the depicted use cases that extension header insertion > is being done by intermediate nodes, but extension header insertion is > currently prohibited by RFC8200. There was an I-D posted on 6man to allow > this for SR, but that was met with pushback. Is there going to be followup > to resolve this? > > - For the uplink use cases, this seems to be more like using SR to source > route to an egress router. In other words, it's not strictly related to > mobility. Is there some connection to mobility that I'm missing? > > - The size or number of SR headers in the uplink cases seems to be larger > than necessary (IMO minimizing these is important since each additional sid > is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and > DA=A2::1-- this seems to be redundant information. Also this depicts a > second SR being inserted, but the first one should no longer be relevant. > Why not just discard the first one and save the overhead? In the second > scenario, DA is changing from A2::1 to A3::1, but AFAICT that was not done > per the SR processing. What is the operation that happened here? (it's > actaully looks like an ILA transfomation). > > - Considering the points above, could this have been done in the following > manner to minimize overhead? A1 creates one SRH with one sid and makes > DA=A2. A2 makes DA=A3. At A3 SR is processed, DA is restored to Internet > address, and EH is removed. > > - For downlink this does see to be relevant to mobility. But I have the > same question, wouldn't it be less overhead to only use one SRH and one > sid? i.e. A3 creates an SRH with just one sid that is the S:: (identifier > in identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, > A1 restores original packet for delivery. > > - One possible typo. In the last use case slide SA=S:: and DA=D::, I > believe these should be swapped? > > Thanks, > Tom > > > > > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] Policy in the FPC draft - definitions, context transfer, keys, indexing, etc.
Hello folks, Policy seems always to be complicated. I wrote up a scenario that, I think, captures many of the complications and relevant areas of application. I also think the explanations about policy management as used in the scenario mostly represent the intention of the text currently in the FPC draft. If the description about how policy is managed for the handover scenario is appropriate, I would like to use it and carry out a slight reorganization of the descriptions in the draft. Regards, Charlie P. == Example for mobile node movement from DPN-1 to DPN-2. MN has two flows: * = F1: best effort traffic * = F2: voice call When MN attaches to the access network of DPN-1, DPN-1 constructs a Mobility Context for MN. It has the following (say, at network entry): * = MN's IP address (MN_IP) * = Policy X for F1 * = Policy Y for F2 * = other stuff (charging ID, current remaining credit, ...) When MN moves to the access network of DPN-2, DPN-2 should receive the Mobility Context for MN from DPN-1, and make the necessary modifications so that the Mobility Context for MN is parameterized for operation with DPN-2. Suppose that for this example, DPN-1 routes all traffic to/from MN through a common gateway G-11. Also suppose that FPC Client has installed two policies on both DPN-1 and DPN-2 -- one for best effort traffic, one for voice. Then DPN-1 might store in the Mobility Context for MN the following rules: * = R1: If (packet belongs to flow F1), then route through G11 * = R2: If (packet belongs to flow F2), then route through G11 * = R3: Else, drop In simplest terms, at DPN-1 don't support any fancy applications, and route all packets through G11. Observe that the actual rules would certainly be different, but I think this is sufficient for the example. As this description of the scenario proceeds, the need for other policies will be considered. How did rules R1, R2, and R3 get installed on DPN-1? Presumably the FPC Client has a list of policies that are supported in the Domain (i.e., operator's network). One policy (X) could be called "Handling-Best-Effort" with Policy-Key P-12 and the other policy (Y) could be called "Handling-Voice" with Policy-Key P-37. Keys P-12 and P-37 are unique within the namespace available to the FPC-Client for data-plane nodes in its Domain. When MN registers at DPN-1, DPN-1 should already have policies P-12 and P-37 available for insertion into MN's mobility context. Let's say that these two policies are in the set of Assigned Policies at DPN-1 and DPN-2, and that the FPC client configures those policies at the time the data-plane topology is established that contains DPN-1 and DPN-2. The FPC Client might have more policies that are pertinent to all flows on the mobile node, and when a mobile node registers at a DPN, the DPN process determines which of those policies are associated with a particular mobile node, according to the flow information that is provided during registration. For our mobile node, suppose that policy P-51 applies to every flow on the mobile node. There might be some other policies that are applied for traffic to/from every mobile node, regardless of the specific credentials or flows supported on that mobile node. These might be Domain policies, or they might be configured only for a particular Interface Group, or both. Domain policies might pertain to a particular class of mobile nodes, such as visitors from another specific domain. This is a matter for discussion. There might be another category of policies that are DPN-specific. Such policies would apply to every Mobility Context resident on a particular DPN, regardless of the particular mobile node. But another DPN might not have any of the policies of the first DPN, or only some of them. Let's call those DPN policies. Back to the scenario where the MN moves from DPN-1 to DPN-2. Suppose that the mobility management system wants to do a smooth handover, and that this requires transferring MN's Mobility Context from DPN-1 to DPN-2. Suppose that on DPN-1 there are DPN-specific policies P-40 and P-41 that apply to the mobile node, and Domain policies P-50 and P-52. This depends on how the policy rules are stored on DPN-1. Here is one possibility: * = DPN-specific policies are not transferred with the Mobility Context * = Domain policy keys P-50 and P-52 COULD be transferred, or we could specify that DPN-2 determines what Domain policies apply even though we would expect them to be the same policies. * = MN-specific policy key P-51 is transferred * = Flow-specific policy keys P-12 and P-37 are transferred. In this formulation, the Mobility Context transfer has to carry the Key information for the relevant policies, but not the full policy def
Re: [DMM] Policy in the FPC draft - definitions, context transfer, keys, indexing, etc.
Charlie, Thanks for the example. A couple of notes. I appears that in your proposed terminology for Descriptors and Actions it is not clear where Attribute Values appear. Are they the Settings we’ve been using? To your proposal “For simplicity, I suggest that the Policy Keys enable access to the same policies throughout a Domain.” I would point out that in the Naming section (usually Section 4.4 in many of the drafts) we note that the keys are universal to the tenant and analogous to the G-Key. Thus, any Client signaling on behalf of the same tenant will use the same Policy keys. If we want these keys to span multiple tenants the domain concept may be practical but we need to be clear about the scope (is it a G++ key ;) )? Also, we can’t assume much higher order coordination. As to you point about looking at multiple locations for Assigned vs. Embedded (dynamic) rules, it is a known issue. The problem is lifecycle. Dynamic Rules are typically signaled via special instructions in a mobility protocol or, more likely, using another interface. In our case we planned to place them in the Mobility Context just to ensure they disappear with the Context and the Policy subtree does not contain Rules that can come/go quickly and quickly increases the size of the Policy Set (it will be the size of all policies in the system). If we put it in the Policy tree we now have housekeeping of Rule deletion in the Policy tree. It’s a tradeoff. We noticed that using only the Policy Set (no embedded Rule concept) was tough on the over the wire operations. For example we needed either 2 operations, specific order processing (policies before context) for operations and coordination between people working on static policy and the mobility protocol (which is what ultimately killed the design as humans and call processing operate at two different speeds). The other issue was that a lot of create/delete on a large index was not performing well in the DPN or SDN controller. It’s always tradeoffs. For the DPN it knows it needs more work for the Embedded (Context) Rule. The Agent / Client are responsible for installing the pre configured policy on the DPN so that it no blocking occurs when an Assigned Policy is referenced in a Context. From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Charlie Perkins Sent: Sunday, January 28, 2018 11:04 AM To: dmm@ietf.org Subject: [DMM] Policy in the FPC draft - definitions, context transfer, keys, indexing, etc. Hello folks, Policy seems always to be complicated. I wrote up a scenario that, I think, captures many of the complications and relevant areas of application. I also think the explanations about policy management as used in the scenario mostly represent the intention of the text currently in the FPC draft. If the description about how policy is managed for the handover scenario is appropriate, I would like to use it and carry out a slight reorganization of the descriptions in the draft. Regards, Charlie P. == Example for mobile node movement from DPN-1 to DPN-2. MN has two flows: * = F1: best effort traffic * = F2: voice call When MN attaches to the access network of DPN-1, DPN-1 constructs a Mobility Context for MN. It has the following (say, at network entry): * = MN's IP address (MN_IP) * = Policy X for F1 * = Policy Y for F2 * = other stuff (charging ID, current remaining credit, ...) When MN moves to the access network of DPN-2, DPN-2 should receive the Mobility Context for MN from DPN-1, and make the necessary modifications so that the Mobility Context for MN is parameterized for operation with DPN-2. Suppose that for this example, DPN-1 routes all traffic to/from MN through a common gateway G-11. Also suppose that FPC Client has installed two policies on both DPN-1 and DPN-2 -- one for best effort traffic, one for voice. Then DPN-1 might store in the Mobility Context for MN the following rules: * = R1: If (packet belongs to flow F1), then route through G11 * = R2: If (packet belongs to flow F2), then route through G11 * = R3: Else, drop In simplest terms, at DPN-1 don't support any fancy applications, and route all packets through G11. Observe that the actual rules would certainly be different, but I think this is sufficient for the example. As this description of the scenario proceeds, the need for other policies will be considered. How did rules R1, R2, and R3 get installed on DPN-1? Presumably the FPC Client has a list of policies that are supported in the Domain (i.e., operator's network). One policy (X) could be called "Handling-Best-Effort" with Policy-Key P-12 and the other policy (Y) could be called "Handling-Voice" with Policy-Key P-37. Keys P-12 and P-37 are unique within the namespace available to the FPC-Client for data-plane
Re: [DMM] Questions about SRv6 mobile user-plane
Hello Tom, To make the overhead discussion quantitative and realistic, I’ve made a spreadsheet of user-plane total overhead comparison by deployment scenarios. https://docs.google.com/spreadsheets/d/1Fx8ilE_bQPkhFBoSd-qRS5ok2IO1i0VZbmwzZJNVh0g/edit?usp=sharing This includes not only for mobility, but also range of possible cases of real deployment in operators to fulfill isolation, quality and reliability requirements for mobile networks. Some of them seem most likely cases, but others sound extreme. But I’d like to share all those scenarios to make us aware of them when it comes to packet overhead in real deployments. The total overhead length of the scenarios which exceed 2x SIDs (58) and 4x SIDs (90) cases are highlighted with red color to the number and the cell respectively in the sheet. Please take a look at it. The sheet looks a bit busy but you may find some interesting points, or errors. Any comments and corrections from all of you are really welcome. Best regards, --satoru > 2018/01/27 2:13、Tom Herbert のメール: > > Hello, > > I am working on a comparison between ILA and SRv6 for the mobile user-plane. > I have some questions/comments about SRv6 and particularly on the example use > cases that were depicted in the slides that were presented in IETF100: > > https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/ > > - It's clear from the depicted use cases that extension header insertion is > being done by intermediate nodes, but extension header insertion is currently > prohibited by RFC8200. There was an I-D posted on 6man to allow this for SR, > but that was met with pushback. Is there going to be followup to resolve this? > > - For the uplink use cases, this seems to be more like using SR to source > route to an egress router. In other words, it's not strictly related to > mobility. Is there some connection to mobility that I'm missing? > > - The size or number of SR headers in the uplink cases seems to be larger > than necessary (IMO minimizing these is important since each additional sid > is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and > DA=A2::1-- this seems to be redundant information. Also this depicts a second > SR being inserted, but the first one should no longer be relevant. Why not > just discard the first one and save the overhead? In the second scenario, DA > is changing from A2::1 to A3::1, but AFAICT that was not done per the SR > processing. What is the operation that happened here? (it's actaully looks > like an ILA transfomation). > > - Considering the points above, could this have been done in the following > manner to minimize overhead? A1 creates one SRH with one sid and makes DA=A2. > A2 makes DA=A3. At A3 SR is processed, DA is restored to Internet address, > and EH is removed. > > - For downlink this does see to be relevant to mobility. But I have the same > question, wouldn't it be less overhead to only use one SRH and one sid? i.e. > A3 creates an SRH with just one sid that is the S:: (identifier in > identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 > restores original packet for delivery. > > - One possible typo. In the last use case slide SA=S:: and DA=D::, I believe > these should be swapped? > > Thanks, > Tom > > > > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
