Subject: Label_Set and Channel_Set in draft-ietf-ccamp-gmpls-dcsc-channel-ext-01.txt
From: Remi Theillaud <[email-masked]>
To: [email-masked]
Date: Tue, 31 Mar 2009 12:32:01 +0200

One question about a Label_Set containing Channel_Set labels:

  Let's consider the following LABEL_SET object. Labels are assumed to 
be two bytes Generalized labels (type 2) - such as the EVPL Generalized 
Label format defined in draft-ietf-ccamp-gmpls-ether-svcs-03.txt.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Length             | Class-Num (36)|   C-Type (1)  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Action(0)  |      Reserved     |        Label Type(4)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Action(2)  |Num Subchannels(2) |        Label Type(2)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Subchannel 1(100)      |        Subchannel 2(200)      |
  |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Action(2)  |Num Subchannels(2) |        Label Type(2)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Subchannel 1(300)      |        Subchannel 2(400)      |
  |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  I can see two different interpretation of this LABEL_SET:

1. This LABEL_SET specifies a single subchannel, which uses the format 
of a Channel_Set label.The Channel_Set label consists of two ranges: 
100..200 and 300..400.  The purpose of this LABEL_SET would be to force 
the downstream node to send back a LABEL object that consists of range 
100..200 AND range 300..400.

2. This LABEL_SET specifies two subchannels, both using the format of a 
Channel_Set label. The first channel is the range 100..200; the second 
one is the range 300..400. The purpose of this LABEL_SET would be to 
force the downstream node to send back a LABEL object that consists 
either of range 100..200 OR range 300..400

  Which interpretation is the correct one? am I misunderstanding something?

  One way to remove the ambiguity would be to consider that the 
LABEL_SET object can contain only one Channel_Set label (case 1 is then 
the correct interpretation). And it would be possible (if needed) to 
handle case 2 by using two LABEL_SET objects in a Path message.
 
  Rémi

Delivery-date: Mon, 30 Mar 2009 02:11:03 +0000
Reply-To: "Weiqiang Sun" <[email-masked]>
From: "Weiqiang Sun" <[email-masked]>
To: "ccamp80" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ccamp-lsp-dppm-05.txt 
Date: Mon, 30 Mar 2009 10:10:00 +0800
Organization: Shanghai Jiao Tong University

Hi all,

We have updated draft-ietf-ccamp-lsp-dppm into a -05 version.
The only technical change: we included 
draft-shiomoto-ccamp-switch-programming by Kohei Shiomoto and Adrian Farrel 
as a reference. We believe it is a good companion document to the our draft, 
as it clarifies the potential implementation inconsistency of provisioning 
in CP and DP.

Comments are welcome.

Thanks,
Weiqiang

--------------------------------------------------
From: <[email-masked]>
Sent: Monday, March 30, 2009 9:45 AM
To: <[email-masked]>
Cc: <[email-masked]>
Subject: I-D Action:draft-ietf-ccamp-lsp-dppm-05.txt

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Common Control and Measurement Plane 
> Working Group of the IETF.
>
>
> Title           : Label Switched Path (LSP) Dynamic Provisioning 
> Performance Metrics in Generalized MPLS Networks
> Author(s)       : W. Sun, et al.
> Filename        : draft-ietf-ccamp-lsp-dppm-05.txt
> Pages           : 47
> Date            : 2009-03-29
>
> Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
> promising candidate technologies for future data transmission
> network.  GMPLS has been developed to control and operate different
> kinds of network elements, such as conventional routers, switches,
> Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop
> Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-
> connects (OXCs), etc.  Dynamic provisioning ability of these
> physically diverse devices differs from each other drastically.  At
> the same time, the need for Dynamicly provisioned connections is
> increasing because optical networks are being deployed in metro
> areas.  As different applications have varied requirements in the
> provisioning performance of optical networks, it is imperative to
> define standardized metrics and procedures such that the performance
> of networks and application needs can be mapped to each other.
>
> This document provides a series of performance metrics to evaluate
> the dynamic LSP provisioning performance in GMPLS networks,
> specifically the Dynamic LSP setup/release performance.  These
> metrics can depict the features of GMPLS networks in LSP dynamic
> provisioning.  They can also be used in operational networks for
> carriers to monitor the control plane performance in realtime.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

Delivery-date: Mon, 30 Mar 2009 01:47:54 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-lsp-dppm-05.txt 
Date: Sun, 29 Mar 2009 18:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks
	Author(s)       : W. Sun, et al.
	Filename        : draft-ietf-ccamp-lsp-dppm-05.txt
	Pages           : 47
	Date            : 2009-03-29

Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for future data transmission
network.  GMPLS has been developed to control and operate different
kinds of network elements, such as conventional routers, switches,
Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop
Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc.  Dynamic provisioning ability of these
physically diverse devices differs from each other drastically.  At
the same time, the need for Dynamicly provisioned connections is
increasing because optical networks are being deployed in metro
areas.  As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other.

This document provides a series of performance metrics to evaluate
the dynamic LSP provisioning performance in GMPLS networks,
specifically the Dynamic LSP setup/release performance.  These
metrics can depict the features of GMPLS networks in LSP dynamic
provisioning.  They can also be used in operational networks for
carriers to monitor the control plane performance in realtime.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lsp-dppm-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Sun, 29 Mar 2009 01:57:49 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>
Subject: draft-shiomoto-ccamp-switch-programming
Date: Sun, 29 Mar 2009 02:05:38 +0100

Hi,

Just a quick note on Kohei's draft draft-shiomoto-ccamp-switch-programming 
which was due to be presented in San Francisco. Unfortunately, Kohei was 
unable to travel, and I was too sick to get to the meeting.

Please have a look at the slides for the draft, and also review the draft 
itself. We have already received useful comments from Weiqiang Sun, and plan 
a new revision soon, but we would certainly welcome more comments.

In summary, the draft clarifies and summarises the RSVP-TE protocol 
exchanges with relation to the programming of cross-connects along both 
unidirectional and bidirectional LSPs. This isn't really more than a 
restatement of what can be found in existing RFCs, but we have found that 
the distribution of the necessary information has made it hard for people to 
work out what they should and should not do with their implementations. In 
particular, draft-ietf-ccamp-lsp-dppm discusses measuring setup times in 
terms of control plane behavior, and it is important to know how this 
relates to the actual availability of the LSP.

Thanks,
Adrian 

Delivery-date: Wed, 25 Mar 2009 01:32:25 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt 
Date: Tue, 24 Mar 2009 18:30:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt
	Author(s)       : R. Rabbat
	Filename        : draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt
	Pages           : 15
	Date            : 2009-03-24

Technology in the optical domain is constantly evolving and as a 
consequence new equipment providing lambda switching capability has 
been developed and is currently being deployed. However, RFC 3471 has 
defined that a wavelength label (section 3.2.1.1) "only has 
significance between two neighbors" and global wavelength continuity 
is not considered. In order to achieve interoperability in a network 
composed of next generation lambda switch-capable equipment, this 
document defines a standard lambda label format, being compliant with 
ITU-T G.694. Moreover some consideration on how to ensure lambda 
continuity with RSVP-TE is provided. This document is a companion to 
the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It 
defines the label format when Lambda Switching is requested in an all 
optical network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Tue, 24 Mar 2009 15:08:05 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: slides
Date: Tue, 24 Mar 2009 15:06:29 -0000

Good catch. Thanks.
Fixed.
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 24, 2009 9:09 AM

> Hi Adrian,
>
> I found that slides for Framework for WSON Impairments in RWA session are
> same as ones for Framework for RWA in WSON in impairment session.
> I think it was uploaded in mistake.
>
> Best Regards,
> Xihua Fu
> ZTE Corporation

Delivery-date: Mon, 23 Mar 2009 18:16:56 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-mln-extensions-04.txt 
Date: Mon, 23 Mar 2009 11:15:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
	Author(s)       : I. Property
	Filename        : draft-ietf-ccamp-gmpls-mln-extensions-04.txt
	Pages           : 22
	Date            : 2009-03-23

There are specific requirements for the support of networks 

  comprising Label Switching Routers (LSR) participating in different 

  data plane switching layers controlled by a single Generalized Multi 

  Protocol Label Switching (GMPLS) control plane instance, referred to 

  as GMPLS Multi-Layer Networks/Multi-Region Networks (MLN/MRN).  

  This document defines extensions to GMPLS routing and signaling 

  protocols so as to support the operation of GMPLS Multi-Layer/Multi-

  Region Networks. It covers the elements of a single GMPLS control 

  plane instance controlling multiple LSP regions or layers within a 

  single TE domain.

  D. Papadimitriou

Expires September 21, 2009

[page 1] 

  Internet-Draft

 March 22, 2009 

  Table of Content

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-mln-extensions-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 23 Mar 2009 17:56:09 +0000
Content-class: urn:content-classes:message
Subject: Last Call complete draft-ietf-ccamp-lsp-hierarchy-bis-06.txt
Date: Mon, 23 Mar 2009 13:54:05 -0400
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

Hi,

The Last Call completed with no comments. I'll prepare for forwarding to
publish.

Thanks,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Thursday, March 05, 2009 11:31 AM
To: [email-masked]
Subject: Working Group Last Call
draft-ietf-ccamp-lsp-hierarchy-bis-06.txt

Hi,

This email begins a two week working group last call on
draft-ietf-ccamp-lsp-hierarchy-bis-06.txt:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-0
6.txt

Please send your comments to the list before the last call closes on
March 19, 2009.

Thanks,
Deborah

Delivery-date: Sun, 22 Mar 2009 04:36:00 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Communication received from OIF
Date: Sun, 22 Mar 2009 04:30:57 -0000

Hi,

I fumbled this incoming communication that arrived at the end of February.

You can find it at and the attachment at 
http://www.olddog.co.uk/incoming.htm

Adrian
...

Dear Adrian and Deborah,

We have been working on multi-domain restoration requirements in the Carrier 
Working Group in OIF.

The attached document includes mutually agreed requirements from multiple 
carriers. It focuses on restoration across multiple domains, and presents 
several failure scenarios. It considers intra-domain restoration, 
inter-domain restoration, and the coordination required across multiple 
domains for each case. It represents an addendum to the previously sent 
requirements document (oif.2006.134.02), and it focuses on multi-domain 
service recovery using E-NNI interfaces.

As we continue work on multi-domain restoration, we would appreciate if 
CCAMP will take these requirements into consideration in further CCAMP work 
on GMPLS recovery.

We will be happy to have a dialog with CCAMP, if you have any questions or 
comments on these requirements.

Thank you.
Sincerely yours,
Lyndon Ong
OIF Technical Committee Chair 

Delivery-date: Sun, 22 Mar 2009 01:23:59 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Slides
Date: Sun, 22 Mar 2009 01:21:24 -0000

Hi,

A good number of slides have been received and posted
(http://www.ietf.org/proceedings/09mar/agenda/ccamp.htm)

Everyone else...
soon as possible, please.

Thanks,
Adrian

Delivery-date: Fri, 20 Mar 2009 12:32:58 +0000
Date: Fri, 20 Mar 2009 13:30:26 +0100
From: Martin Vigoureux <[email-masked]>
Organization: Alcatel-Lucent
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: slides for joint mpls-tp session

all,

could you please start sending the slides you will use
for your presentation(s). Thanks.

The joint wg session on mpls-tp is on Wednesday, 9:00-11:30 am
http://www.ietf.org/proceedings/09mar/agenda/mpls.txt

martin

Delivery-date: Thu, 19 Mar 2009 12:50:13 +0000
Date: Thu, 19 Mar 2009 13:48:04 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: poll to make draft-busi-mpls-tp-oam-framework an mpls working group document

Working Group,

the authors of draft-busi-mpls-tp-oam-framework-02-02-1.txt has
requested the document shall be accepted as a working group document.

This is a one week poll to see if there are support for making it a
working group document, please respond to the mpls-tp mailing list
before Wednesday March 26.

The document will be found at:

http://www.tla-group.com/~loa/draft-busi-mpls-tp-oam-framework-02-02-1.txt

Disclaimer: I've decided to start this poll even though the draft is not
available from the IETF repository.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13 

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Delivery-date: Wed, 18 Mar 2009 14:53:11 +0000
Date: Wed, 18 Mar 2009 15:50:42 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: working groupm last call on draft-ietf-mpls-tp-gach-gal-02 has ended

  All,

  the working group last call on draft-ietf-mpls-tp-gach-gal-02
  has ended.

  1. we have received the information from ITU-T ad hoc team on mpls-tp
     that the comments they have is aligned with the last call comments
     received under point 5. below in the MPLS wg last call.

  2. We have received one comment that says that the associated channel
     should not be used for OAM. Since this is the entire purpose of the
     of the associated channel the authors/editors are instructed not
     consider this comment.
  3. We have received comments that would require us to revisit the
     results of the JWT investigtaion. We will not do so, since this is
     not within our charter.
  4. We have received one comment that we are allocating too many
     experimental code points, the editors/authors are instructed to solve
     this together with the current and future RTG AD and the MEAD team
     chair.

  5. We have received a set of comments, that should be considered as
     "friendly amendments" and that should be responded to by the
     authors-editors.

  Could the authors lease update the draft and republish.

  /Loa
-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13 

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Envelope-to: [email-masked]
Delivery-date: Tue, 17 Mar 2009 21:31:33 +0000
Date: Tue, 17 Mar 2009 14:23:40 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Editorial Errata Reported] RFC5298 (1730)
From: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

The following errata report has been submitted for RFC5298,
"Analysis of Inter-Domain Label Switched Path (LSP) Recovery".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5298&eid=1730

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[email-masked]>

Section: 4.4.2, pg.15

Original Text
-------------
   Since both LSPs are computed in a single pass, the LSPs can be
|  signaled simultaneously of sequentially according to the preference
   of the head-end LSR.
                           ^^

Corrected Text
--------------
   Since both LSPs are computed in a single pass, the LSPs can be
|  signaled simultaneously or sequentially according to the preference
   of the head-end LSR.
                           ^^

Notes
-----
Distorting typo; keep for Update!

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5298 (draft-ietf-ccamp-inter-domain-recovery-analysis-05)
--------------------------------------
Title               : Analysis of Inter-Domain Label Switched Path (LSP) Recovery
Publication Date    : August 2008
Author(s)           : T. Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur
Category            : INFORMATIONAL
Source              : Common Control and Measurement Plane
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

Delivery-date: Tue, 17 Mar 2009 14:37:39 +0000
Date: Tue, 17 Mar 2009 15:35:26 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: poll on making the draft-beller-mpls-tp-gach-dcn

All,

the authors/editors of draft-beller-mpls-tp-gach-dcn has
asked us to accept the document as an MPLS Working group
document.

This is a one week poll to see if there are support for making it a
working group document, please respond to the mpls-tp mailing
list before Wednesday March 25.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Envelope-to: [email-masked]
Delivery-date: Sat, 14 Mar 2009 00:50:55 +0000
To: [email-masked], [email-masked]
Subject: RFC 5495 on Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Fri, 13 Mar 2009 17:47:13 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 5495

        Title:      Description of the Resource Reservation 
                    Protocol - Traffic-Engineered (RSVP-TE) Graceful 
                    Restart Procedures 
        Author:     D. Li, J. Gao,
                    A. Satyanarayana, S. Bardalai
        Status:     Informational
        Date:       March 2009
        Mailbox:    [email-masked], [email-masked], 
                    [email-masked], [email-masked]
        Pages:      18
        Characters: 39325
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gr-description-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5495.txt

The Hello message for the Resource Reservation Protocol (RSVP) has
been defined to establish and maintain basic signaling node
adjacencies for Label Switching Routers (LSRs) participating in a
Multiprotocol Label Switching (MPLS) traffic-engineered (TE)
network.  The Hello message has been extended for use in Generalized
MPLS (GMPLS) networks for state recovery of control channel or nodal
faults.

The GMPLS protocol definitions for RSVP also allow a restarting node to
learn which label it previously allocated for use on a Label
Switched Path (LSP).

Further RSVP protocol extensions have been defined to enable a
restarting node to recover full control plane state by exchanging
RSVP messages with its upstream and downstream neighbors.

This document provides an informational clarification of the
control plane procedures for a GMPLS network when there are
multiple node failures, and describes how full control plane state
can be recovered in different scenarios where the order in which
the nodes restart is different.

This document does not define any new processes or procedures.  All
protocol mechanisms are already defined in the referenced documents.
This memo provides information for the Internet community.

This document is a product of the Common Control and Measurement Plane Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Envelope-to: [email-masked]
Delivery-date: Fri, 13 Mar 2009 17:59:32 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236967069; bh=jNeTYvsMQ8w6QNtoZOUB1LrJ/JKg2SOzhiZIORTjK+c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=i6d1Ew5Lt9+ZeQv9kb+PIjCJbS6KOGQx4vSPefgvwWgDE3GR5t50gXIsxWCMY7mGtv2sJgeyG0DVBxQ5fJvzoBCMcr73CaMp9ofD8kAPxm13hUote1yQN8stid9qDT9JuAoJIx9+mkgzu8FapRg4t0q3O2fBlKdsWTsZ0En+CZg=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=cRzo/+U5bwL+5UCloRvhhhXRc8mQHePCVAUBuTURDqSMoZ2MJkhx331ocXyhYAYf+UsHLGNEbwx/5/MJEbYAzKmYTxjBqhp2ujN8evmEsRkbToFsIqLeJBmOBsjqfceKubE1CNrCrnOZySaXhVTQKy24Yg1RlpYBExFKi+p9LnU=;
Message-ID: <[email-masked]>
Date: Fri, 13 Mar 2009 10:57:49 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Liaison to Q6/15 and Meeting Questions...
To: Malcolm Betts <[email-masked]>, "Razdan, Rajender" <[email-masked]>, Greg Bernstein <[email-masked]>, ccamp <[email-masked]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-679904759-1236967069=:50421"

--0-679904759-1236967069=:50421
Content-Type: text/plain; charset=us-ascii

Malcolm,

Agree completely with the suggested refinement.

Cheers,
Igor

________________________________
From: Malcolm Betts <[email-masked]>
To: "Razdan, Rajender" <[email-masked]>; Greg Bernstein <[email-masked]>; ccamp <[email-masked]>
Sent: Thursday, March 12, 2009 1:12:57 PM
Subject: RE: Liaison to Q6/15 and Meeting Questions...

One refinement on:
(e) Measurements -- G.697 
seems to give a rough framework on applications of measurement, types of 
measurements, measurement parameters. Is this a good place for anyone 
investigating the relationship between control plane and optical measurements to 
start? Other recommendations/ideas
We 
should ask Q6 how the results of these measurements could be used to refine the 
values of the impairment parameters used when computing an optical path.  
As a part of this discussion we also need to understand when (i.e. what event) 
triggers the measurements.
Malcolm Betts 
Nortel Networks 
Phone: +1 613 763 7860 (ESN 
393) 
email: 
[email-masked] 
________________________________
 From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Razdan, 
Rajender
Sent: Thursday, March 12, 2009 12:32 PM
To: Greg 
Bernstein; ccamp
Subject: RE: Liaison to Q6/15 and Meeting 
Questions...

Hi Greg/all,
 
     I think we do have a consensus on 
the relative roles of Q6 and CCAMP with regard to the WSON work. It seems to me 
that the questions Don put up earlier, along with the set of questions you have 
below, form an excellent starting point for questions we should put forth to Q6 
in its upcoming meeting. In addition to everything else I would also add 
:
FOADM/ROADM/OXC charcterization, i.e. are there any general 
characterization/parametrization we can use? In particular is there a way to 
characterize the loss in a photonic network taking into account the filter 
characteristics of these devices?
 
Cheers,
Rajender Razdan

________________________________
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Bernstein
Sent: Thursday, March 12, 2009 
11:53 AM
To: ccamp
Subject: Liaison to Q6/15 and Meeting 
Questions...

Hi folks, we seem to be re-iterating some issues that I thought we 
had reached consensus on. However in this conversation some good questions have 
arisen for the special CCAMP/Q6 meeting.
I thought we had consensus that 
CCAMP will not define new optical impairments, parameters, etc... but we 
will use ITU-T existing definitions. If we think we need something we will bring 
this up with Q6. The response we've seen from Q6 so far has been very 
positive in working together in this area. 

Some potential questions and 
areas for discussion:
(a) WDM Link characterization  -- G.680 gives lots 
of examples in appendices but does not actually specify yet. There are a host of 
other ITU-T documents that cover fiber, amplifiers, dispersion compensation 
modules, etc... So we'll want Q6's input on a somewhat self contained 
model.
(b) Receiver characterization -- Is there are general 
characterization/parameterization we should use?
(c) Transmitter 
characterization -- Similar question
(d) Signal characterization -- There are 
a number of different documents in this area, some are specific to SDH, some are 
very general WDM interface characterizations; Guidance would be welcome so that 
we don't over specialize.
(e) Measurements -- G.697 seems to give a rough 
framework on applications of measurement, types of measurements, measurement 
parameters. Is this a good place for anyone investigating the relationship 
between control plane and optical measurements to start? Other 
recommendations/ideas.
(f) Characterization of optical parameters -- 
(feedback from Q6 desired) parameters that are NE wide, apply to each port, 
apply between particular ports (port-to-port), frequency dependence of 
parameters (important for info model and encoding)

Other questions for Q6 
from CCAMP?

Best Regards

Greg

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

      
--0-679904759-1236967069=:50421
Content-Type: multipart/related; boundary="0-594068941-1236967069=:50421"

--0-594068941-1236967069=:50421
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Malcolm,<br><br>Agree completely with the suggested refinement.<br><br>Cheers,<br>Igor<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Malcolm Betts &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">To:</span></b> "Razdan, Rajender" &lt;[email-masked]&gt;; Greg Bernstein &lt;[email-masked]&gt;; ccamp &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">Sent:</span></b> Thursday, March 12, 2009 1:12:57 PM<br><b><span style="font-weight: bold;">Subject:</span></b> RE: Liaison to Q6/15 and Meeting Questions...<br></font><br>

 

<div dir="ltr" align="left"><font size="2" color="#0000ff" face="Arial"><span class="750120917-12032009">One refinement on:</span></font></div>
<div dir="ltr" align="left"><span class="750120917-12032009">(e) Measurements -- G.697 
seems to give a rough framework on applications of measurement, types of 
measurements, measurement parameters. Is this a good place for anyone 
investigating the relationship between control plane and optical measurements to 
start? Other recommendations/ideas</span></div>
<div><span class="750120917-12032009"><font size="2" color="#0000ff" face="Arial">We 
should ask Q6 how the results of these measurements could be used to refine the 
values of the impairment parameters used when computing an optical path.&nbsp; 
As a part of this discussion we also need to understand when (i.e. what event) 
triggers the measurements.</font></span></div>
<p><span lang="en-us"><font size="2" face="Arial">Malcolm Betts</font></span> 
<br><span lang="en-us"><font size="2" face="Arial">Nortel Networks</font></span> 
<br><span lang="en-us"><font size="2" face="Arial">Phone: +1 613 763 7860 (ESN 
393)</font></span> <br><span lang="en-us"><font size="2" face="Arial">email: 
[email-masked]</font></span> </p>
<p>
</p><hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> [email-masked] 
[mailto:[email-masked]] <b>On Behalf Of </b>Razdan, 
Rajender<br><b>Sent:</b> Thursday, March 12, 2009 12:32 PM<br><b>To:</b> Greg 
Bernstein; ccamp<br><b>Subject:</b> RE: Liaison to Q6/15 and Meeting 
Questions...<br></font><br><p></p>
<div></div>
<div dir="ltr" align="left"><span class="465112216-12032009"><font size="2" color="#0000ff" face="Arial">Hi Greg/all,</font></span></div>
<div dir="ltr" align="left"><span class="465112216-12032009"><font size="2" color="#0000ff" face="Arial"></font></span>&nbsp;</div>
<div dir="ltr" align="left"><span class="465112216-12032009"><font size="2" color="#0000ff" face="Arial">&nbsp;&nbsp;&nbsp;&nbsp; I think we do have a consensus on 
the relative roles of Q6 and CCAMP with regard to the WSON work. It seems to me 
that the questions Don put up earlier, along with the set of questions you have 
below, form an excellent starting point for questions we should put forth to Q6 
in its upcoming meeting. In addition to everything else I would also add 
:</font></span></div>
<div dir="ltr" align="left"><span class="465112216-12032009"><font size="2" color="#0000ff" face="Arial">FOADM/ROADM/OXC charcterization, i.e. are there any general 
characterization/parametrization we can use? In particular is there a way to 
characterize the loss in a photonic network taking into account the filter 
characteristics of these devices?</font></span></div>
<div dir="ltr" align="left"><span class="465112216-12032009"><font size="2" color="#0000ff" face="Arial"></font></span>&nbsp;</div>
<div dir="ltr" align="left"><span class="465112216-12032009"><font size="2" color="#0000ff" face="Arial">Cheers,</font></span></div>
<div dir="ltr" align="left"><span class="465112216-12032009"><font size="2" color="#0000ff" face="Arial">Rajender Razdan</font></span></div><br>
<div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us"></div><br><img alt="" src="cid:[email-masked]" align="baseline" border="0" hspace="0"><br>
<div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us">
<hr tabindex="-1">
</div>
<div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us"><font size="2" face="Tahoma"><b>From:</b> [email-masked] [mailto:[email-masked]] 
<b>On Behalf Of </b>Greg Bernstein<br><b>Sent:</b> Thursday, March 12, 2009 
11:53 AM<br><b>To:</b> ccamp<br><b>Subject:</b> Liaison to Q6/15 and Meeting 
Questions...<br></font><br></div>
<div></div>Hi folks, we seem to be re-iterating some issues that I thought we 
had reached consensus on. However in this conversation some good questions have 
arisen for the special CCAMP/Q6 meeting.<br>I thought we had consensus that 
CCAMP <i><b>will not define new optical impairments, parameters, etc... but we 
will use ITU-T existing definitions. If we think we need something we will bring 
this up with Q6. </b></i>The response we've seen from Q6 so far has been very 
positive in working together in this area. <br><br>Some potential questions and 
areas for discussion:<br>(a) WDM Link characterization&nbsp; -- G.680 gives lots 
of examples in appendices but does not actually specify yet. There are a host of 
other ITU-T documents that cover fiber, amplifiers, dispersion compensation 
modules, etc... So we'll want Q6's input on a somewhat self contained 
model.<br>(b) Receiver characterization -- Is there are general 
characterization/parameterization we should use?<br>(c) Transmitter 
characterization -- Similar question<br>(d) Signal characterization -- There are 
a number of different documents in this area, some are specific to SDH, some are 
very general WDM interface characterizations; Guidance would be welcome so that 
we don't over specialize.<br>(e) Measurements -- G.697 seems to give a rough 
framework on applications of measurement, types of measurements, measurement 
parameters. Is this a good place for anyone investigating the relationship 
between control plane and optical measurements to start? Other 
recommendations/ideas.<br>(f) Characterization of optical parameters -- 
(feedback from Q6 desired) parameters that are NE wide, apply to each port, 
apply between particular ports (port-to-port), frequency dependence of 
parameters (important for info model and encoding)<br><br>Other questions for Q6 
from CCAMP?<br><br>Best Regards<br><br>Greg<br><pre class="moz-signature">-- <br>===================================================<br>Dr Greg Bernstein, Grotto Networking (510) 573-2237<br><br></pre><br></div></div></div><br>

      </body></html>
--0-594068941-1236967069=:50421
Content-Type: image/gif; name="ATT2601587.gif"
Content-Transfer-Encoding: base64
Content-Id: <[email-masked]>
Content-Description: ATT2601587.gif

--0-594068941-1236967069=:50421--
--0-679904759-1236967069=:50421--

Envelope-to: [email-masked]
Delivery-date: Fri, 13 Mar 2009 09:59:04 +0000
Date: Fri, 13 Mar 2009 02:56:10 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Editorial Errata Reported] RFC5467 (1715)
From: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

The following errata report has been submitted for RFC5467,
"GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5467&eid=1715

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[email-masked]>

Section: 6, 1st para

Original Text
-------------
   This document introduces new message objects for use in GMPLS
   signaling [RFC3473] -- specifically the UPSTREAM_TSPEC,
   UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects.  These objects
|  parallel the exiting SENDER_TSPEC, ADSPEC, and FLOWSPEC objects but
   are used in the opposite direction.  As such, any vulnerabilities
   that are due to the use of the old objects now apply to messages
   flowing in the reverse direction.

Corrected Text
--------------
   This document introduces new message objects for use in GMPLS
   signaling [RFC3473] -- specifically the UPSTREAM_TSPEC,
   UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects.  These objects
|  parallel the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC objects but
   are used in the opposite direction.  As such, any vulnerabilities
   that are due to the use of the old objects now apply to messages
   flowing in the reverse direction.

Notes
-----
Rationale: typo changing the sense !
  ==>   s/exiting/existing/

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5467 (draft-ietf-ccamp-asymm-bw-bidir-lsps-02)
--------------------------------------
Title               : GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
Publication Date    : March 2009
Author(s)           : L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric
Category            : EXPERIMENTAL
Source              : Common Control and Measurement Plane
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

Delivery-date: Thu, 12 Mar 2009 22:01:22 +0000
From: "Sadler, Jonathan B." <[email-masked]>
To: Malcolm Betts <[email-masked]>, "Razdan, Rajender" <[email-masked]>, Greg Bernstein <[email-masked]>, ccamp <[email-masked]>
Date: Thu, 12 Mar 2009 16:57:05 -0500
Subject: RE: Liaison to Q6/15 and Meeting Questions...
Accept-Language: en-US
acceptlanguage: en-US

--_004_5292FFA96EC22A4386067E9DBCC0CD2B260DCF8D8FEXNAPtellabsw_
Content-Type: multipart/alternative;
	boundary="_000_5292FFA96EC22A4386067E9DBCC0CD2B260DCF8D8FEXNAPtellabsw_"

--_000_5292FFA96EC22A4386067E9DBCC0CD2B260DCF8D8FEXNAPtellabsw_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

One other item that came up in my read of the liaison text is that Q6 will =
do a great job helping us with O-O-O, but O-E-O ends up going outside their=
 area of responsibility.  The "E" is actually something that Q12 (from an a=
rchitecture) and Q11 (from a signal rates/format) have responsibility for.

I can understand that we can talk about O-E-O in terms of a general use cas=
e when speaking with Q6, but the issues specifiic to the "E" layer as well =
as how it relates to the "O" layer is outside Q6's scope.

Jonathan Sadler

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Malc=
olm Betts [[email-masked]]
Sent: Thursday, March 12, 2009 12:12 PM
To: Razdan, Rajender; Greg Bernstein; ccamp
Subject: RE: Liaison to Q6/15 and Meeting Questions...

One refinement on:
(e) Measurements -- G.697 seems to give a rough framework on applications o=
f measurement, types of measurements, measurement parameters. Is this a goo=
d place for anyone investigating the relationship between control plane and=
 optical measurements to start? Other recommendations/ideas
We should ask Q6 how the results of these measurements could be used to ref=
ine the values of the impairment parameters used when computing an optical =
path.  As a part of this discussion we also need to understand when (i.e. w=
hat event) triggers the measurements.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Razdan, Rajender
Sent: Thursday, March 12, 2009 12:32 PM
To: Greg Bernstein; ccamp
Subject: RE: Liaison to Q6/15 and Meeting Questions...

