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

[Satoru Matsushima]

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 

[DMM] SRv6 for mobile user plane

[Sri Gundavelli (sgundave)]

Thinking from an end to end system point of view on how to realize an optimized 
user plane, I think there needs to be other things in place. For example, its 
easy say, "lets optimize the data plane", but we need to be able to quantify 
that optimization and the need for that optimization, otherwise it may not mean 
anything.

These are some of the work items that I think can give completeness to the 
work. May be some fall in DMM, some in other IETF working group and some in 
SDO's, but we need to think about these aspects as we make progress on the SRv6 
user plane draft. Also, some working code (#9) can really help in understanding 
the challenges with this approach.


1.) Requirements and Goals for realizing Optimizations to Mobile User Plane
2.) Extensions to PMIPv6 Signaling Plane for Supporting SRv6 User Plane
3.) Recommendations to 3GPP on how to support SRv6 Mobile Plane (includes 
signaling extensions)
4.) Dynamic Anchor Support with SRv6 mobile user plane
5.) Security Considerations for Mobile User Plane based on SRv6
6.) QoS Considerations for SRv6 based Mobile User Plane
7.) Performance Testing of SRv6 Mobile User Plane - Report
8.) POC of SRv6 MIP and Hackethon Events
9.) OAM for SRv6 Mobile User Plane
10.) Altnerative Approaches (non-SRv6) for Mobile User Plane and Comparative 
Analysis
11.) Extensions to FPC Interface for supporting SRv6 type user-plane


Sri

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

[Sri Gundavelli (sgundave)]

Folks:

The call for adoption has now ended.

Based on the opinions expressed in the mailing list and during f2f meeting at 
IETF100, we believe there is sufficient interest for taking up this work as a 
chartered working group item. I have discussed with my co-chair Dapeng and have 
decided to adopt this document as a DMM working group document.  I have also 
discussed with our AD (Suresh), to make sure this is inline with the overall 
DMM charter.

There were few offline comments that I have received expressing some concerns 
on the readiness of the document and around lack of details on how the entire 
system works. As noted earlier, the document is a starting point and we believe 
significant amount of work needs still needs to go into the document; 
contributions from the entire group is needed for this effort to be complete. 
We also need to put a scope this work correctly, such as strictly keeping the 
focus on realizing optimizations in the user plane in the form of tunnel 
elimination, and minimizing the subscriber state that is present in today's 
mobile architectures. There can be other contributions that can focus on the 
other aspects such as in signaling plane, and for covering the gaps in the end 
to end system.

Finally,  Authors have also expressed interest to include Charlie Perkins as a 
co-author. Given Charlie's prior work around source routing and his interest to 
contribute to this document, we thought its a good idea to have Charlie as a 
co-author.


Authors:

Please submit, "draft-matsushima-spring-dmm-srv6-mobile-uplane-03" as 
"draft-ietf-dmm-srv6-mobile-uplane-00" with exactly one change reflecting 
Charlie as a co-author.

Regards
Dapeng & Sri





From: dmm > on behalf of Sri 
Gundavelli >
Date: Tuesday, November 14, 2017 at 4:02 PM
To: "dmm@ietf.org" >
Subject: [DMM] Call for adoption of 
draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

Folks:

The following message commences a two week call for opinions on the adoption of 
draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as a DMM Working document.

---
The DMM working group is considering adopting the draft, 
"draft-matsushima-spring-dmm-srv6-mobile-uplane-03" as a working group 
document. The chairs have polled the room for opinions during IETF100, and it 
was determined that there is good support for taking up this work. The chairs 
would like to confirm the same in the mailing list.  Please provide your 
feedback.


Document Link:
https://www.ietf.org/id/draft-matsushima-spring-dmm-srv6-mobile-uplane-03.txt

Slides:
https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/

Background:
https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-mobile-data-plane-evolution-motivation-goals/
---

Regards
Dapping & Sri

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Bertz, Lyle T [CTO]]

Type of the accompanying value.  There was a line continuation that made 
reading it awkward in some e-mail clients.

