[DMM] Fwd: New Version Notification for draft-herbert-fast-00.txt

2018-01-23 Thread Tom Herbert 
Hello,

This might be of interest to DMM group.

The basic idea of FAST (Firewall and Service Tickets) is to allow
applications to signal to the network the services they want for their
flows. The granted services are expressed in "tickets" that an
application sets in packet of of a flow (destination or nexthop
options EH). Tickets are interpreted by the ingress node of the
network and services are applied (QoS, diffserv, map to network slice,
encapsulation, etc.). Tickets are reflected by peers to get services
applied in the reverse direction. They are also stateless and in fact
a goal of FAST is to reduce flow state in the network.

Tom


-- Forwarded message --
From:  
Date: Thu, Jan 11, 2018 at 11:46 AM
Subject: New Version Notification for draft-herbert-fast-00.txt
To: Tom Herbert 



A new version of I-D, draft-herbert-fast-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:   draft-herbert-fast
Revision:   00
Title:  Firewall and Service Tickets
Document date:  2018-01-11
Group:  Individual Submission
Pages:  21
URL:https://www.ietf.org/internet-drafts/draft-herbert-fast-00.txt
Status: https://datatracker.ietf.org/doc/draft-herbert-fast/
Htmlized:   https://tools.ietf.org/html/draft-herbert-fast-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-herbert-fast-00


Abstract:
   This document describes the Firewalls and Service Tickets protocol. A
   ticket is data that accompanies a packet and indicates a granted
   right to traverse a network or a request for network service to be
   applied. Applications request tickets from a local agent in the
   network and attach issued tickets to packets. Firewall tickets are
   issued to grant packets the right to traverse a network; service
   tickets indicate the desired service to be applied to a packets. A
   single ticket may provide both firewall and service ticket
   information. Tickets are sent in either IPv6 Destination options or
   Hop-by-Hop options.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [DMM] Long message <was, Re: Using traffic Descriptors to characterize flows in a Mobility Context>

2018-01-23 Thread Lyle Bertz 
snipped all but this response to reduce size.

I believe you are close in your understanding.

Regarding policy.

Policies have a couple of origins.   They are typically referred to as
"dynamic" (dynamically built) or "pre configured" (templates aka static
policy).   Prior to FPC the focus had been on dynamic or sending a
'dynamic' policy over the wire and remembering it.  How pre-configuration
works was largely out of the scope of most protocols but needed to be
addressed in reality.  The more pre-configuration of policy that was done,
the more complexity was required in a dynamic only protocol so support it.
Many operators referred to these static policies and their lifecycles as
"magic" which is never a great sign when troubleshooting.

Is the difference necessary? Yes.  Pre-configuration works more as a
template that needs some complementary runtime information to make it
applicable to individual users.   The value of templates are well
understood as well as having entities pre-configured.

Dynamic has trended toward highly customized policies.  There are two
origins of this in today's networks:
- Application Detection - The Rule has a vague descriptor such as "bit
torrent" or "example.com".   This isn't really actionable.  In 3GPP and
other systems once the IP flows (5-tuple) is associated with the traffic,
then the actions are associated with the 5-tuple (descriptor).  In the case
of 3GPP some configurations only use Application Detection to notify the
policy decision point (PCRF in this case) of the 5-tuple and the PCRF will
apply a rule on a gateway with the 5-tuple and action.
- Application Function (AF) -  There are many products that require
different treatment (most people think QoS but it can be more general).
The widest application is SIP / IMS based flows (which do require QoS).
SDP based negotiations are dynamic and very narrow.  They are, in effect,
not very reusable.

To support generic, re-usable Rules we put them in the Mobility-Context
(not shown below) to reflect the fact that they are required but their
assignment will change as the device moves.  In the Assigned-DPN-Policy you
have a couple of things that need to be noted:
- DPN interface the Rule(s) are applied to
- Complementary Settings which you described below (a 'fill in the blanks'
set of attributes)
- Rules to be assigned.  The templates (Assigned-Policy-Key Set) and/or
(dynamic) embedded rules

We chose the term embedded to note it was part of the Context.  It does not
require being remembered once the Context is destroyed.

per your question "But, stepping back a little bit...  why do we need the
Policies? We can have them, but we already have the Flow characterizations
by using Descriptors in a natural way."

I think you are talking about your proposed change.   I would say I am
against the Flow model you propose.  Too granular of a flow makes the
Context a Rule without an Action Set and why wouldn't you call it a Rule?
When it is an IP address its a Session.   If we nix the policy as you
propose then it is truly just a Rule and we already have that convention in
the model.

I like the Request-Policy-Key and Assigned-Policy-Key.  It's clear imo and
should be adopted.

