Thanks for the review. Please see comments below and confirm agreement on proposed actions before we make changes to the document.

Greg & Young

On 2/1/2011 1:09 PM, Adrian Farrel wrote:

Hi authors of draft-ietf-ccamp-rwa-wson-framework, Here is the Routing Directorate review of your draft. Dimitri sent it into the ADs during the IETF last call period, and I would appreciate you handling the comments as if they were last call comments. Most of his points look pretty sound to me, so I think you will need to do another revision. Many thanks, Adrian

-----Original Message----- From: Papadimitriou, Dimitri (Dimitri) [mailto:dimitri.papadimitriou <at> alcatel- lucent.com] Sent: 31 January 2011 23:42 To: dbrungard <at> att.com Cc: danli <at> huawei.com; adrian.farrel <at> huawei.com; stbryant <at> cisco.com Subject: RE: [Rtg Area Wiki] #49 (waiting): Review of

draft-ietf-ccamp-rwa-wson-

framework Hi, Here below my review of this document: o) Section 1. Introduction . State the actual issue(s) when applying current GMPLS (RFC X,Y,Z) to wavelength switched networks to initiate such "framework" otherwise one could think of a BCP

-->  The fundamental new issues raised are: (a) asymmetry of switching nodes, (b) RWA control plane architectural alternatives (particularly including PCE),  (c) optical signal compatibility (for path selection).

The detailed comparison to specific GMPLS RFCs are given in section 6, however we can add a paragraph or two of summary text to the introduction.

. RFC 3945 mention support of wavelength/lambda switching is that different from WSON ? or is the second a special case of the former (note this is how

the

terminology section reads).

--> All "GMPLS" applications fall under the general description provided by RFC3945. The wavelength/lambda switching of RFC3945 is very general, in this document we rigorize the notions with the definition of optical signals in section 3.3 (based on ITU-T definitions). This helps clarify the use of amplifiers and regenerators and their implications for the control plane.
--> can add text to introduction clarifying relation to RFC3945.

. "In order to provision an optical connection (an optical path) through a WSON certain path continuity and resource availability constraints must be met to determine viable and optimal paths through the network." I will come back to this latter but the term "network" is to be qualified in

context

of this document. In particular, afaik aren't there different specifications

of IaDI

and IrDI interfaces.

--> suggest changing "network" to "optical subnetwork".

. "Note that this document focuses on the generic properties of links, switches and path selection constraints that occur in WSONs." in which sense the term "generic" is used in this statement (usually

considered

as application to multiple switching technologies) The main comment concerning this introduction is that the "motivation" (what's the problem) and "positioning" (how it positions ?) shall be clarified.

-->  "Generic" in the sense of those properties of optical networks found across different contexts such as access, metro, and long haul.
--> Suggest changing order of last two sentences of last paragraph of introduction.

o) Section 3.1 . " The number of channels is significantly smaller than the 32 bit GMPLS label space defined for GMPLS, see [RFC3471]. A label representation for these ITU-T grids is given in [Otani] and provides a common label format to be used in signaling optical paths. " This falls into a Section describing (C)WDM links. It would be appropriate to

move

such material into a sub-section describing the corresponding GMPLS/link capabilities. The same remark applies to Section 3.2 and 3.3: it would be appropriate to have a sub-section dedicated to the implication on the control plane (first) and then to GMPLS protocols.

--> This document has been through numerous revisions and last calls and its present structure represents working group consensus. Would not recommend the proposed restructuring at this point in time.

o) Section 3.2 . Transmitter failure isn't specific to "WSON" but implications are the same

or not

? If a DXC transmitter fails clearly the node shall select another outgoing interface.

-->  Your statement is true for a digital cross connect. However for a transparent network the problem would be with the source node and not the optical network.

. "Hence, additional mechanisms may be necessary to detect and differentiate this failure from the others, e.g., one doesn't not want to initiate mesh restoration if the source transmitter has failed, since the optical transmitter will still be failed on the alternate optical path." This example is rather confusing, if a source transmitter fails of course

selecting a

path along that transmitter won't work.

--> See above comments. This text was suggested by another working group chair/AD. We could remove this entire discussion, but that may cause us trouble with a different chair/AD...

o) Section 3.3 . "Note that a number of non-standard or proprietary modulation formats and FEC codes are commonly used in WSONs. For some digital bit streams the presence of Forwarding Equivalence Class (FEC) can be

==> error in text should be "Forward Error Correction"

detected, e.g., in [G.707] this is indicated in the signal itself via the FEC Status Indication (FSI) byte, while in [G.709] this can be inferred from whether the FEC field of the Optical Channel Transport Unit-k (OTUk) is all zeros or not." Please indicate the impact at the control plane level, and GMPLS protocol

level.

--> Will fix error in text.

o) Section 3.4 . "Only a subset of these and their non-impairment related properties are considered in the following sections." How that subset has been selected ? Why not the full set ? Does it mean that

the

GMPLS capabilities will only apply to this subset ?

--> Will change text to read "only the subset of these relevant to the control plane".

. "As the degree of the ROADM increases beyond two it can have properties of both a switch (OXC) and a multiplexer and hence it is necessary to know the switched connectivity offered by such a network element to effectively utilize it. " These constraints are equivalent to link administrative coloring with

combinatorial

combination that can be encoded in their mask. I am not stating this would be more effective than the proposed bit maps but how these constraint differs

from

a MT routing when constraints are induced by node structure or topological considerations.

--> this statement is concerned with the connectivity capabilities of a switch which was modeled via the connectivity matrix mechanism.

o) Section 3.4.2. and 3.4.3 . Are combiners and splitters also controlled by means of GMPLS. Splitter have "fixed connectivity matrix" what is then the role of GMPLS / control plane ?

--> Fixed connectivity devices tend to be used in conjunction with switched devices. Hence their presence is crucial in determining paths.

. Same question applies for combiners.

--> See above.

. The side question how hybrid environment would operate (e.g. GMPLS/OXC with non-GMPLS splitters or combiners)

-->  Would need to use the network management system. Out of our scope.

o) Section 3.4.4 on Fixed Optical Add/Drop Multiplexers appears as a

particular

case of ROADMs not sure whether the need a dedicated sub-section

-->  Suggest leaving the section. Since these are common in optical networks.

o) Section 3.5 . A definition of "transparency" would be more than welcome to understand the remaining part of this sub-section . The statement "they can be more or less "transparent" to an "optical signal" depending on their functionality and/or implementation." should be clarified

-->  The definitions of the different levels of regenerators (from optical amplifiers to 3R) serves to illustrate the somewhat vague concept of "transparency".  There is no formal definition of "transparency" and previous attempts to make one ran into difficulties (not defined by ITU-T, not clear what this would mean when nonlinearities are introduced).

o) Section 3.5.1 . States "What this table also shows by its omission is that no switching or multiplexing occurs at this layer." the "this" refers to ?

--> Will change text to read "What table 2 also shows..."

o) Section 3.5.2 . This section speaks more about regenerators than OEO (whereas this Section entitled OEO Switches). The relationship between OEO and regeneration isn't explicit from the text and should be outlined to ease

understanding/readability

of this part of the document.

-->  Suggest rearranging order of sentences 2 and 3 of this paragraph and rewording a bit to make functionality of OEO switches and their relation to regeneration clearer.

o) Section 3.6 . " In WSONs where wavelength converters are sparse an optical path may appear to loop or "backtrack" upon itself in order to reach a wavelength converter prior to continuing on to its destination." There is a point to clarify here. A physical constraint would generate a loop

that

can only be detected by means of RRO (but it is receiver which breaks the loop not the sender).

--> Yes.  No change to text seems indicated.

o) Section 3.6.1 . It seems from its description that a conversion pool is a particular case of

use of

adjustment descriptor defined in RFC 6001 (that is a general mean to associate resource pools to SC).

--> This is similar in concept, except we are not treating this as a MLN/MRN problem but as a single layer since there is essentially only one level of switching capability.

o) Section 4 . From the description can authors confirm/infirm whether this framework applies to a single "TE domain" thus in practice a single routing area ? or

not ?

--> This document does not address multiple AS issues.

. "It is to be noted that the choice of specific RWA algorithm is out of the scope for this document" The more fundamental question is whether all RWA algorithms can be covered or not by a single set of non-contending extensions/mechanisms or not; this point is to be clarified as whether the proposed framework is "generic" or

further

specialisation is still to be expected ?

-->  There are RWA techniques (not purely algorithms) that utilize distributed mechanisms that do not fit with the GMPLS/PCE signaling and routing paradigm.  However, the combined RWA architecture of 4.1.1 can support any algorithm by definition.  No further specialization is expected.

. Worth mentioning that the RWA problem is NP Complete. Thus "optimality" should more carefully qualified here. More importantly (in the context of this document) which level of sub-optimality is considered as acceptable in terms

of

first rejection/retrial and second rejection/retrial this would provide nice

bounds

on what the control suite should deliver (taking into account what it is

capable to

deliver).

--> Previous editions of this document pointed out the complexity of the RWA problem and to surveys such as

[1]	H. Zang, J. Jue, and B. Mukherjeee, “A review of routing and wavelength assignment approaches for wavelength-routed optical WDM networks,” Optical Networks Magazine, 2000.

that show the types algorithms and situations that can arise. Such information was removed at the request of WG chairs and/or ADs.

o) Section 4.1.3 . It is required to distinguish signaling of unidirectional vs bidirectional

path and

emphasize that the issue it is the upstream assignment in bi-dir LSP which is issuing blocking not the downstream label one (indeed on the downstream direction label assignment can't be blocking in terms of continuity otherwise there no wavelength left for such assignment). The true problem is the

upstream

label assignment and the error issued (cf. Acceptable Label Set) never sorted

out

actually -- just for the record: <http://tools.ietf.org/html/draft-oki-ccamp- upstream-labelset-00>

--> acknowledged.

o) Section 4.2 . "Utilize incremental updates if feasible." of which information assuming one refers to routing information here ? are incremental updates intended to decrease the number of state updates or the rate of updates ?

--> "incremental" updates of link information, particularly available bandwidth. Can remove this statement if desired.

o) Section 5.2 . "The calculation of optical impairment feasible routes is outside the scope of this document. In general impairment feasible routes serve as an input to RWA algorithm. It is advisable to qualify what is an "impairment" vs "optical impairment"

against

a constraint induced by regeneration, conversion used to elevate these impairments.

==> Error in text. All impairments we are talking about are optical. Will insert the word "optical".

o) Section 6.2.1 . " 4. Acceptable G-PID list: a list of G-PIDs corresponding to the "client" digital streams that is compatible with this device." Why is this a problem when "client devices" (e.g. routers in Fig.7) advertise

their

G-PID (see RFC 4202).

-->  This is a reminder that GPID can be important for optical networks too.  Optical networks are not necessarily as "transparent" as people are led to believe.

o) Section 6.2.3 . " 1. These are the per port wavelength restrictions of an optical device such as a ROADM and are independent of any optical constraints imposed by a fiber link." The term "per port" seems to contradict the description and the actual

attribute

association. See also above comment concerning this "restriction".

--> This statement is clarifying the difference between the source of the wavelength restriction (i.e. the ROADM versus the fiber).  Can remove if desired.

. "4. Not necessarily needed in the case of distributed wavelength assignment via signaling." The fundamental question isn't answered the combined RWA and separate RWA are by definition centralized and global approaches (the computing node has complete topology information and computes all paths even those for which it isn't the source) -> why delocalizing them on each node makes the assumption that the information exchange should de-facto rely on "link-state routing"

(the

question isn't whether RWA needs this information or not, it does); on this

point,

there is an interesting discussion initiated on bullet 4, Section 4.2 but it

seems

that alternatives weren't considered at the end. Not the intention here to remove or to preclude that option but ask to document/motivate the proposed selection in the context of this framework.

--> Alternatives along these lines were discussed at the PCE group but not adopted as a work item.

o) Other remarks . There is no discussion about contention resolution in case of concurrency

among

requests, MBB applicability, and use of LMP (is the latter not foreseen or not usable in the WSON context ?).

--> Current mechanisms suffice for WSON, i.e., WSON isn't so different from SONET/SDH in this regard.

. Understanding that minimizing the number of re-trials/crankback is a

reasonable

goal; however, the question of extensions to crankback RFC and related that

will

be needed in case of multiple concurrent requests isn't discussed at all e.g. should the retry go back to the source or to intermediate nodes ? in which conditions ? etc.

--> Good question for PCE. Not specific to WSON.

Thanks, -dimitri.

-----Original Message----- From: Rtg Area Wiki [mailto:trac <at> tools.ietf.org] Sent: Wednesday, January 19, 2011 12:12 AM To: Papadimitriou, Dimitri (Dimitri); dbrungard <at> att.com Cc: danli <at> huawei.com; adrian.farrel <at> huawei.com; stbryant <at> cisco.com Subject: Re: [Rtg Area Wiki] #49 (waiting): Review of draft-ietf-ccamp-rwa-wson-framework #49: Review of draft-ietf-ccamp-rwa-wson-framework Changes (by dbrungard <at> ...): * cc: adrian.farrel <at> ..., stbryant <at> ... (added) * owner: dbrungard <at> ... => dimitri.papadimitriou <at> ... * status: open => waiting Old description: New description: By 2/1. -- -- ------------------------------+------------------------------- -------------- Reporter: dbrungard <at> ... | Owner: dimitri.papadimitriou <at> ... Type: review | Status: waiting Priority: major | Version: Keywords: wson gmpls | Draft: draft-ietf-ccamp-rwa-wson-framework ------------------------------+------------------------------- -------------- Ticket URL: <http://trac.tools.ietf.org/area/rtg/trac/ticket/49#comment:2> Rtg Area Wiki <http://tools.ietf.org/area/rtg/> =

-- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp