Subject: Re: [Supa] supa and routing policies - Reformating the reponse

From: "Susan Hares" <[email-masked]>
Date: Mon, 15 Jun 2015 11:42:54 -0400

Juergen: 

Please use this message to respond to.

Sue 

=======

BGP configuration and routing policy is focusing on the device level. 

BGP policies need the guidance of a network-wide policy that handles full
network (AS as whole) BGP.  This cross-network policy is missing inside of
IETF.   It is the middle ground between the L3SM (L3VPN service model) and
the policies for the devices.  

.         L3SM (service)

.         BGP full-network policies

.         BGP device policies (BGP config and the rtgwg policies, ACL etc). 

SUPA's policy can provide what Scott Bradner calls full-network routing and
data policy.  If SUPA can help advance the BGP full-network policies - this
is a win.  

If I am still not aligned with the charter - please let me know.

Sue 

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, June 15, 2015 11:39 AM
To: 'Juergen Schoenwaelder'; [email-masked]
Subject: Re: [Supa] supa and routing policies

Juergen: 

BGP configuration and routing policy is focusing on the device level. 

BGP policies need the guidance of a network-wide policy that handles full
network (AS as whole) BGP.  This cross-network policy is missing inside of

IETF.   It is the middle ground between the L3SM (L3VPN service model) and

the policies for the devices.  

L3SM (service)

BGP full-network policies

BGP device policies (BGP config and the rtgwg policies, ACL etc). 

SUPA's policy can provide what Scott Bradner calls full-network routing and
data policy.  If SUPA can help advance the BGP full-network policies - this
is a win.  

If I am still not aligned with the charter - please let me know. 

Sue 

------

  Policies embedded in the configuration of network elements are not in

  the scope of SUPA. In contrast to policies targeted by SUPA, embedded

  policies are usually interpreted on network elements in isolation, and

  often at timescales that require the representation of embedded

  policies to be optimized for a specific purpose. Some examples of

  embedded policies that are not in the scope of SUPA:

    - packet filtering policies

    - packet marking and scheduling policies

    - route import and export policies

    - authorization policies (configured on network elements)

-----Original Message-----

From: Supa [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder

Sent: Monday, June 15, 2015 11:16 AM

To:  <mailto:[email-masked]> [email-masked]

Subject: [Supa] supa and routing policies

Hi,

this is what the charter currently says:

  Policies embedded in the configuration of network elements are not in

  the scope of SUPA. In contrast to policies targeted by SUPA, embedded

  policies are usually interpreted on network elements in isolation, and

  often at timescales that require the representation of embedded

  policies to be optimized for a specific purpose. Some examples of

  embedded policies that are not in the scope of SUPA:

    - packet filtering policies

    - packet marking and scheduling policies

    - route import and export policies

    - authorization policies (configured on network elements)

/js

-- 

Juergen Schoenwaelder           Jacobs University Bremen gGmbH

Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany

Fax:   +49 421 200 3103         < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>

_______________________________________________

Supa mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/supa>
https://www.ietf.org/mailman/listinfo/supa

_______________________________________________

Supa mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/supa>
https://www.ietf.org/mailman/listinfo/supa

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Jun 2015 23:25:48 +0200

> If I am still not aligned with the charter - please let me know.

This sounds more aligned.

The problem is that the term 'routing policy' without further
qualification is ambiguous.

Since I thought you were referring to the ECA route import/export
policy I-D (which we were told to look at a few weeks ago), I
interpreted 'routing policy' as a kind of 'embedded policy' that is
not in the SUPA scope (like ACLs, which were mentioned in the same
part of the discussion).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 15 Jun 2015 19:07:51 -0400

Juergen: 

You are correct - the term routing policy is ambiguous.  Can you suggest a
term we can use to point of the network-wide routing policy? 

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, June 15, 2015 5:26 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

On Mon, Jun 15, 2015 at 11:42:54AM -0400, Susan Hares wrote:
> BGP policies need the guidance of a network-wide policy that handles 
> full network (AS as whole) BGP.  This cross-network policy is missing
inside of
> SUPA's policy can provide what Scott Bradner calls full-network 
> routing and data policy.  If SUPA can help advance the BGP 
> full-network policies - this is a win.
> 

The problem is that the term 'routing policy' without further qualification
is ambiguous.

Since I thought you were referring to the ECA route import/export policy I-D
(which we were told to look at a few weeks ago), I interpreted 'routing
policy' as a kind of 'embedded policy' that is not in the SUPA scope (like
ACLs, which were mentioned in the same part of the discussion).

