[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Alex,
Thank you for taking the time to clarify the process, and for having
the expert review of our document done.
(I think the suggestions and comments will be very valuable in helping
to further improve the document.)
Looking at your note, I think I understood the stages right, and also
understood correctly that changes/enhancements are normal in stages
3-6 as well.
On the other hand, it is my understanding that the debate surrounding
a document (technical aspects, key content, applicability, etc.) is
completed
in stages 1 and 2. In fact, I understand that passing the final WG LC, is
the point that marks the conclusion of such a debate(s).
Thereafter, we essentially try to work to refine and tighten a document
for eventual publication as an RFC, in the appropriate category
(in this case informational). Hence, my confusion.
Is my understanding not correct?
Regards,
-Vishal
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Alex Zinin
> Sent: Wednesday, March 10, 2004 5:38 PM
> To: Vishal Sharma
> Cc: Adrian Farrel; Greg Bernstein; Eric Mannie; ccamp@ops.ietf.org; Bert
> Wijnen
> Subject: 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
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >> >
> >> >
>