Subject: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt

From: Igor Bryskin <[email-masked]>
Date: Thu, 16 Apr 2009 12:14:54 -0700 (PDT)

Hi,

Here is my comments on  the draft “Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements” http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt 
 
General comments.
 
1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is
worth to make it clear. I know that many people think that IGP-TE is an
extension of IGP for TE purposes, but in fact, the two are completely different
protocols with completely different purposes: one is to dynamically manage IP
forwarding tables, and the other is to discover network resources of various network
layers and use this information for constraint based path computations. The
only thing that the two have in common is that they may share the same instance
of the IGP flooding/synchronization machinery (even this becomes increasingly
untrue: today many use separate instances, look for the OSPF transport instance
and multi-instance activities in the OSPF WG). Other then that, the two
protocols have nothing in common; and this is especially true in the context of
this document. It is quite reasonable to imagine, for example, that within the
PCE Architecture one can completely eliminate use  of IGP-TE by using, say, PCEP instead, to
send local resource updates directly to PCE(s).  However, one will still need IGP for
forwarding control plane traffic. So my point here is that we want alternative
methods to IGP-TE and not to IGP.
 
2. I’d like to see in the draft a discussion on why the
flooding of TE information and the PCE architecture is not a good match. And
this is because flooding of any type of information works well on homogeneous
topologies, where all participants originate, distribute and use the information.
That’s why IP OSPF, for example, works well: all OSPF speakers originate LSAs,
flood local and remote LSAs and use them in route calculations. The PCE
architecture is by definition asymmetrical with respect to the information used
in path computations: many elements originate, but only few use it, and the
flooding under these circumstances could be very inefficient for all these
reasons that you mentioned: memory, CPU, bandwidth, etc.
 
Specific comments:
 
1. You write:
“  This draft does not
advocate that the alternative methods specified 
   in this draft
should completely replace the IGP as the method of 
   creating the TED.”
 
Why not? I mean there is a variety of ways how the
alternative methods could relate to the IGP-TE method of managing TEDs. And I’d
like to see a section describing different use cases and examples of IGP-TE and
the alternatives cooperating with each other. One such use case is, for
example, a network built of simple optical NEs managed by a tiny control plane
that consists of:
1) PCC instance to send updates to remote PCE(s) on local
resources status and also request path computations;
2) Very limited RSVP-TE instance for signaling fully
explicit EROs  provided by the PCE(s).
 
In this case IGP-TE is not involved at all. 
 
There could be different ways how the alternatives can
cooperate with IGP-TE. One such cooperation, as you suggested, could be a split
of what information is distributed by IGP-TE and what via alternatives. For
example, it makes sense to distribute “static” (rarely modified) and sizable
data – e.g. NE switching asymmetricity – via methods other than IGP-TE, while
more frequently changed data via IGP-TE. This could significantly decrease the
IGP-TE information and its footprint on all speakers.
 
Another type of cooperation between the IGP-TE method and
its alternatives is limiting number and type of elements participating in
IGP-TE. Your architectural option #3 requires inter-PCE TED synchronization.
How about interconnecting PCEs into one or more rings  via IP-IP tunnels and use an  instance of IGP-TE over the tunnels for the
sole purpose of TED synchronization between the PCEs?
 
2. You wrote:
 
“In OSPF the information directly related to IP 
   connectivity (and
hence the control communications plane for all 
   three technologies)
is kept in the link state database (LSDB), while 
   additional
information related to traffic engineering used by MPLS 
   and GMPLS is kept
in a (conceptually) separate traffic engineering 
   database (TED)”.
 
This is not accurate. All IP and non-IP advertisements are
stored in LSDB. Additionally, TE info is kept in TED.
 
3. In section 2.0 you describe the advantages of using
alternative to IGP-TE methods. You also need here to clearly state the
disadvantages, which are:
a)  necessity of
mechanisms that we take for granted when use IGP-TE: removal of stale
information, reliable delivery of updates to all participants; recovery after
reboots/crashes/upgrades, etc.
b) additional security concerns;
c) protocol to discover PCEs that are capable and willing to
accept direct updates;
d) protocol to send the updates;
etc.
 
4. Why not PCEP?
 
This is not a requirement document. So I think it would be
beneficial to suggest a solution for the protocol to be used by NEs to send
resource updates to PCE(s). Considering that this protocol is supposed to:
a) discover PCE(s) capable and willing to receive such
updates;
b) maintain sessions between NEs and PCE(s);
c) address all the security concerns  for PCE(s) to accept such updates;
d) guarantee reliable delivery of the updates;
 
why not to extend PCEP for this purpose since it is already
doing all these things?
 
Cheers,
Igor

---

From: Young Lee <[email-masked]>
Date: Thu, 16 Apr 2009 15:24:13 -0500