In Descriptors it is the type of Descriptor Value
> Descriptor-Id = 22
> Descriptor-Type = IPFilterRule 
> Descriptor-Value = in ip from any to assigned 22
In Actions it is the type of Action Value

However, we gave an Action Type (Drop) where the value is unnecessary.  The 
same would be for the type 'Permit'.  In other standards we use a boolean value 
'Gate' (True=Drop; False=Permit).



-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Tuesday, November 28, 2017 7:32 PM
To: Moses, Danny 
Cc: dmm@ietf.org
Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

Now I seems I’m confused when I see what does the type define.

Does the type define type of value, or type of action/descritor?

Cheers,
--satoru

> 2017/11/28 14:11、Moses, Danny のメール:
> 
> I am OK with the current structure.
>  
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
> Sent: Tuesday, November 28, 2017 23:45
> To: Bertz, Lyle T [CTO] ; dmm@ietf.org
> Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
>  
> So, then I don’t see the point of changing the current structure. Other 
> opinions?
>  
> From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
> Sent: Dienstag, 28. November 2017 19:42
> To: Marco Liebsch; dmm@ietf.org
> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>  
> I intentionally left out my opinion from the analysis.  I am against both as 
> the reusability for a value of a Descriptor/Action (especially descriptor) 
> does not meet the define once, use many objective for Descriptors.  The 
> define once, use many for Rule re-use is already present in Policy.
>  
> From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
> Sent: Tuesday, November 28, 2017 9:54 AM
> To: Bertz, Lyle T [CTO] ; dmm@ietf.org
> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>  
> Hi Lyle,
> 
> I see the analysis you brought, thanks for that. My proposal #2 is not 
> my preference as it was only an attempt to extend and match what 
> Satoru had in mind without losing the value in current 
> descriptors/actions. Maybe it did not help ;-)
>  
> I just see that an action value belongs to an actions type. Clearly 
> there are types which don’t require a value, e.g. drop. Here value is void 
> and re-usability is ensured, IMO.
> But moving the value entirely out of action / descriptor I just saw 
> shortcomings.
>  
> So, you brought examples and arguments against proposal #1 and proposal #2.
> But I could not conclude if there are any preferences or alternative? Do we 
> leave it as it is now?
>  
> marco
>  
>  
> From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
> Sent: Montag, 20. November 2017 15:15
> To: Marco Liebsch; dmm@ietf.org
> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>  
> Marco,
>  
> Thank you for the write up of both proposals.  Forgive the length of the 
> response but I wanted to provide concrete examples based upon the existing 
> data types.
>  
> Summary, see below for examples and details:
> -  Satoru’s Proposal (Proposal 1) - the use of only ID/Type could be 
> replaced by making the Type a U-Key (similar to a registry or identity in 
> YANG). In any arrangement though only the Type could be use.  The downside 
> for Proposal 1 is reusability.  
> -  Marco’s Proposal (Proposal 2) - To make sense the setting MUST not 
> be in any of the existing Settings, i.e. it is a setting that MUST NOT be 
> tied to the Mobility-Context, DPN Interface or the fact that a DPN was 
> assigned to enforce a Rule.  Does such an example exist?
>  
> >> My Opinion <
>  
> I would not pursue Proposal 1 due to the loss of reusability which is a key 
> benefit of entities under the Policy Model.
> I would not pursue Proposal 2 if we cannot find clear examples that the 
> settings can be placed in other settings locations.  I cannot think of an 
> example at this time but I am just one person and hope the team can provide 
> such examples.
>  
> Lyle
>  
> >> Detail <<<
>  
>  
> Let’s take a step back.   Consider the IPFilterRule (RFC 6733) to block 
> inbound port 22 traffic (even from itself)
> “deny in ip from any to assigned 22”
>  
> Recall that from 6733, “The keyword "assigned" is the address or set of 
> addresses assigned to the terminal.”
>  
> If I use a ‘IPFilterRule’ Descriptor Type (it is not in the spec; I am making 
> up a new type here) and provide a value of descriptor “in ip from any to 
> assigned 22”  you will note the only Setting to deal with here is ‘assigned’.
>  
> In Satoru’s proposal, we will call it Proposal 1, we could see a 
> Descriptor example as