Hi Greg/all,

     I think we do have a consensus on the relative roles of Q6 and CCAMP w=
ith regard to the WSON work. It seems to me that the questions Don put up e=
arlier, along with the set of questions you have below, form an excellent s=
tarting point for questions we should put forth to Q6 in its upcoming meeti=
ng. In addition to everything else I would also add :
FOADM/ROADM/OXC charcterization, i.e. are there any general characterizatio=
n/parametrization we can use? In particular is there a way to characterize =
the loss in a photonic network taking into account the filter characteristi=
cs of these devices?

Cheers,
Rajender Razdan

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Greg Bernstein
Sent: Thursday, March 12, 2009 11:53 AM
To: ccamp
Subject: Liaison to Q6/15 and Meeting Questions...

Hi folks, we seem to be re-iterating some issues that I thought we had reac=
hed consensus on. However in this conversation some good questions have ari=
sen for the special CCAMP/Q6 meeting.
I thought we had consensus that CCAMP will not define new optical impairmen=
ts, parameters, etc... but we will use ITU-T existing definitions. If we th=
ink we need something we will bring this up with Q6. The response we've see=
n from Q6 so far has been very positive in working together in this area.

Some potential questions and areas for discussion:
(a) WDM Link characterization  -- G.680 gives lots of examples in appendice=
s but does not actually specify yet. There are a host of other ITU-T docume=
nts that cover fiber, amplifiers, dispersion compensation modules, etc... S=
o we'll want Q6's input on a somewhat self contained model.
(b) Receiver characterization -- Is there are general characterization/para=
meterization we should use?
(c) Transmitter characterization -- Similar question
(d) Signal characterization -- There are a number of different documents in=
 this area, some are specific to SDH, some are very general WDM interface c=
haracterizations; Guidance would be welcome so that we don't over specializ=
e=2E
(e) Measurements -- G.697 seems to give a rough framework on applications o=
f measurement, types of measurements, measurement parameters. Is this a goo=
d place for anyone investigating the relationship between control plane and=
 optical measurements to start? Other recommendations/ideas.
(f) Characterization of optical parameters -- (feedback from Q6 desired) pa=
rameters that are NE wide, apply to each port, apply between particular por=
ts (port-to-port), frequency dependence of parameters (important for info m=
odel and encoding)

Other questions for Q6 from CCAMP?

Best Regards

Greg

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--_000_5292FFA96EC22A4386067E9DBCC0CD2B260DCF8D8FEXNAPtellabsw_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta content=3D"MSHTML 6.00.2900.3492" name=3D"GENERATOR">
<style title=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body ocsi=3D"x">
<div dir=3D"ltr"><font face=3D"Tahoma" color=3D"#000000" size=3D"2">One oth=
er item that came up in my read of the liaison text is that Q6 will do a gr=
eat job helping us with O-O-O, but O-E-O ends up going outside their area o=
f responsibility.&nbsp; The &quot;E&quot; is actually something
 that Q12 (from an architecture) and Q11 (from a signal rates/format) have =
responsibility for.</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">I can understand that we =
can talk about O-E-O in terms of a general use case when speaking with Q6, =
but the issues specifiic to the&nbsp;&quot;E&quot; layer&nbsp;as well as&nb=
sp;how it relates to the &quot;O&quot; layer is outside Q6's scope.</font><=
/div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">Jonathan Sadler</font></d=
iv>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div id=3D"divRpF443134" style=3D"DIRECTION: ltr">
<hr tabindex=3D"-1">
<font face=3D"Tahoma" size=3D"2"><b>From:</b> [email-masked] [own=
[email-masked]] On Behalf Of Malcolm Betts [[email-masked]]<br>
<b>Sent:</b> Thursday, March 12, 2009 12:12 PM<br>
<b>To:</b> Razdan, Rajender; Greg Bernstein; ccamp<br>
<b>Subject:</b> RE: Liaison to Q6/15 and Meeting Questions...<br>
</font><br>
</div>
<div></div>
<div>
<div dir=3D"ltr" align=3D"left"><font face=3D"Arial" color=3D"#0000ff" size=
=3D"2"><span class=3D"750120917-12032009">One refinement on:</span></font><=
/div>
<div dir=3D"ltr" align=3D"left"><span class=3D"750120917-12032009">(e) Meas=
urements -- G.697 seems to give a rough framework on applications of measur=
ement, types of measurements, measurement parameters. Is this a good place =
for anyone investigating the relationship
 between control plane and optical measurements to start? Other recommendat=
ions/ideas</span></div>
<div><span class=3D"750120917-12032009"><font face=3D"Arial" color=3D"#0000=
ff" size=3D"2">We should ask Q6 how the results of these measurements could=
 be used to refine the values of the impairment parameters used when comput=
ing an optical path.&nbsp; As a part of this
 discussion we also need to understand when (i.e. what event) triggers the =
measurements.</font></span></div>
<p><span lang=3D"en-us"><font face=3D"Arial" size=3D"2">Malcolm Betts</font=
></span> <br>
<span lang=3D"en-us"><font face=3D"Arial" size=3D"2">Nortel Networks</font>=
</span> <br>
<span lang=3D"en-us"><font face=3D"Arial" size=3D"2">Phone: &#43;1 613 763 =
7860 (ESN 393)</font></span>
<br>
<span lang=3D"en-us"><font face=3D"Arial" size=3D"2">email: betts01@nortel.=
com</font></span>
</p>
<p></p>
<hr tabindex=3D"-1">
<font face=3D"Tahoma" size=3D"2"><b>From:</b> [email-masked] [mai=
lto:[email-masked]]
<b>On Behalf Of </b>Razdan, Rajender<br>
<b>Sent:</b> Thursday, March 12, 2009 12:32 PM<br>
<b>To:</b> Greg Bernstein; ccamp<br>
<b>Subject:</b> RE: Liaison to Q6/15 and Meeting Questions...<br>
</font><br>
<p></p>
<div></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"465112216-12032009"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2">Hi Greg/all,</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"465112216-12032009"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span class=3D"465112216-12032009"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2">&nbsp;&nbsp;&nbsp;&nbsp; I think =
we do have a consensus on the relative roles of Q6 and CCAMP with regard to=
 the WSON work. It seems to me that the questions Don put up earlier,
 along with the set of questions you have below, form an excellent starting=
 point for questions we should put forth to Q6 in its upcoming meeting. In =
addition to everything else I would also add :</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"465112216-12032009"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2">FOADM/ROADM/OXC charcterization, =
i=2Ee. are there any general characterization/parametrization we can use? I=
n particular is there a way to characterize the
 loss in a photonic network taking into account the filter characteristics =
of these devices?</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"465112216-12032009"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span class=3D"465112216-12032009"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2">Cheers,</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"465112216-12032009"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2">Rajender Razdan</font></span></di=
v>
<br>
<div class=3D"OutlookMessageHeader" lang=3D"en-us" dir=3D"ltr" align=3D"lef=
t"></div>
<br>
<img alt=3D"" hspace=3D"0" src=3D"cid:750120917@12032009-223F" align=3D"bas=
eline" border=3D"0"><br>
<div class=3D"OutlookMessageHeader" lang=3D"en-us" dir=3D"ltr" align=3D"lef=
t">
<hr tabindex=3D"-1">
</div>
<div class=3D"OutlookMessageHeader" lang=3D"en-us" dir=3D"ltr" align=3D"lef=
t"><font face=3D"Tahoma" size=3D"2"><b>From:</b> [email-masked] [=
mailto:[email-masked]]
<b>On Behalf Of </b>Greg Bernstein<br>
<b>Sent:</b> Thursday, March 12, 2009 11:53 AM<br>
<b>To:</b> ccamp<br>
<b>Subject:</b> Liaison to Q6/15 and Meeting Questions...<br>
</font><br>
</div>
<div></div>
Hi folks, we seem to be re-iterating some issues that I thought we had reac=
hed consensus on. However in this conversation some good questions have ari=
sen for the special CCAMP/Q6 meeting.<br>
I thought we had consensus that CCAMP <i><b>will not define new optical imp=
airments, parameters, etc... but we will use ITU-T existing definitions. If=
 we think we need something we will bring this up with Q6.
</b></i>The response we've seen from Q6 so far has been very positive in wo=
rking together in this area.
<br>
<br>
Some potential questions and areas for discussion:<br>
(a) WDM Link characterization&nbsp; -- G.680 gives lots of examples in appe=
ndices but does not actually specify yet. There are a host of other ITU-T d=
ocuments that cover fiber, amplifiers, dispersion compensation modules, etc=
.=2E. So we'll want Q6's input on a somewhat
 self contained model.<br>
(b) Receiver characterization -- Is there are general characterization/para=
meterization we should use?<br>
(c) Transmitter characterization -- Similar question<br>
(d) Signal characterization -- There are a number of different documents in=
 this area, some are specific to SDH, some are very general WDM interface c=
haracterizations; Guidance would be welcome so that we don't over specializ=
e=2E<br>
(e) Measurements -- G.697 seems to give a rough framework on applications o=
f measurement, types of measurements, measurement parameters. Is this a goo=
d place for anyone investigating the relationship between control plane and=
 optical measurements to start?
 Other recommendations/ideas.<br>
(f) Characterization of optical parameters -- (feedback from Q6 desired) pa=
rameters that are NE wide, apply to each port, apply between particular por=
ts (port-to-port), frequency dependence of parameters (important for info m=
odel and encoding)<br>
<br>
Other questions for Q6 from CCAMP?<br>
<br>
Best Regards<br>
<br>
Greg<br>
<pre class=3D"moz-signature" cols=3D"72">--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</pre>
<br>
</div>
<pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
</pre></body>
</html>

--_000_5292FFA96EC22A4386067E9DBCC0CD2B260DCF8D8FEXNAPtellabsw_--

--_004_5292FFA96EC22A4386067E9DBCC0CD2B260DCF8D8FEXNAPtellabsw_
Content-Type: image/gif; name="ATT2601587.gif"
Content-Description: ATT2601587.gif
Content-Disposition: inline; filename="ATT2601587.gif"; size=3410;
	creation-date="Thu, 12 Mar 2009 12:16:06 GMT";
	modification-date="Thu, 12 Mar 2009 16:59:56 GMT"
Content-ID: <750120917@12032009-223F>
Content-Location: ATT2601587.gif
Content-Transfer-Encoding: base64

--_004_5292FFA96EC22A4386067E9DBCC0CD2B260DCF8D8FEXNAPtellabsw_--

Delivery-date: Thu, 12 Mar 2009 18:49:08 +0000
Content-class: urn:content-classes:message
Subject: CCAMP Agenda
Date: Thu, 12 Mar 2009 14:47:50 -0400
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

Hi,

The CCAMP agenda is available:

http://www.ietf.org/proceedings/09mar/agenda/ccamp.htm

Let us know if any issues. If you have a slot, please provide your
slides no later than March 23rd  (Monday).=20

Deborah and Adrian

Delivery-date: Thu, 12 Mar 2009 17:14:24 +0000
Content-class: urn:content-classes:message
Subject: RE: Liaison to Q6/15 and Meeting Questions...
Date: Thu, 12 Mar 2009 13:12:57 -0400
From: "Malcolm Betts" <[email-masked]>
To: "Razdan, Rajender" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "ccamp" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A335.CA6CE065
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C9A335.CA6CE065"

------_=_NextPart_002_01C9A335.CA6CE065
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

One refinement on:
(e) Measurements -- G.697 seems to give a rough framework on
applications of measurement, types of measurements, measurement
parameters. Is this a good place for anyone investigating the
relationship between control plane and optical measurements to start?
Other recommendations/ideas
We should ask Q6 how the results of these measurements could be used to
refine the values of the impairment parameters used when computing an
optical path.  As a part of this discussion we also need to understand
when (i.e. what event) triggers the measurements.

Malcolm Betts=20
Nortel Networks=20
Phone: +1 613 763 7860 (ESN 393)=20
email: [email-masked]=20

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Razdan, Rajender
Sent: Thursday, March 12, 2009 12:32 PM
To: Greg Bernstein; ccamp
Subject: RE: Liaison to Q6/15 and Meeting Questions...

Hi Greg/all,
=20
     I think we do have a consensus on the relative roles of Q6 and
CCAMP with regard to the WSON work. It seems to me that the questions
Don put up earlier, along with the set of questions you have below, form
an excellent starting point for questions we should put forth to Q6 in
its upcoming meeting. In addition to everything else I would also add :
FOADM/ROADM/OXC charcterization, i.e. are there any general
characterization/parametrization we can use? In particular is there a
way to characterize the loss in a photonic network taking into account
the filter characteristics of these devices?
=20
Cheers,
Rajender Razdan

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Bernstein
Sent: Thursday, March 12, 2009 11:53 AM
To: ccamp
Subject: Liaison to Q6/15 and Meeting Questions...

Hi folks, we seem to be re-iterating some issues that I thought we had
reached consensus on. However in this conversation some good questions
have arisen for the special CCAMP/Q6 meeting.
I thought we had consensus that CCAMP will not define new optical
impairments, parameters, etc... but we will use ITU-T existing
definitions. If we think we need something we will bring this up with
Q6. The response we've seen from Q6 so far has been very positive in
working together in this area.=20

Some potential questions and areas for discussion:
(a) WDM Link characterization  -- G.680 gives lots of examples in
appendices but does not actually specify yet. There are a host of other
ITU-T documents that cover fiber, amplifiers, dispersion compensation
modules, etc... So we'll want Q6's input on a somewhat self contained
model.
(b) Receiver characterization -- Is there are general
characterization/parameterization we should use?
(c) Transmitter characterization -- Similar question
(d) Signal characterization -- There are a number of different documents
in this area, some are specific to SDH, some are very general WDM
interface characterizations; Guidance would be welcome so that we don't
over specialize.
(e) Measurements -- G.697 seems to give a rough framework on
applications of measurement, types of measurements, measurement
parameters. Is this a good place for anyone investigating the
relationship between control plane and optical measurements to start?
Other recommendations/ideas.
(f) Characterization of optical parameters -- (feedback from Q6 desired)
parameters that are NE wide, apply to each port, apply between
particular ports (port-to-port), frequency dependence of parameters
(important for info model and encoding)

Other questions for Q6 from CCAMP?

Best Regards

Greg

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

------_=_NextPart_002_01C9A335.CA6CE065
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D750120917-12032009>One refinement on:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D750120917-12032009>(e) =
Measurements -- G.697=20
seems to give a rough framework on applications of measurement, types of =

measurements, measurement parameters. Is this a good place for anyone=20
investigating the relationship between control plane and optical =
measurements to=20
start? Other recommendations/ideas</SPAN></DIV>
<DIV><SPAN class=3D750120917-12032009><FONT face=3DArial color=3D#0000ff =
size=3D2>We=20
should ask Q6 how the results of these measurements could be used to =
refine the=20
values of the impairment parameters used when computing an optical =
path.&nbsp;=20
As a part of this discussion we also need to understand when (i.e. what =
event)=20
triggers the measurements.</FONT></SPAN></DIV><!-- Converted from =
text/rtf format -->
<P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Malcolm =
Betts</FONT></SPAN>=20
<BR><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Nortel =
Networks</FONT></SPAN>=20
<BR><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Phone: +1 613 763 =
7860 (ESN=20
393)</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial =
size=3D2>email:=20
[email-masked]</FONT></SPAN> </P>
<P>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Razdan,=20
Rajender<BR><B>Sent:</B> Thursday, March 12, 2009 12:32 PM<BR><B>To:</B> =
Greg=20
Bernstein; ccamp<BR><B>Subject:</B> RE: Liaison to Q6/15 and Meeting=20
Questions...<BR></FONT><BR></P>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D465112216-12032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Greg/all,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D465112216-12032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D465112216-12032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; I think we do have a =
consensus on=20
the relative roles of Q6 and CCAMP with regard to the WSON work. It =
seems to me=20
that the questions Don put up earlier, along with the set of questions =
you have=20
below, form an excellent starting point for questions we should put =
forth to Q6=20
in its upcoming meeting. In addition to everything else I would also add =

:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D465112216-12032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>FOADM/ROADM/OXC charcterization, i.e. are there =
any general=20
characterization/parametrization we can use? In particular is there a =
way to=20
characterize the loss in a photonic network taking into account the =
filter=20
characteristics of these devices?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D465112216-12032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D465112216-12032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D465112216-12032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Rajender Razdan</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft></DIV><BR><IMG=20
alt=3D"" hspace=3D0 src=3D"cid:750120917@12032009-223F" align=3Dbaseline =
border=3D0><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
</DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
size=3D2><B>From:</B> [email-masked] =
[mailto:[email-masked]]=20
<B>On Behalf Of </B>Greg Bernstein<BR><B>Sent:</B> Thursday, March 12, =
2009=20
11:53 AM<BR><B>To:</B> ccamp<BR><B>Subject:</B> Liaison to Q6/15 and =
Meeting=20
Questions...<BR></FONT><BR></DIV>
<DIV></DIV>Hi folks, we seem to be re-iterating some issues that I =
thought we=20
had reached consensus on. However in this conversation some good =
questions have=20
arisen for the special CCAMP/Q6 meeting.<BR>I thought we had consensus =
that=20
CCAMP <I><B>will not define new optical impairments, parameters, etc... =
but we=20
will use ITU-T existing definitions. If we think we need something we =
will bring=20
this up with Q6. </B></I>The response we've seen from Q6 so far has been =
very=20
positive in working together in this area. <BR><BR>Some potential =
questions and=20
areas for discussion:<BR>(a) WDM Link characterization&nbsp; -- G.680 =
gives lots=20
of examples in appendices but does not actually specify yet. There are a =
host of=20
other ITU-T documents that cover fiber, amplifiers, dispersion =
compensation=20
modules, etc... So we'll want Q6's input on a somewhat self contained=20
model.<BR>(b) Receiver characterization -- Is there are general=20
characterization/parameterization we should use?<BR>(c) Transmitter=20
characterization -- Similar question<BR>(d) Signal characterization -- =
There are=20
a number of different documents in this area, some are specific to SDH, =
some are=20
very general WDM interface characterizations; Guidance would be welcome =
so that=20
we don't over specialize.<BR>(e) Measurements -- G.697 seems to give a =
rough=20
framework on applications of measurement, types of measurements, =
measurement=20
parameters. Is this a good place for anyone investigating the =
relationship=20
between control plane and optical measurements to start? Other=20
recommendations/ideas.<BR>(f) Characterization of optical parameters --=20
(feedback from Q6 desired) parameters that are NE wide, apply to each =
port,=20
apply between particular ports (port-to-port), frequency dependence of=20
parameters (important for info model and encoding)<BR><BR>Other =
questions for Q6=20
from CCAMP?<BR><BR>Best Regards<BR><BR>Greg<BR><PRE =
class=3Dmoz-signature cols=3D"72">--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</PRE><BR></BODY></HTML>

------_=_NextPart_002_01C9A335.CA6CE065--

------_=_NextPart_001_01C9A335.CA6CE065
Content-Type: image/gif;
	name="ATT2601587.gif"
Content-Transfer-Encoding: base64
Content-ID: <750120917@12032009-223F>
Content-Description: ATT2601587.gif
Content-Location: ATT2601587.gif

------_=_NextPart_001_01C9A335.CA6CE065--

Delivery-date: Thu, 12 Mar 2009 16:32:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Liaison to Q6/15 and Meeting Questions...
Date: Thu, 12 Mar 2009 12:31:31 -0400
From: "Razdan, Rajender" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, "ccamp" <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_3AC2_01C9A30E.7C19B920
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C9A330.02EFC192"

------_=_NextPart_001_01C9A330.02EFC192
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Greg/all,
=20
     I think we do have a consensus on the relative roles of Q6 and
CCAMP with regard to the WSON work. It seems to me that the questions
Don put up earlier, along with the set of questions you have below, form
an excellent starting point for questions we should put forth to Q6 in
its upcoming meeting. In addition to everything else I would also add :
FOADM/ROADM/OXC charcterization, i.e. are there any general
characterization/parametrization we can use? In particular is there a
way to characterize the loss in a photonic network taking into account
the filter characteristics of these devices?
=20
Cheers,
Rajender Razdan

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Bernstein
Sent: Thursday, March 12, 2009 11:53 AM
To: ccamp
Subject: Liaison to Q6/15 and Meeting Questions...

Hi folks, we seem to be re-iterating some issues that I thought we had
reached consensus on. However in this conversation some good questions
have arisen for the special CCAMP/Q6 meeting.
I thought we had consensus that CCAMP will not define new optical
impairments, parameters, etc... but we will use ITU-T existing
definitions. If we think we need something we will bring this up with
Q6. The response we've seen from Q6 so far has been very positive in
working together in this area.=20

Some potential questions and areas for discussion:
(a) WDM Link characterization  -- G.680 gives lots of examples in
appendices but does not actually specify yet. There are a host of other
ITU-T documents that cover fiber, amplifiers, dispersion compensation
modules, etc... So we'll want Q6's input on a somewhat self contained
model.
(b) Receiver characterization -- Is there are general
characterization/parameterization we should use?
(c) Transmitter characterization -- Similar question
(d) Signal characterization -- There are a number of different documents
in this area, some are specific to SDH, some are very general WDM
interface characterizations; Guidance would be welcome so that we don't
over specialize.
(e) Measurements -- G.697 seems to give a rough framework on
applications of measurement, types of measurements, measurement
parameters. Is this a good place for anyone investigating the
relationship between control plane and optical measurements to start?
Other recommendations/ideas.
(f) Characterization of optical parameters -- (feedback from Q6 desired)
parameters that are NE wide, apply to each port, apply between
particular ports (port-to-port), frequency dependence of parameters
(important for info model and encoding)

Other questions for Q6 from CCAMP?

Best Regards

Greg

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

------_=_NextPart_001_01C9A330.02EFC192
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><!DOCTYPE =
HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><!DOCTYPE HTML =
PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><head><META =
content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type">
<META content=3D"text/html; charset=3Dutf-8" http-equiv=3DContent-Type>
<META content=3D"MSHTML 6.00.2900.3395" name=3DGENERATOR></head><BODY>
<DIV align=3Dleft dir=3Dltr><SPAN class=3D465112216-12032009><FONT =
color=3D#0000ff face=3DArial size=3D2>Hi Greg/all,</FONT></SPAN></DIV>
<DIV align=3Dleft dir=3Dltr><SPAN class=3D465112216-12032009><FONT =
color=3D#0000ff face=3DArial size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV align=3Dleft dir=3Dltr><SPAN class=3D465112216-12032009><FONT =
color=3D#0000ff face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; I think =
we do have a consensus on=20
the relative roles of Q6 and CCAMP with regard to the WSON work. It =
seems to me=20
that the questions Don put up earlier, along with the set of questions =
you have=20
below, form an excellent starting point for questions we should put =
forth to Q6=20
in its upcoming meeting. In addition to everything else I would also add =

:</FONT></SPAN></DIV>
<DIV align=3Dleft dir=3Dltr><SPAN class=3D465112216-12032009><FONT =
color=3D#0000ff face=3DArial size=3D2>FOADM/ROADM/OXC charcterization, =
i.e. are there any general=20
characterization/parametrization we can use? In particular is there a =
way to=20
characterize the loss in a photonic network taking into account the =
filter=20
characteristics of these devices?</FONT></SPAN></DIV>
<DIV align=3Dleft dir=3Dltr><SPAN class=3D465112216-12032009><FONT =
color=3D#0000ff face=3DArial size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV align=3Dleft dir=3Dltr><SPAN class=3D465112216-12032009><FONT =
color=3D#0000ff face=3DArial size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV align=3Dleft dir=3Dltr><SPAN class=3D465112216-12032009><FONT =
color=3D#0000ff face=3DArial size=3D2>Rajender =
Razdan</FONT></SPAN></DIV><BR>
<DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr lang=3Den-us>
</DIV><BR><IMG ALIGN=3D"baseline" ALT BORDER=3D"0" HSPACE=3D"0" =
SRC=3D"cid:[email-masked]"><BR><DIV align=3Dleft =
class=3DOutlookMessageHeader dir=3Dltr lang=3Den-us><HR =
tabIndex=3D-1></DIV><DIV align=3Dleft class=3DOutlookMessageHeader =
dir=3Dltr lang=3Den-us>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Greg=20
Bernstein<BR><B>Sent:</B> Thursday, March 12, 2009 11:53 =
AM<BR><B>To:</B>=20
ccamp<BR><B>Subject:</B> Liaison to Q6/15 and Meeting=20
Questions...<BR></FONT><BR></DIV>
<DIV></DIV>Hi folks, we seem to be re-iterating some issues that I =
thought we=20
had reached consensus on. However in this conversation some good =
questions have=20
arisen for the special CCAMP/Q6 meeting.<BR>I thought we had consensus =
that=20
CCAMP <I><B>will not define new optical impairments, parameters, etc... =
but we=20
will use ITU-T existing definitions. If we think we need something we =
will bring=20
this up with Q6. </B></I>The response we've seen from Q6 so far has been =
very=20
positive in working together in this area. <BR><BR>Some potential =
questions and=20
areas for discussion:<BR>(a) WDM Link characterization&nbsp; -- G.680 =
gives lots=20
of examples in appendices but does not actually specify yet. There are a =
host of=20
other ITU-T documents that cover fiber, amplifiers, dispersion =
compensation=20
modules, etc... So we'll want Q6's input on a somewhat self contained=20
model.<BR>(b) Receiver characterization -- Is there are general=20
characterization/parameterization we should use?<BR>(c) Transmitter=20
characterization -- Similar question<BR>(d) Signal characterization -- =
There are=20
a number of different documents in this area, some are specific to SDH, =
some are=20
very general WDM interface characterizations; Guidance would be welcome =
so that=20
we don't over specialize.<BR>(e) Measurements -- G.697 seems to give a =
rough=20
framework on applications of measurement, types of measurements, =
measurement=20
parameters. Is this a good place for anyone investigating the =
relationship=20
between control plane and optical measurements to start? Other=20
recommendations/ideas.<BR>(f) Characterization of optical parameters --=20
(feedback from Q6 desired) parameters that are NE wide, apply to each =
port,=20
apply between particular ports (port-to-port), frequency dependence of=20
parameters (important for info model and encoding)<BR><BR>Other =
questions for Q6=20
from CCAMP?<BR><BR>Best Regards<BR><BR>Greg<BR><PRE =
class=3Dmoz-signature cols=3D"72">--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</PRE><BR></BODY></HTML>

------_=_NextPart_001_01C9A330.02EFC192--

------=_NextPart_000_3AC2_01C9A30E.7C19B920
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>

------=_NextPart_000_3AC2_01C9A30E.7C19B920--

Delivery-date: Thu, 12 Mar 2009 15:54:58 +0000
Date: Thu, 12 Mar 2009 08:52:40 -0700
From: Greg Bernstein <[email-masked]>
To: ccamp <[email-masked]>
Subject: Liaison to Q6/15 and Meeting Questions...

This is a multi-part message in MIME format.
--------------060008040909080600040909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi folks, we seem to be re-iterating some issues that I thought we had 
reached consensus on. However in this conversation some good questions 
have arisen for the special CCAMP/Q6 meeting.
I thought we had consensus that CCAMP /*will not define new optical 
impairments, parameters, etc... but we will use ITU-T existing 
definitions. If we think we need something we will bring this up with 
Q6. */The response we've seen from Q6 so far has been very positive in 
working together in this area.

Some potential questions and areas for discussion:
(a) WDM Link characterization  -- G.680 gives lots of examples in 
appendices but does not actually specify yet. There are a host of other 
ITU-T documents that cover fiber, amplifiers, dispersion compensation 
modules, etc... So we'll want Q6's input on a somewhat self contained model.
(b) Receiver characterization -- Is there are general 
characterization/parameterization we should use?
(c) Transmitter characterization -- Similar question
(d) Signal characterization -- There are a number of different documents 
in this area, some are specific to SDH, some are very general WDM 
interface characterizations; Guidance would be welcome so that we don't 
over specialize.
(e) Measurements -- G.697 seems to give a rough framework on 
applications of measurement, types of measurements, measurement 
parameters. Is this a good place for anyone investigating the 
relationship between control plane and optical measurements to start? 
Other recommendations/ideas.
(f) Characterization of optical parameters -- (feedback from Q6 desired) 
parameters that are NE wide, apply to each port, apply between 
particular ports (port-to-port), frequency dependence of parameters 
(important for info model and encoding)

Other questions for Q6 from CCAMP?

Best Regards

Greg

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

--------------060008040909080600040909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi folks, we seem to be re-iterating some issues that I thought we had
reached consensus on. However in this conversation some good questions
have arisen for the special CCAMP/Q6 meeting.<br>
I thought we had consensus that CCAMP <i><b>will not define new
optical impairments, parameters, etc... but we will use ITU-T existing
definitions. If we think we need something we will bring this up with
Q6. </b></i>The response we've seen from Q6 so far has been very
positive in working together in this area. <br>
<br>
Some potential questions and areas for discussion:<br>
(a) WDM Link characterization&nbsp; -- G.680 gives lots of examples in
appendices but does not actually specify yet. There are a host of other
ITU-T documents that cover fiber, amplifiers, dispersion compensation
modules, etc... So we'll want Q6's input on a somewhat self contained
model.<br>
(b) Receiver characterization -- Is there are general
characterization/parameterization we should use?<br>
(c) Transmitter characterization -- Similar question<br>
(d) Signal characterization -- There are a number of different
documents in this area, some are specific to SDH, some are very general
WDM interface characterizations; Guidance would be welcome so that we
don't over specialize.<br>
(e) Measurements -- G.697 seems to give a rough framework on
applications of measurement, types of measurements, measurement
parameters. Is this a good place for anyone investigating the
relationship between control plane and optical measurements to start?
Other recommendations/ideas.<br>
(f) Characterization of optical parameters -- (feedback from Q6
desired) parameters that are NE wide, apply to each port, apply between
particular ports (port-to-port), frequency dependence of parameters
(important for info model and encoding)<br>
<br>
Other questions for Q6 from CCAMP?<br>
<br>
Best Regards<br>
<br>
Greg<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</pre>
</body>
</html>

--------------060008040909080600040909--

Delivery-date: Thu, 12 Mar 2009 01:13:42 +0000
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Wed, 11 Mar 2009 20:11:48 -0500
Content-class: urn:content-classes:message
From: "O'Connor, Don" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Adrian

You indicate

"There is NO REQUIREMENT in any of this WSON work for
   any measurement of impairments. The only person to say there
   is a requirement is you. Everyone else keeps repeating that there
   is no requirement to measure impairments. The only requirement
   is to distribute information about impairments however it has been
   obtained, and to consider how to use the information during path
   computation"

This statement is incorrect.

The substance of my email indicated that there is an IMPLIED REQUIREMENT
for ROADMs to make some form of measurement and it is not appropriate
for CCAMP to write protocol standards that imply ROADM data plane
related requirements.

Or if this is not the case and it is not necessary for ROADMs to make
any measurements, then can we agree that the  following text is added to
the Introduction and Scope of all relevant GMPLS for WSON with optical
impairments IDs.