Hi Igor,

Thanks for your comments on the draft. Please see in-line for my reply.
Thanks. 

Regards,

Young

  _____  

From: Igor Bryskin [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009 2:15 PM
To: Young Lee; [email-masked]
Subject: Comments on draft-lee-pce-ted-alternatives-01.txt

Hi,

Here is my comments on  the draft "Alternative Approaches to Traffic
Engineering Database Creation and Maintenance for Path Computation Elements"

http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt 

General comments.

1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to make
it clear. I know that many people think that IGP-TE is an extension of IGP
for TE purposes, but in fact, the two are completely different protocols
with completely different purposes: one is to dynamically manage IP
forwarding tables, and the other is to discover network resources of various
network layers and use this information for constraint based path
computations. The only thing that the two have in common is that they may
share the same instance of the IGP flooding/synchronization machinery (even
this becomes increasingly untrue: today many use separate instances, look
for the OSPF transport instance and multi-instance activities in the OSPF
WG). Other then that, the two protocols have nothing in common; and this is
especially true in the context of this document. It is quite reasonable to
imagine, for example, that within the PCE Architecture one can completely
eliminate use  of IGP-TE by using, say, PCEP instead, to send local resource
updates directly to PCE(s).  However, one will still need IGP for forwarding
control plane traffic. So my point here is that we want alternative methods
to IGP-TE and not to IGP.

Young>> Yes, we meant IGP, IGP-TE. 

2. I'd like to see in the draft a discussion on why the flooding of TE
information and the PCE architecture is not a good match. And this is
because flooding of any type of information works well on homogeneous
topologies, where all participants originate, distribute and use the
information. That's why IP OSPF, for example, works well: all OSPF speakers
originate LSAs, flood local and remote LSAs and use them in route
calculations. The PCE architecture is by definition asymmetrical with
respect to the information used in path computations: many elements
originate, but only few use it, and the flooding under these circumstances
could be very inefficient for all these reasons that you mentioned: memory,
CPU, bandwidth, etc.

Young>> I agree. This sounds like a helpful discussion within the draft
highlighting the motivation for this work. 

Specific comments:

1. You write:

"  This draft does not advocate that the alternative methods specified 

   in this draft should completely replace the IGP as the method of 

   creating the TED."

Young>> What the statement above meant was for general case. For WSON case,
we see great value considering alternative methods that can replace IGP-TE.
On the other hands, there are applications (as you mentioned in 2) where
current method (IGP-TE) works perfectly well. 

Why not? I mean there is a variety of ways how the alternative methods could
relate to the IGP-TE method of managing TEDs. And I'd like to see a section
describing different use cases and examples of IGP-TE and the alternatives
cooperating with each other. One such use case is, for example, a network
built of simple optical NEs managed by a tiny control plane that consists
of:

1) PCC instance to send updates to remote PCE(s) on local resources status
and also request path computations;

2) Very limited RSVP-TE instance for signaling fully explicit EROs  provided
by the PCE(s).

Young>> Again, I tend to agree with you that these cases would justify PCE
based alternative method. 

There could be different ways how the alternatives can cooperate with
IGP-TE. One such cooperation, as you suggested, could be a split of what
information is distributed by IGP-TE and what via alternatives. For example,
it makes sense to distribute "static" (rarely modified) and sizable data -
e.g. NE switching asymmetricity - via methods other than IGP-TE, while more
frequently changed data via IGP-TE. This could significantly decrease the
IGP-TE information and its footprint on all speakers.

Young>>  Yes, cooperation between IGP-TE and alternative methods can prove
some cases. I was envisioning that IGP-TE would continue distribute existing
TE while WSON related info would be distributed via a new alternative. 

Another type of cooperation between the IGP-TE method and its alternatives
is limiting number and type of elements participating in IGP-TE. Your
architectural option #3 requires inter-PCE TED synchronization. How about
interconnecting PCEs into one or more rings  via IP-IP tunnels and use an
instance of IGP-TE over the tunnels for the sole purpose of TED
synchronization between the PCEs?

Young>> I was thinking a similar method that runs a separate OPSF-TE
instance over the tunnels taking advantage of OSPF's database
synchronization and updates capability with neighbors. 

2. You wrote:

"In OSPF the information directly related to IP 

   connectivity (and hence the control communications plane for all 

   three technologies) is kept in the link state database (LSDB), while 

   additional information related to traffic engineering used by MPLS 

   and GMPLS is kept in a (conceptually) separate traffic engineering 

   database (TED)".

This is not accurate. All IP and non-IP advertisements are stored in LSDB.
Additionally, TE info is kept in TED.

Young>> We can correct this. 

3. In section 2.0 you describe the advantages of using alternative to IGP-TE
methods. You also need here to clearly state the disadvantages, which are:

a)  necessity of mechanisms that we take for granted when use IGP-TE:
removal of stale information, reliable delivery of updates to all
participants; recovery after reboots/crashes/upgrades, etc.

c) protocol to discover PCEs that are capable and willing to accept direct
updates;

etc.

Young>> This is fair to put in the document. That's why if we can re-use
many of the IGP-TE's mechanism (for instance for architectural option #3, we
can re-use OSPF-TE between PCE-PCE for TED synch, etc.). 

4. Why not PCEP?

This is not a requirement document. So I think it would be beneficial to
suggest a solution for the protocol to be used by NEs to send resource
updates to PCE(s). Considering that this protocol is supposed to:

a) discover PCE(s) capable and willing to receive such updates;

why not to extend PCEP for this purpose since it is already doing all these
things?

Young>> This was the original motivation for this work. We need to elaborate
this point in the update. Thanks. 

Cheers,

Igor

---

From: "Daniel King" <[email-masked]>
Date: Mon, 20 Apr 2009 14:42:30 +0100

Hi Young, et al. 

I thought the draft was well written and an interesting area for discussion.
I had the following general comments. 

a) A key goal of the work is to gather necessary network management
information for offline complex path computation. Its logical to assume that
the complex offline path computation might be centralized. It might be worth
stating this as an assumption.

b) We should not get to caught up in the details of proposed mechanisms or
solutions. This is after all an architecture document. 

c) A hybrid approach to performing path computation in the network might be
considered as there is motivation for performing path computation (simple
versus complex) in different parts of the network. All planning and complex
path computation could be performed by the offline and centralized PCE.
Rapid restoration and local repair could then distributed to the local PCEs.
Each distributed PCE can always signal the centralized PCE for
reoptimization after the initial local path computation, in order to request
a path computation that considers more complex constraints. 

d) Fundamentally we should  use the right mechanism to distribute the data
according to where it is needed. If some form of path computation is needed
on LSRs, then in my opinion the necessary information should  be distributed
using the IGPs. We should be careful about recommending a solution that does
not use the IGP at all. In a model where there are many nodes with path
computation capabilities, we effectively need to flood information to each
PCE. The IGPs have been designed for this. If we use PCEP to distribute
information to go in the TED we may end up trying to turn PCEP into a
flooding protocol that replaces the IGPs. 

e) As mentioned in point (b), we should avoid getting into solution details.
As an architecture/requirements document, this draft should maybe not
mention any protocols at all except in the context of what they already do
and are used for. So, discussing using PCEP for data distribution, or
discussing LDAP may be out of scope (even for an Appendix). But it is very
valid to describe the data model, and I think that bit that is not generally
flooded is a distributed database just like in the LDAP model.

f) I made some minor comments and suggestions along the points above as
change modifications in a word document. I will unicast the document to you
shortly. 

Br, Dan.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 21 Apr 2009 10:59:05 -0700 (PDT)

Hi,

In my comments I forgot to mention IMO a very good argument in favor and a strong drive for using an alternative to IGP-TE method for managing TED.

Consider a "network planner" type of applications which try various "what if?" scenarios on network topologies that do not (fully or partially) exist yet but could be provisioned under certain circumstances. These applications , of course, require numerous complex path computations and are great candidates  to play the PCC role. But, as Eve Varma said on the last IETF, our path computations are only as good as our advertisements. So, for a Network Planner it would be quite easy to use PCEP and send the necessary resource state information to a PCE for not yet existing links on behalf of not yet existing NEs, request the path computation(s) and then clean up the PCE's TED. It is much more difficult (if not impossible) to do the same things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then flush them out when they are not needed anymore).

So there are two important byproducts that a PCEP based method of managing TED gives compared to the IGP-TE method:
a) ability to send TE info updates on behalf of unexisting links and NEs;
b) determine the moment when all the necessary TE info is installed in the PCE's TED, and it is possible to request the path computations.

Note that b) in its own right is quite non-trivial problem to solve when one uses the IGP-TE method for the TED management.

Cheers,
Igor

________________________________
From: Greg Bernstein <[email-masked]>
To: Young Lee <[email-masked]>
Cc: Igor Bryskin <[email-masked]>
Sent: Thursday, April 16, 2009 5:37:08 PM
Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt

Great to have help with the editing and concept development!

Cheers

Greg

Young Lee wrote: 
 
Hi Igor,
 
Thanks a lot
for your comments. They are
all valuable ones and we can put most of them in the update. I will
send you
the WORD template of the existing version so that you may be able to
participate editing exercise with other co-authors. Thanks. 
 
Regards,
Young

________________________________

