Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control

["Adrian Farrel" <adrian@olddog.co.uk>]

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
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> >
>
>
>