" GMPLS for WSON with Optical Impairments only applies to the case where
ROADMs, OXC, or any other optical network nodes do not make any
measurements related to optical link impairments"

Regards

Don

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]=20
Sent: Wednesday, March 11, 2009 7:10 PM
To: O'Connor, Don; [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Hi Don,

> The draft liaison text below

Not draft any more. The liaison has been sent.

> does not ask Q6/15's views on how the optical link impairment
> data should be acquired such that the wavelength routing
> assignment achieves satisfactory results.

Right.
The liaison explicitly says
"It is not within the scope of CCAMP to determine how impairments are=20
gathered."

Nor is it our business to request anyone to make standards for this
purpose.
If the standards do not exist and are needed, I am sure people will make

contributions to Q6/5 accordingly.

> Some potential options are
>
> 1) ROADM / OXC measure impairments in service - At present there
> are no ITU SG 15 standards for this
>
> 2) ROADM / OXC estimate link impairment based on measuring
> some link parameters - At present there are no ITU SG 15 standards
> for this
>
> 3) Link impairments are measured out of service with some test
> equipment - then you do not need any CCAMP ROADM protocols
> - the measurement results can be directly exported from the test
> equipment to the PCE

I have no idea what you mean by a CCAMP ROADM protocol.

Of course, it is possible to export information into the PCE's TED by
any=20
means. This is fundamental to RFC 4655.

You may be considering that all path computaiton in a WSON is
centralised,=20
but please note that if the path computation is fully distributed, a=20
convenient mechanism may be to use a routing protocol to distribute this

information (just as we do for TE metric which is a static configured=20
parameter).

> 4) Link impairments are estimated without making any measurements
>  - we do not need any CCAMP ROADM protocols

This is just as above.

Don, it is OK if you do not want to use GMPLS in your WSON.

> The draft text in the liaison below appears to assume that ITU SG 15
> already has standards in place to support control plane based
wavelength
> routing and assignment based on optical impairments, and all that is
> necessary is for SG 15 Q6 to provide CCAMP with some guidance on how
to
> use these standards. I do not [think] this is the case, particularly
for=20
> the
> case of 1) or 2) above.

Hmmm. You sound less than sure it is the case for 3) and 4).

But no matter. The whole reason for talking to Q6/15 is to let them tell
us=20
what the state of affairs is. I am sure Q6/15 are perfectly capable of=20
telling us what can be achieved using their in force Recommendations.

> Let me make an analogy. Today there are no IETF MPLS OAM standards for
> PM measurement. It would not be good for ITU to go off and generate
some
> standards that would require MPLS LSR to perform some PM measurements.

Poor analogy on two fronts.
1. Generating requirements is a very good thing. It is the construction
   of solutions that would be worrying.
2. There is NO REQUIREMENT in any of this WSON work for
   any measurement of impairments. The only person to say there
   is a requirement is you. Everyone else keeps repeating that there
   is no requirement to measure impairments. The only requirement
   is to distribute information about impairments however it has been
   obtained, and to consider how to use the information during path
   computation.

> To move the process forward, I will propose the following update
> to the draft liaison text below

As I said in my previous two emails (and this one) the liaison has
already=20
gone.

> "We would appreciate Q6/15's view on the following issues:
> - What optical link impairments are suitable for consideration in this
>   type of network,

OK. We have that already.

> - How should these impairments be measured, estimated, or
> otherwise determined

Why? It is not our business.
If you want an answer to this question, you have to go to Q6/15 direct,
not=20
through CCAMP.
Since "configured" is always an answer to your question, there is
already a=20
role for CCAMP protocols to distribute the configured information.

> - In addition to optical link impairments, should other impairments be
> considered such as those introduced by ROADM / OXC, Optical
> Amplifiers, etc

I think we are considering the OLS when we say "optical link", aren't
we?
It may be that we should also consider nodal impairments (at ROADMs and=20
PXCs) and that would be a very interesting question to put to Q6/15
during=20
the meeting.

But, as Kireeti commented...
| While I'd like to see this broader, what we deal with primarily in
| GMPLS is link parameters.  So I'm okay with this (as a start).

We should note that the IGPs do now have the capability to exchange node

capabilities, so this would not be hard to factor into GMPLS.

> - What rules should we use for these impairments to achieve
>  a reasonable approximation of how they are accumulated
>  along a path?
>  That is, CCAMP is looking for the rules by which the end-
>  to-end impairments of a path may be determined from a
>  knowledge of parameters of the path and impairments on
>  the path segments.

OK. We have that already.

> - What are the generic encodings and ranges of values for
>  the impairment parameters?

OK. We have that already.

> - Which existing Recommendations can be applied

OK. We have that already.

> - Will it be necessary for ITU SG 15 Q6 to generate any new
> Recommendations or Amendments to existing Recommendations
> to support this application?

That is also a fine question to bring up in the meeting.
I suspect that in answer to the previous question we will be told of any

lacunae.

Cheers,
Adrian=20

Delivery-date: Wed, 11 Mar 2009 23:31:23 +0000
Content-class: urn:content-classes:message
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Wed, 11 Mar 2009 18:30:05 -0500
From: "O'Connor, Don" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Adrian

The draft liaison text below does not ask Q6/15's views on how the
optical link impairment data should be acquired such that the wavelength
routing assignment achieves satisfactory results. Some potential options
are

1) ROADM / OXC measure impairments in service - At present there are no
ITU SG 15 standards for this

2) ROADM / OXC estimate link impairment based on measuring some link
parameters - At present there are no ITU SG 15 standards for this

3) Link impairments are measured out of service with some test equipment
- then you do not need any CCAMP ROADM protocols - the measurement
results can be directly exported from the test equipment to the PCE

4) Link impairments are estimated without making any measurements - we
do not need any CCAMP ROADM protocols

The draft text in the liaison below appears to assume that ITU SG 15
already has standards in place to support control plane based wavelength
routing and assignment based on optical impairments, and all that is
necessary is for SG 15 Q6 to provide CCAMP with some guidance on how to
use these standards. I do not this is the case, particularly for the
case of 1) or 2) above.=20

Let me make an analogy. Today there are no IETF MPLS OAM standards for
PM measurement. It would not be good for ITU to go off and generate some
standards that would require MPLS LSR to perform some PM measurements.

To move the process forward, I will propose the following update to the
draft liaison text below

"We would appreciate Q6/15's view on the following issues:
- What optical link impairments are suitable for consideration in this
  type of network,
- How should these impairments be measured, estimated, or otherwise
determined
- In addition to optical link impairments, should other impairments be
considered such as those introduced by ROADM / OXC, Optical Amplifiers,
etc=20
- What rules should we use for these impairments to achieve
  a reasonable approximation of how they are accumulated
  along a path?
  That is, CCAMP is looking for the rules by which the end-
  to-end impairments of a path may be determined from a
  knowledge of parameters of the path and impairments on
  the path segments.
- What are the generic encodings and ranges of values for
  the impairment parameters?
- Which existing Recommendations can be applied
- Will it be necessary for ITU SG 15 Q6 to generate any new
Recommendations or Amendments to existing Recommendations to support
this application?"

Regards

Don

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]=20
Sent: Wednesday, March 11, 2009 5:33 PM
To: O'Connor, Don; [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Don,

You will see from the liaison sent that we have said...

"It is not within the scope of CCAMP to determine how impairments are
gathered."

and

"We would appreciate Q6/15's view on the following issues:
- What impairments are suitable for consideration in this
  type of network, and which Recommendations should we use
  as references?
- What rules should we use for these impairments to achieve
  a reasonable approximation of how they are accumulated
  along a path?
  That is, CCAMP is looking for the rules by which the end-
  to-end impairments of a path may be determined from a
  knowledge of parameters of the path and impairments on
  the path segments.
- What are the generic encodings and ranges of values for
  the impairment parameters?"

I hope you feel that this defers suitably to Q6/15.

If it does not, I feel sure that they will tell us their feelings.

Thanks,
Adrian

----- Original Message -----=20
From: "O'Connor, Don" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Malcolm Betts"=20
<[email-masked]>; <[email-masked]>
Sent: Wednesday, March 11, 2009 10:17 PM
Subject: RE: Re-Updated Draft Liaison to Q6/15

Adrian, Malcolm

Malcolm's email and Adrian's reply do not address the key issue of how
the link impairments are measured or estimated. It is up to ITU SG 15 Q6
to determine how this should be accomplished such that wavelength
routing and assignment with optical impairments produces a satisfactory
result for service providers. ITU SG 15 has responsibility for the
optical channel data plane not CCAMP.

ITU SG 15 Q6 needs to specify what information the Path Computation
Elements requires to adequately perform the computation, and how it is
measured or acquired including the role of ROADM /OXC. After ITU SG 15
Q6 specifies these details (note that it may be necessary for ITU SG 15
to generate one or more new standards or standard amendments), then
CCAMP can specify what protocols to use and how to encode the
information.

With respect to the liaison, Adrian indicated below,

" I'm open to suggestions of text."

I proposed an updated version of the liaison yesterday. I suggest that
we either use this version or somebody propose an update to what I
proposed

Regards

Don

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, March 11, 2009 9:22 AM
To: Malcolm Betts; O'Connor, Don; [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Thanks Malcolm.
Helpful.

> Looking at the comments from Don and Dan I think we should take
> a step back and think about the requirements that the protocol
> extensions are intended to address

Sure

> I think we can all agree that we must be able to report link
> impairments and the encoding we use should accommodate
> the parameters currently defined by Q6 and should be
> extensible to accommodate any parameters that are defined
> at a later date.

That is true.
And that (I was hoping) is the bulk of the work to be done with Q6's
help.

> Now to the more contentious issues:
>
> - How frequently do we expect the impairment parameters to
>   change, is it in the order of mSec, Seconds, minutes, hours,
>   days.  I suggest that once it is beyond seconds the actual
>   frequency becomes a "don't care".

You missed "never".

>From a protocol standpoint there are only three categories:
- never
- within the bounds of a routing protocol to advertise
- too fast for a routing protocol to advertise.

Certainly Q6 can help us identify if the third case applies. (I had
assumed
not since current networks use manual configuration.)

> - Does the protocol need to activate/deactivate measurements
>   on an in service link.  If so what types of parameters would
>   need to be specified for these measurements.

I have not heard anyone asking for this (perhaps I am not listening?).
This seems like a whole different kettle of ball-games akin to running
before we can walk.

> My assumption is that if we define an extensible method for
> reporting link impairment parameters then we can use the
> same message to report any link impairments independent
> of how they are provided (provisioned, measured at installation
> time, measured in service...).

Right.
Yes, isn't this where we started?
What we need from Q6 is help to understand how to encode each of the
parameters, and what the ranges are for each parameter.

> I suggest that we phrase the liaison to get input from Q6
> to help us define the requirements for these last two points.

I'm open to suggesitons of text.

Adrian

Delivery-date: Wed, 11 Mar 2009 22:18:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Wed, 11 Mar 2009 17:17:22 -0500
From: "O'Connor, Don" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Malcolm Betts" <[email-masked]>, <[email-masked]>

Adrian, Malcolm

Malcolm's email and Adrian's reply do not address the key issue of how
the link impairments are measured or estimated. It is up to ITU SG 15 Q6
to determine how this should be accomplished such that wavelength
routing and assignment with optical impairments produces a satisfactory
result for service providers. ITU SG 15 has responsibility for the
optical channel data plane not CCAMP.=20

ITU SG 15 Q6 needs to specify what information the Path Computation
Elements requires to adequately perform the computation, and how it is
measured or acquired including the role of ROADM /OXC. After ITU SG 15
Q6 specifies these details (note that it may be necessary for ITU SG 15
to generate one or more new standards or standard amendments), then
CCAMP can specify what protocols to use and how to encode the
information.

With respect to the liaison, Adrian indicated below,

" I'm open to suggestions of text."

I proposed an updated version of the liaison yesterday. I suggest that
we either use this version or somebody propose an update to what I
proposed

Regards

Don

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]=20
Sent: Wednesday, March 11, 2009 9:22 AM
To: Malcolm Betts; O'Connor, Don; [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Thanks Malcolm.
Helpful.

> Looking at the comments from Don and Dan I think we should take
> a step back and think about the requirements that the protocol
> extensions are intended to address

Sure

> I think we can all agree that we must be able to report link
> impairments and the encoding we use should accommodate
> the parameters currently defined by Q6 and should be
> extensible to accommodate any parameters that are defined
> at a later date.

That is true.
And that (I was hoping) is the bulk of the work to be done with Q6's
help.

> Now to the more contentious issues:
>
> - How frequently do we expect the impairment parameters to
>   change, is it in the order of mSec, Seconds, minutes, hours,
>   days.  I suggest that once it is beyond seconds the actual
>   frequency becomes a "don't care".

You missed "never".

>From a protocol standpoint there are only three categories:
- never
- within the bounds of a routing protocol to advertise
- too fast for a routing protocol to advertise.

Certainly Q6 can help us identify if the third case applies. (I had
assumed=20
not since current networks use manual configuration.)

> - Does the protocol need to activate/deactivate measurements
>   on an in service link.  If so what types of parameters would
>   need to be specified for these measurements.

I have not heard anyone asking for this (perhaps I am not listening?).
This seems like a whole different kettle of ball-games akin to running=20
before we can walk.

> My assumption is that if we define an extensible method for
> reporting link impairment parameters then we can use the
> same message to report any link impairments independent
> of how they are provided (provisioned, measured at installation
> time, measured in service...).

Right.
Yes, isn't this where we started?
What we need from Q6 is help to understand how to encode each of the=20
parameters, and what the ranges are for each parameter.

> I suggest that we phrase the liaison to get input from Q6
> to help us define the requirements for these last two points.

I'm open to suggesitons of text.

Adrian

Delivery-date: Wed, 11 Mar 2009 21:34:49 +0000
Content-class: urn:content-classes:message
Subject: RE: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]
Date: Wed, 11 Mar 2009 16:33:05 -0500
From: "O'Connor, Don" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Hernandez-Valencia, Enrique (Enrique)" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Giovanni Martinelli" <[email-masked]>, "Malcolm Betts" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A290.F870A807
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Igor, Enrique, all

=20

This is an interesting discussion and interesting opinions, but
ultimately this needs to determined by and standardized in ITU SG 15 Q6
WG who has responsibility for the optical channel data plane. The scope
of CCAMP is control plane protocols not photonic layer data plane
aspects.

=20

Regards

=20

Don

=20

From: Igor Bryskin [mailto:[email-masked]]=20
Sent: Wednesday, March 11, 2009 1:23 PM
To: Hernandez-Valencia, Enrique (Enrique); Adrian Farrel; Giovanni
Martinelli; Malcolm Betts; O'Connor, Don
Cc: [email-masked]
Subject: Re: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]

=20

I agree with Enrique (if, of course, I understood him correctly). We
want to advertise things that help to constrain path computation so that
resulting paths will likely to be satisfactorily from the impairments
point of view. I don't see much value in measurement of optical
impairments on existing paths, other than improving  the quality of
things we  advertise and hence future path computation results.

Igor=20

=20

________________________________

From: "Hernandez-Valencia, Enrique (Enrique)"
<[email-masked]>
To: Adrian Farrel <[email-masked]>; Giovanni Martinelli
<[email-masked]>; Malcolm Betts <[email-masked]>; "O'Connor,
Don" <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 10, 2009 1:31:33 PM
Subject: RE: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]

Adrian,

If one replaces "optical impairments" for "packet impairments" (e.g.,
excessive BER, excessive PLR, excessive delay/delay variation) and
compares that with what CCAMP currently does for PSC technologies, would
that help clarify what CCAMP wants to do for WSON?

It would seem the focus of the CCAMP protocol extension would be on
advertising budgets/objectives not on actual impairment measurements.

Regards,=20
Enrique

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 10, 2009 12:48 PM
To: Giovanni Martinelli; Malcolm Betts; O'Connor, Don
Cc: [email-masked]
Subject: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]

I'm going to try to answer all of the comments about measuring
impairments=20
in one email.

I'm arguing all of this from an abstract point of view. I want to "out"
in=20
advance of the meeting as much of opinion held in CCAMP. I do not
believe it=20
is valuable to go into the meeting expressing what we think may be Q6's=20
view. Instead, we need to say what it is people in CCAMP may want to do.

Then we can get Q6 feedback on whether that is practical and what the=20
concerns are.

So...

The ability to measure optical impairments on an active path is claimed
by=20
several vendors. I am not in a position to judge whether they are
successful=20
or not.

Giovanni reasonably asks "what exactly you mean by *ability to
measure*?"

We are proposing protocol extensions that allow nodes to distribute=20
information about optical impairments. It is not our business to define
from=20
where this information is gathered. We can observe that the information=20
might be configured, might be measured during network provisioning and
held=20
static, might be determined by a node applying some algorithm to
configured=20
on pre-measured information, or might be measured dynamically. So we can

choose between:
- optical impairments can be advertised, but cannot be updated
- optical impairments can be advertised, and can be updated

If we choose the first of these, it seems that we are shutting out what
some=20
people want to be able to do. If we choose the latter, we are not
requiring=20
anyone to update the information they advertise, but we are allowing
this to=20
be done if a node chooses to do so.

To answer Don specifically, I see no proposal in CCAMP about which=20
impairments could be measured or how they would be measured. But, to
turn=20
this point around, I do not believe that CCAMP should say "you must not=20
measure an impairment". As Don says, this is outside our remit.

Malcolm's suggestion doesn't cut it for me.
By saying "We understand that Q6 currently has no requirement to measure

impairments after the transport equipment is deployed" we miss the
point.=20
The point is not what Q6 requires or does not require, but is what CCAMP

requires.

So I wonder what is wrong with the statement (in the context of
describing=20
what CCAMP wants to do) that "There is no requirement to measure=20
impairments."

Don objected specifically to...
>    However, if an implementer chooses to measure impairments
>    on their device, this should not be prohibited, and should be
>    accommodated.

How would it be if we defered the practicality of such measurements to
the=20
ITU? We could then write...

    However, if an implementer chooses to measure impairments
    on their device, and this can be achieved within the mechanisms
    and definitions defined by the ITU-T, then this should not be
    prohibited by the CCAMP protocol mechanisms, and should be
    accommodated within GMPLS.

Cheers,
Adrian=20

=20

------_=_NextPart_001_01C9A290.F870A807
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Arial","sans-serif";
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Igor, Enrique, all<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>This is an interesting discussion and interesting opinions, =
but
ultimately this needs to determined by and standardized in ITU SG 15 Q6 =
WG who
has responsibility for the optical channel data plane. The scope of =
CCAMP is
control plane protocols not photonic layer data plane =
aspects.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Regards<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Don<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Igor =
Bryskin
[mailto:[email-masked]] <br>
<b>Sent:</b> Wednesday, March 11, 2009 1:23 PM<br>
<b>To:</b> Hernandez-Valencia, Enrique (Enrique); Adrian Farrel; =
Giovanni
Martinelli; Malcolm Betts; O'Connor, Don<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: Measuring impairments [Was: Updated Draft Liaiosn to =
Q6/15]<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p class=3DMsoNormal>I agree with Enrique (if, of course, I understood =
him
correctly). We want to advertise things that help to constrain path =
computation
so that resulting paths will likely to be satisfactorily from the =
impairments point
of view. I don't see much value in measurement of optical impairments on
existing paths, other than improving&nbsp; the quality of things =
we&nbsp;
advertise and hence future path computation results.<br>
<br>
Igor <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>

<hr size=3D1 width=3D"100%" align=3Dcenter>

</span></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> &quot;Hernandez-Valencia, Enrique
(Enrique)&quot; &lt;[email-masked]&gt;<br>
<b>To:</b> Adrian Farrel &lt;[email-masked]&gt;; Giovanni =
Martinelli
&lt;[email-masked]&gt;; Malcolm Betts &lt;[email-masked]&gt;;
&quot;O'Connor, Don&quot; &lt;[email-masked]&gt;<br>
<b>Cc:</b> [email-masked]<br>
<b>Sent:</b> Tuesday, March 10, 2009 1:31:33 PM<br>
<b>Subject:</b> RE: Measuring impairments [Was: Updated Draft Liaiosn to =
Q6/15]<br>
</span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><br>
Adrian,<br>
<br>
If one replaces &quot;optical impairments&quot; for &quot;packet
impairments&quot; (e.g.,<br>
excessive BER, excessive PLR, excessive delay/delay variation) and<br>
compares that with what CCAMP currently does for PSC technologies, =
would<br>
that help clarify what CCAMP wants to do for WSON?<br>
<br>
It would seem the focus of the CCAMP protocol extension would be on<br>
advertising budgets/objectives not on actual impairment =
measurements.<br>
<br>
Regards, <br>
Enrique<br>
<br>
-----Original Message-----<br>
From: <a =
href=3D"mailto:[email-masked]">[email-masked]</a>
[mailto:<a =
href=3D"mailto:[email-masked]">[email-masked]</a>]
On<br>
Behalf Of Adrian Farrel<br>
Sent: Tuesday, March 10, 2009 12:48 PM<br>
To: Giovanni Martinelli; Malcolm Betts; O'Connor, Don<br>
Cc: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
Subject: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]<br>
<br>
I'm going to try to answer all of the comments about measuring<br>
impairments <br>
in one email.<br>
<br>
I'm arguing all of this from an abstract point of view. I want to
&quot;out&quot;<br>
in <br>
advance of the meeting as much of opinion held in CCAMP. I do not<br>
believe it <br>
is valuable to go into the meeting expressing what we think may be Q6's =
<br>
view. Instead, we need to say what it is people in CCAMP may want to =
do.<br>
<br>
Then we can get Q6 feedback on whether that is practical and what the =
<br>
concerns are.<br>
<br>
So...<br>
<br>
The ability to measure optical impairments on an active path is =
claimed<br>
by <br>
several vendors. I am not in a position to judge whether they are<br>
successful <br>
or not.<br>
<br>
Giovanni reasonably asks &quot;what exactly you mean by *ability to<br>
measure*?&quot;<br>
<br>
We are proposing protocol extensions that allow nodes to distribute <br>
information about optical impairments. It is not our business to =
define<br>
from <br>
where this information is gathered. We can observe that the information =
<br>
might be configured, might be measured during network provisioning =
and<br>
held <br>
static, might be determined by a node applying some algorithm to<br>
configured <br>
on pre-measured information, or might be measured dynamically. So we =
can<br>
<br>
choose between:<br>
- optical impairments can be advertised, but cannot be updated<br>
- optical impairments can be advertised, and can be updated<br>
<br>
If we choose the first of these, it seems that we are shutting out =
what<br>
some <br>
people want to be able to do. If we choose the latter, we are not<br>
requiring <br>
anyone to update the information they advertise, but we are allowing<br>
this to <br>
be done if a node chooses to do so.<br>
<br>
To answer Don specifically, I see no proposal in CCAMP about which <br>
impairments could be measured or how they would be measured. But, to<br>
turn <br>
this point around, I do not believe that CCAMP should say &quot;you must =
not <br>
measure an impairment&quot;. As Don says, this is outside our remit.<br>
<br>
Malcolm's suggestion doesn't cut it for me.<br>
By saying &quot;We understand that Q6 currently has no requirement to =
measure<br>
<br>
impairments after the transport equipment is deployed&quot; we miss =
the<br>
point. <br>
The point is not what Q6 requires or does not require, but is what =
CCAMP<br>
<br>
requires.<br>
<br>
So I wonder what is wrong with the statement (in the context of<br>
describing <br>
what CCAMP wants to do) that &quot;There is no requirement to measure =
<br>
impairments.&quot;<br>
<br>
Don objected specifically to...<br>
&gt;&nbsp; &nbsp; However, if an implementer chooses to measure =
impairments<br>
&gt;&nbsp; &nbsp; on their device, this should not be prohibited, and =
should be<br>
&gt;&nbsp; &nbsp; accommodated.<br>
<br>
How would it be if we defered the practicality of such measurements =
to<br>
the <br>
ITU? We could then write...<br>
<br>
&nbsp; &nbsp; However, if an implementer chooses to measure =
impairments<br>
&nbsp; &nbsp; on their device, and this can be achieved within the =
mechanisms<br>
&nbsp; &nbsp; and definitions defined by the ITU-T, then this should not =
be<br>
&nbsp; &nbsp; prohibited by the CCAMP protocol mechanisms, and should =
be<br>
&nbsp; &nbsp; accommodated within GMPLS.<br>
<br>
Cheers,<br>
Adrian <br>
<br>
<br>
<o:p></o:p></span></p>

</div>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9A290.F870A807--

Envelope-to: [email-masked]
Delivery-date: Wed, 11 Mar 2009 18:25:01 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236795806; bh=Pln2TDL24PqgQhzdCOsbrD1EVqZ7GkqK++Eye4/z77o=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=xeFzegWE9u9EswRjZWoKi7irfaemjRIFW19uacHEwlGj0TzAazl6FJUuAcQbEdbJM6QFAOmGWDFo5XxVb1tnvUpv0O9Jd7geG/G0GSbihGdzwabRd7mHpTpaD3Q7wld7c6H+p9V3pXOftvQOrZpQCGN8EDqSi6Mi85aoy0Uay+M=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=wHtXY8l2Nd+mLcVR2F+BWm4+ifsxPRnahlC2lDPr7ZGtZDiV0w8pnwKCq4XQQTgcWSMWnPkvxPdg7x08aF0i+YJWhNXL3dO1TrmHDilipQEnmNHmZjThUudz/WIT93boIzC+SHOqnj03UNA6rIc9YCTq4ZdLuXClLvGD5xRiDs4=;
Message-ID: <[email-masked]>
Date: Wed, 11 Mar 2009 11:23:26 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]
To: "Hernandez-Valencia, Enrique \(Enrique\)" <[email-masked]>, Adrian Farrel <[email-masked]>, Giovanni Martinelli <[email-masked]>, Malcolm Betts <[email-masked]>, "O'Connor, Don" <[email-masked]>
Cc: [email-masked]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1012946335-1236795806=:34658"

--0-1012946335-1236795806=:34658
Content-Type: text/plain; charset=us-ascii

I agree with Enrique (if, of course, I understood him correctly). We want to advertise things that help to constrain path computation so that resulting paths will likely to be satisfactorily from the impairments point of view. I don't see much value in measurement of optical impairments on existing paths, other than improving  the quality of things we  advertise and hence future path computation results.

Igor

________________________________
From: "Hernandez-Valencia, Enrique (Enrique)" <[email-masked]>
To: Adrian Farrel <[email-masked]>; Giovanni Martinelli <[email-masked]>; Malcolm Betts <[email-masked]>; "O'Connor, Don" <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 10, 2009 1:31:33 PM
Subject: RE: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]

Adrian,

If one replaces "optical impairments" for "packet impairments" (e.g.,
excessive BER, excessive PLR, excessive delay/delay variation) and
compares that with what CCAMP currently does for PSC technologies, would
that help clarify what CCAMP wants to do for WSON?

It would seem the focus of the CCAMP protocol extension would be on
advertising budgets/objectives not on actual impairment measurements.

Regards, 
Enrique

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 10, 2009 12:48 PM
To: Giovanni Martinelli; Malcolm Betts; O'Connor, Don
Cc: [email-masked]
Subject: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]

I'm going to try to answer all of the comments about measuring
impairments 
in one email.

I'm arguing all of this from an abstract point of view. I want to "out"
in 
advance of the meeting as much of opinion held in CCAMP. I do not
believe it 
is valuable to go into the meeting expressing what we think may be Q6's 
view. Instead, we need to say what it is people in CCAMP may want to do.

Then we can get Q6 feedback on whether that is practical and what the 
concerns are.

So...

The ability to measure optical impairments on an active path is claimed
by 
several vendors. I am not in a position to judge whether they are
successful 
or not.

Giovanni reasonably asks "what exactly you mean by *ability to
measure*?"

We are proposing protocol extensions that allow nodes to distribute 
information about optical impairments. It is not our business to define
from 
where this information is gathered. We can observe that the information 
might be configured, might be measured during network provisioning and
held 
static, might be determined by a node applying some algorithm to
configured 
on pre-measured information, or might be measured dynamically. So we can

choose between:
- optical impairments can be advertised, but cannot be updated
- optical impairments can be advertised, and can be updated

If we choose the first of these, it seems that we are shutting out what
some 
people want to be able to do. If we choose the latter, we are not
requiring 
anyone to update the information they advertise, but we are allowing
this to 
be done if a node chooses to do so.

To answer Don specifically, I see no proposal in CCAMP about which 
impairments could be measured or how they would be measured. But, to
turn 
this point around, I do not believe that CCAMP should say "you must not 
measure an impairment". As Don says, this is outside our remit.

Malcolm's suggestion doesn't cut it for me.
By saying "We understand that Q6 currently has no requirement to measure

impairments after the transport equipment is deployed" we miss the
point. 
The point is not what Q6 requires or does not require, but is what CCAMP

requires.

So I wonder what is wrong with the statement (in the context of
describing 
what CCAMP wants to do) that "There is no requirement to measure 
impairments."

Don objected specifically to...
>    However, if an implementer chooses to measure impairments
>    on their device, this should not be prohibited, and should be
>    accommodated.

How would it be if we defered the practicality of such measurements to
the 
ITU? We could then write...

    However, if an implementer chooses to measure impairments
    on their device, and this can be achieved within the mechanisms
    and definitions defined by the ITU-T, then this should not be
    prohibited by the CCAMP protocol mechanisms, and should be
    accommodated within GMPLS.

Cheers,
Adrian 

      
--0-1012946335-1236795806=:34658
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>I agree with Enrique (if, of course, I understood him correctly). We want to advertise things that help to constrain path computation so that resulting paths will likely to be satisfactorily from the impairments point of view. I don't see much value in measurement of optical impairments on existing paths, other than improving&nbsp; the quality of things we&nbsp; advertise and hence future path computation results.<br><br>Igor <br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> "Hernandez-Valencia, Enrique (Enrique)" &lt;[email-masked]&gt;<br><b><span style="font-weight:
 bold;">To:</span></b> Adrian Farrel &lt;[email-masked]&gt;; Giovanni Martinelli &lt;[email-masked]&gt;; Malcolm Betts &lt;[email-masked]&gt;; "O'Connor, Don" &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">Cc:</span></b> [email-masked]<br><b><span style="font-weight: bold;">Sent:</span></b> Tuesday, March 10, 2009 1:31:33 PM<br><b><span style="font-weight: bold;">Subject:</span></b> RE: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]<br></font><br>