The question becomes if the Embedded-Rules are vague enough they can be
assigned to the top level (I *think* this is the case but will look at pcap
files today to determine).  If this is true then they would be a second
class of Rule (one that does not need Descriptor-Id values or Action-Id) as
it is never intended to be re-used after the Context is destroyed.

Charlie,

I would propose we keep working the Requested (template) and Embedded
(disposable) first.  I would like to see the updated context with the
prefixes.  I think we can describe the Agent/DPN logic then tackle the Flow
vs. Prefix.  It is a lot to try to address and we may change our views on
the matter once we have an agreed up on approach for static vs. dynamic
policy.

Nice work!


On Mon, Jan 22, 2018 at 11:18 PM, Charlie Perkins <
charles.perk...@earthlink.net> wrote:

> Hello again Lyle and all,
>
> Here's what it starts to look like.  From discussion earlier today, all of
> this data structure effectively resides in the DPN, and pertains to a
> single mobile node that is current utilizing some of the resources of the
> DPN.  The DPN uses it to manage data-plane traffic to/from the Mobile Node.
>
>   |
>>   +-[Mobility-Context]  
>>   |+-[Interface-Group-Key] (O)
>>   |+-[Flow] (O)
>>   ||   +-[Interface-Key]  (O)
>>   ||   |   +-[Direction] (O)
>>   ||   +-[Descriptor-Match-Type] (M)
>>   ||   +-[Descriptor-Key] 
>>   ||   |   +-[Descriptor-Value]
>>   |+-[Assigned-Policy-DPN-Key] 
>>   ||  +-[Complementary-DPN-Settings]
>>   ||

Re: [DMM] Using traffic Descriptors to characterize flows in a Mobility Context

2018-01-23 Thread Charlie Perkins 

Hello Lyle and all,

Follow-up below...

On 1/23/2018 5:38 AM, Bertz, Lyle T [CTO] wrote:

The current Mobility Context uses the assigned address or prefixes in 
conjunction with device information, or similar information in an ancestor (if 
this is a child/descendent), to let the DPN know all traffic serviced with the 
Mobility Context information MUST have a destination/source matching the 
address(es) (per the direction of the traffic).


I think this means that the DPN provides service to a flow in a way that 
depends on the source/destination addresses of the traffic of the flow.




This is an implicit Descriptor if you would like to view it that way.  It was 
placed in the original documents in this manner I would assume for consistency 
with the current and next gen designs.


Check.  In fact, a flow could be defined to also depend on other things 
about the traffic (port number, packet size, ...).




The implication of what you are proposing is a more granular (sub-session) 
context with possible no actions.


I am O.K. with having actions as well.  Granularity is according to 
whatever is convenient for whoever defines the flows.




The current implementation allows Rules to be assigned to DPNs in the 
underlying list.   The Rule containing the Descriptors and associated Actions.


This will very simple to provide, and I will change the rough draft to 
reflect this.  Suppose the Rule is something like "if byte count exceeds 
current payment, send warning".  Is that related to what you have in mind?




I would stick to the current design; placing lists of Descriptors (beyond the 
Addresses) w/o Rule and DPN assignment creates too much ambiguity, validation 
cross checking in the DPN / Agent and would result in large, granular 
hierarchies.


Does the above resolve your concern?  I don't think I grasp the 
implication of your last clause, but if associating Rules with flows is 
acceptable, then all is good.


Regards,
Charlie P.

= end of new text ===




From: Charlie Perkins 
Sent: Monday, January 22, 2018 10:08 PM
To: Bertz, Lyle T [CTO]
Cc: dmm@ietf.org
Subject: Using traffic Descriptors to characterize flows in a Mobility Context

Hello Lyle and all,

I had an idea about characterizing the flows in a Mobility Context.

Namely, it seems that they can be characterized using the same kind of
Descriptors that are already used in the Rules.  A Rule matches traffic
against a Descriptor expression and if the traffic satisfies the
Descriptor, some action is taken.

That's just about what we want to say about a flow -- namely, that it
matches some Descriptor expression.

I am proposing to modify the Mobility Context to have some
mobile-node-specific information and a List of Descriptors, just as we
already reference under the Policy structure.  Since the Descriptors are
located in an Indexed Set, the Mobility Context only has to supply the
Descriptor-Key along with Descriptor-Values as before.

I am hoping this will provide a boost towards improving the naturalness
of the Information Model for Mobility Context.

Comments?

Regards,
Charlie P.



On 1/22/2018 1:28 PM, Bertz, Lyle T [CTO] wrote:

More inline.

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 2:27 PM
To: Bertz, Lyle T [CTO] 
Cc: dmm@ietf.org
Subject: Re: [DMM] Parent versus child mobility context

Hello Lyle,

More follow-up inline.  We're getting closer.


On 1/22/2018 11:27 AM, Bertz, Lyle T [CTO] wrote:

Hello Lyle and all,

I think I agree with most of what you say below.  I'm concerned with how to 
organize the information in the model.  So, for that purpose, please verify 
whether my following understandings are correct.

- The mobility context resides on a DPN.

- The mobility context provides necessary information (e.g., QoS) for a single 
mobile node.

- The DPN uses it to manage data-plane traffic for that mobile node.


This may be too broad of a view. What about a mobile node with
multiple mobility sessions? In such a case it may be managing one or
more (but not necessarily all of) the mobile node's mobility
sessions

Yes.  This is why I did not put "all" between "manage" and "data-plane".

LB > Ok.  We should probably be more explicit though for the casual observer if 
this language is used in the specification.


In my earlier email on this subject, I was using Mobility Context as describing something 
more associated with a mobile node, than with a particular flow.  If you want it to mean 
"bearer", then we ought to call it a Bearer.

Maybe it would be easier to understand if we had something called a "Mobile-Node Context", and in 
that context we had a set of Bearer Contexts (or, just Bearers).  Each bearer would inherit from the Mobile 
Node context simply by being part of it.  The Mobile Node context

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

2018-01-23 Thread Charlie Perkins 

Hello Lyle,


I am sorry to say that I don't understand your explanation.


To start with, I didn't mean to have a direct mapping between Interface 
Groups and 3GPP features.  Instead, I would like to suggest that 
Interface Groups are defined/configured/populated to make it easier to 
support features as needed.  If multiple Interface Groups are required 
(say, because the feature is complicated, or multi-modal, or spans 
multiple DPNs) that should be O.K.  If necessary, we could create a new 
kind of entity which collects together multiple Interface Groups which 
are then configured together to support the complicated feature. 
Hierarchically, you might say.



Questions below:


On 1/23/2018 5:25 AM, Bertz, Lyle T [CTO] wrote:


​

wrt

"What if we make that to be two different access-network features, and 
enable selection of Interface Groups for each feature?"



> emergency calls when roaming are not treated the same when they are 
domestic.




Doesn't this mean that they are handled using different DPNs, and thus 
different Interface Groups?



  this is especially true when it comes from an automobile.



I reckon that for vehicular mobility we will indeed see substantial 
differences in many aspects of mobility management.



   In fact, they are often set aside as different APNs.



Somehow this seems to motivate even more strongly the design advantage 
of having the Interfaces of an Interface Group reside on a single DPN.


  I'd like to be able to support the current DDDS implementations as 
well as TS 29.303.




Agreed -- if we can't do that, something is likely to be wrong, or else 
outside the jurisdiction of IETF.



Furthermore, such scenarios are indexed given their criticality;



Here I am at a loss.  An indexed set provides entity handles for 
reference in other structures.  Do you have some additional mechanism in 
mind?  How does criticality affect the creation of the index?


requiring an index to be built from a feature scan or security 
scenarios is not placing the operator in a comfortable situation.




And so I do not understand this either.  An indexed set offers 
references to a set of ("indexed") entities that share the same 
information model definition.  Can you say more about when and how a 
feature scan might work?  How would the indexed set be populated from 
that?  How would a security scenario impact the indexing of the Indexed 
Set?  If we don't provide an Information Model that enables the desired 
security scenarios, then we didn't finish our job yet. Security could 
well influence the configuration of appropriate Interfaces into an 
Interface Group, but I don't see how it is related to the creation of an 
index into a set of such Groups.


Thanks in advance for your consideration of my questions!

Regards,
Charlie P.





*From:* Charlie Perkins 
*Sent:* Monday, January 22, 2018 7:10 PM
*To:* Bertz, Lyle T [CTO]
*Cc:* dmm@ietf.org
*Subject:* Re: Question about Interface Groups (formerly, DPN Groups)
Hello Lyle,

Thanks for the detailed reply.  It clears up a lot of questions in my 
mind.  To briefly reply:


- The reason I was asking about whether or not an Interface Group 
lived on a DPN was to help me figure out how to structure the 
Interface Group definition.  It's already structured as an Indexed 
Set, and so we will have an Interface-Group-Key.  The DPN structure 
will have a list of such keys, for each Interface Group that exists 
and includes an Interface from the DPN.  I think this is O.K. for your 
scenario of different security zones.  Notably, we do not provide that 
as an attribute of an Interface, but then again I don't think we could 
reasonably be expected to delineate all possible attributes of Interfaces.


An Interface Group will also have a DPN-Key, for the DPN that hosts 
its interfaces.


Your example about having to select a DPN to handle emergency calls as 
well as "normal" call processing is very interesting.  What if we make 
that to be two different access-network features, and enable selection 
of Interface Groups for each feature?  Then we are still O.K. with 
having each Interface Group to be configured with only one DPN-Key.


Regards,
Charlie P.

