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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Feb 2011 21:09:11 -0000

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: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
> 
> . 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).
> 
> . "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.
> 
> . "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.
> 
> 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.
> 
> 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.
> 
> . "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.
> 
> 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
>    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.
> 
> 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 ?
> 
> . "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.
> 
> 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 ?
> 
> . Same question applies for combiners.
> 
> . The side question how hybrid environment would operate (e.g. GMPLS/OXC
> with non-GMPLS splitters or combiners)
> 
> 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
> 
> 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
> 
> 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 ?
> 
> 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.
> 
> 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).
> 
> 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).
> 
> 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 ?
> 
> . "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 ?
> 
> . 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).
> 
> 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> ;-)
> 
> 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 ?
> 
> 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.
> 
> 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).
> 
> 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".
> 
> . "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.
> 
> 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 ?).
> 
> . 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.
> 
> Thanks,
> -dimitri.
> 
> 
> 
> > -----Original Message-----
> > From: Rtg Area Wiki [mailto:[email-masked]]
> > Sent: Wednesday, January 19, 2011 12:12 AM
> > To: Papadimitriou, Dimitri (Dimitri); [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > 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/>
> >
> > =

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 03 Feb 2011 14:17:35 -0800

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

Greg & Young

>> wavelength switched networks to initiate such "framework" otherwise one could
-->  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.
>> 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.
>> of this document. In particular, afaik aren't there different specifications
--> suggest changing "network" to "optical subnetwork".
>> 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.
>> 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.
>> ? If a DXC transmitter fails clearly the node shall select another outgoing
-->  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.
>> 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...
>>     streams the presence of Forwarding Equivalence Class (FEC) can be
==> error in text should be "Forward Error Correction"
>> Please indicate the impact at the control plane level, and GMPLS protocol
--> Will fix error in text.
>> GMPLS capabilities will only apply to this subset ?
--> Will change text to read "only the subset of these relevant to the 
control plane".
>> a MT routing when constraints are induced by node structure or topological
--> this statement is concerned with the connectivity capabilities of a 
switch which was modeled via the connectivity matrix mechanism.
>> "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.
>> with non-GMPLS splitters or combiners)
-->  Would need to use the network management system. Out of our scope.
>> case of ROADMs not sure whether the need a dedicated sub-section
-->  Suggest leaving the section. Since these are common in optical 
networks.
>> 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).
>> multiplexing occurs at this layer." the "this" refers to ?
--> Will change text to read "What table 2 also shows..."
>> 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.
>> can only be detected by means of RRO (but it is receiver which breaks the loop
--> Yes.  No change to text seems indicated.
>> adjustment descriptor defined in RFC 6001 (that is a general mean to associate
--> 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.
>> applies to a single "TE domain" thus in practice a single routing area ? or

--> This document does not address multiple AS issues.
>> 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.
>> on what the control suite should deliver (taking into account what it is
--> 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.
>> actually -- just for the record:<http://tools.ietf.org/html/draft-oki-ccamp-
--> acknowledged.
>> 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.
>> a constraint induced by regeneration, conversion used to elevate these
==> Error in text. All impairments we are talking about are optical. 
Will insert the word "optical".
>> Why is this a problem when "client devices" (e.g. routers in Fig.7) advertise
-->  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.
>> 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.
>> selection in the context of this framework.
--> Alternatives along these lines were discussed at the PCE group but 
not adopted as a work item.
>> usable in the WSON context ?).
--> Current mechanisms suffice for WSON, i.e., WSON isn't so different 
from SONET/SDH in this regard.
>> should the retry go back to the source or to intermediate nodes ? in which
--> Good question for PCE. Not specific to WSON.
>>> Rtg Area Wiki<http://tools.ietf.org/area/rtg/>
>>>
>>> =
>

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 4 Feb 2011 12:17:26 -0000

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:[email-masked]] 
Sent: 03 February 2011 22:18
To: [email-masked]
Cc: [email-masked];
[email-masked]; 'CCAMP'; [email-masked]
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

 
 
Many thanks,
Adrian
 
-----Original Message-----
 
Hi,

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

 

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

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. 

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

 
o) Section 3.4

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

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

 
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

. 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

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

 
 
. 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

 
 
  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

  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

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

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. 

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

 
Thanks,
-dimitri.

-----Original Message-----
From: Rtg Area Wiki [mailto:[email-masked]]
Sent: Wednesday, January 19, 2011 12:12 AM
To: Papadimitriou, Dimitri (Dimitri); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Rtg Area Wiki] #49 (waiting): Review of

 

Old description:

New description:
 
 By 2/1.
 
--

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

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 07 Feb 2011 08:41:28 -0800

Hi CCAMPers and WSON interested parties. We have just uploaded the 
newest version of the WSON framework with the previously mentioned 
changes.  Note we used "WSON" rather than the ITU-T term "optical 
subnetwork" per Adrian's recommendation.
Cheers
Greg & Young
On 2/4/2011 4:17 AM, Adrian Farrel wrote:
> 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:[email-masked]]
> *Sent:* 03 February 2011 22:18
> *To:* [email-masked]
> *Cc:* [email-masked]; 
> *Subject:* Re: Routing Directorate:Review of 
--snip--