Subject: COPS doubt

From: "Y.T. Ramanjaneyulu" <[email-masked]>
Date: Tue, 24 Oct 2000 00:01:29 +0530 (IST)

HI,

If already discussed these things then please provide pointers to mail
archives

I am currently working on a Project which involves developing a Label
Switched router in a MPLS domain.The core protocols which are used in this
work are MPLS as the forwarding mechanism  and  RSVP-TE as the signalling
Protocol.Main intention of ours is to provide Qos services to the end users in MPLS
domain.  

I thought of having a Resource manager inside each LSR to manage the
resources locally. We have policies to allow user to consume only certain amount of
bandwidth etc.

PDP generally situated in some remote machine and collecting statistics
from allclients and making descisions .
 
  So in our scenario is it necessary to have a PEP and a PDP (COPS
Protocol) inside the network ???

 Thanx in advance

-- 
Regards
YTR

NOTE:
-----
              P L E A S E   DON'T    R E P L Y   TO THIS  MAIL ID.

*************************
If u want to reply

  please reply to 
[email-masked]

************************

---

From: Ping Pan <[email-masked]>
Date: Tue, 24 Oct 2000 10:20:37 -0400

The way I view the use of COPS in MPLS networking environment is the
same as RIPE being used for BGP route filters in the backbone today.
ISP's can define a bunch of TE policies to map user traffic to some MPLS
LSP's at the network edge. That information is sent to the edge routers
(LSR's or PEP's) via COPS, where a COPS PDP is a UNIX box sitting at NOC
somewhere running COPS daemon. When something is wrong, the LSR's can
notify the PDP via COPS too.

But, IMH, here is something more:
1. COPS PEP should not be put on every routers, only border/edge ones at
best.
2. COPS distributes policies only, and is not a signaling mechanism to
select bandwidth, labels, routing path...
3. People can setup the policy entries from the routers directly without
using COPS.
4. If people actually deploy SNMP with security and set/trap
functionality, that would work too.

Here is a badly out-dated web page on an out-dated ID:
http://www.cs.columbia.edu/~pingpan/projects/policy_cu.html

- Ping

---

From: Dimitrios Pendarakis <[email-masked]>
Date: Tue, 24 Oct 2000 16:47:37 -0400

YTR,

COPS is intended to provide two main benefits:
 - The ability to outsource policy decisions to an external PDP.
 - To allow a PEP to communicate with third party, COPS compliant, PDPs.

To decide whether you need COPS, you should evaluate the relevance of these
benefits to your network, taking into account the complexity of implementing COPS.
In general, an external PDP is necessary if processing requirements of policy
decisions are too high for your LSR, if your LSR lacks the intelligence or the
flexibility to provide the functionality, or if the information needed to make the
decisions is not available locally at the PEP.

If you have already decided you need an external PDP, COPS is certainly a
valid option, if not the most appropriate. However, if you are planning to develop
the PDP on your own, you could also consider other options, such as SNMP
(as pointed out by Ping's earlier mail), LDAP,  etc. In any case, policy decisions
need only be taken at the ingress and egress nodes of an administrative domain.

Regards,

Dimitrios Pendarakis
Tellium, Inc.

---

From: Ping Pan <[email-masked]>
Date: Tue, 24 Oct 2000 17:35:29 -0400 (EDT)

On Tue, 24 Oct 2000, Dimitrios Pendarakis wrote:

> decisions are too high for your LSR, 

I thought LSR's don't need to maintain policy database, that's why we need
to keep it else where and use COPS to pick it up.

> if your LSR lacks the intelligence or the
> flexibility to provide the functionality, 

Wonder which LSR's are you referring to. :-) If LSR's can handle routing
protocols and RSVP, they'd better have a lot of intellengence and
flexibility. :-)

Take care!

- Ping

---

From: Dimitrios Pendarakis <[email-masked]>
Date: Tue, 24 Oct 2000 19:28:50 -0400

Ping,

> to keep it else where and use COPS to pick it up.

I thought you gave an answer to this yourself :-)
Here is a quote from your previous message:
    "3. People can setup the policy entries from the routers directly without
    using COPS."

BTW, is there a flaw in the above reasoning? I am not sure what your exact definition
of a policy database is, but the fact that LSR's "don't need to maintain policy database"
doesn't necessarily imply that we "need to keep it elsewhere and use COPS".
You could apply the reverse argument as well: if the LSR can maintain a policy
database, why can't it make policy decisions locally and avoid the need for COPS?
It's all a matter of relative complexity...

