Re: [CCAMP] Routing Directorate:Review of draft-ietf-ccamp-rwa-wson-framework

[Greg Bernstein <[e-mail]>]

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@alcatel-
>> lucent.com]
>> Sent: 31 January 2011 23:42
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> 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:[e-mail]]
>>> Sent: Wednesday, January 19, 2011 12:12 AM
>>> To: Papadimitriou, Dimitri (Dimitri); [e-mail]
>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>> 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@...):
>>>
>>>   * cc: adrian.farrel@..., stbryant@... (added)
>>>    * owner:  dbrungard@... =>  dimitri.papadimitriou@...
>>>    * status:  open =>  waiting
>>>
>>>
>>> Old description:
>>>
>>>
>>>
>>> New description:
>>>
>>>   By 2/1.
>>>
>>> --
>>>
>>> --
>>> ------------------------------+-------------------------------
>>> --------------
>>> Reporter:  dbrungard@...        |     Owner:
>>> dimitri.papadimitriou@...
>>>      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 [phone]