Last Call: draft-ietf-ccamp-ospf-interas-te-extension (OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering) to Proposed Standard

[The IESG <[e-mail]>]

The IESG has received a request from the Common Control and Measurement 
Plane WG (ccamp) to consider the following document:

- 'OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching 
   (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering '
   <draft-ietf-ccamp-ospf-interas-te-extension-05.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2008-07-14. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16070&rfc_flag=0





Envelope-to: [e-mail]
Delivery-date: Mon, 30 Jun 2008 17:52:21 +0000
To: IETF-Announce <[e-mail]> 
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-ccamp-ospf-interas-te-extension (OSPF  Extensions in Support of Inter-AS Multiprotocol Label Switching  (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering) to  Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 30 Jun 2008 10:50:39 -0700 (PDT)

The IESG has received a request from the Common Control and Measurement 
Plane WG (ccamp) to consider the following document:

- 'OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching 
   (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering '
   <draft-ietf-ccamp-ospf-interas-te-extension-05.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2008-07-14. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16070&rfc_flag=0




Envelope-to: [e-mail]
Delivery-date: Mon, 30 Jun 2008 16:13:09 +0000
To: IETF-Announce <[e-mail]> 
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-ccamp-isis-interas-te-extension (ISIS  Extensions in Support of Inter-AS Multiprotocol Label Switching  (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering) to  Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 30 Jun 2008 09:10:17 -0700 (PDT)

The IESG has received a request from the Common Control and Measurement 
Plane WG (ccamp) to consider the following document:

- 'ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching 
   (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering '
   <draft-ietf-ccamp-isis-interas-te-extension-02.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2008-07-14. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-02.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16894&rfc_flag=0




Envelope-to: [e-mail]
Delivery-date: Sun, 29 Jun 2008 08:44:46 +0000
Message-ID: <039401c8d9c3$ee6f49a0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ross Callon" <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>, "Lou Berger" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Please publish draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt
Date: Sun, 29 Jun 2008 09:40:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Proto-write-up for draft-ietf-ccamp-asymm-bw-bidir-lsps-01

Intended status : Experimental

Please note that the authors propose these protocol extensions as
experimental with the support of the CCAMP working group. The logic
is that, while the protocol extensions have full support of the
working group, there is no immediate intention to build or deploy
product containing these features.

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

Adrian Farrel is the document shepherd.
He has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

This document has been reviewed by the CCAMP working group and received
some comments at IETF meetings and on the mailing list.

The document has had sufficient review for an Experimental RFC.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.
No IPR disclosures filed.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

There were no problems with consensus for this document.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

All checks made.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

IANA section is OK.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

BNF checked by hand.
Note that this BNF follows the de facto standard for RSVP and RSVP-TE
BNF as presented in RFC 2205, RFC 3209, and RFC 3473. No formal 
definition of this BNF exists and none is deemed necessary by the CCAMP
or MPLS working groups.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>           Relevant content can frequently be found in the abstract
>           and/or introduction of the document.  If not, this may be
>           an indication that there are deficiencies in the abstract
>           or introduction.

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 RSVP model for the transport of traffic related parameters.
The procedures described in this document are experimental.

>        Working Group Summary
>           Was there anything in WG process that is worth noting?  For
>           example, was there controversy about particular points or
>           were there decisions where the consensus was particularly
>           rough?

Please note that the authors propose these protocol extensions as
experimental with the support of the CCAMP working group. The logic
is that, while the protocol extensions have full support of the
working group, there is no immediate intention to build or deploy
product containing these features.

>        Document Quality
>           Are there existing implementations of the protocol?  Have a
>           significant number of vendors indicated their plan to
>           implement the specification?  Are there any reviewers that
>           merit special mention as having done a thorough review,
>           e.g., one that resulted in important changes or a
>           conclusion that the document had no substantive issues?  If
>           there was a MIB Doctor, Media Type or other expert review,
>           what was its course (briefly)?  In the case of a Media Type
>           review, on what date was the request posted?
 
There are no implementations of these protocol extensions and no
immediate plans for implementation. 




Envelope-to: [e-mail]
Delivery-date: Wed, 25 Jun 2008 09:06:12 +0000
Message-ID: <[e-mail]>
Date: Wed, 25 Jun 2008 11:03:26 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: [e-mail], pwe3 <[e-mail]>, ccamp <[e-mail]>,  George Swallow <[e-mail]>, Adrian Farrel <[e-mail]>,  Deborah Brungard <[e-mail]>, Stewart Bryant <[e-mail]>, Danny McPherson <[e-mail]>,  BOCCI Matthew <[e-mail]>
Subject: mpls wg meetings in Dublin (wg and mpls-tp)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

All,

we send the this to MPLS, CCAMP and PWE3 working groups, since
it includes the announcement of the MPLS-TP meeting on Wednesday
morning during the IETF in Dublin.

The MPLS working group will meet in Dublin (twice), and it is
time to start compiling the agenda.

We will have one meeting Monday morning:
----------------------------------------

0900-1130 Morning Session I
Convention 3	RTG	mpls	Multiprotocol Label Switching WG

This meeting will be the traditional MPLS wg meeting focusing
on progressing our wg documents and documents intended for the
working group.

If you want time on the agenda it is now time to send a request
to the wg co-chairs. Please be clear about that your request is
intended for the Monday morning meeting.

We will also have a meting Wednesday morning:
---------------------------------------------

0900-1130 Morning Session I
Convention 3	RTG	mpls	Multiprotocol Label Switching WG

While this is formally an MPLS wg meeting, it will in effect be
a joint meeting with the CCAMP and PWE3 working groups. The intention
is to discuss the work we started up after the agreement with ITU-T
to include a transport profile within the MPLS architecture (MPLS-TP).

The agenda will include reports from the MEAD team and the editors
of the MPLS-TP documents, for this purpose there is no need to
request agenda time.

If you want time on the agenda it is now time to send a request
to the mpls wg co-chairs. Please be clear about that your request is
intended for the Wednesday morning meeting.

For those of you that is not familiar with the work going on in the
MEAD team there is a charter at:

http://www.tla-group.com/~loa/mead-team-charter.pdf

and document with information on the documents we are working on at:

http://www.tla-group.com/~loa/editor-doc-list.pdf
please note that this is a living document and will change from
time to time.


See you all in Dublin.

Loa and George

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]




Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jun 2008 17:32:22 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-dppm-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 24 Jun 2008 10: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		: Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks
	Author(s)	: W. Sun, G. Zhang, J. Gao, G. Xie, R. Papneja, B. Gu, X. Wei
	Filename	: draft-ietf-ccamp-lsp-dppm-02.txt
	Pages		: 39
	Date		: 2008-6-24
	
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-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-lsp-dppm-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Sat, 21 Jun 2008 14:24:17 +0000
Message-ID: <1b8801c8d3aa$0941fe00$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Zafar Ali \(zali\)" <[e-mail]>, <[e-mail]>, "Anca Zamfir \(ancaz\)" <[e-mail]>, "Newton, Jonathan" <[e-mail]>
Cc: <[e-mail]>
Subject: Progress on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Sat, 21 Jun 2008 15:21:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Authors,

The WG last call ended on this draft on March 5th.
Do you have plans to address the comments raised?

If there are issues please let me know. We can possibly find someone to help 
with the editing work, or we can move the draft to dead state when it 
expires next month.

Thanks,
Adrian
----- Original Message ----- 
From: "Zafar Ali (zali)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; "Anca Zamfir (ancaz)" <[e-mail]>; "Newton, 
Jonathan" <[e-mail]>
Sent: Monday, March 10, 2008 10:00 PM
Subject: RE: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown


Adrian-

On behalf of the authors, I am acking this action item on us.

Thanks

Regards... Zafar

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Sunday, March 09, 2008 2:48 PM
> To: [e-mail]
> Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
>
> Hi,
>
> This last call generated a lot of questions, issues and
> discussions on the list.
>
> Authors: I know you got involved in the debate, so thanks.
> What you should do now is send mail to the list enumerating
> and summarising the issues raised. For each you can say
> whether resolved (and how), or your plan for resolution.
>
> Thanks,
> Adrian
> ----- Original Message -----
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, February 13, 2008 11:06 AM
> Subject: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
>
>
> > Hi,
> >
> > The authors of this draft have been indicating that they
> thought it was
> > complete for some time. They have now updated the document
> to fix various
> > formatting nits and minor issues raised in the working group.
> >
> > Therefore, this email marks the start of a working group
> last call on
> >
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-grac
> eful-shutdown-05.txt
> > This is positioned to be an Informational RFC.
> >
> > The last call will end on Wednesday 5th March at 12 noon
> GMT. Please send
> > your comments to the list.
> >
> > Thanks,
> > Adrian
> >
> >
> >
>
>
>
>





Envelope-to: [e-mail]
Delivery-date: Fri, 20 Jun 2008 09:12:55 +0000
Message-ID: <1aaa01c8d2b5$7850bd90$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: WG Last Call draft-ietf-softwire-bgp-te-attribute-00.txt
Date: Fri, 20 Jun 2008 10:10:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I think that CCAMP may want to look at this I-D as well.

Cheers,
Adrian
----- Original Message ----- 
From: "David Ward" <[e-mail]>
To: <[e-mail]>; "Alain Durand" <[e-mail]>; 
"idr" <[e-mail]>; <[e-mail]>; "Ross Callon" <[e-mail]>; 
"Mark Townsley" <[e-mail]>; "Jari Arkko" <[e-mail]>
Cc: "Hamid Ould-Brahim" <[e-mail]>; "Yakov Rekhter" 
<[e-mail]>; "Don Fedyk" <[e-mail]>
Sent: Thursday, June 19, 2008 3:05 PM
Subject: WG Last Call draft-ietf-softwire-bgp-te-attribute-00.txt


> All -
>
> We are starting a two week WG (in the softwires WG)  last call for
> the draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-bgp-te-
> attribute-00.txt
>
>
>
> Please send your comments before 1700 CDT 2008.07.03
>
> Thanks
>
> DWard, Alain
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 18 Jun 2008 15:43:18 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D159.E4F2C27E"
Subject: RE: Draft communication to Q6/15
Date: Wed, 18 Jun 2008 11:42:19 -0400
Message-ID: <[e-mail]>
Thread-Topic: Draft communication to Q6/15
Thread-Index: AcjRVvg3kr5zR2lnS+6+2g6Z5OyApQAAr4rg
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8D159.E4F2C27E
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Thanks Greg - at this time, it is only informational. There is no need
for a response from Q6.

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Greg Bernstein
Sent: Wednesday, June 18, 2008 11:19 AM
To: [e-mail]
Subject: Re: Draft communication to Q6/15


This looks good Deborah and Adrian. Should we put in any info to remind
them that our next IETF meeting is in July in Dublin?

Regards

Greg B.

BRUNGARD, DEBORAH A, ATTLABS wrote:=20

	Hi,
	=20
	Now that we have WG drafts on WSON, we have prepared the
following Liaison to Q6/15. It will be communicated as informational.
	=20
	Please let us know if any comments,
	Deborah and Adrian
	=20
	=3D=3D=3D=3D=3D=3D
	Communication to Q6/15 from the IETF's CCAMP Working Group
	=20
	The CCAMP Working Group of IETF would like to inform you of our
work on enhancing GMPLS's support for Lambda Switching to support the
new generation of Lambda Switch Capable equipment (e.g. ROADMs and
PXCs). GMPLS provides a standard control plane in support of setting up
(or restoring) a connection for multiple technologies (e.g. photonic,
TDM (SONET/SDH), Ethernet).=20

=09

	When GMPLS currently sets up an end-to-end wavelength connection
(i.e. a Lambda LSP), the label that identifies the Lambda to use only
has local context (between the neighboring nodes at the ends of the
Lambda link). With the recent progress on optical network technology and
the capability to activate/reroute an optical path over a larger domain
comprised of DWDM, ROADMs, and PXCs (e.g. G.680 Appendix III
application), CCAMP participants are interested to investigate these new
applications to ensure the applicability of GMPLS protocols for
connection setup and path computation and whether additional extensions
are needed. The following document "Framework for GMPLS and PCE Control
of Wavelength Switched Optical Networks (WSON)" provides a framework for
our work effort:

=09
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-switched
-framework-00.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-switche
d-framework-00.txt>=20

=09

	Note, CCAMP is concerned with the GMPLS protocol aspects for
control of Lambda Switch Capable equipment. Work on characterization of
optical signals, devices, and fibers is not within our scope.

=09

	The first aspect being considered is a standardized wavelength
representation. The proposal for the wavelength label representation is
based on the grids used by G.694.1 and G.694.2. The following document
"Generalized Labels for G.694 Lambda-Switching Capable Label Switching
Routers" describes our proposal:

=09
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-
labels-01.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda
-labels-01.txt>=20

=09

	Both of these documents are in a very early phase of
development. As we progress our work, we will be including aspects of
G.680. We welcome any comments you may have at this time on our work and
we would appreciate if you would keep us informed of your progress in
this area.
	=20


--=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 [phone]


------_=_NextPart_001_01C8D159.E4F2C27E
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.3354" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D317024115-18062008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks Greg - at this time, it is&nbsp;only =
informational.=20
There is no need for a response from Q6.</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Greg=20
Bernstein<BR><B>Sent:</B> Wednesday, June 18, 2008 11:19 =
AM<BR><B>To:</B>=20
[e-mail]<BR><B>Subject:</B> Re: Draft communication to=20
Q6/15<BR></FONT><BR></DIV>
<DIV></DIV>This looks good Deborah and Adrian. Should we put in any info =
to=20
remind them that our next IETF meeting is in July in=20
Dublin?<BR><BR>Regards<BR><BR>Greg B.<BR><BR>BRUNGARD, DEBORAH A, =
ATTLABS wrote:=20

<BLOCKQUOTE=20
cite=3Dmid:[e-mail]=
.com=20
type=3D"cite">
  <META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D742273714-18062008>Hi,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D742273714-18062008>Now =
that we have=20
  WG drafts on WSON, we have prepared the following Liaison to Q6/15. It =
will be=20
  communicated as informational.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D742273714-18062008>Please let us know=20
  if any comments,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D742273714-18062008>Deborah and=20
  Adrian</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D742273714-18062008>=3D=3D=3D=3D=3D=3D</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D742273714-18062008>Communication to=20
  Q6/15 from the IETF's CCAMP Working Group</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D+0><SPAN class=3D742273714-18062008>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3DArial><FONT=20
  size=3D2>The CCAMP Working Group of IETF would like to inform you of =
our work on=20
  enhancing GMPLS&#8217;s support for Lambda Switching to support the =
new generation=20
  of Lambda Switch Capable equipment (e.g. ROADMs and PXCs). GMPLS =
provides a=20
  standard control plane in support of setting up (or restoring) a =
connection=20
  for multiple technologies (e.g. photonic, TDM (SONET/SDH), Ethernet).=20
  <O:P></O:P></FONT></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><O:P><FONT =
face=3DArial=20
  size=3D2></FONT></O:P></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3DArial><FONT=20
  size=3D2>When GMPLS currently sets up an end-to-end wavelength =
connection (i.e.=20
  a Lambda LSP), the label that identifies the Lambda to use only has =
local=20
  context (between the neighboring nodes at the ends of the Lambda =
link). With=20
  the recent progress on optical network technology and the capability =
to=20
  activate/reroute an optical path over a larger domain comprised of =
DWDM,=20
  ROADMs, and PXCs (e.g. G.680 Appendix III application), CCAMP =
participants are=20
  interested to investigate these new applications to ensure the =
applicability=20
  of GMPLS protocols for connection setup and path computation and =
whether=20
  additional extensions are needed. The following document =
&#8220;Framework for GMPLS=20
  and PCE Control of Wavelength Switched Optical Networks (WSON)&#8221; =
provides a=20
  framework for our work effort:<O:P></O:P></FONT></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-s=
witched-framework-00.txt"=20
  moz-do-not-send=3D"true"><FONT face=3DArial=20
  =
size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-=
switched-framework-00.txt</FONT></A><O:P></O:P></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><O:P><FONT =
face=3DArial=20
  size=3D2></FONT></O:P></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3DArial><FONT=20
  size=3D2>Note, CCAMP is concerned with the GMPLS protocol aspects for =
control of=20
  Lambda Switch Capable equipment. Work on characterization of optical =
signals,=20
  devices, and fibers is not within our =
scope.<O:P></O:P></FONT></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><O:P><FONT =
face=3DArial=20
  size=3D2></FONT></O:P></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3DArial><FONT=20
  size=3D2>The first aspect being considered is a standardized =
wavelength=20
  representation. The proposal for the wavelength label representation =
is based=20
  on the grids used by G.694.1 and G.694.2. The following document =
&#8220;Generalized=20
  Labels for G.694 Lambda-Switching Capable Label Switching =
Routers&#8221; describes=20
  our proposal:<O:P></O:P></FONT></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-=
lambda-labels-01.txt"=20
  moz-do-not-send=3D"true"><FONT face=3DArial=20
  =
size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694=
-lambda-labels-01.txt</FONT></A><O:P></O:P></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><O:P><FONT =
face=3DArial=20
  size=3D2></FONT></O:P></P><SPAN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'"><FONT =
face=3DArial=20
  size=3D2>Both of these documents are in a very early phase of =
development. As we=20
  progress our work, we will be including aspects of G.680. We welcome =
any=20
  comments you may have at this time on our work and we would appreciate =
if you=20
  would keep us informed of your progress in this=20
  area.</FONT></SPAN></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  =
class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV></BLOCKQUOTE><BR><PR=
E 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 [phone]

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

------_=_NextPart_001_01C8D159.E4F2C27E--



Envelope-to: [e-mail]
Delivery-date: Wed, 18 Jun 2008 15:20:13 +0000
Message-ID: <[e-mail]>
Date: Wed, 18 Jun 2008 08:18:58 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Draft communication to Q6/15
Content-Type: multipart/alternative; boundary="------------030105060307090906050504"

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

This looks good Deborah and Adrian. Should we put in any info to remind 
them that our next IETF meeting is in July in Dublin?

Regards

Greg B.

BRUNGARD, DEBORAH A, ATTLABS wrote:
> Hi,
>  
> Now that we have WG drafts on WSON, we have prepared the following 
> Liaison to Q6/15. It will be communicated as informational.
>  
> Please let us know if any comments,
> Deborah and Adrian
>  
> ======
> Communication to Q6/15 from the IETF's CCAMP Working Group
>  
>
> The CCAMP Working Group of IETF would like to inform you of our work 
> on enhancing GMPLS's support for Lambda Switching to support the new 
> generation of Lambda Switch Capable equipment (e.g. ROADMs and PXCs). 
> GMPLS provides a standard control plane in support of setting up (or 
> restoring) a connection for multiple technologies (e.g. photonic, TDM 
> (SONET/SDH), Ethernet).
>
>  
>
> When GMPLS currently sets up an end-to-end wavelength connection (i.e. 
> a Lambda LSP), the label that identifies the Lambda to use only has 
> local context (between the neighboring nodes at the ends of the Lambda 
> link). With the recent progress on optical network technology and the 
> capability to activate/reroute an optical path over a larger domain 
> comprised of DWDM, ROADMs, and PXCs (e.g. G.680 Appendix III 
> application), CCAMP participants are interested to investigate these 
> new applications to ensure the applicability of GMPLS protocols for 
> connection setup and path computation and whether additional 
> extensions are needed. The following document "Framework for GMPLS and 
> PCE Control of Wavelength Switched Optical Networks (WSON)" provides a 
> framework for our work effort:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-switched-framework-00.txt
>
>  
>
> Note, CCAMP is concerned with the GMPLS protocol aspects for control 
> of Lambda Switch Capable equipment. Work on characterization of 
> optical signals, devices, and fibers is not within our scope.
>
>  
>
> The first aspect being considered is a standardized wavelength 
> representation. The proposal for the wavelength label representation 
> is based on the grids used by G.694.1 and G.694.2. The following 
> document "Generalized Labels for G.694 Lambda-Switching Capable Label 
> Switching Routers" describes our proposal:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt
>
>  
>
> Both of these documents are in a very early phase of development. As 
> we progress our work, we will be including aspects of G.680. We 
> welcome any comments you may have at this time on our work and we 
> would appreciate if you would keep us informed of your progress in 
> this area.
>  

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



--------------030105060307090906050504
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">
</head>
<body bgcolor="#ffffff" text="#000000">
This looks good Deborah and Adrian. Should we put in any info to remind
them that our next IETF meeting is in July in Dublin?<br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
BRUNGARD, DEBORAH A, ATTLABS wrote:
<blockquote
 cite="mid:[e-mail]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.3354" name="GENERATOR">
  <div><font face="Arial" size="2"><span class="742273714-18062008">Hi,</span></font></div>
  <div><font face="Arial" size="2"><span class="742273714-18062008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="742273714-18062008">Now
that we have WG drafts on WSON, we have prepared the following Liaison
to Q6/15. It will be communicated as informational.</span></font></div>
  <div><font face="Arial" size="2"><span class="742273714-18062008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="742273714-18062008">Please
let us know if any comments,</span></font></div>
  <div><font face="Arial" size="2"><span class="742273714-18062008">Deborah
and Adrian</span></font></div>
  <div><font face="Arial" size="2"><span class="742273714-18062008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="742273714-18062008">======</span></font></div>
  <div><font face="Arial" size="2"><span class="742273714-18062008">Communication
to Q6/15 from the IETF's CCAMP Working Group</span></font></div>
  <div><font face="Arial" size="2"><span class="742273714-18062008"></span></font>&nbsp;</div>
  <div><font><span class="742273714-18062008">
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Arial"><font
 size="2">The CCAMP Working Group of IETF would like to inform you of
our work on enhancing GMPLS&#8217;s support for Lambda Switching to support
the new generation of Lambda Switch Capable equipment (e.g. ROADMs and
PXCs). GMPLS provides a standard control plane in support of setting up
(or restoring) a connection for multiple technologies (e.g. photonic,
TDM (SONET/SDH), Ethernet). <o:p></o:p></font></font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><o:p><font
 face="Arial" size="2">&nbsp;</font></o:p></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Arial"><font
 size="2">When GMPLS currently sets up an end-to-end wavelength
connection (i.e. a Lambda LSP), the label that identifies the Lambda to
use only has local context (between the neighboring nodes at the ends
of the Lambda link). With the recent progress on optical network
technology and the capability to activate/reroute an optical path over
a larger domain comprised of DWDM, ROADMs, and PXCs (e.g. G.680
Appendix III application), CCAMP participants are interested to
investigate these new applications to ensure the applicability of GMPLS
protocols for connection setup and path computation and whether
additional extensions are needed. The following document &#8220;Framework for
GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)&#8221;
provides a framework for our work effort:<o:p></o:p></font></font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><a
 moz-do-not-send="true"
 href="http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-switched-framework-00.txt"><font
 face="Arial" size="2">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-switched-framework-00.txt</font></a><o:p></o:p></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><o:p><font
 face="Arial" size="2">&nbsp;</font></o:p></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Arial"><font
 size="2">Note, CCAMP is concerned with the GMPLS protocol aspects for
control of Lambda Switch Capable equipment. Work on characterization of
optical signals, devices, and fibers is not within our scope.<o:p></o:p></font></font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><o:p><font
 face="Arial" size="2">&nbsp;</font></o:p></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Arial"><font
 size="2">The first aspect being considered is a standardized
wavelength representation. The proposal for the wavelength label
representation is based on the grids used by G.694.1 and G.694.2. The
following document &#8220;Generalized Labels for G.694 Lambda-Switching
Capable Label Switching Routers&#8221; describes our proposal:<o:p></o:p></font></font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><a
 moz-do-not-send="true"
 href="http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt"><font
 face="Arial" size="2">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt</font></a><o:p></o:p></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><o:p><font
 face="Arial" size="2">&nbsp;</font></o:p></p>
  <span style="font-size: 12pt; font-family: 'Times New Roman';"><font
 face="Arial" size="2">Both of these documents are in a very early
phase of development. As we progress our work, we will be including
aspects of G.680. We welcome any comments you may have at this time on
our work and we would appreciate if you would keep us informed of your
progress in this area.</font></span></span></font></div>
  <div><font face="Arial" size="2"><span class="742273714-18062008"></span></font>&nbsp;</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]

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

--------------030105060307090906050504--



Envelope-to: [e-mail]
Delivery-date: Wed, 18 Jun 2008 14:55:23 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D152.FAB54EEE"
Subject: Draft communication to Q6/15
Date: Wed, 18 Jun 2008 10:52:46 -0400
Message-ID: <[e-mail]>
Thread-Topic: Draft communication to Q6/15
Thread-Index: AcjRUvgIHzeEYOdzQt6thTtK+KM+dA==
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8D152.FAB54EEE
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
Now that we have WG drafts on WSON, we have prepared the following
Liaison to Q6/15. It will be communicated as informational.
=20
Please let us know if any comments,
Deborah and Adrian
=20
=3D=3D=3D=3D=3D=3D
Communication to Q6/15 from the IETF's CCAMP Working Group
=20
The CCAMP Working Group of IETF would like to inform you of our work on
enhancing GMPLS's support for Lambda Switching to support the new
generation of Lambda Switch Capable equipment (e.g. ROADMs and PXCs).
GMPLS provides a standard control plane in support of setting up (or
restoring) a connection for multiple technologies (e.g. photonic, TDM
(SONET/SDH), Ethernet).=20

=20

When GMPLS currently sets up an end-to-end wavelength connection (i.e. a
Lambda LSP), the label that identifies the Lambda to use only has local
context (between the neighboring nodes at the ends of the Lambda link).
With the recent progress on optical network technology and the
capability to activate/reroute an optical path over a larger domain
comprised of DWDM, ROADMs, and PXCs (e.g. G.680 Appendix III
application), CCAMP participants are interested to investigate these new
applications to ensure the applicability of GMPLS protocols for
connection setup and path computation and whether additional extensions
are needed. The following document "Framework for GMPLS and PCE Control
of Wavelength Switched Optical Networks (WSON)" provides a framework for
our work effort:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-switched
-framework-00.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-switche
d-framework-00.txt>=20

=20

Note, CCAMP is concerned with the GMPLS protocol aspects for control of
Lambda Switch Capable equipment. Work on characterization of optical
signals, devices, and fibers is not within our scope.

=20

The first aspect being considered is a standardized wavelength
representation. The proposal for the wavelength label representation is
based on the grids used by G.694.1 and G.694.2. The following document
"Generalized Labels for G.694 Lambda-Switching Capable Label Switching
Routers" describes our proposal:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-
labels-01.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda
-labels-01.txt>=20

=20

Both of these documents are in a very early phase of development. As we
progress our work, we will be including aspects of G.680. We welcome any
comments you may have at this time on our work and we would appreciate
if you would keep us informed of your progress in this area.
=20

------_=_NextPart_001_01C8D152.FAB54EEE
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.3354" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D742273714-18062008>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D742273714-18062008>Now =
that we have WG=20
drafts on WSON, we have prepared the following Liaison to Q6/15. It will =
be=20
communicated as informational.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D742273714-18062008>Please =
let us know=20
if any comments,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D742273714-18062008>Deborah and=20
Adrian</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D742273714-18062008>=3D=3D=3D=3D=3D=3D</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D742273714-18062008>Communication to=20
Q6/15 from the IETF's CCAMP Working Group</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D742273714-18062008>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3DArial><FONT size=3D2>The=20
CCAMP Working Group of IETF would like to inform you of our work on =
enhancing=20
GMPLS&#8217;s support for Lambda Switching to support the new generation =
of Lambda=20
Switch Capable equipment (e.g. ROADMs and PXCs). GMPLS provides a =
standard=20
control plane in support of setting up (or restoring) a connection for =
multiple=20
technologies (e.g. photonic, TDM (SONET/SDH), Ethernet). <?xml:namespace =
prefix=20
=3D o ns =3D "urn:schemas-microsoft-com:office:office"=20
/><o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3DArial=20
size=3D2>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3DArial><FONT=20
size=3D2>When GMPLS currently sets up an end-to-end wavelength =
connection (i.e. a=20
Lambda LSP), the label that identifies the Lambda to use only has local =
context=20
(between the neighboring nodes at the ends of the Lambda link). With the =
recent=20
progress on optical network technology and the capability to =
activate/reroute an=20
optical path over a larger domain comprised of DWDM, ROADMs, and PXCs =
(e.g.=20
G.680 Appendix III application), CCAMP participants are interested to=20
investigate these new applications to ensure the applicability of GMPLS=20
protocols for connection setup and path computation and whether =
additional=20
extensions are needed. The following document &#8220;Framework for GMPLS =
and PCE=20
Control of Wavelength Switched Optical Networks (WSON)&#8221; provides a =
framework for=20
our work effort:<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-s=
witched-framework-00.txt"><FONT=20
face=3DArial=20
size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-=
switched-framework-00.txt</FONT></A><o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3DArial=20
size=3D2>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3DArial><FONT=20
size=3D2>Note, CCAMP is concerned with the GMPLS protocol aspects for =
control of=20
Lambda Switch Capable equipment. Work on characterization of optical =
signals,=20
devices, and fibers is not within our =
scope.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3DArial=20
size=3D2>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3DArial><FONT size=3D2>The=20
first aspect being considered is a standardized wavelength =
representation. The=20
proposal for the wavelength label representation is based on the grids =
used by=20
G.694.1 and G.694.2. The following document &#8220;Generalized Labels =
for G.694=20
Lambda-Switching Capable Label Switching Routers&#8221; describes our=20
proposal:<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-=
lambda-labels-01.txt"><FONT=20
face=3DArial=20
size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694=
-lambda-labels-01.txt</FONT></A><o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3DArial=20
size=3D2>&nbsp;</FONT></o:p></P><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EN-US; =
mso-ansi-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
face=3DArial size=3D2>Both of these documents are in a very early phase =
of=20
development. As we progress our work, we will be including aspects of =
G.680. We=20
welcome any comments you may have at this time on our work and we would=20
appreciate if you would keep us informed of your progress in this=20
area.</FONT></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D742273714-18062008></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C8D152.FAB54EEE--



Envelope-to: [e-mail]
Delivery-date: Tue, 17 Jun 2008 19:46:18 +0000
Message-ID: <035601c8d0b2$a384bac0$d106a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: IETF-72 planning
Date: Tue, 17 Jun 2008 20:43:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi CCAMP,

We have two slots again in Dublin.

These are *provisionally* scheduled as:

Monday 28th 17.40-19.50
Thursday 31st 13.00-15.00

However, we have requested to swap the Thursday meeting with PCE making it 
9.00-11.30.

At the moment, our plan is to split the work as before with normal CCAMP 
business on Monday, and Ethernet and WSON on Thursday.

Please send any agenda requests to Deborah and me.


Please also note that there will be a joint meeting of MPLS, PWE3, and CCAMP 
to discuss MPLS-TP (the transport profile of MPLS). At the moment I think 
this will be in one of the two slots scheduled for the MPLS WG (Mon 9-11, or 
Weds 9-11) but I can't tell you which.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Tue, 17 Jun 2008 18:19:31 +0000
Message-ID: <032701c8d0a6$4925c620$d106a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Communication received from the OIF
Date: Tue, 17 Jun 2008 19:15:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We have received a communication from the OIF on the subject of ASON 
routing. Hoping that the design team can take this into account in their 
work.

You can find all incoming and outgoing communications at 
http://www.olddog.co.uk/ccamp.htm

Cheers,
Adrian
===
From: Mr. Lyndon Ong, OIF TC Chair, [e-mail]
Subject: Liaison to IETF on G.7715.1 Routing Requirements

Dear Adrian and Deborah,

We have been monitoring the work on ASON routing in the IETF CCAMP WG as we 
have done prototyping work
on multi-layer routing. As a result agreed at the 2Q2008 TC Plenary meeting, 
we have identified a number of
requirements in ITU G.7715.1 that we believe are important and may be 
helpful input to your work.

G.7715.1 includes requirements that many attributes of a link be advertised 
on a layer-specific basis. These
attributes, described in Section 9.5.1, include:
- Signal Type
- Link Capacity
- Link Weight *
- Resource Class *
- Link Availability *
- Diversity Support *
- Local Connection Type +
- Local Client Adaptations Supported +

Current IETF extensions to OSPF cover most of these attributes, but they are 
not provided on a layer-specific basis.
These items are identified above by an asterisk (*). Additionally, two of 
the attributes we cannot identify as being
provided by GMPLS routing. These are identified above by a plus (+).

As the OIF has been working on multi-layer routing we have found that 
maintaining attributes on a layer-specific
basis is beneficial. Furthermore we find the Local Connection Type and Local 
Client Adaptation information
useful for identifying the multi-layer relationships that exist at a link 
end.

As we continue work on multi-layer routing, we anticipate needing extensions 
to GMPLS routing to provide these
functions. We therefore request the IETF consider these requirements as they 
continue work on ASON routing.

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





Envelope-to: [e-mail]
Delivery-date: Wed, 11 Jun 2008 18:18:40 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 11 Jun 2008 11: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		: Service Provider Requirements for Ethernet control with GMPLS
	Author(s)	: W. Imajuku, Y. Sone, M. Suzuki, K. Matsuda, N. Bitar
	Filename	: draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt
	Pages		: 11
	Date		: 2008-6-11
	
 Generalized Multi-Protocol Label Switching (GMPLS) is applicable to
   Ethernet switches supporting Provider Backbone Bridge Traffic 
   Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label
   switch network not only automates creation of Ethernet Label Switched
   Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery
   Mechanisms such as protection and restoration of an Eth-LSP. This
   document describes the requirements for the set of solutions of GMPLS
   controlled Ethernet label switch networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.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-ethernet-gmpls-provider-reqs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Wed, 04 Jun 2008 14:14:45 +0000
Message-ID: <[e-mail]>
Date: Wed, 04 Jun 2008 16:11:22 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: [e-mail], ccamp <[e-mail]>, pwe3 <[e-mail]>,  L2VPN <[e-mail]>
Subject: MPLS TP status
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

with this mail we would like to informally share with you
the status of the work on MPLS-Transport Profile within the
IETF MPLS Interoperability Design Team (MEAD Team).

The MEAD Team has worked to define a document structure
related to the agreement between ITU-T and IETF to add an
MPLS-Transport Profile within the IETF MPLS architecture.

A list of documents the Team thinks is a good enough start to form
the architectural foundation for the MPLS TP has been prepared and
editors appointed.

The current list of documents and editors can be found at:

http://www.tla-group.com/~loa/editor-doc-list.pdf

Please note that this document is a living document and changes if
and when the information changes.

It is also possible that the document structure will change as the
topics are better understood.

There is also a still pending action to define a document structure
for the OAM Procedures documents

As recommended by the JWT document (MPLS-TP_overview-22.ppt), it is
assumed that both IETF and ITU-T participants will participate as
contributing authors to the development of these documents.
Cross-participation is highly appreciated to early capture the
major input before we reaches the final processes for the documents.

A contributing author of the document contributes text and
participates in defining changes, extensions and modifications to
the existing text.

If you want to contribute to any of these documents you need to
get in contact with the editors of that document.

Note that it is up to the editor team to decide how the discussions
should be conducted (e.g. via working group mailing lists or via
dedicated lists).

Some of you have not earlier contributed to Internet Drafts or RFC,
please remember that this is an effort that will take place very
much unrelated to IETF meetings, and that IETF will progress
documents by decisions take based on traffic on wg mailing lists.

Best Regards

Loa and Italo


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]