Adrian,<br><br>If one replaces "optical impairments" for "packet impairments" (e.g.,<br>excessive BER, excessive PLR, excessive delay/delay variation) and<br>compares that with what CCAMP currently does for PSC technologies, would<br>that help clarify what CCAMP wants to do for WSON?<br><br>It would seem the focus of the CCAMP protocol extension would be on<br>advertising budgets/objectives not on actual impairment measurements.<br><br>Regards, <br>Enrique<br><br>-----Original Message-----<br>From: <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a> [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] On<br>Behalf Of Adrian Farrel<br>Sent: Tuesday, March 10, 2009 12:48 PM<br>To: Giovanni Martinelli; Malcolm Betts; O'Connor, Don<br>Cc: <a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a><br>Subject: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]<br><br>I'm going to try to answer all of the comments about measuring<br>impairments <br>in one email.<br><br>I'm arguing all of this from an abstract point of view. I want to "out"<br>in <br>advance of the meeting as much of opinion held in CCAMP. I do not<br>believe it <br>is valuable to go into the meeting expressing what we think may be Q6's <br>view. Instead, we need to say what it is people in CCAMP may want to do.<br><br>Then we can get Q6 feedback on whether that is practical and what the <br>concerns are.<br><br>So...<br><br>The ability to measure optical impairments on an active path is claimed<br>by <br>several vendors. I am not in a position to judge whether they are<br>successful <br>or not.<br><br>Giovanni reasonably asks "what exactly you mean by *ability to<br>measure*?"<br><br>We are proposing protocol
 extensions that allow nodes to distribute <br>information about optical impairments. It is not our business to define<br>from <br>where this information is gathered. We can observe that the information <br>might be configured, might be measured during network provisioning and<br>held <br>static, might be determined by a node applying some algorithm to<br>configured <br>on pre-measured information, or might be measured dynamically. So we can<br><br>choose between:<br>- optical impairments can be advertised, but cannot be updated<br>- optical impairments can be advertised, and can be updated<br><br>If we choose the first of these, it seems that we are shutting out what<br>some <br>people want to be able to do. If we choose the latter, we are not<br>requiring <br>anyone to update the information they advertise, but we are allowing<br>this to <br>be done if a node chooses to do so.<br><br>To answer Don specifically, I see no proposal in CCAMP about which
 <br>impairments could be measured or how they would be measured. But, to<br>turn <br>this point around, I do not believe that CCAMP should say "you must not <br>measure an impairment". As Don says, this is outside our remit.<br><br> Malcolm's suggestion doesn't cut it for me.<br>By saying "We understand that Q6 currently has no requirement to measure<br><br>impairments after the transport equipment is deployed" we miss the<br>point. <br>The point is not what Q6 requires or does not require, but is what CCAMP<br><br>requires.<br><br>So I wonder what is wrong with the statement (in the context of<br>describing <br>what CCAMP wants to do) that "There is no requirement to measure <br>impairments."<br><br>Don objected specifically to...<br>&gt;&nbsp; &nbsp; However, if an implementer chooses to measure impairments<br>&gt;&nbsp; &nbsp; on their device, this should not be prohibited, and should be<br>&gt;&nbsp; &nbsp; accommodated.<br><br>How would it be if we
 defered the practicality of such measurements to<br>the <br>ITU? We could then write...<br><br>&nbsp; &nbsp; However, if an implementer chooses to measure impairments<br>&nbsp; &nbsp; on their device, and this can be achieved within the mechanisms<br>&nbsp; &nbsp; and definitions defined by the ITU-T, then this should not be<br>&nbsp; &nbsp; prohibited by the CCAMP protocol mechanisms, and should be<br>&nbsp; &nbsp; accommodated within GMPLS.<br><br>Cheers,<br>Adrian <br><br><br><br></div></div></div><br>

      </body></html>
--0-1012946335-1236795806=:34658--

Delivery-date: Wed, 11 Mar 2009 14:23:20 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Malcolm Betts" <[email-masked]>, "O'Connor, Don" <[email-masked]>, <[email-masked]>
Subject: Re: Re-Updated Draft Liaison to Q6/15
Date: Wed, 11 Mar 2009 14:21:31 -0000

Thanks Malcolm.
Helpful.

> Looking at the comments from Don and Dan I think we should take
> a step back and think about the requirements that the protocol
> extensions are intended to address

Sure

> I think we can all agree that we must be able to report link
> impairments and the encoding we use should accommodate
> the parameters currently defined by Q6 and should be
> extensible to accommodate any parameters that are defined
> at a later date.

That is true.
And that (I was hoping) is the bulk of the work to be done with Q6's help.

> Now to the more contentious issues:
>
> - How frequently do we expect the impairment parameters to
>   change, is it in the order of mSec, Seconds, minutes, hours,
>   days.  I suggest that once it is beyond seconds the actual
>   frequency becomes a "don't care".

You missed "never".

>From a protocol standpoint there are only three categories:
- never
- within the bounds of a routing protocol to advertise
- too fast for a routing protocol to advertise.

Certainly Q6 can help us identify if the third case applies. (I had assumed 
not since current networks use manual configuration.)

> - Does the protocol need to activate/deactivate measurements
>   on an in service link.  If so what types of parameters would
>   need to be specified for these measurements.

I have not heard anyone asking for this (perhaps I am not listening?).
This seems like a whole different kettle of ball-games akin to running 
before we can walk.

> My assumption is that if we define an extensible method for
> reporting link impairment parameters then we can use the
> same message to report any link impairments independent
> of how they are provided (provisioned, measured at installation
> time, measured in service...).

Right.
Yes, isn't this where we started?
What we need from Q6 is help to understand how to encode each of the 
parameters, and what the ranges are for each parameter.

> I suggest that we phrase the liaison to get input from Q6
> to help us define the requirements for these last two points.

I'm open to suggesitons of text.

Adrian

Delivery-date: Wed, 11 Mar 2009 12:52:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Wed, 11 Mar 2009 08:49:16 -0400
From: "Malcolm Betts" <[email-masked]>
To: "O'Connor, Don" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Adrian, all

Looking at the comments from Don and Dan I think we should take a step
back and think about the requirements that the protocol extensions are
intended to address:

I think we can all agree that we must be able to report link impairments
and the encoding we use should accommodate the parameters currently
defined by Q6 and should be extensible to accommodate any parameters
that are defined at a later date.

Now to the more contentious issues:

- How frequently do we expect the impairment parameters to change, is it
in the order of mSec, Seconds, minutes, hours, days.  I suggest that
once it is beyond seconds the actual frequency becomes a "don't care".

- Does the protocol need to activate/deactivate measurements on an in
service link.  If so what types of parameters would need to be specified
for these measurements.

My assumption is that if we define an extensible method for reporting
link impairment parameters then we can use the same message to report
any link impairments independent of how they are provided (provisioned,
measured at installation time, measured in service...).

I suggest that we phrase the liaison to get input from Q6 to help us
define the requirements for these last two points.=20

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: O'Connor, Don [mailto:[email-masked]]=20
Sent: Tuesday, March 10, 2009 5:45 PM
To: Adrian Farrel; Betts, Malcolm (CAR:X632); [email-masked]
Subject: RE: Re-Updated Draft Liaison to Q6/15

Adrian, all

I agreed with

" we should phrase the liaison to stimulate a discussion with the
experts in Q6 on the value of making measurements on active optical
paths"

In returning to your draft liaison I do not agree with

" In focusing on the third of these categories, CCAMP intends to base
its work on G.680 and related recommendations with the following
understanding:"

We have not yet reached this level of agreement in CCAMP as no ID
pertinent to WSON with optical impairments has progressed beyond
individual contribution

I do not agree with the following interpretation of G.680

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

I think the following sentence is misleading in the context alternative
3) "impairment estimation"

" There is no requirement to measure impairments."

Even for estimation, it may be necessary for the ROADM to make some
measurements. It will be necessary for ITU SG 15 Q6 to define the
details of any estimation scheme including any associated measurements.=20

So my proposal is to truncate all the text after the definition of what
CCAMP currently believes are the four alternatives. But add some
additional text on discussion of WSON with optical impairments with ITU
SG 15 Q6. I suggest the following

" 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. We also believe that this gives rise to four
distinct deployment scenarios:

1. No concern for impairments or lambda continuity
   because there is sufficient margin in all impairments.
   (Original GMPLS)
2. No concern for impairments (again because there is
    sufficient margin), but lambda continuity is important.
   (The RWA problem)
3. Networks in which it is necessary to consider impairments,
   but there is sufficient margin such that approximate
   impairment estimation (using "simple" computation of the
   accumulation) could be used and still have a high
   probability that the optical path would be viable and would
   not perturb any existing paths.
4. Networks in which detailed impairment validation is
   necessary to perform a full computation of the accumulation
   of impairments including the impact on existing paths.

It has also been suggested in the course of our discussions that G.680
can possibly to applied to address some of the requirements of 3) and
4). We would like to initiate discussions with Q6 on routing and
wavelength assignment with optical impairments and the associated
control plane support. We would like to apply existing ITU standards
such as G.680, but also understand that if any new standard ROADM
functionality is needed that such standardization would fall within the
scope of ITU SG 15 Q6"

For reference, some early work on impairment-aware GMPLS is listed
below. This work is not yet adopted as CCAMP work.

"A Framework for the Control of Wavelength Switched Optical Networks
(WSON) with Impairments"
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairmen
ts-02.txt

"Information Model for Impaired Optical Path Validation"
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info
-00.txt

Looking forward to a profitable meeting, Deborah Brungard and Adrian
Farrel CCAMP Working Group Co-Chairs"

Regards

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 10, 2009 3:07 PM
To: Malcolm Betts; [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Hi Malcolm,

> Adrian, I don't like either paragraph....

Consensus is a slippery beast.

> The point I was attempting to raise, and I think Enrique made a=20
> similar point, is that we should phrase the liaison to stimulate a=20
> discussion with the experts in Q6 on the value of making measurements=20
> on active optical paths.

I don't object to this discussion, or any other discussion.

Maybe we need to separate measuring impairments on the idle components
of an OLS while other components may or may not be active (which is what
I thought people wanted to do), and measuring impairments on active
components (which I had not heard people suggesting they would do).

A

Delivery-date: Wed, 11 Mar 2009 00:20:16 +0000
Date: Wed, 11 Mar 2009 08:18:06 +0800
From: Dan Li <[email-masked]>
Subject: Re: Re-Updated Draft Liaison to Q6/15
To: Adrian Farrel <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_ipl5yKDiD1C0S1KtCsOn0g)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Adrian, all,

I think we should not state where and how to get these link impairments, we may only say our GMPLS protocols can support to carry these link impairments which has been defined (or may be defined in the near future) in ITU-T standards.

To stimulate the discuss in Q6, we can ask for their suggestions on the list of link impairments, and would like to know how ITU-T gets it.

Regards,

Dan

  ----- Original Message ----- 
  From: Adrian Farrel 
  To: [email-masked] 
  Sent: Wednesday, March 11, 2009 3:16 AM
  Subject: Re: Re-Updated Draft Liaison to Q6/15

  Does anyone else have an opinion on the difference between these two 
  paragraphs...

  > However, if a service provider chooses to measure optical link
  > impairments on an out of service basis and this can be achieved
  > within ITU-T standards , then this should not be prohibited by
  > the CCAMP protocol mechanisms, and the communication of the
  > information collected should be accommodated within GMPLS"

  > However, if an implementer chooses to measure impairments
  > on their device, and this can be achieved within the mechanisms
  > and definitions defined by the ITU-T, then this should not be
  > prohibited by the CCAMP protocol mechanisms, and the
  > communication of the information collected should be
  > accommodated within GMPLS.

  There are several differences:

  - state impairments are "optical impairments"
  - limit impairments to "link impairments"
  - restrict discussion to "out of service measurements"
  - refer to "ITU-T standards" rather than "mechanisms
    and definitions defined by the ITU-T"

  Thanks,
  Adrian 

--Boundary_(ID_ipl5yKDiD1C0S1KtCsOn0g)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.3492" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=&#23435;&#20307; size=2>Adrian, all,</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=&#23435;&#20307; size=2>I think we should not state where and how to get these 
link impairments, we may only say our GMPLS protocols can support to carry these 
link impairments which has been defined (or may be defined in the near 
future)&nbsp;in ITU-T standards.</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=&#23435;&#20307; size=2>To stimulate the discuss in Q6, we can ask for their 
suggestions on the list of link impairments, and would like to know how ITU-T 
gets it.</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Regards,</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Dan</FONT></DIV>
<DIV>
<P></P>
<P></P><FONT face=Arial color=gray size=1><BR></FONT></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 9pt &#23435;&#20307;">----- Original Message ----- </DIV>
  <DIV style="BACKGROUND: #e4e4e4; FONT: 9pt &#23435;&#20307;; font-color: black"><B>From:</B> 
  <A title=[email-masked] href="mailto:[email-masked]">Adrian 
  Farrel</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Sent:</B> Wednesday, March 11, 2009 3:16 AM</DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Subject:</B> Re: Re-Updated Draft Liaison to 
  Q6/15</DIV>
  <DIV><BR></DIV>Does anyone else have an opinion on the difference between 
  these two <BR>paragraphs...<BR><BR>&gt; However, if a service provider chooses 
  to measure optical link<BR>&gt; impairments on an out of service basis and 
  this can be achieved<BR>&gt; within ITU-T standards , then this should not be 
  prohibited by<BR>&gt; the CCAMP protocol mechanisms, and the communication of 
  the<BR>&gt; information collected should be accommodated within 
  GMPLS"<BR><BR>&gt; However, if an implementer chooses to measure 
  impairments<BR>&gt; on their device, and this can be achieved within the 
  mechanisms<BR>&gt; and definitions defined by the ITU-T, then this should not 
  be<BR>&gt; prohibited by the CCAMP protocol mechanisms, and the<BR>&gt; 
  communication of the information collected should be<BR>&gt; accommodated 
  within GMPLS.<BR><BR>There are several differences:<BR><BR>- state impairments 
  are "optical impairments"<BR>- limit impairments to "link impairments"<BR>- 
  restrict discussion to "out of service measurements"<BR>- refer to "ITU-T 
  standards" rather than "mechanisms<BR>&nbsp; and definitions defined by the 
  ITU-T"<BR><BR>Thanks,<BR>Adrian <BR><BR><BR></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_ipl5yKDiD1C0S1KtCsOn0g)--

Delivery-date: Tue, 10 Mar 2009 22:11:28 +0000
Date: Tue, 10 Mar 2009 23:10:23 +0100
From: Giovanni Martinelli <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Hi,

Adrian Farrel wrote:
> Does anyone else have an opinion on the difference between these two 
> paragraphs...
>
>> However, if a service provider chooses to measure optical link
>> impairments on an out of service basis and this can be achieved
>> within ITU-T standards , then this should not be prohibited by
>> the CCAMP protocol mechanisms, and the communication of the
>> information collected should be accommodated within GMPLS"
>
>> However, if an implementer chooses to measure impairments
>> on their device, and this can be achieved within the mechanisms
>> and definitions defined by the ITU-T, then this should not be
>> prohibited by the CCAMP protocol mechanisms, and the
>> communication of the information collected should be
>> accommodated within GMPLS.
>
> There are several differences:
>
> - state impairments are "optical impairments"
> - limit impairments to "link impairments"
> - restrict discussion to "out of service measurements"  
I lean toward the second par.  What is possible or not in term of 
measurement will be to ITU to define.

Cheers
G

> - refer to "ITU-T standards" rather than "mechanisms
>  and definitions defined by the ITU-T"
>
> Thanks,
> Adrian
>

Delivery-date: Tue, 10 Mar 2009 21:46:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Tue, 10 Mar 2009 16:44:41 -0500
From: "O'Connor, Don" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Malcolm Betts" <[email-masked]>, <[email-masked]>

Adrian, all

I agreed with

" we should phrase the liaison to stimulate a discussion with the
experts in Q6 on the value of making
measurements on active optical paths"

In returning to your draft liaison I do not agree with

" In focusing on the third of these categories, CCAMP intends to base
its work on G.680 and related recommendations with the following
understanding:"

We have not yet reached this level of agreement in CCAMP as no ID
pertinent to WSON with optical impairments has progressed beyond
individual contribution

I do not agree with the following interpretation of G.680

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

I think the following sentence is misleading in the context alternative
3) "impairment estimation"

" There is no requirement to measure impairments."

Even for estimation, it may be necessary for the ROADM to make some
measurements. It will be necessary for ITU SG 15 Q6 to define the
details of any estimation scheme including any associated measurements.=20

So my proposal is to truncate all the text after the definition of what
CCAMP currently believes are the four alternatives. But add some
additional text on discussion of WSON with optical impairments with ITU
SG 15 Q6. I suggest the following

" 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. We also believe that this gives rise to four
distinct deployment scenarios:

1. No concern for impairments or lambda continuity
   because there is sufficient margin in all impairments.
   (Original GMPLS)
2. No concern for impairments (again because there is
    sufficient margin), but lambda continuity is important.
   (The RWA problem)
3. Networks in which it is necessary to consider impairments,
   but there is sufficient margin such that approximate
   impairment estimation (using "simple" computation of the
   accumulation) could be used and still have a high
   probability that the optical path would be viable and would
   not perturb any existing paths.
4. Networks in which detailed impairment validation is
   necessary to perform a full computation of the accumulation
   of impairments including the impact on existing paths.

It has also been suggested in the course of our discussions that G.680
can possibly to applied to address some of the requirements of 3) and
4). We would like to initiate discussions with Q6 on routing and
wavelength assignment with optical impairments and the associated
control plane support. We would like to apply existing ITU standards
such as G.680, but also understand that if any new standard ROADM
functionality is needed that such standardization would fall within the
scope of ITU SG 15 Q6"

For reference, some early work on impairment-aware GMPLS is listed
below. This work is not yet adopted as CCAMP work.

"A Framework for the Control of Wavelength Switched Optical Networks
(WSON) with Impairments"
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairmen
ts-02.txt

"Information Model for Impaired Optical Path Validation"
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info
-00.txt

Looking forward to a profitable meeting, Deborah Brungard and Adrian
Farrel CCAMP Working Group Co-Chairs"

Regards

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 10, 2009 3:07 PM
To: Malcolm Betts; [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Hi Malcolm,

> Adrian, I don't like either paragraph....

Consensus is a slippery beast.

> The point I was attempting to raise, and I think Enrique made
> a similar point, is that we should phrase the liaison to stimulate
> a discussion with the experts in Q6 on the value of making
> measurements on active optical paths.

I don't object to this discussion, or any other discussion.

Maybe we need to separate measuring impairments on the idle components
of an=20
OLS while other components may or may not be active (which is what I
thought=20
people wanted to do), and measuring impairments on active components
(which=20
I had not heard people suggesting they would do).

A

Delivery-date: Tue, 10 Mar 2009 21:14:22 +0000
Content-class: urn:content-classes:message
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Tue, 10 Mar 2009 17:13:17 -0400
From: "Malcolm Betts" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Adrian, apologies for the hasty reply - distracted on conference calls
;(
The current wording implies that ccamp is going to do this, perhaps you
could reword to get the discussion around what, in the opinion of Q6, is
it worth doing in terms of measurements on an in service network.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]=20
Sent: Tuesday, March 10, 2009 4:07 PM
To: Betts, Malcolm (CAR:X632); [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Hi Malcolm,

> Adrian, I don't like either paragraph....

Consensus is a slippery beast.

> The point I was attempting to raise, and I think Enrique made a=20
> similar point, is that we should phrase the liaison to stimulate a=20
> discussion with the experts in Q6 on the value of making measurements=20
> on active optical paths.

I don't object to this discussion, or any other discussion.

Maybe we need to separate measuring impairments on the idle components
of an OLS while other components may or may not be active (which is what
I thought people wanted to do), and measuring impairments on active
components (which I had not heard people suggesting they would do).

A

Delivery-date: Tue, 10 Mar 2009 20:43:41 +0000
Date: Tue, 10 Mar 2009 13:41:43 -0800
Subject: Re: Re-re-Updated Draft Liaiosn to Q6/15
From: Kireeti Kompella <[email-masked]>
To: Adrian Farrel <[email-masked]>, <[email-masked]>

Hi Adrian,

On Tue Mar/10/09 11:16 , Adrian Farrel wrote:

> Does anyone else have an opinion on the difference between these two
> paragraphs...

>> However, if a service provider chooses to measure optical link
>> impairments on an out of service basis and this can be achieved
>> within ITU-T standards , then this should not be prohibited by
>> the CCAMP protocol mechanisms, and the communication of the
>> information collected should be accommodated within GMPLS"
> 
>> However, if an implementer chooses to measure impairments
>> on their device, and this can be achieved within the mechanisms
>> and definitions defined by the ITU-T, then this should not be
>> prohibited by the CCAMP protocol mechanisms, and the
>> communication of the information collected should be
>> accommodated within GMPLS.

I prefer to leave in "optical link impairments", to stimulate discussion by
Q6; I don't like "definitions defined"; and I don't see why CCAMP *protocol
mechanisms* should be constrained, let alone prohibited.  The key is that
CCAMP doesn't define what or how to measure (especially optical stuff), just
how to carry.

So, my preference is for para 1.

> There are several differences:
> 
> - state impairments are "optical impairments"
> - limit impairments to "link impairments"

While I'd like to see this broader, what we deal with primarily in GMPLS is
link parameters.  So I'm okay with this (as a start).

> - restrict discussion to "out of service measurements"

Not sure why.  If changes are allowed to para 1, then I'd suggest remove "on
an out of service basis".

> - refer to "ITU-T standards" rather than "mechanisms
>   and definitions defined by the ITU-T"

Referring to ITU-T standards emphasizes two things: (a) the ITU-T must be
the one to define (should they so choose) optical impairments; (b) they
should consider doing so, to accommodate service providers who want this.

> Thanks,
> Adrian 

Kireeti.

Delivery-date: Tue, 10 Mar 2009 20:07:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Malcolm Betts" <[email-masked]>, <[email-masked]>
Subject: Re: Re-Updated Draft Liaison to Q6/15
Date: Tue, 10 Mar 2009 20:06:47 -0000

Hi Malcolm,

> Adrian, I don't like either paragraph....

Consensus is a slippery beast.

> The point I was attempting to raise, and I think Enrique made
> a similar point, is that we should phrase the liaison to stimulate
> a discussion with the experts in Q6 on the value of making
> measurements on active optical paths.

I don't object to this discussion, or any other discussion.

Maybe we need to separate measuring impairments on the idle components of an 
OLS while other components may or may not be active (which is what I thought 
people wanted to do), and measuring impairments on active components (which 
I had not heard people suggesting they would do).

A

Delivery-date: Tue, 10 Mar 2009 19:44:49 +0000
Date: Tue, 10 Mar 2009 14:44:10 -0500
From: Young Lee <[email-masked]>
Subject: RE: Re-Updated Draft Liaison to Q6/15
To: 'Adrian Farrel' <[email-masked]>, [email-masked]

Hi all,

This looks good to me. Thanks.

Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Tuesday, March 10, 2009 12:34 PM
To: [email-masked]
Subject: Re-Updated Draft Liaison to Q6/15

Continuing to try to reach some sort of grudging consensus...

===

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 GMPLS 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-lambda-labe
ls-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-framework-01.t
xt

"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
   because there is sufficent margin in all impairments.
   (Original GMPLS)
2. No concern for impairments (again because there is
    sufficient margin), but lambda continuity is important.
   (The RWA problem)
3. Networks in which it is necessary to consider impairments,
   but there is sufficient margin such that approximate
   impairment estimation (using "simple" computation of the
   accumulation) could be used and still have a high
   probability that the optical path would be viable and would
   not perturb any existing paths.
4. Networks in which detailed impairment validation is
   necessary to perform a full computation of the accumulation
   of impairments including the impact on existing paths.

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 the definitions of optical impairments,
   optical parameters, and insights into their use
- 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, and this can be achieved within the mechanisms
   and definitions defined by the ITU-T, then this should not be
   prohibited by the CCAMP protocol mechanisms, and the
   communication of the information collected should be
   accommodated within GMPLS.

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.
   That is, that CCAMP is looking for the rules by which the end-to-
   end impairments of a path may be determined from a knowldedge
   of paramters of the path and impairments on the path segments.
 - 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-impairments-0
2.txt

"Information Model for Impaired Optical Path Validation"
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info-00.
txt

Looking forward to a profitable meeting,
Deborah Brungard and Adrian Farrel
CCAMP Working Group Co-Chairs 

Delivery-date: Tue, 10 Mar 2009 19:38:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Tue, 10 Mar 2009 14:37:46 -0500
From: "Varma, Eve L \(Eve\)" <[email-masked]>
To: "Malcolm Betts" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Adrian, =20

I concur with Malcolm's and Enrique's points.=20

Best regards,
Eve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Malcolm Betts
Sent: Tuesday, March 10, 2009 3:34 PM
To: Adrian Farrel; [email-masked]
Subject: RE: Re-Updated Draft Liaison to Q6/15

Adrian, I don't like either paragraph....

The point I was attempting to raise, and I think Enrique made a similar
point, is that we should phrase the liaison to stimulate a discussion
with the experts in Q6 on the value of making measurements on active
optical paths.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 10, 2009 3:17 PM
To: [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Does anyone else have an opinion on the difference between these two
paragraphs...

> However, if a service provider chooses to measure optical link=20
> impairments on an out of service basis and this can be achieved within

> ITU-T standards , then this should not be prohibited by the CCAMP=20
> protocol mechanisms, and the communication of the information=20
> collected should be accommodated within GMPLS"

> However, if an implementer chooses to measure impairments on their=20
> device, and this can be achieved within the mechanisms and definitions

> defined by the ITU-T, then this should not be prohibited by the CCAMP=20
> protocol mechanisms, and the communication of the information=20
> collected should be accommodated within GMPLS.

There are several differences:

- state impairments are "optical impairments"
- limit impairments to "link impairments"
- restrict discussion to "out of service measurements"
- refer to "ITU-T standards" rather than "mechanisms
  and definitions defined by the ITU-T"

Thanks,
Adrian=20

Delivery-date: Tue, 10 Mar 2009 19:34:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Tue, 10 Mar 2009 15:33:52 -0400
From: "Malcolm Betts" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Adrian, I don't like either paragraph....

The point I was attempting to raise, and I think Enrique made a similar
point, is that we should phrase the liaison to stimulate a discussion
with the experts in Q6 on the value of making measurements on active
optical paths.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 10, 2009 3:17 PM
To: [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Does anyone else have an opinion on the difference between these two
paragraphs...

> However, if a service provider chooses to measure optical link=20
> impairments on an out of service basis and this can be achieved within

> ITU-T standards , then this should not be prohibited by the CCAMP=20
> protocol mechanisms, and the communication of the information=20
> collected should be accommodated within GMPLS"

> However, if an implementer chooses to measure impairments on their=20
> device, and this can be achieved within the mechanisms and definitions

> defined by the ITU-T, then this should not be prohibited by the CCAMP=20
> protocol mechanisms, and the communication of the information=20
> collected should be accommodated within GMPLS.

There are several differences:

- state impairments are "optical impairments"
- limit impairments to "link impairments"
- restrict discussion to "out of service measurements"
- refer to "ITU-T standards" rather than "mechanisms
  and definitions defined by the ITU-T"

Thanks,
Adrian=20

Delivery-date: Tue, 10 Mar 2009 19:23:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Tue, 10 Mar 2009 14:22:33 -0500
From: "Varma, Eve L \(Eve\)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Another difference is the first speaks of service provider choice, and
the second refers to implementer choice.=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 10, 2009 3:17 PM
To: [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Does anyone else have an opinion on the difference between these two
paragraphs...

> However, if a service provider chooses to measure optical link=20
> impairments on an out of service basis and this can be achieved within

> ITU-T standards , then this should not be prohibited by the CCAMP=20
> protocol mechanisms, and the communication of the information=20
> collected should be accommodated within GMPLS"

> However, if an implementer chooses to measure impairments on their=20
> device, and this can be achieved within the mechanisms and definitions

> defined by the ITU-T, then this should not be prohibited by the CCAMP=20
> protocol mechanisms, and the communication of the information=20
> collected should be accommodated within GMPLS.

There are several differences:

- state impairments are "optical impairments"
- limit impairments to "link impairments"
- restrict discussion to "out of service measurements"
- refer to "ITU-T standards" rather than "mechanisms
  and definitions defined by the ITU-T"

Thanks,
Adrian=20

Delivery-date: Tue, 10 Mar 2009 19:18:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: Re-Updated Draft Liaison to Q6/15
Date: Tue, 10 Mar 2009 19:16:53 -0000

Does anyone else have an opinion on the difference between these two 
paragraphs...

> However, if a service provider chooses to measure optical link
> impairments on an out of service basis and this can be achieved
> within ITU-T standards , then this should not be prohibited by
> the CCAMP protocol mechanisms, and the communication of the
> information collected should be accommodated within GMPLS"

> However, if an implementer chooses to measure impairments
> on their device, and this can be achieved within the mechanisms
> and definitions defined by the ITU-T, then this should not be
> prohibited by the CCAMP protocol mechanisms, and the
> communication of the information collected should be
> accommodated within GMPLS.

There are several differences:

- state impairments are "optical impairments"
- limit impairments to "link impairments"
- restrict discussion to "out of service measurements"
- refer to "ITU-T standards" rather than "mechanisms
  and definitions defined by the ITU-T"

Thanks,
Adrian 

Delivery-date: Tue, 10 Mar 2009 18:02:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Tue, 10 Mar 2009 13:01:39 -0500
From: "O'Connor, Don" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>

Adrian=20

It does not look good to me. Please revise the paragraph in question to
the following

"However, if a service provider chooses to measure optical link
impairments on an out of service basis and this can be achieved within
ITU-T standards , then this should not be
prohibited by the CCAMP protocol mechanisms, and the
communication of the information collected should be
accommodated within GMPLS"

There are no ITU standards for in service measurement

Regards

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Bernstein
Sent: Tuesday, March 10, 2009 12:46 PM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Looks good to me!

Greg

Adrian Farrel wrote:
> Continuing to try to reach some sort of grudging consensus...
>
> =3D=3D=3D
>
> Dear Peter,
>
> CCAMP experts are looking forward to our joint meeting with Q6/5 on=20
> March 20th to discuss optical impairments and the control plane=20
> 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=20
> OEOs, ROADMs, and photonic cross-connects (PXCs). In fact, lambda=20
> switching was the technology that led to the development of GMPLS from

> the packet switching MPLS control plane.
>
> The IETF's CCAMP working group is the design authority for all=20
> 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=20
> disregard optical impairments and where the number of regeneration=20
> points is high. In these environments, path computation can be=20
> performed on a reachability graph, and lambda conversion can be=20
> performed as necessary within the network.
>
> As PXCs were introduced into WSONs, it remained the case that optical=20
> impairments could be disregarded by the control plane. Where=20
> necessary, optimal impairment-aware paths could be computed off-line=20
> and supplied to the control plane, leaving the control plane to handle

> establishment of connections and recovery after failure. Failure=20
> recovery scenarios might lead to contention for wavelengths or=20
> suboptimal optical paths, but these could be handled by crankback=20
> within the signaling protocol.
>
> More recent work on WSONs indicates that the proportion of pure=20
> optical devices (ROADMs and PXCs) is increasing. This means that it is

> necessary to compute paths that offer end-to-end lambda continuity.=20
> This problem (called the routing and wavelength assignment (RWA)=20
> 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=20
> this problem it is convenient if there is a common identification=20
> scheme for wavelengths across the whole network (previously,=20
> wavelength identification was a local matter between the nodes at the=20
> ends of each link). To aid with this, the CCAMP working group has=20
> developed
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-
labels-03.txt=20
>
> that provides a protocol-independent encoding for wavelengths in a way

> that is compliant with G.694. Further work on this problem space can=20
> be seen in the following CCAMP documents:
>
> "Framework for GMPLS and PCE Control of Wavelength Switched Optical=20
> Networks (WSON)"
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-
01.txt=20
>
>
> "Routing and Wavelength Assignment Information Model for Wavelength=20
> 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=20
>
>
> CCAMP participants have further identified cases where they believe it

> would be helpful to consider optical impairments during the control=20
> plane operation of a WSON. This gives rise to four distinct deployment

> scenarios:
>
> 1. No concern for impairments or lambda continuity
>   because there is sufficent margin in all impairments.
>   (Original GMPLS)
> 2. No concern for impairments (again because there is
>    sufficient margin), but lambda continuity is important.
>   (The RWA problem)
> 3. Networks in which it is necessary to consider impairments,
>   but there is sufficient margin such that approximate
>   impairment estimation (using "simple" computation of the
>   accumulation) could be used and still have a high
>   probability that the optical path would be viable and would
>   not perturb any existing paths.
> 4. Networks in which detailed impairment validation is
>   necessary to perform a full computation of the accumulation
>   of impairments including the impact on existing paths.
>
>
> In focusing on the third of these categories, CCAMP intends to base=20
> its work on G.680 and related recommendations with the following=20
> understanding:
> - G.680 (et al.) provides the definitions of optical impairments,
>   optical parameters, and insights into their use
> - 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, and this can be achieved within the mechanisms
>   and definitions defined by the ITU-T, then this should not be
>   prohibited by the CCAMP protocol mechanisms, and the
>   communication of the information collected should be
>   accommodated within GMPLS.
>
> With this in mind, CCAMP is looking to Q6/15 to work as a partner in=20
> 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.
>   That is, that CCAMP is looking for the rules by which the end-to-
>   end impairments of a path may be determined from a knowldedge
>   of paramters of the path and impairments on the path segments.
> - Generic encodings and ranges of values for the impairments
>
> For reference, some early work on impairment-aware GMPLS is listed=20
> below. This work is not yet adopted as CCAMP work, but is likely to=20
> form the basis of such work once we have discussed the way forward=20
> with Q6/15.
>
> "A Framework for the Control of Wavelength Switched Optical Networks=20
> (WSON) with Impairments"
>
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairmen
ts-02.txt=20
>
>
> "Information Model for Impaired Optical Path Validation"
>
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info
-00.txt=20
>
>
> Looking forward to a profitable meeting,
> Deborah Brungard and Adrian Farrel
> CCAMP Working Group Co-Chairs
>
>

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

Delivery-date: Tue, 10 Mar 2009 17:46:46 +0000
Date: Tue, 10 Mar 2009 10:45:56 -0700
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Looks good to me!

Greg

Adrian Farrel wrote:
> Continuing to try to reach some sort of grudging consensus...
>
> ===
>
> 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 GMPLS 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-lambda-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-framework-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
>   because there is sufficent margin in all impairments.
>   (Original GMPLS)
> 2. No concern for impairments (again because there is
>    sufficient margin), but lambda continuity is important.
>   (The RWA problem)
> 3. Networks in which it is necessary to consider impairments,
>   but there is sufficient margin such that approximate
>   impairment estimation (using "simple" computation of the
>   accumulation) could be used and still have a high
>   probability that the optical path would be viable and would
>   not perturb any existing paths.
> 4. Networks in which detailed impairment validation is
>   necessary to perform a full computation of the accumulation
>   of impairments including the impact on existing paths.
>
>
> 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 the definitions of optical impairments,
>   optical parameters, and insights into their use
> - 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, and this can be achieved within the mechanisms
>   and definitions defined by the ITU-T, then this should not be
>   prohibited by the CCAMP protocol mechanisms, and the
>   communication of the information collected should be
>   accommodated within GMPLS.
>
> 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.
>   That is, that CCAMP is looking for the rules by which the end-to-
>   end impairments of a path may be determined from a knowldedge
>   of paramters of the path and impairments on the path segments.
> - 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-impairments-02.txt 
>
>
> "Information Model for Impaired Optical Path Validation"
> http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info-00.txt 
>
>
> Looking forward to a profitable meeting,
> Deborah Brungard and Adrian Farrel
> CCAMP Working Group Co-Chairs
>
>

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

Delivery-date: Tue, 10 Mar 2009 17:34:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re-Updated Draft Liaison to Q6/15
Date: Tue, 10 Mar 2009 17:33:52 -0000

Continuing to try to reach some sort of grudging consensus...

===

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 GMPLS 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-lambda-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-framework-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
   because there is sufficent margin in all impairments.
   (Original GMPLS)
2. No concern for impairments (again because there is
    sufficient margin), but lambda continuity is important.
   (The RWA problem)
3. Networks in which it is necessary to consider impairments,
   but there is sufficient margin such that approximate
   impairment estimation (using "simple" computation of the
   accumulation) could be used and still have a high
   probability that the optical path would be viable and would
   not perturb any existing paths.
4. Networks in which detailed impairment validation is
   necessary to perform a full computation of the accumulation
   of impairments including the impact on existing paths.

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 the definitions of optical impairments,
   optical parameters, and insights into their use
- 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, and this can be achieved within the mechanisms
   and definitions defined by the ITU-T, then this should not be
   prohibited by the CCAMP protocol mechanisms, and the
   communication of the information collected should be
   accommodated within GMPLS.

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.
   That is, that CCAMP is looking for the rules by which the end-to-
   end impairments of a path may be determined from a knowldedge
   of paramters of the path and impairments on the path segments.
 - 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-impairments-02.txt

"Information Model for Impaired Optical Path Validation"
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info-00.txt

Looking forward to a profitable meeting,
Deborah Brungard and Adrian Farrel
CCAMP Working Group Co-Chairs 

Delivery-date: Tue, 10 Mar 2009 17:32:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]
Date: Tue, 10 Mar 2009 12:31:33 -0500
From: "Hernandez-Valencia, Enrique \(Enrique\)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Giovanni Martinelli" <[email-masked]>, "Malcolm Betts" <[email-masked]>, "O'Connor, Don" <[email-masked]>
Cc: <[email-masked]>

Adrian,

If one replaces "optical impairments" for "packet impairments" (e.g.,
excessive BER, excessive PLR, excessive delay/delay variation) and
compares that with what CCAMP currently does for PSC technologies, would
that help clarify what CCAMP wants to do for WSON?

It would seem the focus of the CCAMP protocol extension would be on
advertising budgets/objectives not on actual impairment measurements.

Regards,=20
Enrique

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 10, 2009 12:48 PM
To: Giovanni Martinelli; Malcolm Betts; O'Connor, Don
Cc: [email-masked]
Subject: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]

I'm going to try to answer all of the comments about measuring
impairments=20
in one email.

I'm arguing all of this from an abstract point of view. I want to "out"
in=20
advance of the meeting as much of opinion held in CCAMP. I do not
believe it=20
is valuable to go into the meeting expressing what we think may be Q6's=20
view. Instead, we need to say what it is people in CCAMP may want to do.

Then we can get Q6 feedback on whether that is practical and what the=20
concerns are.

So...

The ability to measure optical impairments on an active path is claimed
by=20
several vendors. I am not in a position to judge whether they are
successful=20
or not.

Giovanni reasonably asks "what exactly you mean by *ability to
measure*?"

We are proposing protocol extensions that allow nodes to distribute=20
information about optical impairments. It is not our business to define
from=20
where this information is gathered. We can observe that the information=20
might be configured, might be measured during network provisioning and
held=20
static, might be determined by a node applying some algorithm to
configured=20
on pre-measured information, or might be measured dynamically. So we can

choose between:
- optical impairments can be advertised, but cannot be updated
- optical impairments can be advertised, and can be updated

If we choose the first of these, it seems that we are shutting out what
some=20
people want to be able to do. If we choose the latter, we are not
requiring=20
anyone to update the information they advertise, but we are allowing
this to=20
be done if a node chooses to do so.

To answer Don specifically, I see no proposal in CCAMP about which=20
impairments could be measured or how they would be measured. But, to
turn=20
this point around, I do not believe that CCAMP should say "you must not=20
measure an impairment". As Don says, this is outside our remit.

 Malcolm's suggestion doesn't cut it for me.
By saying "We understand that Q6 currently has no requirement to measure

impairments after the transport equipment is deployed" we miss the
point.=20
The point is not what Q6 requires or does not require, but is what CCAMP

requires.

So I wonder what is wrong with the statement (in the context of
describing=20
what CCAMP wants to do) that "There is no requirement to measure=20
impairments."

Don objected specifically to...
>    However, if an implementer chooses to measure impairments
>    on their device, this should not be prohibited, and should be
>    accommodated.

How would it be if we defered the practicality of such measurements to
the=20
ITU? We could then write...

    However, if an implementer chooses to measure impairments
    on their device, and this can be achieved within the mechanisms
    and definitions defined by the ITU-T, then this should not be
    prohibited by the CCAMP protocol mechanisms, and should be
    accommodated within GMPLS.

Cheers,
Adrian=20

Delivery-date: Tue, 10 Mar 2009 17:21:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Malcolm Betts" <[email-masked]>, "Greg Bernstein" <[email-masked]>
Subject: Lesser comments on Updated Draft Liaiosn to Q6/15
Date: Tue, 10 Mar 2009 17:20:47 -0000

Thanks Malcolm and Greg,

> Deployment scenario 3 "Concern for "basic" impairments" my
> recollection is that we were considering network scenarios in
> which we could allocate sufficient margin so that a "simple"
> computation of the accumulation could be used and still have
> a high probability that the optical path would be viable and
> would not perturb any existing paths.

Thanks. Yes. "Basic" probably conveys that I was struggling for the right 
term!
Greg suggested "Networks in which approximate impairment estimation is 
sufficient", and I will merge this with what you suggested (as in this case 
more may be more!).

> Deployment scenario 4 "Concern for "advanced" impairments"
> again my recollection is that in this scenario a full computation
> of the accumulation of impairments including the impact on
> existing paths is required.  This significantly increases the scope
> of information required and the compute time.

Well, let's not get into the compute time :-)

But you're right, again I was fishing for words, so I will merge what you 
said with what Greg supplied.

> One final concern:
> "With this in mind, CCAMP is looking to Q6/15 to work as a partner in
> establishing:
> - ....
> - the rules by which such impairments are accumulated along a path
>  ...."
>
> This implies that we will standardize an aspect of path computation i.e.
> the method of computing the accumulation of impairments.  If the path
> computation is performed in a single PCE then it is only necessary to
> standardize the collection of the impairments, if it is distributed
> across multiple PCEs it may be preferable to only expose a "figure of
> merit" for the portion of the path that has been computed vs.
> standardization of the method of computation.  This should be discussed
> with the experts from Q6.

I think you are inferring a little more than was intended. In the PCE 
working group they talk of "objective functions". For example, they may say 
"minimize cost" and mean that the cost of a path is computed by accumulating 
cost in a particular way. But that does not specify a mechanism for 
computing the least cost path - only the way that the cost of a path is 
evaluated.

So, it was my intent here to make the same statement. That is, that CCAMP is 
looking for the rules by which the end-to-end impairments of a path may be 
determined from a knowledge of parameters of the path and impairments on the 
path segments.

I will add this clarifying text.

And note that yes, this should be discussed with Q6. That's why we are 
meeting them :-)

Thanks,
Adrian 

Delivery-date: Tue, 10 Mar 2009 17:19:12 +0000
Date: Tue, 10 Mar 2009 10:17:48 -0700
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: Giovanni Martinelli <[email-masked]>, Malcolm Betts <[email-masked]>, "O'Connor, Don" <[email-masked]>, [email-masked]
Subject: Re: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]

Whoops, sorry Adrian I mis-interpreted your statement: "There is no 
requirement to measure impairments."  To forever exclude the measurement 
of impairments. Rather than what it says, i.e., "that we don't make you 
measure impairments".

I particularly wanted to ask Q6 about G.697 as a guiding "framework" for 
measurements. It lists applications, classifies measurement types and 
gives a short list of some measurable parameters.

An aside: In one sense GMPLS already has some optical measurement 
capabilities via LMP. Also see Seno's new draft 
draft-seno-ccamp-wson-impairment-compensate-cntl-00.txt that gives 
another data point for optical measurement applications.

Regards

Greg

Adrian Farrel wrote:
> I'm going to try to answer all of the comments about measuring 
> impairments in one email.
>
> I'm arguing all of this from an abstract point of view. I want to 
> "out" in advance of the meeting as much of opinion held in CCAMP. I do 
> not believe it is valuable to go into the meeting expressing what we 
> think may be Q6's view. Instead, we need to say what it is people in 
> CCAMP may want to do. Then we can get Q6 feedback on whether that is 
> practical and what the concerns are.
>
> So...
>
> The ability to measure optical impairments on an active path is 
> claimed by several vendors. I am not in a position to judge whether 
> they are successful or not.
>
> Giovanni reasonably asks "what exactly you mean by *ability to measure*?"
>
> We are proposing protocol extensions that allow nodes to distribute 
> information about optical impairments. It is not our business to 
> define from where this information is gathered. We can observe that 
> the information might be configured, might be measured during network 
> provisioning and held static, might be determined by a node applying 
> some algorithm to configured on pre-measured information, or might be 
> measured dynamically. So we can choose between:
> - optical impairments can be advertised, but cannot be updated
> - optical impairments can be advertised, and can be updated
>
> If we choose the first of these, it seems that we are shutting out 
> what some people want to be able to do. If we choose the latter, we 
> are not requiring anyone to update the information they advertise, but 
> we are allowing this to be done if a node chooses to do so.
>
> To answer Don specifically, I see no proposal in CCAMP about which 
> impairments could be measured or how they would be measured. But, to 
> turn this point around, I do not believe that CCAMP should say "you 
> must not measure an impairment". As Don says, this is outside our remit.
>
> Malcolm's suggestion doesn't cut it for me.
> By saying "We understand that Q6 currently has no requirement to 
> measure impairments after the transport equipment is deployed" we miss 
> the point. The point is not what Q6 requires or does not require, but 
> is what CCAMP requires.
>
> So I wonder what is wrong with the statement (in the context of 
> describing what CCAMP wants to do) that "There is no requirement to 
> measure impairments."
>
> Don objected specifically to...
>>    However, if an implementer chooses to measure impairments
>>    on their device, this should not be prohibited, and should be
>>    accommodated.
>
> How would it be if we defered the practicality of such measurements to 
> the ITU? We could then write...
>
>    However, if an implementer chooses to measure impairments
>    on their device, and this can be achieved within the mechanisms
>    and definitions defined by the ITU-T, then this should not be
>    prohibited by the CCAMP protocol mechanisms, and should be
>    accommodated within GMPLS.
>
> Cheers,
> Adrian
>
>

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

Delivery-date: Tue, 10 Mar 2009 16:49:04 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Giovanni Martinelli" <[email-masked]>, "Malcolm Betts" <[email-masked]>, "O'Connor, Don" <[email-masked]>
Cc: <[email-masked]>
Subject: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]
Date: Tue, 10 Mar 2009 16:48:25 -0000

I'm going to try to answer all of the comments about measuring impairments 
in one email.

I'm arguing all of this from an abstract point of view. I want to "out" in 
advance of the meeting as much of opinion held in CCAMP. I do not believe it 
is valuable to go into the meeting expressing what we think may be Q6's 
view. Instead, we need to say what it is people in CCAMP may want to do. 
Then we can get Q6 feedback on whether that is practical and what the 
concerns are.

So...

The ability to measure optical impairments on an active path is claimed by 
several vendors. I am not in a position to judge whether they are successful 
or not.

Giovanni reasonably asks "what exactly you mean by *ability to measure*?"

We are proposing protocol extensions that allow nodes to distribute 
information about optical impairments. It is not our business to define from 
where this information is gathered. We can observe that the information 
might be configured, might be measured during network provisioning and held 
static, might be determined by a node applying some algorithm to configured 
on pre-measured information, or might be measured dynamically. So we can 
choose between:
- optical impairments can be advertised, but cannot be updated
- optical impairments can be advertised, and can be updated

If we choose the first of these, it seems that we are shutting out what some 
people want to be able to do. If we choose the latter, we are not requiring 
anyone to update the information they advertise, but we are allowing this to 
be done if a node chooses to do so.

To answer Don specifically, I see no proposal in CCAMP about which 
impairments could be measured or how they would be measured. But, to turn 
this point around, I do not believe that CCAMP should say "you must not 
measure an impairment". As Don says, this is outside our remit.

 Malcolm's suggestion doesn't cut it for me.
By saying "We understand that Q6 currently has no requirement to measure 
impairments after the transport equipment is deployed" we miss the point. 
The point is not what Q6 requires or does not require, but is what CCAMP 
requires.

So I wonder what is wrong with the statement (in the context of describing 
what CCAMP wants to do) that "There is no requirement to measure 
impairments."

Don objected specifically to...
>    However, if an implementer chooses to measure impairments
>    on their device, this should not be prohibited, and should be
>    accommodated.

How would it be if we defered the practicality of such measurements to the 
ITU? We could then write...

    However, if an implementer chooses to measure impairments
    on their device, and this can be achieved within the mechanisms
    and definitions defined by the ITU-T, then this should not be
    prohibited by the CCAMP protocol mechanisms, and should be
    accommodated within GMPLS.

Cheers,
Adrian 

Delivery-date: Tue, 10 Mar 2009 16:44:24 +0000
Date: Tue, 10 Mar 2009 09:43:15 -0700
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Updated Draft Liaiosn to Q6/15

This is a multi-part message in MIME format.
--------------050505050000080709030502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Adrian and all. I tried fixing the text to meet Malcolm's issues and 
added some more specific questions. On the measurement side of things, I 
think it is premature to either include or exclude. If we are starting 
with impairment aware routing and wavelength assignment (a form of 
constrained path estimation) then we can assume that the impairment 
parameters are given to us for the purpose of estimation of impairment 
impacts.
I've seen some recent drafts that present some concrete and reasonable 
uses of the control plane in optical measurements, however these have 
not been discussed and hence doesn't seem appropriate to include in the 
Q6 discussions this time around.

Cheers

Greg

P.S. View in HTML mode since I tried using the "strike through" feature 
to indicate deletions.

Adrian Farrel wrote:
> 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
---------------------------------------------------------------------------GMPLS-----------------------------------
> 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-lambda-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-framework-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
--> Or Networks in which approximate impairment estimation is sufficient
> 4. Concern for "advanced" impairments
--> Or Networks in which detail impairment validation is necessary
>
> 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
 Better - G.680 (et al) provides us with the definitions of optical 
impairments, optical parameters, and insights into their use
> - 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.
- The initial focus of our work  is on the constraints imposed by 
optical impairments on path selection. The parameters characterizing 
these impairments are assumed to be given. We do not currently address 
how these parameters are originally measured or estimated. It is for 
further study whether the control plane has a role in the measurement of 
optical parameters.
>   - 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
       - whether these parameters are "NE wide", or exhibit dependencies 
on a per port or a "port-to-port" basis.
       - frequency/wavelength dependency of parameters, if any, and 
recommended interpolation functions.
>   - and the complete list of Recommendations to use as references
    - depending upon the computational model the rules by which such 
impairments are accumulated along a path
> - 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-impairments-02.txt 
>
>
> "Information Model for Impaired Optical Path Validation"
> http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info-00.txt 
>
>
> Looking forward to a profitable meeting,
> Deborah Brungard and Adrian Farrel
> CCAMP Working Group Co-Chairs
>
>
>

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

--------------050505050000080709030502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Adrian and all. I tried fixing the text to meet Malcolm's issues and
added some more specific questions. On the measurement side of things,
I think it is premature to either include or exclude. If we are
starting with impairment aware routing and wavelength assignment (a
form of constrained path estimation) then we can assume that the
impairment parameters are given to us for the purpose of estimation of
impairment impacts.<br>
I've seen some recent drafts that present some concrete and reasonable
uses of the control plane in optical measurements, however these have
not been discussed and hence doesn't seem appropriate to include in the
Q6 discussions this time around.<br>
<br>
Cheers<br>
<br>
Greg<br>
<br>
P.S. View in HTML mode since I tried using the "strike through" feature
to indicate deletions.<br>
<br>
Adrian Farrel wrote:
<blockquote cite="mid:03D15E1A435F4838857673675DAD25A4@your029b8cecfe"
 type="cite">Hi,
  <br>
  <br>
Had some comments off-list.
  <br>
  <br>
New version with minor changes...
  <br>
  <br>
===
  <br>
  <br>
Dear Peter,
  <br>
  <br>
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).
  <br>
  <br>
This liaison is to summarise the activity within CCAMP on this subject
so far and to set out our objectives for this work.
  <br>
  <br>
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</blockquote>
---------------------------------------------------------------------------GMPLS-----------------------------------<br>
<blockquote cite="mid:03D15E1A435F4838857673675DAD25A4@your029b8cecfe"
 type="cite"> fact, lambda switching was the technology that led to the
development of <strike>MPLS</strike> from the packet switching MPLS
control plane.
  <br>
  <br>
The IETF's CCAMP working group is the design authority for all
extensions to the GMPLS family of protocols.
  <br>
  <br>
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.
  <br>
  <br>
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.
  <br>
  <br>
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
  <br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-03.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-03.txt</a>
  <br>
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:
  <br>
  <br>
"Framework for GMPLS and PCE Control of Wavelength Switched Optical
Networks (WSON)"
  <br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-01.txt</a>
  <br>
  <br>
"Routing and Wavelength Assignment Information Model for Wavelength
Switched Optical Networks"
  <br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-01.txt</a>
  <br>
  <br>
"Routing and Wavelength Assignment Information Encoding for Wavelength
Switched Optical Networks"
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-00.txt</a>
  <br>
  <br>
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:
  <br>
  <br>
1. No concern for impairments or lambda continuity.
  <br>
&nbsp; (Original GMPLS)
  <br>
2. No concern for impairments, but lambda continuity is
  <br>
&nbsp;&nbsp; important. (The RWA problem)
  <br>
3. Concern for "basic" impairments
  <br>
</blockquote>
--&gt; Or Networks in which approximate impairment estimation is
sufficient<br>
<blockquote cite="mid:03D15E1A435F4838857673675DAD25A4@your029b8cecfe"
 type="cite">4. Concern for "advanced" impairments
  <br>
</blockquote>
--&gt; Or Networks in which detail impairment validation is necessary<br>
<blockquote cite="mid:03D15E1A435F4838857673675DAD25A4@your029b8cecfe"
 type="cite"><br>
In focusing on the third of these categories, CCAMP intends to base its
work on G.680 and related recommendations with the following
understanding:
  <br>
- G.680 (et al.) provides a complete list of simple constraints
  <br>
</blockquote>
&nbsp;Better - G.680 (et al) provides us with the definitions of optical
impairments, optical parameters, and insights into their use<br>
<blockquote cite="mid:03D15E1A435F4838857673675DAD25A4@your029b8cecfe"
 type="cite">- Where G.680 refers to "single vendor" domains, it does
not
  <br>
&nbsp; mean single manufacturer, but rather "single system integrator".
  <br>
&nbsp; That is, the equipment is not "plug and play", but has been
  <br>
&nbsp; tested to interoperate and the network has been planned.
  <br>
</blockquote>
<blockquote cite="mid:03D15E1A435F4838857673675DAD25A4@your029b8cecfe"
 type="cite">- <strike>There is no requirement to measure impairments.
  </strike><br>
</blockquote>
- The initial focus of our work&nbsp; is on the constraints imposed by
optical impairments on path selection. The parameters characterizing
these impairments are assumed to be given. We do not currently address
how these parameters are originally measured or estimated. It is for
further study whether the control plane has a role in the measurement
of optical parameters.<br>
<blockquote cite="mid:03D15E1A435F4838857673675DAD25A4@your029b8cecfe"
 type="cite">&nbsp; - <strike>Many networks are engineered such that
configured
  <br>
&nbsp;&nbsp;&nbsp;&nbsp; impairment values are enough information
  </strike><br>
  <strike>&nbsp; - Measuring can often produce ambiguous values
  </strike><br>
&nbsp;<strike> - Equipment to perform measurement may be expensive
  <br>
&nbsp; However, if an implementer chooses to measure impairments
  <br>
&nbsp; on their device, this should not be prohibited, and should be
  <br>
&nbsp; accommodated.
  </strike><br>
  <br>
With this in mind, CCAMP is looking to Q6/15 to work as a partner in
establishing:
  <br>
- the complete list of impairments suitable for this type of network
  <br>
</blockquote>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; - whether these parameters are "NE wide", or exhibit
dependencies on a per port or a "port-to-port" basis.<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; - frequency/wavelength dependency of parameters, if any, and
recommended interpolation functions.<br>
<blockquote cite="mid:03D15E1A435F4838857673675DAD25A4@your029b8cecfe"
 type="cite">&nbsp; - and the complete list of Recommendations to use as
references
  <br>
</blockquote>
&nbsp;&nbsp;&nbsp; - depending upon the computational model the rules by which such
impairments are accumulated along a path
<blockquote cite="mid:03D15E1A435F4838857673675DAD25A4@your029b8cecfe"
 type="cite">-<strike> the rules by which such impairments are
accumulated along a path
  </strike><br>
- generic encodings and ranges of values for the impairments
  <br>
  <br>
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.
  <br>
  <br>
"A Framework for the Control of Wavelength Switched Optical Networks
(WSON) with Impairments"
  <br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairments-02.txt">http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairments-02.txt</a>
  <br>
  <br>
"Information Model for Impaired Optical Path Validation"
  <br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info-00.txt">http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info-00.txt</a>
  <br>
  <br>
Looking forward to a profitable meeting,
  <br>
Deborah Brungard and Adrian Farrel
  <br>
CCAMP Working Group Co-Chairs <br>
  <br>
  <br>
  <br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</pre>
</body>
</html>

--------------050505050000080709030502--

Delivery-date: Tue, 10 Mar 2009 16:05:29 +0000
Date: Tue, 10 Mar 2009 17:03:25 +0100
From: Giovanni Martinelli <[email-masked]>
To: Malcolm Betts <[email-masked]>
CC: "O'Connor, Don" <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: Updated Draft Liaiosn to Q6/15

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: [email-masked]
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Giovanni Martinelli
> Sent: Tuesday, March 10, 2009 5:19 AM
> To: O'Connor, Don
> Cc: Adrian Farrel; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Adrian Farrel
>> Sent: Monday, March 09, 2009 4:50 PM
>> To: [email-masked]
>> 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
>>
>>
>>
>>
>>   
>>     
>
>   

Delivery-date: Tue, 10 Mar 2009 12:50:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Updated Draft Liaiosn to Q6/15
Date: Tue, 10 Mar 2009 08:49:38 -0400
From: "Malcolm Betts" <[email-masked]>
To: "Giovanni Martinelli" <[email-masked]>, "O'Connor, Don" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>

