Re: Updated Draft Liaiosn to Q6/15

Giovanni Martinelli <giomarti@cisco.com> Tue, 10 March 2009 16:03 UTC

Envelope-to: ccamp-data0@psg.com
Delivery-date: Tue, 10 Mar 2009 16:05:29 +0000
Message-ID: <49B68F4D.50705@cisco.com>
Date: Tue, 10 Mar 2009 17:03:25 +0100
From: Giovanni Martinelli <giomarti@cisco.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Malcolm Betts <betts01@nortel.com>
CC: "O'Connor, Don" <don.oconnor@us.fujitsu.com>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
Subject: Re: Updated Draft Liaiosn to Q6/15
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9367; t=1236701006; x=1237565006; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20<giomarti@cisco.com> |Subject:=20Re=3A=20Updated=20Draft=20Liaiosn=20to=20Q6/15 |Sender:=20; bh=X3njuY1NPJkIzyoUADY5LgAkUGSg3boM2BMFITDVQoo=; b=f2NwJdHA/fynIuqKWfZOTNsxm6v8emLq13F5XMM1ZM5T+4LOxPoA+4jiov 32e1MVCzC/9MsCuBb2bJOC0XW/tM1sTOzTHSDSUjtMjl7iossxC0wVSHTVzu 9nlNEbK9Bt;
Authentication-Results: ams-dkim-2; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );

Hi Malcom,

couple of questions for better understanding

