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

["Adrian Farrel" <[e-mail]>]

Hi please go ahead with a new revision.
 
Only point to note is "optical subnetwork". I advise against that as the term
subnetwork has a very specific IETF meaning, and overloading it with ITU-T
meaning is at best going to cause people to whinge. I think that whenever you
say "network" you actually mean "WSON". You could throw that statement in up
front, or you could search and replace network/WSON.
 
Thanks for the work,
Adrian
 
 
From: Greg Bernstein [mailto:[e-mail]] 
Sent: 03 February 2011 22:18
To: [e-mail]
Cc: [e-mail];
[e-mail]; 'CCAMP'; [e-mail]
Subject: Re: Routing Directorate:Review of draft-ietf-ccamp-rwa-wson-framework
 
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>
<http://tools.ietf.org/html/draft-oki-ccamp-
upstream-labelset-00
<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>
<http://trac.tools.ietf.org/area/rtg/trac/ticket/49#comment:2>
Rtg Area Wiki  <http://tools.ietf.org/area/rtg/>
<http://tools.ietf.org/area/rtg/>
 
=
 
 




-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]