From:Igor Bryskin
[mailto:[email-masked]] 
Sent: Thursday, April
16, 2009
2:15 PM
To: Young Lee; [email-masked]
Subject: Comments on
draft-lee-pce-ted-alternatives-01.txt
 
Hi,

Here is my comments on  the draft “Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements” 
http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt 
 
General
comments.
 
1. Everywhere you say IGP you mean, I am
sure, IGP-TE. It is worth to
make it clear. I know that many people think that IGP-TE is an
extension of IGP
for TE purposes, but in fact, the two are completely different
protocols with
completely different purposes: one is to dynamically manage IP
forwarding
tables, and the other is to discover network resources of various
network
layers and use this information for constraint based path computations.
The
only thing that the two have in common is that they may share the same
instance
of the IGP flooding/synchronization machinery (even this becomes
increasingly
untrue: today many use separate instances, look for the OSPF transport
instance
and multi-instance activities in the OSPF WG). Other then that, the two
protocols have nothing in common; and this is especially true in the
context of
this document. It is quite reasonable to imagine, for example, that
within the
PCE Architecture one can completely eliminate use  of IGP-TE by using,
say, PCEP instead, to send local resource updates directly to PCE(s).
 However, one will still need IGP for forwarding control plane traffic.
So
my point here is that we want alternative methods to IGP-TE and not to
IGP.
 
2. I’d like to see in the draft a discussion
on why the flooding of TE
information and the PCE architecture is not a good match. And this is
because
flooding of any type of information works well on homogeneous
topologies, where
all participants originate, distribute and use the information. That’s
why IP
OSPF, for example, works well: all OSPF speakers originate LSAs, flood
local
and remote LSAs and use them in route calculations. The PCE
architecture is by
definition asymmetrical with respect to the information used in path
computations: many elements originate, but only few use it, and the
flooding
under these circumstances could be very inefficient for all these
reasons that
you mentioned: memory, CPU, bandwidth, etc.
 
Specific comments:
 
1. You write:
“  This draft does not advocate that the
alternative methods
specified 
   in this draft should completely replace
the IGP as the
method of 
   creating the TED.”
 
Why not? I mean there is a variety of ways
how the alternative methods
could relate to the IGP-TE method of managing TEDs. And I’d like to see
a
section describing different use cases and examples of IGP-TE and the
alternatives
cooperating with each other. One such use case is, for example, a
network built
of simple optical NEs managed by a tiny control plane that consists of:
1) PCC instance to send updates to remote
PCE(s) on local resources
status and also request path computations;
2) Very limited RSVP-TE instance for
signaling fully explicit
EROs  provided by the PCE(s).

There could be different ways how the
alternatives can cooperate with
IGP-TE. One such cooperation, as you suggested, could be a split of
what
information is distributed by IGP-TE and what via alternatives. For
example, it
makes sense to distribute “static” (rarely modified) and sizable data –
e.g. NE
switching asymmetricity – via methods other than IGP-TE, while more
frequently
changed data via IGP-TE. This could significantly decrease the IGP-TE
information and its footprint on all speakers.
 
Another type of cooperation between the
IGP-TE method and its
alternatives is limiting number and type of elements participating in
IGP-TE.
Your architectural option #3 requires inter-PCE TED synchronization.
How about
interconnecting PCEs into one or more rings  via IP-IP tunnels and use
an  instance of IGP-TE over the tunnels for the sole purpose of TED
synchronization
between the PCEs?
 
2. You wrote:
 
“In OSPF the information directly related to
IP 
   connectivity (and hence the control
communications plane
for all 
   three technologies) is kept in the link
state database
(LSDB), while 
   additional information related to traffic
engineering used
by MPLS 
   and GMPLS is kept in a (conceptually)
separate traffic
engineering 
   database (TED)”.
 
This is not accurate. All IP and non-IP
advertisements are stored in
LSDB. Additionally, TE info is kept in TED.
 
3. In section 2.0 you describe the advantages
of using alternative to
IGP-TE methods. You also need here to clearly state the disadvantages,
which
are:
a)  necessity of mechanisms that we take for
granted when use
IGP-TE: removal of stale information, reliable delivery of updates to
all
participants; recovery after reboots/crashes/upgrades, etc.
b) additional security concerns;
c) protocol to discover PCEs that are capable
and willing to accept
direct updates;
d) protocol to send the updates;
etc.
 
4. Why not PCEP?
 
This is not a requirement document. So I
think it would be beneficial
to suggest a solution for the protocol to be used by NEs to send
resource
updates to PCE(s). Considering that this protocol is supposed to:
a) discover PCE(s) capable and willing to
receive such updates;
b) maintain sessions between NEs and PCE(s);
c) address all the security concerns  for
PCE(s) to accept such
updates;
d) guarantee reliable delivery of the updates;
 