Malcolm Betts wrote:
> I missed this in my first comments ;( I share the concern expressed by
> Don.  
>
> I suggest that we turn this into a question that we can debate with Q6.
> e.g. replace
> "- There is no requirement to measure impairments.
>    - Many networks are engineered such that configured
>       impairment values are enough information
>    - Measuring can often produce ambiguous values
>    - Equipment to perform measurement may be expensive
>    However, if an implementer chooses to measure impairments
>    on their device, this should not be prohibited, and should be
>    accommodated."
>
> with:
>
> "We understand that Q6 currently has no requirement to measure
> impairments
> after the transport equipment is deployed.
>    - Currently networks are engineered such that configured
>       impairment values are enough information
> Does Q6 foresee any value in the future for transport equipment
> including the ability to measure the actual impairments on a path. 
probably looks like a trivial question but, what exactly you mean by 
*ability to measure*?


>  If
> this is a possibility then it would be necessary to report these
> impairment measurements in the same way as the configured impairments
> are reported.
>
>   
"in the same way", saying that for a given impairments either a 
measurement or a configuration shall be coherent (same type and range, 
not the actual value), is my understanding correct?

Cheers,
G

>
> Malcolm Betts
> Nortel Networks
> Phone: +1 613 763 7860 (ESN 393)
> email: betts01@nortel.com
>
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of Giovanni Martinelli
> Sent: Tuesday, March 10, 2009 5:19 AM
> To: O'Connor, Don
> Cc: Adrian Farrel; ccamp@ops.ietf.org
> Subject: Re: Updated Draft Liaiosn to Q6/15
>
>
>
> O'Connor, Don wrote:
>   
>> Adrian
>>
>> Can you please remove this text
>>
>> " However, if an implementer chooses to measure impairments
>>    on their device, this should not be prohibited, and should be
>>    accommodated."
>>
>> This should be determined by ITU not CCAMP. CCAMP cannot generate 
>> standards that imply ROADM data plane functionality. If any optical 
>> impairments are measured by ROADMs, ITU must first generate the 
>> necessary standard
>>   
>>     
> Although I understand there could be some precedences  I would not the
> remove the text.  In principle the RWA problem try to catch some data
> plane constrains as well.
>
> Cheers,
> G
>
>   
>> Regards
>>
>> Don
>>
>> -----Original Message-----
>> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On 
>> Behalf Of Adrian Farrel
>> Sent: Monday, March 09, 2009 4:50 PM
>> To: ccamp@ops.ietf.org
>> Subject: Updated Draft Liaiosn to Q6/15
>>
>> Hi,
>>
>> Had some comments off-list.
>>
>> New version with minor changes...
>>
>>  ===
>>
>>  Dear Peter,
>>
>> CCAMP experts are looking forward to our joint meeting with Q6/5 on 
>> March 20th to discuss optical impairments and the control plane 
>> operation of wavelength switched optical networks (WSONs).
>>
>> This liaison is to summarise the activity within CCAMP on this subject
>>     
>
>   
>> so far and to set out our objectives for this work.
>>
>> As you will be aware, the GMPLS control plane is designed to provide a
>>     
>
>   
>> dynamic control plane for a variety of switching technologies. Amongst
>>     
>
>   
>> these is the "lambda switch capable" data plane where devices are 
>> OEOs, ROADMs, and photonic cross-connects (PXCs). In fact, lambda 
>> switching was the technology that led to the development of MPLS from 
>> the packet switching
>>
>> MPLS control plane.
>>
>> The IETF's CCAMP working group is the design authority for all 
>> extensions to the GMPLS family of protocols.
>>
>> The original work on lambda switching networks within CCAMP recognised
>>     
>
>   
>> that there is a subset of optical networks in which it is possible to 
>> disregard optical impairments and where the number of regeneration 
>> points is high.
>> In
>> these environments, path computation can be performed on a 
>> reachability graph, and lambda conversion can be performed as 
>> necessary within the network.
>>
>> As PXCs were introduced into WSONs, it remained the case that optical 
>> impairments could be disregarded by the control plane. Where 
>> necessary, optimal impairment-aware paths could be computed off-line 
>> and supplied to the control plane, leaving the control plane to handle
>>     
>
>   
>> establishment of connections and recovery after failure. Failure 
>> recovery scenarios might
>>
>> lead to contention for wavelengths or suboptimal optical paths, but 
>> these could be handled by crankback within the signaling protocol.
>>
>> More recent work on WSONs indicates that the proportion of pure 
>> optical devices (ROADMs and PXCs) is increasing. This means that it is
>>     
>
>   
>> necessary to compute paths that offer end-to-end lambda continuity. 
>> This problem (called the routing and wavelength assignment (RWA) 
>> problem) must be solved, and may be compounded by devices with limited
>>     
>
>   
>> cross-connect capabilities (for example, with glass-through, a limited
>>     
>
>   
>> OEO matrix, or restricted port-to-port capabilities). In approaching 
>> this problem it is convenient if there is a common identification 
>> scheme for wavelengths across the whole
>>
>> network (previously, wavelength identification was a local matter 
>> between the nodes at the ends of each link). To aid with this, the 
>> CCAMP working
>>
>> group has developed
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambd
>> a-
>> labels-03.txt
>>  that provides a protocol-independent encoding for wavelengths in a 
>> way that is compliant with G.694. Further work on this problem space 
>> can be seen in the following CCAMP documents:
>>
>> "Framework for GMPLS and PCE Control of Wavelength Switched Optical 
>> Networks (WSON)"
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framewor
>> k-
>> 01.txt
>>
>> "Routing and Wavelength Assignment Information Model for Wavelength 
>> Switched Optical Networks"
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-01.txt
>>
>> "Routing and Wavelength Assignment Information Encoding for Wavelength
>>     
>
>   
>> Switched Optical Networks"
>>
>>     
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-00.
>   
>> txt
>>
>> CCAMP participants have further identified cases where they believe it
>>     
>
>   
>> would be helpful to consider optical impairments during the control 
>> plane operation of a WSON. This gives rise to four distinct deployment
>> scenarios:
>>
>> 1. No concern for impairments or lambda continuity.
>>    (Original GMPLS)
>> 2. No concern for impairments, but lambda continuity is
>>     important. (The RWA problem)
>> 3. Concern for "basic" impairments
>> 4. Concern for "advanced" impairments
>>
>> In focusing on the third of these categories, CCAMP intends to base 
>> its work on G.680 and related recommendations with the following 
>> understanding:
>> - G.680 (et al.) provides a complete list of simple constraints
>> - Where G.680 refers to "single vendor" domains, it does not
>>    mean single manufacturer, but rather "single system integrator".
>>    That is, the equipment is not "plug and play", but has been
>>    tested to interoperate and the network has been planned.
>> - There is no requirement to measure impairments.
>>    - Many networks are engineered such that configured
>>       impairment values are enough information
>>    - Measuring can often produce ambiguous values
>>    - Equipment to perform measurement may be expensive
>>    However, if an implementer chooses to measure impairments
>>    on their device, this should not be prohibited, and should be
>>    accommodated.
>>
>>  With this in mind, CCAMP is looking to Q6/15 to work as a partner in
>> establishing:
>> - the complete list of impairments suitable for this type of network
>>    - and the complete list of Recommendations to use as references
>> - the rules by which such impairments are accumulated along a path
>> - generic encodings and ranges of values for the impairments
>>
>>  For reference, some early work on impairment-aware GMPLS is listed 
>> below.
>> This work is not yet adopted as CCAMP work, but is likely to form the 
>> basis of such work once we have discussed the way forward with Q6/15.
>>
>> "A Framework for the Control of Wavelength Switched Optical Networks
>> (WSON)
>> with Impairments"
>> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairm
>> en
>> ts-02.txt
>>
>>  "Information Model for Impaired Optical Path Validation"
>> http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-in
>> fo
>> -00.txt
>>
>> Looking forward to a profitable meeting, Deborah Brungard and Adrian 
>> Farrel CCAMP Working Group Co-Chairs
>>
>>
>>
>>
>>   
>>     
>
>