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.