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

[<[e-mail]>]

Hi Bob,



Thanks very much for the comments! I think that they are very useful!



It will be very beneficiary for the fast progress of this draft if you would like to contribute as a co-author to this draft and write this additional section that describes "that 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.)"



Best regards,

Georgios



________________________________
Van: Bob Briscoe [[e-mail]]
Verzonden: vrijdag 9 november 2012 16:33
To: Karagiannis, G. (EWI)
Cc: [e-mail]; [e-mail]; [e-mail]; EARDLEY, Phil
Onderwerp: 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, [e-mail] 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



At 12:28 05/11/2012, [e-mail] wrote:
>Hi Ken,
>
>Thank you very much!
>We will try to catch Francois and discuss the last (in line) issue with him!
>
>Best regards,
>Georgios
>
>________________________________________
>Van: ken carlberg [[e-mail]]
>Verzonden: maandag 5 november 2012 13:23
>To: Karagiannis, G. (EWI)
>Cc: [e-mail]; [e-mail]
>Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03
>
>Georgios,
>
> > Georgios: We will try to explain the rationale of why we consider
> that RSVP can only be used for the situation that the
> > decision point is collocated with the PCN-ingress-node. The main
> reason of this is that in the case that the
> > decision point is collocated with the PCN-ingress-node,the
> required signaling protocol used to complete a
> > feedback loop from egress to ingress can be an entirely on-path
> protocol, like what RSVP is.
> > In the situation that the the decision point is a centralized
> node, then the required signaling protocol
> > can be a combination of an on-path and off-path protocol. This is
> because the
> > decision point might not be located on the data path! 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.
> > This is also the reason of why PCN WG decided to only focus on
> the situation that the decision point is
> > collocated with the PCN-ingress-node.
>
>Great, this is helpful, and this is the information that needs to be
>in the draft.
>
> >> 6) This comment is just for you to contemplate -- I'm not
> expecting any changes.
> >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs.
> >> And it seems a lot of this is a carry over from rfc-4860, so in
> a sense you are inheriting an approach that
> >> was agreed to from an earlier effort.  But I wonder in the back
> of my mind, what impact occurs if
> >> an implementor doesn't follow the SHOULD?  Does the design break
> in supporting PCN?
> >> Again, I want to stress that this isnt a show stopper, but I
> would appreciate it if you gave it some thought.
> >
> > Georgios: Yes, in several cases the design might break in supporting PCN.
> > This is also the reason of using SHOULD instead of MAY. Do you
> want us to explain this in more detail in the draft?
>
>well, actually, I was more curious as to why a number of these cases
>are SHOULD instead of MUST.  Again, the SHOULD's in your document
>seem to be a carry-over from rfc-4860 (which set the precedent), so
>its a bit unfair for you to explain what was done in an earlier
>effort.  I just wanted to make sure you gave some thought to the
>subject.  And if things will break if SHOULD is not followed by an
>implementer/configuration, then maybe you should be more stringent
>and change things to MUST.  Perhaps a brief private conversation
>with Francois Le Faucheur will be helpful.
>
>cheers,
>
>-ken

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design