[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Hi Alex,
In response to the feedback from the RTG-Area Directorate, please find
attached our responses about how we intend incorporating their
feedback.
BTW, thanks to the Directorate for their careful review of the document
and their feedback, we think it will help improve the doc. further.
Once we receive a confirmation that these additions look good, we
will modify the draft, and repost to the IETF drafts directory (I
am assuming that is the next step), and cc you.
Thanks,
-Vishal, Greg, Eric
> -----Original Message-----
> From: owner-ccamp at ops.ietf.org [mailto:owner-ccamp at ops.ietf.org]On
> Behalf Of Alex Zinin
> Sent: Thursday, March 04, 2004 4:49 AM
> To: ccamp at ops.ietf.org
> Cc: Rtg-dir at ietf.org
> Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> Folks-
>
> Please find below comments from the RTG area directorate that I would
> like the WG to consider.
>
> Thank you.
>
> --
> Alex Zinin
>
> Technical:
> ----------
>
> Section 3.2:
>
> 1. Figure 1 misses the STM-0 branch
Thanks for noticing! We will add this using G.707.
> Section 3.4.3:
>
> 2. In comparison table, PNNI word appears for the first time in this
> document, any specific reason to mention PNNI in a GMPLS context ?
The intent here was just to ask whether a packet-based control
plane was valuable for advanced TDM service provisioning and mgt.
We could reword this to
"Packet-based control plane (like MPLS or PNNI-based) useful?"
> Section 3.5
>
> 3. "New simplified encapsulations could reduce this overhead to as low
> as 3%, but the gain is not huge compared to SDH and SONET, which have
> other benefits as well.)" any reference available for these new
> simplified encapsulation(s) ?
I believe Eric might be able to locate a reference for this. If not, we
will remove in the revised version.
> 4. "Any encapsulation of IP over WDM should at least provide error
> monitoring capabilities (to detect signal degradation), error
> correction capabilities, such as FEC (Forward Error Correction) that
> are particularly needed for ultra long haul transmission, sufficient
> timing information, to allow robust synchronization (that is, to
> detect the beginning of a packet), and capacity to transport
> signaling, routing and management messages, in order to control the
> optical switches."
>
> The first part refers to data plane capabilities, however the
> requirement: the "encapsulation of IP over WDM" should deliver
> the capacity to transport IP based control plane information -
> why is this the case ? an out of band network would also do the
> job and this statement makes thus the implicit assumption that
> data and control plane topology is congruent
This is an accurate observation.
However, since standardization of IP over WDM without SDH/SONET
is beyond scope here, this could be removed. Although, there still
tends to be confusion when there is talk of "putting IP over lambda",
which does not happen directly.
Alternatively, we could reword this to decouple what
is needed in the data plane from what is required in the control plane,
and mention, in fact, that associated signaling is not a requirement
for GMPLS-based control of SDH/SONET networks, merely one option, and
mention non-associated signaling as the other.
> Section 6:
>
> 5. "Due to the increase in information transferred in the routing
> protocol, it may be useful to separate the relatively static
> parameters concerning a link from those that may be subject to
> frequent changes. The current GMPLS routing extensions [12],[13],
> [14] do not make such a separation, however."
>
> it may be thus worth asking the question was the dissemination
> of these quasi-static "link capabilities" using the same rules
> as for any other TE LSA Type 1 sub-TLV the right approach ?