Wavelength Switched Optical Networking Drafts

Hi CCAMPers, a revised version of the wavelength switched optical 
networking draft is now available at 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-02.txt
This incorporates most of the comments received from the CCAMP list and 
the authors propose that this become a working group draft in order to 
guide the optical efforts at CCAMP and PCE. This document would be 
informational and would contain problem descriptions and models 
highlightng differences encountered in the wavelength switched case 
relative to TDM or MPLS situations.

In addition we have published two more WSON related drafts:
(a) Information encoding for WSON:  
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-info-00.txt 
where we have specified some initial compact encodings of pertinent 
information used in the RWA process.

(b) Signaling extensions for WSON: 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-signaling-00.txt 
where we take a first general crack at defining traffic parameters for 
lightpaths and other useful info to assist in distributed wavelength 
assignment (the WA in RWA). 

Regards

Greg B.

--

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

RE: Questions on RSVP-TE Graceful Restart and the new Extensions

Hi Dan,

I have come up with the following text for the first problem:

+--------------------------+
Additional Restarting Node procedures

According to the current graceful restart procedure [RFC 3473], after a node
restarts its control plane, it needs its upstream node to send PATH message with recovery 
label to synchronize its RSVP state. If the restarted control plane becomes
operational quickly relative to the hello interval, the upstream node may not detect
the restarting of  downstream node and therefore, may send a PATH message without
recovery label causing errors and unwanted connection deletion.

To resolve the aforementioned problem, the following procedures are proposed 
and are meant to work together with the recovery procedures documented in
[RFC3473]. Here, it is assumed that the restarting node and the neighboring 
node(s) support Hello extension as documented in [RFC3209] and recovery 
procedures documented in [RFC3473].

After a node restarts its control plane, it should ignore and silently drop 
all RSVP-TE messages, except hello messages, it receives from any neighbor to which,
no Hello session has been established.

The restarting node should follow [RFC3209] to establish Hello sessions with 
its neighbors,  after its control plane becomes operational. 

The restarting node resumes processing of RSVP-TE messages sent from each
neighbor to which the Hello session has been established.
+---------------------------+

Question on LABEL_SET encoding for VCAT LSPs

Vancouver schedule

Hi,

The *preliminary* schedule is at 
https://datatracker.ietf.org/meeting/70/agenda.html

It shows CCAMP at:

9am Tuesday 4th December
1pm Thursday 6th December

Adrian 

I-D Action:draft-ietf-ccamp-gmpls-mln-extensions-00.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           : Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and
Multi-Region Networks (MLN/MRN)
	Author(s)       : D. Papadimitriou, et al.
	Filename        : draft-ietf-ccamp-gmpls-mln-extensions-00.txt
	Pages           : 18
	Date            : 2007-11-04

There are requirements for the support of networks ccomprising LSRs
with 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.

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

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-mln-extensions-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

The IETF t-mpls design team

The IAB has decided to appoint the following design team:

- Loa Andersson
- Matthew Bocci
- Deborah Brungard
- Stewart Bryant
- Ross Callon
- Dinesh Mohan
- Tom Nadeau
- Tom Walsh

to address issues in preparation of the potential cooperation
between IETF and ITU-T on protocols for t-mpls.

The design team will further discuss its charter and coordinate
it with IAB as necessary; a tentative design team is:

 o Identifying an action list for the IETF
 o Identifying incompatibles and inconsistencies between IETF
   and ITU-T documents
 o IETF decisions to be revisited
 o organization to take care of ITU-T mpls/pwe3 requirements

On behalf of the IAB

/Loa

--

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson <at> acreo.se
                                           loa <at> pi.se

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

Evaluation of possible IGP extensions for WSON

planes Re: I-D Action:draft-nadeau-ccamp-gmpls-oam-requirements-02.txt

Now that this has been accepted as a WG I-D, I want to return to the point about
planes.

This I-D is an extension to RFC4377, which does a good job of teasing out the
extras needed for MPLS OAM - because a LSP is not quite like any other link or
path - and it does it with scarce a mention of planes..  The distinguishing
feature of GMPLS is the separation of control and data planes, different
topology, technology etc so perforce, this I-D will make reference to the data
and control planes.