/js

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 16 Jun 2015 12:23:16 +0000

Imho, we can use - "traffic management policy" term.
SUPA can help to manage traffic with policy based on many underling technologies (data models) not only routing.

Best Regards,
Maxim Klyus

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, June 16, 2015 2:08 AM
To: 'Juergen Schoenwaelder'
Cc: [email-masked]
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

Juergen:

You are correct - the term routing policy is ambiguous.  Can you suggest a term we can use to point of the network-wide routing policy?

Sue

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Monday, June 15, 2015 5:26 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

inside of

The problem is that the term 'routing policy' without further qualification is ambiguous.

Since I thought you were referring to the ECA route import/export policy I-D (which we were told to look at a few weeks ago), I interpreted 'routing policy' as a kind of 'embedded policy' that is not in the SUPA scope (like ACLs, which were mentioned in the same part of the discussion).

/js

[email-masked]

________________________________
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jun 2015 14:28:15 +0200

> Imho, we can use - "traffic management policy" term.

-1; this term is as vague as the one we are trying to fix

/js

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 16 Jun 2015 12:55:22 +0000

"IP-packet flow policy"?

Juergen,
I have several questions also about routing:

1) If we need to perform source based routing within 1 device
2) If we need add route to null within 1 device
3) traffic load balancing across several links within 1 device
4) traffic cleaning based on dpi - similar to ACL I guess
5) If we need to change metric for existing route - we don't add/delete something to/from export/import routing table, we changing property how information will be announced, but it will be announced anyway not depending on metric, but traffic flow will be changed.

Can we say 5 above examples will be in SUPA scope?

Best Regards,
Maxim Klyus

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, June 16, 2015 3:28 PM
To: Maxim Klyus
Cc: [email-masked]; Susan Hares
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jun 2015 15:07:35 +0200

> "IP-packet flow policy"?

-1

> Can we say 5 above examples will be in SUPA scope?

My understanding is that SUPA defines a function that takes policies
as input and creates configuration snippets as output. If there is a
configuration data model to do 'stuff' on a device, then I shoud be
able to use the SUPA framework to write policies expressing where and
when to do 'stuff' in my network.

SUPA is aiming at a generic policy tool, it does not matter whether
the tools is applied to routing, security, or a fancy coffee maker -
as long as there is a YANG data model, we should be ready to play.

/js

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 16 Jun 2015 13:32:33 +0000

Juergen,

Then I may be I didn't understand your intention.
Sure all my examples should be done with appropriate data-models, but with SUPAs help.
As I understand now your suggestion is generalize term in total and do not map it to specific technologies at all.
Just call it "embedded policy" if we applying configuration to standalone NE or let say "group based policy" if it will be applied to the set of NE.
Am I right?
I agree on it, but what I think, it will be useful to specify like an attribute or property or subclass in the model for this "embedded policy" so lower layers will be able to detect what is inside to decide how to interpret policy.
May be it will also question to John.
What do you think?

Best Regards,
Maxim Klyus

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, June 16, 2015 4:08 PM
To: Maxim Klyus
Cc: [email-masked]; Susan Hares
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

-1

> Can we say 5 above examples will be in SUPA scope?

My understanding is that SUPA defines a function that takes policies as input and creates configuration snippets as output. If there is a configuration data model to do 'stuff' on a device, then I shoud be able to use the SUPA framework to write policies expressing where and when to do 'stuff' in my network.

SUPA is aiming at a generic policy tool, it does not matter whether the tools is applied to routing, security, or a fancy coffee maker - as long as there is a YANG data model, we should be ready to play.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jun 2015 15:49:12 +0200

A device implements a packet filter (a function) and it implements a
YANG configuration data model to configure the packet filter (the data
model to configure the function). The generic policy functions we are
talking about is taking a high-level policy such as 'drop all SNMP
traffic on customer facing links' and generates configuration of the
packet filter function (according to the configuration data model for
a packet filter).

What is complicated about this? Let me quote a figure from RFC 3139:

                Configuration Management
               Data (High-level Policies)
                           |
   Network                 V                Network
   Topology ----->   Configuration    <---- Status/performance
   Information     Data Translator(s)       Information
                           |
     -------------------------------------------------
     |               |               |               |
   Device          Device          Device          Device
   Local           Local           Local           Local
   Conf(1)         Conf(2)         Conf(3)         Conf(4)

In this figure, the SUPA function matches the 'Configuration Data
Translator'.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Jun 2015 07:48:28 -0700

On Tue, Jun 16, 2015 at 6:07 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > 5) If we need to change metric for existing route - we don't add/delete
> something to/from export/import routing table, we changing property how
> information will be announced, but it will be announced anyway not
> depending on metric, but traffic flow will be changed.
> >

I cannot find any examples of this is the SUPA drafts.

I see this draft:
https://www.ietf.org/id/draft-bi-supa-policy-model-02.txt

This is a hard-written YANG model designed to implement
a specific policy.

> as long as there is a YANG data model, we should be ready to play.

So how does this work.

  P == the policy data model
  P(i) == instance of the policy schema
  T == the target config model
  T(i) == instance of the target schema

Does SUPA generate new schema?

   SUPA(P) = T

Or does it generate an instance document of a known target schema?

  SUPA(P(i) + T)  == T(i)

It is hard for me to see
how draft-strassner-supa-generic-policy-info-model-01.txt
relates to the hand-coded policy models like
draft-bi-supa-policy-model-02.txt.

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jun 2015 17:17:18 +0200

> This is a hard-written YANG model designed to implement

Yep. Not everything is in sync.

> Or does it generate an instance document of a known target schema?

I think it is the later.
 
> draft-bi-supa-policy-model-02.txt.

It does not.

/js

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 16 Jun 2015 15:38:09 +0000

Juegren,

Nothing complicated.
Let's take you example --->"  'drop all SNMP traffic on customer facing links' and generates configuration of the packet filter function (according to the configuration data model for a packet filter). "
So this "high-level policy" or whatever term you like to use, can have a property inside informational model like "security-management" in your example or "traffic-management", "SLA-policy".
In this case lower layer black-box (configuration maker) can decide how to interpret policy. Also it could be the good reference to existing IETF data-models.
Does it make sense?

Best Regards,
Maxim Klyus

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, June 16, 2015 4:49 PM
To: Maxim Klyus
Cc: [email-masked]; Susan Hares
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

A device implements a packet filter (a function) and it implements a YANG configuration data model to configure the packet filter (the data model to configure the function). The generic policy functions we are talking about is taking a high-level policy such as 'drop all SNMP traffic on customer facing links' and generates configuration of the packet filter function (according to the configuration data model for a packet filter).

                Configuration Management

In this figure, the SUPA function matches the 'Configuration Data Translator'.

/js

On Tue, Jun 16, 2015 at 01:32:33PM +0000, Maxim Klyus wrote:
> From: Juergen Schoenwaelder
> [mailto:[email-masked]]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jun 2015 18:21:37 +0200

> So this "high-level policy" or whatever term you like to use, can have a property inside informational model like "security-management" in your example or "traffic-management", "SLA-policy".

Until you tell me how exactly this property helps doing the
translation I am not sure this is useful.

> In this case lower layer black-box (configuration maker) can decide how to interpret policy. Also it could be the good reference to existing IETF data-models.

I believe we have to overcome the notion there there is a black box
doing magic. I rather have the "high-level policy" concrete enough
that the translation does not require black box magic.

The interpretation in the example above is the translation of 'all
SNMP traffic' into a collection of port number / protocol pairs and
the translation of 'all customer facing links' into sets of interfaces
on the various devices in a network.

/js

---

From: John Strassner <[email-masked]>
Date: Tue, 16 Jun 2015 10:56:42 -0700

> as long as there is a YANG data model, we should be ready to play.

I agree with Juergen (except if the coffee maker does decaf, that should
be unsupported :s )

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 16 Jun 2015 11:00:22 -0700

In the figure from RFC3139, I would say that SUPA fits in two places:
   1) Configuration Management Data (High-level Policies)
   2) Configuration Data Translator(s)

