Liaison statement
Multi-Region and Multi-Layer Networking

The CCAMP working group of the IETF thanks you for your
liaison titled "Follow up Liaison Statement to IETF CCAMP on
Multi-Layer Networking" generated from your May 2007 interim
meeting.

This communication provides answers and explanations in
response to the comments and questions that your liaison
raised.

As previously indicated, the CCAMP working group is ready to
hold a working group last call on these two Internet-Drafts.
However, in view of your comments and interest in this work we
are delaying this last call to allow you to consider our
responses and to provide further comments during your
September interim meeting. Any additional comments that you
supply will be treated as working group last call comments and
handled accordingly.

Working Group last call will complete on 21 September 2007 at
12 noon GMT. Please ensure that any comments are received by
the IETF before that time.

The latest copies of the drafts concerned can be found at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-05.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-03.txt



draft-ietf-ccamp-gmpls-mln-reqs

"1. General - Does this draft apply only to single service
    provider or do you envision it applying when there are
    multiple service providers? The ASON model (G.8080) allows
    for many different configurations of multilayer networks
    ranging from a single provider administering all layers
    and regions to a different provider per layer or region to
    several providers per layer or region. If two layers are
    under different administrative domains because they belong
    to two different providers, the amount of information that
    can be shared between the two domains is more limited than
    in the case where a single provider network provides
    resources at all layers."

A customer network may be provided on top of the GMPLS-based
multi-region/multi-layer network. It is indeed a strong
motivator for the deployment of multi-region/multi-layer
networks as described in Section 3.2 of the draft. This draft
is, however, scoped to the assumption that the control plane
and the data plane are under the responsibility of a single
service provider and so constitute a single administrative
domain. The MRN/MLN suite of documents makes no assumptions
concerning the interfaces with other domains (e.g. UNI,
E-NNI). In particular, the specific problem examined within
the CCAMP MRN/MLN work is the integration of multiple network
layers (that may be from different regions) within the same
administrative domain. Requirements for multiple network
layers under different administrative domains are out of
scope of this document.

It should be noted that the term region used in the MRN/MLN
suite of documents is as per IETF definition (see RFC4206).

The statement has been added to Section 1 to articulate that
this draft is scoped to the requirements for multi-layer
networks under a single control plane and that the
requirements for multi-layer networks under different
administrative domains are out of scope of this document.
But note also that Secitons 1 and 3.3 of this document
reference RFC4726 (A Framework for Inter-Domain
Multiprotocol Label Switching Traffic Engineering) for
interconnection of MRN/MLN TE domains. Another RFC of
possible interest on multilayer-multidomain discusion is
RFC4655 (PCE Architecture).

"2. Section 3 - There is an example of several layers of a
    TDM region. The addition of a VCAT layer example would be
    more complete. For example, VC-4-7v."

Thank you for this suggestion. We have integrated this example
into the I-D.

"3. Section 3.1 - The last paragraph mentions discontinuity
    when crossing a region boundary. We would like to point
    out that the ASON model does not have control plane
    discontinuity when crossing a region boundary as there
    are call controllers at each layer. Call controllers at
    both ends of adaptation into a server (lower) layer
    communicate with each other."

There may be some misunderstanding of the term
"discontinuity". In the context of this section of the draft,
"discontinuity" indicates that it may not be possible to
simply forward the signaling message (i.e. RSVP-TE Path
message) from a node in one layer to a node in the next layer
(even when stitching or 1:1 multiplexing is used) because
there is a necessary change in some of the signaling objects
(for example, the representation of bandwidth) at region
boundaries. We may solve the discontinuity issue in a method
similar to that of ASON by using triggered signaling or any
of the other mechanisms described in this document.

To help clear up the misunderstanding, the last paragraph of
Section 3.1 will be rephrased.

"4. Section 5.3 - Scalability problems can be minimized by
    the use of TED per region in case they are under separate
    administration or for scalability reason."

It is correct to note that the use of a separate TED per
region can improve the scalability. However, part of the
objective of the MRN/MLN work is to allow full visibility
from each network node into all participating layers/regions.
Splitting the TED will not reduce the amount of information
stored or flooded within the network. Indeed, as multiple
switching capabilities can be advertised in a single TE-link
advertisement, the total number of entries in a TED should
not differ much from a single layer network (although each
entry may be a little larger). Furthermore, the number of
TE-link advertisements should not differ much from a single
layer network (although each advertisement may be slightly
larger), thus not putting additional strain on the routing
protocol flooding process. No scalability problems have been
identified.

Section 5.3 will be further clarified.

"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 potential client layer
connectivity that may be achieved through potential server
layer connections. The client layer connectivity is potential
because the TE-link does not actually exist (event though it
is treated in the client layer exactly as though it does
exist). The server layer connections are potential because the
LSPs necessary to support the TE-link have not been set up.

It may be helpful to recap some terminology.

A TE-link is (as discussed in the GMPLS/ASON lexicography set
out in RFC 4397) a 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.

Please note that one of the comments we will be considering
during working group last call is the suggestion to change
the name "virtual TE link" to "potential 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. As far as client layer network is concerned,
there is no difference between virtual and real TE-links.
In both cases the TE-link is connectivity in the client layer,
but (clearly) with a virtual TE-link, although the
connectivity is advertised as if it is real, it is only
potential.

The principal difference between a real TE-link and a virtual
TE-link is that the server layer network resources are not
tied up when the virtual TE-link is not in use, and that the
signaling process of the client layer LSP might fail if the
virtual TE-link cannot be realized (i.e., if the server layer
LSPs cannot be set up).

"6. Section 4.2 - The last paragraph mentions that TE-link
    advertisements may need to provide information about the
    node's internal adaptation capabilities in order to
    perform layer border node functions. It might be worth
    clarifying the instances where this is required versus
    not required. For example, if virtual TE-links are used
    to represent the client (upper) layer connectivity, it is
    not necessary to advertise internal adaptation
    capabilities."

There is no difference with respect to real or virtual TE-
links in this regard, and all TE-links (virtual or otherwise)
must be considered with regard to their switching types and
the adaptation capabilities of their end points.

The adaptation capability, enables a node to discriminate the
remote nodes (and thus allows their selection during a multi-
region path computation) with respect to their adaptation
capability. i.e.,  their capability to terminate LSPs at a
given region.

Please see also RFC4397 for adaptation capability definitions.


draft-ietf-ccamp-gmpls-mln-eval

"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 connections 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 potential connections, and
      the advertisement of virtual TE-links. However,
      nothing precludes from a policy of discovering and
      advertising such a full mesh.

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 potential connectivity
      (as discussed for point 5, above), but does not have a
      server layer trail (i.e., a client layer data link)
      committed. The virtual TE-links 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 identifiers 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 the 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.

Q1-c) In case the virtual TE-link could represent client
      (upper) layer potential connectivity, would the
      identifier have to be virtual as it would represent
      potential adaptation capability into a server (lower)
      layer?

A1-c) As described in A1-b), the identifier of the virtual
      TE-link could be associated with a real physical
      interface. Note, however, that many virtual TE-links
      could exist where there is the physical capacity for
      only one server layer tail at any time. It may be
      convenient to assign each virtual TE-link a different
      identifier.


"2. Section 4.1.1.3 - Traffic disruption minimization during
    FA release. In case disruption is required in the server
    (lower) layer, we think there is also an option to signal
    to the adaptation points and let them re-establish the
    server (lower) layer as opposed to rely on the head-end
    LSRs in the client (upper) layer."

Section 4.1.1.3 does not specify nor preclude any mechanism
to deal with traffic disruption. In the context of the
MRN/MLN, upper layer LSPs may be routed over FAs. For
reasons outside the scope of these documents, an FA may need
to be released or rerouted. This may have a disruptive effect
on the LSPs using this FA in the sense that this would induce
a route change of these upper layer LSPs.

Only the head-end LSR of an (FA-)LSP is responsible for
re-routing or releasing FA-LSPs. As such head-end LSRs
("adaptation points" as stated in the question) are
responsible for rerouting/releasing FA-LSPs and head-end
LSRs of the upper layer LSPs are responsible for rerouting
the LSPs they control. The adaptation points can NOT take
responsibility for rerouting upper layers LSPs over other
(newly established or not) FAs if they are not head-end LSRs
of the upper-layer LSPs but only intermediate LSRs for these
LSPs

The data link created in an upper layer by an FA LSP may be a
protected data link (in the meaning of link level protection
- see RFC 3471). This link level protection may be achieved
by end-to-end protection of the FA LSP, or through any other
LSP protection scheme including LSP restoration. This case
seems to match what you have described, but note that the
process of switching traffic (i.e. the nested LSP) from one
FA LSP to another is likely to cause a small traffic hit in
all but packet/frame technologies.


We would like to thank you for your detailed enquiry into
this topic, and hope that you feel that the discussion has
been fruitful.

Best regards,
Deborah Brungard and Adrian Farrel
IETF CCAMP Co-chairs