[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Vishal,
To clarify the process, here's the list of stages a document usually goes
through:
1. WG discussion
2. WG Last Call
3. AD review (may include directorate <-- You are here now
and expert reviews)
4. IETF LC (generally not needed for INFO)
5. IESG review
6. RFC Editor
I received the doc back in Sep 2003 and asked one of the Routing Area
directorate members for an expert review, which resulted in a long list of
comments. We had a long (and admittedly slow) discussion between the reviewer,
me, and the WG chairs in an attempt to distill it to a set of most significant
technical comments and editorial suggestions, which is what I brought back for
consideration by the WG.
On a related note: please do not assume that work is done once a document has
passed the WG LC. It is normal to receive comments from the ADs and IESG.
Regards.
--
Alex
http://www.psg.com/~zinin/
Sunday, March 7, 2004, 1:41:10 PM, Vishal Sharma wrote:
> Adrian,
> I am still very confused about what the debate is about at this point.
> In any case, I would like to defer to my co-authors on this matter.
> As for the enhancements/edits, I think we already stated that we
> could do those.
> -Vishal
>> -----Original Message-----
>> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>> Sent: Sunday, March 07, 2004 3:24 AM
>> To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> Cc: ccamp@ops.ietf.org; Alexey Zinin; Bert Wijnen
>> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>>
>>
>> Thanks for your thoughts Vishal.
>>
>> The debate occurs now.
>>
>> Are the current authors willing and able to make the changes
>> requested by the AD?
>>
>> Thanks,
>> Adrian
>> ----- Original Message -----
>> From: "Vishal Sharma" <v.sharma@ieee.org>
>> To: "Adrian Farrel" <adrian@olddog.co.uk>; "Greg Bernstein"
>> <gregb@grotto-networking.com>;
>> "Eric Mannie" <eric_mannie@hotmail.com>
>> Cc: <ccamp@ops.ietf.org>; "Alexey Zinin" <azinin@psg.com>; "Bert Wijnen"
>> <bwijnen@lucent.com>
>> Sent: Sunday, March 07, 2004 12:48 AM
>> Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>>
>>
>> > Adrian,
>> >
>> > Thanks for the clarification. Our (the authors) understanding is
>> > that the draft had passed (quite a while back, in May 2002
>> > actually, after we had addressed the very last round of comments from
>> > Kireeti), all of the processes in the WG needed to advance it to
>> > informational RFC.
>> >
>> > Its purpose is really to provide an overall view and framework for
>> > SDH/SONET control using an IP/MPLS control plane.
>> >
>> > So it would be useful for us to know exactly where the debate occurred,
>> > since we were not aware of it.
>> > (As far as the WG is concerned, the draft was approved such a while
>> > back that it has been a completed item for over one-and-a-half years.)
>> >
>> > At the last discussion on it in Sept. 2003, we were told that the only
>> > reason it had got delayed was because it somehow missed being
>> sent to the
>> > ADs on time.
>> >
>> > -Vishal
>> >
>> > > -----Original Message-----
>> > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
>> > > Behalf Of Adrian Farrel
>> > > Sent: Saturday, March 06, 2004 3:11 PM
>> > > To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> > > Cc: ccamp@ops.ietf.org; Alexey Zinin
>> > > Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>> > >
>> > >
>> > > Vishal,
>> > >
>> > > The process is that the WG hands the draft off to the AD to take
>> > > it to the IESG. At this
>> > > point the AD performs a review before taking the draft to the
>> > > IESG and this is what we are
>> > > seeing the results of.
>> > >
>> > > Note that this particular draft has been under "AD watch" for a
>> > > while. Alex may want to
>> > > clarify the reason for this, but my understanding is that there
>> > > was some debate as to
>> > > whether the draft had served its purpose already (that is, as a
>> > > design document for the
>> > > other drafts on SONET/SDH) or whether it should continue and
>> > > become an RFC. This review is
>> > > the next step towards becoming an RFC.
>> > >
>> > > Cheers,
>> > > Adrian
>> > >
>> > > ----- Original Message -----
>> > > From: "Vishal Sharma" <v.sharma@ieee.org>
>> > > To: "Adrian Farrel" <adrian@olddog.co.uk>; "Greg Bernstein"
>> > > <gregb@grotto-networking.com>;
>> > > "Eric Mannie" <eric_mannie@hotmail.com>
>> > > Cc: <ccamp@ops.ietf.org>; "Alexey Zinin" <azinin@psg.com>
>> > > Sent: Saturday, March 06, 2004 8:41 PM
>> > > Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>> > >
>> > >
>> > > > Adrian et al,
>> > > >
>> > > > We will work on the document and make the appropriate modifications
>> > > > to incorporate the comments.
>> > > >
>> > > > BTW, Alex could you please clarify whether this is an IESG review
>> > > > or some other review?
>> > > >
>> > > > Our understanding after the last communication with Kireeti on this
>> > > > subject, sometime
>> > > > in July last year, was that this draft (after having passed several
>> > > > last calls), was being sent to the IESG for completing the process
>> > > > of advancing to informational RFC.
>> > > >
>> > > > Thanks,
>> > > > -Vishal
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>> > > > > Sent: Saturday, March 06, 2004 4:16 AM
>> > > > > To: greg@ciena.com; Eric Mannie; Vishal Sharma (E-mail 2)
>> > > > > Cc: ccamp@ops.ietf.org
>> > > > > Subject: Re: AD-review comments on
>> draft-ietf-ccamp-sdhsonet-control
>> > > > >
>> > > > >
>> > > > > Greg, Eric, Vishal,
>> > > > > Are you willing and able to pick this draft up again and make the
>> > > > > changes from Alex?
>> > > > >
>> > > > > Thanks,
>> > > > > Adrian
>> > > > >
>> > > > > ----- Original Message -----
>> > > > > From: "Alex Zinin" <zinin@psg.com>
>> > > > > To: <ccamp@ops.ietf.org>
>> > > > > Cc: <Rtg-dir@ietf.org>
>> > > > > Sent: Thursday, March 04, 2004 12:48 PM
>> > > > > 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
>> > > > > >
>> > > > > > 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 ?
>> > > > > >
>> > > > > > 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) ?
>> > > > > >
>> > > > > > 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
>> > > > > >
>> > > > > > 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 ?
>> > > > > >
>> > > > > > Section 6.1:
>> > > > > >
>> > > > > > 6. what does the following sentence brings in the scope of
>> > > this control
>> > > > > > plane framework (and this is even not necessarily true
>> > > when vcat is
>> > > > > > provided over different line cards):
>> > > > > >
>> > > > > > "Note that this inverse multiplexing process can be
>> > > significantly
>> > > > > > easier to implement with SONET/SDH signals rather
>> than packets."
>> > > > > >
>> > > > > > Section 6.3:
>> > > > > >
>> > > > > > 7. "However, if only standard concatenation is supported
>> > > then reporting
>> > > > > > gets trickier since there are constraints on where the
>> > > STS-1s can be
>> > > > > > placed. SDH has still more options and constraints,
>> > > hence it is not
>> > > > > > yet clear which is the best way to advertise
>> bandwidth resource
>> > > > > > availability/usage in SONET/SDH. At present, the
>> GMPLS routing
>> > > > > > protocol extensions define minimum and maximum values
>> > > for available
>> > > > > > bandwidth, which allows a remote node to make some
>> > > deductions about
>> > > > > > the amount of capacity available at a remote link and
>> > > the types of
>> > > > > > signals it can accommodate. However, due to the
>> > > multiplexed nature
>> > > > > > of the signals, the authors are of the opinion that
>> reporting of
>> > > > > > bandwidth particular to signal types rather than as a single
>> > > > > > aggregate bit rate is probably very desirable."
>> > > > > >
>> > > > > > -> the authors do not explain from which perspective
>> > > and the reasons
>> > > > > > this particular bw accounting report is desirable
>> > > (sections 2.4.3 &
>> > > > > > 2.4.8 of GMPLS routing explains how these values are
>> > > used to take
>> > > > > > into account the multiplexing capability of a SONET/SDH
>> > > interface),
>> > > > > > there is no real determination of the missing
>> > > information at remote
>> > > > > > nodes for the establishment of an LSP with a certain
>> > > amount of bw
>> > > > > > (note that it is not an issue of flexible vs standard
>> > > concatenation
>> > > > > > issue but a control plane issue)
>> > > > > >
>> > > > > > Section 7.3:
>> > > > > >
>> > > > > > 8. "This information is specified in three parts [17],
>> each of which
>> > > > > > refers to a different network layer."
>> > > > > >
>> > > > > > The description of the signaling elements shall mention the
>> > > following:
>> > > > > > (section 7.3 refers to [17] but the latter does not
>> > > correspond to the
>> > > > > > description given in this section)
>> > > > > >
>> > > > > > 1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
>> > > > > > which contains three parts: LSP Encoding Type, Switching
>> > > > > Type, G-PID
>> > > > > >
>> > > > > > 2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
>> > > > > SENDER_TSPEC/FLOWSPEC
>> > > > > > which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT,
>> > > > > Transparency,
>> > > > > > Profile
>> > > > > >
>> > > > > > 3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
>> > > > > >
>> > > > > > 4. Local Link Selection e.g. IF_ID_RSVP_HOP Object
>> (as [RFC3473])
>> > > > > >
>> > > > > > ----
>> > > > > >
>> > > > > >
>> > > > > > Editorial:
>> > > > > > ----------
>> > > > > >
>> > > > > > Section 3:
>> > > > > >
>> > > > > > 1. Sometimes this document refers to GMPLS other to MPLS and
>> > > > > > sometimes as above as "extending IP technology"
>> > > > > >
>> > > > > > Section 3.1
>> > > > > >
>> > > > > > 2. "When a packet reaches a core packet LSR, this LSR uses
>> > > the label as
>> > > > > > an index into a forwarding table to determine the next
>> > > hop and the
>> > > > > > corresponding outgoing label (and, possibly, the QoS
>> > > treatment to be
>> > > > > > given to the packet), writes the new label into the
>> packet, and
>> > > > > > forwards the packet to the next hop. "
>> > > > > >
>> > > > > > -> replace "core packet LSR" by "packet LSR"
>> > > > > >
>> > > > > > Section 3.2:
>> > > > > >
>> > > > > > 3. "SDH and SONET are two TDM standards widely used by
>> operators to
>> > > > > > transport and multiplex different tributary signals
>> over optical
>> > > > > > links, thus creating a multiplexing structure,
>> which we call the
>> > > > > > SDH/SONET multiplex. SDH, which was developed by the
>> > > ETSI and later
>> > > > > > standardized by the ITU-T [4], is now used worldwide,
>> > > while SONET,
>> > > > > > which was standardized by the ANSI [5], is mainly used
>> > > in the US.
>> > > > > > However, these two standards have several similarities,
>> > > and to some
>> > > > > > extent SONET can be viewed as a subset of SDH.
>> Internetworking
>> > > > > > between the two is possible using gateways.
>> > > > > >
>> > > > > > Should be rather as "ITU-T SDH (G.707) includes both
>> > > the European
>> > > > > > ETSI SDH hierarchy and the USA ANSI SONET hierarchy
>> > > (T1.105)." [...]
>> > > > > > "The ETSI SDH and SONET standards regarding frame
>> structures and
>> > > > > > higher order multiplexing are the same. There are
>> some regional
>> > > > > > differences on the terminology, on the use of some
>> > > overhead bytes,
>> > > > > > and lower order multiplexing. Interworking between
>> the two lower
>> > > > > > order hierarchies is possible using gateways."
>> > > > > >
>> > > > > > Section 3.2
>> > > > > >
>> > > > > > 4. "In addition, a pointer (in the form of the H1, H2
>> and H3 bytes)
>> > > > > > indicates the beginning of the VC/SPE in the payload of
>> > > the overall
>> > > > > > STM/SDH frame."
>> > > > > >
>> > > > > > -> replace "STM/SDH frame" by "STM/STS frame"
>> > > > > >
>> > > > > > Section 4.1
>> > > > > >
>> > > > > > 5. "The SONET case is a bit difficult to explain since,
>> > > unlike in SDH,
>> > > > > > SPEs in SONET do not have individual names." they are
>> > > > > simply referred
>> > > > > > to as VT-N SPE
>> > > > > >
>> > > > > > Section 6:
>> > > > > >
>> > > > > > 6. Since this document distinguishes between "optical
>> > > networks", TDM,
>> > > > > > and WDM it would advisable to avoid the "optical TDM"
>> > > as mentioned
>> > > > > > in the below sentence (it has another meaning than MSn/RSn
>> > > > > switching)
>> > > > > >
>> > > > > > Section 6.1:
>> > > > > >
>> > > > > > 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE
>> > > > > >
>> > > > > > > Section 6.1:
>> > > > > >
>> > > > > > 8. "Standard and flexible concatenations are network
>> services, while
>> > > > > > virtual concatenation is a SONET/SDH end-system
>> service recently
>> > > > > > approved by the committee T1 of ANSI and ITU-T." remove
>> > > "recently
>> > > > > > approved by the committee T1 of ANSI and ITU-T." and
>> > > add the corr.
>> > > > > > reference.
>> > > > > >
>> > > > > > 9. "In one example of virtual concatenation, two end
>> > > systems supporting
>> > > > > > this feature could essentially "inverse multiplex" two
>> > > STS-1s into a
>> > > > > > virtual STS-2c for the efficient transport of 100 Mbps
>> > > > > Ethernet traffic."
>> > > > > >
>> > > > > > -> STS-1-2v instead of "virtual STS-2c"
>> > > > > >
>> > > > > > 10. "Section layer: Preserves all section overhead,
>> > > Basically does not
>> > > > > > touch any of the SONET/SDH bits."
>> > > > > >
>> > > > > > -> replace last part by "Basically does not modify or terminate
>> > > > > > any of the SONET/SDH overhead bits"
>> > > > > >
>> > > > > > left column of the table misses the SDH overhead equivalent
>> > > > > >
>> > > > > > 11. Multiplexing of (?) in the following sentence "To perform
>> > > > > > multiplexing, a SONET network element should be line
>> > > terminating."
>> > > > > >
>> > > > > > Section 6.2:
>> > > > > >
>> > > > > > 12. In the following "Standardized SONET line level protection
>> > > > > techniques
>> > > > > > include: Linear 1+1 and linear 1:N automatic
>> > > protection switching
>> > > > > > (APS) and both two-fiber and four-fiber bi-directional
>> > > > > line switched
>> > > > > > rings (BLSRs). At the path layer, SONET offers
>> > > uni-directional path
>> > > > > > switched ring protection." the same applies to SDH (to
>> > > be adapted
>> > > > > > using the corr. terminology)
>> > > > > >
>> > > > > > Section 7:
>> > > > > >
>> > > > > > 13. "This VC-4 LSP can, in fact, be established between two non-
>> > > > > > adjacent internal nodes in an SDH network, and later
>> > > > > > advertised by a routing protocol as a new (virtual) link
>> > > > > > called a Forwarding Adjacency (FA)." -> add
>> MPLS-HIERARCHY as
>> > > > > > reference
>> > > > > >
>> > > > > > 14. The following paragraph
>> > > > > > "For instance, the payload of an SDH STM-1 frame
>> does not fully
>> > > > > > contain a complete unit of user data. In fact, the
>> > > user data is
>> > > > > > contained in a virtual container (VC) that is allowed to
>> > > > > float over
>> > > > > > two contiguous frames for synchronization purposes. A
>> > > > > pointer in the
>> > > > > > Section Overhead (SOH) indicates the beginning of the
>> > > VC in the
>> > > > > > payload." mixes SDH with SONET - pointers in SDH
>> in H1/H2/H3
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > >
>> > > >
>> > > >
>> > >
>> >
>> >
>> >