At least to me, the first represents the creation of the high-level policy
(e.g., 'drop all SNMP traffic on customer facing links'), while the second
is the actual translation (NOT mapping!) function.

regards,
John

On Tue, Jun 16, 2015 at 6:49 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > As I understand now your suggestion is generalize term in total and do
> not map it to specific technologies at all.
> > Just call it "embedded policy" if we applying configuration to
> standalone NE or let say "group based policy" if it will be applied to the
> set of NE.
> > Am I right?
> > I agree on it, but what I think, it will be useful to specify like an
> attribute or property or subclass in the model for this "embedded policy"
> so lower layers will be able to detect what is inside to decide how to
> interpret policy.
> > > 5) If we need to change metric for existing route - we don't
> add/delete something to/from export/import routing table, we changing
> property how information will be announced, but it will be announced anyway
> not depending on metric, but traffic flow will be changed.
> > >
> > My understanding is that SUPA defines a function that takes policies as
> input and creates configuration snippets as output. If there is a
> configuration data model to do 'stuff' on a device, then I shoud be able to
> use the SUPA framework to write policies expressing where and when to do
> 'stuff' in my network.
> >
> > SUPA is aiming at a generic policy tool, it does not matter whether the
> tools is applied to routing, security, or a fancy coffee maker - as long as
> there is a YANG data model, we should be ready to play.
> >
> > /js
> >
> > --
> > The information transmitted herein is intended only for the person or
> entity to which it is addressed and may contain confidential, proprietary
> and/or privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon, this information by
> persons or entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and delete the material
> from any computer.
>
> --

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 16 Jun 2015 11:12:38 -0700

> Yep. Not everything is in sync.

Agreed. The draft you are referring to Andy was one of the first written.
While it was a start, it was (as you say) hard-coded to a specific policy.
We wanted to build something more generic; hence, the info model
work started.

> I think it is the later.

Case 1: P contains everything it needs (e.g., it knows what SNMP
traffic is, it knows what a customer facing link is, etc.).
Then, SUPA(P) = T
The obvious problem is that SUPA can NOT know everything. So
this can't work.

Case 2: P defines policies. Q defines other things of interest.
Then, SUPA(P+Q) = T
or equivalently, SUPA(P(i) + Q(i)) = T(i)

>It does not.

We didn't have the info model when the above draft was
written, now we do.

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 16 Jun 2015 12:15:56 -0700

I also don't understand the value of the property. It seems
more of a categorization feature than one needed for
actually building or enforcing the policy.

This is why ECA policies are more understood than
intent/declarative/goal policies. The former are easily
translated into algorithmic steps; the latter, if not defined
as something precise (e.g., a logic or calculus) devolves
into (hopefully restricted) English (or a similar language).
And then we DO need a magic black box.

Some people have proposed that there is a middle ground,
where you have "declarative + technology-specific concepts".
This not only defeats the purpose of declarative policy, you
still need a magic black box.

This is why the SUPA info model explores ECA policies
and declarative policies that use formal logic.

regards,
John

On Tue, Jun 16, 2015 at 9:21 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > Let's take you example --->"  'drop all SNMP traffic on customer facing
> links' and generates configuration of the packet filter function (according
> to the configuration data model for a packet filter). "
> > So this "high-level policy" or whatever term you like to use, can have a
> property inside informational model like "security-management" in your
> example or "traffic-management", "SLA-policy".
>
> > In this case lower layer black-box (configuration maker) can decide how
> to interpret policy. Also it could be the good reference to existing IETF
> data-models.
> > Does it make sense?
>

-- 
regards,
John

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 16 Jun 2015 19:51:26 +0000

Juergen,

// Until you tell me how exactly this property helps doing the translation I am not sure this is useful.

 I will try, but it will be some rough example.

In your example you have some conversion to set of interfaces and links.
But in reality will be hard to make such conversion.
Let's say we imagine our network represented by relational database where every NE described very detailed.
And we will take some routers in network like an example.
Router has some modules, interfaces and some logical entities in configuration.
All these objects and router by itself can be related to some specific functions (security/traffic/service ...etc).

So when we make SQL request:

