[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >