[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> > >
> > >
> > >
> > >
>
>
>