[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Draft response to ITU-T on VCAT

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.