But I think it then goes wrong in two ways.  One is the frequent reference to
management plane, something which RFC4377 avoids entirely and I think that this
I-D should do too.

The other is that first sentence, which used to refer to data plane
and now refers to control plane.  I think that neither term is right, that what
ought to be different about GMPLS is for the control plane and data plane to
stay in synch
so what ought to be different about GMPLS OAM is being able to compare the
operational state of the two and determine whether or not that is the case ie
the key feature is neither data plane nor control plane but the relationship
between the two.  You say that the data plane will already have its OAM - well,
so can the control plane.

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <adrian <at> olddog.co.uk>
To: <ccamp <at> ops.ietf.org>
Sent: Saturday, October 13, 2007 3:14 PM
Subject: Re: I-D Action:draft-nadeau-ccamp-gmpls-oam-requirements-02.txt

> Hi Tom,
>
>
> > Yes, I find this version clearer.
>
> Good. Thanks.
>
> > I was struck by two semantic changes, for which I am happy to leave any
> > discussion to when it is a WG I-D.  One is the change of the first
> > sentence from
> > 'This document describes requirements for data plane OAM for GMPLS'
> > to
> > 'This document describes requirements for control plane OAM for GMPLS'
> > which sounds quite a change.   In practice, this does not reflect a
> > dramatic
> > change of contents, but then again, I do not think either sentence gets it
> > quite
> > right.
>
> This tackled a comment from Don O'Connor.
>
> I think the essence of Don's point was that the techniques being described
> were not data plane OAM. In fact, while we may leverage data plane OAM, for
> most (all?) technologies with which we are dealing, the data plane OAM is
> already defined (stroke being defined) by other bodies or other working
> groups.
>
> We'd be happy to see another formulation of this text.
>
> > Second, I notice a much stronger emphasis on (SNMP) MIB modules; I presume
> > it is
> > too early to accommodate other forms, such as the nascent NETCONF.
>
> Ah. Hmm.
>
> As you say, NetConf is nascent. It would be a trifle premature to *require*
> NetConf conformance. In fact, the requirements would perhaps be a little
> more abstract (e.g., "standardised tools for operational management") if
> there wasn't also the general IETF "SHOULD" applied to the development of
> MIB modules for all protocols and protocol extensions.
>
> Cheers,
> Adrian

New draft on: GMPLS RSVP-TE Ethernet OAM Extensions

Hi all,

We submitted a new draft discussing possible extensions for Ethernet OAM
in the context of GELS:
http://www.ietf.org/internet-drafts/draft-takacs-ccamp-rsvp-te-eth-oam-e
xt-00.txt

Your comments are appreciated!
Best regards,
Attila

I-D Action:draft-ietf-ccamp-gmpls-mln-reqs-07.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           : Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
	Author(s)       : K. Shiomoto, et al.
	Filename        : draft-ietf-ccamp-gmpls-mln-reqs-07.txt
	Pages           : 24
	Date            : 2007-11-07

Most of the initial efforts to utilize Generalized MPLS (GMPLS)
have been related to environments hosting devices with a single
switching capability. The complexity raised by the control of such
data planes is similar to that seen in classical IP/MPLS networks.
By extending MPLS to support multiple switching technologies, GMPLS
provides a comprehensive framework for the control of a multi-
layered network of either a single switching technology or multiple
switching technologies.

In GMPLS, a switching technology domain defines a region, and a
network of multiple switching types is referred to in this document
as a Multi-Region Network (MRN). When referring in general to a
layered network, which may consist of either a single or multiple
regions, this document uses the term, Multi-Layer Network (MLN).

 Expires May 2008

  [page 1]

 draft-ietf-ccamp-gmpls-mln-reqs-07.txt
  November 2007

This document defines a framework for GMPLS based multi-region/
multi-layer networks and lists a set of functional requirements.

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

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-mln-reqs-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-07.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce