Subject: [Pce] PCE TED alternatives

From: Young Lee <[email-masked]>
Date: Tue, 05 May 2009 16:49:06 -0500

Hi Pcers, 

The revision of the PCE TED alternatives
(draft-lee-pce-ted-alternatives-02.txt) is now available: 

http://www.ietf.org/internet-drafts/draft-lee-pce-ted-alternatives-02.txt

Please note the following changes made in the revision based on inputs from
many folks. 

*         Global change: IGP -> IGP-TE (per Igor) 

*         Section 1.1 

We corrected a statement as follows (per Igor): 

In OSPF the information directly related to IP connectivity (and hence the
control communications plane for all three technologies) and non-IP
advertisements are kept in the link state database (LSDB), while information
related to traffic engineering used by MPLS and GMPLS is kept in a
(conceptually) separate TED which can be considered a subset of the LSDB.

*         Section 2 (per Igor) 

We have added a few new paragraphs that discuss cooperation between IGP-TE
and an alternative method and some advantages/disadvantages of both models.

*         Section 2.1 (Per Fabien)

Architecture Option 3 has changed to: "Nodes send local information to at
least one PCE" from "Nodes send local information to one PCE." This is to
avoid a single point of failure. Section 2.1.3 below elaborates two possible
ways to implement this option. 

*         Section 2.1.1 (per Fabien)

We added a comment on scaling issue to clarify that scaling issue associated
with option 1 may be of a real concern if there are only a few PCEs (e.g.,
two to three PCEs) in the networks. 

*         Section 2.1.3 (per Fabien) 

We have added a new paragraph: "A number of approaches can be used to ensure
control plane resilience in this architecture. (1) Each node can be
configured with a primary and a secondary PCE to send its information to; In
case of failure of communications with the primary PCE the node would send
its information to a secondary PCE (warm standby). (2) Each node could be
configured to send its information to two different PCEs (hot standby)." 

*         Section 2.4 (Per Peng He)

We elaborated PCE TED maintenance procedure: 

The PCE is responsible for creating and maintaining the TED that it will
use. Key functions include: 

1.         Establishing and authenticating communications between the PCE
and sources of TED information. 

2.         Timely updates of the TED with information received from nodes,
peers or other entities. 

3.         Verifying the validity of information in the TED,i.e., ensure
that the network information obtained from nodes or elsewhere is relatively
timely, or not stale. By analogy with similar functionality provided by IGPs
this can be done via a process where discrete "chunks" of TED information
are "aged" and discard when expired. This combined with nodes periodically
resending their local TE information leads to a timely TED. 

*         Section 3.2 and Appendix

We deleted Section 3.2 and the appendix that discuss the protocol and
implementation details. Thus this draft stays as the framework/requirement
draft. We will address protocol enhancements as separate drafts once this
work is accepted as the WG draft. (Per Dan King)

*         We have added a few contributors. 

We'd appreciate your comments and further discussion on this draft. 

Best Regards,

Young & Greg

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 6 May 2009 06:57:02 -0700 (PDT)

Young,

I am afraid you misunderstood one of my comments. Please, see in line.

Cheers,
Igor

________________________________
From: Young Lee <[email-masked]>
To: [email-masked]
Sent: Tuesday, May 5, 2009 5:49:06 PM
Subject: [Pce] PCE TED alternatives

Hi Pcers, 

 
Please note
the following changes made in the revision based on inputs from many folks. 
·         Global change: IGP -> IGP-TE (per
Igor) 
 
·         Section 1.1 

In OSPF the information directly related to IP connectivity
(and hence the control communications plane for all three technologies) and
non-IP advertisements are kept in the link state database (LSDB), while
information related to traffic engineering used by MPLS and GMPLS is kept in a
(conceptually) separate TED which can be considered a subset of the LSDB.

IB>> LSDB contains *all* LSAs (that is, including TE LSAs) exactly the way they were originated or received from the network, This is required by the OSPF flooding/data base synchronization process. However, it is extreamely awkward to use "raw" TE LSAs for the path computation. Indeed, it would be very naive to browse entire TE Link LSA for every link attribute (such as link switching capability) because the corresponding sub-TLV could be placed anywhere in the LSA. Therefore, TE application implementations (at least, I am aware of) normaly keep the TE link and node attributes in a separate structure in a path computation friendly form, which means that TE information is stored twice - raw form within LSDB and "pre-cooked" form in TED. My point is that if one uses a PCE-TED alternative (e.g. extended PCEP), it would be possible to store the TE updates  only in the latter (path computation friendly) form. Which means that not only it will be not
 necessary to keep TED on the nodes where it is not used, but even where it is used (PCEs), it will take half as  much of the memory space compared to the OSPF-TE method.

Cheers,
Igor

·         Section 2 (per Igor) 
 
We have added a few new paragraphs that discuss cooperation
between IGP-TE and an alternative method and some advantages/disadvantages of
both models.
 
·         Section 2.1 (Per Fabien)
 
Architecture Option 3 has changed to: “Nodes send
local information to at least one PCE” from “Nodes send local
information to one PCE.” This is to avoid a single point of failure.
Section 2.1.3 below elaborates two possible ways to implement this option. 
 
·         Section 2.1.1 (per Fabien)
 
We added a comment on scaling issue to clarify that scaling
issue associated with option 1 may be of a real concern if there are only a few
PCEs (e.g., two to three PCEs) in the networks. 
 
·         Section 2.1.3 (per Fabien) 
 
We have added a new paragraph: “A number of approaches
can be used to ensure control plane resilience in this architecture. (1) Each
node can be configured with a primary and a secondary PCE to send its
information to; In case of failure of communications with the primary PCE the
node would send its information to a secondary PCE (warm standby). (2) Each
node could be configured to send its information to two different PCEs (hot
standby).” 
 
·         Section 2.4 (Per Peng He)

The PCE is responsible for creating and maintaining the TED
that it will use. Key functions include: 
 
1.         Establishing and authenticating
communications between the PCE and sources of TED information. 
2.         Timely updates of the TED with
information received from nodes, peers or other entities. 
3.         Verifying the validity of
information in the TED,i.e., ensure that the network information obtained from
nodes or elsewhere is relatively timely, or not stale. By analogy with similar
functionality provided by IGPs this can be done via a process where discrete
"chunks" of TED information are "aged" and discard when
expired. This combined with nodes periodically resending their local TE
information leads to a timely TED. 
·         Section 3.2 and Appendix
 
We deleted Section 3.2 and the appendix that discuss the
protocol and implementation details. Thus this draft stays as the
framework/requirement draft. We will address protocol enhancements as separate
drafts once this work is accepted as the WG draft. (Per Dan King)
 
·         We have added a few contributors. 
 
We’d appreciate your comments and further discussion
on this draft. 
 
Best Regards,
Young & Greg