> protocols and RSVP, they'd better have a lot of intellengence and

Not sure what answer you are looking for, but I wasn't referring to any particular
LSR. However, people have talked about policies that one would expect several
LSRs to have difficulty processing locally, especially if the policy decisions have to be
made very frequently. RFC 2753 discusses some examples.

And LSR's which have to do more work on the data plane might be more
pressed to conserve cycles by outsourcing policy decisions :-)

> - Ping

Regards,
Dimitris

---

From: Ping Pan <[email-masked]>
Date: Tue, 24 Oct 2000 21:15:20 -0400

> It's all a matter of relative complexity...

That's true. You're right.

> However, people have talked about policies that one would expect several

Processing packets base on policy (aka, enforcing policy) can consume a
lot of CPU cycles. But this is somewhat different from processing policy
decisions. Actually, I cannot imagine that there will be very frequent
policy exchanges on purpose that can swamp LSR's, otherwise, we should
call it man-made policy flopping and need to write a new draft on policy
dampening. ;-)

> pressed to conserve cycles by outsourcing policy decisions :-)

Take care, man. Just busting your chops. ;-)

- Ping

---

From: Ramanjaneyulu Y T <[email-masked]>
Date: Wed, 25 Oct 2000 10:02:55 +0530 (IST)

Thsnks for your comments. After reading your comments , we came to
the following conclusions.

     * We need some entity to take policy decisions , so this is situated
in LSR, according to RFC 2753 , PDP is situated in LSRs

      * For future expansion , we are planning to use COPS between PDP and
RSVP-TE.

        What do u say?. 

        Thanks once again                                 
                                         Regards
                                        Ramanjaneyulu Y.T. 
 
--------------------------------------------------------------------------------

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 25 Oct 2000 10:26:17 +0200

> 1. COPS PEP should not be put on every routers, only border/edge ones at

Wrong in cases where you want to perform traffic engeneering using MPLS
tunnels.

> select bandwidth, labels, routing path...

It is not a signalling mechanism, but it may initiate the signaling
protocol.

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155

---

From: Ping Pan <[email-masked]>
Date: Wed, 25 Oct 2000 08:53:19 -0400

> in LSR, according to RFC 2753 , PDP is situated in LSRs

That is, you should be able to input policy driectly at the LSR's.

>       * For future expansion , we are planning to use COPS between PDP and

That's a good idea, especially when you have many policy entris to
manage.

- Ping

---

From: Ping Pan <[email-masked]>
Date: Wed, 25 Oct 2000 09:16:35 -0400

> Wrong in cases where you want to perform traffic engeneering using MPLS

Are you suggesting of using COPS instead of RSVP-TE?  Don't. :-)

If you argue to use both RSVP-TE and COPS in the same network for MPLS,
installing COPS in every router is a bad idea for several reasons:

1. Since the control is at PDP's, the PDP's need to know everything
about the network at all time. The information includes routing topology
(both static and dynamic) and resource availability at every link.
Otherwise, you cannot setup explict-routing path for TE.

2. The LSR's (PEP's) need to tell PDP's about path setup every step of
the way, including the processing of new messages (PATH and RESV), as
well as reservation termination or error (RESVTEAR, PATHTEAR, RESVERR
and PATHERR). In a large backbone, you may have as many as 300-400
routers, and thousands of reservation states. What do you think the cost
of message processing and state synchronizing at both PDP's and PEP's
would be?

So, if you want to have any policy control over LSP's, do it at edge.
Policy download may be COPS, but network resource monitoring and
updating should be using OSPF-TE and ISIS-TE, while tunnel setup and
maintenance should be done with RSVP-TE/CR-LDP.

- Ping

---

From: Dimitrios Pendarakis <[email-masked]>
Date: Wed, 25 Oct 2000 10:33:23 -0400

Ping,

I wasn't referring to policy enforcement on individual packets; that you have to
do on the LSR anyway. But some of the policies that have been suggested in
the context of RSVP, like checking customer databases, credit cards, verifying
digital certificates, may require a lot of processing.
I have to admit though that I don't know if and how soon these will become a reality,
and I agree that for MPLS traffic engineering purposes LSR's should have the
appropriate processing power. The remaining issue is where does the information
needed to make a decision reside ...

Take care,
Dimitris