I missed this in my first comments ;( I share the concern expressed by
Don. =20

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

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Giovanni Martinelli
Sent: Tuesday, March 10, 2009 5:19 AM
To: O'Connor, Don
Cc: Adrian Farrel; [email-masked]
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=20
> standards that imply ROADM data plane functionality. If any optical=20
> impairments are measured by ROADMs, ITU must first generate the=20
> necessary standard
>  =20
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: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Adrian Farrel
> Sent: Monday, March 09, 2009 4:50 PM
> To: [email-masked]
> Subject: Updated Draft Liaiosn to Q6/15
>
> Hi,
>
> Had some comments off-list.
>
> New version with minor changes...
>
>  =3D=3D=3D
>
>  Dear Peter,
>
> CCAMP experts are looking forward to our joint meeting with Q6/5 on=20
> March 20th to discuss optical impairments and the control plane=20
> 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=20
> OEOs, ROADMs, and photonic cross-connects (PXCs). In fact, lambda=20
> switching was the technology that led to the development of MPLS from=20
> the packet switching
>
> MPLS control plane.
>
> The IETF's CCAMP working group is the design authority for all=20
> 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=20
> disregard optical impairments and where the number of regeneration=20
> points is high.
> In
> these environments, path computation can be performed on a=20
> reachability graph, and lambda conversion can be performed as=20
> necessary within the network.
>
> As PXCs were introduced into WSONs, it remained the case that optical=20
> impairments could be disregarded by the control plane. Where=20
> necessary, optimal impairment-aware paths could be computed off-line=20
> and supplied to the control plane, leaving the control plane to handle

> establishment of connections and recovery after failure. Failure=20
> recovery scenarios might
>
> lead to contention for wavelengths or suboptimal optical paths, but=20
> these could be handled by crankback within the signaling protocol.
>
> More recent work on WSONs indicates that the proportion of pure=20
> optical devices (ROADMs and PXCs) is increasing. This means that it is

> necessary to compute paths that offer end-to-end lambda continuity.=20
> This problem (called the routing and wavelength assignment (RWA)=20
> 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=20
> this problem it is convenient if there is a common identification=20
> scheme for wavelengths across the whole
>
> network (previously, wavelength identification was a local matter=20
> between the nodes at the ends of each link). To aid with this, the=20
> 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=20
> way that is compliant with G.694. Further work on this problem space=20
> can be seen in the following CCAMP documents:
>
> "Framework for GMPLS and PCE Control of Wavelength Switched Optical=20
> 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=20
> 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=20
> 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=20
> its work on G.680 and related recommendations with the following=20
> 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=20
> below.
> This work is not yet adopted as CCAMP work, but is likely to form the=20
> 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=20
> Farrel CCAMP Working Group Co-Chairs
>
>
>
>
>  =20

Delivery-date: Tue, 10 Mar 2009 12:25:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Updated Draft Liaiosn to Q6/15
Date: Tue, 10 Mar 2009 08:23:16 -0400
From: "Malcolm Betts" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Adrian, good summary of the status. A few comments/suggestions to help
the debate:

Deployment scenario 3 "Concern for "basic" impairments" my recollection
is that we were considering network scenarios in which we could allocate
sufficient margin so that a "simple" computation of the accumulation
could be used and still have a high probability that the optical path
would be viable and would not perturb any existing paths.

Deployment scenario 4 "Concern for "advanced" impairments" again my
recollection is that in this scenario a full computation of the
accumulation of impairments including the impact on existing paths is
required.  This significantly increases the scope of information
required and the compute time.

One final concern: =20
"With this in mind, CCAMP is looking to Q6/15 to work as a partner in
establishing:
- ....
- the rules by which such impairments are accumulated along a path
- ...."

This implies that we will standardize an aspect of path computation i.e.
the method of computing the accumulation of impairments.  If the path
computation is performed in a single PCE then it is only necessary to
standardize the collection of the impairments, if it is distributed
across multiple PCEs it may be preferable to only expose a "figure of
merit" for the portion of the path that has been computed vs.
standardization of the method of computation.  This should be discussed
with the experts from Q6.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, March 09, 2009 5:50 PM
To: [email-masked]
Subject: Updated Draft Liaiosn to Q6/15

Hi,

Had some comments off-list.

New version with minor changes...

 =3D=3D=3D

 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-lambda-
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-framework-
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"=20
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.=20
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-impairmen
ts-02.txt

 "Information Model for Impaired Optical Path Validation"
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info
-00.txt

Looking forward to a profitable meeting, Deborah Brungard and Adrian
Farrel CCAMP Working Group Co-Chairs=20

Delivery-date: Tue, 10 Mar 2009 10:12:46 +0000
Date: Tue, 10 Mar 2009 11:11:34 +0100
From: Martin Vigoureux <[email-masked]>
Organization: Alcatel-Lucent
To: [email-masked], [email-masked], [email-masked], [email-masked]
CC: [email-masked], Loa Andersson <[email-masked]>, George Swallow <[email-masked]>
Subject: Time slots for IETF74 joint mpls-tp session

all,

this is reminder.
If you wish to have a presentation slot during the joint mpls-tp
session, let me know.
This session is planned Wednesday 25th, 09:00-11:30 am.

martin

Delivery-date: Tue, 10 Mar 2009 09:20:46 +0000
Date: Tue, 10 Mar 2009 10:18:50 +0100
From: Giovanni Martinelli <[email-masked]>
To: "O'Connor, Don" <[email-masked]>
CC: Adrian Farrel <[email-masked]>, [email-masked]
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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Adrian Farrel
> Sent: Monday, March 09, 2009 4:50 PM
> To: [email-masked]
> 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-lambda-
> 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-framework-
> 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-impairmen
> ts-02.txt
>
>  "Information Model for Impaired Optical Path Validation"
> http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info
> -00.txt
>
> Looking forward to a profitable meeting,
> Deborah Brungard and Adrian Farrel
> CCAMP Working Group Co-Chairs 
>
>
>
>
>   

Delivery-date: Mon, 09 Mar 2009 23:13:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Updated Draft Liaiosn to Q6/15
Date: Mon, 9 Mar 2009 18:12:12 -0500
From: "O'Connor, Don" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

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

Regards

Don=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, March 09, 2009 4:50 PM
To: [email-masked]
Subject: Updated Draft Liaiosn to Q6/15

Hi,

Had some comments off-list.

New version with minor changes...

 =3D=3D=3D

 Dear Peter,

CCAMP experts are looking forward to our joint meeting with Q6/5 on
March=20
20th to discuss optical impairments and the control plane operation of=20
wavelength switched optical networks (WSONs).

This liaison is to summarise the activity within CCAMP on this subject
so=20
far and to set out our objectives for this work.

As you will be aware, the GMPLS control plane is designed to provide a=20
dynamic control plane for a variety of switching technologies. Amongst
these=20
is the "lambda switch capable" data plane where devices are OEOs,
ROADMs,=20
and photonic cross-connects (PXCs). In fact, lambda switching was the=20
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=20
the GMPLS family of protocols.

The original work on lambda switching networks within CCAMP recognised
that=20
there is a subset of optical networks in which it is possible to
disregard=20
optical impairments and where the number of regeneration points is high.
In=20
these environments, path computation can be performed on a reachability=20
graph, and lambda conversion can be performed as necessary within the=20
network.

As PXCs were introduced into WSONs, it remained the case that optical=20
impairments could be disregarded by the control plane. Where necessary,=20
optimal impairment-aware paths could be computed off-line and supplied
to=20
the control plane, leaving the control plane to handle establishment of=20
connections and recovery after failure. Failure recovery scenarios might

lead to contention for wavelengths or suboptimal optical paths, but
these=20
could be handled by crankback within the signaling protocol.

More recent work on WSONs indicates that the proportion of pure optical=20
devices (ROADMs and PXCs) is increasing. This means that it is necessary
to=20
compute paths that offer end-to-end lambda continuity. This problem
(called=20
the routing and wavelength assignment (RWA) problem) must be solved, and
may=20
be compounded by devices with limited cross-connect capabilities (for=20
example, with glass-through, a limited OEO matrix, or restricted=20
port-to-port capabilities). In approaching this problem it is convenient
if=20
there is a common identification scheme for wavelengths across the whole

network (previously, wavelength identification was a local matter
between=20
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-lambda-
labels-03.txt
 that provides a protocol-independent encoding for wavelengths in a way
that=20
is compliant with G.694. Further work on this problem space can be seen
in=20
the following CCAMP documents:

"Framework for GMPLS and PCE Control of Wavelength Switched Optical
Networks=20
(WSON)"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-
01.txt

"Routing and Wavelength Assignment Information Model for Wavelength
Switched=20
Optical Networks"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-01.txt

"Routing and Wavelength Assignment Information Encoding for Wavelength=20
Switched Optical Networks"=20
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=20
be helpful to consider optical impairments during the control plane=20
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=20
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=20
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.=20
This work is not yet adopted as CCAMP work, but is likely to form the
basis=20
of such work once we have discussed the way forward with Q6/15.

"A Framework for the Control of Wavelength Switched Optical Networks
(WSON)=20
with Impairments"
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairmen
ts-02.txt

 "Information Model for Impaired Optical Path Validation"
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info
-00.txt

Looking forward to a profitable meeting,
Deborah Brungard and Adrian Farrel
CCAMP Working Group Co-Chairs=20

Delivery-date: Mon, 09 Mar 2009 22:01:19 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-mpls-graceful-shutdown-10.txt 
Date: Mon,  9 Mar 2009 15:00:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks
	Author(s)       : Z. Ali, et al.
	Filename        : draft-ietf-ccamp-mpls-graceful-shutdown-10.txt
	Pages           : 10
	Date            : 2009-03-09

MPLS-TE Graceful Shutdown is a method for explicitly notifying 
the nodes in a Traffic Engineering (TE) enabled network that the 
TE capability on a link or on an entire Label Switching Router 
(LSR) is going to be disabled. MPLS-TE graceful shutdown 
mechanisms are tailored toward addressing planned outage in the 
network.  
 
This document provides requirements and protocol mechanisms to 
reduce/eliminate traffic disruption in the event of a planned 
shutdown of a network resource. These operations are equally 
applicable to both MPLS and its Generalized MPLS (GMPLS) 
extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-mpls-graceful-shutdown-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 09 Mar 2009 21:51:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Updated Draft Liaiosn to Q6/15
Date: Mon, 9 Mar 2009 21:49:32 -0000

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-lambda-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-framework-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-impairments-02.txt

 "Information Model for Impaired Optical Path Validation"
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info-00.txt

Looking forward to a profitable meeting,
Deborah Brungard and Adrian Farrel
CCAMP Working Group Co-Chairs 

Delivery-date: Mon, 09 Mar 2009 17:01:29 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-mpls-graceful-shutdown-09.txt 
Date: Mon,  9 Mar 2009 10:00:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Category: Informational Expires: September 08, 2009 March 09, 2009
	Author(s)       : Z. Ali, et al.
	Filename        : draft-ietf-ccamp-mpls-graceful-shutdown-09.txt
	Pages           : 10
	Date            : 2009-03-09

MPLS-TE Graceful Shutdown is a method for explicitly notifying 
the nodes in a Traffic Engineering (TE) enabled network that the 
TE capability on a link or on an entire Label Switching Router 
(LSR) is going to be disabled. MPLS-TE graceful shutdown 
mechanisms are tailored toward addressing planned outage in the 
network.  
 
This document provides requirements and protocol mechanisms to 
reduce/eliminate traffic disruption in the event of a planned 
shutdown of a network resource. These operations are equally 
applicable to both MPLS and its Generalized MPLS (GMPLS) 
extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-mpls-graceful-shutdown-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 09 Mar 2009 16:17:09 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Draft Liaiosn to Q6/15
Date: Mon, 9 Mar 2009 16:15:13 -0000

Hi,

Given the time constraints, could you please comment on this proposed 
liaison as quickly as possible.

Thanks,
Adrian

===

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 GMPLS 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. The routing and
wavelength assignment (RWA) problem must be solved, and may be compounded by 
devices with limited cross-connect 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-lambda-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-framework-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 with the following understanding:
- G.680 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
- the rules by which such impairments are accumulated along a path
- generic encodings and ranges of values for the impairments in G.680

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-impairments-02.txt

"Information Model for Impaired Optical Path Validation"
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info-00.txt

Looking forward to a profitable meeting,
Deborah Brungard and Adrian Farrel
CCAMP Working Group Co-Chairs 

Delivery-date: Mon, 09 Mar 2009 14:01:32 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-rsvp-te-eth-oam-ext-01.txt 
Date: Mon,  9 Mar 2009 07:00:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : GMPLS RSVP-TE Extensions for Ethernet OAM Configuration
	Author(s)       : A. Takacs, et al.
	Filename        : draft-ietf-ccamp-rsvp-te-eth-oam-ext-01.txt
	Pages           : 21
	Date            : 2009-03-09

The GMPLS controlled Ethernet Label Switching (GELS) work is
extending GMPLS RSVP-TE to support the establishment of Ethernet
LSPs.  IEEE Ethernet Connectivity Fault Management (CFM) specifies an
adjunct OAM flow to check connectivity in Ethernet networks.  CFM can
be also used with Ethernet LSPs for fault detection and triggering
recovery mechanisms.  The ITU-T Y.1731 specification builds on CFM
and specifies additional OAM mechanisms, including Performance
Monitoring, for Ethernet networks.  This document specifies
extensions of GMPLS RSVP-TE to support the setup of the associated
Ethernet OAM (CFM and Y.1731) entities adding a technology specific
TLV to [OAM-CONF-FWK].Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-eth-oam-ext-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rsvp-te-eth-oam-ext-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 09 Mar 2009 13:23:30 +0000
Date: Mon, 09 Mar 2009 21:22:07 +0800
From: MachChen 55527 <[email-masked]>
Subject: =?gb2312?B?u9i4tA==?=:RE: OSPF inter-AS extensions for GMPLS (RFC5392) questions
To: Fabien Verhaeghe <[email-masked]>
Cc: 'Adrian Farrel' <[email-masked]>, [email-masked]

Hi Faibien=2C

Sorry about the confusion=2E

----- =D4=AD=D3=CA=BC=FE -----
=B7=A2=BC=FE=C8=CB=3A Fabien Verhaeghe =3Cfabien=2Everhaeghe=40marben-pro=
ducts=2Ecom=3E
=C8=D5=C6=DA=3A =D0=C7=C6=DA=D2=BB=2C =C8=FD=D4=C2 9=C8=D5=2C 2009 =CF=C2=
=CE=E73=3A41
=D6=F7=CC=E2=3A RE=3A OSPF inter-AS extensions for GMPLS (RFC5392) questi=
ons
=CA=D5=BC=FE=C8=CB=3A =27Adrian Farrel=27 =3Cadrian=40olddog=2Eco=2Euk=3E=
=2C ccamp=40ops=2Eietf=2Eorg

=3E Hi Adrian=2C
=3E =

=3E See in-line
=3E =

=3E =3E Hi Fabien=2C
=3E =3E =

=3E =3E =3E Sorry to come a little late on this but I have a question on =

=3E inter-AS
=3E =3E =3E extensions RFC5392 (also applicable on ISIS extensions)=2E
=3E =3E =3E In section 4=3A
=3E =3E =3E =22 Only some essential TE information for the link needs to =
be
=3E =3E =3E   advertised=3B i=2Ee=2E=2C the Link Type=2C the Remote AS nu=
mber=2C and =

=3E the Remote
=3E =3E =3E   ASBR ID=2E=22
=3E =3E =3E
=3E =3E =3E First what does =22remote=22 mean here=3F is it remote in the=
 context =

=3E of the
=3E =3E =3E proxied link or in the context of the Router=3F
=3E =3E =3E i=2Ee=2E
=3E =3E =3E
=3E =3E =3E RouterA in AS1 ------TE Link------ RouterB in AS2
=3E =3E =3E
=3E =3E =3E I guess it is in the context of the link=2E That is in LSA =

=3E generated by
=3E =3E =3E router
=3E =3E =3E A for B-=3EA link (proxied) we put AS1 and routerA ASBR Id=2E=
 Is that
=3E =3E correct=3F
=3E =3E =

=3E =3E Yeah=2C you could say =22in the context of the router=2E=22 Or ev=
en =22in the
=3E =3E context
=3E =3E of the IGP instance=22=2E Since the IGP will only be running in o=
ne =

=3E AS=2C the
=3E =3E advertising router is talking about the IDs of the =22other=22 AS=
 and =

=3E ASBR=2E=3E =

=3E =

=3E Sorry but I am still a little bit confused=2E
=3E Router A generates 2 LSAs for a TE link between A and B=2E
=3E One for A-=3EB direction and one for B-=3EA direction (because B is i=
n a
=3E separate IGP)=2E
=3E Are you saying that in both LSAs the remote AS number sub TLV is =

=3E set to
=3E Router A=27s AS=3F

No=2C for A-=3EB direction=2C the remote AS number sub=5FTLV is set to Ro=
uter B=27s =

AS=2C and for B-=3EA direction=2C it is set to Router A=27s AS=2E

I think it more accurate to say =22in the context of the router or proxie=
d =

router=22 or even =22in the context of the IGP instance or proxied IGP in=
tance=22 =

=3A-)

For me=2C =22in the context of the link=22 is also OK=2E

=3E =

=3E If yes what I don=27t get is how other routers in this AS knows which=
 =

=3E LSAcorresponds to A-=3EB direction and which one corresponds to B-=3E=
A =

=3E direction=2E
=3E That is why I thought =22remote=22 in the text mentioned in my first =
email
=3E refers to the =22link context=22=2E Then both LSAs would contain =

=3E different remote
=3E AS/ASBRId so that we can tell which one corresponds to each direction=
=2E
=3E =

Correct=2E

=3E Please let me know if I miss something=2E=2E=2E
=3E =

=3E Thanks
=3E Fabien
=3E =

=3E =

=3E =

Best regards=2C
Mach

Delivery-date: Mon, 09 Mar 2009 12:17:47 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-oam-configuration-fwk-01.txt 
Date: Mon,  9 Mar 2009 05:15:02 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : OAM Configuration Framework and Requirements for GMPLS RSVP-TE
	Author(s)       : A. Takacs, et al.
	Filename        : draft-ietf-ccamp-oam-configuration-fwk-01.txt
	Pages           : 22
	Date            : 2009-03-09

OAM is an integral part of transport connections, hence it is 
required that OAM functions are activated/deactivated in sync with 
connection commissioning/decommissioning; avoiding spurious alarms 
and ensuring consistent operation.  In certain technologies OAM 
entities are inherently established once the connection is set up, 
while other technologies require extra configuration to establish
and configure OAM entities.  This document specifies extensions to
RSVP-TE to support the establishment and configuration of OAM
entities along with LSP signaling.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-oam-configuration-fwk-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-oam-configuration-fwk-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 09 Mar 2009 07:41:12 +0000
From: "Fabien Verhaeghe" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: OSPF inter-AS extensions for GMPLS (RFC5392) questions
Date: Mon, 9 Mar 2009 08:39:20 +0100

Hi Adrian,

See in-line

> Hi Fabien,
> 
> > Sorry to come a little late on this but I have a question on inter-AS
> > extensions RFC5392 (also applicable on ISIS extensions).
> > In section 4:
> > " Only some essential TE information for the link needs to be
> >   advertised; i.e., the Link Type, the Remote AS number, and the Remote
> >   ASBR ID."
> >
> > First what does "remote" mean here? is it remote in the context of the
> > proxied link or in the context of the Router?
> > i.e.
> >
> > RouterA in AS1 ------TE Link------ RouterB in AS2
> >
> > I guess it is in the context of the link. That is in LSA generated by
> > router
> > A for B->A link (proxied) we put AS1 and routerA ASBR Id. Is that
> correct?
> 
> Yeah, you could say "in the context of the router." Or even "in the
> context
> of the IGP instance". Since the IGP will only be running in one AS, the
> advertising router is talking about the IDs of the "other" AS and ASBR.
> 

Sorry but I am still a little bit confused.
Router A generates 2 LSAs for a TE link between A and B.
One for A->B direction and one for B->A direction (because B is in a
separate IGP).
Are you saying that in both LSAs the remote AS number sub TLV is set to
Router A's AS?

If yes what I don't get is how other routers in this AS knows which LSA
corresponds to A->B direction and which one corresponds to B->A direction.

That is why I thought "remote" in the text mentioned in my first email
refers to the "link context". Then both LSAs would contain different remote
AS/ASBRId so that we can tell which one corresponds to each direction.

Please let me know if I miss something...

Thanks
Fabien

Delivery-date: Sun, 08 Mar 2009 21:37:22 +0000
Content-class: urn:content-classes:message
Subject: RE: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
Date: Sun, 8 Mar 2009 22:34:04 +0100
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Ben Niven-Jenkins" <[email-masked]>, "Thomas Nadeau" <[email-masked]>, "Loa Andersson" <[email-masked]>
Cc: "George Swallow" <[email-masked]>, <[email-masked]>, "ITU-T ad hoc team on MPLS-TP" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "David Ward" <[email-masked]>, "Malcolm Betts" <[email-masked]>, "VIGOUREUX MARTIN" <[email-masked]>

Agreed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Ben Niven-Jenkins
Sent: Friday, March 06, 2009 18:42
To: Thomas Nadeau; Loa Andersson
Cc: George Swallow; [email-masked]; ITU-T ad hoc team on MPLS-TP;
[email-masked]; [email-masked]; [email-masked]; David Ward; Malcolm
Betts; VIGOUREUX MARTIN
Subject: Re: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

Agreed.

It addresses a need and provides a solution for operators evolving to
MPLS-TP from their existing deployed MPLS & PW services without
significant
changes to their existing support infrastructures.

Ben

On 06/03/2009 14:00, "Thomas Nadeau" <[email-masked]> wrote:

>=20
> I think this document is ready to progress forward.
>=20
> --Tom
>=20
>=20
> On Feb 24, 2009:10:25 AM, at 10:25 AM, Loa Andersson wrote:
>=20
>> All,
>>=20
>> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal
>> has been published.
>>=20
>> The draft is found at:
>>=20
>> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
>>=20
>> Since the updates are significant this is to initiate a 2 week
>> working group last call on the new version.
>>=20
>> Please send your comments to the [email-masked] mailing list.
>>=20
>> The working group last call will end on March 11.
>>=20
>> /Loa
>> -- =20
>>=20
>>=20
>> Loa Andersson
>>=20
>> Sr Strategy and Standards Manager
>> Ericsson ///                          phone:  +46 8 632 77 14
>>=20
>>                                      email:
>> [email-masked]
>>
[email-masked]
>>                                              [email-masked]
>>=20
>>=20
>> _______________________________________________
>> pwe3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>=20
>=20
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

Delivery-date: Sat, 07 Mar 2009 10:33:03 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-path-key-ero-04.txt 
Date: Sat,  7 Mar 2009 02:30:01 -0800 (PST)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : RSVP Extensions for Path Key Support
	Author(s)       : A. Farrel, et al.
	Filename        : draft-ietf-ccamp-path-key-ero-04.txt
	Pages           : 14
	Date            : 2009-03-07

The paths taken by Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched
Paths (LSPs) may be computed by Path Computation Elements (PCEs).
Where the TE LSP crosses multiple domains, such as Autonomous Systems
(ASes), the path may be computed by multiple PCEs that cooperate,
with each responsible for computing a segment of the path.

To preserve confidentiality of topology within each AS, the PCEs
support a mechanism to hide the contents of a segment of a path (such
as the segment of the path that traverses an AS), called the
Confidential Path Segment (CPS), by encoding the contents as a Path
Key Subobject (PKS) and embedding this subobject within the result of
its path computation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-path-key-ero-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Fri, 06 Mar 2009 16:43:10 +0000
Date: Fri, 06 Mar 2009 16:42:00 +0000
Subject: Re: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
From: Ben Niven-Jenkins <[email-masked]>
To: Thomas Nadeau <[email-masked]>, Loa Andersson <[email-masked]>
CC: George Swallow <[email-masked]>, <[email-masked]>, ITU-T ad hoc team on MPLS-TP <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, David Ward <[email-masked]>, Malcolm Betts <[email-masked]>, VIGOUREUX MARTIN <[email-masked]>

Agreed.

It addresses a need and provides a solution for operators evolving to
MPLS-TP from their existing deployed MPLS & PW services without significant
changes to their existing support infrastructures.

Ben

On 06/03/2009 14:00, "Thomas Nadeau" <[email-masked]> wrote:

> 
> I think this document is ready to progress forward.
> 
> --Tom
> 
> 
> On Feb 24, 2009:10:25 AM, at 10:25 AM, Loa Andersson wrote:
> 
>> All,
>> 
>> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal
>> has been published.
>> 
>> The draft is found at:
>> 
>> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
>> 
>> Since the updates are significant this is to initiate a 2 week
>> working group last call on the new version.
>> 
>> Please send your comments to the [email-masked] mailing list.
>> 
>> The working group last call will end on March 11.
>> 
>> /Loa
>> --  
>> 
>> 
>> Loa Andersson
>> 
>> Sr Strategy and Standards Manager
>> Ericsson ///                          phone:  +46 8 632 77 14
>> 
>>                                      email:
>> [email-masked]
>>                                              [email-masked]
>>                                              [email-masked]
>> 
>> 
>> _______________________________________________
>> pwe3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pwe3
>> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

Delivery-date: Fri, 06 Mar 2009 14:02:18 +0000
Cc: [email-masked], [email-masked], [email-masked], [email-masked], ITU-T ad hoc team on MPLS-TP <[email-masked]>, George Swallow <[email-masked]>, Ross Callon <[email-masked]>, David Ward <[email-masked]>, Malcolm Betts <[email-masked]>, VIGOUREUX MARTIN <[email-masked]>
From: Thomas Nadeau <[email-masked]>
To: Loa Andersson <[email-masked]>
Subject: Re: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
Date: Fri, 6 Mar 2009 14:00:00 +0000

	I think this document is ready to progress forward.

	--Tom

On Feb 24, 2009:10:25 AM, at 10:25 AM, Loa Andersson wrote:

> All,
>
> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal
> has been published.
>
> The draft is found at:
>
> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
>
> Since the updates are significant this is to initiate a 2 week
> working group last call on the new version.
>
> Please send your comments to the [email-masked] mailing list.
>
> The working group last call will end on March 11.
>
> /Loa
> --  
>
>
> Loa Andersson
>
> Sr Strategy and Standards Manager
> Ericsson ///                          phone:  +46 8 632 77 14
>
>                                      email:   
> [email-masked]
>                                              [email-masked]
>                                              [email-masked]
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

Envelope-to: [email-masked]
Delivery-date: Fri, 06 Mar 2009 00:59:54 +0000
To: [email-masked], [email-masked]
Subject: RFC 5467 on GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Thu,  5 Mar 2009 16:56:03 -0800 (PST)

A new Request for Comments is now available in online RFC libraries.

        RFC 5467

        Title:      GMPLS Asymmetric Bandwidth Bidirectional Label 
                    Switched Paths (LSPs) 
        Author:     L. Berger, A. Takacs,
                    D. Caviglia, D. Fedyk,
                    J. Meuric
        Status:     Experimental
        Date:       March 2009
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked],
                    [email-masked], 
                    [email-masked]
        Pages:      14
        Characters: 29335
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5467.txt

This document defines a method for the support of GMPLS asymmetric
bandwidth bidirectional Label Switched Paths (LSPs).  The presented
approach is applicable to any switching technology and builds on the
original Resource Reservation Protocol (RSVP) model for the transport
of traffic-related parameters.  The procedures described in this document
are experimental.  This memo defines an Experimental Protocol for the Internet community.

This document is a product of the Common Control and Measurement Plane Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Delivery-date: Thu, 05 Mar 2009 16:43:59 +0000
Content-class: urn:content-classes:message
Subject: RE: New Version Notification for draft-rhodes-rsvp-recovery-signaling-01 
Date: Thu, 5 Mar 2009 17:42:35 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Nic Neate" <[email-masked]>, <[email-masked]>
Cc: "Aria - Adrian Farrel Personal" <[email-masked]>, "Fatai Zhang" <[email-masked]>, "Francesco Fondelli" <[email-masked]>, "Fujitsu - Fred Gruman" <[email-masked]>, "Fujitsu - Snigdho Bardalai" <[email-masked]>

Nic:=20

I am a bit afraid that the main discussion will soon become a trilogy
between=20

1. actual interpretation of the RFCs (without taking into account
feeback from the list/f2f meetings)=20

2. lack of understanding on how to use existing RFCs to implement
certain scenarios

3. protocol elements left for further improvement (cf. WTR negotiation
example)=20

up to chairs to tell here about the process but usually only point 3. is
in scope of "internet-drafts".

thanks,
-d.
> -----Original Message-----
> From: Nic Neate [mailto:[email-masked]]=20
> Sent: Thursday, March 05, 2009 11:53 AM
> To: [email-masked]
> Cc: Aria - Adrian Farrel Personal; PAPADIMITRIOU Dimitri;=20
> Fatai Zhang; Francesco Fondelli; Fujitsu - Fred Gruman;=20
> Fujitsu - Snigdho Bardalai
> Subject: FW: New Version Notification for=20
> draft-rhodes-rsvp-recovery-signaling-01=20
>=20
> Hi all,
>=20
> Following discussions on the CCAMP mailing list and in=20
> Minneapolis, we've updated=20
> http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signalin
g to give a clearer statement of the problems we identified in > GMPLS
recovery signaling.  It covers the following.
>=20
> -  Association procedures for segment recovery
> -  Association procedures for inter-domain LSPs
> -  Signaling a recovery LSP that is itself protected
> -  Data loss resulting from overlapping segment recovery LSPs
> -  Assignment of the segment-recording-desired flag (a new=20
> but straight-forward issue not yet raised on the mailing list)
>=20
> Thanks to those who have helped us clarify these issues. =20
> Please let us know if you have further comments on the=20
> problem descriptions in the draft.
>=20
> The next step will then be to develop solutions to some or=20
> all of them, either by progressing=20
> draft-rhodes-ccamp-rsvp-recovery-fix or other documents.  As=20
> always, further input and collaboration welcome.
>=20
> Nic, David and Andrew
>=20
>=20
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]=20
> Sent: 04 March 2009 15:32
> To: David McWalter
> Cc: Andrew Rhodes; Nic Neate
> Subject: New Version Notification for=20
> draft-rhodes-rsvp-recovery-signaling-01=20
>=20
>=20
> A new version of I-D,=20
> draft-rhodes-rsvp-recovery-signaling-01.txt has been=20
> successfuly submitted by David McWalter and posted to the=20
> IETF repository.
>=20
> Filename:	 draft-rhodes-rsvp-recovery-signaling
> Revision:	 01
> Title:		 Problems observed with RSVP recovery signaling
> Creation_date:	 2009-03-04
> WG ID:		 Independent Submission
> Number_of_pages: 12
>=20
> Abstract:
> Implementation experience with RSVP-TE recovery signaling has=20
> uncovered some problems.  Associations between LSPs in=20
> different sessions are forbidden.  Protecting LSPs cannot=20
> themselves be protected.  Overlapping repairs cause loss of=20
> traffic.  This draft provides details of these problems for=20
> the community to consider.
>                                                              =20
>                    =20
>=20
>=20
> The IETF Secretariat.
>=20
>=20
>=20

Delivery-date: Thu, 05 Mar 2009 16:33:32 +0000
Content-class: urn:content-classes:message
Subject: Working Group Last Call draft-ietf-ccamp-lsp-hierarchy-bis-06.txt
Date: Thu, 5 Mar 2009 11:31:29 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

Hi,

This email begins a two week working group last call on
draft-ietf-ccamp-lsp-hierarchy-bis-06.txt:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-0
6.txt

Please send your comments to the list before the last call closes on
March 19, 2009.

Thanks,
Deborah

Delivery-date: Thu, 05 Mar 2009 10:53:47 +0000
From: Nic Neate <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Aria - Adrian Farrel Personal <[email-masked]>, ALU - Dimitri Papadimitriou <[email-masked]>, Fatai Zhang <[email-masked]>, Francesco Fondelli <[email-masked]>, Fujitsu - Fred Gruman <[email-masked]>, Fujitsu - Snigdho Bardalai <[email-masked]>
Date: Thu, 5 Mar 2009 10:52:40 +0000
Subject: FW: New Version Notification for draft-rhodes-rsvp-recovery-signaling-01 
Accept-Language: en-US
acceptlanguage: en-US

Hi all,

Following discussions on the CCAMP mailing list and in Minneapolis, we've u=
pdated http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling to g=
ive a clearer statement of the problems we identified in GMPLS recovery sig=
naling.  It covers the following.

-  Association procedures for segment recovery
-  Association procedures for inter-domain LSPs
-  Signaling a recovery LSP that is itself protected
-  Data loss resulting from overlapping segment recovery LSPs
-  Assignment of the segment-recording-desired flag (a new but straight-for=
ward issue not yet raised on the mailing list)

Thanks to those who have helped us clarify these issues.  Please let us kno=
w if you have further comments on the problem descriptions in the draft.

The next step will then be to develop solutions to some or all of them, eit=
her by progressing draft-rhodes-ccamp-rsvp-recovery-fix or other documents.=
  As always, further input and collaboration welcome.

Nic, David and Andrew

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]=20
Sent: 04 March 2009 15:32
To: David McWalter
Cc: Andrew Rhodes; Nic Neate
Subject: New Version Notification for draft-rhodes-rsvp-recovery-signaling-=
01=20

A new version of I-D, draft-rhodes-rsvp-recovery-signaling-01.txt has been =
successfuly submitted by David McWalter and posted to the IETF repository.

Filename:	 draft-rhodes-rsvp-recovery-signaling
Revision:	 01
Title:		 Problems observed with RSVP recovery signaling
Creation_date:	 2009-03-04
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
Implementation experience with RSVP-TE recovery signaling has uncovered som=
e problems.  Associations between LSPs in different sessions are forbidden.=
  Protecting LSPs cannot themselves be protected.  Overlapping repairs caus=
e loss of traffic.  This draft provides details of these problems for the c=
ommunity to consider.
                                                                           =
      =20

The IETF Secretariat.

Delivery-date: Thu, 05 Mar 2009 09:50:39 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Fabien Verhaeghe" <[email-masked]>, <[email-masked]>
Subject: Re: OSPF inter-AS extensions for GMPLS (RFC5392) questions
Date: Thu, 5 Mar 2009 09:49:11 -0000

Hi Fabien,

> Sorry to come a little late on this but I have a question on inter-AS
> extensions RFC5392 (also applicable on ISIS extensions).
> In section 4:
> " Only some essential TE information for the link needs to be
>   advertised; i.e., the Link Type, the Remote AS number, and the Remote
>   ASBR ID."
>
> First what does "remote" mean here? is it remote in the context of the
> proxied link or in the context of the Router?
> i.e.
>
> RouterA in AS1 ------TE Link------ RouterB in AS2
>
> I guess it is in the context of the link. That is in LSA generated by 
> router
> A for B->A link (proxied) we put AS1 and routerA ASBR Id. Is that correct?

Yeah, you could say "in the context of the router." Or even "in the context 
of the IGP instance". Since the IGP will only be running in one AS, the 
advertising router is talking about the IDs of the "other" AS and ASBR.

> Second question: I'm not sure about the purpose of "only some essential TE
> information for the link needs to be advertised" sentence.
> Does it mean it not allowed to put other information like bandwidth,
> protection type? (in case the link has asymetric characteristic)
> Besides I think another essential information is the remote link Id or
> remote IP address in order to correlate the proxied B->A link with the 
> A->B
> link.
> Do you agree?

Perhaps the text is a bit vague here. I would use the rest of the document 
that contains definitions of which sub-TLVs are allowed.

A 

Delivery-date: Thu, 05 Mar 2009 07:54:51 +0000
From: "Fabien Verhaeghe" <[email-masked]>
To: <[email-masked]>
Subject: OSPF inter-AS extensions for GMPLS (RFC5392) questions
Date: Thu, 5 Mar 2009 08:52:56 +0100

Hello,

Sorry to come a little late on this but I have a question on inter-AS
extensions RFC5392 (also applicable on ISIS extensions).
In section 4:
" Only some essential TE information for the link needs to be
   advertised; i.e., the Link Type, the Remote AS number, and the Remote
   ASBR ID."

First what does "remote" mean here? is it remote in the context of the
proxied link or in the context of the Router?
i.e.

RouterA in AS1 ------TE Link------ RouterB in AS2

I guess it is in the context of the link. That is in LSA generated by router
A for B->A link (proxied) we put AS1 and routerA ASBR Id. Is that correct?

Second question: I'm not sure about the purpose of "only some essential TE
information for the link needs to be advertised" sentence.
Does it mean it not allowed to put other information like bandwidth,
protection type? (in case the link has asymetric characteristic)
Besides I think another essential information is the remote link Id or
remote IP address in order to correlate the proxied B->A link with the A->B
link.
Do you agree?

Thanks
Fabien

-----------------------------------

Fabien Verhaeghe (Senior consultant)
Marben Products

Delivery-date: Wed, 04 Mar 2009 17:17:41 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-rwa-wson-framework-02.txt 
Date: Wed,  4 Mar 2009 09:15:01 -0800 (PST)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)
	Author(s)       : G. Bernstein
	Filename        : draft-ietf-ccamp-rwa-wson-framework-02.txt
	Pages           : 48
	Date            : 2009-03-04

This memo provides a framework for applying Generalized Multi-
Protocol Label Switching (GMPLS) and the Path Computation Element 
(PCE) architecture to the control of wavelength switched optical 
networks (WSON).  In particular we provide control plane models for 
key wavelength switched optical network subsystems and processes. The 
subsystems include wavelength division multiplexed links, tunable 
laser transmitters, reconfigurable optical add/drop multiplexers 
(ROADM) and wavelength converters.  

Lightpath provisioning, in general, requires the routing and 
wavelength assignment (RWA) process. This process is reviewed and the 
information requirements, both static and dynamic for this process 
are presented, along with alternative implementation scenarios that 
could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. 
This memo does NOT address optical impairments in any depth and 
focuses on topological elements and path selection constraints that 
are common across different WSON environments.  It is expected that a 
variety of different techniques will be applied to optical 
impairments depending on the type of WSON, such as access, metro or 
long haul.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rwa-wson-framework-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Wed, 04 Mar 2009 09:31:43 +0000
From: "Shoichiro Seno" <[email-masked]>
To: <[email-masked]>
Subject: New I-D: draft-seno-ccamp-wson-impairment-compensate-cntl-00
Date: Wed, 4 Mar 2009 18:27:08 +0900

Hi CCAMPers, and especially those interested in WSON;

I have submitted a new draft for your consideration: 
draft-seno-ccamp-wson-impairment-compensate-cntl-00.txt.
http://www.ietf.org/internet-drafts/draft-seno-ccamp-wson-impairment-compensate-cntl-00.txt

Please take a look at this I-D, of which abstract is shown below. 
Any comments are welcome.
 
============================================================== 
Abstract:
This memo describes requirements of compensation control of optical 
impairments such as chromatic dispersion for dynamic optical paths, 
as well as automatic discovery of fiber-related impairments over 
links by collaboration of a pair of adjacent nodes upon installation. 
It is intended as a supplement to the wavelength switched optical 
networks (WSON) framework with impairments, because GMPLS-based 
automatic adjustment of impairment compensation and automatic 
discovery of link impairments will improve usability of WSON.
==============================================================

Thank you for your attention.
 
Sho
--
        Shoichiro Seno (E-mail) [email-masked]
        Information Technology R&D Center, Mitsubishi Electric Corporation

Delivery-date: Tue, 03 Mar 2009 18:32:00 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-rwa-wson-encode-01.txt 
Date: Tue,  3 Mar 2009 10:30:01 -0800 (PST)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
	Author(s)       : G. Bernstein
	Filename        : draft-ietf-ccamp-rwa-wson-encode-01.txt
	Pages           : 30
	Date            : 2009-03-03

A wavelength switched optical network (WSON) requires that certain 
key information elements are made available to facilitate path 
computation and the establishment of label switching paths (LSPs). 
The information model described in "Routing and Wavelength Assignment 
Information for Wavelength Switched Optical Networks" shows what 
information is required at specific points in the WSON. 

The information may be used in Generalized Multiprotocol Label 
Switching (GMPLS) signaling protocols, and may be distributed by 
GMPLS routing protocols. Other distribution mechanisms (for example, 
XML-based protocols) may also be used. 

This document provides efficient, protocol-agnostic encodings for the 
information elements necessary to operate a WSON. It is intended that 
protocol-specific documents will reference this memo to describe how 
information is carried for specific uses. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rwa-wson-encode-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Tue, 03 Mar 2009 16:47:16 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-rwa-info-02.txt 
Date: Tue,  3 Mar 2009 08:45:01 -0800 (PST)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
	Author(s)       : G. Bernstein
	Filename        : draft-ietf-ccamp-rwa-info-02.txt
	Pages           : 17
	Date            : 2009-03-03

This document provides a model of information needed by the routing 
and wavelength assignment (RWA) process in wavelength switched 
optical networks (WSONs).  The purpose of the information described 
in this model is to facilitate constrained lightpath computation in 
WSONs, particularly in cases where there are no or a limited number 
of wavelength converters available. This model does not include 
optical impairments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rwa-info-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Tue, 03 Mar 2009 03:37:03 +0000
Date: Tue, 03 Mar 2009 11:36:12 +0800
From: Fatai Zhang <[email-masked]>
Subject: New draft: draft-zhang-ccamp-gmpls-call-extensions-00
To: [email-masked]
Cc: [email-masked], [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_ybdmXTslL77N5s2za9vU9A)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_GGe5X28z5vxiJYnRb0ygQA)"

--Boundary_(ID_GGe5X28z5vxiJYnRb0ygQA)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT

Dear friends,

We just uploaded a new ID (draft-zhang-ccamp-gmpls-call-extensions-00), and the following is the abstract of this new ID.

Please check out the attached document for details.

We would welcome any comments.

=========================================================================
Abstract:

Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are used to support Calls. Although it is stated that these mechanisms are applicable to any environment (including multi-area), the "Call 
Path" is determined hop-by-hop by each "Call Manager" in sequence along the path of the Call. 
  
However, it is desirable to allow the Call-initiator to identify the Call Path explicitly in some cases (especially in the multi-domain 
case). 

This document describes RSVP-TE signaling extensions to allow the Call-initiator to identify the Call Path explicitly when transit 
nodes (besides the Call-initiator and Call-terminator) are involved in these Calls. 

Thanks
 
Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
  ----- Original Message ----- 
  From: IETF I-D Submission Tool 
  To: [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Monday, March 02, 2009 4:03 PM
  Subject: New Version Notification for draft-zhang-ccamp-gmpls-call-extensions-00

  A new version of I-D, draft-zhang-ccamp-gmpls-call-extensions-00.txt has been successfuly submitted by Fatai Zhang and posted to the IETF repository.

  Filename: draft-zhang-ccamp-gmpls-call-extensions
  Revision: 00
  Title: RSVP-TE extensions to GMPLS Calls
  Creation_date: 2009-03-02
  WG ID: Independent Submission
  Number_of_pages: 14

  Abstract:
  Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource 
  ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are 
  used to support Calls. Although it is stated that these mechanisms 
  are applicable to any environment (including multi-area), the "Call 
  Path" is determined hop-by-hop by each "Call Manager" in sequence 
  along the path of the Call. 

   
   However, it is desirable to allow the Call-initiator to identify the 
  Call Path explicitly in some cases (especially in the multi-domain 
  case). 

  This document describes RSVP-TE signaling extensions to allow the 
  Call-initiator to identify the Call Path explicitly when transit 
  nodes (besides the Call-initiator and Call-terminator) are involved 
  in these Calls. 

  Conventions used in this document 

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
  document are to be interpreted as described in RFC-2119 [RFC2119].

  The IETF Secretariat.

--Boundary_(ID_GGe5X28z5vxiJYnRb0ygQA)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: base64

--Boundary_(ID_GGe5X28z5vxiJYnRb0ygQA)--

--Boundary_(ID_ybdmXTslL77N5s2za9vU9A)
Content-type: text/plain; name=draft-zhang-ccamp-gmpls-call-extensions-00.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
 filename=draft-zhang-ccamp-gmpls-call-extensions-00.txt

Network work group                                           Fatai Zhang
Internet Draft                                                    Dan Li 
Intended status: Standards Track                             Jianhua Gao   
Expires: September 2009                                           Huawei 
                                                          March 02, 2009      

                                      
                     RSVP-TE extensions to GMPLS Calls 

                                      
              draft-zhang-ccamp-gmpls-call-extensions-00.txt 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with   
   the provisions of BCP 78 and BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering   
   Task Force (IETF), its areas, and its working groups.  Note that   
   other groups may also distribute working documents as Internet-   
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months   
   and may be updated, replaced, or obsoleted by other documents at any   
   time.  It is inappropriate to use Internet-Drafts as reference   
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at   
   http://www.ietf.org/ietf/1id-abstracts.txt. 

   The list of Internet-Draft Shadow Directories can be accessed at   
   http://www.ietf.org/shadow.html. 

   This Internet-Draft will expire on September 02, 2009. 

Abstract 

   Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource 
   ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are 
   used to support Calls. Although it is stated that these mechanisms 
   are applicable to any environment (including multi-area), the "Call 
   Path" is determined hop-by-hop by each "Call Manager" in sequence 
   along the path of the Call. 

 
 
<Zhang>               Expires September 02, 2009               [Page 1] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   However, it is desirable to allow the Call-initiator to identify the 
   Call Path explicitly in some cases (especially in the multi-domain 
   case). 

   This document describes RSVP-TE signaling extensions to allow the 
   Call-initiator to identify the Call Path explicitly when transit 
   nodes (besides the Call-initiator and Call-terminator) are involved 
   in these Calls. 

Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119 [RFC2119]. 

Table of Contents 

   1. Introduction.................................................2 
   2. Motivation...................................................3 
   3. Solution.....................................................5 
   4. Operations...................................................8 
      4.1. User-Initiated Calls....................................8 
   5. Security Considerations......................................9 
   6. Manageability Considerations.................................9 
   7. IANA Considerations..........................................9 
      7.1. Call_ERO Object.........................................9 
      7.2. Call_RRO Object........................................10 
      7.3. RSVP Error Codes and Error Values......................10 
   8. Normative References........................................10 
   9. Authors' Addresses..........................................12 
   Acknowledgment.................................................12 

1. Introduction 

   The concept of a Generalized Multi-Protocol Label Switching (GMPLS) 
   Call is introduced in [RFC4974]. A Call is an association between 
   endpoints and possibly between key transit points (such as network 
   boundaries) in support of an instance of a service. The requirements 
   of Calls and the RSVT-TE extensions in support of Calls are also 
   described in [RFC4974]. 

   A Call is usually established between end-points to verify polices 
   and authorization applied on these end-points. However, in a multi-
   domain environment, some key polices and authorization are usually 

Zhang                 Expires September 01, 2009               [Page 2] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   deployed on the corresponding domain border nodes (domain ingress or 
   egress nodes), so these border nodes are also involved in processing 
   the Call when the Call is going through these domains. These nodes 
   that process the Call are known as "Call Managers". 

   Although it is stated that the mechanisms proposed in [RFC4974] are 
   applicable to any environment (including multi-area), the "Call Path" 
   is determined hop-by-hop by each Call Manager in sequence along the 
   path of the Call. That is, each Call Manager forwards the Notify 
   message that is used to manage the Call to the next Call Manager 
   along the Call Path. The Notify messages are targeted at (i.e., carry 
   the IP address of) the next Call Manager, and the route that the 
   messages follow through the network to reach the next Call Manager is 
   not important. 

   However, it is desirable to allow the Call-initiator to determine the 
   Call Path and to signal it explicitly in some cases (especially in 
   the multi-domain case). 

   This document describes RSVP-TE signaling extensions to allow the 
   Call-initiator to identify the Call Path explicitly when transit Call 
   Managers (besides the Call-initiator and Call-terminator) are 
   involved in a Call. 

   Note that Call and Connection are separated in the signaling, and 
   Call procedures do not impact the Connection procedures, so this 
   document does not modify any Connection procedures defined in 
   [RFC3471], [RFC3473], [RFC4208], and other existing protocol family. 

2. Motivation 

   In some cases, it is desirable to set up a Call through not only the 
   Call-initiator and Call-terminator, but also some transit Call 
   Manager nodes (e.g., transit border domain nodes) to verify the 
   corresponding polices and authorization applied on these nodes. 

   For instance, in the multi-domain case as shown in Figure 1, there 
   are three interconnected domains. Nodes I, D11, and D12 are in Domain 
   1, and the nodes D11 and D12 are the border nodes. Nodes D21, D22, 
   D23, and D24 are the border nodes of Domain 2, and the internal nodes 
   of Domain 2 are not shown in the figure. Nodes D31, D32, and E are in 
   Domain 3, and the nodes D31 and D32 are the border nodes. 

   Policies and authorization are often applied in domain border nodes, 
   such as the nodes D11, D12, D21, D22, D23, D24, D31, and D32 in this 
   example. Therefore, in this case, when a Call between Call-initiator 
   (node I) and Call-terminator (node E) is going to be setup, the Call 

Zhang                 Expires September 01, 2009               [Page 3] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   should be processed in some domain border nodes (for example, the 
   nodes D11, D21, D23, D31 should process the Call when the Call Path 
   I-D11-D21-D23-D31-E is selected).  

   Note that in this case, there may be several alternative Call Paths 
   between Call-initiator and Call-terminator. For example, in the 
   Figure 1, the possible Call paths may be I-D11-D21-D23-D31-E or I-
   D12-D22-D24-D32-E, or some other path depending on the 
   interconnectivity across the domains.  

       +------------------+  +----------------+  +-----------------+     
       |            +--+  |  |  +--+    +--+  |  |  +--+           |     
       |          --|  |--|--|--|  |----|  |--|--|--|  |--         |     
       |         /  |  |  |  |  |  |    |  |  |  |  |  |  \        |     
       |        /   +--+  |  |  +--+    +--+  |  |  +--+   \       |     
       |  +--+ /     D11  |  |   D21     D23  |  |   D31    \ +--+ |     
       |  |  |-           |  |                |  |           -|  | |     
       |  |  |-           |  |                |  |           -|  | |     
       |  +--+ \    +--+  |  |  +--+    +--+  |  |  +--+    / +--+ |     
       |   I    \   |  |  |  |  |  |    |  |  |  |  |  |   /   E   |     
       |         ---|  |--|--|--|  |----|  |--|--|--|  |---        |     
       |            +--+  |  |  +--+    +--+  |  |  +--+           |     
       |             D12  |  |   D22     D24  |  |   D32           |     
       |                  |  |                |  |                 |     
       +------------------+  +----------------+  +-----------------+     
            Domain1               Domain2             Domain3            

                      Figure 1: Multi-domain Scenario 

   Note that how to determine the Call Path is out of the scope of this 
   document.  

   According to the Section 7.3.1 of [RFC 4974], it is already supported 
   that the third parties (i.e., non-end points such as External Call 
   Managers) are involved in the Call, but there is no mechanisms for 
   the Call-initiator to control the Call Path. The Call Path is 
   determined by each Call Manager in turn selecting the next Call 
   Manager on the path to the Call-terminator and forwarding the Notify 
   message that sets up the Call. 

   However, in the case of a multi-domain Call, commercial and policy 
   motivations normally play a role in selecting the Call Path. This 
   selection may be at a coarse level (for example, identifying which 
   domains should or should not be used), or may be at a finer level 
   (for example, identifying which Call Managers to use). Note that 
   there is no concept of specifying links or resources within the Call 

Zhang                 Expires September 01, 2009               [Page 4] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   Path as the Call is an ordered association of Call Managers, and not 
   a data path in the network. 

   Therefore, it is desirable to allow full control for the Call-
   initiator, which means that the Call-initiator can identify the full 
   Call Path explicitly. Moreover, the management plane needs to be able 
   to identify the Call Path explicitly as an instruction to the Call-
   initiator. 

   This document defines protocol extensions that provide a solution for 
   these requirements. 

3. Solution 

   In order to identify the Call Path explicitly for the Call-initiator, 
   the CALL_EXPLICIT_ROUTE object (Call_ERO) is introduced. 

   The format of the Call_ERO is defined as follows: 

   Class = TBD (0bbbbbbb), C_Type = 1 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                        (Subobjects)                         // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The format of the Call_ERO is the same as EXPLICIT_ROUTE object (ERO) 
   described in [RFC3209]. And the subobjects including IPv4 prefix, 
   IPv6 prefix, and autonomous system number defined in [RFC3209] could 
   be reused as subobjects of Call_ERO. 

   In inter-domain environment, it is possible to collect and 
   communicate information about the inter-domain links because the 
   domains usually don't share the Traffic Engineering (TE) information 
   between domains. So Call_RRO and its Link_Capability subobject are 
   introduced to record this information. 

   The format of the Call_RRO is defined as follows: 

   Class = TBD (11bbbbbb), C_Type = 1 

 
Zhang                 Expires September 01, 2009               [Page 5] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

 
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                        (Subobjects)                         // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The format of the Call_RRO is the same as RECORD_ROUTE object (RRO) 
   described in [RFC3209].  

   The subobjects of RRO including IPv4 address and IPv6 address defined 
   in [RFC3209] could be reused as subobjects of Call_RRO and the 
   formats of the subobjects for LINK_CAPABILITY object [RFC4974] 
   including type 1, type 2, type 4, type 64 and type 65 could be reused 
   as Link_Capability subobjects of Call_RRO (Note that the 
   corresponding types are redefined as type 3, type 4, type 5, type 64 
   and type 65).  

   The following subobjects are defined currently: 

      -  Type 1: IPv4 address subobject defined in Section 4.4.1.1 of 
                 [RFC3209]. 

      -  Type 2: IPv6 address subobject defined in Section 4.4.1.2 of 
                 [RFC3209]. 

      -  Type 3: the link local IPv4 address of a link or a numbered 
                 bundle using the format defined in [RFC3209]. 

      -  Type 4: the link local IPv6 address of a link or a numbered 
                 bundle using the format defined in [RFC3209]. 

      -  Type 5: the link local identifier of an unnumbered link or 
                 bundle using the format defined in [RFC3477]. 

      -  Type 64: the Maximum Reservable Bandwidth corresponding to this      
                  link or bundle (see [RFC4201]). 

      -  Type 65: the interface switching capability descriptor (see      
                  [RFC4202]) corresponding to this link or bundle (see 
                  also [RFC4201]). 

 
 
Zhang                 Expires September 01, 2009               [Page 6] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   Similar to the Label RRO [RFC3209], the Link_Capability subobjects 
   are pushed onto the Call_RRO object prior to pushing on the IPv4 or 
   IPV6 subobject. A Call Manager MUST NOT push on a Link_Capability 
   subobject without also pushing on an IPv4 or IPv6 subobject. 

   Note that multiple Link_Capability subobjects following IPv4 or IPv6 
   subobject can be presented in the Call_RRO to collect all the 
   possible link information between domains. 

   The revised Notify message is as follows using the meta-language 
   described in [RBNF]: 

      <Notify message>  ::= <Common Header> [ <INTEGRITY> ] 

                            [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...] 

                            [ <MESSAGE_ID> ] 

                            <ERROR_SPEC> 

                            <notify session list> 

   Where 

      <notify session list> ::= [ <notify session list> ] 

                                <notify session> 

      <notify session>  ::= <SESSION> [ <ADMIN_STATUS> ] 

                            [ <POLICY_DATA>...] 

                            [ <LINK_CAPABILITY> ] 

                            [ <SESSION_ATTRIBUTE> ] 

                            [ <Call_ERO> ] 

                            [ <Call_RRO> ] 

                            [ <sender descriptor> | <flow descriptor> ] 

   And where: 

      <sender descriptor> ::= see [RFC3473] 

      <flow descriptor> ::= see [RFC3473] 

Zhang                 Expires September 01, 2009               [Page 7] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

4. Operations 

   The processes for the revised Notify message comply with the 
   procedures described in [RFC3974] except that the Call_ERO is 
   processed at the Call Managers. The processes for the Call_ERO and 
   Call_RRO are similar to the Connection ERO and RRO [RFC3209].  

   The procedures of Call Setup for the revised Notify message are 
   summarized as follows (other procedures are the same as [RFC3974]): 

   (1)The Call-initiator initiates Call setup and processes the Call 
      locally (e.g., verifies the policy, etc.). After that, it adds 
      the Call_ERO to the Notify message, including the sub-objects to 
      identify the Call Path. If Call_RRO is required, it also should 
      add Call_RRO to the Notify message. Then the Call-initiator sends 
      the Notify message to the first Call Manager indicated by the 
      first sub-object of the Call_ERO (Note that there is no Label 
      _Recording for Call_RRO). 

   (2)The transit Call Managers process the Call when they receive the 
      Notify messages. After that, they remove themselves from the 
      Call_ERO. If Call_RRO is presented in the Notify message, it 
      should also process Call_RRO similar to [RFC3209]. Then it sends 
      the Notify message to the next Call Manager identified by the 
      Call_ERO. 

   (3)Step 2 recurs until the Notify message gets to the Call-
      terminator. And the corresponding Notify message returns to Call-
      initiator in the inverse direction. 

   If, at any time, the Call_ERO is absent or present but empty (for 
   example, when a transit Call Manager removes itself from the 
   Call_ERO), a Call Manager MUST select a next Call Manager on the Call 
   Path toward the Call-terminator (identified in the Session object of 
   the Notify message). This next Call Manager may be another transit 
   Call Manager or may be the Call-terminator itself. The Call Manager 
   MAY create a new Call_ERO if none exists to define hops to the Call-
   terminator, or may add hops to the existing Call_ERO between itself 
   and the next hop in the received Call_ERO. Such actions are subject 
   to local policy. 

4.1. User-Initiated Calls 

   The extensions in this document can also be applied in user-initiated 
   calls, although the example described in this document is about 
   network-initiated Call. Note that, in this case, the first node 
   within the first network domain may be responsible for specifying the 

Zhang                 Expires September 01, 2009               [Page 8] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   Call Path explicitly in the Notify message. The procedures should 
   comply with the description in the Section 7.2 of [RFC 4974]. 

5. Security Considerations 

   The security considerations about Call setup in single domain are 
   described in [RFC 4974]. In the case of multi-domain environment, the 
   security about Call is similar to that of Connection which is 
   described in [RFC 5151]. Therefore, please refer to the corresponding 
   Security Consideration sections in [RFC 4974] and [RFC 5151] to take 
   into account the security issues. 

6. Manageability Considerations 

   The mechanisms defined in this document call upon the use of policy 
   at Call Managers. Such policy SHOULD be available for configuration 
   by the operator either directly acting on the Call Manager or through 
   a policy server. Important information for the application of policy 
   is carried in the Call establishment messages (Notify messages) in 
   the Session, Session_Attributes, Sender_Template, Link_Capability, 
   and Policy_Data objects. 

   The mechanism used to determine the entire Call Path or next Call 
   Manager in a Call Path is beyond the scope of this document. One 
   solution is to allow configuration of the Call Path from the operator 
   as part of the service request (just as the explicit path of a label 
   switched path (LSP) can be specified by the operator). 

   Operators will expect to be able to inspect Call Managers and 
   determine for which Calls they are initiator, transit, or terminator. 
   Furthermore, they will expect to be able to inspect a Call at any 
   Call Manager that it uses, and determine all information about the 
   Call including its Call Path. 

7. IANA Considerations 

   This document introduces two new classes named Call_ERO and Call_RRO. 

7.1. Call_ERO Object  

   Class-Num = TBD (0bbbbbbb) 

   C-Type=1 (Call_ERO) 

   The Call_ERO object is only used for Call messages in Notify messages. 

   Subobjects of the Call_ERO object with C-Type 1: 

Zhang                 Expires September 01, 2009               [Page 9] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

             1       IPv4 prefix 

             2       IPv6 prefix 

            32       Autonomous system number 

7.2. Call_RRO Object  

   Class-Num = TBD (11bbbbbb) 

   C-Type=1 (Call_RRO) 

   The Call_RRO object is only used for Call messages in Notify messages. 

   The subobjects of Call_RRO are defined in Section 3 of this document. 

7.3. RSVP Error Codes and Error Values 

   The Call message (Notify message) should be rejected when any Call 
   Manager which receives the Call message including Call_ERO does not 
   recognize the Call_ERO. 

      o  Error Codes: 

         - Call Management (value 32) 

      o  Error Values: 

         - Call Management/Unknown Call_ERO      (value=TBD) 

8. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC4974] D. Papadimitriou, A. Farrel, "Generalized MPLS (GMPLS) 
             RSVP-TE Signaling Extensions in Support of Calls ", RFC 
             4974, August 2007. 

            [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T.,                    
             Srinivasan, V.  and G. Swallow, "RSVP-TE: Extensions               
             to RSVP for LSP Tunnels", RFC 3209, December 2001. 

 
 
Zhang                 Expires September 01, 2009              [Page 10] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 
             (GMPLS) Signaling Functional Description", RFC 3471, 
             January 2003. 

   [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 
             Switching (GMPLS) Signaling Resource ReserVation Protocol-
             Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 
             January 2003. 

   [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 
             "Generalized Multiprotocol Label Switching (GMPLS) User- 
             Network Interface (UNI): Resource ReserVation Protocol- 
             Traffic Engineering (RSVP-TE) Support for the Overlay 
             Model", RFC 4208, October 2005. 

   [RFC5151] A. Farrel, A. Ayyangar, JP. Vasseur, "Inter-Domain MPLS and 
             GMPLS Traffic Engineering-Resource Reservation Protocol-
             Traffic Engineering (RSVP-TE) Extensions", RFC 5151, 
             February 2008. 

   [RBNF]    Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used 
             in Various Protocol  Specifications", draft-farrel-rtg-
             common-bnf, work in progress. 

 
 
Zhang                 Expires September 01, 2009              [Page 11] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

9. Authors' Addresses

   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912
   Email: [email-masked]

   Dan Li
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28973237
   Email: [email-masked]

   Jianhua Gao
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912
   Email: [email-masked]

Acknowledgment 

   TBD. 

Intellectual Property 
 
   The IETF Trust takes no position regarding the validity or scope of   
   any Intellectual Property Rights or other rights that might be   
   claimed to pertain to the implementation or use of the technology   
   described in any IETF Document or the extent to which any license   
   under such rights might or might not be available; nor does it   
   represent that it has made any independent effort to identify any   
   such rights. 

 
Zhang                 Expires September 01, 2009              [Page 12] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   Copies of Intellectual Property disclosures made to the IETF   
   Secretariat and any assurances of licenses to be made available, or   
   the result of an attempt made to obtain a general license or   
   permission for the use of such proprietary rights by implementers or   
   users of this specification can be obtained from the IETF on-line IPR   
   repository at http://www.ietf.org/ipr 

   The IETF invites any interested party to bring to its attention any   
   copyrights, patents or patent applications, or other proprietary   
   rights that may cover technology that may be required to implement   
   any standard or specification contained in an IETF Document. Please   
   address the information to the IETF at [email-masked]. 

   The definitive version of an IETF Document is that published by, or   
   under the auspices of, the IETF. Versions of IETF Documents that are   
   published by third parties, including those that are translated into   
   other languages, should not be considered to be definitive versions   
   of IETF Documents. The definitive version of these Legal Provisions   
   is that published by, or under the auspices of, the IETF. Versions of   
   these Legal Provisions that are published by third parties, including   
   those that are translated into other languages, should not be   
   considered to be definitive versions of these Legal Provisions. 

   For the avoidance of doubt, each Contributor to the IETF Standards   
   Process licenses each Contribution that he or she makes as part of   
   the IETF Standards Process to the IETF Trust pursuant to the   
   provisions of RFC 5378. No language to the contrary, or terms,   
   conditions or rights that differ from or are inconsistent with the   
   rights and licenses granted under RFC 5378, shall have any effect and   
   shall be null and void, whether published or posted by such   
   Contributor, or included with or in such Contribution. 

Disclaimer of Validity 
 
   All IETF Documents and the information contained therein are provided   
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE   
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE   
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL   
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY   
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE   
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS   
   FOR A PARTICULAR PURPOSE. 

Full Copyright Statement 

 
Zhang                 Expires September 01, 2009              [Page 13] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

 
   Copyright (c) 2009 IETF Trust and the persons identified as the   
   document authors. All rights reserved. 

   This document is subject to BCP 78 and the IETF Trust's Legal   
   Provisions Relating to IETF Documents in effect on the date of   
   publication of this document (http://trustee.ietf.org/license-info).   
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document. 

 
 
Zhang                 Expires September 01, 2009              [Page 14] 


--Boundary_(ID_ybdmXTslL77N5s2za9vU9A)--

Delivery-date: Tue, 03 Mar 2009 03:14:02 +0000
Date: Tue, 03 Mar 2009 11:11:12 +0800
From: Fatai Zhang <[email-masked]>
Subject: New draft: draft-zhang-ccamp-rwa-wson-routing-ospf-00
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], Zhang Fatai <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_/UOBwo4WKxGF8cgOyNyh8A)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_oSz0wJ4sE3R7eJNY27Iwxg)"

--Boundary_(ID_oSz0wJ4sE3R7eJNY27Iwxg)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT

Dear CCAMPers,

We just posted a new I-D: draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt.

Following the work on the RWA problem in the existing CCAMP drafts, and working with the protocol-independent encodings defined in   draft-ietf-ccamp-rwa-wson-encode, we have started work on OSPF extensions.  This work is at an early stage and we expect to revise the document over the next months. 

Any comments are welcome.

The following is the abstract of this new I-D, please check out the attachment for details.

=========================================================================
Abstract 

Wavelength switched optical networks (WSONs) are based on Wavelength Division Multiplexing (WDM) in which user traffic is carried by data channels of different optical wavelengths. In traditional WDM Networks, each wavelength path is statically configured. With the  deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), photonic cross-connects (PXCs), and tunable laser, WSONs have become more dynamic, and operators can flexibly set up wavelength paths to carry user traffic.

In WSONs where there are no or a limited number of switches capable of wavelength conversion paths must be set up subject to the wavelength continuity" constraint. This leads to a path computation problem known as routing and wavelength assignment (RWA). In order to 
perform such computations, it is necessary to collect information about the available wavelengths within the network. 

This document describes OSPF routing protocols extensions to support Wavelength Switched Optical Networks (WSON) under the control of 
Generalized MPLS (GMPLS). 

Thanks
 
Fatai 
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
  ----- Original Message ----- 
  From: IETF I-D Submission Tool 
  To: [email-masked] 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Monday, March 02, 2009 3:47 PM
  Subject: New Version Notification for draft-zhang-ccamp-rwa-wson-routing-ospf-00

  A new version of I-D, draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt has been successfuly submitted by Fatai Zhang and posted to the IETF repository.

  Filename: draft-zhang-ccamp-rwa-wson-routing-ospf
  Revision: 00
  Title: OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs)
  Creation_date: 2009-03-02
  WG ID: Independent Submission
  Number_of_pages: 17

  Abstract:
  Wavelength switched optical networks (WSONs) are based on Wavelength 
  Division Multiplexing (WDM) in which user traffic is carried by data 
  channels of different optical wavelengths. In traditional WDM 
  Networks, each wavelength path is statically configured. With the 

   deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), 
  photonic cross-connects (PXCs), and tunable laser, WSONs have become 
  more dynamic, and operators can flexibly set up wavelength paths to 
  carry user traffic.

  In WSONs where there are no or a limited number of switches capable 
  of wavelength conversion paths must be set up subject to the 
  "wavelength continuity" constraint. This leads to a path computation 
  problem known as routing and wavelength assignment (RWA). In order to 
  perform such computations, it is necessary to collect information 
  about the available wavelengths within the network. 

  This document describes OSPF routing protocols extensions to support 
  Wavelength Switched Optical Networks (WSON) under the control of 
  Generalized MPLS (GMPLS). 

  Conventions used in this document 

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
  document are to be interpreted as described in RFC-2119 [RFC2119].

  The IETF Secretariat.

--Boundary_(ID_oSz0wJ4sE3R7eJNY27Iwxg)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: base64

--Boundary_(ID_oSz0wJ4sE3R7eJNY27Iwxg)--

--Boundary_(ID_/UOBwo4WKxGF8cgOyNyh8A)
Content-type: text/plain; name=draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
 filename=draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt

Network work group                                           Fatai Zhang 
Internet Draft                                                    Huawei 
Intended status: Standards Track                            G. Bernstein    
Expires: September 2009                                Grotto Networking
                                                               Young Lee  
                                                                  Dan Li
                                                             Jianrui Han 
                                                                  Huawei 
                                                          March 02, 2009 

                                      
            OSPF Extensions in Support of Routing and Wavelength 
      Assignment (RWA) in Wavelength Switched Optical Networks (WSONs) 

                                      
              draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with   
   the provisions of BCP 78 and BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering   
   Task Force (IETF), its areas, and its working groups.  Note that   
   other groups may also distribute working documents as Internet-   
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months   
   and may be updated, replaced, or obsoleted by other documents at any   
   time.  It is inappropriate to use Internet-Drafts as reference   
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at   
   http://www.ietf.org/ietf/1id-abstracts.txt. 

   The list of Internet-Draft Shadow Directories can be accessed at   
   http://www.ietf.org/shadow.html. 

   This Internet-Draft will expire on September 02, 2009. 

Abstract 

   Wavelength switched optical networks (WSONs) are based on Wavelength 
   Division Multiplexing (WDM) in which user traffic is carried by data 
   channels of different optical wavelengths. In traditional WDM 
   Networks, each wavelength path is statically configured. With the 

 
<Zhang>               Expires September 2, 2009               [Page 1] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), 
   photonic cross-connects (PXCs), and tunable laser, WSONs have become 
   more dynamic, and operators can flexibly set up wavelength paths to 
   carry user traffic.   

   In WSONs where there are no or a limited number of switches capable 
   of wavelength conversion paths must be set up subject to the 
   "wavelength continuity" constraint. This leads to a path computation 
   problem known as routing and wavelength assignment (RWA). In order to 
   perform such computations, it is necessary to collect information 
   about the available wavelengths within the network. 

   This document describes OSPF routing protocols extensions to support 
   Wavelength Switched Optical Networks (WSON) under the control of 
   Generalized MPLS (GMPLS). 

Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119 [RFC2119]. 

Table of Contents 

   1. Introduction.................................................3 
   2. Node Information.............................................3 
      2.1. Connectivity Matrix.....................................4 
         2.1.1. Link Set...........................................5 
      2.2. Wavelength Converter Pool Information...................7 
   3. Link Information.............................................7 
      3.1. WSON Port Wavelength Restrictions.......................8 
      3.2. Wavelength Availability Information.....................9 
      3.3. Shared Backup Wavelengths..............................11 
   4. Procedures for Routing Flooding.............................11 
   5. Security Considerations.....................................12 
   6. IANA Considerations.........................................12 
      6.1. Node Information.......................................12 
      6.2. Link Information.......................................12 
   7. References..................................................12 
   8. Authors' Addresses..........................................15 
   Acknowledgment.................................................16 

 
 
Zhang                  Expires September 2009                 [Page 2] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

1. Introduction 

   Wavelength switched optical networks (WSONs) are based on Wavelength 
   Division Multiplexing (WDM) in which user traffic is carried by data 
   channels of different optical wavelengths. In traditional WDM 
   Networks, each wavelength path is statically configured. With the 
   deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), 
   photonic cross-connects (PXCs), and tunable laser, WSONs have become 
   more dynamic, and operators can flexibly set up wavelength paths to 
   carry user traffic.  

   In WSONs where there are no or a limited number of switches capable 
   of wavelength conversion paths must be set up subject to the 
   "wavelength continuity" constraint. This leads to a path computation 
   problem known as routing and wavelength assignment (RWA). In order to 
   perform such computations, it is necessary to collect information 
   about the available wavelengths within the network. 

   [WSON-Frame] provides a framework for applying GMPLS [RFC3945] and 
   the Path Computation Element (PCE) architecture [RFC4655] to the 
   control of WSONs to address the RWA problem. [WSON-Info] describes an 
   information model that specifies the information needed at various 
   points in a WSON in order to compute paths and establish Label 
   Switched Paths (LSPs). Based on the information model of [WSON-Info], 
   [WSON-Encode] provides efficient protocol-independent encodings of 
   the information needed by the RWA process in a WSON. Such encodings 
   can be used to extend GMPLS signaling and routing protocols.    

   Therefore, in order to enable GMPLS to control WSON networks, this 
   document follows on from [WSON-Info], [WSON-Encode], and [WSON-IGP-
   Eval] to define extensions to the OSPF routing protocol to enhance 
   the Traffic Engineering (TE) properties of GMPLS TE which are defined 
   in [RFC3630], [RFC4202], and [RFC4203]. 

   No consideration of optical impairment routing related information is 
   included in this document. 

2. Node Information 

   According to [WSON-Info] and [WSON-Encode], the node information 
   about WSON nodes includes Node ID, connectivity matrix, wavelength 
   converter pool information. Except for the Node ID which should 
   comply with Routing Address described in [RFC3630], the other pieces 
   of information are defined in this document. 

   [OSPF-Node] defines a new top TLV named the Node Attribute TLV which 
   carries attributes related to a router/node. Connectivity matrix, 

Zhang                  Expires September 2009                 [Page 3] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   wavelength converter pool information are attributes associated with 
   a WSON node, so this document defines the following sub-TLVs of Node 
   Attribute TLV: 

   (1)Connectivity matrix sub-TLV 

   (2)Wavelength converter pool information sub-TLV 

2.1. Connectivity Matrix 

   Unlike the packet and TDM networks whose switching devices are 
   symmetric, the switching devices in a WSON are highly asymmetric. 
   Therefore, it is necessary to identify which ingress ports and 
   wavelengths can be connected to (the same wavelength on) a specific 
   egress port. Detailed descriptions of the Connectivity Matrix can be 
   found in the corresponding sections of [WSON-Info] and [WSON-Encode]. 

   The Connectivity Matrix TLV is a sub-TLV (the type is TBD by IANA) of 
   the Node Attribute TLV. The format of this sub-TLV is defined as 
   follows: 

       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Connectivity  |              Reserved                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        Link Set A #1                          | 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        Link Set B #1                          | 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     Additional Link set pairs as needed       | 
      :                     to specify connectivity                   : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Type = TBD 

   Connectivity : 8 bits 

       The following values are currently defined. All other values are 
   reserved and SHOULD be transmitted as zero and ignored on receipt. 

       0x01: Fixed Connectivity Matrix 

Zhang                  Expires September 2009                 [Page 4] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

       Indicates that the switching element is a kind of fixed switching 
   device, so the connectivity matrix represents the potential 
   connectivity matrix. This applies to asymmetric fixed devices or to 
   the fixed part of a "hybrid" device [Switch]. 

       0x02: Switched Connectivity Matrix 

       Indicates that the switching element is a kind of switched device 
   (e.g., ROADM or OXC). The connectivity matrix represents the 
   potential connectivity matrix for an asymmetric switch. 

   Reserved: 24 bits 

       This field is reserved. It SHOULD be set to zero on transmission 
   and MUST be ignored on receipt. 

   Link Set: At least one Link Set MUST be present. Multiple Link Sets 
   MAY be present. Each one has variable length. The Link set is defined 
   in Section 2.2.1.. 

2.1.1. Link Set   

       Link Set identifies a link group and is defined as follows: 

       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    Action     |Dir|  Format   |    Num Links  |    Reserved   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                       Link Identifier 1                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      :                               :                               : 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                       Link Identifier N                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The Link Set is not a kind of sub-TLV and it is just a part of the 
   Connectivity Matrix TLV. (Note that this construct may be reused in 
   the Wavelength Converter Pool information in Section 2.3 in a future 
   version of this document.) 

   Action: 8 bits 

       The following values are currently defined. All other values are 
   reserved.   

Zhang                  Expires September 2009                 [Page 5] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

       0x01: Inclusive List 

       Indicates that one or more link identifiers are included in the 
   Link Set. Each identifies a separate link that is part of the set. 

       0x02: Inclusive Range 

       Indicates that the Link Set defines a range of links.  It 
   contains two link identifiers. The first identifier indicates the 
   start of the range (inclusive). The second identifier indicates the 
   end of the range (inclusive). All links with numeric values between 
   the bounds are considered to be part of the set. A value of zero in 
   either position indicates that there is no bound on the corresponding 
   portion of the range. Note that the Action field could be set to 
   0x02(Inclusive Range) only when unnumbered link identifier is used. 

   Directionality of the Link Set (Dir): 2 bits 

       The following values are currently defined. All other values are 
   reserved.   

       0x01: Bidirectional 

       Indicates that the links in the Link Set are bidirectional. 

      0x02: Incoming 

       Indicates that the links in the Link Set are from the incoming 
   direction with respect to the node advertising the information. 

      0x03: Outgoing 

       Indicates that the links in the Link Set are to the outgoing 
   direction with respect to the node advertising the information. 

   Format: 6 bits 

   This field identifies the format of the link identifier. The 
   following values are currently defined. All other values are reserved. 

      0x01: Link Local Identifier with IPv4 address 

       Indicates that the links in the Link Set are identified by link 
   local identifiers which are IPv4 numbered. All link local identifiers 
   are supplied in the context of the advertising node. 

      0x02: Link Local Identifier with unnumbered interface 

Zhang                  Expires September 2009                 [Page 6] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

       Indicates that the links in the Link Set are identified by link 
   local identifiers which are unnumbered interface IDs. All link local 
   identifiers are supplied in the context of the advertising node. 

   Num Links: 8 bits 

   This field indicates the total number of the links in the Link Set. 

   Reserved: 8 bits  

       This field is reserved. It MUST be set to zero on transmission 
   and MUST be ignored on receipt.  

   Link Identifier: 32 bits for each link 

      If the Format field is set to 0x01 (Link Local Identifier with 
   IPv4 address), the link identifier is the interface IP address used 
   to identify the incoming or outgoing port corresponding to the link. 
   The format of the Link Identifier should comply with the format of 
   the Local/Remote Interface IP Address described in [RFC3630].  

       If the Format field is set to 0x02 (Link Local Identifier with 
   unnumbered interface), the link identifier is unnumbered. 

   An example about Connectivity Matrix representation could be referred 
   to the Section 3.2 of [WSON-Encode]. 

2.2. Wavelength Converter Pool Information 

     TBD. 

3. Link Information 

   The most common link sub-TLVs are already defined in [RFC3630], 
   [RFC4203]. For example, Link ID, Administrative Group, Interface 
   Switching Capability Descriptor (ISCD), Link Protection Type, Shared 
   Risk Link Group Information (SRLG), and Traffic Engineering Metric.  

   For WSONs, per [WSON-Info] and [WSON-Encode], the following 
   additional link sub-TLVs are defined in this document. 

   (1) WSON Port Wavelength Restrictions sub-TLV 

   (2) Wavelength Availability sub-TLV 

   (3) Shared Backup Wavelengths sub-TLV 

 
Zhang                  Expires September 2009                 [Page 7] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

3.1. WSON Port Wavelength Restrictions 

   In WSONs, there may be wavelength restrictions on a link or port. For 
   example, a WSON link might only be able to support switching some 
   specific wavelengths. These restrictions are distributed by OSPF to 
   be convenient for wavelength path computation. 

   The WSON Port Wavelength Restrictions TLV is a sub-TLV (the type is 
   TBD by IANA) of the Link TLV. The format of this sub-TLV is defined 
   as follows: 

       0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |RestrictionKind|T|  Reserved   |       MaxNumChannels          | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
     |                     Wavelength Set                            |  
     |                      (variable)                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
   Type = TBD 

   RestrictionKind: 8 bits 

       The following values are currently defined. All other values are 
   reserved.   

       0x01: Simple wavelength selective restriction 

       In this case, MaxNumChannels indicates the maximum number of 
   wavelengths permitted on the port, and the accompanying Wavelength 
   Set indicates the specific permitted wavelengths. 

       0x02: Waveband device with a tunable center frequency and 
   passband. 

       In this case, MaxNumChannels indicates the maximum width of the 
   waveband in terms of the channels spacing given in the Wavelength Set. 
   The corresponding wavelength set is used to indicate the overall 
   tuning range. Specific center frequency tuning information can be 
   obtained from dynamic channel in use information. 

   MaxNumChannels indicates the maximum number of channels supported on 
   the port/waveband dependent on the setting of the RestrictionKind 
   field. 

 
 
Zhang                  Expires September 2009                 [Page 8] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   Wavelength Set information is carried as defined in Section 3.4 of 
   [WSON-Encode]. 

3.2. Wavelength Availability Information 

   The requirements for a global semantic for wavelength labels and the 
   corresponding standardized wavelength label can be found in [Lambda-
   Labels]. 

   Because the wavelength continuity along the wavelength Label Switched 
   Path (LSP) should be ensured without wavelength conversion or with 
   wavelength conversion at some switches along the path, the 
   information about wavelength availability and wavelength connectivity 
   is very important when computing a wavelength LSP. For example, if 
   the wavelength label range [lambda 1, lambda 5] of fiber 1 can be 
   connected to the same wavelength label range of fiber 2, but only 
   lambda 3 is available on fiber 2 because other wavelength labels are 
   occupied, lambda 3 must be selected on fiber 1.  

   If the wavelength availability information is not known by the node    
   performing the path computation, then the computation can only be   
   performed at the level of TE links, and wavelength assignment must be   
   resolved locally by the switches on a hop-by-hop basis enhanced by   
   signaling protocol mechanisms used to negotiate label selection.   
   However, this case may be very inefficient in the signaling protocol,   
   and can easily lead to blocking problems where a path is selected for   
   which there is no suitable wavelength availability, unless some or   
   all of the switches along the path are capable of full wavelength   
   conversion. In the general case of limited or no wavelength   
   conversion, information on wavelength availability is essential to    
   perform efficient and accurate path computation.  

   It is possible to consider reporting the statuses of each wavelength 
   on a link using implicit wavelength identification based on the link-
   local knowledge of wavelengths supported and a well-known sequence. 
   However, this information would be of no use in a wider context (i.e., 
   away from the link ends). On the other hand, if the standardized 
   label format described in [Lambda-Labels] is used to identify every 
   wavelength when its status is reported, the wavelength information 
   will be a little larger (or the order of one wavelength label per 
   status advertised). This may have a significant affect on the total 
   information advertised in a network because a WSON link often 
   supports many wavelengths (e.g., 80 or 160 wavelength systems).  

   To minimize the size of information, a bitmap wavelength set is 
   defined in [WSON-Encode] to indicate the wavelength availability 
   information for a fiber, i.e., only one bit is used to indicate the 

Zhang                  Expires September 2009                 [Page 9] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   status of a certain wavelength (the wavelength is either available or 
   not available).   

   Note that there are five approaches for Wavelength Set which is used 
   to represent the wavelength availability information described in 
   Section 3.4 of [WSON-Encode]. Considering that the continuity of the 
   available or unavailable wavelength set can be scattered for the 
   dynamic wavelength availability, so it may burden the routing to 
   reorganize the wavelength set information when the Inclusive 
   (/Exclusive) List (/Range) approaches are used to represent 
   wavelength availability information. Therefore, it is RECOMMENDED 
   that only the Bitmap Set be used for representation wavelength 
   availability information as follows. 

   The Wavelength Availability  TLV is a sub-TLV (the type is TBD by 
   IANA) of the Link TLV. The format of this sub-TLV is defined as 
   follows: 

       0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |          Num Wavelengths      |         Reserved              | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |Grid |  C.S. |     Reserved    |    n  for lowest frequency    | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |    Bit Map Double-word #1 (Lowest frequency channels)         | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     :                                                               : 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |Bit Map Double-word #N (Highest frequency channels)|Padded bits| 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Type = TBD 

   The three fields (Grid, C.S. and n) are defined in [Lambda-Label]. 

   Num Wavelengths: 8 bits 

       Indicates the number of the wavelengths represented by the bit 
   map.  

   Each bit in the bit map represents a particular frequency with a 
   value of 1/0 indicating whether the frequency is available or not. 
   Bit position zero represents the lowest frequency, while each 
   succeeding bit position represents the next frequency a channel 
   spacing (C.S.) above the previous. The values of the bit map are 
   defined as follows: 

Zhang                  Expires September 2009                [Page 10] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

       1 = Available  

       0 = Assigned (in use, or failed, or administratively down, or 
   under testing)  

   The valid length of the bit map is clearly Num Wavelengths bits, but 
   the bit map should be padded to make the whole number of the bits in 
   bitmap be the time of 32 bits so that the TLV is a multiple of four 
   bytes. Padded bit SHOULD be set to 0 and MUST be ignored. 

   Bits that do not represent wavelengths (i.e., those in positions (Num 
   Wavelengths - 1) and beyond) SHOULD be set to zero and MUST be 
   ignored.  

3.3. Shared Backup Wavelengths 

   TBD. 

4. Procedures for Routing Flooding 

   The advertisement for the node attributes SHOULD comply with the 
   procedures described in [OSPF-Node]. 

   In the WSON networks, the node information can be classified as two 
   kinds: one is static information comparatively such as Node ID, 
   Connectivity Matrix information; the other is dynamic information 
   such as Wavelength Converter Pool Status information. For the static 
   node information, the router announces the static node information in 
   the node attribute TLV which could be advertised during the node 
   starts or periodically for some configurable time (e.g., per hour or 
   several hours). For the dynamic node information, the router 
   announces this information in the separate node attribute TLV which 
   SHOULD be advertised during node starts or when the corresponding 
   node information is changed. 

   For the WSON link information, the procedures for the routing 
   flooding SHOULD comply with [RFC3630], [RFC4203] and the other 
   existing family standards, and there is no extended process for the 
   link attributes advertisement, except that some link sub-TLVs are 
   defined in this document. 

   Note that as with other TE information, an implementation SHOULD take 
   measures to avoid rapid and frequent updates of routing information 
   that could cause the routing network to become swamped. A threshold 
   mechanism MAY be applied such that updates are only flooded when a 

Zhang                  Expires September 2009                [Page 11] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   number of changes have been made to the wavelength availability 
   information within a specific time. Such mechanisms MUST be 
   configurable if they are implemented. 

5. Security Considerations 

   This document does not introduce any further security issues other   
   than those discussed in [RFC 3630], [RFC 4203]. 

6. IANA Considerations 

   [RFC3630] says that the top level Types in a TE LSA and Types for 
   sub-TLVs for each top level Types must be assigned by Expert Review, 
   and must be registered with IANA. 

   IANA is requested to allocate new Types for the sub-TLVs as defined 
   in Sections 2.1, 3.1, and 3.2 as follows: 

6.1. Node Information 

   This document introduces the following sub-TLV of Node Attribute TLV 
   (Value TBD, see [OSPF-Node]) 

   Type   sub-TLV 

   TBD    Connectivity matrix 

6.2. Link Information 

   This document introduces the following sub-TLV of TE Link TLV (Value 
   2) 

   Type   sub-TLV 

   TBD    WSON Port Wavelength Restrictions 

   TBD    Wavelength Availability 

7. References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 
             (GMPLS) Signaling Functional Description", RFC 3471, 
             January 2003. 

 
Zhang                  Expires September 2009                [Page 12] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic                   
             Engineering (TE) Extensions to OSPF Version 2", RFC                
             3630, September 2003. 

   [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 
             in Support of Generalized Multi-Protocol Label Switching 
             (GMPLS)", RFC 4202, October 2005 

   [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 
             Support of Generalized Multi-Protocol Label Switching 
             (GMPLS)", RFC 4203, October 2005.  

   [RFC3945] E. Mannie, Ed., "OGeneralized Multi-Protocol Label Switching (GMPLS) 
             Architecture", RFC 3945, October 2004.  

   [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path               
             Computation Element (PCE)-Based Architecture ", RFC 4655, 
             August 2006.  

   [OSPF-Node] R. Aggarwal and K. Kompella, "Advertising a Router's             
               Local Addresses in OSPF TE Extensions", draft-ietf-ospf-          
               te-node-addr, work in progress. 

   [Lambda-Labels] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, 
                    "Generalized Labels for G.694 Lambda-Switching 
                    Capable Label Switching Routers", work in progress: 
                    draft-ietf-ccamp-gmpls-g-694-lambda-labels-03.txt, 
                    January 2009. 

   [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS 
                and PCE Control of Wavelength Switched Optical 
                Networks", work in progress: draft-ietf-ccamp-rwa-WSON-
                Framework-00.txt, December 2008. 

   [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 
               Wavelength Assignment Information Model for Wavelength 
               Switched Optical Networks", work in progress: draft-ietf-
               ccamp-rwa-info-01.txt, October 2008. 

   [WSON-Encode]                     G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 
                Wavelength Assignment Information Encoding for 
                Wavelength Switched Optical Networks", work in progress: 
                draft-ietf-ccamp-rwa-wson-encode-00.txt, December 2008. 

 
 
Zhang                  Expires September 2009                [Page 13] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   [WSON-IGP-Eval] Dan Li, J. Gao, Y. Lee, "Evaluation of Possible 
                    Interior Gateway Protocol Extensions for Wavelength 
                    Switching Optical Networks", work in progress: 
                    draft-li-ccamp-wson-igp-eval-01.txt, July 2008. 

    [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling         
             WDM Wavelength Switching Systems for use in Automated Path 
             Computation", http://www.grotto-   
             networking.com/wson/ModelingWSONswitchesV2a.pdf , June, 
             2008 

    

 
 
Zhang                  Expires September 2009                [Page 14] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

8. Authors' Addresses

   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912 
   Email: [email-masked]

   Greg Bernstein
   Grotto Networking 
   Fremont CA, USA 

   Phone: (510) 573-2237 
   Email: [email-masked]

   Young Lee
   Huawei Technologies
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   USA

   Phone: (972) 509-5599 (x2240)
   Email: [email-masked]

   Dan Li
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China
    
   Phone: +86-755-28973237
   Email: [email-masked]

   Jianrui Han
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

 
Zhang                  Expires September 2009                [Page 15] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   Phone: +86-755-28972913
   Email: [email-masked]
    
Acknowledgment 

   TBD. 
 
Intellectual Property 
 
   The IETF Trust takes no position regarding the validity or scope of   
   any Intellectual Property Rights or other rights that might be   
   claimed to pertain to the implementation or use of the technology   
   described in any IETF Document or the extent to which any license   
   under such rights might or might not be available; nor does it   
   represent that it has made any independent effort to identify any   
   such rights. 

   Copies of Intellectual Property disclosures made to the IETF   
   Secretariat and any assurances of licenses to be made available, or   
   the result of an attempt made to obtain a general license or   
   permission for the use of such proprietary rights by implementers or   
   users of this specification can be obtained from the IETF on-line IPR   
   repository at http://www.ietf.org/ipr 

   The IETF invites any interested party to bring to its attention any   
   copyrights, patents or patent applications, or other proprietary   
   rights that may cover technology that may be required to implement   
   any standard or specification contained in an IETF Document. Please   
   address the information to the IETF at [email-masked]. 

   The definitive version of an IETF Document is that published by, or   
   under the auspices of, the IETF. Versions of IETF Documents that are   
   published by third parties, including those that are translated into   
   other languages, should not be considered to be definitive versions   
   of IETF Documents. The definitive version of these Legal Provisions   
   is that published by, or under the auspices of, the IETF. Versions of   
   these Legal Provisions that are published by third parties, including   
   those that are translated into other languages, should not be   
   considered to be definitive versions of these Legal Provisions. 

   For the avoidance of doubt, each Contributor to the IETF Standards   
   Process licenses each Contribution that he or she makes as part of   
   the IETF Standards Process to the IETF Trust pursuant to the   
   provisions of RFC 5378. No language to the contrary, or terms,   
   conditions or rights that differ from or are inconsistent with the   
   rights and licenses granted under RFC 5378, shall have any effect and   

 
Zhang                  Expires September 2009                [Page 16] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   shall be null and void, whether published or posted by such   
   Contributor, or included with or in such Contribution. 

Disclaimer of Validity 
 
   All IETF Documents and the information contained therein are provided   
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE   
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE   
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL   
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY   
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE   
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS   
   FOR A PARTICULAR PURPOSE. 

Full Copyright Statement 
 
   Copyright (c) 2009 IETF Trust and the persons identified as the   
   document authors. All rights reserved. 

   This document is subject to BCP 78 and the IETF Trust's Legal   
   Provisions Relating to IETF Documents in effect on the date of   
   publication of this document (http://trustee.ietf.org/license-info).   
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document. 

 
 
Zhang                  Expires September 2009                [Page 17] 


--Boundary_(ID_/UOBwo4WKxGF8cgOyNyh8A)--

Delivery-date: Sun, 01 Mar 2009 20:03:58 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, <[email-masked]>
Subject: Re: Chair review of draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt
Date: Sun, 1 Mar 2009 20:02:16 -0000

And finally...

>> Section 3.2
>>
>> Subchannel: Variable
>>
>> See [RFC3471] for a description of this field. Note that this
>> field may not be 32 bit aligned.
>>
>> I think it is worth highlighting the context for the meaning and the
>> length of the subchannel ID
>>
> can you be more specific? I don't understand what you are asking for.

Yeah, OK, I didn't go and read the reference. Sorry.

>> Section 3.3
>>
>> Don't you think it is a layer of complexity too far to have a Label Set
>> made up of a set of Channel_Set Labels each made up of a series of
>> Channel_Set subobjects each made up of a set of channels?
>
> yes, this is a tad excessive.  I'm not sure why anyone would construct 
> such an object though...

Let's get rid of options.
It makes the code easier to write. Just because you don't create the object, 
doesn't mean you don't have to parse it.

See below...

>> What on earth is the meaning of the Label Set if the action is set to
>> "inclusive range" or "exclusive range" and the label entries are
>> Channel_Set labels? What if the Label Set says "inclusive list" and one
>> of the Channel_Set subobjects says "exclusive list", or the other way
>> around.
>
> nothing that can't be represented with some nice logical expressions.

This problem goes away if you make the restriction I suggest below...

>> Perhaps you can set some limits on the action field in the Label Set etc?
>
> Do you have a suggestions?

Label_Set and Acceptable_Label_Set objects SHOULD NOT contain more than one 
Channel_Set Label, and when they contain a Channel_Set Label MUST have the 
Action field set to 0 (Inclusive List).

Many thanks for the work.
Cheers,
Adrian 

Delivery-date: Sun, 01 Mar 2009 19:41:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, <[email-masked]>
Subject: Re: Chair review of draft-ietf-ccamp-gmpls-ether-svcs-02.txt
Date: Sun, 1 Mar 2009 19:40:40 -0000

Hi again, Lou.

[SNIP]

>> Section 2.1.1.1
>>
>> A CALL_ATTRIBUTES object containing an Endpoint ID TLV MAY be
>> included in the signaling messages of an LSP (connection) associated
>> with an established call. Such objects are processed according to
>> [4420BIS].
>>
>> As per our (elongated) discussion for the MLN extensions. I don't see
>> the value of including this object in a connection signaling message,
>> and I see some significant dangers (including a breach in the "need to
>> know" policy for the distribution of information within the Internet).
>>
>> But I have two issues with this paragraph.
>>
>> 1. You say "MAY be included", but nowhere in the spec do you
>> say why or what it might be used for. We are not in the habit of
>> defining mechanisms on the chance that they will be valuable at
>> some time in the future. If you have a specific use in mind, please
>> state it. Otherwise, we should delete this paragraph and let new
>> documents vary the rules when/if a use is found.
>>
> 
> I think the primary value is providing the operator/carrier with 
> additional OAM information on the LSP.
> 
>> 2. Draft 4420-bis (now RFC 5420) does not mention this object
>> and it is not appropriate to reference it for processing rules.
> 
> Looks like a broken reference to me, (wrong attributes object) should be 
> [GMPLS-MRN].
>
>> Transit nodes supporting this document MUST propagate the Endpoint ID
>> TLV without modification.
>>
>> Are you sure this is what you want?
>> Isn't it the case that endpoint identifiers could be mapped at UNI and
>> E-NNI reference points?
> 
> the line will be removed - someone else commented on this too.

So you took out both paragraphs.
That is OK with me, but I wanted to check it's what you intended.

>> Section 2.3.1
>> Ethernet connections established according to this document MUST
>> include the L2CP TLV in the [ETH-TRAFFIC] traffic parameters carried
>> in the FLOWSPEC and TSPEC objects.
>>
>> What do I do if the TLV is not there in each case?
> 
> what you always do you in RSVP when there's a malformed message.

What? Crash?

Oh, you mean drop the message and log, or send a PathErr message?
(Noting that 2205 and 3209 distinguish situations for both options.)

If a PathErr, what error code and error value?

Not too much to ask you to clarify?

Otherwise, thanks for all the updates.

Cheers,
Adrian

Delivery-date: Sun, 01 Mar 2009 19:20:15 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: <[email-masked]>, "Lou Berger" <[email-masked]>
Subject: Re: Chair review of draft-ietf-ccamp-gmpls-mef-uni-01.txt
Date: Sun, 1 Mar 2009 19:17:50 -0000

Thanks, Lou.

[SNIP]

>> Section 1
>>
>> Paragraph 1 doesn't seem sure how many frameworks there are.
>> Perhaps
>> OLD
>> [MEF6] and [G.8011] provide parallel frameworks
>> NEW
>> [MEF6] and [G.8011] provide parallel views of a framework
>
> humm, I think the original phrasing is more accurate.

Sorry, I wasn't clear.

The second sentence starts "The framework discusses ..."

Thus you need either my suggestion above, or to change to "The frameworks 
discuss ..."

All other changes look good, so we can pick this up when we have to take 
IETF/IESG comments.

Cheers,
Adrian