Hi,
Please, see my comments in line.
Igor
"5. Section 5.8.2 - Virtual TE-links - We can think of two
different models and are not sure which one is implied in
this document. The first one is that a virtual TE-link
represents server (lower) layer potential connectivity.
The second one is that a virtual TE-link represents
client (upper) layer potential connectivity. The first
one requires knowledge of the adaptation capabilities by
the client (upper) layer. The second does not require any
knowledge of the adaptation capabilities or even the
existence of the server (lower) layer and should also be
a valid configuration. The second option may be required,
for example, when the different layers are administered
by different entities."
The virtual TE-link represents lower layer potential
connectivity. It may be helpful to recap some terminology.
A TE Link is (as discussed in the GMPLS/ASON lexicography set
out in RFC 4397) as logical routing element that allows path
selection to be decoupled from resource assignment. Thus a TE
Link is associated with one or more data links. This is
equivalent to an SNPP link.
A TE Link in one layer may, of course, be achieved by one or
more LSPs in a lower layer. That is, an LSP in one layer may
form a data link in an upper layer.
A Virtual TE Link (again referencing RFC 4397) is a TE Link
associated with zero data links. It is the potential for a TE
Link, that may be used in path computation on the assumption
that, if it is used, an attempt will be made dynamically to
create the necessary data link(s). That is, to signal an LSP
in a lower layer, to designate the LSP as a data link in the
upper layer, and to assign the data link to the TE Link.
Thus, the Virtual TE Link is dynamically converted into an
actual TE Link.
Advertisement of the Virtual TE Link is dependent (just as
with a real TE Link) on the adaptation capabilities at the
end points. The principal differences are that the lower
layer network resources are not tied up when the Virtual TE
Link has not been made real, and that the signaling process
of the upper layer LSP might fail if the Virtual TE Link
cannot be realized.
IB>> The ITU folks are asking here a very good question, and IMO we are
not responding correctly. VC4 connection (server layer) could be
advertised as a TE link in VC12 layer network (client layer). This could
be done only if VC4 resources at the edges of the VC4 trail have the
necessary adaptation capability (that is to adopt VC12 signal). If the
VC12 TE link is advertised, then there is an implicit advertisement that
the client signal (VC12) can be adopted over the server trail (VC4), and
there is no need to advertise VC12/VC4 adaptation capability. Having
said this, it should be noted that the VC12 link advertisement may
contain adaptation capability for *potential clients* of the VC12, so
that a VC12 connection terminated on one of the ends of the advertised
link could be considered for advertising as a TE link into a higher
layer.
So, my answer would be as follows.
As far as client layer network is concerned, there is no difference
between virtual and real TE link. In both cases the link is connectivity
in the client layer (that is, model #2 as it stated in the question).
The link advertisement should not contain adaptation capability for this
client/server pair, but may contain adaptation capability for higher
client/client pair.
The server layer is the only one who distinguishes virtual from real TE
link, because in the latter case the trail is created only when it is
needed, while in the former case it is created proactively. Thus,
virtual TE link is associated with potential connection/trail in the
lower layer (that is, it is not potential connectivity in the lower
layer as stated in the response).
"1. Section 4.1.1.2 - Setting up virtual TE-links. We would
like to understand why the virtual TE-links need to be
created as opposed to discovered, manually or dynamically.
In terms of scalability, could a Virtual TE-link (assuming
it represents server (lower) layer resources) be assigned
a virtual link identifier that may be locally associated
to one or more link identifiers? It is not clear from the
draft whether this is allowed or not but we think it is
essential in developing a scalable solution. In case the
virtual TE-link could represent client (upper) layer
potential connectivity, the identifier would have to be
virtual as it would represent potential adaptation
capability into a server (lower) layer."
First of all, please note again that the requirements for
multi-layer networks under different administrative domains
are out of scope of this document. Advertising the virtual
TE-link into the "client" network, which is under different
administrative domain, is out of scope of this document.
The above question may be separated into three sub-questions
as follows;
Q1-a) Why do the virtual TE-links need to be created as
opposed to discovered, manually or dynamically?
A1-a) It would be possible to automatically discover all
potential connectivity across the lower layer network
and to advertise a full mesh of Virtual TE Links.
However, we believe that this scenario is unlikely to
meet with the requirements of service providers who
will want to apply their own operational policies.
Such operational policies effectively install a
management function (e.g., VNT Manager) between the
analysis of the lower layer network connectivity, and
the advertisement of Virtual TE Links.
Q1-b) Could a Virtual TE-link be assigned a virtual link
identifier that may be locally associated to one or
more link identifiers?
A1-b) In general, data link identifiers can be autogenerated
and "discovered" through information exchange between
adjacent nodes. TE Link identifiers can similarly be
autogenerated, and exchanged and associated with data
links. This, however, presupposes the existence of the
data links when the TE Links are created.
The virtual TE-link represents lower layer potential
connectivity but does not have a lower layer data link
committed.=20
IB>> I disagree. The virtual TE link represents client layer
connectivity but unlike real TE link does not have the trail in the
server layer just yet.
It must still be advertised so that they can
be use in path computation. Virtual TE-link identifiers
are assigned at both end points. They are logical ones
and are not necessarily identical to any identifiers
associated with the real physical interfaces. They may
be picked from a local pool of identifiers at both end
points and exchanged between the both end points. On
the other hand, assigning the identifier associated
with a real physical interface to the Virtual TE-link
is not precluded. Clearly configuration (manual or
through an automated process such as the Virtual
Network Topology Manager) may provide this information
in this case. The use of LMP for exchange of
information for Virtual TE Links is for future study.
Q-c) In case the virtual TE-link could represent client
(upper) layer potential connectivity, the identifier
would have to be virtual as it would represent
potential adaptation capability into a server (lower)
layer?
A1-c) The virtual TE-link does not represent client (upper)
layer potential connectivity.
IB>> Again, see my comment above. Virtual or real TE link in a given
layer represents connectivity in this layer. It is not a potential
connectivity in the lower layer; rather, it is potential connection
(trail) in the lower layer.