Thank you for bring the PCE drafts to our attention. There has been recent
work in SG15 on layer architecture and control plane discussion on interlayer
A recent Recommendation G.800 “Unified Functional Architecture of Transport
Networks” describes the architecture of transport networks that encompasses
G.805, which is applicable to connection-oriented technologies, and G.809,
which is applicable to connectionless technologies. All three Recommendations
use the term “layer” which refers to the generation, transport and termination
of a particular type of information (or “characteristic information”). While
the use of the term has identical meaning in many cases between SG15 documents
and the PCE drafts, reading the I-Ds with the G.800 definition of layer
suggests that clarification of the terms “higher layer” and “lower layer”
would be helpful. We assume that this is the same as the client-server
relationship in G.800. One implication of this is that a lower (server) layer
does not necessarily imply that the characteristic information transferred is
larger (more bits) than the higher (client) layer. Examples of this would be
an inverse mux layer (e.g., a VCAT layer such as VC-3-3v) to its constituent
layer, or a packet in packet case. Another implication is that the technology
of the higher and lower layer could even be the same (packet in packet).
Regarding draft-ietf-pce-inter-layer-frwk-05.txt, Q12/15 has been discussing
topology representations for multi-layer networks and two models have emerged.
The first represents a layer network with resources strictly in that layer.
If server layers can be used to connect portions of the layer network of
interest, then this can be represented as a link or node, sometime called
pseudo links or pseudo nodes. This appears to be similar to the
representation of the dotted link in the various figures of the I-D.
PCEs can have visibility of individual layers with the potential connectivity.
Multiple layer visibility would be accomplished by putting several layers
into scope of one PCE.
Another representation of the topology is one in which links from all layers
are in the graph and adaptations supported at each link end are represented.
Path computations on this model would be allowed to follow pairs of
adaptations that exist on links such that the ingress and egress layers end up
being the same. Pruning of the graph prior to, or during, the path
calculation by removing links whose ingress/egress layers are not desired, can
improve the efficiency of the calculation.
Restricting PCE visibility to one or subset of the available layers of this
second model is needed for the multiple PCE inter-layer path computation of
section 3.2. It could be done with some type of VNT manager.
Comments by section on draft-ietf-pce-inter-layer-req-06.txt are:
1. Introduction. Current text (in paragraph 3) suggests that the optimization
is required. We suggest that the requirement be phrased as “It is important
to be able to optimize network resource utilization globally…” since there may
be non-technical reasons that prevent global optimization. Similarly, it is
suggested that some brief discussion of resource ownership be included as
administrative/ownership boundaries between layers can affect the ability to
optimize. For example, if a server layer only uses the management plane for
connection establishment (no control plane).
2. Section 3.1.2. It should be clarified that when a PCC makes a request, it
should specify the layer for which it is requesting a path. If there are
several “mono” layers that could satisfy a path request, what indication is
given to the PCE about which to select?
3. Section 3.1.3. It may be helpful to have a depth indicator in the original
PCC request that limits the maximum number of adaptations allowed in the
returned path. Similarly some indicator of how many administrative boundaries
to cross could be useful to contain the cost of a potential path.
An electronic copy of this liaison statement is available at: