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

[Alex Zinin <zinin@psg.com>]

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