On 1/22/2018 1:49 PM, Bertz, Lyle T [CTO] wrote:


Your scenarios are correct.  I think we are in agreement but I want 
to clarify a few things:


Wrt your statement “(b) it makes good sense for all the Interfaces of 
an Interface Group to be hosted on the same DPN.”


Ack.  I agree when the required interfaces within an Interface Group 
can be hosted on the same DPN to service a request.  However, we 
leave DPN selection up to the implementations as they may have 
proprietary or other perfectly good reasons not to do this.  By the 
above statement I have interpreted it as a recommendation and not a 
mandate, i.e. it is not a requirement in FPC to do this.   Is that 
correct?


Wrt the

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

2018-01-23 Thread Bertz, Lyle T [CTO] 
​

wrt

"What if we make that to be two different access-network features, and enable 
selection of Interface Groups for each feature?"


> emergency calls when roaming are not treated the same when they are domestic. 
>   this is especially true when it comes from an automobile.In fact, they 
> are often set aside as different APNs.   I'd like to be able to support the 
> current DDDS implementations as well as TS 29.303.  Furthermore, such 
> scenarios are indexed given their criticality; requiring an index to be built 
> from a feature scan or security scenarios is not placing the operator in a 
> comfortable situation.




From: Charlie Perkins 
Sent: Monday, January 22, 2018 7:10 PM
To: Bertz, Lyle T [CTO]
Cc: dmm@ietf.org
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

Thanks for the detailed reply.  It clears up a lot of questions in my mind.  To 
briefly reply:

- The reason I was asking about whether or not an Interface Group lived on a 
DPN was to help me figure out how to structure the Interface Group definition.  
It's already structured as an Indexed Set, and so we will have an 
Interface-Group-Key.  The DPN structure will have a list of such keys, for each 
Interface Group that exists and includes an Interface from the DPN.  I think 
this is O.K. for your scenario of different security zones.  Notably, we do not 
provide that as an attribute of an Interface, but then again I don't think we 
could reasonably be expected to delineate all possible attributes of Interfaces.

An Interface Group will also have a DPN-Key, for the DPN that hosts its 
interfaces.

Your example about having to select a DPN to handle emergency calls as well as 
"normal" call processing is very interesting.  What if we make that to be two 
different access-network features, and enable selection of Interface Groups for 
each feature?  Then we are still O.K. with having each Interface Group to be 
configured with only one DPN-Key.

Regards,
Charlie P.

On 1/22/2018 1:49 PM, Bertz, Lyle T [CTO] wrote:
Your scenarios are correct.  I think we are in agreement but I want to clarify 
a few things:

Wrt your statement “(b) it makes good sense for all the Interfaces of an 
Interface Group to be hosted on the same DPN.”

Ack.  I agree when the required interfaces within an Interface Group can be 
hosted on the same DPN to service a request.  However, we leave DPN selection 
up to the implementations as they may have proprietary or other perfectly good 
reasons not to do this.  By the above statement I have interpreted it as a 
recommendation and not a mandate, i.e. it is not a requirement in FPC to do 
this.   Is that correct?

Wrt the statement “I just want all of the Interfaces of an Interface Group to 
be on the same DPN”

I wish that was always the case but when the interface types are different or 
have a different purpose, e.g. normal calls vs. emergency calls, this is not 
the case in practice.

In the model then are you proposing the Interface Groups only reside under the 
DPN structure? If so, then one must load all DPNs and index them by Interface 
Groups Id to determine they are from the same group.  The purpose in pulling 
them out was to create a single Set that could be used to house the typing and 
common configuration information.   DPN interfaces assigned to support an 
Interface Group are then assigned to it.  Thus, if a DPN had 2 interfaces which 
are of the same type but in different security zones (or have different 
routes/networks served) they may not be able to serve in the same group.

Lyle



From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 3:25 PM
To: Bertz, Lyle T [CTO] 

Cc: dmm@ietf.org
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

I agree that:

  1.  - Interface Groups are designed to be used to select DPN.
  2.  - Interface Groups may contain a number of different Interface Types
  3.  - There may be more than one Interface Group providing equivalent 
service, at least for the purpose of selecting a DPN.
For (1) -- I imagine that the selection process would look to make sure that 
the Interface Group has the proper interfaces that are needed (say, by the FPC 
Client).  Then, the FPC Client would select the DPN hosting the Interface 
Group, set up connectivity with the interfaces in the Peer Interface Group(s), 
and all is good.

For (2) -- this is really the motivation for the concept of Interface Groups.

For (3) -- really a follow-on from (1): the FPC Client would then look at the 
other properties of the DPN hosting the Interface Group, to determine which was 
the least cost, or highest benefit, choice.  Or alternatively the FPC Client 
would look at the Settings on the Interfaces of the Group, to see which 
Interfaces had the best fit for