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

From: "Diego Caviglia" <[email-masked]>
Date: Thu, 1 Sep 2005 12:13:44 +0200

Hi all,
        I'd like to make some comments on the ID in the subjec.

Section 7

   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.

   - 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?

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

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

[quote]
When the out-of-fiber configuration is used, control channels may be shared
to handle several fibers
[/quote]
[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.

[quote]
Consequently, to provide the resilience capability of control channels, it
is reasonable to use out-of-fiber rather than in-fiber for GMPLS.
[quote/]
[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.

Regards

Diego

---

From: "Kim Young Hwa" <[email-masked]>
Date: Tue, 6 Sep 2005 15:24:34 +0900

Hi, Diego
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.
 
Regards
 
Young

----- Original Message ----- 
From: "Diego Caviglia" <[email-masked]> 
From Date: 2005-09-01 ?? 7:13:44 
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
Cc: 
Subject: Comments on draft-kim-ccamp-cc-protection-04 

>and seems very strange to me to think about a SONET/SDH box that do not 

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.

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

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

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

>CC can serve several TE link and thus several fibre; this is not related on 
 
I think it's okey if we agree that control channels are used to control data channels between adjacent nodes.

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

---

From: "Kim Young Hwa" <[email-masked]>
Date: Tue, 6 Sep 2005 15:45:02 +0900

Maybe, it looks like that there is a problem on sending this email.
I will try it one more.
 
Hi, Diego 

Regards 

Young

---

From: "Kim Young Hwa" <[email-masked]>
Date: Tue, 6 Sep 2005 16:28:03 +0900

Hi, Diego

Regards

Young

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 7 Sep 2005 17:02:26 +0200

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

Regards

Diego

"Kim Young Hwa" <[email-masked]> on 06/09/2005 09.28.03

Please respond to "Kim Young Hwa" <[email-masked]>

To:    <[email-masked]>, <[email-masked]>
cc:

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

[CUT]
>and seems very strange to me to think about a SONET/SDH box that do not

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.

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

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

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