Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

From: <[email-masked]>
Date: Sat, 9 Mar 2013 07:47:53 +0000

Hi Bob,

Thanks for your comments!

In the below email you propose to introduce the description of a policy-based admission control (PBAC) architecture in order to respond to the answer about on-path vs off-path policy.
In my opinion if it is to introduce a new policy-based admission control (PBAC) architecture to be used in the context of PCN, then this should be done in another document and not in the draft-ietf-tsvwg-rsvp-pcn.

Regarding the answer about on-path vs off-path policy, in draft-ietf-tsvwg-rsvp-pcn-04 I have included the argumentation that I proposed as answer to the comment on-path vs off-path signaling provided by Ken, and which he actually agreed with!

Best regards,
Georgios

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]<https://xs.utwente.nl/owa/redir.aspx?C=Nbum9aHfj0KVa6QWoWQdUmsGWht4ps8IsUqKQDAPZNk0j8fbXNgdf5bdf_jZa7dRLDi6AlK6wy0.&URL=mailto%3abob.briscoe%40bt.com>]
> Sent: vrijdag 9 november 2012 16:33
> To: Karagiannis, G. (EWI)
> Cc: [email-masked]; [email-masked]; [email-masked]; EARDLEY, Phil
> Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03
>
> Georgios,
>
> I shall post my full review of this draft in the next few days (needs typing up -
> currently scribbled on a paper copy). This email is solely in response to your
> answer about on-path vs off-path policy.
>
> At 18:55 04/11/2012, [email-masked] wrote:
> >So in this case an additional signaling protocol will be needed to be
> >specified that covers the signaling between the PCN-egress-node and the
> >centralized node and between PCN-ingress-node and the centralized node.
> >In PCN we decdided to only focus on the specification of the signaling
> >protocol that completes the feedback loop from PCN-egress-node to
> >PCN-ingress-node and to focus on the signaling protocol used between
> >the edge nodes and the centralized node.
>
> When I/we originally designed CL-PCN over RSVP (2005), the idea was that it
> would fit with the policy-based admission control (PBAC) architecture of
> RFC2753. In this architecture, an Intserv node at the ingress to a domain is
> the policy enforcement point (PEP), and it refers to a logically centralised
> 'policy decision point' (PDP) for decisions on which flows to block/terminate,
> typically using COPS.
>
> To make this doc fit the PBAC framework, all we have to do is:
> * Describe the PCN-ingress only as the PCN-ingress and not as the decision
> point (find 'decision' throughout doc and fix).
> * Add a section saying the PCN-ingress can refer flow admission and
> termination decisions to a central decision point (using e.g. COPS), which will
> respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress
> could itself be the policy decision point.)
> * Refer to this new PBAC section from Section 3.11 giving the admission
> decision procedure.
>
> * Some people might think this means COPS will need new protocol
> elements to carry PCN marking rates to the policy decision point. But PCN
> marking rates are irrelevant to the policy decision: the PCN-ingress just uses
> PCN to determine whether it needs to block or terminate, and it refers to the
> policy decision point for which flows to block/terminate.
>
> * Unfortunately, neither of the two PCN system descriptions [RFC6661,
> RFC6662] describe a PBAC-based case. The architecture [RFC5559] refers to
> the PBAC framework [RFC2753] but unfortunately doesn't spell out how it
> fits. Originally, I referenced PBAC from RFC5559, but just as the PCN w-g was
> closing I realised that (some?) others in the PCN w-g were working under the
> assumption that the only way to talk to a centralised policy node was from
> the egress, possibly without being aware of the contents of RFC2753.
>
> I think it's OK to introduce a new architectural arrangement in this RSVP doc,
> given RFC2753 is specific to the way RSVP works.
>
>
> Bob

---

From: "Black, David" <[email-masked]>
Date: Sat, 9 Mar 2013 13:14:53 -0500

Hi Georgios,

<WG co-chair hat OFF>

I think you've missed the point here:

> In my opinion if it is to introduce a new policy-based admission control (PBAC)
> architecture to be used in the context of PCN, then this should be done in another
> document and not in the draft-ietf-tsvwg-rsvp-pcn.

