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

["Vishal Sharma" <v.sharma@ieee.org>]

Alex,

Great! Thanks for clarifying. I think this clears up my confusion.

We will send a response to the various comments on the list
along the lines you have indicated, and also
start incorporating them appropriately in a revised of the
document, and (I assume) re-post to the IETF drafts directory,
so the document can move forward.

-Vishal

> -----Original Message-----
> From: Alex Zinin [mailto:zinin@psg.com]
> Sent: Thursday, March 11, 2004 2:35 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,
>
>  The technical part of the debate may in general continue up
> until the end of
>  the IESG review. Fortunately there is only a small percentage of
> documents
>  that end up in such situation.
>
>  Pass the WG LC means that the WG is comfortable sending the doc
> to the IESG.
>  However, the AD can bring back feedback for consideration by the
> WG. Possible
>  replies for each comment could be something like "yes, we'll
> address this", or
>  "we discussed this and decided to do that way, because...", or a
> discussion.
>
>  Thanks.
>
> --
> Alex
> http://www.psg.com/~zinin/
>
> Wednesday, March 10, 2004, 8:15:10 PM, Vishal Sharma wrote:
> > 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
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >>