Thanks for your comments. And, sorry for late resposnse.
I feel the contents of "Necessities for Resilience of Control Channels" should be rewritten.
I think contents of other sections could be updated as well.
I'm on rewriting the requirements for the area of control palne robustness or resilience.
Please, look at in-line comments about more detailed things.
----- Original Message -----
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
From Date: 2005-09-01 ?? 7:13:44
To: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>
Subject: Comments on draft-kim-ccamp-cc-protection-04
> I'd like to make some comments on the ID in the subjec.
> In general, there may be several advantages of out-of-fiber over in-
> fiber such as the followings:
>[dc] I don't agree with this sentence. I don't think that there are
>advantes in the usage of out-of-fiber.
> - When using the overhead bytes of SONET/SDH as a control channel,
> in-fiber may require more resources such as HDLC controllers whereas
> out-of-fiber could reduce the number of these resources;
>[dc] This is a strange sentece. SONET/SDH DCC have not been developed for
>GMPLS, are there since several years
>and seems very strange to me to think about a SONET/SDH box that do not
>support DCC processing.
As you guess, to use DCC overhead bytes, HDLC controllers should be considered. However,
in case of out-of-fiber, there is no need to consider resources such as HDLC controllers.
> - In case of only in-fiber, it looks that there is no room or no need
> for protecting control channels. However, out-of-fiber may apply the
> various and effective software based protection schemes;
>[dc] Why there is no room for protecting control channels? Do you have any
>figures about this? The line level DCC is 576 kbps while
>the section DCC is 192 kbps. Do you thing the control traffic will be more
Contro channels are used to carry packets generated from signaling protocols, routing protocols, ,LMP, and so on. I think DCC overhaed bytes could not afford to support the bandwidth of control channels for these control protocols. According to a private document, it is said the bandwidth of IS-IS protocols amount to about 7 or 8 Mbps within a certain AS. I think that DCC overhead bytes will be used for the extremely limited control traffic due to the limitation of bandwidth. DCC overhead bytes could not support routing protocols.
> - In-fiber is difficult to separate control plane from transport
> plane, whereas out-of-fiber is easy to separate control plane;
>[dc] IMHO this is not true and moreover you need to explain why is more
>difficult. Today DCC are widely used to transport management traffic and
>there are no difficulties in order to separate management from data
I agree DCC could be used for management traffic. Even in this case, but, short management traffic could be supported. It is difficult to support long management traffic such as bulky data.
My view is related to whether DCC based in-fiber is not proper in supporting generic control plane requirements, or not. However, I think a possibilty of using DCC overhead bytes as control channels should be considered in control plane.
> - Because in-fiber provides the connection control function only
> within a single fiber, in-fiber could not provide the connection
> control function beyond a single fiber, whereas out-of-fiber has no
> restriction about the number of fibers for the connection control
>[dc] Could you explain me a little bit more this? I don't see anything
>that prevent me to set-up more that one CC on a fiber.
Here, I assumed the in-fiber control channel is used for the only own fiber.
If you think an in-fiber control channel could be used for controlling other fibers, I or you share thought.
Nevertheless, I think there may be a subtle gap bewteen you and me.
Even though in-fiber control channels could be used in controlling physically other fibers, from the view-point of the physically other fibers, I think the control channels are not in-fiber but out-of-fiber.
When the out-of-fiber configuration is used, control channels may be shared
>to handle several fibers
>[dc] IMHO the cc are associated to the TE and not to the fibre, so a single
>CC can serve several TE link and thus several fibre; this is not related on
>how it is implemented.
I think it's okey if we agree that control channels are used to control data channels between adjacent nodes.
>Consequently, to provide the resilience capability of control channels, it
>is reasonable to use out-of-fiber rather than in-fiber for GMPLS.
>[dc] I don't see how the previous sentences can lead to this statement.
>What is reasonable is that the control channels must be resilient but this
>don't implies the fact they should be out-of-fiber.
I agree to your point. I think that it is not good to argue the resilience capability of control channels with in-fiber and out-of-fiber. I will modify these parts in a further document.