>> * Refer to this new PBAC section from Section 3.11 giving the admission

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, March 09, 2013 2:48 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

Hi Bob,

Best regards,
Georgios

---

From: <[email-masked]>
Date: Sat, 9 Mar 2013 19:28:19 +0000

Hi David,

Thanks for your comment!

What I meant is that Bob would like to see a description of PCN based PBAC framework in the RSVP over PCN draft

that is not realy specified in any other PCN documents.

In my opinion the RSVP over PCN draft is not the draft that should introduce such a PBAC framework.

Best regards,

Georgios

________________________________
Van: Black, David [[email-masked]]
Verzonden: zaterdag 9 maart 2013 19:14
To: Karagiannis, G. (EWI); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Onderwerp: RSVP PCN and PBAC

Hi Georgios,

<WG co-chair hat OFF>

Thanks,
--David

Hi Bob,

Best regards,
Georgios

---

From: "Black, David" <[email-masked]>
Date: Sat, 9 Mar 2013 17:01:59 -0500

Hi Georgios,

(Still posting as an individual, not a WG co-chair)

Then I guess we disagree on what a framework is, because I agree that a full PBAC framework should not be described in this draft, but I don't view the changes that Bob is asking for (primarily to point out that the PCN edge and the decision point may be separate) as coming close to describing such a framework.

Thanks, --David +++Sent from Blackberry

From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, March 09, 2013 02:28 PM
To: Black, David; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: RSVP PCN and PBAC

Hi David,

Thanks for your comment!

Best regards,

Georgios

Hi Georgios,

<WG co-chair hat OFF>

Thanks,
--David

Hi Bob,

Best regards,
Georgios

---

From: Anurag Bhargava <[email-masked]>
Date: Sun, 10 Mar 2013 19:23:50 -0400

Hi David,

 The point which is not clear is about the need of admission decision
procedure in this draft.
 Whys does this have to be covered here?

Thx
-Anurag

On Sat, Mar 9, 2013 at 1:14 PM, Black, David <[email-masked]> wrote:
> I do not believe that Bob is asking that this draft add a PBAC architecture,
> but rather that minor changes be made so that this draft is consistent with
> the PBAC architectural approach:
>
>
>
> In the below email you propose to introduce the description of a
> policy-based admission control (PBAC) architecture in order to respond to
> the answer about on-path vs off-path policy.
>
> In my opinion if it is to introduce a new policy-based admission control
> (PBAC) architecture to be used in the context of PCN, then this should be
> done in another document and not in the draft-ietf-tsvwg-rsvp-pcn.
>
>
>
> Regarding the answer about on-path vs off-path policy, in
> draft-ietf-tsvwg-rsvp-pcn-04 I have included the argumentation that I
> proposed as answer to the comment on-path vs off-path signaling provided by
> Ken, and which he actually agreed with!
>
>
>
> Best regards,
>
> Georgios
>
>
>
>
>
>> From: Bob Briscoe [mailto:[email-masked]]

-- 
BR,
-Anurag

---

From: "Black, David" <[email-masked]>
Date: Sun, 10 Mar 2013 21:46:53 -0400

>  The point which is not clear is about the need of admission decision procedure in this draft.
>  Why does this have to be covered here?

It's not necessary to cover the detailed decision procedure; it should
suffice to state that admission control decisions are necessary, which
the draft already does in this sentence in Section 1.1:

   The
   PCN-egress-nodes measure the rates of differently marked PCN traffic
   in periodic intervals and report these rates to the Decision Points
   for admission control and flow termination; the Decision Points use
   these rates to make decisions.

The following useful sentence is also in that section that could probably
be expanded to deal with Bob's concerns around the possibility of multiple
decision locations:

   If the PCN decision point is not collocated with the PCN-ingress-node
   then additional signalling procedures are required that are out of
   the scope of this document.

Thanks,
--David

> From: Anurag Bhargava [mailto:[email-masked]]
> Sent: Sunday, March 10, 2013 7:24 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [tsvwg] RSVP PCN and PBAC
> 
> Hi David,
> 
> >> (PBAC)