Subject: Re: [DMM] draft-ietf-dmm-fpc-cpdp-01

From: Lyle Bertz <[email-masked]>
Date: Mon, 5 Oct 2015 13:04:48 -0500

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

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 8 Oct 2015 13:00:26 +0000

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:[email-masked]]
Sent: Montag, 5. Oktober 2015 20:05
To: [email-masked]; [email-masked]
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

---

From: Lyle Bertz <[email-masked]>
Date: Thu, 8 Oct 2015 08:39:59 -0500

Marco,

Thanks for the response.

In general, I agree with you that the properties is most likely the way to
go. It would be interesting if it is of any value to add properties per
rule.   I would note you already have port properties supporting tunnels so
I am not sure that adding this information as part of the traffic selector
is ideal.

In general, a port level property is perfect for common property
construction and should remain in the specification.  This now becomes a
matter of construction.  Does the community believe that there will be
enough single (narrow) traffic selectors with properties that we will
unintentionally create multiple ports?  If so, the properties attached to
the rule may be of value.

My number one concern is the second e-mail on copying and tunneling
packets.  For operators this is a priority given their obligations.

As for the rest of the properties, a small group is doing a gap analysis of
Diameter => 3GPP (Gx,Gxx,Sd), 3GPP => FPC and then FPC => SDN functions
(specifically Openflow versions 1.4.x and 1.5x).   The general trend
observed so far is that we have a lot in Diameter (such as the options in
the IPFilterRule), lose it in Gx (which precludes options in their extended
AVPs of IPFilterRule for key use cases), then would map to FPC and then to
OpenFlow.  Ironically, OpenFlow *can* support the options (OXM has much of
this) but we lose it 3GPP.  I will see if we can release the information as
it is critical to deciding if we actually need this stuff or are fine with
current state.

As for the SPI Range my question is one of pure curiosity at this point,
when do I need a SPI range?

I am not married to any solution here but we also need to think about how
FPC is extended in terms of properties in both a registry manner and
experimental properties/rules.

Thank you, again, for the response.

Lyle

On Thu, Oct 8, 2015 at 8:00 AM, Marco Liebsch <[email-masked]>
wrote:

> 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:[email-masked]]
> *Sent:* Montag, 5. Oktober 2015 20:05
> *To:* [email-masked]; [email-masked]
> *Subject:* RE: draft-ietf-dmm-fpc-cpdp-01
>
>
>
> All,
>
>
>