[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
- To: ccamp@ops.ietf.org
- Subject: Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
- From: George Newsome <gnewsome@ieee.org>
- Date: Wed, 25 Feb 2004 11:18:09 -0500
- User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
All,
My attention was drawn to
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the
following comments.
1) It is not clear to me why there should be any interaction between
connections being provided for the purpose of Virtual Concatenation
(VCAT) and connections being used for any other purpose. The existence
of VCAT is invisible within the network, and should also be invisible to
the connection protocol.
You are quite right when you point out that its perhaps a good idea to
identically route each leg, and explicit routing seems to meet that
need. However, when the goal of VCAT and LCAS is diversity and graceful
degradation, identical routing of each leg is useless. In this case,
there is no other solution than treating each leg as an independent
connection request. That being the case, each leg should always be
treated as an independent connection request, and there can be no single
end to end session associated with that set of connections.
2) The entity that actually controls LCAS is an application; in
particular it is the application that takes the request for a particular
capacity and translates that request in a set of connection requests. In
ITU parlance, that is call processing. As you say, that application can
run on either a network element or a Management System. As connections
can be set up bi-directionally, bi-directional operation of the VCAT
group is a function of call processing; not of the individual connection
requests.
3) LCAS and VCAT groups provide a vivid illustration of the separation
of call processing from connection signaling. As VCAT groups will be
operated for many different purposes, including diverse routing for
graceful degradation, it is not possible to burden the signaling
protocol with LCAS management as there are many signaling sessions - one
for each leg of the VCAT group.
It therefore seems incorrect to consider adding VCAT/LCAS details into
the connection protocol.
Regards
George