RE: Comments on draft-kim-ccamp-cc-protection-04

["Diego Caviglia" <Diego.Caviglia@marconi.com>]

Hi Kim,
        I've some further comments in line.

Regards

Diego



"Kim Young Hwa" <yhwkim@etri.re.kr> on 06/09/2005 09.28.03

Please respond to "Kim Young Hwa" <yhwkim@etri.re.kr>

To:    <Diego.Caviglia@marconi.com>, <ccamp@ops.ietf.org>
cc:

Subject:    RE: Comments on draft-kim-ccamp-cc-protection-04

[CUT]
>
> - 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.
[dc] Actually my point was that every box that is compliant with SDH/SONET
specs is able to process DCC.
So it is not a point to say that "n-fiber may require more resources such
as HDLC controllers" because AFAIK every SONET/SDH box in the
world have that 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

>than that?
>

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.
[dc] I'm sorry but the sentence "I think DCC overhaed bytes could not
afford to support the bandwidth of control channels for these control
protocols" is not enough for a technical discussion.

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.
[dc]I'm sorry again but I don't think that a private doc can be used as
reference for a ID, otherwise I can state that accordingly to a private doc
the bandwidth of IS-IS is less than 1 byte/day.

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

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.
[dc] Usually SW update is done remotely via DCN and DCN is also made by
DCC.  IMHO SW update (a.k.a. sw download) is a long management operation.

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.
[dc] IMHO if you want to do a requirement docs you don't have to suggest
implementation or say the DCC are not good for control plane.  Just write
down the requirements and leave to the developer the choice.

>
> - 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
> function.
>[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.
[dc] So there is a need to make a definition of what in-fiber means.