why not to extend PCEP for this purpose since
it is already doing all
these things?
 
Cheers,
Igor

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

---

From: Peng He <[email-masked]>
Date: Wed, 22 Apr 2009 10:02:06 -0400

Hello Young,

This is definitely a very interesting draft. Have a question here:
you mentioned at page 13 that "One key function is to ensure that the
network information obtained from nodes or elsewhere is relatively
timely, or not stale ";

I'd like to know if you have considered how to make sure the obtained
information is NOT stale? what is the metric to justify it? what is
the bottom line?say, 1 second, or i minute? maybe the question is too
detail :) Thanks a lot.

Regards,
Peng

On Tue, Apr 21, 2009 at 1:59 PM, Igor Bryskin <[email-masked]> wrote:
> Hi,
>
> In my comments I forgot to mention IMO a very good argument in favor and a
> strong drive for using an alternative to IGP-TE method for managing TED.
>
> Consider a "network planner" type of applications which try various "what
> if?" scenarios on network topologies that do not (fully or partially) exist
> yet but could be provisioned under certain circumstances. These applications
> , of course, require numerous complex path computations and are great
> candidates  to play the PCC role. But, as Eve Varma said on the last IETF,
> our path computations are only as good as our advertisements. So, for a
> Network Planner it would be quite easy to use PCEP and send the necessary
> resource state information to a PCE for not yet existing links on behalf of
> not yet existing NEs, request the path computation(s) and then clean up the
> PCE's TED. It is much more difficult (if not impossible) to do the same
> things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then
> flush them out when they are not needed anymore).
>
> b) determine the moment when all the necessary TE info is installed in the
> PCE's TED, and it is possible to request the path computations.
>
> Note that b) in its own right is quite non-trivial problem to solve when one
> uses the IGP-TE method for the TED management.
>
> Cheers,
> Igor
>
> Thanks a lot for your comments. They are all valuable ones and we can put
> most of them in the update. I will send you the WORD template of the
> existing version so that you may be able to participate editing exercise
> with other co-authors. Thanks.
>
>
>
> Regards,
>
> Young
>
>
>
> Here is my comments on  the draft “Alternative Approaches to Traffic
> Engineering Database Creation and Maintenance for Path Computation Elements”
>
> 2. I’d like to see in the draft a discussion on why the flooding of TE
> information. That’s why IP OSPF, for example, works well: all OSPF speakers
> “  This draft does not advocate that the alternative methods specified
>
> relate to the IGP-TE method of managing TEDs. And I’d like to see a section
> it makes sense to distribute “static” (rarely modified) and sizable data –
> e.g. NE switching asymmetricity – via methods other than IGP-TE, while more
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 23 Apr 2009 08:23:23 -0700

Hi Peng, I think Young is out of the office this week.
On the statement "One key function is to ensure that the network 
information obtained from nodes or elsewhere is relatively timely, or 
not stale " .
This is similar to the requirements we see on link state IGPs and seemed 
appropriate here as an important maintenance procedure.

By the way link state IPGs use two mechanisms: (a) link state update 
messages (there is some rate control on how often these can be sent, but 
the latency can be significantly under 1 second), (b) aging of link 
state advertisements (LSAs) -- OSPF terminology --. In the "aging" 
mechanism information gets removed from the TED if not refreshed 
(typically many minutes). However we didn't want to get into 
implementation details.

Best Regards

Greg (trying to fill in for Young)

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 23 Apr 2009 10:46:24 -0700

Dear Greg,
without getting into implementation details I'd add third important
mechanism used by IGPs to maintain reasonably up-to-date LSDB - exchange of
Hello/Keepalive messages between immediate neighbors.

Regards,
Greg

On Thu, Apr 23, 2009 at 8:23 AM, Greg Bernstein <[email-masked]
> wrote:

> information obtained from nodes or elsewhere is relatively timely, or not
> stale " .
> messages (there is some rate control on how often these can be sent, but the
> latency can be significantly under 1 second), (b) aging of link state
> advertisements (LSAs) -- OSPF terminology --. In the "aging" mechanism
> information gets removed from the TED if not refreshed (typically many
> minutes). However we didn't want to get into implementation details.
>
> Best Regards
>
> On Tue, Apr 21, 2009 at 1:59 PM, Igor Bryskin <[email-masked]> <[email-masked]> wrote:
>
>
>  Hi,
>
> From: Greg Bernstein <[email-masked]> <[email-masked]>
> To: Young Lee <[email-masked]> <[email-masked]>
> Cc: Igor Bryskin <[email-masked]> <[email-masked]>
> From: Igor Bryskin [mailto:[email-masked] <[email-masked]>]
> Pce mailing [email-masked]://www.ietf.org/mailman/listinfo/pce
>
>
>
> --