select * from my_network net_object_properties
where my_network.id = net_object_properties.id
my_network,ne_type = router and my_network.ne_type = interface

Imho it's will be useful add in database field something like ---> and net_object_properties.class = security
because in fact may be not all interface objects will be security dependent/related

Our policy type will be predefined - "security" and we know precisely elements we need to change.

Another example SP provides VPN services for customers like silver, bronze, gold... whatever. We decide to change services and service parameters for type gold.
So we need to select NE and NE related objects for this service type and our sql will be:
select * from my_network net_object_properties
where my_network.id = net_object_properties.id
and  net_object_properties_sla_class = gold

As result we will have a collection of elements related to gold service we need to apply new configuration.

Potentially in real network we can have some SDN hierarchy and security, traffic management, service management configuration will be divided/distributed based on function type between different management boxes.
When orchestration addresses policy to central management box it will be good to have such parameter (security....etc) to address our policy to exact underlying box.

The benefits I see:

1) targeting policy
2) policy flexibility
3) intent based policy possibility
4) policy function distribution
5) as I said before it also can be a reference to specific data-model we want to use

Does it work for you?

Best Regards,
Maxim Klyus

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, June 16, 2015 7:22 PM
To: Maxim Klyus
Cc: [email-masked]; Susan Hares
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

> So this "high-level policy" or whatever term you like to use, can have a property inside informational model like "security-management" in your example or "traffic-management", "SLA-policy".

Until you tell me how exactly this property helps doing the translation I am not sure this is useful.

> In this case lower layer black-box (configuration maker) can decide how to interpret policy. Also it could be the good reference to existing IETF data-models.

I believe we have to overcome the notion there there is a black box doing magic. I rather have the "high-level policy" concrete enough that the translation does not require black box magic.

The interpretation in the example above is the translation of 'all SNMP traffic' into a collection of port number / protocol pairs and the translation of 'all customer facing links' into sets of interfaces on the various devices in a network.

/js

---

From: John Strassner <[email-masked]>
Date: Tue, 16 Jun 2015 20:35:11 +0000

Hi Max,

I think I understand you now. You want **Roles**, not attributes. Attributes suffer from being a static list. Roles can be thought of as a view, and enable an object to adapt to the needs of different clients through transparently attached role objects. This enables different contexts to be kept separate. It also has the side effect of being a very useful selection filter.

Riehle, Bäumer, Wulf, and Siberski defined this around 1999 in PLoP. I've used and enhanced it ever since.

Let me know if you can't find their paper, I can dig it up for you.

regards,
John

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Tuesday, June 16, 2015 12:51 PM
To: Juergen Schoenwaelder
Cc: Susan Hares; [email-masked]
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

Juergen,

The benefits I see:

1) targeting policy
2) policy flexibility

Does it work for you?

Best Regards,
Maxim Klyus

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, June 16, 2015 7:22 PM
To: Maxim Klyus
Cc: [email-masked]; Susan Hares
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jun 2015 11:53:09 +0200

But SUPA does not define the policies, an operator does. SUPA defines
how policies can be expressed, that is the input format of the policy
translation function but not the input itself.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jun 2015 12:03:10 +0200

The example policy said:

    drop all SNMP traffic on customer facing links

If you want a policy saying:

    drop all SNMP traffic on all network elements tagged 'security'

then this seems to be a slightly different policy. Perhaps the first
one can be written slightly differently:

    drop all SNMP traffic on all links tagged 'customer'

But note that this is not what you proposed, namely:

  So this "high-level policy" or whatever term you like to use, can
  have a property inside informational model like
  "security-management" in your example or "traffic-management",
  "SLA-policy".

This sounds more like classifying policy rules and with many rules
grouping them may be useful. But I doubt such a classification helps
much with the interpretation. And yes, we need to see how the generic
topology work in I2RS evolves since having ways to properly tag
topology elements will SUPA a lot.

/js

---

From: John Strassner <[email-masked]>
Date: Wed, 17 Jun 2015 18:57:35 +0000

Agreed - SUPA is used by the operator to express policies.

regards,
John

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, June 17, 2015 2:53 AM
To: John Strassner
Cc: Maxim Klyus; Susan Hares; [email-masked]
Subject: Re: [Supa] supa and routing policies - Reformating the reponse

/js