Re: draft-ietf-dmm-fpc-cpdp-01

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 protected]>
wrote:

> 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 protected]]
> *Sent:* Montag, 5. Oktober 2015 20:05
> *To:* [email protected]; [email protected]
> *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
[email protected]
https://www.ietf.org/mailman/listinfo/dmm