---

From: Peng He <[email-masked]>
Date: Fri, 24 Apr 2009 09:23:51 -0400

Dear Greg,

Got it. Many thanks..

My intent is just to emphasize the not-stale TE info is so important
to the quality of path computation; although above some special
'threshold' value, increasing refreshing rate may have very limited
contribution to improve the path computation quality.

Regards,
Peng

On Thu, Apr 23, 2009 at 11:23 AM, Greg Bernstein
<[email-masked]> wrote:
> On the statement "One key function is to ensure that the network information
> obtained from nodes or elsewhere is relatively timely, or not stale " .

---

From: Young Lee <[email-masked]>
Date: Tue, 28 Apr 2009 11:26:51 -0500

Hi Dan, 

Sorry for my late response. I just got back to office. Please see in-line
for my response to your comments. Thanks.

Regards,
Young

  _____  

From: Daniel King [mailto:[email-masked]] 
Sent: Monday, April 20, 2009 8:43 AM
To: 'Young Lee'
Cc: [email-masked]
Subject: RE: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt

Hi Young, et al. 

Young>> We are not necessarily assuming centralised offline PCE regime in
this draft. As we explore many architecture options that include multiple
PCE options and possibly using some on-line protocols in disseminating TED
related information, I am a little hesitant to state your suggested
assumption. 

Young>> Yes, this document is basically an architecture/framework document.
We are not proposing any particular mechanisms or solutions here. We simply
stated a set of candidate mechanisms/solutions to give a more realistic
perspective. We will clean up the texts in the revision to make sure your
point is addressed. 

Young>> Good point! As you point out, there may be cases where both
node-based PCE and server-based PCE may need to interact. I can also
envision that complex path computation like IA-RWA solely depend on
server-based PCE while quick calculation has to be done at the node level
such as restoration, etc. We can add a section that discusses usage
scenarios. 

Young>> Yes, we are NOT proposing replacement of IGP-TE in favour of
alternative mechanisms. I envision that IGP-TE and the alternative mechanism
would be complementary to each other. It all depends on where path
computation would be done. Route calculation can be done easily at the node
level while WA (Wavelength Assignment) and IV (Impairment Validation) can be
done at the server PCE although all of them can be done at the server level
or at the node level. I envision that whatever is defined in the current
IGP-TE, we should continue to use them using IGP-TE's flooding while new
information may be transported using new mechanism. 

Young>> I think we discussed this issue previously. 

Young>> Thanks for your help! We have a quite a few comments/suggestions so
far for this work. I will put them together in the revision and let the WG
know the changes from the previous version. Look forward to seeing your
modifications. 

Br, Dan.

---

From: Young Lee <[email-masked]>
Date: Tue, 28 Apr 2009 15:21:45 -0500

Hi Igor,

I have a couple of comments on your "network planner" application using
PCEP. 

-          First of all, this is specific to PCEP implementation which we
need to address in the solutions draft once the PCE-TED draft idea has been
accepted in the WG. We need to separate detail discussion on a particular
implementation from the current draft. But I think your suggested
application is worth to revisit once we have a solution draft. 

-          The intention of PCE-TED draft is not necessarily to replace the
whole IGP-TE as information disseminating mechanism but to suggest that
certain applications may warrant alternative methods that can co-exist with
IGP-TE.  We don't want to reinvent the new wheel necessarily with the
current scope of the draft. We would want to stay as "complementary" to
IGP-TE. 

Thanks.

Regards,

Young

  _____  

From: Igor Bryskin [mailto:[email-masked]] 
Sent: Tuesday, April 21, 2009 12:59 PM
To: Greg Bernstein; Young Lee
Cc: [email-masked]
Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt

Hi,

So there are two important byproducts that a PCEP based method of managing
TED gives compared to the IGP-TE method:
a) ability to send TE info updates on behalf of unexisting links and NEs;
b) determine the moment when all the necessary TE info is installed in the
PCE's TED, and it is possible to request the path computations.

Cheers,
Igor

  _____  

Cheers

Greg

Young Lee wrote: 

Hi Igor,

Regards,

Young

  _____  

Hi,

General comments.

Specific comments:

1. You write:

   creating the TED."

2. You wrote:

   database (TED)".

etc.

4. Why not PCEP?

Cheers,

Igor

--

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 29 Apr 2009 09:50:15 -0700 (PDT)

Young.

Please see my comments in line.

Igor

________________________________
From: Young Lee <[email-masked]>
To: Igor Bryskin <[email-masked]>; Greg Bernstein <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, April 28, 2009 4:21:45 PM
Subject: RE: Comments on draft-lee-pce-ted-alternatives-01.txt

Hi Igor,
 
I have a couple of
comments on your “network planner” application using PCEP. 
 
-          First
of all, this is specific to PCEP implementation which we need to address in the
solutions draft once the PCE-TED draft idea has been accepted in the WG. We
need to separate detail discussion on a particular implementation from the
current draft. But I think your suggested application is worth to revisit once
we have a solution draft. 

IB>>
I know you want to avoid to talk about specific solutions to IGP-TE alternative
at this stage. But this is not a requirements document. So IMO it is OK to give
an example of one obvious (at least to me) such solution - extended PCEP -
because:
a)
no matter how TED is managed on the PCE, each NE will have to support the PCC
side of PCEP to take advantage of the remote path computation service, so why use/invent
other protocols?
b)
PCEP already addresses (or at least is supposed to address) such important
aspects as security, reliable and in-order message delivery, client-server
session support, etc.
c)
I also remember discussions in PCE WG about having PCEP provide an opaque
option to deliver arbitrary information between PCC and PCE, everybody agreed
(as I remember) that this is a reasonable and quite easy thing to do; and this
is exactly what we need for the PCE-TED application

 -          The
intention of PCE-TED draft is not necessarily to replace the whole IGP-TE as
information disseminating mechanism but to suggest that certain applications
may warrant alternative methods that can co-exist with IGP-TE.  We don’t
want to reinvent the new wheel necessarily with the current scope of the draft.
We would want to stay as “complementary” to IGP-TE. 

IB>>
I think we need to consider two cases:
1)
All path computations are performed on PCEs (no local path computations)
2)
Some path computations are performed on PCEs, while some locally.
In
case 1) I don't really see why PCE-TED should co-exist with IGP-TE. If two
mechanisms perform exactly the same function, and one is better than the other,
what sense does it make to advertise certain things via one and other things using
the other? It makes perfect sense to me just to pick the better one;
In
case 2) it does make some sense to have IGP-TE and PCE-TED co-exist. One
example of such co-operation is that you can break your optical layer network
into multiple areas in such a way that intra-area paths would not require
optical impairments aware path computations, while inter-area paths should be computed
with optical impairments constraints in mind. So now you can split:
a)
advertising: IGP-TE for all non-impairement related information;
                       
PCE-TED for all impairement related information;
b)
computation: local for intra-area paths; PCE for inter-area paths.

One
last note. My understanding, Young, that you have in mind to use PCE-TED for
all WSON-related information, and IGP-TE for everything else. This path, I
think, is not correct for the following reasons:
a)
as I mentioned above such cooperation only makes sense when you assume that at
least some path computations are performed locally (not via remote PCE);
b)
in the optical layer network link level path computations (what you call
routing without lambda assignment in a hope that somebody else (signaling or
PCE) assign proper lambdas over computed link-level paths) are very impractical
(to say the least) . Because local TEDs won't contain in this case lambda and switching
assymetricity information, local path computations will produce no value, hence
all computations eventually would have to be performed on PCEs which (as I
mentioned above) will make the PCE-TED and IGP-TE cooperation unnecessary.

Cheers,
Igor

Thanks.
 
Regards,
Young

From:Igor Bryskin
[mailto:[email-masked]] 
Sent: Tuesday, April 21, 2009
12:59 PM
To: Greg Bernstein; Young Lee
Cc: [email-masked]
Subject: Re: Comments on
draft-lee-pce-ted-alternatives-01.txt
 
Hi,

Consider a "network planner" type of applications which try various
"what if?" scenarios on network topologies that do not (fully or
partially) exist yet but could be provisioned under certain circumstances.
These applications , of course, require numerous complex path computations and
are great candidates  to play the PCC role. But, as Eve Varma said on the
last IETF, our path computations are only as good as our advertisements. So,
for a Network Planner it would be quite easy to use PCEP and send the necessary
resource state information to a PCE for not yet existing links on behalf of not
yet existing NEs, request the path computation(s) and then clean up the PCE's
TED. It is much more difficult (if not impossible) to do the same things using
IGP-TE (e.g. have unexisting NEs originate TE LSAs and then flush them out when
they are not needed anymore).

So there are two important byproducts that a PCEP based method of managing TED
gives compared to the IGP-TE method:
a) ability to send TE info updates on behalf of unexisting links and NEs;
b) determine the moment when all the necessary TE info is installed in the
PCE's TED, and it is possible to request the path computations.

Cheers,
Igor

From:Greg Bernstein
<[email-masked]>
To: Young Lee
<[email-masked]>
Cc: Igor Bryskin
<[email-masked]>
Sent: Thursday, April 16, 2009
5:37:08 PM
Subject: Re: Comments on
draft-lee-pce-ted-alternatives-01.txt

Cheers

Greg

Young Lee wrote: 
Hi Igor,
 
