Draft liaison #3 - MRN/MLN

["Adrian Farrel" <[e-mail]>]

Hi,

ITU-T Study Group 15 Question 14 sent us a liaison with some detailed 
questions about the MLN Requirements and Evaluation I-Ds.

The author teams of the two I-Ds have drafted a technical response which I 
have dressed up in suitable liaison-speak.

Please review and send your comments.

The liaison states in a couple of places that updates will be / have been 
made to the I-Ds. I am relying on the document editors to make these changes 
and submit the new revisions by 10th August so that they can be attached to 
the liaison.

The liaison leaves us with the following timeline...

4th August : Post draft liaison to mailing list
10th August : Post any updates to the I-Ds
15th August : Send liaison
6th September : WG last call starts
10th September : ITU-T Q14/15 meet in Stuttgart
20th September : Deadline for responses from the ITU-T
21st September : WG last call ends

Hoping this meets with your approval.

Thanks,
Adrian

===

From     : IETF CCAMP Working Group
To       : ITU-T Study Group 15 Question 14
For      : Action
Deadline : 20 September 2007

Subject  : 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-03.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 will be 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.

"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 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.

"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 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. 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.

"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