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