Hi Lyle, thanks for your position and good comments to the current version of the draft. First of all, the draft is not complete and for sure needs feedback on required control. So, your proposal is more than welcome.
My understanding of your comment is that you’re looking for control on a rule, that filters traffic. The current spec comprises traffic descriptors, and properties, that apply to the described traffic. I can imagine two types of filters: (1) One is a default filter, which applies to all traffic that does not match any of the descriptions. An associated property can be drop, or forward to a particular IP address as next hop. (2) Another is that traffic, to which the filter applies, is explicitly described using the traffic descriptors. Both require minor extensions of the spec’s attributes list. It would require a traffic descriptor which applies to all other traffic for which no properties have been configured. Also, additional properties may be needed to configure what to do with the filtered traffic. Such filtering can be implicit and enforced by Data-Plane device management. Or: If we want the Control-Plane to enforce dynamic configuration to filter particular traffic and control what to do with the filtered traffic, then we can add the associated attributes. I hope that addresses your comments 1 and 2. About comment 3: We added the traffic selector to have means to describe IP data traffic more accurate, not only per aggregated or per-host IP addresses. That does not mean all fields in the Traffic selector, such as the SPI, need to be used. But that makes me actually aware of the need of additional traffic descriptors, which identify traffic on a GRE key or a GTP TEID. What do you think? Thanks, Marco From: Lyle Bertz [mailto:lyleb551...@gmail.com] Sent: Montag, 5. Oktober 2015 20:05 To: draft-ietf-dmm-fpc-c...@ietf.org; dmm@ietf.org Subject: RE: draft-ietf-dmm-fpc-cpdp-01 All, I took a look at the draft and am generally happy with it. I do have a few questions: 1. When looking at mapping something as common as an IPFilterRule to this specification, I understand why the direction value is left out as it is obvious and the use of the TrafficSelector makes the mappings straight forward, imo. However, the options portion of the IPFilterRule is left out of this current specficaiton. This could be added as other data to the rule with the understanding that it does add complexity and needs some language on matching beyond longest match for priority. Could the authors help me understand this design and if such options will not be supported how does a carrier support an IPFilterRule in mobility (other than never specifying no options in it)? Could some sort of extension be added to the rule because, imo, it does not belong to the port properties but I can be wrong here. 2. Drops are implicit (send packet to a port with no forwarding configuration) but as an operations person troubleshooting a solution using FPC is there something that can be done in this document (specification OR noting it as a warning) to make it obvious that a drop configuration was intentional vs a poor client not following through or some connection error condition? 3. This is a RFC 6088 question but why would there be a SPI range in a traffic selector and is that something necessary in FPC? Lyle
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