Thanks a lot for your comments. They are
all valuable ones and we can put most of them in the update. I will send you
the WORD template of the existing version so that you may be able to
participate editing exercise with other co-authors. Thanks. 
 
Regards,
Young

From:Igor Bryskin [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009
2:15 PM
To: Young Lee; [email-masked]
Subject: Comments on
draft-lee-pce-ted-alternatives-01.txt
 
Hi,

General comments.
 
1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to
make it clear. I know that many people think that IGP-TE is an extension of IGP
for TE purposes, but in fact, the two are completely different protocols with completely
different purposes: one is to dynamically manage IP forwarding tables, and the
other is to discover network resources of various network layers and use this
information for constraint based path computations. The only thing that the two
have in common is that they may share the same instance of the IGP
flooding/synchronization machinery (even this becomes increasingly untrue:
today many use separate instances, look for the OSPF transport instance and
multi-instance activities in the OSPF WG). Other then that, the two protocols
have nothing in common; and this is especially true in the context of this
document. It is quite reasonable to imagine, for example, that within the PCE
Architecture one can completely eliminate use  of IGP-TE by using, say,
PCEP instead, to send local resource updates directly to PCE(s).  However,
one will still need IGP for forwarding control plane traffic. So my point here
is that we want alternative methods to IGP-TE and not to IGP.
 
2. I’d like to see in the draft a discussion on why the flooding
of TE information and the PCE architecture is not a good match. And this is
because flooding of any type of information works well on homogeneous
topologies, where all participants originate, distribute and use the
information. That’s why IP OSPF, for example, works well: all OSPF
speakers originate LSAs, flood local and remote LSAs and use them in route
calculations. The PCE architecture is by definition asymmetrical with respect
to the information used in path computations: many elements originate, but only
few use it, and the flooding under these circumstances could be very
inefficient for all these reasons that you mentioned: memory, CPU, bandwidth,
etc.
 
Specific comments:
 
1. You write:
“  This draft does not advocate that the alternative methods
specified 
   in this draft should completely replace the IGP as the
method of 
   creating the TED.”
 
Why not? I mean there is a variety of ways how the alternative methods
could relate to the IGP-TE method of managing TEDs. And I’d like to see a
section describing different use cases and examples of IGP-TE and the
alternatives cooperating with each other. One such use case is, for example, a
network built of simple optical NEs managed by a tiny control plane that
consists of:
1) PCC instance to send updates to remote PCE(s) on local resources
status and also request path computations;
2) Very limited RSVP-TE instance for signaling fully explicit
EROs  provided by the PCE(s).

There could be different ways how the alternatives can cooperate with
IGP-TE. One such cooperation, as you suggested, could be a split of what
information is distributed by IGP-TE and what via alternatives. For example, it
makes sense to distribute “static” (rarely modified) and sizable
data – e.g. NE switching asymmetricity – via methods other than
IGP-TE, while more frequently changed data via IGP-TE. This could significantly
decrease the IGP-TE information and its footprint on all speakers.
 
Another type of cooperation between the IGP-TE method and its
alternatives is limiting number and type of elements participating in IGP-TE.
Your architectural option #3 requires inter-PCE TED synchronization. How about
interconnecting PCEs into one or more rings  via IP-IP tunnels and use
an  instance of IGP-TE over the tunnels for the sole purpose of TED
synchronization between the PCEs?
 
2. You wrote:
 
“In OSPF the information directly related to IP 
   connectivity (and hence the control communications plane
for all 
   three technologies) is kept in the link state database
(LSDB), while 
   additional information related to traffic engineering used
by MPLS 
   and GMPLS is kept in a (conceptually) separate traffic
engineering 
   database (TED)”.
 
This is not accurate. All IP and non-IP advertisements are stored in
LSDB. Additionally, TE info is kept in TED.
 
3. In section 2.0 you describe the advantages of using alternative to
IGP-TE methods. You also need here to clearly state the disadvantages, which
are:
a)  necessity of mechanisms that we take for granted when use
IGP-TE: removal of stale information, reliable delivery of updates to all
participants; recovery after reboots/crashes/upgrades, etc.
b) additional security concerns;
c) protocol to discover PCEs that are capable and willing to accept
direct updates;
d) protocol to send the updates;
etc.
 
4. Why not PCEP?
 
This is not a requirement document. So I think it would be beneficial
to suggest a solution for the protocol to be used by NEs to send resource
updates to PCE(s). Considering that this protocol is supposed to:
a) discover PCE(s) capable and willing to receive such updates;
b) maintain sessions between NEs and PCE(s);
c) address all the security concerns  for PCE(s) to accept such updates;
d) guarantee reliable delivery of the updates;
 
why not to extend PCEP for this purpose since it is already doing all
these things?
 
Cheers,
Igor

--