[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Vishal,
I'm cc'ing the RTG-DIR so Dimitri can follow up with you directly if
necessary. Most of the replies are fine, some comments inline below, pls.
Dimitri will follow up on the rest.
Thanks.
--
Alex
http://www.psg.com/~zinin/
Friday, March 26, 2004, 2:51:32 PM, Vishal Sharma wrote:
> Hi Alex,
> We had sent these suggestions for addressing the review
> comments, and were wondering if you could let us know
> if they are adequate.
> If so, we would like to make changes to the document, and
> resubmit to help move it forward.
> Thanks,
> -Vishal
>> -----Original Message-----
>> From: Vishal Sharma [mailto:v.sharma at ieee.org]
>> Sent: Monday, March 15, 2004 4:23 PM
>> To: Alex Zinin; ccamp at ops.ietf.org
>> Cc: Rtg-dir at ietf.org; Greg Bernstein; Eric Mannie; Adrian Farrel;
>> Kireeti Kompella; Bert Wijnen
>> Subject: 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?"
I don't have a strong opinion on this, as PNNI is mentioned for
informational purposes only, it seems.
>> > 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.
I suggest that this part of the text is reworded so it doesn't sound
like a requirement for IP-o-WDM encapsulation (or did you mean it to
sound that way?).
>> > 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 ?
>>
>> From the carriers perspective, the up-to-date dissemination of all link
>> properties is essential and desired. The use of a link-state routing
>> protocol to distribute this information provides timely and efficient
>> delivery. Now, if we got to the point that bandwidth updates happened
>> very frequently, it makes sense, from an efficiency point of view, to
>> separate them out for update. This situation is not yet seen in
>> actual networks, however if GMPLS signaling is put into widespread use
>> then the need could arise.
I have a feeling that if start peeling this onion (separation of more-static vs
more-dynamic info distribution), we'll get into a rat-hole. It is clear that
this direction hasn't been pursued. It is not clear if it will ever be.
How do you guys feel about removing this statement?
EOM