Subject: [Pce] PCE TED work

From: Young Lee <[email-masked]>
Date: Thu, 09 Apr 2009 13:34:13 -0500

Dear fellow PCE working group participants, 

As discussed at the PCE WG meeting at the 74th IETF meeting in San Francisco
we'd like to get feedback on the document: "draft-lee-pce-ted-alternatives".
This document examines alternative and supplementary approaches to creating
and maintaining the Traffic Engineering Database (TED) used by a PCE. In
addition, the document examines areas for potential standardization within
these alternative approaches. This document does not extend or alter any
existing protocols or dictate a particular approach.

The benefits of this document to the PCE working group include:
(a) Further elaboration with examples of the concepts presented in section
4.3 of the PCE Architecture document (RFC4655).

(b) Compares various approaches to achieving the concepts of section 4.3 of
RFC4655.

(c) Points the way for possible future standardization work.

The eventual goal would be for this document to become an informational WG
document/RFC. 

Best Regards

Young and Greg
------------------------------

Message: 2
Date: Wed, 25 Mar 2009 10:07:18 -0500
From: "Bardalai, Snigdho" <[email-masked]>
Subject: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt
To: <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi

I believe capturing this information is important in order to attain a
consistent behavior for the PCC and PCE implementations. Also, this
provides engineering guidelines for system design.

Given that I would propose that we either add solution options to this
ID or create a separate one.

Thanks,

Snigdho

---

From: "Fabien Verhaeghe" <[email-masked]>
Date: Wed, 15 Apr 2009 08:24:18 +0200

Hi Young and Greg,

Here are some comments on draft-lee-pce-ted-alternatives

A) In architecure presented in Figure 3, if one of the PCE fails we loose
information sent by nodes to that PCE.
Each node should send information to at least 2 PCEs to avoid single point
of failure.

B) section "2.1.1. Nodes Send TE Info to all PCEs"

"As the number of PCEs grow we have scaling concerns"

Is it really a concern? How many PCEs do you think may be needed?

C) section "2.2. Nodes Finding PCEs"

In case 3 nodes the selection of the PCE needs to be done so that the load
is correctly balanced among PCEs.

D) Not sure what is the advantage of architecture 2 compared to architecture
1.
At first I thought the advantage was that the node only sent information to
one entity instead of N PCEs.
But since we also need a backup server for resiliency purpose, eventually it
seems to me both architecture
are equivalent.

Actually I think my problem is that I do not see what is the purpose of
having multiple PCEs for one intermediate
server.
I thought the goal of having multiple PCEs (in case 1) was for backup
purpose. This does not seems to be the case for case 2
since the backup is provided by having 2 intermediate server.

E) section "3.2.2. Communication Protocols"

One idea:
Isn't it possible to meet the presented architecture by using IGP over
tunnels.
For case 1 for instance. In figure 1 the characters "|", "-", "/", or "\"
represents some (GRE) tunnels.

You run OSPF (or ISIS) over those tunnels so that there is an adjacency
between each node and the PCE in a dedicated OSPF (or IS-IS) area.
You can rely on regular OSPF/ISIS procedure to send TE information from node
to PCE.

The only OSPF/ISIS trick needed is at the PCE to prevent LSA received from
one node to be sent to other nodes.
I think this it is possible, without having any problem with legacy
OSPF/ISIS node though it needs to be check more deeply.

The advantage would be that it requires none or few protocol extensions.
One drawback is that it offers less flexibilities to target which
information are sent to the PCE and which are not.

BR
Fabien

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Young Lee
> Envoyé : jeudi 9 avril 2009 20:34
> À : [email-masked]
> Objet : [Pce] PCE TED work
> 
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Young Lee <[email-masked]>
Date: Wed, 15 Apr 2009 10:20:01 -0500

Hi Fabien,

Thanks for your valuable comments. Please see in-line for my response. 

Best Regards,
Young

-----Original Message-----
From: Fabien Verhaeghe [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2009 1:24 AM
To: 'Young Lee'; [email-masked]
Subject: RE: [Pce] PCE TED work

Hi Young and Greg,

Young>> I can see your point. Definitely this would enhance resiliency in
case a PCE fails. Since each PCE only has a partial TED information, when a
PCE fails, we may not be able to maintain the complete TED. 

Young>> Each node will need to maintain session to each PCE with this
architecture and this could be burden to the nodes if there are "too many"
PCEs. If we are talking about 2-3 PCEs, the scaling concern may not be a
real issue. 

Young>> Yes. I agree with you. 

Young>> Architecture 2 employs publish/subscribe functionality similar to
BGP route reflectors. P/S server needs not be a PCE although it can be
collocated with a PCE. We definitely need to consider resiliency of P/S
servers as you indicate. 

Young>> You may be right. We are exploring different possibilities in the
draft. We may elaborate advantages/disadvantages for each architecture. 

One idea:

Young>> Sounds a good choice. At this point, we are not proposing any
solution. This draft simply illustrates a set of possible communication
protocols that can implement the proposed architectures. We can add your
tunnels + IGP idea into the text. Ultimately, once this work is approved,
then we can think of implementation details. 

BR
Fabien

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 15 Apr 2009 10:13:17 -0700

Hi all a couple more comments on top of Young's and Fabien's. See inline 
below.

Best Regards

Greg

Young Lee wrote:
> -- snip --
--->> Agree, initially, this is a good place to start especially for 
small WSONs.
> -- snip --
---- Greg >> This case was trying to cover lots of PCE and the scaling 
issue of the NEs talking to the PCEs.
> then we can think of implementation details. 
-- Greg >> The new OSPF multiple-instance drafts could also help in this 
area.
-- snip ---

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: "Bardalai, Snigdho" <[email-masked]>
Date: Wed, 15 Apr 2009 15:40:45 -0500

Hi all,

I agree in terms of a solution this is fairly simple. In addition to the
tunnels and LSA filtering (i.e. PCE filters LSAs over an adjacency with
a PCC) you also need to identify whether the neighbor is a PCC or a PCE
which could be based on the PCE discovery mechanisms.

Regards
Snigdho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Greg Bernstein
Sent: Wednesday, April 15, 2009 12:13 PM
To: Young Lee
Cc: [email-masked]
Subject: Re: [Pce] PCE TED work

below.

Best Regards

Greg

area.
-- snip ---