EGEE SA2-JRA4 telecon
=====================
Venue: CERN Telecon
Date and Time: Friday 08 July 05 
               at 13:30 BST / 14:30 CEST (CERN time)

Attended
--------

J-P Gautier (JPG), M Goutelle (MG), 
V Konoplev (VK), M N Boyarsky (MNB), 
A Patil (AP), M Büchli (MB), 
K Kavoussanakis (KK), C Palansuriya (CP),
G Vuagnin (GV)


Apologies
---------

A Sevasti (AS)


Agenda
------

  1) Go through actions
  2) Objectives of SA2-JRA4 doc
  3) AOB
  4) DONM


New Actions
-----------

VK: Email the issue of distinguishing Preminum IP and non-Premium IP 
    traffic flow between two end points to MG.

MG: Add abstract to SA2-JRA4 doc

MG: Change title of the SA2-JRA4 document to
    "Network Service Provisioning Model"

MG: Update all references to "architecture" to
    "model" in the SA2-JRA4 document.

MG: Add a reference to DSA2.2 when mentioning SLA
    monitoring in SA2-JRA4 document.


On going actions
----------------

[JPG/MG] Contact NPM team regarding SLA monitoring
         - This is mentioned in DSA2.2


Completed Actions
-----------------

[MG] Fix version problem on SA2-JRA4 doc

[MG] Consider whether title of this document is still descriptive
     of its content

[MG] Add to the SA2-JRA4 doc 

     - that the architecture accommodates light path networks.
     - What we are assuming from NRENs and GEANT; what we are  
       assuming from EGEE

[AP/MB] Review current SA2-JRA4 doc and send comments to MG (cc
        email to SA2 and JRA4).


Discussion
----------

All agreed to change the title of the document to 
"Network Service Provisioning Model". 

There was a discussion of SLA monitoring. KK, who represents
the NPM, said that NPM only supports collection of data from
existing monitoring frameworks. It is unclear who in EGEE
provide such a monitoring framework. It is also unclear such a
monitoring framework would provide all the data required for
SLA monitoring. It is noticed that two types of SLA monitoring
can be performed -> On-demand (active) monitoring or passive monitoring.
On-demand monitoring requests SLA data during service requests and
activation periods while. Passive monitoring provides historical SLA
data - long after service activation is finished. KK said NPM
facilitates passive monitoring.

CP noticed that two sets of terminology is used to described "Network Service
Classes". SA2 uses the terminology described in DSA2.1 (platinum classes) 
whereas JRA4 uses the terminology described in DJRA4.1 (e.g., VLL, GDFT, etc.).

MG said DSA2.1 describes services classes for EGEE middleware whereas DJRA4.1
describes service classes for BAR and middleware may translates the service
classes in DSA2.1 to services classes in DJRA4.1. 

CP highlighted that BAR is also a middleware. To be clear and to avoid
potential mis-understandings, middleware that uses BAR should be referred 
to as Higher Layer Middleware (HLM).

MG said classes in DSA2.1 to be used from application to HLM. However, it
is confusing to have two sets of service classes describing similar items.

JPG mentioned that according to minutes of previous SA2-JRA4 telecon
(20th January 2005, 14.00-15.15 GMT) JRA4 agrees to use terminology
in DSA2.1.

VK said there is a direct mapping between service classes in DSA2.1 and 
service classes in DJRA4.1

CP and MB pointed out that service classes describe in DSA2.1 is at
different middleware layer (i.e., HLM) to service classes described in
DJRA4.1 (BAR). For example, Platinum Bulk Transfer service described in
DSA2.1 does *not* require advance reservation as it is uses Best Effort
of Less Than Best Effort. However, the similar service class described in
DJRA4.1, Guaranteed Deadline File Transfer (GDFT) will use Premium IP
and requires advance reservation.

No agreement reached at this telecon on how to resolve this confusion.
This discussion is a good candidate for the next SA2-JRA4 F2F meeting
planned at 4th EGEE conference, Pisa - October 2005.

A question on BAR end-to-end specification:
VK asked how traffic flow is distinguished for given set of end points (i.e.,
source and destination). AP said agreed DSCP value (46) is used to
distinguish Premium IP and non-Premium IP traffic. If a network
service can not mark the DSCP field then currently only the
network address can be used. May be this requires Port in addition
to network address - requiring update to interfaces defined in DJRA4.1.


DONM
====

Friday 5 August 2005 @ 13:30 BST / 14:30 CEST (CERN time).