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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
