Subject: Draft response to ITU-T on VCAT

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 Aug 2008 19:10:40 +0100

Hi CCAMP,

We have a liaison to respond to from the ITU-T on VCAT 
(https://datatracker.ietf.org/liaison/429/).

Please a draft response below.
Comments to me by Friday September 5.

Thanks,
Adrian

=====

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

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