Subject: RE: [PWE3] Correction of my statement regarding PCE.

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 2 Aug 2005 09:39:00 -0400

I am confused on use of PCE in this context.

Can PCE,
1) know about all the QOS info of soft/dynamic links (PWs do go over
tunnels which in turn are soft, i.e. they can be created dynamically for
whatever b/w the underlying PSN can offer) of all the S-PEs between
U-PEs? And handle the rate at which tunnels are created/removed, up/down
sized?

2) handle perhaps millions of PWs - after all PWs are multiplexed over
LSPs, so it is definitely magnitude higher than LSPs that are
anticipated for PCEs to scale with.

/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adrian Farrel
Sent: Tuesday, August 02, 2005 9:18 AM
To: pwe3
Subject: Re: [PWE3] Correction of my statement regarding PCE.

Hi,

Let me build on what Luca says by typing from the front of the PCE WG
meeting (where I should be concentrating on what JP is saying, but there
are limits even to my concentration abilities). Luca is right that
signaling paths is not computing paths.

We also need to distinguish between the different PCE models.

There are hundreds of instances of PCE already deployed in networks
today.
Those PCEs reside with (are part of) LSRs and/or NMSs. That is, a PCE is
a
computation element that supplies a computation result on behalf of a
client that may be closely tied to the computation element.

What the PCE working group is doing is examining other models where the
PCE may be remote from the requesting client. In these models there may
be
"one oracle in the sky" that can see all topology. There may be many
demi-gods that cooperate or operate independently. The demi-gods may
have
limited visibility (i.e. within a domain).

You can cut the cake many ways.

Please read the PCE architecture (see the charter page).

Thanks,
Adrian

----- Original Message ----- 
From: "Luca Martini" <[email-masked]>
To: "pwe3" <[email-masked]>
Sent: Tuesday, August 02, 2005 1:38 PM
Subject: [PWE3] Correction of my statement regarding PCE.

> Now, If Lou Had not derailed my thoughts ...
>
> What I meant to say was that neither RSVP-TE  nor any flavors of LDP
can
> properly solve the problem of computing the shortest path between two
> domains/AS/areas. We will need PCE to produce the computed path ,
which
> could then be signaled by either RSVP or LDP.
>
> I believe that we often do not make the distinction between the C-SPF
> calculation and RSVP-TE.
>
>
> Luca
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>
>

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Aug 2005 00:40:48 +0100

Hi,

I am resisting the obvious "read the architecture I-D" answer, but please
do read the architecture I-D.

> U-PEs? And handle the rate at which tunnels are created/removed, up/down

If the information is knowable, PCE can know it.
How it is collected and passed to PCE might be an interesting discussion.
MPLS-TE is reasonably good at handling "dynamic links" or "tunnels" that
are established with whatever b/w is requested and between many end
points.

Can PCE handle the rate at which tunnels are created/removed/modified?
This is largely an implementation and network architecture question. We
believe that it is possible to build PCE systems that can do this, and
that the protocol and structure will not impede this.

But it is possible that we do not understand the scale of the issue and it
would be appropriate to bring some numbers and associated requirements to
the PCE mailing list.

> anticipated for PCEs to scale with.

Not sure that the total number of PWs is relevant. The rate of arrival of
computation requests might be more relevant as above.

But let us be clear: if paths need to be computed, then they must be
computed by someone. PCE is simply the thing that computes the path, it is
not magic. The PCE architecutre will show you that it is a deployment
issue to decide where those computation elements are positioned. OTOH, if
paths do not need to be computed, then why would you worry about PCE?

Thanks,
Adrian

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

Hi,

Thanks,
Adrian

----- Original Message ----- 
From: "Luca Martini" <[email-masked]>
To: "pwe3" <[email-masked]>
Sent: Tuesday, August 02, 2005 1:38 PM
Subject: [PWE3] Correction of my statement regarding PCE.

can
which

---

From: Dong Jixiong <[email-masked]>
Date: Wed, 03 Aug 2005 11:11:48 +0800

I think it's good if we can distinguish the hierarchy of different entities.
PCE is strong relevant to the routing protocols, such as OSPF. PCE can be
a logical entity,i.e., resides in router to compute routing for routing protocol.
PCE can also be a physical entity, i.e., a routing-computer network element, which
will communicate with router's routing protocols or link status protocols. In generally, 
PCE will tell the computing result to the request sender, then the request sender will initiate 
the signalling with explicit routing information.So it should be only relevant to the routing protocols.
PCE is only a routing computer part of a routing protocol. But now there are requirement that
routing compter part should be indepent of and can be designed and developed respectively.

Up to now, we didn't discuss to introduce OSPF/CSPF in pwe3. So we don't need
to discuss if we should introduce PCE in PWE3.