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

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

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