Liaison statement
Continued Work on GMPLS Signaling for VCAT/LCAS

The IETF CCAMP working group thanks you for your liaison on GMPLS control of
VCAT/LCAS dated February 1st 2008, and received February 29th.

Please find our responses in line.

> Here are our comments to the responses provided in your liaison:
>
> a) Regarding your response to Question 1 on protocol
>    extensibility to encompass technologies other than
>    SONET/SDH, we notice that the recent I-D
>    (draft-ietf-ccamp-gmpls-vcat-lcas-04.txt) limits the
>    number of VCGs per call to one. We support this
>    position and consider this to be a VCAT call.

Thank you. Your support is appreciated.

> b) Regarding your response to Question 4 on multiple calls
>    support, VCAT is viewed as a layer of its own and has its
>    own call controller.
>    As per the interlayer architecture in G.8080 section 6.6,
>    the VCAT call would be associated with a server layer call
>    or calls, each of which would have/own one or more server
>    layer connections.  It is these connections that are part of the
>    VCG. In retrospect, a single call is sufficient for diverse
>    routing as it can hold details of both connections so that they
>    don't use the same resources.
>    An example where multiple server calls associated with one
>    VCAT call would be useful is when all VCAT connections
>    are to be protected.
>    Here, rather than one call maintain the knowledge of all
>    working/protection pairs, it is simpler to have multiple calls
>    each of which only maintains one working/protection pair.
>    This is even more convenient when restoration behavior is
>    applied when the protection connection fails.

We note that in a functional architecture it makes good sense to separate
the VCAT layer from the server/protection layer. We also observe that the
protocol solution does not need to be tied rigidly to the functional
architecture where optimizations may be made from collapsing layers into a
single set of protocol exchanges.

> c) Regarding your response to Question 6 on IP address format in
>    GMPLS, we suggest the I-D clarifies that there are different name
>    (or identifier) spaces even though they may all use the same IP
>    address format, e.g.
>    - Control component
>      The identifiers used to identify the entities that perform the
>      control plane functions, such as route computation, signaling,
>      control plane message delivering, etc.
>    - Transport resource
>      The identifiers used to identify transport resource when they are
>      referred to in the control plane messages. Note that these
>      identifiers may not be the same as those referred to in the
>      management plane messages.
>    - SCN
>      The addresses used to deliver control plane messages
>
>    Examples of a similar address format in use in two different name
>    spaces can be seen in the OSPF routing protocol, where router ID
>    (control and transport link scope) and IP address (used by the
>    forwarder) do not have to be the same.

While we understand that these distinctions are not clear from reading this
particular Internet-Draft, we believe that the distinction is clear from the
weight of GMPLS RFCs. However, we thank you for pointing out that further
clarity could be achieved, and will look at ways to add text to this
document.

The CCAMP working group is currently entering the final phase of work on
this topic. The current version of the draft can be seen at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-05.txt
and we would welcome any final input from ITU-T SG15 before we complete the
publication process. With that in mind, we invite you to review this
document and send us any comments before our November meeting. The response
date to this liaison is set accordingly.

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