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 >> >> >> >> >> >> > >
- Re: Updated Draft Liaiosn to Q6/15 Greg Bernstein
- Re: Updated Draft Liaiosn to Q6/15 Giovanni Martinelli
- RE: Updated Draft Liaiosn to Q6/15 Malcolm Betts
- RE: Updated Draft Liaiosn to Q6/15 Malcolm Betts
- Re: Updated Draft Liaiosn to Q6/15 Giovanni Martinelli
- RE: Updated Draft Liaiosn to Q6/15 O'Connor, Don
- Updated Draft Liaiosn to Q6/15 Adrian Farrel