Subject: MPLS over OTN

From: "Howard Green" <[email-masked]>
Date: Thu, 31 Jul 2008 18:55:47 +0200

Just to record for the list a chat with Adrian and Lou Berger. I
discover from reading G.7041 Amendment 2 that there is a codepoint
defined to allow unicast MPLS frames to be carried over OTN (ODUx)
channels by way of GFP encoding. Reading RFC 4328, there is an encoding
type for ODUx, and the switching type is TDM. There is no specific G-PID
value defined for the MPLS codepoint (which was probably defined
concurrently with the writing of RFC 4328). Adrian and Lou took the view
that in this situation, the use of the unicast MPLS ethertype (#8847)
would define for signalling this bearer type (as described in RFC 3471).

This is relevant partly because G.7041 amendment 2 defines the codepoint
to be for "MPLS or T-MPLS". I assume that this usage carries over to
MPLS-TP. In this situation,interestingly, there is no prospect of inband
IP control, and so GMPLS is the only control plane option.
Is this correct?
Regards Howard

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 Aug 2008 09:53:24 +0100

Hi Howard,

[adding MPLS-TP mailing list]

Accurate representation of our conversation.
That is, in GMPLS we have label type, switching type, encoding type, and 
G-PID.
G-PID identifies the payload and re-uses the Ethertype codepoints. Thus we 
can carry MPLS.
If GFP is used for framing, it must also identify the payload and, as you 
point out, GFP has an MPLS codepoint.

That the GFP codepoint for MPLS is the same as that for "T-MPLS" is good for 
Option 1 (which is where we are) since there is no practical difference 
between MPLS and MPLS-TP.

Now, the operation of MPLS over OTN that you describe is actually the 
operation of an OTN. So the issues of control channels in OTN are exactly as 
you describe, but have nothing to do with the payload protocol. This is 
simply GMPLS control of OTN. Period.

GMPLS control of MPLS-TP is a different kettle of ball games. Here the 
switching type is PSC: the same switching type as for MPLS. A feature of 
GMPLS is that there is *logical* separation of control plane and data plane. 
This means that the control plane can be in-band (MPLS-TE), out-of-band but 
in-fibre (SONET/SDH or OSC), or out-of-fibre.

MPLS-TP requirements say that it must be possible to operate the network "in 
the absence of IP." I have taken this to mean "in the absence of IP routing 
and forwarding" (but this is my opinion and there is no explicit evidence in 
the requirements I-D). With this view...
- We can use IP identifiers (addresses) in the data plane and the control 
plane
- We can use IP-based control protocols (GMPLS)
- We can use an IP-based control network if available, but we cannot
   mandate it
- Control entities that need to communicate must be allowed to be
   IP-adjacent so that there is no requirement for IP-forwarding in the
   network

I believe we can do all of the above, and often do in GMPLS networks.
The crunch questions are:
1. What is the physical technology for the data links in the control plane?
2. How do we identify control plane traffic when it arrives at a node?
3. How do we exchange control plane messages between nodes that
   do not have a common data link in the control plane?

Answers are:
1. We don't care :-)
    But a possible answer in MPLS-TP is an LSP (e.g. a reserved label)
2. From the data link (since there is no need to disambiguate the control
   plane traffic from any other traffic on the data link)
3. This is a more tricky question. However nearly all of the messages
   are exchanged only between data-plane-adjacent nodes. This can be
   the case in the IGP-TE protocols, and is true for all messages in
   RSVP-TE with a couple of exceptions (below). It is also the case for
   LMP. So IP forwarding is not required in the control plane.
   The tricky cases are:
   - echo response in LSP Ping (we are rebuilding the OAM)
   - Notify message in RSVP-TE (we are considering OAM approaches
     for the uses of Notify where IP forwarding is not available)
   - "Targeted Path messages" used in hierarchical LSPs (and LSP
      stitching). In these cases we are effectively building a virtual
      data plane adjacency and should build a parallel virtual control
      plane link between the end points (e.g. an LSP).

We should note that the output of the JWT *appears* to be that "GMPLS meets 
the requirements of a control plane for MPLS-TP."

We should also note that management plane operation of MPLS-TP is a 
requirement, and we must assume that management plane messages may need to 
be exchanged between management stations and network nodes using some 
protocol and connectivity.

</homily>

Adrian
----- Original Message ----- 
From: "Howard Green" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 31, 2008 5:55 PM
Subject: MPLS over OTN

Delivery-date: Thu, 31 Jul 2008 20:27:05 +0000
Content-class: urn:content-classes:message
Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Date: Thu, 31 Jul 2008 15:26:18 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "Ccamp (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F34B.B0765B74
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Hi Adrian and Dan,
>=20
> I have the following comments on this draft. I was wondering what were =
the objectives for the IGP evaluation. IMHO the evaluation from WSON =
perspective should address the following:
> 1. IGP usage in the context of traditional distributed solutions for =
WSON
> 2. IGP usage in the context of PCE solutions for WSON=20
> 3. Flooding and refresh of static and dynamic link state updates
> 4. Data base sync-up during node restarts
>=20
> Could you please let me know if the above is within the current scope? =
I believe that these are important.
>=20
> Thanks,
> Snigdho
>=20
>=20
>=20
>=20
>=20

------_=_NextPart_001_01C8F34B.B0765B74
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>Comments on =
&quot;draft-li-ccamp-wson-igp-eval-01.txt&quot;</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Adrian and Dan,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have the following comments on this =
draft. I was wondering what were the objectives for the IGP evaluation. =
IMHO the evaluation from WSON perspective should address the =
following:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. IGP usage in the context of =
traditional distributed solutions for WSON</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">2. IGP usage in the context of PCE =
solutions for WSON </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">3. Flooding and refresh of static and =
dynamic link state updates</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">4. Data base sync-up during node =
restarts</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Could you please let me know if the =
above is within the current scope? I believe that these are =
important.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Snigdho</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C8F34B.B0765B74--

Delivery-date: Thu, 31 Jul 2008 17:46:50 +0000
Content-class: urn:content-classes:message
Subject: RE: comment on draft-takacs-ccamp-revertive-ps-01
Date: Thu, 31 Jul 2008 19:45:46 +0200
From: "Attila Takacs" <[email-masked]>
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, <[email-masked]>

Hi Dimitri,
Thanks for the comments, please see inline!
Attila

> comments on this doc:
>=20
> 1. the document should leave outside its scope signaling of=20
> the hold-off timer.
>=20

So you are suggesting to go with alternative 2.

> reason: this timer is used for multi-layer recovery while it=20
> would be advisable to have a more detailed understanding=20
> about the needs before extending the protection object
>=20

Even in a single layer case one has to set the hold-off timer properly
(e.g., it may be see on a per LSP bases so it can limit the load of the
protection switching process).
I do agree in that muli-layer recovery needs to be properly understood.
On the other hand, from actual extensions point of view, I'm not sure if
there is more to be done than to carry the respective timers. The
complexity of multi-layer considerations relies in the way the proper
values are derived which is probably outside the scope of the extension
doc.

> 2. segment protection: it should address first RFC4872 and=20
> then see how it could be applied to segment protection=20
> because different segments can have different WTR (i.e.=20
> multiple protection object could be included because race=20
> condition can appear when protected segment overlap and a=20
> failure on another segment occurs on another segment while=20
> the other is ready to the reverted).
>=20
> example:--A---B---C---D--
>           |   +   |   +
>            -E-+---    +
>               +       +
>               +++++++++
>=20
> B-C fails -> recovery segment B-D, then A-B fails=20
>=20

Agreed, e2e protection seems to be straightforward, while for segment
protection multiple timers may be needed.=20

> thanks,     =20
> -d.
>=20
>=20

Delivery-date: Thu, 31 Jul 2008 16:56:32 +0000
Content-class: urn:content-classes:message
Subject: MPLS over OTN
Date: Thu, 31 Jul 2008 18:55:47 +0200
From: "Howard Green" <[email-masked]>
To: <[email-masked]>

Delivery-date: Thu, 31 Jul 2008 16:39:41 +0000
Content-class: urn:content-classes:message
Subject: comment on draft-takacs-ccamp-revertive-ps-01
Date: Thu, 31 Jul 2008 18:37:51 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: <[email-masked]>

comments on this doc:

1. the document should leave outside its scope signaling of the hold-off
timer.

reason: this timer is used for multi-layer recovery while it would be
advisable to have a more detailed understanding about the needs before
extending the protection object

2. segment protection: it should address first RFC4872 and then see how
it could be applied to segment protection because different segments can
have different WTR (i.e. multiple protection object could be included
because race condition can appear when protected segment overlap and a
failure on another segment occurs on another segment while the other is
ready to the reverted).

example:--A---B---C---D--
          |   +   |   +
           -E-+---    +
              +       +
              +++++++++

B-C fails -> recovery segment B-D, then A-B fails=20

thanks,     =20
-d.

Envelope-to: [email-masked]
Delivery-date: Tue, 29 Jul 2008 08:24:59 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>,  ccamp mailing list <[email-masked]>,  ccamp chair <[email-masked]>
Subject: Document Action: 'Evaluation of existing GMPLS  Protocols against Multi Layer and Multi Region Networks  (MLN/MRN)' to Informational RFC 
Message-Id: <[email-masked]>
Date: Tue, 29 Jul 2008 01:22:04 -0700 (PDT)

The IESG has approved the following document:

- 'Evaluation of existing GMPLS Protocols against Multi Layer and Multi 
   Region Networks (MLN/MRN) '
   <draft-ietf-ccamp-gmpls-mln-eval-06.txt> as an Informational RFC

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

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-06.txt

Technical Summary

   This document provides an evaluation of Generalized Multi-Protocol
   Label Switching (GMPLS) protocols and mechanisms against the
   requirements for Multi-Layer Networks (MLN) and Multi-Region Networks
   (MRN). In addition, this document identifies areas where additional
   protocol extensions or procedures are needed to satisfy these
   requirements, and provides guidelines for potential extensions.

   This document is closely related to draft-ietf-ccamp-gmpls-mln-reqs,
   which is on the same IESG telechat agenda. 

Working Group Summary

   No dissent reported. This document has had broad review. See 
   PROTO writeup by Adrian Farrel for more details. 

Document Quality

   This is an evaluation of existing GMPLS mechanisms against the 
   requirements described in draft-ietf-ccamp-gmpls-mln-reqs. There
   is related ongoing work in the CCAMP working group. 

Personnel

   Adrian Farrel is the Document Shepherd for this document.  
   Ross Callon is the Responsible Area Director.  There are 
   no related IANA requirements (there is a null IANA section
   to make this clear).

Delivery-date: Mon, 28 Jul 2008 23:31:14 +0000
Date: Tue, 29 Jul 2008 00:29:50 +0100
To: "Ong, Lyndon" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Dublin Draft Agenda
Cc: "Lou Berger" <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>,<[email-masked]>

Hi Lyndon,

See below.

At 09:31 PM 7/28/2008, Ong, Lyndon wrote:
>Hi Lou,
>
>The ether-svcs draft points to the CALL_ATTRIBUTES object to carry the
>Ethernet endpoint identifier, while the mef-uni draft points to the
>LSP_ATTRIBUTES object, is this intentionally different or something that
>is going to be aligned in the future?

it's a bug, see http://www3.ietf.org/proceedings/08jul/slides/ccamp-9.ppt

>Also, do you have a pointer to a definition for
>Ethernet endpoint identifier?

per the text:

    Ethernet endpoint identifiers, as they are defined in [G.8011] and
    [MEF10.1], differ significantly from the identifiers used by GMPLS.
    Specifically, the Ethernet endpoint identifiers are character based
    as apposed to the GMPLS norm of being IP address based.

and the UNI document:

    2.2. Ethernet Endpoint (UNI) Identification

    UNI identification, except as noted below, MUST follow Ethernet
    endpoint (UNI) identification as defined in [GMPLS-ESVCS]. There is
    one additional case that is covered in this document where the scope
    of the Ethernet endpoint identifier is relevant beyond the typical
    case of just ingress and egress nodes.

So it's "ethernet identification" in the generic document and UNI 
identification in the UNI document, which maps to the UNI 
ID/identifier in MEF/G.8011...

Lou

>I took a quick look over G.8011 and MEF
>10.1
>and did not locate that particular term.  Is this intended to be a MAC
>address or something else?
>
>Thanks,
>
>Lyndon
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Lou Berger
>Sent: Monday, July 21, 2008 12:39 PM
>To: Greg Bernstein
>Cc: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
>Subject: Re: Dublin Draft Agenda
>
>I was going to cover use of CALL_ATTRIBUTES object in my time slots
>(12/13).  Can do otherwise/earlier if desired...
>
>Lou
>
>At 12:01 PM 7/18/2008, Greg Bernstein wrote:
> >Hi Deborah and Adrian, for session I on Monday you've got me down for
> >15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-) Was
>
> >part of this time for Lou to discuss a general "call approach"?
> >If not then I probably only need 10 minutes and will talk about an
> >encoding based on the CALL_ATTRIBUTES object class, from the MLN
> >extensions draft but using a new C-Type for VCAT/LCAS control.
> >
> >Also for session II, the WSON signaling draft will be presented by Dan
> >King. This is the merging of the two signaling drafts and the title of
> >my submission was a bit more generic than Sugang's.
> >
> >Regards
> >
> >Greg
> >
> >BRUNGARD, DEBORAH A, ATTLABS wrote:
> >>Hi CCAMP,
> >>
> >>We've uploaded a draft agenda:
> >><http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.iet
> >>f.org/proceedings/08jul/agenda/ccamp.txt
> >>
> >>Please let us know if we have missed anything.
> >>
> >>Adrian and Deborah
> >>
> >
> >
> >--
> >===================================================
> >Dr Greg Bernstein, Grotto Networking (510) 573-2237
> >

Delivery-date: Mon, 28 Jul 2008 20:33:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Dublin Draft Agenda
Date: Mon, 28 Jul 2008 16:31:46 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

Hi Lou,

The ether-svcs draft points to the CALL_ATTRIBUTES object to carry the
Ethernet endpoint identifier, while the mef-uni draft points to the
LSP_ATTRIBUTES object, is this intentionally different or something that
is going to be aligned in the future?

Also, do you have a pointer to a definition for
Ethernet endpoint identifier?  I took a quick look over G.8011 and MEF
10.1
and did not locate that particular term.  Is this intended to be a MAC
address or something else?

Thanks,

Lyndon=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lou Berger
Sent: Monday, July 21, 2008 12:39 PM
To: Greg Bernstein
Cc: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
Subject: Re: Dublin Draft Agenda

I was going to cover use of CALL_ATTRIBUTES object in my time slots
(12/13).  Can do otherwise/earlier if desired...

Lou

At 12:01 PM 7/18/2008, Greg Bernstein wrote:
>Hi Deborah and Adrian, for session I on Monday you've got me down for=20
>15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-) Was

>part of this time for Lou to discuss a general "call approach"?
>If not then I probably only need 10 minutes and will talk about an=20
>encoding based on the CALL_ATTRIBUTES object class, from the MLN=20
>extensions draft but using a new C-Type for VCAT/LCAS control.
>
>Also for session II, the WSON signaling draft will be presented by Dan=20
>King. This is the merging of the two signaling drafts and the title of=20
>my submission was a bit more generic than Sugang's.
>
>Regards
>
>Greg
>
>BRUNGARD, DEBORAH A, ATTLABS wrote:
>>Hi CCAMP,
>>
>>We've uploaded a draft agenda:
>><http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.iet
>>f.org/proceedings/08jul/agenda/ccamp.txt
>>
>>Please let us know if we have missed anything.
>>
>>Adrian and Deborah
>>
>
>
>--
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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: Mon, 28 Jul 2008 15:03:05 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Jabber
Date: Mon, 28 Jul 2008 16:01:09 +0100

Anyone here in Dublin who groks jabber and would be prepared to monitor the 
ccamp jabber room?

Please step forward!

Thanks,
Adrian 

Delivery-date: Sun, 27 Jul 2008 08:31:47 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-06.txt 
Date: Sun, 27 Jul 2008 01:30: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           : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
	Author(s)       : M. Chen, R. Zhang
	Filename        : draft-ietf-ccamp-ospf-interas-te-extension-06.txt
	Pages           : 19
	Date            : 2008-07-27

This document describes extensions to the OSPF version 2 and 3 
protocols to support Multiprotocol Label Switching (MPLS) and 
Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple 
Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined 
for the flooding of TE information about inter-AS links which can be 
used to perform inter-AS TE path computation. 

 No support for flooding information from within one AS to another AS 
is proposed or defined in this document. 

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-ospf-interas-te-extension-06.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-ospf-interas-te-extension-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Sun, 27 Jul 2008 00:25:38 +0000
Date: Sun, 27 Jul 2008 09:23:25 +0900
From: Tomohiro Otani <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: Problems posting draft-ietf-ccamp-gmpls-ted-mib-04.txt

Hi Adrian,

Thank you very much for your notice.
I thought that it had been uploaded.....
I very much apologize the inconvenience at this time.

Regards

Tomo

Adrian Farrel =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=
=97=E3=81=9F:
> Tomo has been having some problems getting=20
> draft-ietf-ccamp-gmpls-ted-mib-04.txt posted.
>
> He submitted before the deadline but there are still some unresolved=20
> issues.
>
> I have put a copy of the draft at http://www.olddog.co.uk/missing.htm
>
> Cheers,
> Adrian
>
>
>
>

Delivery-date: Sat, 26 Jul 2008 09:32:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Problems posting draft-ietf-ccamp-gmpls-ted-mib-04.txt
Date: Sat, 26 Jul 2008 09:48:24 +0100

Tomo has been having some problems getting 
draft-ietf-ccamp-gmpls-ted-mib-04.txt posted.

He submitted before the deadline but there are still some unresolved issues.

I have put a copy of the draft at http://www.olddog.co.uk/missing.htm

Cheers,
Adrian 

Delivery-date: Thu, 24 Jul 2008 18:41:10 +0000
Date: Thu, 24 Jul 2008 11:38:49 -0700
From: Greg Bernstein <[email-masked]>
To: "Bardalai, Snigdho" <[email-masked]>
CC: "Ccamp (E-mail)" <[email-masked]>
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

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

Hi Snigdho, I think we should meet and discuss in Dublin, face to face 
discussions are sometimes easier than e-mail, but see below for one last 
comment.
Regards

Greg

Bardalai, Snigdho wrote:
-- snip--
>
>     ---> Hmm, I thought this was clear from the above: "When we
>     encounter OEO devices such as wavelength converters or
>     regenerators many of these can accomodate multiple signal types
>     but need this basic low level information to determine
>     compatibility."  By including such information as modulation type,
>     modulation parameters, and bit rate in signaling we can configure
>     the devices along the path.  For example a 3R regenerator or OEO
>     based wavelength converter is needs timing (bit rate) information
>     (see ITU-T G.872 Annex A).
>     [Bardalai, Snigdho] Sorry, my question was not clear. What is
>     preventing us from using the "signal type" for this purpose?
>
--> The same "signal type" such as an OTUk, STM, or an Ethernet might 
use different (a) modulation type, (b) modulation parameters, or (c) FEC 
(which can also affect the bit rate).  Or do you mean a generalization 
of the "signal type" to include these new fields for a "light path" (or 
whatever we choose or are allowed to call it). And this information is, 
in effect, lower layer information and hence appropriate to the WSON 
discussions.
>
>>         -- 
>>         ===================================================
>>         Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>>             
>>
>
>     -- 
>     ===================================================
>     Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>         
>

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

--------------040305060204000609090805
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 Snigdho, I think we should meet and discuss in Dublin, face to face
discussions are sometimes easier than e-mail, but see below for one
last comment.<br>
Regards<br>
<br>
Greg<br>
<br>
Bardalai, Snigdho wrote:<br>
-- snip--<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title></title>
  <meta content="MSHTML 6.00.2900.3354" name="GENERATOR">
  <blockquote dir="ltr" style="margin-right: 0px;">---&gt; Hmm, I
thought this was clear from the above: "When we encounter OEO devices
such as wavelength converters or regenerators many of these can
accomodate multiple signal types but need this basic low level
information to determine compatibility."&nbsp; By including such information
as modulation type, modulation parameters, and bit rate in signaling we
can configure the devices along the path.&nbsp; For example a 3R regenerator
or OEO based wavelength converter is needs timing (bit rate)
information (see ITU-T G.872 Annex A).<br>
    <span class="715365615-23072008"><font color="#0000ff" face="Arial"
 size="2">[Bardalai, Snigdho]&nbsp;Sorry, my question was not clear. What is
preventing us from using the "signal type" for this purpose? </font></span><br>
  </blockquote>
</blockquote>
--&gt; The same "signal type" such as an OTUk, STM, or an Ethernet
might use different (a) modulation type, (b) modulation parameters, or
(c) FEC (which can also affect the bit rate).&nbsp; Or do you mean a
generalization of the "signal type" to include these new fields for a
"light path" (or whatever we choose or are allowed to call it). And
this information is, in effect, lower layer information and hence
appropriate to the WSON discussions.<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <blockquote dir="ltr" style="margin-right: 0px;">
    <blockquote
 cite="mid:[email-masked]"
 type="cite">
      <blockquote dir="ltr" style="margin-right: 0px;">
        <pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

    </pre>
      </blockquote>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

    </pre>
  </blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

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

--------------040305060204000609090805--

Delivery-date: Wed, 23 Jul 2008 23:24:37 +0000
Date: Thu, 24 Jul 2008 08:19:54 +0900
From: Kohei Shiomoto <[email-masked]>
To: "Ccamp (E-mail)" <[email-masked]>, [email-masked], [email-masked]
Subject: MPLS 2008 to take place in October 19-22, 2008 in Washington, DC (www.mpls2008.com)

MPLS 2008 to take place in October 19-22, 2008 in Washington, DC
(www.mpls2008.com <_http://www.mpls2008.com_> )

MPLS2008, the 11th annual International Conference on MPLS and Related
Technologies, and the major event in next generation Internet will be
held October 19-22 in Washington, DC.

This will be followed by a public Interop demo on October 23 at Isocore
facilities.

The full program is available at
_http://www.isocore.com/mpls2008/program/technical_sessions.htm_ . MPLS
2008 will include an extensive four day program that consists of
tutorials, technical sessions, panels, and exhibits. The key topics to
be discussed at this year$B!G(Bs conference include: MPLS applicability in
transport, Carrier Ethernet deployments and experiences, IPv6
transition, Multicast over Ethernet and MPLS, Mobile and Wireless
backhaul, Content Delivery, Resiliency, and OAM aspects.

Registration for MPLS2008 is open now at
_http://www.isocore.com/mpls2008/registration/attendees.htm_.

The rooms are limited and hotel reservations can be made at:
_http://www.isocore.com/mpls2008/hotel.htm_.

A public interop demo is also scheduled with the conference -
_http://www.mpls2008.com/program/inter_op.htm

_We look forward to seeing at the conference!

Regards,
Kohei

Delivery-date: Wed, 23 Jul 2008 16:05:53 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Date: Wed, 23 Jul 2008 11:05:25 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Cc: "Ccamp (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8ECDD.EAFB745C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Greg,
=20
Responses.
=20
Snigdho

-----Original Message-----
From: Greg Bernstein [mailto:[email-masked]]
Sent: Wednesday, July 23, 2008 10:30 AM
To: Bardalai, Snigdho
Cc: Ccamp (E-mail)
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

Hi Snigdho, responses below.

--Snip--=20

-----> What is a "WSON signal" is a key question we are trying to nail =
down hear and with the framework draft. Sorry to lead you astray with =
the "wireless" backhaul application.  We are primarily concerned with =
digital signals as is the case for G.872 and G.709.  However =
specification of the signal type such as STM-256 is not sufficient =
anymore since the same signal type may employ different modulations. In =
ITU-T G.959.1 (March 2006) they introduce general signal classes to =
differentiate this, i.e., NRZ 40G and RZ 40G. This ITU-T spec and many =
others including G.872 lay the foundation for what we need to =
characterize a "WSON signal" for our purposes...
[Bardalai, Snigdho] Is specification of the STM-256 modulation scheme a =
WSON specific issue? Should this not be addressed generally from a GMPLS =
perspective?=20

--->     GMPLS is a general approach that includes a base set of =
protocols plus extensions. STM-256's are handled with the SONET/SDH =
extensions detailed in RFC4606. From a layering perspective I'd argue =
against modifying RFC4606 since that document and its predecessor dealt =
with the digital (TDM) signals and their multiplexing structure. Hence =
I'd think it more prudent to model the fact that a given digital signal =
(STM, or Ethernet say) can have more than optical modulation or FEC =
schemes at an appropriate "optical layer".
[Bardalai, Snigdho] Why not extend RFC4328? G.709 allows STMx over OCh.=20

--snip--

------> Let me clarify this a bit. GMPLS signaling utilizing the "label =
set" feature already supports distributed wavelength assignment. However =
this technique encounters a problem when we attempt to use it for =
bi-directional signals per current GMPLS standards. See the Framework =
document for more details. Hence this requirement is really a request to =
fix something that is broken not add a whole new class of functionality.
[Bardalai, Snigdho] This seems to an general GMPLS issue wrt specifying =
the "label set" for the reverse direction traffic. Again, why is this =
specific to WSON?

---> Extensions to GMPLS protocols may or may not be specific to a =
technology or an application area.  However the demand for an extension =
to GMPLS must stem from some concrete requirement.  Hence when we look =
at GMPLS RSVP-TE signaling as specified in RFC3473 you see that it is =
updated by RFC 4003,RFC 4201,RFC 4420,RFC 4783,RFC 4873,RFC 4874,RFC =
4974,RFC 5063,RFC 5151.  And these are all the extensions available for =
use in "GMPLS RSVP-TE".  You'll see another example of this in Dublin =
where the VCAT/LCAS draft needed some kind of call object, similarly for =
some Ethernet service stuff and it turns out that the MRN draft has a =
CALL_OPS defined which the other drafts will use.
[Bardalai, Snigdho] Could this be part of an extension of RFC4328 ???=20

--snip--

------->  "bit rate" is a standard GMPLS/MPLS-TE signaling parameter, =
though it is actually specified in bytes per second and specified as a =
32 bit IEEE floating point number so this isn't a new parameter for =
GMPLS.  I'm looking at "necessary" "optical/physical" parameters since =
we know the signal types such as OTUk, STM-x, GigE, etc... When we =
encounter OEO devices such as wavelength converters or regenerators many =
of these can accomodate multiple signal types but need this basic low =
level information to determine compatibility. ITU-T G.872 Annex A tells =
us what information we must have to determine compatibility with a =
particular level of regenerator (and hence we can use this for OEO based =
wavelength converters too).
[Bardalai, Snigdho] Why is it necessary to encode additional =
"optical/physical" parameters for O-E-O regeneration? What is the basis =
of your assumption? =20

---> Hmm, I thought this was clear from the above: "When we encounter =
OEO devices such as wavelength converters or regenerators many of these =
can accomodate multiple signal types but need this basic low level =
information to determine compatibility."  By including such information =
as modulation type, modulation parameters, and bit rate in signaling we =
can configure the devices along the path.  For example a 3R regenerator =
or OEO based wavelength converter is needs timing (bit rate) information =
(see ITU-T G.872 Annex A).
[Bardalai, Snigdho] Sorry, my question was not clear. What is preventing =
us from using the "signal type" for this purpose?=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 (510) 573-2237

   =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 (510) 573-2237

------_=_NextPart_001_01C8ECDD.EAFB745C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D715365615-23072008>Hi=20
Greg,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D715365615-23072008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D715365615-23072008>Responses.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D715365615-23072008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D715365615-23072008>Snigdho</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Greg Bernstein=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July =
23, 2008=20
  10:30 AM<BR><B>To:</B> Bardalai, Snigdho<BR><B>Cc:</B> Ccamp=20
  (E-mail)<BR><B>Subject:</B> Re: Comments on=20
  draft-bernstein-ccamp-wson-signaling-02.txt<BR><BR></FONT></DIV>Hi =
Snigdho,=20
  responses below.<BR><BR><FONT color=3Dblue><FONT size=3D2><FONT=20
  face=3DArial>--Snip--</FONT></FONT></FONT>=20
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
l=20
  type=3D"cite">
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">-----&gt; What is =
a "WSON=20
      signal" is a key question we are trying to nail down hear and with =
the=20
      framework draft. Sorry to lead you astray with the "wireless" =
backhaul=20
      application.&nbsp; We are primarily concerned with digital signals =
as is=20
      the case for G.872 and G.709.&nbsp; However specification of the =
signal=20
      type such as STM-256 is not sufficient anymore since the same =
signal type=20
      may employ different modulations. In ITU-T G.959.1 (March 2006) =
they=20
      introduce general signal classes to differentiate this, i.e., NRZ =
40G and=20
      RZ 40G. This ITU-T spec and many others including G.872 lay the =
foundation=20
      for what we need to characterize a "WSON signal" for our=20
      purposes...<BR><FONT color=3D#00ffff><SPAN =
class=3D380453119-22072008><FONT=20
      face=3DArial size=3D2><FONT color=3D#ff0000>[Bardalai, =
Snigdho]&nbsp;Is=20
      specification of the STM-256 modulation scheme a WSON specific=20
      issue?&nbsp;Should&nbsp;this not be addressed generally from a =
GMPLS=20
      perspective?</FONT>=20
  =
</FONT></SPAN><BR></FONT></BLOCKQUOTE></BLOCKQUOTE>---&gt;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
  GMPLS is a general approach that includes a base set of protocols plus =

  extensions. STM-256's are handled with the SONET/SDH extensions =
detailed in=20
  RFC4606. From a layering perspective I'd argue against modifying =
RFC4606 since=20
  that document and its predecessor dealt with the digital (TDM) signals =
and=20
  their multiplexing structure. Hence I'd think it more prudent to model =
the=20
  fact that a given digital signal (STM, or Ethernet say) can have more =
than=20
  optical modulation or FEC schemes at an appropriate "optical =
layer".<BR><SPAN=20
  class=3D715365615-23072008><FONT face=3DArial color=3D#0000ff =
size=3D2>[Bardalai,=20
  Snigdho]&nbsp;Why not extend RFC4328? G.709 allows STMx&nbsp;over=20
  OCh.&nbsp;</FONT></SPAN><BR><BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
l=20
  type=3D"cite">
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <BLOCKQUOTE =
cite=3Dmid:[email-masked]=20
      type=3D"cite">
        <DIV class=3DSection1>
        <BLOCKQUOTE=20
        style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in">
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN=20
          style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV>
          <DIV><FONT color=3Dnavy><FONT size=3D2><FONT=20
          =
face=3DArial><I><B>--snip--</B></I></FONT></FONT></FONT></DIV></BLOCKQUOT=
E></DIV></BLOCKQUOTE>------&gt;=20
      Let me clarify this a bit. GMPLS signaling utilizing the "label =
set"=20
      feature already supports distributed wavelength assignment. =
However this=20
      technique encounters a problem when we attempt to use it for=20
      bi-directional signals per current GMPLS standards. See the =
Framework=20
      document for more details. Hence this requirement is really a =
request to=20
      fix something that is broken not add a whole new class of=20
      functionality.<BR><FONT color=3D#ff0000><SPAN =
class=3D380453119-22072008><FONT=20
      face=3DArial size=3D2>[Bardalai, Snigdho]&nbsp;This seems to an =
general GMPLS=20
      issue wrt specifying the "label set" for the reverse=20
      direction&nbsp;traffic. Again, why is this specific to=20
      WSON?</FONT></SPAN><BR></FONT></BLOCKQUOTE></BLOCKQUOTE>---&gt; =
Extensions to=20
  GMPLS protocols may or may not be specific to a technology or an =
application=20
  area.&nbsp; However the demand for an extension to GMPLS must stem =
from some=20
  concrete requirement.&nbsp; Hence when we look at GMPLS RSVP-TE =
signaling as=20
  specified in RFC3473 you see that it is <B>updated by</B> <FONT=20
  color=3D#330033>RFC 4003,RFC 4201,RFC 4420,RFC 4783,RFC 4873,RFC =
4874,RFC=20
  4974,RFC 5063,RFC 5151.&nbsp; And these are all the extensions =
available for=20
  use in "GMPLS RSVP-TE".&nbsp; You'll see another example of this in =
Dublin=20
  where the VCAT/LCAS draft needed some kind of call object, similarly =
for some=20
  Ethernet service stuff and it turns out that the MRN draft has a =
CALL_OPS=20
  defined which the other drafts will use.<BR><SPAN=20
  class=3D715365615-23072008><FONT face=3DArial color=3D#0000ff =
size=3D2>[Bardalai,=20
  Snigdho]&nbsp;Could this be part of an extension&nbsp;of RFC4328=20
  ???&nbsp;</FONT></SPAN><BR></FONT>
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
l=20
  type=3D"cite">
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <BLOCKQUOTE =
cite=3Dmid:[email-masked]=20
      type=3D"cite">
        <DIV class=3DSection1>
        <BLOCKQUOTE=20
        style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in">
          <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">--snip--</SPAN></FONT><BR></P></BLOCKQUOTE></DIV></BLOCKQUOTE>----=
---&gt;&nbsp;=20
      "bit rate" is a standard GMPLS/MPLS-TE signaling parameter, though =
it is=20
      actually specified in bytes per second and specified as a 32 bit =
IEEE=20
      floating point number so this isn't a new parameter for =
GMPLS.&nbsp; I'm=20
      looking at "necessary" "optical/physical" parameters since we know =
the=20
      signal types such as OTUk, STM-x, GigE, etc... When we encounter =
OEO=20
      devices such as wavelength converters or regenerators many of =
these can=20
      accomodate multiple signal types but need this basic low level =
information=20
      to determine compatibility. ITU-T G.872 Annex A tells us what =
information=20
      we must have to determine compatibility with a particular level of =

      regenerator (and hence we can use this for OEO based wavelength =
converters=20
      too).<BR><FONT color=3D#800000><SPAN =
class=3D380453119-22072008><FONT=20
      face=3DArial size=3D2><FONT color=3D#ff0000>[Bardalai, =
Snigdho]&nbsp;Why is it=20
      necessary to encode additional "optical/physical" parameters for =
O-E-O=20
      regeneration? What is the basis of your=20
      assumption?</FONT>&nbsp;</FONT></SPAN></FONT> <FONT =
color=3Dblack><FONT=20
      size=3D2><FONT=20
  face=3D"Courier =
New"></FONT></FONT></FONT><BR></BLOCKQUOTE></BLOCKQUOTE>---&gt;=20
  Hmm, I thought this was clear from the above: "When we encounter OEO =
devices=20
  such as wavelength converters or regenerators many of these can =
accomodate=20
  multiple signal types but need this basic low level information to =
determine=20
  compatibility."&nbsp; By including such information as modulation =
type,=20
  modulation parameters, and bit rate in signaling we can configure the =
devices=20
  along the path.&nbsp; For example a 3R regenerator or OEO based =
wavelength=20
  converter is needs timing (bit rate) information (see ITU-T G.872 =
Annex=20
  A).<BR><SPAN class=3D715365615-23072008><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>[Bardalai, Snigdho]&nbsp;Sorry, my question was not clear. =
What is=20
  preventing us from using the "signal type" for this=20
  purpose?&nbsp;</FONT></SPAN><BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
l=20
  type=3D"cite">
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><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></BLOCKQUOTE></BLOCKQUOTE><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></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C8ECDD.EAFB745C--

Delivery-date: Wed, 23 Jul 2008 15:32:52 +0000
Date: Wed, 23 Jul 2008 08:30:08 -0700
From: Greg Bernstein <[email-masked]>
To: "Bardalai, Snigdho" <[email-masked]>
CC: "Ccamp (E-mail)" <[email-masked]>
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

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

Hi Snigdho, responses below.

--Snip--
>
>     -----> What is a "WSON signal" is a key question we are trying to
>     nail down hear and with the framework draft. Sorry to lead you
>     astray with the "wireless" backhaul application.  We are primarily
>     concerned with digital signals as is the case for G.872 and
>     G.709.  However specification of the signal type such as STM-256
>     is not sufficient anymore since the same signal type may employ
>     different modulations. In ITU-T G.959.1 (March 2006) they
>     introduce general signal classes to differentiate this, i.e., NRZ
>     40G and RZ 40G. This ITU-T spec and many others including G.872
>     lay the foundation for what we need to characterize a "WSON
>     signal" for our purposes...
>     [Bardalai, Snigdho] Is specification of the STM-256 modulation
>     scheme a WSON specific issue? Should this not be addressed
>     generally from a GMPLS perspective?
>
--->     GMPLS is a general approach that includes a base set of 
protocols plus extensions. STM-256's are handled with the SONET/SDH 
extensions detailed in RFC4606. From a layering perspective I'd argue 
against modifying RFC4606 since that document and its predecessor dealt 
with the digital (TDM) signals and their multiplexing structure. Hence 
I'd think it more prudent to model the fact that a given digital signal 
(STM, or Ethernet say) can have more than optical modulation or FEC 
schemes at an appropriate "optical layer".
>
>>         /*--snip--*/
>>
>     ------> Let me clarify this a bit. GMPLS signaling utilizing the
>     "label set" feature already supports distributed wavelength
>     assignment. However this technique encounters a problem when we
>     attempt to use it for bi-directional signals per current GMPLS
>     standards. See the Framework document for more details. Hence this
>     requirement is really a request to fix something that is broken
>     not add a whole new class of functionality.
>     [Bardalai, Snigdho] This seems to an general GMPLS issue wrt
>     specifying the "label set" for the reverse direction traffic.
>     Again, why is this specific to WSON?
>
---> Extensions to GMPLS protocols may or may not be specific to a 
technology or an application area.  However the demand for an extension 
to GMPLS must stem from some concrete requirement.  Hence when we look 
at GMPLS RSVP-TE signaling as specified in RFC3473 you see that it is 
*updated by* RFC 4003,RFC 4201,RFC 4420,RFC 4783,RFC 4873,RFC 4874,RFC 
4974,RFC 5063,RFC 5151.  And these are all the extensions available for 
use in "GMPLS RSVP-TE".  You'll see another example of this in Dublin 
where the VCAT/LCAS draft needed some kind of call object, similarly for 
some Ethernet service stuff and it turns out that the MRN draft has a 
CALL_OPS defined which the other drafts will use.
>
>>         --snip--
>>
>     ------->  "bit rate" is a standard GMPLS/MPLS-TE signaling
>     parameter, though it is actually specified in bytes per second and
>     specified as a 32 bit IEEE floating point number so this isn't a
>     new parameter for GMPLS.  I'm looking at "necessary"
>     "optical/physical" parameters since we know the signal types such
>     as OTUk, STM-x, GigE, etc... When we encounter OEO devices such as
>     wavelength converters or regenerators many of these can accomodate
>     multiple signal types but need this basic low level information to
>     determine compatibility. ITU-T G.872 Annex A tells us what
>     information we must have to determine compatibility with a
>     particular level of regenerator (and hence we can use this for OEO
>     based wavelength converters too).
>     [Bardalai, Snigdho] Why is it necessary to encode additional
>     "optical/physical" parameters for O-E-O regeneration? What is the
>     basis of your assumption? 
>
---> Hmm, I thought this was clear from the above: "When we encounter 
OEO devices such as wavelength converters or regenerators many of these 
can accomodate multiple signal types but need this basic low level 
information to determine compatibility."  By including such information 
as modulation type, modulation parameters, and bit rate in signaling we 
can configure the devices along the path.  For example a 3R regenerator 
or OEO based wavelength converter is needs timing (bit rate) information 
(see ITU-T G.872 Annex A).
>
>     -- 
>     ===================================================
>     Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>         
>

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

--------------040509010403000802080901
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 Snigdho, responses below.<br>
<br>
<font color="blue"><font size="2"><font face="Arial">--Snip--</font></font></font>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <blockquote dir="ltr" style="margin-right: 0px;">-----&gt; What is a
"WSON signal" is a key question we are trying to nail down hear and
with the framework draft. Sorry to lead you astray with the "wireless"
backhaul application.&nbsp; We are primarily concerned with digital signals
as is the case for G.872 and G.709.&nbsp; However specification of the
signal type such as STM-256 is not sufficient anymore since the same
signal type may employ different modulations. In ITU-T G.959.1 (March
2006) they introduce general signal classes to differentiate this,
i.e., NRZ 40G and RZ 40G. This ITU-T spec and many others including
G.872 lay the foundation for what we need to characterize a "WSON
signal" for our purposes...<br>
    <font color="#00ffff"><span class="380453119-22072008"><font
 face="Arial" size="2"><font color="#ff0000">[Bardalai, Snigdho]&nbsp;Is
specification of the STM-256 modulation scheme a WSON specific
issue?&nbsp;Should&nbsp;this not be addressed generally from a GMPLS perspective?</font>
    </font></span><br>
    </font></blockquote>
</blockquote>
---&gt;&nbsp;&nbsp;&nbsp;&nbsp; GMPLS is a general approach that includes a base set of
protocols plus extensions. STM-256's are handled with the SONET/SDH
extensions detailed in RFC4606. From a layering perspective I'd argue
against modifying RFC4606 since that document and its predecessor dealt
with the digital (TDM) signals and their multiplexing structure. Hence
I'd think it more prudent to model the fact that a given digital signal
(STM, or Ethernet say) can have more than optical modulation or FEC
schemes at an appropriate "optical layer".<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <blockquote dir="ltr" style="margin-right: 0px;">
    <blockquote
 cite="mid:[email-masked]" type="cite">
      <div class="Section1">
      <blockquote
 style="margin-top: 5pt; margin-bottom: 5pt; margin-right: 0in;">
        <div>
        <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span style="font-size: 12pt;"><O:P></O:P></span></font></p>
        </div>
        <div><font color="navy"><font size="2"><font face="Arial"><i><b>--snip--</b></i></font></font></font></div>
      </blockquote>
      </div>
    </blockquote>
------&gt; Let me clarify this a bit. GMPLS signaling utilizing the
"label set" feature already supports distributed wavelength assignment.
However this technique encounters a problem when we attempt to use it
for bi-directional signals per current GMPLS standards. See the
Framework document for more details. Hence this requirement is really a
request to fix something that is broken not add a whole new class of
functionality.<br>
    <font color="#ff0000"><span class="380453119-22072008"><font
 face="Arial" size="2">[Bardalai, Snigdho]&nbsp;This seems to an general
GMPLS issue wrt specifying the "label set" for the reverse
direction&nbsp;traffic. Again, why is this specific to WSON?</font></span><br>
    </font></blockquote>
</blockquote>
---&gt; Extensions to GMPLS protocols may or may not be specific to a
technology or an application area.&nbsp; However the demand for an extension
to GMPLS must stem from some concrete requirement.&nbsp; Hence when we look
at GMPLS RSVP-TE signaling as specified in RFC3473 you see that it is <b>updated
by</b> <font color="#330033">RFC 4003,RFC 4201,RFC 4420,RFC 4783,RFC
4873,RFC 4874,RFC 4974,RFC 5063,RFC 5151.&nbsp; And these are all the
extensions available for use in "GMPLS RSVP-TE".&nbsp; You'll see another
example of this in Dublin where the VCAT/LCAS draft needed some kind of
call object, similarly for some Ethernet service stuff and it turns out
that the MRN draft has a CALL_OPS defined which the other drafts will
use.<br>
</font>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <blockquote dir="ltr" style="margin-right: 0px;">
    <blockquote
 cite="mid:[email-masked]" type="cite">
      <div class="Section1">
      <blockquote
 style="margin-top: 5pt; margin-bottom: 5pt; margin-right: 0in;">
        <p class="MsoNormal"><font color="blue" face="Arial" size="2"><span
 style="font-size: 10pt; color: blue; font-family: Arial;">--snip--</span></font><br>
        </p>
      </blockquote>
      </div>
    </blockquote>
-------&gt;&nbsp; "bit rate" is a standard GMPLS/MPLS-TE signaling
parameter, though it is actually specified in bytes per second and
specified as a 32 bit IEEE floating point number so this isn't a new
parameter for GMPLS.&nbsp; I'm looking at "necessary" "optical/physical"
parameters since we know the signal types such as OTUk, STM-x, GigE,
etc... When we encounter OEO devices such as wavelength converters or
regenerators many of these can accomodate multiple signal types but
need this basic low level information to determine compatibility. ITU-T
G.872 Annex A tells us what information we must have to determine
compatibility with a particular level of regenerator (and hence we can
use this for OEO based wavelength converters too).<br>
    <font color="#800000"><span class="380453119-22072008"><font
 face="Arial" size="2"><font color="#ff0000">[Bardalai, Snigdho]&nbsp;Why is
it necessary to encode additional "optical/physical" parameters for
O-E-O regeneration? What is the basis of your assumption?</font>&nbsp;</font></span></font>
    <font color="black"><font size="2"><font face="Courier New"></font></font></font><br>
  </blockquote>
</blockquote>
---&gt; Hmm, I thought this was clear from the above: "When we
encounter OEO devices such as wavelength converters or regenerators
many of these can accomodate multiple signal types but need this basic
low level information to determine compatibility."&nbsp; By including such
information as modulation type, modulation parameters, and bit rate in
signaling we can configure the devices along the path.&nbsp; For example a
3R regenerator or OEO based wavelength converter is needs timing (bit
rate) information (see ITU-T G.872 Annex A).<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <blockquote dir="ltr" style="margin-right: 0px;">
    <pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

    </pre>
  </blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

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

--------------040509010403000802080901--

Delivery-date: Wed, 23 Jul 2008 08:46:57 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Missing I-D on the agenda
Date: Wed, 23 Jul 2008 09:01:15 +0100

Hi,

Zhihong Kang submitted his I-D on 7th July, but it hasn't shown up in the 
repository.

Since it is on the agenda for the second CCAMP session, I have put a copy 
at...

http://www.olddog.co.uk/download/draft-kang-ccamp-wdm-switch-info-00.txt

Cheers,
Adrian 

Delivery-date: Wed, 23 Jul 2008 00:44:06 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: "Final" agenda posted
Date: Tue, 22 Jul 2008 23:03:45 +0100

Hi,

We revised the agenda a little to make it fit with people's other 
commitments.

Please take a look to make sure you don't miss the bits you are interested 
in.

Send in you slides as soon as you can.

Thanks,
Adrian 

Delivery-date: Tue, 22 Jul 2008 19:39:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Date: Tue, 22 Jul 2008 14:38:56 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, "Young Lee" <[email-masked]>
Cc: "Ccamp (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8EC32.94512D44
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Greg,
=20
Responses below.
=20
Snigdho

-----Original Message-----
From: Greg Bernstein [mailto:[email-masked]]
Sent: Tuesday, July 22, 2008 11:08 AM
To: Young Lee
Cc: Bardalai, Snigdho; 'Ccamp (E-mail)'
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

Hi Snigdho, Young and all.  A few clarifications and comments below

Greg

---snip---

Bardalai, Snigdho wrote:=20

Hi Greg et al,=20

I have a few comments on this draft proposal.=20

1. I believe basic WSON signaling extensions should be separated from =
signaling based RWA solutions. The reason is the scope of each problem =
is different.

There are three basic requirements in the signaling draft (a) =
characterization of WSON signals, (b) bi-directional distributed =
wavelength assignment for WSON signals, and (c) an option for specifying =
the distributed wavelength assignment method to be used at each node. =
Items (a) and (c) were from Young and my original draft and (b) was from =
Sugang, Hiroki and Dan King's draft which the chairs mentioned we should =
merge with ours. Is item (c) bothering you? Or the combination of (a) =
with (b) and (c).  We wanted the WG's opinion on item (c).
[Bardalai, Snigdho] May I ask what is a "WSON signal" ? Somewhere below =
you mention a "wireless" application, what application is this, what =
std. is it based on? It seems we are assuming something about the =
data-plane here. If that is not clearly defined how can we discuss about =
characterization? On the other hand I can completely understand what (b) =
and (c) is refering to.

-----> What is a "WSON signal" is a key question we are trying to nail =
down hear and with the framework draft. Sorry to lead you astray with =
the "wireless" backhaul application.  We are primarily concerned with =
digital signals as is the case for G.872 and G.709.  However =
specification of the signal type such as STM-256 is not sufficient =
anymore since the same signal type may employ different modulations. In =
ITU-T G.959.1 (March 2006) they introduce general signal classes to =
differentiate this, i.e., NRZ 40G and RZ 40G. This ITU-T spec and many =
others including G.872 lay the foundation for what we need to =
characterize a "WSON signal" for our purposes...
[Bardalai, Snigdho] Is specification of the STM-256 modulation scheme a =
WSON specific issue? Should this not be addressed generally from a GMPLS =
perspective?=20

Hence, I believe the scope of (a) is different from (b) and (c). (b) and =
(c) are addressing some specific issues of distributed (signaling based) =
RWA.

[Young] (b) actually does not deal with "distributed" wavelength =
assignment." Perhaps, we have to clarify some of the wordings used in =
the current draft to avoid misunderstanding. The main focus of (b) is =
how to permit simultaneous bi-directional wavelength assignment. It =
defines a signalling mechanism for same wavelength bidirectional =
lightpath to reduce setup times and lowers blocking probability. The =
exact wavelength to use hop-by-hop can be assigned by the PCE or by the =
NE.=20

------> Let me clarify this a bit. GMPLS signaling utilizing the "label =
set" feature already supports distributed wavelength assignment. However =
this technique encounters a problem when we attempt to use it for =
bi-directional signals per current GMPLS standards. See the Framework =
document for more details. Hence this requirement is really a request to =
fix something that is broken not add a whole new class of functionality.
[Bardalai, Snigdho] This seems to an general GMPLS issue wrt specifying =
the "label set" for the reverse direction traffic. Again, why is this =
specific to WSON?

As for (c), we are asking the WG as Greg said before if we should retain =
it or not --- This is an optional feature for sure.=20

The other concern is compliance to such a document. Typically there will =
be a choice between distributed (signaling based) or centralized =
(PCE/routing based) RWA, but (a) would be required to be supported for =
both RWA approaches. Hence I would consider (a) to be a basic =
requirement. I believe that we are mixing too many things here.

2. I believe we have not yet established what level of client layer =
characterization should be included in an OCH layer LSP. For that matter =
the definition of "Lightpath" is not yet completed and agreed.

--> In the e-mail I sent concerning the WSON Framework document I =
brought up the issue of "lightpath" definition.  In a more detailed =
reading of G.709 and G.872 I got the impression that OCh is a bit too =
restrictive. In G.709 it is defined from 3R to 3R.  Now we want to =
include wavelength converters even if we are not currently dealing with =
impairments and most wavelength converters are regenerators (2R or 3R) =
with tunable lasers. G.872 doesn't consider the wavelength of the =
optical signal part of its characteristic information hence an OCh can =
go through a wavelength converter and they give an example in Appendix =
I. =20
[Bardalai, Snigdho] Thanks for the clarification.=20

3. Basic WSON signaling should be in alignment with G.872 and G.709 =
concepts.=20

Agree. Note that RFC4328 covers the standard G.709 digital hierarchy. =
For signals not in the G.709 digital hierarchy the concepts and =
terminology of G.709/G.872 still apply (with some caveats): the OCh =
(optical channel), OMS (optical multiplex section), OTS (optical =
transmission section), and Physical Media Layer (the optical fiber =
itself). It seems that G.709 and G.872 have slightly different notions =
of what an OCh is (G.709 seeming more restrictive).
Now from the practical side of things there are standards at the ITU-T =
that actually talk about characterizing the signals like G.696.1. To =
determine receiver compatibility we can run into trouble with a higher =
layer signal designation such as STM-256 since different modulation (RZ, =
NRZ) maybe used. Hence the ITU-T started defining signal classes by (a) =
modulation, (b) modulation parameters (if any), (c) bit rate, and (d) =
FEC.

4. If optical impairments is not in the current scope why do we need to =
encode "analog bit rate", will the client layer signal type (i.e. =
SONET/SDH or ODUk etc.) not be sufficient for your purposes?

--> Do you mean "analog bandwidth"? Although G.872 are aimed at =
transport of digital signals, I recall a request from someone to include =
some minimum ability to deal with "analog signals" for an application =
where wireless signals were put over the fiber without much processing.
If you meant "bit rate" for a digital signal compatibility with the =
receiver and any OEO based wavelength converters...
[Bardalai, Snigdho] I meant "bit rate". I don't think bit-rate, mod and =
FEC is sufficient for OEO based digital signal compatibility, which =
means information such as encoding type, signal type etc. is necessary. =
Given that I cannot understand why we need to include the "analog bit =
rate", because based on signal type information it is possible to derive =
the bit-rate. Also, without completely understanding the wireless =
application it is not possible to say if we do require the analog =
bandwidth, so I will defer my comment on that till I understand what you =
are refering to.

------->  "bit rate" is a standard GMPLS/MPLS-TE signaling parameter, =
though it is actually specified in bytes per second and specified as a =
32 bit IEEE floating point number so this isn't a new parameter for =
GMPLS.  I'm looking at "necessary" "optical/physical" parameters since =
we know the signal types such as OTUk, STM-x, GigE, etc... When we =
encounter OEO devices such as wavelength converters or regenerators many =
of these can accomodate multiple signal types but need this basic low =
level information to determine compatibility. ITU-T G.872 Annex A tells =
us what information we must have to determine compatibility with a =
particular level of regenerator (and hence we can use this for OEO based =
wavelength converters too).
[Bardalai, Snigdho] Why is it necessary to encode additional =
"optical/physical" parameters for O-E-O regeneration? What is the basis =
of your assumption?=20

Thanks,=20
Snigdho=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 (510) 573-2237
=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 (510) 573-2237

------_=_NextPart_001_01C8EC32.94512D44
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D380453119-22072008>Hi=20
Greg,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D380453119-22072008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D380453119-22072008>Responses below.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D380453119-22072008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D380453119-22072008>Snigdho</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Greg Bernstein=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, July 22, =
2008=20
  11:08 AM<BR><B>To:</B> Young Lee<BR><B>Cc:</B> Bardalai, Snigdho; =
'Ccamp=20
  (E-mail)'<BR><B>Subject:</B> Re: Comments on=20
  draft-bernstein-ccamp-wson-signaling-02.txt<BR><BR></FONT></DIV>Hi =
Snigdho,=20
  Young and all.&nbsp; A few clarifications and comments=20
  below<BR><BR>Greg<BR><BR><FONT color=3Dblack><FONT size=3D3><FONT=20
  face=3D"Times New Roman">---snip---</FONT></FONT></FONT><BR>
  <BLOCKQUOTE cite=3Dmid:[email-masked] =

  type=3D"cite">
    <DIV class=3DSection1>
    <BLOCKQUOTE=20
      style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><P=20
      class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt">Bardalai, Snigdho wrote:=20
      <O:P></O:P></SPAN></FONT></P>
      <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><!-- Converted from =
text/rtf format -->Hi=20
      Greg et al,</SPAN></FONT> <O:P></O:P></P>
      <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I have a few =
comments on this=20
      draft proposal.</SPAN></FONT> <O:P></O:P></P>
      <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">1. I believe basic =
WSON=20
      signaling extensions should be separated from signaling based RWA=20
      solutions. The reason is the scope of each problem is=20
      different.</SPAN></FONT><O:P></O:P></P>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt">There are three basic requirements in =
the=20
      signaling draft (a) characterization of WSON signals, (b) =
bi-directional=20
      distributed wavelength assignment for WSON signals, and (c) an =
option for=20
      specifying the distributed wavelength assignment method to be used =
at each=20
      node. Items (a) and (c) were from Young and my original draft and =
(b) was=20
      from Sugang, Hiroki and Dan King's draft which the chairs =
mentioned we=20
      should merge with ours. Is item (c) bothering you? Or the =
combination of=20
      (a) with (b) and (c).&nbsp; We wanted the WG's opinion on item=20
      (c).<BR></SPAN></FONT><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">[Bardalai,=20
      Snigdho]&nbsp;May I ask what is a "WSON signal" ? Somewhere below =
you=20
      mention a "wireless" application, what application is this, what =
std. is=20
      it based on? It seems we are assuming something about the =
data-plane here.=20
      If that is not clearly defined how can we discuss about =
characterization?=20
      On the other hand I can completely understand what (b) and (c) is =
refering=20
      =
to.</SPAN></FONT></P></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE>-----&gt; =
What is a=20
  "WSON signal" is a key question we are trying to nail down hear and =
with the=20
  framework draft. Sorry to lead you astray with the "wireless" backhaul =

  application.&nbsp; We are primarily concerned with digital signals as =
is the=20
  case for G.872 and G.709.&nbsp; However specification of the signal =
type such=20
  as STM-256 is not sufficient anymore since the same signal type may =
employ=20
  different modulations. In ITU-T G.959.1 (March 2006) they introduce =
general=20
  signal classes to differentiate this, i.e., NRZ 40G and RZ 40G. This =
ITU-T=20
  spec and many others including G.872 lay the foundation for what we =
need to=20
  characterize a "WSON signal" for our purposes...<BR><FONT =
color=3D#00ffff><SPAN=20
  class=3D380453119-22072008><FONT face=3DArial size=3D2><FONT=20
  color=3D#ff0000>[Bardalai, Snigdho]&nbsp;Is specification of the =
STM-256=20
  modulation scheme a WSON specific issue?&nbsp;Should&nbsp;this not be=20
  addressed generally from a GMPLS=20
  perspective?</FONT>&nbsp;</FONT></SPAN><BR></FONT>
  <BLOCKQUOTE cite=3Dmid:[email-masked] =

  type=3D"cite">
    <DIV class=3DSection1>
    <BLOCKQUOTE=20
      style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hence, =
I=20
      believe&nbsp;the scope of (a) is different from (b) and (c). (b) =
and=20
      (c)&nbsp;are addressing&nbsp;some specific issues of distributed=20
      (signaling based) RWA.</SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><O:P></O:P></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><O:P></O:P></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">[Young] =
(b)=20
      actually does not deal with &#8220;distributed&#8221; wavelength =
assignment.&#8221; Perhaps,=20
      we have to clarify some of the wordings used in the current draft =
to avoid=20
      misunderstanding. The main focus of (b) is how to <B><I><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">permit =
simultaneous=20
      bi-directional wavelength assignment. It=20
      </SPAN></I></B></SPAN></FONT><B><I><FONT face=3DArial color=3Dnavy =

      size=3D2><SPAN lang=3DEN-GB=20
      style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; =
FONT-STYLE: italic; FONT-FAMILY: Arial">defines=20
      a signalling mechanism for same wavelength bidirectional lightpath =
to=20
      reduce setup times and lowers blocking probability. The exact =
wavelength=20
      to use hop-by-hop can be assigned by the PCE or by the NE.=20
      =
</SPAN></FONT></I></B></P></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE>------&gt=
; Let=20
  me clarify this a bit. GMPLS signaling utilizing the "label set" =
feature=20
  already supports distributed wavelength assignment. However this =
technique=20
  encounters a problem when we attempt to use it for bi-directional =
signals per=20
  current GMPLS standards. See the Framework document for more details. =
Hence=20
  this requirement is really a request to fix something that is broken =
not add a=20
  whole new class of functionality.<BR><FONT color=3D#ff0000><SPAN=20
  class=3D380453119-22072008><FONT face=3DArial size=3D2>[Bardalai, =
Snigdho]&nbsp;This=20
  seems to an general GMPLS issue wrt specifying the "label set" for the =
reverse=20
  direction&nbsp;traffic. Again, why is this specific to=20
  WSON?</FONT></SPAN><BR></FONT>
  <BLOCKQUOTE cite=3Dmid:[email-masked] =

  type=3D"cite">
    <DIV class=3DSection1>
    <BLOCKQUOTE=20
      style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As for =
(c), we=20
      are asking the WG as Greg said before if we should retain it or =
not ---=20
      This is an optional feature for sure. =
<O:P></O:P></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The =
other concern=20
      is compliance to such a document. Typically there will be a choice =
between=20
      distributed (signaling based) or centralized (PCE/routing based) =
RWA, but=20
      (a) would&nbsp;be required to be supported for both RWA =
approaches. Hence=20
      I would consider (a) to be a basic requirement. I believe that we =
are=20
      mixing too many things here.</SPAN></FONT><O:P></O:P></P></DIV>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"=20
      =
cite=3Dmid:[email-masked]=
l=20
      type=3D"cite">
        <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">2. I believe we =
have not yet=20
        established what level of client layer characterization should =
be=20
        included in an OCH layer LSP. For that matter the definition of=20
        "Lightpath" is not yet completed and=20
      agreed.</SPAN></FONT><O:P></O:P></P></BLOCKQUOTE>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt">--&gt; In the e-mail I sent concerning =
the WSON=20
      Framework document I brought up the issue of "lightpath" =
definition.&nbsp;=20
      In a more detailed reading of G.709 and G.872 I got the impression =
that=20
      OCh is a bit too restrictive. In G.709 it is defined from 3R to =
3R.&nbsp;=20
      Now we want to include wavelength converters even if we are not =
currently=20
      dealing with impairments and most wavelength converters are =
regenerators=20
      (2R or 3R) with tunable lasers. G.872 doesn't consider the =
wavelength of=20
      the optical signal part of its characteristic information hence an =
OCh can=20
      go through a wavelength converter and they give an example in =
Appendix=20
      I.&nbsp; <BR></SPAN></FONT><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">[Bardalai,=20
      Snigdho]&nbsp;Thanks for the=20
      clarification.&nbsp;</SPAN></FONT><BR><BR><O:P></O:P></P>
      <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">3. Basic WSON =
signaling should=20
      be in alignment with G.872 and G.709 concepts.</SPAN></FONT>=20
      <O:P></O:P></P>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt">Agree. Note that RFC4328 covers the =
standard G.709=20
      digital hierarchy. For signals not in the G.709 digital hierarchy =
the=20
      concepts and terminology of G.709/G.872 still apply (with some =
caveats):=20
      the OCh (optical channel), OMS (optical multiplex section), OTS =
(optical=20
      transmission section), and Physical Media Layer (the optical fiber =

      itself). It seems that G.709 and G.872 have slightly different =
notions of=20
      what an OCh is (G.709 seeming more restrictive).<BR>Now from the =
practical=20
      side of things there are standards at the ITU-T that actually talk =
about=20
      characterizing the signals like G.696.1. To determine receiver=20
      compatibility we can run into trouble with a higher layer signal=20
      designation such as STM-256 since different modulation (RZ, NRZ) =
maybe=20
      used. Hence the ITU-T started defining signal classes by (a) =
modulation,=20
      (b) modulation parameters (if any), (c) bit rate, and (d)=20
      FEC.<BR><O:P></O:P></SPAN></FONT></P>
      <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">4. If optical =
impairments is=20
      not in the current scope why do we need to encode "analog bit =
rate", will=20
      the client layer signal type (i.e. SONET/SDH or ODUk etc.) not be=20
      sufficient for your purposes?</SPAN></FONT><O:P></O:P></P>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt">--&gt; Do you mean "analog bandwidth"? =
Although=20
      G.872 are aimed at transport of digital signals, I recall a =
request from=20
      someone to include some minimum ability to deal with "analog =
signals" for=20
      an application where wireless signals were put over the fiber =
without much=20
      processing.<BR>If you meant "bit rate" for a digital signal =
compatibility=20
      with the receiver and any OEO based wavelength=20
      converters...<BR></SPAN></FONT><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">[Bardalai,=20
      Snigdho]&nbsp;I meant "bit rate". I don't think&nbsp;bit-rate, mod =
and FEC=20
      is sufficient for OEO based digital signal compatibility, which =
means=20
      information such as encoding type, signal type etc. is necessary. =
Given=20
      that I cannot understand why we need to include the "analog bit =
rate",=20
      because based on signal type information it is possible to derive =
the=20
      bit-rate. Also, without completely understanding the wireless =
application=20
      it is not possible to say if we do require the analog bandwidth, =
so I will=20
      defer my comment on that till I understand what you are refering=20
      =
to.</SPAN></FONT><BR></P></BLOCKQUOTE></DIV></BLOCKQUOTE>-------&gt;&nbsp=
;=20
  "bit rate" is a standard GMPLS/MPLS-TE signaling parameter, though it =
is=20
  actually specified in bytes per second and specified as a 32 bit IEEE =
floating=20
  point number so this isn't a new parameter for GMPLS.&nbsp; I'm =
looking at=20
  "necessary" "optical/physical" parameters since we know the signal =
types such=20
  as OTUk, STM-x, GigE, etc... When we encounter OEO devices such as =
wavelength=20
  converters or regenerators many of these can accomodate multiple =
signal types=20
  but need this basic low level information to determine compatibility. =
ITU-T=20
  G.872 Annex A tells us what information we must have to determine=20
  compatibility with a particular level of regenerator (and hence we can =
use=20
  this for OEO based wavelength converters too).<BR><FONT =
color=3D#800000><SPAN=20
  class=3D380453119-22072008><FONT face=3DArial size=3D2><FONT=20
  color=3D#ff0000>[Bardalai, Snigdho]&nbsp;Why is it necessary to encode =

  additional "optical/physical" parameters for O-E-O regeneration? What =
is the=20
  basis of your assumption?</FONT>&nbsp;</FONT></SPAN><BR></FONT>
  <BLOCKQUOTE cite=3Dmid:[email-masked] =

  type=3D"cite">
    <DIV class=3DSection1>
    <BLOCKQUOTE=20
      style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><P=20
      class=3DMsoNormal><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
      face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2></FONT><BR><O:P></O:P></P>
      <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT>=20
      <BR><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Snigdho</SPAN></FONT>=20
      <O:P></O:P></P>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
      face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2></FONT><BR><BR><O:P></O:P></SPAN></FONT></P><PRE><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">-- <O:P></O:P></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<O:P></O:P></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">Dr Greg =
Bernstein, Grotto Networking (510) =
573-2237<O:P></O:P></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><O:P>&nbsp;</O:P></SPAN></FONT></PRE></BLOCKQUOTE></DIV></BLOCKQUOT=
E><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></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C8EC32.94512D44--

Delivery-date: Tue, 22 Jul 2008 18:42:33 +0000
Date: Tue, 22 Jul 2008 14:10:30 -0400
To: Greg Bernstein <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Dublin Draft Agenda
Cc: Lou Berger <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>,[email-masked]

Sounds like a plan...

Lou

At 01:44 PM 7/22/2008, Greg Bernstein wrote:
>Hi Lou, I'll just point out that were planning on using 
>CALL_ATTRIBUTES for VCAT/LCAS signaling and will point out that 
>you'll cover this in a more general context. And this approach is 
>now in Deborah's updated agenda!
>
>Greg
>
>Lou Berger wrote:
>>I was going to cover use of CALL_ATTRIBUTES object in my time slots 
>>(12/13).  Can do otherwise/earlier if desired...
>>
>>Lou
>>
>>At 12:01 PM 7/18/2008, Greg Bernstein wrote:
>>>Hi Deborah and Adrian, for session I on Monday you've got me down 
>>>for 15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-)
>>>Was part of this time for Lou to discuss a general "call 
>>>approach"? If not then I probably only need 10 minutes and will 
>>>talk about an encoding based on the CALL_ATTRIBUTES object class, 
>>>from the MLN extensions draft but using a new C-Type for VCAT/LCAS control.
>>>
>>>Also for session II, the WSON signaling draft will be presented by 
>>>Dan King. This is the merging of the two signaling drafts and the 
>>>title of my submission was a bit more generic than Sugang's.
>>>
>>>Regards
>>>
>>>Greg
>>>
>>>BRUNGARD, DEBORAH A, ATTLABS wrote:
>>>>Hi CCAMP,
>>>>
>>>>We've uploaded a draft agenda:
>>>><http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt 
>>>>
>>>>
>>>>Please let us know if we have missed anything.
>>>>
>>>>Adrian and Deborah
>>>
>>>
>>>--
>>>===================================================
>>>Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>
>--
>===================================================
>Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>

Delivery-date: Tue, 22 Jul 2008 17:45:40 +0000
Date: Tue, 22 Jul 2008 10:44:24 -0700
From: Greg Bernstein <[email-masked]>
To: Lou Berger <[email-masked]>
CC: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, [email-masked]
Subject: Re: Dublin Draft Agenda

Hi Lou, I'll just point out that were planning on using CALL_ATTRIBUTES 
for VCAT/LCAS signaling and will point out that you'll cover this in a 
more general context. And this approach is now in Deborah's updated agenda!

Greg

Lou Berger wrote:
> I was going to cover use of CALL_ATTRIBUTES object in my time slots 
> (12/13).  Can do otherwise/earlier if desired...
>
> Lou
>
> At 12:01 PM 7/18/2008, Greg Bernstein wrote:
>> Hi Deborah and Adrian, for session I on Monday you've got me down for 
>> 15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-)
>> Was part of this time for Lou to discuss a general "call approach"? 
>> If not then I probably only need 10 minutes and will talk about an 
>> encoding based on the CALL_ATTRIBUTES object class, from the MLN 
>> extensions draft but using a new C-Type for VCAT/LCAS control.
>>
>> Also for session II, the WSON signaling draft will be presented by 
>> Dan King. This is the merging of the two signaling drafts and the 
>> title of my submission was a bit more generic than Sugang's.
>>
>> Regards
>>
>> Greg
>>
>> BRUNGARD, DEBORAH A, ATTLABS wrote:
>>> Hi CCAMP,
>>>
>>> We've uploaded a draft agenda:
>>> <http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt 
>>>
>>>
>>> Please let us know if we have missed anything.
>>>
>>> Adrian and Deborah
>>>
>>
>>
>> -- 
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>
>

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

Delivery-date: Tue, 22 Jul 2008 16:49:09 +0000
Content-class: urn:content-classes:message
Subject: RE: [Tsvwg] [mpls] multiple-working group last call ondraft-ietf-mpls-cosfield-def-04.txt
Date: Tue, 22 Jul 2008 09:47:06 -0700
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

What about 'CoS'?=20

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]=20
>Sent: Tuesday, July 22, 2008 9:34 AM
>To: [email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked];=20
>[email-masked]; [email-masked]; [email-masked]
>Subject: Re: [Tsvwg] [mpls] multiple-working group last call=20
>ondraft-ietf-mpls-cosfield-def-04.txt
>
>I tend to agree with Ben - in effect whatever we end up=20
>calling it there should be a clear explanation of what we=20
>think it actually means.
>
>If you are still open to new suggestions how about "traffic=20
>information field" as strictly using it for ECN still isn't=20
>traffic management. Or even "traffic signalling field"
>
>Toby
>
>____________________________________________________________________
>Toby Moncaster, <[email-masked]> Networks Research=20
>Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734=20
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]=20
>On Behalf=20
>> Of Ben Niven-Jenkins
>> Sent: 21 July 2008 16:15
>> To: John Kenney; Loa Andersson
>> Cc: L2VPN; [email-masked]; [email-masked]; ccamp; pwe3;=20
>[email-masked]
>> Subject: Re: [Tsvwg] [mpls] multiple-working group last call on=20
>> draft-ietf-mpls-cosfield-def-04.txt
>>=20
>> I'm not precious about which term we use but if we use Traffic=20
>> Management I think a paragraph should be added explaining what is=20
>> meant to put it in context.
>>=20
>> Ben
>>=20
>>=20
>>=20
>> On 21/07/2008 15:07, "John Kenney" <[email-masked]> wrote:
>>=20
>> > Hi Loa,
>> >=20
>> > This is a good draft.  It's time to rename the EXP field. =20
>While CoS=20
>> > Field may have been a good choice at one time, we've now
>> heard from many
>> > who think it is too narrow for current usage of this field.
>> >=20
>> > I suggest "Traffic Management Field".
>> >=20
>> > Traffic management is a common, generic, and concise term. =20
>> It covers
>> > all current uses of the field: scheduling class, drop=20
>priority, and=20
>> > congestion notification. CoS really only covers the first.=20
> Traffic=20
>> > management is well-scoped to this purpose, and clearly
>> preferable to CoS
>> > in my opinion.
>> >=20
>> > In terms of the draft, I think a simple global substitution
>> of "traffic
>> > management" for "class of service" and of "TM" for "CoS"=20
>> should suffice.
>> >=20
>> > I think in the long run we'll be glad if we bite the bullet
>> now and make
>> > this change.
>> >=20
>> > Best Regards,
>> > John
>> >=20
>> >=20
>> > Loa Andersson wrote:
>> >>=20
>> >> Bob,
>> >>=20
>> >> thanks for useful comments :)
>> >>=20
>> >> Bob Briscoe wrote:
>> >>> Loa,
>> >>>=20
>> >>> I believe this draft has no technical effect. However
>> there is some
>> >>> truth in the idea that names are important.
>> >>>=20
>> >>> So, let's set aside a few clock cycles to consider this...
>> >>>=20
>> >>> 1/ Is CoS a good description of ECN? Given RFC5129=20
>(Using the EXP=20
>> >>> field for ECN in MPLS), is it really appropriate now to
>> call this a
>> >>> CoS field?
>> >>>=20
>> >>> Thinking out loud...
>> >>> - CoS is a signal from an ingress to the interior (a=20
>request for a=20
>> >>> certain class of service),
>> >>> - whereas ECN is a signal from the interior forwarding
>> plane to the
>> >>> egress (a response from the interior saying whether the class of=20
>> >>> service requested was congested).
>> >>>=20
>> >>> The way 5129 was done, two (or more) EXP codepoints can
>> be designated
>> >>> as the same CoS, but one can be used to say "this packet
>> experienced
>> >>> congestion when using this CoS", while the other says=20
>"it didn't".
>> >>> So, I guess I could live with this field being called CoS, even=20
>> >>> though it's not strictly correct. I can't think of
>> anything better.
>> >>=20
>> >> We had the same discussion when we started to discuss this
>> draft, we
>> >> wanted to find a name the covered both cases. We just=20
>couldn't come=20
>> >> with a better name, so we said "Let us call it 'CoS
>> Field'" and change
>> >> it someone comes up with something better.
>> >>=20
>> >> I'm still open to do that change, but time is kind of
>> running out, the
>> >> latest point in time we can do this change is an RFC
>> editor note, when
>> >> the IESG has approved the document.
>> >=20
>>=20
>>=20
>

Delivery-date: Tue, 22 Jul 2008 16:09:29 +0000
Date: Tue, 22 Jul 2008 09:07:46 -0700
From: Greg Bernstein <[email-masked]>
To: Young Lee <[email-masked]>
CC: "'Bardalai, Snigdho'" <[email-masked]>, "'Ccamp (E-mail)'" <[email-masked]>
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

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

Hi Snigdho, Young and all.  A few clarifications and comments below

Greg

---snip---
>
>     Bardalai, Snigdho wrote:
>
>     Hi Greg et al,
>
>     I have a few comments on this draft proposal.
>
>     1. I believe basic WSON signaling extensions should be separated
>     from signaling based RWA solutions. The reason is the scope of
>     each problem is different.
>
>     There are three basic requirements in the signaling draft (a)
>     characterization of WSON signals, (b) bi-directional distributed
>     wavelength assignment for WSON signals, and (c) an option for
>     specifying the distributed wavelength assignment method to be used
>     at each node. Items (a) and (c) were from Young and my original
>     draft and (b) was from Sugang, Hiroki and Dan King's draft which
>     the chairs mentioned we should merge with ours. Is item (c)
>     bothering you? Or the combination of (a) with (b) and (c).  We
>     wanted the WG's opinion on item (c).
>     [Bardalai, Snigdho] May I ask what is a "WSON signal" ? Somewhere
>     below you mention a "wireless" application, what application is
>     this, what std. is it based on? It seems we are assuming something
>     about the data-plane here. If that is not clearly defined how can
>     we discuss about characterization? On the other hand I can
>     completely understand what (b) and (c) is refering to.
>
-----> What is a "WSON signal" is a key question we are trying to nail 
down hear and with the framework draft. Sorry to lead you astray with 
the "wireless" backhaul application.  We are primarily concerned with 
digital signals as is the case for G.872 and G.709.  However 
specification of the signal type such as STM-256 is not sufficient 
anymore since the same signal type may employ different modulations. In 
ITU-T G.959.1 (March 2006) they introduce general signal classes to 
differentiate this, i.e., NRZ 40G and RZ 40G. This ITU-T spec and many 
others including G.872 lay the foundation for what we need to 
characterize a "WSON signal" for our purposes...
>
>     Hence, I believe the scope of (a) is different from (b) and (c).
>     (b) and (c) are addressing some specific issues of distributed
>     (signaling based) RWA.
>
>      
>
>     [Young] (b) actually does not deal with "distributed" wavelength
>     assignment." Perhaps, we have to clarify some of the wordings used
>     in the current draft to avoid misunderstanding. The main focus of
>     (b) is how to */permit simultaneous bi-directional wavelength
>     assignment. It /**/defines a signalling mechanism for same
>     wavelength bidirectional lightpath to reduce setup times and
>     lowers blocking probability. The exact wavelength to use
>     hop-by-hop can be assigned by the PCE or by the NE. /*
>
------> Let me clarify this a bit. GMPLS signaling utilizing the "label 
set" feature already supports distributed wavelength assignment. However 
this technique encounters a problem when we attempt to use it for 
bi-directional signals per current GMPLS standards. See the Framework 
document for more details. Hence this requirement is really a request to 
fix something that is broken not add a whole new class of functionality.
>
>     As for (c), we are asking the WG as Greg said before if we should
>     retain it or not --- This is an optional feature for sure.
>
>     The other concern is compliance to such a document. Typically
>     there will be a choice between distributed (signaling based) or
>     centralized (PCE/routing based) RWA, but (a) would be required to
>     be supported for both RWA approaches. Hence I would consider (a)
>     to be a basic requirement. I believe that we are mixing too many
>     things here.
>
>>     2. I believe we have not yet established what level of client
>>     layer characterization should be included in an OCH layer LSP.
>>     For that matter the definition of "Lightpath" is not yet
>>     completed and agreed.
>>
>     --> In the e-mail I sent concerning the WSON Framework document I
>     brought up the issue of "lightpath" definition.  In a more
>     detailed reading of G.709 and G.872 I got the impression that OCh
>     is a bit too restrictive. In G.709 it is defined from 3R to 3R. 
>     Now we want to include wavelength converters even if we are not
>     currently dealing with impairments and most wavelength converters
>     are regenerators (2R or 3R) with tunable lasers. G.872 doesn't
>     consider the wavelength of the optical signal part of its
>     characteristic information hence an OCh can go through a
>     wavelength converter and they give an example in Appendix I. 
>     [Bardalai, Snigdho] Thanks for the clarification. 
>
>     3. Basic WSON signaling should be in alignment with G.872 and
>     G.709 concepts.
>
>     Agree. Note that RFC4328 covers the standard G.709 digital
>     hierarchy. For signals not in the G.709 digital hierarchy the
>     concepts and terminology of G.709/G.872 still apply (with some
>     caveats): the OCh (optical channel), OMS (optical multiplex
>     section), OTS (optical transmission section), and Physical Media
>     Layer (the optical fiber itself). It seems that G.709 and G.872
>     have slightly different notions of what an OCh is (G.709 seeming
>     more restrictive).
>     Now from the practical side of things there are standards at the
>     ITU-T that actually talk about characterizing the signals like
>     G.696.1. To determine receiver compatibility we can run into
>     trouble with a higher layer signal designation such as STM-256
>     since different modulation (RZ, NRZ) maybe used. Hence the ITU-T
>     started defining signal classes by (a) modulation, (b) modulation
>     parameters (if any), (c) bit rate, and (d) FEC.
>
>     4. If optical impairments is not in the current scope why do we
>     need to encode "analog bit rate", will the client layer signal
>     type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your
>     purposes?
>
>     --> Do you mean "analog bandwidth"? Although G.872 are aimed at
>     transport of digital signals, I recall a request from someone to
>     include some minimum ability to deal with "analog signals" for an
>     application where wireless signals were put over the fiber without
>     much processing.
>     If you meant "bit rate" for a digital signal compatibility with
>     the receiver and any OEO based wavelength converters...
>     [Bardalai, Snigdho] I meant "bit rate". I don't think bit-rate,
>     mod and FEC is sufficient for OEO based digital signal
>     compatibility, which means information such as encoding type,
>     signal type etc. is necessary. Given that I cannot understand why
>     we need to include the "analog bit rate", because based on signal
>     type information it is possible to derive the bit-rate. Also,
>     without completely understanding the wireless application it is
>     not possible to say if we do require the analog bandwidth, so I
>     will defer my comment on that till I understand what you are
>     refering to.
>
------->  "bit rate" is a standard GMPLS/MPLS-TE signaling parameter, 
though it is actually specified in bytes per second and specified as a 
32 bit IEEE floating point number so this isn't a new parameter for 
GMPLS.  I'm looking at "necessary" "optical/physical" parameters since 
we know the signal types such as OTUk, STM-x, GigE, etc... When we 
encounter OEO devices such as wavelength converters or regenerators many 
of these can accomodate multiple signal types but need this basic low 
level information to determine compatibility. ITU-T G.872 Annex A tells 
us what information we must have to determine compatibility with a 
particular level of regenerator (and hence we can use this for OEO based 
wavelength converters too).
>
>
>     Thanks,
>     Snigdho
>
>
>
>     -- 
>
>     ===================================================
>
>     Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>      
>

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

--------------090706080304050302000805
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 Snigdho, Young and all.&nbsp; A few clarifications and comments below<br>
<br>
Greg<br>
<br>
<font color="black"><font size="3"><font face="Times New Roman">---snip---</font></font></font><br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div class="Section1">
  <blockquote
 style="margin-top: 5pt; margin-right: 0in; margin-bottom: 5pt;">
    <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span style="font-size: 12pt;">Bardalai, Snigdho wrote: <o:p></o:p></span></font></p>
    <p><font color="black" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><!-- Converted from text/rtf format -->Hi
Greg et al,</span></font>
    <o:p></o:p></p>
    <p><font color="black" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">I have a few comments on
this draft proposal.</span></font> <o:p></o:p></p>
    <p><font color="black" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">1. I believe basic WSON
signaling extensions should be
separated from signaling based RWA solutions. The reason is the scope
of each
problem is different.</span></font><o:p></o:p></p>
    <div>
    <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span style="font-size: 12pt;">There are three basic
requirements in the signaling
draft (a) characterization of WSON signals, (b) bi-directional
distributed
wavelength assignment for WSON signals, and (c) an option for
specifying the
distributed wavelength assignment method to be used at each node. Items
(a) and
(c) were from Young and my original draft and (b) was from Sugang,
Hiroki and
Dan King's draft which the chairs mentioned we should merge with ours.
Is item
(c) bothering you? Or the combination of (a) with (b) and (c).&nbsp; We
wanted
the WG's opinion on item (c).<br>
    </span></font><font color="blue" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: blue;">[Bardalai,
Snigdho]&nbsp;May I ask what is a "WSON
signal" ? Somewhere below you mention a "wireless" application,
what application is this, what std. is it based on? It seems we are
assuming
something about the data-plane here. If that is not clearly defined how
can we
discuss about characterization? On the other hand I can completely
understand
what (b) and (c) is refering to.</span></font></p>
    </div>
  </blockquote>
  </div>
</blockquote>
-----&gt; What is a "WSON signal" is a key question we are trying to
nail down hear and with the framework draft. Sorry to lead you astray
with the "wireless" backhaul application.&nbsp; We are primarily concerned
with digital signals as is the case for G.872 and G.709.&nbsp; However
specification of the signal type such as STM-256 is not sufficient
anymore since the same signal type may employ different modulations. In
ITU-T G.959.1 (March 2006) they introduce general signal classes to
differentiate this, i.e., NRZ 40G and RZ 40G. This ITU-T spec and many
others including G.872 lay the foundation for what we need to
characterize a "WSON signal" for our purposes...<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div class="Section1">
  <blockquote
 style="margin-top: 5pt; margin-right: 0in; margin-bottom: 5pt;">
    <div>
    <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span style="font-size: 12pt;"><o:p></o:p></span></font></p>
    </div>
    <div>
    <p class="MsoNormal"><font color="blue" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: blue;">Hence, I
believe&nbsp;the scope of (a) is
different from (b) and (c). (b) and (c)&nbsp;are addressing&nbsp;some specific
issues of distributed (signaling based) RWA.</span></font><font
 face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p></o:p></span></font></p>
    <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
    <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">[Young] (b)
actually does not deal with &#8220;distributed&#8221;
wavelength assignment.&#8221; Perhaps, we have to clarify some of the
wordings
used in the current draft to avoid misunderstanding. The main focus of
(b) is how
to <b><i><span style="font-weight: bold; font-style: italic;">permit
simultaneous
bi-directional wavelength assignment. It </span></i></b></span></font><b><i><font
 color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy; font-weight: bold; font-style: italic;"
 lang="EN-GB">defines a signalling
mechanism for same wavelength bidirectional lightpath to reduce setup
times and
lowers blocking probability. The exact wavelength to use hop-by-hop can
be
assigned by the PCE or by the NE. </span></font></i></b></p>
    </div>
  </blockquote>
  </div>
</blockquote>
------&gt; Let me clarify this a bit. GMPLS signaling utilizing the
"label set" feature already supports distributed wavelength assignment.
However this technique encounters a problem when we attempt to use it
for bi-directional signals per current GMPLS standards. See the
Framework document for more details. Hence this requirement is really a
request to fix something that is broken not add a whole new class of
functionality.<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div class="Section1">
  <blockquote
 style="margin-top: 5pt; margin-right: 0in; margin-bottom: 5pt;">
    <div>
    <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">As
for (c), we are asking
the WG as Greg said before if we should retain it or not --- This is an
optional feature for sure. <o:p></o:p></span></font></p>
    </div>
    <div>
    <p class="MsoNormal"><font color="blue" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: blue;">The other
concern is compliance to such a
document. Typically there will be a choice between distributed
(signaling
based) or centralized (PCE/routing based) RWA, but (a) would&nbsp;be
required
to be supported for both RWA approaches. Hence I would consider (a) to
be a
basic requirement. I believe that we are mixing too many things here.</span></font><o:p></o:p></p>
    </div>
    <blockquote style="margin-top: 5pt; margin-bottom: 5pt;"
 cite="mid:[email-masked]"
 type="cite">
      <p><font color="black" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">2. I believe we have not
yet established what level of
client layer characterization should be included in an OCH layer LSP.
For that
matter the definition of "Lightpath" is not yet completed and agreed.</span></font><o:p></o:p></p>
    </blockquote>
    <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span style="font-size: 12pt;">--&gt; In the e-mail I sent
concerning the WSON
Framework document I brought up the issue of "lightpath"
definition.&nbsp; In a more detailed reading of G.709 and G.872 I got the
impression that OCh is a bit too restrictive. In G.709 it is defined
from 3R to
3R.&nbsp; Now we want to include wavelength converters even if we are not
currently dealing with impairments and most wavelength converters are
regenerators (2R or 3R) with tunable lasers. G.872 doesn't consider the
wavelength of the optical signal part of its characteristic information
hence
an OCh can go through a wavelength converter and they give an example
in
Appendix I.&nbsp; <br>
    </span></font><font color="blue" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: blue;">[Bardalai,
Snigdho]&nbsp;Thanks for the
clarification.&nbsp;</span></font><br>
    <br>
    <o:p></o:p></p>
    <p><font color="black" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">3. Basic WSON signaling
should be in alignment with G.872
and G.709 concepts.</span></font> <o:p></o:p></p>
    <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span style="font-size: 12pt;">Agree. Note that RFC4328
covers the standard G.709
digital hierarchy. For signals not in the G.709 digital hierarchy the
concepts
and terminology of G.709/G.872 still apply (with some caveats): the OCh
(optical channel), OMS (optical multiplex section), OTS (optical
transmission
section), and Physical Media Layer (the optical fiber itself). It seems
that
G.709 and G.872 have slightly different notions of what an OCh is
(G.709
seeming more restrictive).<br>
Now from the practical side of things there are standards at the ITU-T
that
actually talk about characterizing the signals like G.696.1. To
determine
receiver compatibility we can run into trouble with a higher layer
signal
designation such as STM-256 since different modulation (RZ, NRZ) maybe
used.
Hence the ITU-T started defining signal classes by (a) modulation, (b)
modulation parameters (if any), (c) bit rate, and (d) FEC.<br>
    <o:p></o:p></span></font></p>
    <p><font color="black" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">4. If optical impairments
is not in the current scope why do
we need to encode "analog bit rate", will the client layer signal
type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your purposes?</span></font><o:p></o:p></p>
    <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span style="font-size: 12pt;">--&gt; Do you mean "analog
bandwidth"?
Although G.872 are aimed at transport of digital signals, I recall a
request
from someone to include some minimum ability to deal with "analog
signals" for an application where wireless signals were put over the
fiber
without much processing.<br>
If you meant "bit rate" for a digital signal compatibility with the
receiver and any OEO based wavelength converters...<br>
    </span></font><font color="blue" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: blue;">[Bardalai,
Snigdho]&nbsp;I meant "bit
rate". I don't think&nbsp;bit-rate, mod and FEC is sufficient for OEO
based digital signal compatibility, which means information such as
encoding
type, signal type etc. is necessary. Given that I cannot understand why
we need
to include the "analog bit rate", because based on signal type
information it is possible to derive the bit-rate. Also, without
completely
understanding the wireless application it is not possible to say if we
do
require the analog bandwidth, so I will defer my comment on that till I
understand what you are refering to.</span></font><br>
    </p>
  </blockquote>
  </div>
</blockquote>
-------&gt;&nbsp; "bit rate" is a standard GMPLS/MPLS-TE signaling
parameter, though it is actually specified in bytes per second and
specified as a 32 bit IEEE floating point number so this isn't a new
parameter for GMPLS.&nbsp; I'm looking at "necessary" "optical/physical"
parameters since we know the signal types such as OTUk, STM-x, GigE,
etc... When we encounter OEO devices such as wavelength converters or
regenerators many of these can accomodate multiple signal types but
need this basic low level information to determine compatibility. ITU-T
G.872 Annex A tells us what information we must have to determine
compatibility with a particular level of regenerator (and hence we can
use this for OEO based wavelength converters too).<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div class="Section1">
  <blockquote
 style="margin-top: 5pt; margin-right: 0in; margin-bottom: 5pt;">
    <p class="MsoNormal"><br>
    <o:p></o:p></p>
    <p><font color="black" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Thanks,</span></font> <br>
    <font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Snigdho</span></font>
    <o:p></o:p></p>
    <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span style="font-size: 12pt;"><br>
    <br>
    <o:p></o:p></span></font></p>
    <pre><font color="black" face="Courier New" size="2"><span
 style="font-size: 10pt;">-- <o:p></o:p></span></font></pre>
    <pre><font color="black" face="Courier New" size="2"><span
 style="font-size: 10pt;">===================================================<o:p></o:p></span></font></pre>
    <pre><font color="black" face="Courier New" size="2"><span
 style="font-size: 10pt;">Dr Greg Bernstein, Grotto Networking (510) 573-2237<o:p></o:p></span></font></pre>
    <pre><font color="black" face="Courier New" size="2"><span
 style="font-size: 10pt;"><o:p>&nbsp;</o:p></span></font></pre>
  </blockquote>
  </div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

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

--------------090706080304050302000805--

Delivery-date: Tue, 22 Jul 2008 14:03:07 +0000
From: IESG Secretary <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: WG Action: RECHARTER: Common Control and Measurement Plane  (ccamp) 
Date: Tue, 22 Jul 2008 07:00:01 -0700 (PDT)

The Common Control and Measurement Plane (ccamp) working group in the
Routing Area of the IETF has been rechartered.  For additional
information, please contact the Area Directors or the working group
Chairs.

Common Control and Measurement Plane (ccamp)
---------------------------------------------------
Current Status: Active Working Group

Last Modified: 2008-07-21

Chairs:

Chair(s):
    Adrian Farrel <[email-masked]> 
    Deborah Brungard <[email-masked]> 

Routing Area Director(s):
    Ross Callon <[email-masked]> 
    David Ward <[email-masked]> 

Routing Area Advisor:
    Ross Callon <[email-masked]> 

Technical Advisor(s):
    Lou Berger <[email-masked]> 

Mailing Lists:
    General Discussion: [email-masked]
    To Subscribe: [email-masked]
    In Body: subscribe ccamp
    Archive: https://ops.ietf.org/lists/ccamp

Description of Working Group:

Organizational Overview

The CCAMP working group coordinates the work within the IETF
defining a common control plane and a separate common measurement
plane for physical path and core tunneling technologies of Internet
and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O
optical switches, TDM Switches, Ethernet Switches, ATM and Frame
Relay switches, IP encapsulation tunneling technologies, and MPLS
in cooperation with the MPLS WG.

In this context, measurement refers to the acquisition and
distribution of attributes relevant to the setting up of tunnels
and paths.

CCAMP WG work scope includes:

- Definition of protocol-independent metrics and parameters
  (measurement attributes) for describing links and paths that are
  required for routing and signaling. These will be developed in
  conjunction with requests and requirements from other WGs to
  ensure overall usefulness.

- Definition of protocol(s) and extensions to them required for
  link and path attribute measurement. Link Management Protocol
  (LMP) is included here.

- Functional specification of extensions for routing (OSPF, ISIS)
  and signalling (RSVP-TE) required for path establishment.
  Protocol formats and procedures that embody these extensions will
  be done jointly with the WGs supervising those protocols.

- Definition of the mechanisms required to determine the route and
  properties of an established path (tunnel tracing).

- Definition of management objects (e.g. as part of MIB modules) and
  OAM techniques relevant to the protocols and extensions specified
  within the WG.

- Work on traffic-engineering GMPLS mechanisms and protocol
  extensions to support source-controlled and explicitly-routed
  Ethernet data paths for Ethernet data planes that are already
  approved by an Standards Development Organization (SDO) with
  responsibility for the Ethernet data plane. It is expected that the
  primary SDO in this case is the IEEE. Note that the specification or
  modification of Ethernet data planes is out of scope.
- Work on GMPLS mechanisms and protocol extensions to support the
  transport profile of MPLS (MPLS-TP) in cooperation with the MPLS,
  L2VPN, and PWE3 Working Group and in coordination with the
  requirements expressed jointly by the IETF and ITU-T.

CCAMP WG currently works on the following tasks:

- Define how the properties of network resources gathered by a
  measurement protocol can be distributed in existing routing
  protocols, such as OSPF and IS-IS. CCAMP defines the generic
  description of the properties and how they are distributed in
  OSPF. The specifics of distribution within IS-IS are being
  addressed in the ISIS WG.

- Define signaling and routing mechanisms and extensions to allow
  path and tunnel setup and maintenance across multiple domains,
  where a domain may be an IGP area, an Autonomous System, or any
  other region of topological visibility. To this end, work
  cooperatively with the PCE and MPLS WGs.

- Define abstract link and path properties needed for link and
  path protection. Specify signalling mechanisms for path
  protection, diverse routing and fast path restoration. Ensure
  that multi-layer path protection and restoration functions are
  achievable using the defined signalling, routing, and measurement
  protocols, either separately or in combination.

- Identify which requirements for signaling and routing for
  Automatically Switched Optical Network (ASON) are not currently met
  by protocols defined in CCAMP; based on these, define mechanisms to
  address these requirements.

- Produce extensions to the CCAMP WG protocols and RFCs necessary
  to create an MPLS Transport Profile (MPLS TP). The work on the
  MPLS TP will be coordinated between the MPLS, L2VPN, PWE3, and CCAMP
  working groups that are jointly chartered to do MPLS TP work.

In doing this work, the WG will work closely with at least the
following other WGs: MPLS, L2VPN, PWE3, ISIS, OSPF, IDR, L1VPN and PCE.
The WG will also cooperate with the ITU-T and the IEEE 802.1.

Goals and Milestones:

Done	  	Post strawman WG goals and charter
Done	  	Identify and document a limited set of candidate solutions for
 		signalling and for measurement. Among candidate control solutions 
		to be considered are the existing GMPLS drafts.
Done	  	Build appropriate design teams
Done	  	Submit WG document defining path setup portions of common control

		plane protocol
Done	  	Submit WG document defining common measurement plane protocol
Done	  	Submit LMP MIB to IESG
Done	  	Submit protection & restoration documents to IESG
Done	  	Submit ASON signaling requirements doc to IESG
Done	  	Submit GMPLS MIBs to IESG
Done	  	Produce CCAMP WG document for generic tunnel tracing protocol
Done	  	Produce CCAMP WG document for multi-area/AS signaling and routing
Done	  	Submit ASON routing requirements doc to IESG
Done	  	Submit revised charter and milestones to IESG for IESG 
		consideration of more detailed deliverables and determination of 
		usefulness of continuation of WG
Done	  	First version WG I-D for Advertising TE Node Capabilities in ISIS

		and OSPF
Done	  	First version WG I-D for Automatic discovery of MPLS-TE mesh 
		membership
Done	  	Submit ASON Routing evaluation I-D for IESG review
Done	  	Cross-WG review of I-D for Advertising TE Node Capabilities in 
		ISIS and OSPF
Done	  	First version WG I-D MPLS to GMPLS migration strategies
Done	  	First version WG I-D Requirements for Multi-Layer and Multi-Region
 
		Networks
Done	  	First version WG I-D for Evaluation of existing protocols for 
		MLN/MRN
Done	  	First version of WG I-D for ASON Routing solutions
Done	  	Submit RSVP-TE extensions for inter-domain signaling I-D for IESG

		review
Done	  	Submit Per-domain path computation signaling I-D for IESG review
Done	  	First version of WG I-D for OSPF-TE/GMPLS MIB module
Done	  	Submit GMPLS signaling in support of Call Management I-D for IESG

		review
Done	  	First version WG Informational I-D for Analysis of inter-domain 
		issues for disjoint and protected paths
Done	  	Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF 
		for IESG review
Done	  	First version WG I-D for Protocol solutions for MLN/MRN
Done	  	Submit GMPLS/ASON lexicography I-D for IESG review
Done	  	First version WG I-D MPLS-GMPLS interworking requirements and 
		solutions
Done	  	Submit LSP Stitching I-D for IESG review
Done	  	Submit I-D for Automatic discovery of MPLS-TE mesh membership for

		IESG review
Done	  	First version WG I-D GMPLS OAM Requirements
Done	  	Submit GMPLS routing and signaling interoperability advice I-D for
 
		IESG review
Done	  	Submit MPLS to GMPLS migration strategies I-D for IESG review
Done	  	Submit Requirements for Multi-Layer and Multi-Region Networks I-D

		for IESG review
Done	  	Submit MPLS-GMPLS interworking requirements and solutions I-D for

		IESG review
Done	  	Submit Evaluation of existing protocols for MLN/MRN for IESG 
		review
Done	  	First version WG I-Ds for GMPLS source-controlled and explicitly-
		routed Ethernet networks
Done	  	Submit Informational I-D for Analysis of inter-domain issues for 
		disjoint and protected paths for IESG review
Mar 2008	  	Submit Control Plane Framework for MPLS-TP for IESG review
Aug 2008	  	First version of Working Group draft providing Control Plane 
			Framework for MPLS-TP
Sep 2008	  	Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
Oct 2008	  	First version of Working Group draft defining RSVP-TE 
			extensions for MPLS-TP
Dec 2008	  	Submit ASON Routing solutions I-D for IESG review
Dec 2008	  	Submit GMPLS OAM Requirements I-D for IESG review
Jan 2009	  	Submit protocol extensions for GMPLS source-controlled and 
			explicitly-routed Ethernet networks for IESG review
Feb 2009	  	Submit Protocol solutions for MLN/MRN I-D for IESG review
Jun 2009	  	Submit RSVP-TE extensions for MPLS-TP for IESG review
Jun 2009	  	Recharter or close Working Group

Delivery-date: Mon, 21 Jul 2008 19:39:45 +0000
Date: Mon, 21 Jul 2008 15:38:31 -0400
To: Greg Bernstein <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Dublin Draft Agenda
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>,[email-masked]

I was going to cover use of CALL_ATTRIBUTES object in my time slots 
(12/13).  Can do otherwise/earlier if desired...

Lou

At 12:01 PM 7/18/2008, Greg Bernstein wrote:
>Hi Deborah and Adrian, for session I on Monday you've got me down 
>for 15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-)
>Was part of this time for Lou to discuss a general "call approach"? 
>If not then I probably only need 10 minutes and will talk about an 
>encoding based on the CALL_ATTRIBUTES object class, from the MLN 
>extensions draft but using a new C-Type for VCAT/LCAS control.
>
>Also for session II, the WSON signaling draft will be presented by 
>Dan King. This is the merging of the two signaling drafts and the 
>title of my submission was a bit more generic than Sugang's.
>
>Regards
>
>Greg
>
>BRUNGARD, DEBORAH A, ATTLABS wrote:
>>Hi CCAMP,
>>
>>We've uploaded a draft agenda:
>><http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt
>>
>>Please let us know if we have missed anything.
>>
>>Adrian and Deborah
>>
>
>
>--
>===================================================
>Dr Greg Bernstein, Grotto Networking (510) 573-2237
>

Delivery-date: Mon, 21 Jul 2008 18:59:10 +0000
Date: Mon, 21 Jul 2008 13:57:27 -0500
From: Young Lee <[email-masked]>
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
To: "'Bardalai, Snigdho'" <[email-masked]>, 'Greg Bernstein' <[email-masked]>
Cc: "'Ccamp (E-mail)'" <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_fqesC3WK8gim/88dz/SvFQ)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

Hi Snigdho, 

See my response in-line. Thanks. 

Young

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bardalai, Snigdho
Sent: Monday, July 21, 2008 12:23 PM
To: Greg Bernstein
Cc: Ccamp (E-mail)
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

Hi Greg,

Please see my responses.

Thanks,

Snigdho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Greg Bernstein
Sent: Monday, July 21, 2008 11:27 AM
To: Bardalai, Snigdho
Cc: Ccamp (E-mail)
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

Hi Snigdho! I've got some questions on your comments and I'll take a stab at
some answers...

Regards

Greg

Bardalai, Snigdho wrote: 

Hi Greg et al, 

I have a few comments on this draft proposal. 

1. I believe basic WSON signaling extensions should be separated from
signaling based RWA solutions. The reason is the scope of each problem is
different.

There are three basic requirements in the signaling draft (a)
characterization of WSON signals, (b) bi-directional distributed wavelength
assignment for WSON signals, and (c) an option for specifying the
distributed wavelength assignment method to be used at each node. Items (a)
and (c) were from Young and my original draft and (b) was from Sugang,
Hiroki and Dan King's draft which the chairs mentioned we should merge with
ours. Is item (c) bothering you? Or the combination of (a) with (b) and (c).
We wanted the WG's opinion on item (c).
[Bardalai, Snigdho] May I ask what is a "WSON signal" ? Somewhere below you
mention a "wireless" application, what application is this, what std. is it
based on? It seems we are assuming something about the data-plane here. If
that is not clearly defined how can we discuss about characterization? On
the other hand I can completely understand what (b) and (c) is refering to.

Hence, I believe the scope of (a) is different from (b) and (c). (b) and (c)
are addressing some specific issues of distributed (signaling based) RWA.

[Young] (b) actually does not deal with "distributed" wavelength
assignment." Perhaps, we have to clarify some of the wordings used in the
current draft to avoid misunderstanding. The main focus of (b) is how to
permit simultaneous bi-directional wavelength assignment. It defines a
signalling mechanism for same wavelength bidirectional lightpath to reduce
setup times and lowers blocking probability. The exact wavelength to use
hop-by-hop can be assigned by the PCE or by the NE. 

As for (c), we are asking the WG as Greg said before if we should retain it
or not --- This is an optional feature for sure. 

The other concern is compliance to such a document. Typically there will be
a choice between distributed (signaling based) or centralized (PCE/routing
based) RWA, but (a) would be required to be supported for both RWA
approaches. Hence I would consider (a) to be a basic requirement. I believe
that we are mixing too many things here.

2. I believe we have not yet established what level of client layer
characterization should be included in an OCH layer LSP. For that matter the
definition of "Lightpath" is not yet completed and agreed.

--> In the e-mail I sent concerning the WSON Framework document I brought up
the issue of "lightpath" definition.  In a more detailed reading of G.709
and G.872 I got the impression that OCh is a bit too restrictive. In G.709
it is defined from 3R to 3R.  Now we want to include wavelength converters
even if we are not currently dealing with impairments and most wavelength
converters are regenerators (2R or 3R) with tunable lasers. G.872 doesn't
consider the wavelength of the optical signal part of its characteristic
information hence an OCh can go through a wavelength converter and they give
an example in Appendix I.  
[Bardalai, Snigdho] Thanks for the clarification. 

3. Basic WSON signaling should be in alignment with G.872 and G.709
concepts. 

Agree. Note that RFC4328 covers the standard G.709 digital hierarchy. For
signals not in the G.709 digital hierarchy the concepts and terminology of
G.709/G.872 still apply (with some caveats): the OCh (optical channel), OMS
(optical multiplex section), OTS (optical transmission section), and
Physical Media Layer (the optical fiber itself). It seems that G.709 and
G.872 have slightly different notions of what an OCh is (G.709 seeming more
restrictive).
Now from the practical side of things there are standards at the ITU-T that
actually talk about characterizing the signals like G.696.1. To determine
receiver compatibility we can run into trouble with a higher layer signal
designation such as STM-256 since different modulation (RZ, NRZ) maybe used.
Hence the ITU-T started defining signal classes by (a) modulation, (b)
modulation parameters (if any), (c) bit rate, and (d) FEC.

4. If optical impairments is not in the current scope why do we need to
encode "analog bit rate", will the client layer signal type (i.e. SONET/SDH
or ODUk etc.) not be sufficient for your purposes?

--> Do you mean "analog bandwidth"? Although G.872 are aimed at transport of
digital signals, I recall a request from someone to include some minimum
ability to deal with "analog signals" for an application where wireless
signals were put over the fiber without much processing.
If you meant "bit rate" for a digital signal compatibility with the receiver
and any OEO based wavelength converters...
[Bardalai, Snigdho] I meant "bit rate". I don't think bit-rate, mod and FEC
is sufficient for OEO based digital signal compatibility, which means
information such as encoding type, signal type etc. is necessary. Given that
I cannot understand why we need to include the "analog bit rate", because
based on signal type information it is possible to derive the bit-rate.
Also, without completely understanding the wireless application it is not
possible to say if we do require the analog bandwidth, so I will defer my
comment on that till I understand what you are refering to.

Thanks, 
Snigdho 

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

--Boundary_(ID_fqesC3WK8gim/88dz/SvFQ)
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:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
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 11 (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: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";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:Tahoma;
	color:black;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027" />
</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 bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Snigdho, =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>See my response in-line. Thanks. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Young<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:windowtext'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [email-masked] =
[mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Bardalai, Snigdho<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 21, =
2008 12:23
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Greg Bernstein<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Ccamp (E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Comments on
draft-bernstein-ccamp-wson-signaling-02.txt</span></font><font =
color=3Dblack><span
style=3D'color:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><!--[if gte vml 1]><v:shapetype =
id=3D"_x0000_t74"=20
 coordsize=3D"21600,21600" o:spt=3D"74" =
path=3D"m10860,2187c10451,1746,9529,1018,9015,730,7865,152,6685,,5415,,41=
75,152,2995,575,1967,1305,1150,2187,575,3222,242,4220,,5410,242,6560,575,=
7597l10860,21600,20995,7597v485,-1037,605,-2187,485,-3377c21115,3222,2042=
0,2187,19632,1305,18575,575,17425,152,16275,,15005,,13735,152,12705,730v-=
529,288,-1451,1016,-1845,1457xe">
 <v:stroke joinstyle=3D"miter" />
 <v:path gradientshapeok=3D"t" o:connecttype=3D"custom" =
o:connectlocs=3D"10860,2187;2928,10800;10860,21600;18672,10800"=20
  o:connectangles=3D"270,180,90,0" textboxrect=3D"5037,2277,16557,13677" =
/>
</v:shapetype><v:shape id=3D"DtsShapeName" o:spid=3D"_x0000_s1026" =
type=3D"#_x0000_t74"=20
 =
alt=3D"47E529CG097D5920@5BB2C5D2BED5405097@8h96D8BM62793!!!!!!BIHO@]M6279=
3!!!!!!!!!!1110BCGBD3519Onsl`m/enu!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!1"=20
 =
style=3D'position:absolute;margin-left:0;margin-top:0;width:.05pt;height:=
.05pt;
 z-index:1;visibility:hidden'>
 <w:anchorlock/>
</v:shape><![endif]--></span></font><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Hi =
Greg,</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Please see my =
responses.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>=

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Snigdho</span></font><o:p></o:p></p>=

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]]<b><span style=3D'font-weight:bold'>On =
Behalf Of
</span></b>Greg Bernstein<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 21, =
2008 11:27
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Bardalai, Snigdho<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Ccamp (E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Comments on
draft-bernstein-ccamp-wson-signaling-02.txt</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Hi Snigdho! I've got some questions on your =
comments
and I'll take a stab at some answers...<br>
<br>
Regards<br>
<br>
Greg<br>
<br>
Bardalai, Snigdho wrote: <o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><!-- Converted from text/rtf format -->Hi Greg et =
al,</span></font>
<o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have a few comments on this draft =
proposal.</span></font> <o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>1. I believe basic WSON signaling extensions should =
be
separated from signaling based RWA solutions. The reason is the scope of =
each
problem is different.</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>There are three basic requirements in the =
signaling
draft (a) characterization of WSON signals, (b) bi-directional =
distributed
wavelength assignment for WSON signals, and (c) an option for specifying =
the
distributed wavelength assignment method to be used at each node. Items =
(a) and
(c) were from Young and my original draft and (b) was from Sugang, =
Hiroki and
Dan King's draft which the chairs mentioned we should merge with ours. =
Is item
(c) bothering you? Or the combination of (a) with (b) and (c).&nbsp; We =
wanted
the WG's opinion on item (c).<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[Bardalai, Snigdho]&nbsp;May I ask what is =
a &quot;WSON
signal&quot; ? Somewhere below you mention a &quot;wireless&quot; =
application,
what application is this, what std. is it based on? It seems we are =
assuming
something about the data-plane here. If that is not clearly defined how =
can we
discuss about characterization? On the other hand I can completely =
understand
what (b) and (c) is refering to.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hence, I believe&nbsp;the scope of =
(a) is
different from (b) and (c). (b) and (c)&nbsp;are addressing&nbsp;some =
specific
issues of distributed (signaling based) RWA.</span></font><font size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>[Young] (b) actually does not deal =
with &#8220;distributed&#8221;
wavelength assignment.&#8221; Perhaps, we have to clarify some of the =
wordings
used in the current draft to avoid misunderstanding. The main focus of =
(b) is how
to <b><i><span style=3D'font-weight:bold;font-style:italic'>permit =
simultaneous
bi-directional wavelength assignment. It =
</span></i></b></span></font><b><i><font
size=3D2 color=3Dnavy face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:Arial;color:navy;font-weight:bold;font-style:italic'>defines =
a signalling
mechanism for same wavelength bidirectional lightpath to reduce setup =
times and
lowers blocking probability. The exact wavelength to use hop-by-hop can =
be
assigned by the PCE or by the NE. <o:p></o:p></span></font></i></b></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'><o:p>&nbsp;</o:p></span></font></i></b></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>As for (c), we =
are asking
the WG as Greg said before if we should retain it or not --- This is an
optional feature for sure. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>The other concern is compliance to =
such a
document. Typically there will be a choice between distributed =
(signaling
based) or centralized (PCE/routing based) RWA, but (a) would&nbsp;be =
required
to be supported for both RWA approaches. Hence I would consider (a) to =
be a
basic requirement. I believe that we are mixing too many things =
here.</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'
cite=3D"mid:[email-masked]=
al"
type=3Dcite>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>2. I believe we have not yet established what level =
of
client layer characterization should be included in an OCH layer LSP. =
For that
matter the definition of &quot;Lightpath&quot; is not yet completed and =
agreed.</span></font><o:p></o:p></p>

</blockquote>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>--&gt; In the e-mail I sent concerning the =
WSON
Framework document I brought up the issue of &quot;lightpath&quot;
definition.&nbsp; In a more detailed reading of G.709 and G.872 I got =
the
impression that OCh is a bit too restrictive. In G.709 it is defined =
from 3R to
3R.&nbsp; Now we want to include wavelength converters even if we are =
not
currently dealing with impairments and most wavelength converters are
regenerators (2R or 3R) with tunable lasers. G.872 doesn't consider the
wavelength of the optical signal part of its characteristic information =
hence
an OCh can go through a wavelength converter and they give an example in
Appendix I.&nbsp; <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[Bardalai, Snigdho]&nbsp;Thanks for the
clarification.&nbsp;</span></font><br>
<br>
<o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>3. Basic WSON signaling should be in alignment with =
G.872
and G.709 concepts.</span></font> <o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Agree. Note that RFC4328 covers the standard =
G.709
digital hierarchy. For signals not in the G.709 digital hierarchy the =
concepts
and terminology of G.709/G.872 still apply (with some caveats): the OCh
(optical channel), OMS (optical multiplex section), OTS (optical =
transmission
section), and Physical Media Layer (the optical fiber itself). It seems =
that
G.709 and G.872 have slightly different notions of what an OCh is (G.709
seeming more restrictive).<br>
Now from the practical side of things there are standards at the ITU-T =
that
actually talk about characterizing the signals like G.696.1. To =
determine
receiver compatibility we can run into trouble with a higher layer =
signal
designation such as STM-256 since different modulation (RZ, NRZ) maybe =
used.
Hence the ITU-T started defining signal classes by (a) modulation, (b)
modulation parameters (if any), (c) bit rate, and (d) FEC.<br>
<br>
<br>
<o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>4. If optical impairments is not in the current scope =
why do
we need to encode &quot;analog bit rate&quot;, will the client layer =
signal
type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your =
purposes?</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>--&gt; Do you mean &quot;analog =
bandwidth&quot;?
Although G.872 are aimed at transport of digital signals, I recall a =
request
from someone to include some minimum ability to deal with &quot;analog
signals&quot; for an application where wireless signals were put over =
the fiber
without much processing.<br>
If you meant &quot;bit rate&quot; for a digital signal compatibility =
with the
receiver and any OEO based wavelength converters...<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[Bardalai, Snigdho]&nbsp;I meant &quot;bit
rate&quot;. I don't think&nbsp;bit-rate, mod and FEC is sufficient for =
OEO
based digital signal compatibility, which means information such as =
encoding
type, signal type etc. is necessary. Given that I cannot understand why =
we need
to include the &quot;analog bit rate&quot;, because based on signal type
information it is possible to derive the bit-rate. Also, without =
completely
understanding the wireless application it is not possible to say if we =
do
require the analog bandwidth, so I will defer my comment on that till I
understand what you are refering to.</span></font><br>
<br>
<o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Snigdho</span></font>
<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><br>
<br>
<o:p></o:p></span></font></p>

<pre><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>-- <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Dr Greg Bernstein, Grotto Networking (510) =
573-2237<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre></blockqu=
ote>

</div>

</body>

</html>

--Boundary_(ID_fqesC3WK8gim/88dz/SvFQ)--

Delivery-date: Mon, 21 Jul 2008 17:23:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Date: Mon, 21 Jul 2008 12:22:41 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Cc: "Ccamp (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8EB56.61531504
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Greg,
=20
Please see my responses.
=20
Thanks,
Snigdho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On =
Behalf Of Greg Bernstein
Sent: Monday, July 21, 2008 11:27 AM
To: Bardalai, Snigdho
Cc: Ccamp (E-mail)
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

Hi Snigdho! I've got some questions on your comments and I'll take a =
stab at some answers...

Regards

Greg

Bardalai, Snigdho wrote:=20

Hi Greg et al,=20

I have a few comments on this draft proposal.=20

1. I believe basic WSON signaling extensions should be separated from =
signaling based RWA solutions. The reason is the scope of each problem =
is different.

There are three basic requirements in the signaling draft (a) =
characterization of WSON signals, (b) bi-directional distributed =
wavelength assignment for WSON signals, and (c) an option for specifying =
the distributed wavelength assignment method to be used at each node. =
Items (a) and (c) were from Young and my original draft and (b) was from =
Sugang, Hiroki and Dan King's draft which the chairs mentioned we should =
merge with ours. Is item (c) bothering you? Or the combination of (a) =
with (b) and (c).  We wanted the WG's opinion on item (c).
[Bardalai, Snigdho] May I ask what is a "WSON signal" ? Somewhere below =
you mention a "wireless" application, what application is this, what =
std. is it based on? It seems we are assuming something about the =
data-plane here. If that is not clearly defined how can we discuss about =
characterization? On the other hand I can completely understand what (b) =
and (c) is refering to.
=20
Hence, I believe the scope of (a) is different from (b) and (c). (b) and =
(c) are addressing some specific issues of distributed (signaling based) =
RWA.
=20
The other concern is compliance to such a document. Typically there will =
be a choice between distributed (signaling based) or centralized =
(PCE/routing based) RWA, but (a) would be required to be supported for =
both RWA approaches. Hence I would consider (a) to be a basic =
requirement. I believe that we are mixing too many things here.

2. I believe we have not yet established what level of client layer =
characterization should be included in an OCH layer LSP. For that matter =
the definition of "Lightpath" is not yet completed and agreed.

--> In the e-mail I sent concerning the WSON Framework document I =
brought up the issue of "lightpath" definition.  In a more detailed =
reading of G.709 and G.872 I got the impression that OCh is a bit too =
restrictive. In G.709 it is defined from 3R to 3R.  Now we want to =
include wavelength converters even if we are not currently dealing with =
impairments and most wavelength converters are regenerators (2R or 3R) =
with tunable lasers. G.872 doesn't consider the wavelength of the =
optical signal part of its characteristic information hence an OCh can =
go through a wavelength converter and they give an example in Appendix =
I. =20
[Bardalai, Snigdho] Thanks for the clarification.=20

3. Basic WSON signaling should be in alignment with G.872 and G.709 =
concepts.=20

Agree. Note that RFC4328 covers the standard G.709 digital hierarchy. =
For signals not in the G.709 digital hierarchy the concepts and =
terminology of G.709/G.872 still apply (with some caveats): the OCh =
(optical channel), OMS (optical multiplex section), OTS (optical =
transmission section), and Physical Media Layer (the optical fiber =
itself). It seems that G.709 and G.872 have slightly different notions =
of what an OCh is (G.709 seeming more restrictive).
Now from the practical side of things there are standards at the ITU-T =
that actually talk about characterizing the signals like G.696.1. To =
determine receiver compatibility we can run into trouble with a higher =
layer signal designation such as STM-256 since different modulation (RZ, =
NRZ) maybe used. Hence the ITU-T started defining signal classes by (a) =
modulation, (b) modulation parameters (if any), (c) bit rate, and (d) =
FEC.

4. If optical impairments is not in the current scope why do we need to =
encode "analog bit rate", will the client layer signal type (i.e. =
SONET/SDH or ODUk etc.) not be sufficient for your purposes?

--> Do you mean "analog bandwidth"? Although G.872 are aimed at =
transport of digital signals, I recall a request from someone to include =
some minimum ability to deal with "analog signals" for an application =
where wireless signals were put over the fiber without much processing.
If you meant "bit rate" for a digital signal compatibility with the =
receiver and any OEO based wavelength converters...
[Bardalai, Snigdho] I meant "bit rate". I don't think bit-rate, mod and =
FEC is sufficient for OEO based digital signal compatibility, which =
means information such as encoding type, signal type etc. is necessary. =
Given that I cannot understand why we need to include the "analog bit =
rate", because based on signal type information it is possible to derive =
the bit-rate. Also, without completely understanding the wireless =
application it is not possible to say if we do require the analog =
bandwidth, so I will defer my comment on that till I understand what you =
are refering to.

Thanks,=20
Snigdho=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 (510) 573-2237

------_=_NextPart_001_01C8EB56.61531504
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Greg,</FONT></SPAN></DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>Please=20
see my responses.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =

size=3D2>Snigdho</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>Greg=20
  Bernstein<BR><B>Sent:</B> Monday, July 21, 2008 11:27 AM<BR><B>To:</B> =

  Bardalai, Snigdho<BR><B>Cc:</B> Ccamp (E-mail)<BR><B>Subject:</B> Re: =
Comments=20
  on draft-bernstein-ccamp-wson-signaling-02.txt<BR><BR></FONT></DIV>Hi =
Snigdho!=20
  I've got some questions on your comments and I'll take a stab at some=20
  answers...<BR><BR>Regards<BR><BR>Greg<BR><BR>Bardalai, Snigdho wrote:=20
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
l=20
  type=3D"cite">
    <META content=3D"MS Exchange Server version 6.5.7652.24" =
name=3DGenerator><!-- Converted from text/rtf format -->
    <P><FONT face=3DArial size=3D2>Hi Greg et al,</FONT> </P>
    <P><FONT face=3DArial size=3D2>I have a few comments on this draft=20
    proposal.</FONT> </P>
    <P><FONT face=3DArial size=3D2>1. I believe basic WSON signaling =
extensions=20
    should be separated from signaling based RWA solutions. The reason =
is the=20
    scope of each problem is different.</FONT></P></BLOCKQUOTE>
  <DIV>There are three basic requirements in the signaling draft (a)=20
  characterization of WSON signals, (b) bi-directional distributed =
wavelength=20
  assignment for WSON signals, and (c) an option for specifying the =
distributed=20
  wavelength assignment method to be used at each node. Items (a) and =
(c) were=20
  from Young and my original draft and (b) was from Sugang, Hiroki and =
Dan=20
  King's draft which the chairs mentioned we should merge with ours. Is =
item (c)=20
  bothering you? Or the combination of (a) with (b) and (c).&nbsp; We =
wanted the=20
  WG's opinion on item (c).<BR><SPAN class=3D830255216-21072008><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>[Bardalai, Snigdho]&nbsp;May I ask what is a =
"WSON=20
  signal" ? Somewhere below you mention a "wireless" application, what=20
  application is this, what std. is it based on? It seems we are =
assuming=20
  something about the data-plane here. If that is not clearly defined =
how can we=20
  discuss about characterization? On the other hand I can completely =
understand=20
  what (b) and (c) is refering to.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D830255216-21072008><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D830255216-21072008><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Hence, I believe&nbsp;the scope of (a) is different from (b) =
and (c).=20
  (b) and (c)&nbsp;are addressing&nbsp;some specific issues of =
distributed=20
  (signaling based) RWA.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D830255216-21072008><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D830255216-21072008><FONT face=3DArial =
color=3D#0000ff size=3D2>The=20
  other concern is compliance to such a document. Typically there will =
be a=20
  choice between distributed (signaling based) or centralized =
(PCE/routing=20
  based) RWA, but (a) would&nbsp;be required to be supported for both =
RWA=20
  approaches. Hence I would consider (a) to be a basic requirement. I =
believe=20
  that we are mixing too many things here.</FONT></SPAN><BR></DIV>
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
l=20
  type=3D"cite">
    <P><FONT face=3DArial size=3D2>2. I believe we have not yet =
established what=20
    level of client layer characterization should be included in an OCH =
layer=20
    LSP. For that matter the definition of "Lightpath" is not yet =
completed and=20
    agreed.</FONT></P></BLOCKQUOTE>--&gt; In the e-mail I sent =
concerning the WSON=20
  Framework document I brought up the issue of "lightpath" =
definition.&nbsp; In=20
  a more detailed reading of G.709 and G.872 I got the impression that =
OCh is a=20
  bit too restrictive. In G.709 it is defined from 3R to 3R.&nbsp; Now =
we want=20
  to include wavelength converters even if we are not currently dealing =
with=20
  impairments and most wavelength converters are regenerators (2R or 3R) =
with=20
  tunable lasers. G.872 doesn't consider the wavelength of the optical =
signal=20
  part of its characteristic information hence an OCh can go through a=20
  wavelength converter and they give an example in Appendix I.&nbsp; =
<BR><SPAN=20
  class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>[Bardalai,=20
  Snigdho]&nbsp;Thanks for the clarification.&nbsp;</FONT></SPAN><BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
l=20
  type=3D"cite">
    <P><FONT face=3DArial size=3D2></FONT></P>
    <P><FONT face=3DArial size=3D2>3. Basic WSON signaling should be in =
alignment=20
    with G.872 and G.709 concepts.</FONT> <BR></P></BLOCKQUOTE>Agree. =
Note that=20
  RFC4328 covers the standard G.709 digital hierarchy. For signals not =
in the=20
  G.709 digital hierarchy the concepts and terminology of G.709/G.872 =
still=20
  apply (with some caveats): the OCh (optical channel), OMS (optical =
multiplex=20
  section), OTS (optical transmission section), and Physical Media Layer =
(the=20
  optical fiber itself). It seems that G.709 and G.872 have slightly =
different=20
  notions of what an OCh is (G.709 seeming more restrictive).<BR>Now =
from the=20
  practical side of things there are standards at the ITU-T that =
actually talk=20
  about characterizing the signals like G.696.1. To determine receiver=20
  compatibility we can run into trouble with a higher layer signal =
designation=20
  such as STM-256 since different modulation (RZ, NRZ) maybe used. Hence =
the=20
  ITU-T started defining signal classes by (a) modulation, (b) =
modulation=20
  parameters (if any), (c) bit rate, and (d) FEC.<BR><BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
l=20
  type=3D"cite">
    <P><FONT face=3DArial size=3D2>4. If optical impairments is not in =
the current=20
    scope why do we need to encode "analog bit rate", will the client =
layer=20
    signal type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your =

    purposes?</FONT></P></BLOCKQUOTE>--&gt; Do you mean "analog =
bandwidth"?=20
  Although G.872 are aimed at transport of digital signals, I recall a =
request=20
  from someone to include some minimum ability to deal with "analog =
signals" for=20
  an application where wireless signals were put over the fiber without =
much=20
  processing.<BR>If you meant "bit rate" for a digital signal =
compatibility with=20
  the receiver and any OEO based wavelength converters...<BR><SPAN=20
  class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>[Bardalai,=20
  Snigdho]&nbsp;I meant "bit rate". I don't think&nbsp;bit-rate, mod and =
FEC is=20
  sufficient for OEO based digital signal compatibility, which means =
information=20
  such as encoding type, signal type etc. is necessary. Given that I =
cannot=20
  understand why we need to include the "analog bit rate", because based =
on=20
  signal type information it is possible to derive the bit-rate. Also, =
without=20
  completely understanding the wireless application it is not possible =
to say if=20
  we do require the analog bandwidth, so I will defer my comment on that =
till I=20
  understand what you are refering to.</FONT></SPAN><BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
l=20
  type=3D"cite">
    <P><FONT face=3DArial size=3D2>Thanks,</FONT> <BR><FONT face=3DArial =

    size=3D2>Snigdho</FONT> </P></BLOCKQUOTE><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></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C8EB56.61531504--

Envelope-to: [email-masked]
Delivery-date: Mon, 21 Jul 2008 16:40:35 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>,  ccamp mailing list <[email-masked]>,  ccamp chair <[email-masked]>
Subject: Document Action: 'Analysis of Inter-domain Label  Switched Path (LSP) Recovery' to Informational RFC 
Message-Id: <[email-masked]>
Date: Mon, 21 Jul 2008 09:39:23 -0700 (PDT)

The IESG has approved the following document:

- 'Analysis of Inter-domain Label Switched Path (LSP) Recovery '
   <draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt> as an Informational RFC

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

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt

Technical Summary

   Protection and recovery are important features of service offerings
   in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   networks. Increasingly, MPLS and GMPLS networks are being extended
   from single domain scope to multi-domain environments.

   Various schemes and processes have been developed to establish Label
   Switched Paths (LSPs) in multi-domain environments. These are
   discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol
   Label Switching Traffic Engineering.

   This document analyzes the application of these techniques to
   protection and recovery in multi-domain networks. The main focus for
   this document is on establishing end-to-end diverse Traffic
   Engineering (TE) LSPs in multi-domain networks.

Working Group Summary

   I-D had good review and discussion in the CCAMP working group 
   doing its development. It has not had review in any wider forums,
   but none was deemed necessary or appropriate. Good consensus 
   within CCAMP reported. 

Document Quality

   This is an informational document that does not specify a protocol. 
   As such it is not subject to implementation. 

Personnel

   Deborah Brungard is the document shepherd. Ross Callon is the
   responsible AD.

Delivery-date: Mon, 21 Jul 2008 16:28:36 +0000
Date: Mon, 21 Jul 2008 09:27:19 -0700
From: Greg Bernstein <[email-masked]>
To: "Bardalai, Snigdho" <[email-masked]>
CC: "Ccamp (E-mail)" <[email-masked]>
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

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

Hi Snigdho! I've got some questions on your comments and I'll take a 
stab at some answers...

Regards

Greg

Bardalai, Snigdho wrote:
>
> Hi Greg et al,
>
> I have a few comments on this draft proposal.
>
> 1. I believe basic WSON signaling extensions should be separated from 
> signaling based RWA solutions. The reason is the scope of each problem 
> is different.
>
There are three basic requirements in the signaling draft (a) 
characterization of WSON signals, (b) bi-directional distributed 
wavelength assignment for WSON signals, and (c) an option for specifying 
the distributed wavelength assignment method to be used at each node. 
Items (a) and (c) were from Young and my original draft and (b) was from 
Sugang, Hiroki and Dan King's draft which the chairs mentioned we should 
merge with ours. Is item (c) bothering you? Or the combination of (a) 
with (b) and (c).  We wanted the WG's opinion on item (c).
>
> 2. I believe we have not yet established what level of client layer 
> characterization should be included in an OCH layer LSP. For that 
> matter the definition of "Lightpath" is not yet completed and agreed.
>
--> In the e-mail I sent concerning the WSON Framework document I 
brought up the issue of "lightpath" definition.  In a more detailed 
reading of G.709 and G.872 I got the impression that OCh is a bit too 
restrictive. In G.709 it is defined from 3R to 3R.  Now we want to 
include wavelength converters even if we are not currently dealing with 
impairments and most wavelength converters are regenerators (2R or 3R) 
with tunable lasers. G.872 doesn't consider the wavelength of the 
optical signal part of its characteristic information hence an OCh can 
go through a wavelength converter and they give an example in Appendix I. 
>
> 3. Basic WSON signaling should be in alignment with G.872 and G.709 
> concepts.
>
Agree. Note that RFC4328 covers the standard G.709 digital hierarchy. 
For signals not in the G.709 digital hierarchy the concepts and 
terminology of G.709/G.872 still apply (with some caveats): the OCh 
(optical channel), OMS (optical multiplex section), OTS (optical 
transmission section), and Physical Media Layer (the optical fiber 
itself). It seems that G.709 and G.872 have slightly different notions 
of what an OCh is (G.709 seeming more restrictive).
Now from the practical side of things there are standards at the ITU-T 
that actually talk about characterizing the signals like G.696.1. To 
determine receiver compatibility we can run into trouble with a higher 
layer signal designation such as STM-256 since different modulation (RZ, 
NRZ) maybe used. Hence the ITU-T started defining signal classes by (a) 
modulation, (b) modulation parameters (if any), (c) bit rate, and (d) FEC.
>
> 4. If optical impairments is not in the current scope why do we need 
> to encode "analog bit rate", will the client layer signal type (i.e. 
> SONET/SDH or ODUk etc.) not be sufficient for your purposes?
>
--> Do you mean "analog bandwidth"? Although G.872 are aimed at 
transport of digital signals, I recall a request from someone to include 
some minimum ability to deal with "analog signals" for an application 
where wireless signals were put over the fiber without much processing.
If you meant "bit rate" for a digital signal compatibility with the 
receiver and any OEO based wavelength converters...
> Thanks,
> Snigdho

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

--------------040406070905000408070004
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 Snigdho! I've got some questions on your comments and I'll take a
stab at some answers...<br>
<br>
Regards<br>
<br>
Greg<br>
<br>
Bardalai, Snigdho wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 6.5.7652.24">
  <title>Comments on draft-bernstein-ccamp-wson-signaling-02.txt</title>
<!-- Converted from text/rtf format -->
  <p><font face="Arial" size="2">Hi Greg et al,</font>
  </p>
  <p><font face="Arial" size="2">I have a few comments on this draft
proposal.</font>
  </p>
  <p><font face="Arial" size="2">1. I believe basic WSON signaling
extensions should be separated from signaling based RWA solutions. The
reason is the scope of each problem is different.</font></p>
</blockquote>
There are three basic requirements in the signaling draft (a)
characterization of WSON signals, (b) bi-directional distributed
wavelength assignment for WSON signals, and (c) an option for
specifying the distributed wavelength assignment method to be used at
each node. Items (a) and (c) were from Young and my original draft and
(b) was from Sugang, Hiroki and Dan King's draft which the chairs
mentioned we should merge with ours. Is item (c) bothering you? Or the
combination of (a) with (b) and (c).&nbsp; We wanted the WG's opinion on
item (c).<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <p><font face="Arial" size="2">2. I believe we have not yet
established what level of client layer characterization should be
included in an OCH layer LSP. For that matter the definition of
"Lightpath" is not yet completed and agreed.</font></p>
</blockquote>
--&gt; In the e-mail I sent concerning the WSON Framework document I
brought up the issue of "lightpath" definition.&nbsp; In a more detailed
reading of G.709 and G.872 I got the impression that OCh is a bit too
restrictive. In G.709 it is defined from 3R to 3R.&nbsp; Now we want to
include wavelength converters even if we are not currently dealing with
impairments and most wavelength converters are regenerators (2R or 3R)
with tunable lasers. G.872 doesn't consider the wavelength of the
optical signal part of its characteristic information hence an OCh can
go through a wavelength converter and they give an example in Appendix
I.&nbsp; <br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <p><font face="Arial" size="2"> </font></p>
  <p><font face="Arial" size="2">3. Basic WSON signaling should be in
alignment with G.872 and G.709 concepts.</font>
  <br>
  </p>
</blockquote>
Agree. Note that RFC4328 covers the standard G.709 digital hierarchy.
For signals not in the G.709 digital hierarchy the concepts and
terminology of G.709/G.872 still apply (with some caveats): the OCh
(optical channel), OMS (optical multiplex section), OTS (optical
transmission section), and Physical Media Layer (the optical fiber
itself). It seems that G.709 and G.872 have slightly different notions
of what an OCh is (G.709 seeming more restrictive).<br>
Now from the practical side of things there are standards at the ITU-T
that actually talk about characterizing the signals like G.696.1. To
determine receiver compatibility we can run into trouble with a higher
layer signal designation such as STM-256 since different modulation
(RZ, NRZ) maybe used. Hence the ITU-T started defining signal classes
by (a) modulation, (b) modulation parameters (if any), (c) bit rate,
and (d) FEC.<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <p><font face="Arial" size="2">4. If optical impairments is not in
the current scope why do we need to encode "analog bit rate", will the
client layer signal type (i.e. SONET/SDH or ODUk etc.) not be
sufficient for your purposes?</font></p>
</blockquote>
--&gt; Do you mean "analog bandwidth"? Although G.872 are aimed at
transport of digital signals, I recall a request from someone to
include some minimum ability to deal with "analog signals" for an
application where wireless signals were put over the fiber without much
processing.<br>
If you meant "bit rate" for a digital signal compatibility with the
receiver and any OEO based wavelength converters...<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <p><font face="Arial" size="2">Thanks,</font>
  <br>
  <font face="Arial" size="2">Snigdho</font>
  </p>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

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

--------------040406070905000408070004--

Delivery-date: Mon, 21 Jul 2008 15:15:46 +0000
Date: Mon, 21 Jul 2008 16:14:43 +0100
Subject: Re: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt
From: Ben Niven-Jenkins <[email-masked]>
To: John Kenney <[email-masked]>, Loa Andersson <[email-masked]>
CC: L2VPN <[email-masked]>, <[email-masked]>, <[email-masked]>, Bob Briscoe <[email-masked]>, ccamp <[email-masked]>, pwe3 <[email-masked]>, <[email-masked]>

I'm not precious about which term we use but if we use Traffic Management I
think a paragraph should be added explaining what is meant to put it in
context.

Ben

On 21/07/2008 15:07, "John Kenney" <[email-masked]> wrote:

> Hi Loa,
> 
> This is a good draft.  It's time to rename the EXP field.  While CoS
> Field may have been a good choice at one time, we've now heard from many
> who think it is too narrow for current usage of this field.
> 
> I suggest "Traffic Management Field".
> 
> Traffic management is a common, generic, and concise term.  It covers
> all current uses of the field: scheduling class, drop priority, and
> congestion notification. CoS really only covers the first.  Traffic
> management is well-scoped to this purpose, and clearly preferable to CoS
> in my opinion.
> 
> In terms of the draft, I think a simple global substitution of "traffic
> management" for "class of service" and of "TM" for "CoS" should suffice.
> 
> I think in the long run we'll be glad if we bite the bullet now and make
> this change.
> 
> Best Regards,
> John
> 
> 
> Loa Andersson wrote:
>> 
>> Bob,
>> 
>> thanks for useful comments :)
>> 
>> Bob Briscoe wrote:
>>> Loa,
>>> 
>>> I believe this draft has no technical effect. However there is some
>>> truth in the idea that names are important.
>>> 
>>> So, let's set aside a few clock cycles to consider this...
>>> 
>>> 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP
>>> field for ECN in MPLS), is it really appropriate now to call this a
>>> CoS field?
>>> 
>>> Thinking out loud...
>>> - CoS is a signal from an ingress to the interior (a request for a
>>> certain class of service),
>>> - whereas ECN is a signal from the interior forwarding plane to the
>>> egress (a response from the interior saying whether the class of
>>> service requested was congested).
>>> 
>>> The way 5129 was done, two (or more) EXP codepoints can be designated
>>> as the same CoS, but one can be used to say "this packet experienced
>>> congestion when using this CoS", while the other says "it didn't".
>>> So, I guess I could live with this field being called CoS, even
>>> though it's not strictly correct. I can't think of anything better.
>> 
>> We had the same discussion when we started to discuss this draft, we
>> wanted to find a name the covered both cases. We just couldn't come
>> with a better name, so we said "Let us call it 'CoS Field'" and change
>> it someone comes up with something better.
>> 
>> I'm still open to do that change, but time is kind of running out, the
>> latest point in time we can do this change is an RFC editor note, when
>> the IESG has approved the document.
> 

Delivery-date: Mon, 21 Jul 2008 13:25:11 +0000
Date: Mon, 21 Jul 2008 10:37:43 +0200
From: Loa Andersson <[email-masked]>
To: Bob Briscoe <[email-masked]>
CC: [email-masked], [email-masked], ccamp <[email-masked]>,  L2VPN <[email-masked]>, pwe3 <[email-masked]>, [email-masked]
Subject: Re: [Tsvwg] multiple-working group last call on  draft-ietf-mpls-cosfield-def-04.txt

Bob,

thanks for useful comments :)

Bob Briscoe wrote:
> Loa,
> 
> I believe this draft has no technical effect. However there is some 
> truth in the idea that names are important.
> 
> So, let's set aside a few clock cycles to consider this...
> 
> 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP field 
> for ECN in MPLS), is it really appropriate now to call this a CoS field?
> 
> Thinking out loud...
> - CoS is a signal from an ingress to the interior (a request for a 
> certain class of service),
> - whereas ECN is a signal from the interior forwarding plane to the 
> egress (a response from the interior saying whether the class of service 
> requested was congested).
> 
> The way 5129 was done, two (or more) EXP codepoints can be designated as 
> the same CoS, but one can be used to say "this packet experienced 
> congestion when using this CoS", while the other says "it didn't". So, I 
> guess I could live with this field being called CoS, even though it's 
> not strictly correct. I can't think of anything better.

We had the same discussion when we started to discuss this draft, we
wanted to find a name the covered both cases. We just couldn't come
with a better name, so we said "Let us call it 'CoS Field'" and change
it someone comes up with something better.

I'm still open to do that change, but time is kind of running out, the
latest point in time we can do this change is an RFC editor note, when
the IESG has approved the document.

> 
> 
> 2/ BTW, Thanks for pointing out that the RFC Index doesn't identify 
> RFC5129 or RFC3270 as updates to RFC3032.
> 
> According to a recent discussion on TSVWG with Bob Braden, the 
> annotation of the RFC Index is the responsibility of the RFC Editor, and 
> doesn't need to be driven by text in RFCs. So we can send an email to 
> the RFC Editor  at any time asking for annotation to be added to the index.
> 
> If no-one objects on this thread, will you be doing that? If not, I can.

I'll do it.

> 
> But does 5129 UPDATE 3270? I don't believe it does. 5129 deliberately 
> doesn't change or contradict anything in 3270. It complements it.

I tend to agree, but have a problem how to capture this. We have

obsoletes
obsoleted by
updates
updated by

Would the following change to the paragraph in the ID suffice:

                                    "We recommend this scheme, which we
       call `per-domain ECT checking', and define it more precisely in
       the following section.  Its chief drawback is that it can cause
       packets to be forwarded after encountering congestion only to be
       dropped at the egress of the MPLS domain.  The rationale for this
       decision is given in Section 8.1.  This scheme is an update to RFC
       3032 [RFC3032] and RFC 3270 [RFC3270] is extended to allow for
       CoS Field code points to encode ECN information."

and - yes if you agree and could improve on grammar that would be great.

"The problem" I have is that even with the changed version this is an
"updates/updated by" the way it is used by the RFC Editor. We want to
point to this extension from 3270 to give implementation context.

/Loa

PS
you helped me pick another nit alos 5219 should be 5129

> 
> 
> Thoughts?
> 
> 
> Bob
> 
> At 12:59 10/07/2008, Loa Andersson wrote:
>> All,
>>
>> this mail initiates a two week multiple-working group last call on
>>
>> draft-ietf-mpls-cosfield-def-04.txt
>>
>> Background:
>>
>> The name "EXP field" of a three bit field in the MPLS shim header,
>> and the statement in RFC3032 "For experimental use" has led other
>> SDOs to believe that this field could be used for any type of
>> experiments. The field has however from the start been intended to
>> carry Class of Service (CoS) information.
>>
>> The draft therefore renames the field "Class of Service (CoS) Field".
>>
>> This is an update of RFC3032, and also of drafts that builds on
>> RFC3032. This multiple-working group last call is therefore sent to
>> working groups with RFCs that has been updated.
>>
>> The document has been through wg last call in the mpls working group,
>> which I don't think will stop that wg producing new comments now,
>> nor should it :) .
>>
>> This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG.
>>
>> Since this is also of interest in the work we started on a
>> Transport Profile for MPLS (MPLS-TP) we are also sending it to the
>> Ad HoC Team on MPLS in the ITU-T.
>>
>> Please review and send comments to the mpls wg mailing list, or to
>> the mailing list for mpls-tp discussion that just been set up:
>>
>> [email-masked]
>>
>> or directly to the mpls wg co-chairs before e.o.b. July 24.
>>
>> /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:  [email-masked]
>>                                            [email-masked]
> 
> ____________________________________________________________________________ 
> 
> Notice: This contribution is the personal view of the author and does 
> not necessarily reflect the technical nor commercial direction of BT plc.
> ____________________________________________________________________________ 
> 
> Bob Briscoe,                           Networks Research Centre, BT 
> Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 
> 645196
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Sat, 19 Jul 2008 13:10:08 +0000
Content-class: urn:content-classes:message
Subject: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Date: Sat, 19 Jul 2008 08:08:17 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "Ccamp (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8E9A0.82D1A646
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Greg et al,

I have a few comments on this draft proposal.

1. I believe basic WSON signaling extensions should be separated from =
signaling based RWA solutions. The reason is the scope of each problem =
is different.
2. I believe we have not yet established what level of client layer =
characterization should be included in an OCH layer LSP. For that matter =
the definition of "Lightpath" is not yet completed and agreed.=20
3. Basic WSON signaling should be in alignment with G.872 and G.709 =
concepts.
4. If optical impairments is not in the current scope why do we need to =
encode "analog bit rate", will the client layer signal type (i.e. =
SONET/SDH or ODUk etc.) not be sufficient for your purposes?

Thanks,
Snigdho

------_=_NextPart_001_01C8E9A0.82D1A646
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>Comments on draft-bernstein-ccamp-wson-signaling-02.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Greg et al,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a few comments on this draft =
proposal.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. I believe basic WSON signaling =
extensions should be separated from signaling based RWA solutions. The =
reason is the scope of each problem is different.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. I believe we have not yet =
established what level of client layer characterization should be =
included in an OCH layer LSP. For that matter the definition of =
&quot;Lightpath&quot; is not yet completed and agreed. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3. Basic WSON signaling should be in =
alignment with G.872 and G.709 concepts.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">4. If optical impairments is not in =
the current scope why do we need to encode &quot;analog bit rate&quot;, =
will the client layer signal type (i.e. SONET/SDH or ODUk etc.) not be =
sufficient for your purposes?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Snigdho</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C8E9A0.82D1A646--

Delivery-date: Fri, 18 Jul 2008 16:02:21 +0000
Date: Fri, 18 Jul 2008 09:01:02 -0700
From: Greg Bernstein <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
CC: [email-masked]
Subject: Re: Dublin Draft Agenda

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

Hi Deborah and Adrian, for session I on Monday you've got me down for 15 
minutes to discuss the VCAT/LCAS draft. This is too generous ;-)
Was part of this time for Lou to discuss a general "call approach"? If 
not then I probably only need 10 minutes and will talk about an encoding 
based on the CALL_ATTRIBUTES object class, from the MLN extensions draft 
but using a new C-Type for VCAT/LCAS control.

Also for session II, the WSON signaling draft will be presented by Dan 
King. This is the merging of the two signaling drafts and the title of 
my submission was a bit more generic than Sugang's.

Regards

Greg

BRUNGARD, DEBORAH A, ATTLABS wrote:
> Hi CCAMP,
>  
> We've uploaded a draft agenda:
> http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt
>  
> Please let us know if we have missed anything.
>  
> Adrian and Deborah
>  

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

--------------090800040401070408090407
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">
Hi Deborah and Adrian, for session I on Monday you've got me down for
15 minutes to discuss the VCAT/LCAS draft. This is too generous <span
 class="moz-smiley-s3"><span> ;-) </span></span><br>
Was part of this time for Lou to discuss a general "call approach"? If
not then I probably only need 10 minutes and will talk about an
encoding based on the CALL_ATTRIBUTES object class, from the MLN
extensions draft but using a new C-Type for VCAT/LCAS control.<br>
<br>
Also for session II, the WSON signaling draft will be presented by Dan
King. This is the merging of the two signaling drafts and the title of
my submission was a bit more generic than Sugang's.<br>
<br>
Regards<br>
<br>
Greg <br>
<br>
BRUNGARD, DEBORAH A, ATTLABS wrote:
<blockquote
 cite="mid:[email-masked]"
 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="800553700-18072008">Hi
CCAMP,</span></font></div>
  <div><font face="Arial" size="2"><span class="800553700-18072008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="800553700-18072008">We've
uploaded a draft agenda:</span></font></div>
  <div><font face="Arial" size="2"><span class="800553700-18072008"><a
 moz-do-not-send="true"
 href="http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt">http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt</a></span></font></div>
  <div><font face="Arial" size="2"><span class="800553700-18072008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="800553700-18072008">Please
let us know if we have missed anything.</span></font></div>
  <div><font face="Arial" size="2"><span class="800553700-18072008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="800553700-18072008">Adrian
and Deborah</span></font></div>
  <div><font face="Arial" size="2"><span class="800553700-18072008"></span></font>&nbsp;</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

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

--------------090800040401070408090407--

Delivery-date: Fri, 18 Jul 2008 00:45:25 +0000
Content-class: urn:content-classes:message
Subject: Dublin Draft Agenda
Date: Thu, 17 Jul 2008 20:43:12 -0400
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8E86F.4304E362
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi CCAMP,
=20
We've uploaded a draft agenda:
http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt
=20
Please let us know if we have missed anything.
=20
Adrian and Deborah
=20

------_=_NextPart_001_01C8E86F.4304E362
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 class=3D800553700-18072008>Hi=20
CCAMP,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D800553700-18072008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D800553700-18072008>We've =
uploaded a=20
draft agenda:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D800553700-18072008><A=20
href=3D"http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt">http://ww=
w.ietf.org/proceedings/08jul/agenda/ccamp.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D800553700-18072008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D800553700-18072008>Please =
let us know=20
if we have missed anything.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D800553700-18072008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D800553700-18072008>Adrian =
and=20
Deborah</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D800553700-18072008></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C8E86F.4304E362--

Delivery-date: Wed, 16 Jul 2008 17:58:40 +0000
Date: Wed, 16 Jul 2008 10:56:46 -0700
From: Greg Bernstein <[email-masked]>
To: [email-masked]
CC: Dan Li <[email-masked]>, ccamp <[email-masked]>, [email-masked]
Subject: Re: =?GB2312?B?tPC4tDogUmU6IFRpbWVzIHNsb3RzIGZvciBXU09OIGRyYWZ0cw==?= =?GB2312?B?IGF0IENDQU1QLi4u?=

This is a multi-part message in MIME format.
--------------080701010203070109020209
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit

Hi Kang, Let's address the time slot request to the Working Group chairs
Adrian and Deborah since neither Dan nor I can give out time slots.
We're just asking for some time slots to present and trying to round up
all the WDM/WSON (or whatever we want to call it) related items so they
can be grouped together.

One question that came to my mind when browsing your draft (I haven't
read it in detail yet). Was how does your verification
requirement/functionality differ from LMP either conceptually (you want
additional basic functionality) or in the details (want particular
additional information).

Regards

Greg B.

[email-masked] wrote:
>
> Dear Dan, Bernstein and Everyone,
>
> We have finished one new draft which focus on the application and
> extention of GMPLS to WDM network. There is no significant declaration
> about the mechanism of link connectivity verification for WDM link,
> and there are certain constraints in WDM network. The contraints is
> the root of RWA. This new draft is the supplement for DWM link
> connectivity verification, and provides the constraint information
> extension to route for static light path computation and selection in
> WDM network.
>
> We would like to request a timesolt in CCAMP session.
>
> Thanks
>
> Kang
>
>
>
>
> 	*Dan Li <[email-masked]>*
> ·¢¼þÈË£º [email-masked]
>
> 2008-07-10 11:45
>
> 	
> ÊÕ¼þÈË£º Greg Bernstein <[email-masked]>, ccamp
> <[email-masked]>
> ³ËÍ£º
> Ö÷Ìâ£º Re: Times slots for WSON drafts at CCAMP...
>
>
>
>
> Hi,
>
> We are updating WSON-IGP-EVAL draft, and try to make it be consistent
> with WSON Info Model Encoding draft. So we also would like to request
> a timesolt in CCAMP session.
>
> Thanks,
>
> Dan
>
> ----- Original Message -----
> From: "Greg Bernstein" <[email-masked]>
> To: "ccamp" <[email-masked]>
> Sent: Wednesday, July 09, 2008 10:03 PM
> Subject: Times slots for WSON drafts at CCAMP...
>
>
> > Hi Chairs and WG participants. There are a number of drafts concerning
> > Wavelength Switched Optical Networks (WSON) that will (or may) want a
> > time slot for the Dublin meeting. Here is a list of those that I know
> > of and what would/could be discussed:
> >
> > (a) Framework Draft -- Mostly a discussion of update plans, this hasn't
> > been changed since becoming a working group document a few months back.
> > (b) WSON High Level Information Model -- This has been significantly
> > refined since it was split off from the previous info model draft per
> > the chair's suggestion.
> > (c) WSON Info Model Encoding -- This also has been significantly
> refined
> > since it was split off from the previous info model draft.
> >
> > (d) WSON Signaling -- This is a merging of two drafts from separate
> > groups of contributors. Requirements and solutions are clearly
> delimited
> > in this new draft. Dan King has volunteered to present.
> > (e) G.694 based lambda labels -- Did Tomohiro want to give us a quick
> > update since this is now a WG document?
> >
> > (f) I saw a new draft from Zhihong Kang and others at ZTE. This
> seems to
> > hit a number of topics related to the on going WSON work. I didn't know
> > if they wanted a slot at Dublin. This is probably closer to framework
> > and modeling than to signaling issues.
> >
> > All the above have been uploaded. I'll send an update with links once
> > they are posted by the IETF. Also there was some discussion of a CCAMP
> > sponsored sub-mailing list for WSON discussions any progress?
> >
> > Thanks
> >
> > Greg B.
> >
> > --
> > ===================================================
> > Dr Greg Bernstein, Grotto Networking (510) 573-2237
> >
> >
> >
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated to
> maintain secrecy and are not permitted to disclose the contents of
> this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the originator of the message. Any views expressed in this message are
> those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam
> system.
>
>
> --------------------------------------------------------
> ZTEInformationSecurityNotice:Theinformationcontainedinthismailissolelypropertyofthesender'sorganization.Thismailcommunicationisconfidential.Recipientsnamedaboveareobligatedtomaintainsecrecyandarenotpermittedtodisclosethecontentsofthiscommunicationtoothers.
> Thisemailandanyfilestransmittedwithitareconfidentialandintendedsolelyfortheuseoftheindividualorentitytowhomtheyareaddressed.Ifyouhavereceivedthisemailinerrorpleasenotifytheoriginatorofthemessage.Anyviewsexpressedinthismessagearethoseoftheindividualsender.
> ThismessagehasbeenscannedforvirusesandSpambyZTEAnti-Spamsystem.
>   

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

--------------080701010203070109020209
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=GB2312" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Kang, Let's address the time slot request to the Working Group
chairs Adrian and Deborah since neither Dan nor I can give out time
slots. We're just asking for some time slots to present and trying to
round up all the WDM/WSON (or whatever we want to call it) related
items so they can be grouped together.<br>
<br>
One question that came to my mind when browsing&nbsp; your draft (I haven't
read it in detail yet).&nbsp; Was how does your verification
requirement/functionality differ from LMP either conceptually (you want
additional basic functionality) or in the details (want particular
additional information).<br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite"><br>
  <tt><font size="2">Dear Dan, Bernstein and Everyone,</font></tt>
  <br>
  <br>
  <tt><font size="2">We have finished one new draft which focus on the
application and extention of GMPLS to WDM network. There is no
significant
declaration about the mechanism of link connectivity verification for
WDM
link, &nbsp;and there are certain constraints in WDM network. The contraints
is the root of RWA. This new draft is the supplement for DWM link
connectivity
verification, and provides the constraint information extension to
route
for static light path computation and selection in WDM network.</font></tt>
  <br>
  <br>
  <tt><font size="2">We would like to request a timesolt in CCAMP
session.</font></tt>
  <br>
  <br>
  <tt><font size="2">Thanks</font></tt>
  <br>
  <br>
  <tt><font size="2">Kang</font></tt>
  <br>
  <br>
  <br>
  <br>
  <table width="100%">
    <tbody>
      <tr valign="top">
        <td>
        <br>
        </td>
        <td><font face="sans-serif" size="1"><b>Dan Li
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></b></font>
        <br>
        <font face="sans-serif" size="1">·¢¼þÈË£º <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></font>
        <br>
        <p><font face="sans-serif" size="1">2008-07-10 11:45</font>
        </p>
        </td>
        <td><font face="Arial" size="1">&nbsp; &nbsp; &nbsp; &nbsp; </font>
        <br>
        <font face="sans-serif" size="1">&nbsp; &nbsp; &nbsp; &nbsp; ÊÕ¼þÈË£º
&nbsp; &nbsp; &nbsp; &nbsp;Greg Bernstein <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
ccamp <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></font>
        <br>
        <font face="sans-serif" size="1">&nbsp; &nbsp; &nbsp; &nbsp; ³ËÍ£º
&nbsp; &nbsp; &nbsp; &nbsp;</font>
        <br>
        <font face="sans-serif" size="1">&nbsp; &nbsp; &nbsp; &nbsp; Ö÷Ìâ£º
&nbsp; &nbsp; &nbsp; &nbsp;Re: Times slots for WSON drafts at CCAMP...</font></td>
      </tr>
    </tbody>
  </table>
  <br>
  <br>
  <br>
  <tt><font size="2">Hi,<br>
  <br>
We are updating WSON-IGP-EVAL draft, and try to make it be consistent
with
WSON Info Model Encoding draft. So we also would like to request a
timesolt
in CCAMP session.<br>
  <br>
Thanks,<br>
  <br>
Dan<br>
  <br>
----- Original Message ----- <br>
From: "Greg Bernstein" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
To: "ccamp" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
Sent: Wednesday, July 09, 2008 10:03 PM<br>
Subject: Times slots for WSON drafts at CCAMP...<br>
  <br>
  <br>
&gt; Hi Chairs and WG participants. There are a number of drafts
concerning
  <br>
&gt; Wavelength Switched Optical Networks (WSON) that will (or may)
want
a <br>
&gt; time slot for the Dublin meeting. &nbsp;Here is a list of those that
I know <br>
&gt; of and what would/could be discussed:<br>
&gt; <br>
&gt; (a) Framework Draft -- Mostly a discussion of update plans, this
hasn't
  <br>
&gt; been changed since becoming a working group document a few months
back.<br>
&gt; (b) WSON High Level Information Model -- This has been
significantly
  <br>
&gt; refined since it was split off from the previous info model draft
per <br>
&gt; the chair's suggestion.<br>
&gt; (c) WSON Info Model Encoding -- This also has been significantly
refined
  <br>
&gt; since it was split off from the previous info model draft.<br>
&gt; <br>
&gt; (d) WSON Signaling -- This is a merging of two drafts from
separate
  <br>
&gt; groups of contributors. Requirements and solutions are clearly
delimited
  <br>
&gt; in this new draft. Dan King has volunteered to present.<br>
&gt; (e) G.694 based lambda labels -- Did Tomohiro want to give us a
quick
  <br>
&gt; update since this is now a WG document?<br>
&gt; <br>
&gt; (f) I saw a new draft from Zhihong Kang and others at ZTE. This
seems
to <br>
&gt; hit a number of topics related to the on going WSON work. I didn't
know <br>
&gt; if they wanted a slot at Dublin. This is probably closer to
framework
  <br>
&gt; and modeling than to signaling issues.<br>
&gt; <br>
&gt; All the above have been uploaded. I'll send an update with links
once
  <br>
&gt; they are posted by the IETF. Also there was some discussion of a
CCAMP
  <br>
&gt; sponsored sub-mailing list for WSON discussions any progress?<br>
&gt; <br>
&gt; Thanks<br>
&gt; <br>
&gt; Greg B.<br>
&gt; <br>
&gt; -- <br>
&gt; ===================================================<br>
&gt; Dr Greg Bernstein, Grotto Networking (510) 573-2237<br>
&gt; <br>
&gt; <br>
&gt; <br>
  <br>
  <br>
  <br>
--------------------------------------------------------<br>
ZTE Information Security Notice: The information contained in this mail
is solely property of the sender's organization. This mail
communication
is confidential. Recipients named above are obligated to maintain
secrecy
and are not permitted to disclose the contents of this communication to
others.<br>
This email and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error please notify the originator
of
the message. Any views expressed in this message are those of the
individual
sender.<br>
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.<br>
  </font></tt>
  <br>
  <br>
  <pre>--------------------------------------------------------
ZTE&nbsp;Information&nbsp;Security&nbsp;Notice:&nbsp;The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;mail&nbsp;is&nbsp;solely&nbsp;property&nbsp;of&nbsp;the&nbsp;sender's&nbsp;organization.&nbsp;This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidential.&nbsp;Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to&nbsp;maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to&nbsp;disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication&nbsp;to&nbsp;others.
This&nbsp;email&nbsp;and&nbsp;any&nbsp;files&nbsp;transmitted&nbsp;with&nbsp;it&nbsp;are&nbsp;confidential&nbsp;and&nbsp;intended&nbsp;solely&nbsp;for&nbsp;the&nbsp;use&nbsp;of&nbsp;the&nbsp;individual&nbsp;or&nbsp;entity&nbsp;to&nbsp;whom&nbsp;they&nbsp;are&nbsp;addressed.&nbsp;If&nbsp;you&nbsp;have&nbsp;received&nbsp;this&nbsp;email&nbsp;in&nbsp;error&nbsp;please&nbsp;notify&nbsp;the&nbsp;originator&nbsp;of&nbsp;the&nbsp;message.&nbsp;Any&nbsp;views&nbsp;expressed&nbsp;in&nbsp;this&nbsp;message&nbsp;are&nbsp;those&nbsp;of&nbsp;the&nbsp;individual&nbsp;sender.
This&nbsp;message&nbsp;has&nbsp;been&nbsp;scanned&nbsp;for&nbsp;viruses&nbsp;and&nbsp;Spam&nbsp;by&nbsp;ZTE&nbsp;Anti-Spam&nbsp;system.
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

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

--------------080701010203070109020209--

Delivery-date: Tue, 15 Jul 2008 10:01:24 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt 
Date: Tue, 15 Jul 2008 03:00: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           : draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt
	Author(s)       : D. Caviglia, et al.
	Filename        : draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt
	Pages           : 23
	Date            : 2008-07-15

We would like to dedicate this work to our friend and colleague Dino
Bramanti, who passed away at the early age of 38.  Dino has been
involved in this work since its beginning.

In a transport network scenario, where Data Plane connections
controlled either by GMPLS Control Plane (Soft Permanent Connections
- SPC) or by Management System (Permanent Connections - PC) may
independently coexist, the ability of transforming an existing PC
into a SPC and vice versa - without actually affecting Data Plane
traffic being carried over it - is a requirement.  See draft
"draft-ietf-ccamp-pc-and-reqs-04.txt [1].  This memo provides a minor
extension to RSVP-TE [RFC2205],[RFC3471],[RFC3473],[RFC4872]
signaling protocol, within GMPLS architecture, to enable such
connection ownership transfer and describes the proposed procedures.
Failure conductions and subsequent roll back are also illustrated
taking into account that an handover failure must not impact the
already established data plane connections.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-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-pc-spc-rsvpte-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: Tue, 15 Jul 2008 09:02:25 +0000
To: Dan Li <[email-masked]>
Cc: ccamp <[email-masked]>, Greg Bernstein <[email-masked]>, [email-masked]
Subject: =?GB2312?B?tPC4tDogUmU6IFRpbWVzIHNsb3RzIGZvciBXU09OIGRyYWZ0cyBhdA==?= =?GB2312?B?IENDQU1QLi4u?=
From: [email-masked]
Date: Tue, 15 Jul 2008 14:09:01 +0800

This is a multipart message in MIME format.
--=_alternative 0021F20B48257487_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

--=_alternative 0021F20B48257487_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

--=_alternative 0021F20B48257487_=--

Delivery-date: Tue, 15 Jul 2008 01:37:04 +0000
Date: Tue, 15 Jul 2008 09:35:33 +0800
From: Dan Li <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
To: Tomohiro Otani <[email-masked]>, [email-masked]

Dear Tomohiro,

For "n", I prefer 16 bits to 17 bits. Because it's easier for programmer to parse the label.

Thanks,

Dan

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 15, 2008 3:15 AM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.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 Labels for G.694 Lambda-Switching Capable Label Switching Routers
> Author(s) : T. Otani, H. Guo, K. Miyazaki, D. Caviglia
> Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
> Pages : 10
> Date : 2008-7-14
> 
> 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-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.
> 

Delivery-date: Mon, 14 Jul 2008 20:31:30 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-eval-06.txt 
Date: Mon, 14 Jul 2008 13:30: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		: Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)
	Author(s)	: J. Le Roux, D. Papadimitriou, D. Brungard, E. Oki, K. Shiomoto, M. Vigoureux
	Filename	: draft-ietf-ccamp-gmpls-mln-eval-06.txt
	Pages		: 23
	Date		: 2008-7-14
	
This document provides an evaluation of Generalized Multi-Protocol 
   Label Switching (GMPLS) protocols and mechanisms against the 
   requirements for Multi-Layer Networks (MLN) and Multi-Region Networks 
   (MRN). In addition, this document identifies areas where additional 
   protocol extensions or procedures are needed to satisfy these 
   requirements, and provides guidelines for potential extensions.

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

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

--NextPart--

Delivery-date: Mon, 14 Jul 2008 19:16:28 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt 
Date: Mon, 14 Jul 2008 12: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 Labels for G.694 Lambda-Switching Capable Label Switching Routers
	Author(s)	: T. Otani, H. Guo, K. Miyazaki, D. Caviglia
	Filename	: draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
	Pages		: 10
	Date		: 2008-7-14
	
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-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-gmpls-g-694-lambda-labels-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Mon, 14 Jul 2008 19:01:45 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-02.txt 
Date: Mon, 14 Jul 2008 12:00: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		: Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
	Author(s)	: D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Roux, E. Oki, I. Inoue, E. Dotaro, G. Grammel
	Filename	: draft-ietf-ccamp-gmpls-mln-extensions-02.txt
	Pages		: 18
	Date		: 2008-7-14
	
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-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-gmpls-mln-extensions-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Mon, 14 Jul 2008 17:02:21 +0000
Date: Mon, 14 Jul 2008 13:01:45 -0400
From: "Peng He" <[email-masked]>
To: "Don Fedyk" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Cc: "CCAMP List" <[email-masked]>

Agreed from the viewpoint of functionality.

But see the context in your draft:

"...
Defined in both [802.1ag & Y.1731]:
   - CCM/RDI: Connectivity Check, Remote Defect Indication
   - LBM/LBR: Loopback Message, Loopback Reply
   - LTM/LTR: Link trace Message, Link trace Reply
   - VSM/VSR: Vendor-specific extensions Message/Reply

"
There are terms of 'CCM/RDI, LBM/LBR, LTM/LTR" both defined in 802.1ag
and Y.1731. That's fine. But there is no term like "VSM/VSR" defined
in 802.1ag, although there is a similar TLV  in 802.1ag. I just guess
that the current context (see above) might confuse people sometimes.

Regards,
Peng

On Mon, Jul 14, 2008 at 12:23 PM, Don Fedyk <[email-masked]> wrote:
> Hi Peng
>
> I believe this refers to 802.1ag Clause 21.5.2 Organization-Specific
> TLV.  My read of this is it supports Vendor specific messages.  Is that
> OK?
>
> Don
>
>> -----Original Message-----
>> From: Peng He [mailto:[email-masked]]
>> Sent: Monday, July 14, 2008 12:02 PM
>> To: Fedyk, Don (BL60:1A00)
>> Cc: CCAMP List
>> Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
>>
>> Hello Don,
>>
>> Just wonder if you are sure that the "VSM/VSR: Vendor-specific
>> extensions Message/Reply" is defined in 802.1ag also (page 8 in your
>> draft)?
>>
>>
>> Regards,
>> Peng
>>
>> 2008/7/14  <[email-masked]>:
>> > 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 Ethernet Label Switching
>> Architecture and Framework
>> >        Author(s)       : D. Fedyk, et al.
>> >        Filename        : draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
>> >        Pages           : 20
>> >        Date            : 2008-07-13
>> >
>> > There has been significant recent work in increasing the
>> capabilities
>> > of Ethernet switches and Ethernet forwarding models. As a
>> > consequence, the role of Ethernet is rapidly expanding into
>> > "transport networks" that previously were the domain of other
>> > technologies such as SONET/SDH TDM and ATM. This document defines an
>> > architecture and framework for a GMPLS based control plane for
>> > Ethernet in this "transport network" capacity. GMPLS has
>> already been
>> > specified for similar technologies. Some additional
>> extensions to the
>> > GMPLS control plane are needed and this document provides a
>> framework
>> > for these extensions.Contents
>> >
>> > A URL for this Internet-Draft is:
>> >
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth
> ernet-arch-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.
>> >
>> >
>> >
>>
>

Delivery-date: Mon, 14 Jul 2008 16:46:18 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-01.txt 
Date: Mon, 14 Jul 2008 09:45: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           : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching
	Author(s)       : L. Berger, et al.
	Filename        : draft-ietf-ccamp-gmpls-ether-svcs-01.txt
	Pages           : 22
	Date            : 2008-07-14

This document describes a method for controlling two specific types
of Ethernet switching via Generalized Multi-Protocol Label Switching
(GMPLS).  This document supports the types of switching required to
implied by the Ethernet services that have been defined in the
context of the Metro Ethernet Forum (MEF) and International
Telecommunication Union (ITU) G.8011.  Specifically, switching in
support of Ethernet private line service and Ethernet virtual private
line service.  Support for MEF and ITU defined parameters are also
covered.  Some of the extensions defined in this document are generic
in nature and not specific to Ethernet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-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-gmpls-ether-svcs-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, 14 Jul 2008 16:24:06 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Date: Mon, 14 Jul 2008 12:23:29 -0400
From: "Don Fedyk" <[email-masked]>
To: "Peng He" <[email-masked]>
Cc: "CCAMP List" <[email-masked]>

Hi Peng

I believe this refers to 802.1ag Clause 21.5.2 Organization-Specific
TLV.  My read of this is it supports Vendor specific messages.  Is that
OK?

Don =20

> -----Original Message-----
> From: Peng He [mailto:[email-masked]]=20
> Sent: Monday, July 14, 2008 12:02 PM
> To: Fedyk, Don (BL60:1A00)
> Cc: CCAMP List
> Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
>=20
> Hello Don,
>=20
> Just wonder if you are sure that the "VSM/VSR: Vendor-specific
> extensions Message/Reply" is defined in 802.1ag also (page 8 in your
> draft)?
>=20
>=20
> Regards,
> Peng
>=20
> 2008/7/14  <[email-masked]>:
> > A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> > This draft is a work item of the Common Control and=20
> Measurement Plane Working Group of the IETF.
> >
> >
> >        Title           : GMPLS Ethernet Label Switching=20
> Architecture and Framework
> >        Author(s)       : D. Fedyk, et al.
> >        Filename        : draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
> >        Pages           : 20
> >        Date            : 2008-07-13
> >
> > There has been significant recent work in increasing the=20
> capabilities
> > of Ethernet switches and Ethernet forwarding models. As a
> > consequence, the role of Ethernet is rapidly expanding into
> > "transport networks" that previously were the domain of other
> > technologies such as SONET/SDH TDM and ATM. This document defines an
> > architecture and framework for a GMPLS based control plane for
> > Ethernet in this "transport network" capacity. GMPLS has=20
> already been
> > specified for similar technologies. Some additional=20
> extensions to the
> > GMPLS control plane are needed and this document provides a=20
> framework
> > for these extensions.Contents
> >
> > A URL for this Internet-Draft is:
> >=20
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth
ernet-arch-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.
> >
> >
> >
>=20

Delivery-date: Mon, 14 Jul 2008 16:04:17 +0000
Date: Mon, 14 Jul 2008 12:02:29 -0400
From: "Peng He" <[email-masked]>
To: "Don Fedyk" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Cc: "CCAMP List" <[email-masked]>

Hello Don,

Just wonder if you are sure that the "VSM/VSR: Vendor-specific
extensions Message/Reply" is defined in 802.1ag also (page 8 in your
draft)?

Regards,
Peng

2008/7/14  <[email-masked]>:
> 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 Ethernet Label Switching Architecture and Framework
>        Author(s)       : D. Fedyk, et al.
>        Filename        : draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
>        Pages           : 20
>        Date            : 2008-07-13
>
> There has been significant recent work in increasing the capabilities
> of Ethernet switches and Ethernet forwarding models. As a
> consequence, the role of Ethernet is rapidly expanding into
> "transport networks" that previously were the domain of other
> technologies such as SONET/SDH TDM and ATM. This document defines an
> architecture and framework for a GMPLS based control plane for
> Ethernet in this "transport network" capacity. GMPLS has already been
> specified for similar technologies. Some additional extensions to the
> GMPLS control plane are needed and this document provides a framework
> for these extensions.Contents
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-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.
>
>
>

Delivery-date: Mon, 14 Jul 2008 13:00:10 +0000
Date: Mon, 14 Jul 2008 14:59:24 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked], L2VPN <[email-masked]>, ccamp <[email-masked]>,  pwe3 <[email-masked]>
Subject: mpls wg agenda for Dublin

All,

I've just uploaded a preliminary agenda for the MPLS wg meeting in
Dublin.

First: I've a strong feeling that I dropped one request for an agenda
slot, so could all of you who have requested  slots check if it got
on the the agenda.

Second: Pleas note that the agenda covers both MPLS wg meetings in
Dublin, Monday morning (the "traditional" wg meeting) and Wednesday
(the meeting on MPLS-TP). Though this meeting is formally a MPLS
wg meeting, since the focus is MPLS-TP it is from very important
aspects a joint meeting with pwe3, ccamp and l2vpn, this mails is
therefore sent to these working groups as well.

The agenda is available at;

http://www.ietf.org/proceedings/08jul/agenda/mpls.txt

/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:  [email-masked]
                                            [email-masked]

Delivery-date: Mon, 14 Jul 2008 12:47:16 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt 
Date: Mon, 14 Jul 2008 05: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           : GMPLS Ethernet Label Switching Architecture and Framework
	Author(s)       : D. Fedyk, et al.
	Filename        : draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
	Pages           : 20
	Date            : 2008-07-13

There has been significant recent work in increasing the capabilities
of Ethernet switches and Ethernet forwarding models. As a
consequence, the role of Ethernet is rapidly expanding into
"transport networks" that previously were the domain of other
technologies such as SONET/SDH TDM and ATM. This document defines an
architecture and framework for a GMPLS based control plane for
Ethernet in this "transport network" capacity. GMPLS has already been
specified for similar technologies. Some additional extensions to the
GMPLS control plane are needed and this document provides a framework
for these extensions.Contents

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

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

--NextPart--

Delivery-date: Mon, 14 Jul 2008 09:03:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Unable to travel to Dublin? Try listening.
Date: Mon, 14 Jul 2008 09:55:01 +0100

Here is news of the audio streaming from Dublin.
Adrian
----- Original Message ----- 
From: "Joel Jaeggli" <[email-masked]>
To: "IETF Discussion" <[email-masked]>
Sent: Sunday, July 13, 2008 9:35 PM
Subject: Audio Streaming - IETF 72 July 28th - August 1st

> Greetings,
> 
> All 8 parallel tracks will be broadcast starting with the
> commencement of working group sessions on Monday July 28 at 0900
> IST (UTC+1) and continue until Friday the 1st at 1130 IST. Additionally 
> it is our intention to broadcast the IEPG meeting occurring on Sunday 
> the 27th starting at 1000 IST.
> 
> Because I have been asked several times in the past, note that if you
> wish to use the rooms that are being recorded for impromptu meeting
> during unscheduled sessions or lunch breaks that you can invite remote
> participants to tune in to the appropriate stream. Recording cannot be
> guaranteed for unscheduled sessions. Conversely, it should never be
> assumed that recording or observation is not occurring on open
> microphones, they are after all connected to the Internet.
> 
> The links for streaming sources and the schedule (shortly) will be 
> available thanks to the continued support of the Network Startup 
> Resource Center in their traditional location:
> 
> http://videolab.uoregon.edu/events/ietf/
> 
> I Look forward to seeing some of you in Dublin and hope that this
> facility remains useful for remote participants in and observers of the
> IETF Process.
> 
> Regards
> Joel Jaeggli
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

Delivery-date: Mon, 14 Jul 2008 05:02:44 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt 
Date: Sun, 13 Jul 2008 22:00: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           : GMPLS control of Ethernet PBB-TE
	Author(s)       : D. Fedyk, et al.
	Filename        : draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt
	Pages           : 31
	Date            : 2008-07-13

This specification is complementary to the GMPLS controlled Ethernet
architecture document [ARCH] and describes the technology specific
aspects of GMPLS control for Provider Backbone Bridging Traffic
Engineering (PBB-TE) [IEEE 802.1Qay].  The necessary GMPLS extensions
and mechanisms are described to establish Ethernet PBB-TE point to
point (P2P) and point to multipoint (P2MP) connections. This document
supports, but does not modify, the standard IEEE data plane.

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

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

--NextPart--

Delivery-date: Sat, 12 Jul 2008 16:31:54 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-05.txt 
Date: Sat, 12 Jul 2008 09: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           : Ethernet Traffic Parameters
	Author(s)       : D. Papadimitriou, I. Property
	Filename        : draft-ietf-ccamp-ethernet-traffic-parameters-05.txt
	Pages           : 13
	Date            : 2008-07-12

This document describes the Metro Ethernet Forum (MEF) - specific
Ethernet Traffic Parameters as described in MEF10.1 when using
Generalized Multi-Protocol Label Switching (GMPLS) Resource
ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.

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

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

--NextPart--

Delivery-date: Sat, 12 Jul 2008 04:19:45 +0000
Date: Fri, 11 Jul 2008 21:17:40 -0700
From: "Richard Rabbat" <[email-masked]>
To: "Jishnu A" <[email-masked]>
Subject: Re: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments
Cc: [email-masked], [email-masked], [email-masked],  ccamp <[email-masked]>

------=_Part_15373_5259735.1215836260353
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Jishnu,
shouldn't we rather use use a procedure similar to the bandwidth increase
procedure of rfc 3209 (see 4.6.4)?
Richard.

On Thu, Jul 10, 2008 at 9:13 PM, Jishnu A <[email-masked]>
wrote:

>  Adding ccamp
>
>
>
> Regards,
>
> Jishnu A
>   ------------------------------
>
> *From:* Jishnu A [mailto:[email-masked]]
> *Sent:* Wednesday, July 09, 2008 11:15 AM
> *To:* [email-masked]'
> *Cc:* [email-masked]'; [email-masked]'
> *Subject:* draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments
>
>
>
> Dear Imajuku,
>
> One aspect presently not covered in the draft is modification of the VCG ID
> keeping the bandwidth same. This would be required in the case where some
> VCG member has to be relinquished for the purpose of reassigning it to some
> other purpose. This with the present architecture would require two calls:
> one for removing a VCG and second one for adding the new VCG ID. I am not
> sure if this is within the scope of this draft.
>
>
>
> If this is within the scope of the draft, my suggestion for it would be to
> have a Action value =4 in which case there are two VCG IDs, the first to be
> removed and the second to be added.
>
>
>
> Regards,
>
> Jishnu A
>
> Lead Engineer
>
> Standards & Technology Group
>
> CTO's Office
>
> Tejas Networks India Ltd
>
> No 58, 1st Main Road,
>
> J.P. Nagar 3rd Phase
>
> Bangalore - 78
>
>
>
> Phone: +91 80 4179 4635
>
> Mail:[email-masked]<[email-masked]>
>
>
>

------=_Part_15373_5259735.1215836260353
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Jishnu,<br>shouldn&#39;t we rather use use a procedure similar to the bandwidth increase procedure of rfc 3209 (see 4.6.4)?<br>Richard. <br><br><div class="gmail_quote">On Thu, Jul 10, 2008 at 9:13 PM, Jishnu A &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div link="blue" vlink="purple" lang="EN-US">

<div>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Adding ccamp</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">&nbsp;</span></font></p>

<div>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Regards,</span></font><font color="navy"><span style="color: navy;"></span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Jishnu A</span></font></p>

</div>

<div>

<div style="text-align: center;" align="center"><font size="3" face="Times New Roman"><span style="font-size: 12pt;">

<hr size="2" width="100%" align="center">

</span></font></div>

<p><b><font size="2" face="Tahoma"><span style="font-size: 10pt; font-family: Tahoma; font-weight: bold;">From:</span></font></b><font size="2" face="Tahoma"><span style="font-size: 10pt; font-family: Tahoma;"> Jishnu A
[mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style="font-weight: bold;">Sent:</span></b> Wednesday, July 09, 2008
11:15 AM<br>
<b><span style="font-weight: bold;">To:</span></b> &#39;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&#39;<br>
<b><span style="font-weight: bold;">Cc:</span></b> &#39;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&#39;;
&#39;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&#39;<br>
<b><span style="font-weight: bold;">Subject:</span></b>
draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments</span></font></p>

</div>

<p><font size="3" face="Times New Roman"><span style="font-size: 12pt;">&nbsp;</span></font></p>

<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">Dear Imajuku,</span></font></p>

<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">One aspect presently not covered in the draft is
modification of the VCG ID keeping the bandwidth same. This would be required in
the case where some VCG member has to be relinquished for the purpose of
reassigning it to some other purpose. This with the present architecture would
require two calls: one for removing a VCG and second one for adding the new VCG
ID. I am not sure if this is within the scope of this draft.</span></font></p>

<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">&nbsp;</span></font></p>

<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">If this is within the scope of the draft, my suggestion for
it would be to have a Action value =4 in which case there are two VCG IDs, the
first to be removed and the second to be added.</span></font></p>

<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">&nbsp;</span></font></p>

<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">Regards,</span></font></p>

<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">Jishnu A</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Lead Engineer</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Standards &amp; Technology Group</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">CTO's Office</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Tejas Networks India Ltd</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">No 58, 1st Main Road,</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">J.P. Nagar 3rd Phase</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Bangalore</span></font><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;"> - 78</span></font></p>

<p><font size="3" face="Times New Roman"><span style="font-size: 12pt;">&nbsp;</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Phone: +91 80 4179 4635</span></font></p>

<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;"><a href="mailto:[email-masked]" target="_blank">Mail:[email-masked]</a></span></font></p>

<p><font size="3" face="Times New Roman"><span style="font-size: 12pt;">&nbsp;</span></font></p>

</div>

</div>

</blockquote></div><br>

------=_Part_15373_5259735.1215836260353--

Delivery-date: Fri, 11 Jul 2008 04:16:10 +0000
From: "Jishnu A" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "ccamp" <[email-masked]>
Subject: RE: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments
Date: Fri, 11 Jul 2008 09:43:37 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_0021_01C8E33A.99D3C4E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Adding ccamp

Regards,

Jishnu A

  _____  

From: Jishnu A [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 11:15 AM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments

Dear Imajuku,

One aspect presently not covered in the draft is modification of the VCG ID
keeping the bandwidth same. This would be required in the case where some
VCG member has to be relinquished for the purpose of reassigning it to some
other purpose. This with the present architecture would require two calls:
one for removing a VCG and second one for adding the new VCG ID. I am not
sure if this is within the scope of this draft.

If this is within the scope of the draft, my suggestion for it would be to
have a Action value =4 in which case there are two VCG IDs, the first to be
removed and the second to be added.

Regards,

Jishnu A

Lead Engineer

Standards & Technology Group

CTO's Office

Tejas Networks India Ltd

No 58, 1st Main Road,

J.P. Nagar 3rd Phase

Bangalore - 78

Phone: +91 80 4179 4635

Mail:[email-masked]

------=_NextPart_000_0021_01C8E33A.99D3C4E0
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:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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 11 (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]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @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";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
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><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Adding =
ccamp<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,</span></font><font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Jishnu =
A</span></font><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Jishnu A
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July 09, =
2008
11:15 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]';
[email-masked]'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b>
draft-ietf-ccamp-gmpls-vcat-lcas-05.txt =
Comments</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Dear Imajuku,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>One aspect presently not covered in the draft is
modification of the VCG ID keeping the bandwidth same. This would be =
required in
the case where some VCG member has to be relinquished for the purpose of
reassigning it to some other purpose. This with the present architecture =
would
require two calls: one for removing a VCG and second one for adding the =
new VCG
ID. I am not sure if this is within the scope of this =
draft.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If this is within the scope of the draft, my =
suggestion for
it would be to have a Action value =3D4 in which case there are two VCG =
IDs, the
first to be removed and the second to be =
added.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Regards,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Jishnu A</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Lead =
Engineer</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Standards &amp; Technology =
Group<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>CTO&#8217;s =
Office</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Tejas Networks India =
Ltd</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>No 58, 1st Main =
Road,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>J.P. Nagar 3rd =
Phase</span></font><o:p></o:p></p>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Bangalore</span></font></st1:City></st1:place><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'> - 78</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Phone: +91 80 4179 =
4635</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Mail:[email-masked]<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0021_01C8E33A.99D3C4E0--

Delivery-date: Thu, 10 Jul 2008 21:29:57 +0000
Date: Thu, 10 Jul 2008 14:27:57 -0700
From: Greg Bernstein <[email-masked]>
To: ccamp <[email-masked]>
Subject: WSON Framework next steps...

Hi folks, one of the next steps for the WSON (wavelength switched 
optical networks) draft was to include wavelength converters a bit more 
rigorously.
We planed (and have tentative text) for relating the models of ITU-T 
G.872 to the current WSON work. Here is a quick summary of the issues 
and some thoughts.

1. Current ITU-T models for "optical channels" OCh tell us:
(a) G.872 OCh characteristic information (CI): maximum bandwidth and SNR 
(Section 5.3). Note that the CI doesn't include the wavelength.
Example of OCh through a wavelength converter in G.872 Appendix I, since 
the wavelength converter doesn’t change the CI this doesn’t involve 
changing layers.Or at least that was my impression.
(b) G.709 “… OCh transports a digital client signal between 3R 
regeneration points.”
2. Most (?) wavelength converters are OEO based and are also 3R 
regenerators.
Would like to handle connection through wavelength converters as a 
single LSP without stitching (RFC5150) if possible for most common cases.
3. Framework draft uses the term “Lightpath”
We didn’t define the characteristic information for this yet but 
signaling drafts are leaning towards such information as modulation, 
modulation parameters, bit rate and FEC since these are minimally needed 
to ascertain if an end system can process the signal into digital bits.
4. Could we define our Lightpath with characteristic information 
(modulation, modulation parameters, bit rate and FEC) then if a 
wavelength converter (whether optical or OEO based) preserves this CI 
then we can use a single LSP to describe. If the wavelength converter 
includes a 3R and changes some CI such as modulation parameter or FEC 
then an LSP stitching mechanism seems to be required.

We will bring this up at the Dublin meeting, but there isn't usually 
time for extended discussion, so figured it was best to kick this around 
on the list a bit.

Regards

Greg B.

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

Delivery-date: Thu, 10 Jul 2008 16:55:28 +0000
From: IESG Secretary <[email-masked]>
To: IETF Announcement list <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: WG Review: Recharter of Common Control and Measurement Plane  (ccamp) 
reply-to: [email-masked]
Date: Thu, 10 Jul 2008 09:52:49 -0700 (PDT)

A modified charter has been submitted for the Common Control and
Measurement Plane (ccamp) working group in the Routing Area of the IETF. 
The IESG has not made any determination as yet.  The modified charter is
provided below for informational purposes only.  Please send your comments
to the IESG mailing list ([email-masked]) by Thursday, July 17, 2008.

Common Control and Measurement Plane (ccamp)
--------------------------------------------

Last Modified: 2008-07-10

Current Status: Active Working Group

Chair(s):
    Adrian Farrel <[email-masked]> 
    Deborah Brungard <[email-masked]> 

Routing Area Director(s):
    Ross Callon <[email-masked]> 
    David Ward <[email-masked]> 

Routing Area Advisor:
    Ross Callon <[email-masked]> 

Technical Advisor(s):
    Lou Berger <[email-masked]> 

Mailing Lists:
    General Discussion: [email-masked]
    To Subscribe: [email-masked]
    In Body: subscribe ccamp
    Archive: https://ops.ietf.org/lists/ccamp

Description of Working Group:

Organizational Overview

The CCAMP working group coordinates the work within the IETF
defining a common control plane and a separate common measurement
plane for physical path and core tunneling technologies of Internet
and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O
optical switches, TDM Switches, Ethernet Switches, ATM and Frame
Relay switches, IP encapsulation tunneling technologies, and MPLS
in cooperation with the MPLS WG.

In this context, measurement refers to the acquisition and
distribution of attributes relevant to the setting up of tunnels
and paths.

CCAMP WG work scope includes:

- Definition of protocol-independent metrics and parameters
  (measurement attributes) for describing links and paths that are
  required for routing and signaling. These will be developed in
  conjunction with requests and requirements from other WGs to
  ensure overall usefulness.

- Definition of protocol(s) and extensions to them required for
  link and path attribute measurement. Link Management Protocol
  (LMP) is included here.

- Functional specification of extensions for routing (OSPF, ISIS)
  and signalling (RSVP-TE) required for path establishment.
  Protocol formats and procedures that embody these extensions will
  be done jointly with the WGs supervising those protocols.

- Definition of the mechanisms required to determine the route and
  properties of an established path (tunnel tracing).

- Definition of management objects (e.g. as part of MIB modules) and 
  OAM techniques relevant to the protocols and extensions specified 
  within the WG.

- Work on traffic-engineering GMPLS mechanisms and protocol
  extensions to support source-controlled and explicitly-routed
  Ethernet data paths for Ethernet data planes that are already
  approved by an Standards Development Organization (SDO) with 
  responsibility for the Ethernet data plane. It is expected that the 
  primary SDO in this case is the IEEE. Note that the specification or 
  modification of Ethernet data planes is out of scope.
- Work on GMPLS mechanisms and protocol extensions to support the
  transport profile of MPLS (MPLS-TP) in cooperation with the MPLS, 
  L2VPN, and PWE3 Working Group and in coordination with the 
  requirements expressed jointly by the IETF and ITU-T.

CCAMP WG currently works on the following tasks:

- Define how the properties of network resources gathered by a
  measurement protocol can be distributed in existing routing
  protocols, such as OSPF and IS-IS. CCAMP defines the generic
  description of the properties and how they are distributed in
  OSPF. The specifics of distribution within IS-IS are being
  addressed in the ISIS WG.

- Define signaling and routing mechanisms and extensions to allow
  path and tunnel setup and maintenance across multiple domains,
  where a domain may be an IGP area, an Autonomous System, or any
  other region of topological visibility. To this end, work
  cooperatively with the PCE and MPLS WGs.

- Define abstract link and path properties needed for link and
  path protection. Specify signalling mechanisms for path
  protection, diverse routing and fast path restoration. Ensure
  that multi-layer path protection and restoration functions are
  achievable using the defined signalling, routing, and measurement
  protocols, either separately or in combination.

- Identify which requirements for signaling and routing for 
  Automatically Switched Optical Network (ASON) are not currently met 
  by protocols defined in CCAMP; based on these, define mechanisms to 
  address these requirements.

- Produce extensions to the CCAMP WG protocols and RFCs necessary
  to create an MPLS Transport Profile (MPLS TP). The work on the
  MPLS TP will be coordinated between the MPLS, L2VPN, PWE3, and CCAMP
  working groups that are jointly chartered to do MPLS TP work.

In doing this work, the WG will work closely with at least the
following other WGs: MPLS, L2VPN, PWE3, ISIS, OSPF, IDR, L1VPN and PCE. 
The WG will also cooperate with the ITU-T and the IEEE 802.1.

Goals and Milestones:

Done    Post strawman WG goals and charter
Done    Identify and document a limited set of candidate solutions for 
        signalling and for measurement. Among candidate control solutions

        to be considered are the existing GMPLS drafts.
Done    Build appropriate design teams
Done    Submit WG document defining path setup portions of common 
        control plane protocol
Done    Submit WG document defining common measurement plane protocol
Done    Submit LMP MIB to IESG
Done    Submit protection & restoration documents to IESG
Done    Submit ASON signaling requirements doc to IESG
Done    Submit GMPLS MIBs to IESG
Done    Produce CCAMP WG document for generic tunnel tracing protocol
Done    Produce CCAMP WG document for multi-area/AS signaling and 
        routing
Done    Submit ASON routing requirements doc to IESG
Done    Submit revised charter and milestones to IESG for IESG 
        consideration of more detailed deliverables and determination 
        of usefulness of continuation of WG
Done    First version WG I-D for Advertising TE Node Capabilities in 
        ISIS and OSPF
Done    First version WG I-D for Automatic discovery of MPLS-TE mesh 
        membership
Done    Submit ASON Routing evaluation I-D for IESG review
Done    Cross-WG review of I-D for Advertising TE Node Capabilities in 
        ISIS and OSPF
Done    First version WG I-D MPLS to GMPLS migration strategies
Done    First version WG I-D Requirements for Multi-Layer and Multi-
        Region Networks
Done    First version WG I-D for Evaluation of existing protocols for 
        MLN/MRN
Done    First version of WG I-D for ASON Routing solutions
Done    Submit RSVP-TE extensions for inter-domain signaling I-D for 
        IESG review
Done    Submit Per-domain path computation signaling I-D for IESG review
Done    First version of WG I-D for OSPF-TE/GMPLS MIB module
Done    Submit GMPLS signaling in support of Call Management I-D for 
        IESG review
Done    First version WG Informational I-D for Analysis of inter-domain 
        issues for disjoint and protected paths
Done    Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF 
        for IESG review
Done    First version WG I-D for Protocol solutions for MLN/MRN
Done    Submit GMPLS/ASON lexicography I-D for IESG review
Done    First version WG I-D MPLS-GMPLS interworking requirements and 
        solutions
Done    Submit LSP Stitching I-D for IESG review
Done    Submit I-D for Automatic discovery of MPLS-TE mesh membership 
        for IESG review
Done    First version WG I-D GMPLS OAM Requirements
Done    Submit GMPLS routing and signaling interoperability advice I-D 
        for IESG review
Done    Submit MPLS to GMPLS migration strategies I-D for IESG review
Done    Submit Requirements for Multi-Layer and Multi-Region Networks 
        I-D for IESG review
Done    Submit MPLS-GMPLS interworking requirements and solutions I-D 
        for IESG review
Done    Submit Evaluation of existing protocols for MLN/MRN for IESG 
        review
Done    First version WG I-Ds for GMPLS source-controlled and 
        explicitly-routed Ethernet networks
Done    Submit Informational I-D for Analysis of inter-domain issues for 
        disjoint and protected paths for IESG review
Aug 2008    First version of Working Group draft providing Control Plane 
            Framework for MPLS-TP
Sep 2008    Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG 
            review
Oct 2008    First version of Working Group draft defining RSVP-TE 
            extensions for MPLS-TP
Dec 2008    Submit GMPLS OAM Requirements I-D for IESG review
Dec 2008    Submit ASON Routing solutions I-D for IESG review
Jan 2009    Submit protocol extensions for GMPLS source-controlled and 
            explicitly-routed Ethernet networks for IESG review
Feb 2009    Submit Protocol solutions for MLN/MRN I-D for IESG review
Mar 2009    Submit Control Plane Framework for MPLS-TP for IESG review
Jun 2009    Submit RSVP-TE extensions for MPLS-TP for IESG review
Jun 2009    Recharter or close Working Group

Delivery-date: Thu, 10 Jul 2008 12:00:29 +0000
Date: Thu, 10 Jul 2008 13:59:29 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], ccamp <[email-masked]>,  L2VPN <[email-masked]>, pwe3 <[email-masked]>, [email-masked]
Subject: multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt

All,

this mail initiates a two week multiple-working group last call on

draft-ietf-mpls-cosfield-def-04.txt

Background:

The name "EXP field" of a three bit field in the MPLS shim header,
and the statement in RFC3032 "For experimental use" has led other
SDOs to believe that this field could be used for any type of
experiments. The field has however from the start been intended to
carry Class of Service (CoS) information.

The draft therefore renames the field "Class of Service (CoS) Field".

This is an update of RFC3032, and also of drafts that builds on
RFC3032. This multiple-working group last call is therefore sent to
working groups with RFCs that has been updated.

The document has been through wg last call in the mpls working group,
which I don't think will stop that wg producing new comments now,
nor should it :) .

This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG.

Since this is also of interest in the work we started on a
Transport Profile for MPLS (MPLS-TP) we are also sending it to the
Ad HoC Team on MPLS in the ITU-T.

Please review and send comments to the mpls wg mailing list, or to
the mailing list for mpls-tp discussion that just been set up:

[email-masked]

or directly to the mpls wg co-chairs before e.o.b. July 24.

/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:  [email-masked]
                                            [email-masked]

Delivery-date: Thu, 10 Jul 2008 11:44:38 +0000
Date: Thu, 10 Jul 2008 13:41:48 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], MEAD team <[email-masked]>,  [email-masked], [email-masked], ccamp <[email-masked]>,  pwe3 <[email-masked]>, L2VPN <[email-masked]>
Subject: First version of the first MPLS-TP documents

All,

the MPLS-TP work that started after the ITU-T acceptance of the JWT
advice to work with the iETF, using IETF processes, to create a MPLS
Transport Profile (MPLS-TP) within the IETF MPLS architecture.

This effort has now produced a set of documents available in their
first versions. In IETF terminology the documents are still
"individual drafts", but will after discussion, review and updates
hopefully become working groups documents.

First I'd like to thank all the people that has put in efforts to
make this possible, we are actually a bit better of than we planned.
Thanks to all editors and contributing authors!

When accepting documents as working group documents there are two
criteria that working groups are looking at:

- is this document addressing a problem that needs to be solved
- is this document a good starting point in solving this problem

The MPLS-TP documents are in some aspects special with respect to
the IETF process, the JWT produced guidelines on which documents
that needs to be included in the MPLS-TP. The MEAD team has since
"improved and extended" the document list. This makes us pretty
sure that the documents address problems that needs to be solved.

However it is usually beneficial to have documents reviewed early in
order to create a the starting point needed for solving the problem.

We therefore now invite both IETF working groups (CCAMP, MPLS, L2VPN
and PWE3), the MPLS Interoperability (MEAD) team, the JWT and the
ITU-T Ad Hoc MPLS group to participate in this review.

The newly produced documents are:

1. A Framework for MPLS in Transport Networks
     <draft-blb-mpls-tp-framework-00.txt>

2. MPLS Generic Associated Channel
    <draft-bocci-pwe3-mpls-tp-ge-ach-00.txt>

3. MPLS TP Network Management Requirements
    <draft-gray-mpls-tp-nm-req-00.txt>

4. MPLS-TP Requirements
    <draft-jenkins-mpls-mpls-tp-requirements-00.txt>

5. MPLS-TP OAM Analysis
    <draft-sprecher-mpls-tp-oam-analysis-00.txt>

6. Multiprotocol Label Switching Transport Profile Survivability
    Framework
    <draft-sprecher-mpls-tp-survive-fwk-00.txt>

7. Assignment of the Generic Associated Channel Header Label (GAL)
    <draft-vigoureux-mpls-tp-gal-00.txt>

8. Requirements for OAM in MPLS Transport Networks
    <draft-vigoureux-mpls-tp-oam-requirements-00.txt>

9. JWT Report on MPLS Architectural Considerations for a Transport
    Profile
    <draft-bryant-mpls-tp-jwt-report-00.txt>

    Note: This is a document is created to an easily referencable and
    permanent storage for the JWT conclusions and advice. The major
    part of the document are the JWT slides, since it is not possible
    to change the slides it is only the commentary part of the
    document that is possible to comment on.

It is always possible to to send comments on these documents to the
MPLS working group mailing list, for document #2 (The Generic MPLS
Associated Channel) comments could also go to the PWE3 mailing list.

However, we are setting up a dedicated mailing list for the MPLS-TP
discussions:

[email-masked]

To subscribe to this list send a mail to [email-masked],
and confirm by replying or visiting the indicated web-page.

The easiest way to find all the MPLS-TP documents is to use the IETF
ID Tracker:

https://datatracker.ietf.org/idtracker/

and put "mpls-tp" in the filename field.

There is also a 10th document that people from the JWT has pointed
out to us would be beneficial if it did go through the same review
process.

10. "EXP field" renamed to  "CoS Field"
     <draft-ietf-mpls-cosfield-def-04.txt>

The document has been progressed within the IETF as a normal MPLS
document, and has passed MPLS working group last call. However, we
need to run it through working group last call in the working groups
with RFCs that is updated by this document. The ITU-T Ad Hoc MPLS
group will be invited to participate in this wg last call. A mail
will go out shortly with details of this working group last call.

The process in the future will be that when a MPLS-TP document is
published or updated a note will be sent to the relevant working
group (this is an automated IETF process), this note will also be
forwarded to the ITU-T Ad Hoc MPLS group.

Receiving such a note indicates that it is time to review and
comment on the document. When a document goes into working group
last call the mail initiating the last call will also be sent to the
ITU-T Ad Hoc MPLS group. Receiving such a last call REQUIRES, as per
the agreement within the JWT, that the ITU-T respond formally,
indicating either that the document is accepted or indicating
necessary changes.

To test this process we'd appreciate very much if the ITU-T
treated the upcoming last call on this document the same way.

/Loa (chair of the MEAD team)

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Thu, 10 Jul 2008 03:47:52 +0000
Date: Thu, 10 Jul 2008 11:45:49 +0800
From: Dan Li <[email-masked]>
Subject: Re: Times slots for WSON drafts at CCAMP...
To: Greg Bernstein <[email-masked]>, ccamp <[email-masked]>

Hi,

We are updating WSON-IGP-EVAL draft, and try to make it be consistent with WSON Info Model Encoding draft. So we also would like to request a timesolt in CCAMP session.

Thanks,

Dan
 
----- Original Message ----- 
From: "Greg Bernstein" <[email-masked]>
To: "ccamp" <[email-masked]>
Sent: Wednesday, July 09, 2008 10:03 PM
Subject: Times slots for WSON drafts at CCAMP...

> Hi Chairs and WG participants. There are a number of drafts concerning 
> Wavelength Switched Optical Networks (WSON) that will (or may) want a 
> time slot for the Dublin meeting.  Here is a list of those that I know 
> of and what would/could be discussed:
> 
> (a) Framework Draft -- Mostly a discussion of update plans, this hasn't 
> been changed since becoming a working group document a few months back.
> (b) WSON High Level Information Model -- This has been significantly 
> refined since it was split off from the previous info model draft per 
> the chair's suggestion.
> (c) WSON Info Model Encoding -- This also has been significantly refined 
> since it was split off from the previous info model draft.
> 
> (d) WSON Signaling -- This is a merging of two drafts from separate 
> groups of contributors. Requirements and solutions are clearly delimited 
> in this new draft. Dan King has volunteered to present.
> (e) G.694 based lambda labels -- Did Tomohiro want to give us a quick 
> update since this is now a WG document?
> 
> (f) I saw a new draft from Zhihong Kang and others at ZTE. This seems to 
> hit a number of topics related to the on going WSON work. I didn't know 
> if they wanted a slot at Dublin. This is probably closer to framework 
> and modeling than to signaling issues.
> 
> All the above have been uploaded. I'll send an update with links once 
> they are posted by the IETF. Also there was some discussion of a CCAMP 
> sponsored sub-mailing list for WSON discussions any progress?
> 
> Thanks
> 
> Greg B.
> 
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
> 
> 
> 

Envelope-to: [email-masked]
Delivery-date: Wed, 09 Jul 2008 23:39:48 +0000
To: [email-masked], [email-masked]
Subject: RFC 5212 on Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Wed,  9 Jul 2008 16:37:12 -0700 (PDT)

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

        RFC 5212

        Title:      Requirements for GMPLS-Based Multi-Region and 
                    Multi-Layer Networks (MRN/MLN) 
        Author:     K. Shiomoto, D. Papadimitriou,
                    JL. Le Roux, M. Vigoureux,
                    D. Brungard
        Status:     Informational
        Date:       July 2008
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      28
        Characters: 70286
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gmpls-mln-reqs-11.txt

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

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 single or multiple regions, this
document uses the term multi-layer network (MLN).  This document
defines a framework for GMPLS based multi-region / multi-layer
networks and lists a set of functional requirements.  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

Delivery-date: Wed, 09 Jul 2008 15:15:55 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 17:14:05 +0200
From: "Attila Takacs" <[email-masked]>
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, "Loa Andersson" <[email-masked]>, "ccamp" <[email-masked]>

Hi Dimitri,
Please see inline!=20
Attila

> -----Original Message-----
> From: PAPADIMITRIOU Dimitri=20
> [mailto:[email-masked]]=20
> Sent: Wednesday, July 09, 2008 4:39 PM
> To: Attila Takacs; Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> =20
> hi - see inline:
> > -----Original Message-----
> > From: Attila Takacs [mailto:[email-masked]]
> > Sent: Wednesday, July 09, 2008 4:12 PM
> > To: PAPADIMITRIOU Dimitri; Loa Andersson; ccamp
> > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> >=20
> > Hi Dimitri,
> >=20
> > Thanks for the comments!
> > Pease see inline.
> > Best regards,
> > Attila
> >=20
> > > -----Original Message-----
> > > From: PAPADIMITRIOU Dimitri
> > > [mailto:[email-masked]]
> > > Sent: Wednesday, July 09, 2008 2:55 PM
> > > To: Attila Takacs; Loa Andersson; ccamp
> > > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > >=20
> > > attila,
> > >=20
> > > once you are at it, can u explain the following "to=20
> properly setup=20
> > > the remote data plane endpoints" ? what it actually means in the=20
> > > context:
> > >=20
> > > "Such an example is protection switching of bidirectional=20
> > > connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under=20
> > > standardisation in IEEE).  In this case revertiveness=20
> needs to be =20
> > > signalled by RSVP-TE during LSP establishment to properly=20
> setup the =20
> > > remote data plane endpoint."
> > >=20
> >=20
> > With regards to PBB-TE, 1:1 bidirectional protection with=20
> or without=20
> > reversion is supported by the data plane and are executed in data=20
> > plane independently of management or external signaling.=20
> However, this=20
> > requires to configure both endpoints the same way, i.e., protection=20
> > with or without reversion. For this RSVP-TE needs to add=20
> signaling of=20
> > the revertive property.
>=20
> it is to be used iff reversion is not governed by control and=20
> setup during provisioning - ok this i understand=20
>=20
> what i do not is the properly catch is this setup of the=20
> remote data plane endpoint, but which specific config is this=20
> ? in part in the PBB-TE context ?
>=20

When establishing a protection group with worker and protection PBB-TE
ESPs one needs also to specify if reversion is enabled and if so the WTR
time. In particular a WTR timer needs to be specified, which has a
reserved value that disables reversion.

> > > also do u need a V bit, or isn't the WTR time with a=20
> reserved value=20
> > > not sufficient e.g. 0x0 ? when for inst. the locally configured=20
> > > timer would be used (no timer signaled).
> >=20
> > Agreed, we would not need a bit if we had a WTR field with=20
> a reserved=20
> > value. On the other hand, if the WTR value is not required=20
> to change=20
> > on a per-LSP basis, which is possibly the general case, we=20
> would not=20
> > need a WTR field occupying several bits, instead just have single=20
> > revertive bit.
>=20
> you ask for both support and use of the V-bit and WTR timer=20
> in the doc - right ? the fact the WTR is mandatory removes=20
> the needed for a dedicated bit. you can even have something like:
> 0b0000 enable (using local configured timer)
> 0b1111 disable
> 0b0001-0b1110 enable with the signaled timer.
>=20
> this should also solve the below problem entirely assuming=20
> the WTR timer goes before LSP flags.

Agreed.

> -d.
> > > the revertive operation is associated to LSP right ? why did you=20
> > > pull this into the 16-bit space for Link specific=20
> operation (before=20
> > > link flags ?)
> > >=20
> >=20
> > I think there are options to place this information:
> >=20
> > -it could have a dedicated bit (V) as it is in the ID=20
> -alternatively=20
> > reversion may be added to LSP Flags as a specific protection type=20
> > (e.g., adding new types such as Revertive 1:N Protection, Revertive=20
> > 1+1 Bidirectional Protection,...)
> >=20
> > -you are right about the WTR time, it should go before the LSP Flags
> >=20
> >=20
> >=20
> >=20
> > > thx,
> > > -d.
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Attila Takacs
> > > > Sent: Wednesday, July 09, 2008 2:34 PM
> > > > To: Loa Andersson; ccamp
> > > > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > > >=20
> > > > Hi Loa,
> > > >=20
> > > > I assume a part of your comment/question relates to=20
> problems with=20
> > > > reversion if LSP setup and holding priorities are
> > > mismatched. In this
> > > > case the worker may be already deleted before the reversion
> > > would take
> > > > place. This is certainly an interesting question...
> > > >=20
> > > > ...at a first thought an explicit revertive bit may be used to=20
> > > > override the priorities for LSPs with revertive protection.
> > > >=20
> > > > Best regards,
> > > > Attila
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: Loa Andersson [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 09, 2008 12:01 PM
> > > > > To: ccamp; Attila Takacs
> > > > > Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > > > >=20
> > > > > Attila,
> > > > >=20
> > > > > a neat draft that does what it sets out to do. For the
> > > moment I've
> > > > > no actual comments on the draft itself (might have when
> > > I'd time to
> > > > > think about in detail), but more meta-question.
> > > > >=20
> > > > > It is not a given that the revertive behavior always is
> > > beneficial.=20
> > > > > In networks that are very dynamic it might be optional
> > to revert,
> > > > > let the traffic stay on the protecting path or replace them=20
> > > > > altogether.
> > > > >=20
> > > > > Wouldn't it be interesting to discuss more in detail when a=20
> > > > > revertive behavior is needed/wanted and when it is not.
> > > > >=20
> > > > > /Loa
> > > > >=20
> > > > > [email-masked] wrote:
> > > > > > A New Internet-Draft is available from the on-line
> > > > > Internet-Drafts directories.
> > > > > >=20
> > > > > > 	Title           : GMPLS RSVP-TE recovery extension for=20
> > > > > data plane initiated reversion
> > > > > > 	Author(s)       : A. Takacs, B. Tremblay
> > > > > > 	Filename        : draft-takacs-ccamp-revertive-ps-00.txt
> > > > > > 	Pages           : 11
> > > > > > 	Date            : 2008-07-06
> > > > > >=20
> > > > > > RSVP-TE recovery extensions are specified in [RFC4872] and
> > > > > [RFC4873].
> > > > > > Currently these extensions cannot signal request for
> > revertive
> > > > > > protection to the remote endpoint.  This document defines a
> > > > > new bit to
> > > > > > signal this request and a new field to specify a
> > > wait-to-restore
> > > > > > interval.Requirements Language
> > > > > >=20
> > > > > > 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
> > > > > >=20
> > > > > > A URL for this Internet-Draft is:
> > > > > >=20
> > > > >=20
> > > >=20
> > >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > > > > > .txt
> > > > > >=20
> > > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > > ftp://ftp.ietf.org/internet-drafts/
> > > > > >=20
> > > > > > Below is the data which will enable a MIME compliant
> > > mail reader
> > > > > > implementation to automatically retrieve the ASCII
> > > version of the
> > > > > > Internet-Draft.
> > > > > >=20
> > > > > >=20
> > > > > >=20
> > > > >=20
> > > >=20
> > >=20
> >=20
> ----------------------------------------------------------------------
> > > > > > --
> > > > > >=20
> > > > > > _______________________________________________
> > > > > > I-D-Announce mailing list
> > > > > > [email-masked]
> > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > > > Internet-Draft directories:=20
> > http://www.ietf.org/shadow.html or
> > > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > >=20
> > > > >=20
> > > > > --
> > > > > Loa Andersson
> > > > >=20
> > > > > Principal Networking Architect
> > > > > Acreo AB                           phone:  +46 8 632 77 14
> > > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > > > Kista, Sweden                      email: =20
> > [email-masked]
> > > > >                                             [email-masked]
> > > > >=20
> > > >=20
> > > >=20
> > >=20
> >=20
>=20

Delivery-date: Wed, 09 Jul 2008 14:42:25 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 16:39:07 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Attila Takacs" <[email-masked]>, "Loa Andersson" <[email-masked]>, "ccamp" <[email-masked]>

=20
hi - see inline:
> -----Original Message-----
> From: Attila Takacs [mailto:[email-masked]]=20
> Sent: Wednesday, July 09, 2008 4:12 PM
> To: PAPADIMITRIOU Dimitri; Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> Hi Dimitri,
>=20
> Thanks for the comments!
> Pease see inline.
> Best regards,
> Attila=20
>=20
> > -----Original Message-----
> > From: PAPADIMITRIOU Dimitri=20
> > [mailto:[email-masked]]=20
> > Sent: Wednesday, July 09, 2008 2:55 PM
> > To: Attila Takacs; Loa Andersson; ccamp
> > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> >=20
> > attila,
> >=20
> > once you are at it, can u explain the following "to properly=20
> > setup the remote data plane endpoints" ? what it actually=20
> > means in the context:
> >=20
> > "Such an example is protection switching of bidirectional =20
> > connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under =20
> > standardisation in IEEE).  In this case revertiveness needs=20
> > to be  signalled by RSVP-TE during LSP establishment to=20
> > properly setup the  remote data plane endpoint."
> >=20
>=20
> With regards to PBB-TE, 1:1 bidirectional protection with or without
> reversion is supported by the data plane and are executed in=20
> data plane
> independently of management or external signaling. However, this
> requires to configure both endpoints the same way, i.e.,=20
> protection with
> or without reversion. For this RSVP-TE needs to add signaling of the
> revertive property.

it is to be used iff reversion is not governed by control
and setup during provisioning - ok this i understand=20

what i do not is the properly catch is this setup of the=20
remote data plane endpoint, but which specific config is=20
this ? in part in the PBB-TE context ?

> > also do u need a V bit, or isn't the WTR time with a reserved=20
> > value not sufficient e.g. 0x0 ? when for inst. the locally=20
> > configured timer would be used (no timer signaled).
>=20
> Agreed, we would not need a bit if we had a WTR field with a reserved
> value. On the other hand, if the WTR value is not required to=20
> change on
> a per-LSP basis, which is possibly the general case, we would=20
> not need a
> WTR field occupying several bits, instead just have single revertive
> bit.

you ask for both support and use of the V-bit and WTR timer in the=20
doc - right ? the fact the WTR is mandatory removes the needed for
a dedicated bit. you can even have something like:
0b0000 enable (using local configured timer)
0b1111 disable=20
0b0001-0b1110 enable with the signaled timer.

this should also solve the below problem entirely assuming the WTR
timer goes before LSP flags.
-d.
> > the revertive operation is associated to LSP right ? why did=20
> > you pull this into the 16-bit space for Link specific=20
> > operation (before link flags ?)
> >=20
>=20
> I think there are options to place this information:
>=20
> -it could have a dedicated bit (V) as it is in the ID
> -alternatively reversion may be added to LSP Flags as a specific
> protection type (e.g., adding new types such as Revertive 1:N
> Protection, Revertive 1+1 Bidirectional Protection,...)
>=20
> -you are right about the WTR time, it should go before the LSP Flags=20
>=20
>=20
>=20
>=20
> > thx,
> > -d.
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Attila Takacs
> > > Sent: Wednesday, July 09, 2008 2:34 PM
> > > To: Loa Andersson; ccamp
> > > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > >=20
> > > Hi Loa,
> > >=20
> > > I assume a part of your comment/question relates to problems with=20
> > > reversion if LSP setup and holding priorities are=20
> > mismatched. In this=20
> > > case the worker may be already deleted before the reversion=20
> > would take=20
> > > place. This is certainly an interesting question...
> > >=20
> > > ...at a first thought an explicit revertive bit may be used to=20
> > > override the priorities for LSPs with revertive protection.
> > >=20
> > > Best regards,
> > > Attila
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: Loa Andersson [mailto:[email-masked]]
> > > > Sent: Wednesday, July 09, 2008 12:01 PM
> > > > To: ccamp; Attila Takacs
> > > > Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > > >=20
> > > > Attila,
> > > >=20
> > > > a neat draft that does what it sets out to do. For the=20
> > moment I've=20
> > > > no actual comments on the draft itself (might have when=20
> > I'd time to=20
> > > > think about in detail), but more meta-question.
> > > >=20
> > > > It is not a given that the revertive behavior always is=20
> > beneficial.=20
> > > > In networks that are very dynamic it might be optional=20
> to revert,=20
> > > > let the traffic stay on the protecting path or replace them=20
> > > > altogether.
> > > >=20
> > > > Wouldn't it be interesting to discuss more in detail when a=20
> > > > revertive behavior is needed/wanted and when it is not.
> > > >=20
> > > > /Loa
> > > >=20
> > > > [email-masked] wrote:
> > > > > A New Internet-Draft is available from the on-line
> > > > Internet-Drafts directories.
> > > > >=20
> > > > > 	Title           : GMPLS RSVP-TE recovery extension for=20
> > > > data plane initiated reversion
> > > > > 	Author(s)       : A. Takacs, B. Tremblay
> > > > > 	Filename        : draft-takacs-ccamp-revertive-ps-00.txt
> > > > > 	Pages           : 11
> > > > > 	Date            : 2008-07-06
> > > > >=20
> > > > > RSVP-TE recovery extensions are specified in [RFC4872] and
> > > > [RFC4873].
> > > > > Currently these extensions cannot signal request for=20
> revertive=20
> > > > > protection to the remote endpoint.  This document defines a
> > > > new bit to
> > > > > signal this request and a new field to specify a=20
> > wait-to-restore=20
> > > > > interval.Requirements Language
> > > > >=20
> > > > > 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
> > > > >=20
> > > > > A URL for this Internet-Draft is:
> > > > >=20
> > > >=20
> > >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > > > > .txt
> > > > >=20
> > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > ftp://ftp.ietf.org/internet-drafts/
> > > > >=20
> > > > > Below is the data which will enable a MIME compliant=20
> > mail reader=20
> > > > > implementation to automatically retrieve the ASCII=20
> > version of the=20
> > > > > Internet-Draft.
> > > > >=20
> > > > >=20
> > > > >=20
> > > >=20
> > >=20
> >=20
> ----------------------------------------------------------------------
> > > > > --
> > > > >=20
> > > > > _______________________________________________
> > > > > I-D-Announce mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > > Internet-Draft directories:=20
> http://www.ietf.org/shadow.html or=20
> > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >=20
> > > >=20
> > > > --
> > > > Loa Andersson
> > > >=20
> > > > Principal Networking Architect
> > > > Acreo AB                           phone:  +46 8 632 77 14
> > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > > Kista, Sweden                      email: =20
> [email-masked]
> > > >                                             [email-masked]
> > > >=20
> > >=20
> > >=20
> >=20
>=20

Delivery-date: Wed, 09 Jul 2008 14:12:42 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 16:11:54 +0200
From: "Attila Takacs" <[email-masked]>
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, "Loa Andersson" <[email-masked]>, "ccamp" <[email-masked]>

Hi Dimitri,

Thanks for the comments!
Pease see inline.
Best regards,
Attila=20

> -----Original Message-----
> From: PAPADIMITRIOU Dimitri=20
> [mailto:[email-masked]]=20
> Sent: Wednesday, July 09, 2008 2:55 PM
> To: Attila Takacs; Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> attila,
>=20
> once you are at it, can u explain the following "to properly=20
> setup the remote data plane endpoints" ? what it actually=20
> means in the context:
>=20
> "Such an example is protection switching of bidirectional =20
> connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under =20
> standardisation in IEEE).  In this case revertiveness needs=20
> to be  signalled by RSVP-TE during LSP establishment to=20
> properly setup the  remote data plane endpoint."
>=20

With regards to PBB-TE, 1:1 bidirectional protection with or without
reversion is supported by the data plane and are executed in data plane
independently of management or external signaling. However, this
requires to configure both endpoints the same way, i.e., protection with
or without reversion. For this RSVP-TE needs to add signaling of the
revertive property.

> also do u need a V bit, or isn't the WTR time with a reserved=20
> value not sufficient e.g. 0x0 ? when for inst. the locally=20
> configured timer would be used (no timer signaled).
>=20

Agreed, we would not need a bit if we had a WTR field with a reserved
value. On the other hand, if the WTR value is not required to change on
a per-LSP basis, which is possibly the general case, we would not need a
WTR field occupying several bits, instead just have single revertive
bit.

> the revertive operation is associated to LSP right ? why did=20
> you pull this into the 16-bit space for Link specific=20
> operation (before link flags ?)
>=20

I think there are options to place this information:

-it could have a dedicated bit (V) as it is in the ID
-alternatively reversion may be added to LSP Flags as a specific
protection type (e.g., adding new types such as Revertive 1:N
Protection, Revertive 1+1 Bidirectional Protection,...)

-you are right about the WTR time, it should go before the LSP Flags=20

> thx,
> -d.
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Attila Takacs
> > Sent: Wednesday, July 09, 2008 2:34 PM
> > To: Loa Andersson; ccamp
> > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> >=20
> > Hi Loa,
> >=20
> > I assume a part of your comment/question relates to problems with=20
> > reversion if LSP setup and holding priorities are=20
> mismatched. In this=20
> > case the worker may be already deleted before the reversion=20
> would take=20
> > place. This is certainly an interesting question...
> >=20
> > ...at a first thought an explicit revertive bit may be used to=20
> > override the priorities for LSPs with revertive protection.
> >=20
> > Best regards,
> > Attila
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: Loa Andersson [mailto:[email-masked]]
> > > Sent: Wednesday, July 09, 2008 12:01 PM
> > > To: ccamp; Attila Takacs
> > > Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > >=20
> > > Attila,
> > >=20
> > > a neat draft that does what it sets out to do. For the=20
> moment I've=20
> > > no actual comments on the draft itself (might have when=20
> I'd time to=20
> > > think about in detail), but more meta-question.
> > >=20
> > > It is not a given that the revertive behavior always is=20
> beneficial.=20
> > > In networks that are very dynamic it might be optional to revert,=20
> > > let the traffic stay on the protecting path or replace them=20
> > > altogether.
> > >=20
> > > Wouldn't it be interesting to discuss more in detail when a=20
> > > revertive behavior is needed/wanted and when it is not.
> > >=20
> > > /Loa
> > >=20
> > > [email-masked] wrote:
> > > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > > >=20
> > > > 	Title           : GMPLS RSVP-TE recovery extension for=20
> > > data plane initiated reversion
> > > > 	Author(s)       : A. Takacs, B. Tremblay
> > > > 	Filename        : draft-takacs-ccamp-revertive-ps-00.txt
> > > > 	Pages           : 11
> > > > 	Date            : 2008-07-06
> > > >=20
> > > > RSVP-TE recovery extensions are specified in [RFC4872] and
> > > [RFC4873].
> > > > Currently these extensions cannot signal request for revertive=20
> > > > protection to the remote endpoint.  This document defines a
> > > new bit to
> > > > signal this request and a new field to specify a=20
> wait-to-restore=20
> > > > interval.Requirements Language
> > > >=20
> > > > 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
> > > >=20
> > > > A URL for this Internet-Draft is:
> > > >=20
> > >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > > > .txt
> > > >=20
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > >=20
> > > > Below is the data which will enable a MIME compliant=20
> mail reader=20
> > > > implementation to automatically retrieve the ASCII=20
> version of the=20
> > > > Internet-Draft.
> > > >=20
> > > >=20
> > > >=20
> > >=20
> >=20
> ----------------------------------------------------------------------
> > > > --
> > > >=20
> > > > _______________________________________________
> > > > I-D-Announce mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >=20
> > >=20
> > > --
> > > Loa Andersson
> > >=20
> > > Principal Networking Architect
> > > Acreo AB                           phone:  +46 8 632 77 14
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > Kista, Sweden                      email:  [email-masked]
> > >                                             [email-masked]
> > >=20
> >=20
> >=20
>=20

Delivery-date: Wed, 09 Jul 2008 14:05:39 +0000
Date: Wed, 09 Jul 2008 07:03:24 -0700
From: Greg Bernstein <[email-masked]>
To: ccamp <[email-masked]>
Subject: Times slots for WSON drafts at CCAMP...

Hi Chairs and WG participants. There are a number of drafts concerning 
Wavelength Switched Optical Networks (WSON) that will (or may) want a 
time slot for the Dublin meeting.  Here is a list of those that I know 
of and what would/could be discussed:

(a) Framework Draft -- Mostly a discussion of update plans, this hasn't 
been changed since becoming a working group document a few months back.
(b) WSON High Level Information Model -- This has been significantly 
refined since it was split off from the previous info model draft per 
the chair's suggestion.
(c) WSON Info Model Encoding -- This also has been significantly refined 
since it was split off from the previous info model draft.

(d) WSON Signaling -- This is a merging of two drafts from separate 
groups of contributors. Requirements and solutions are clearly delimited 
in this new draft. Dan King has volunteered to present.
(e) G.694 based lambda labels -- Did Tomohiro want to give us a quick 
update since this is now a WG document?

(f) I saw a new draft from Zhihong Kang and others at ZTE. This seems to 
hit a number of topics related to the on going WSON work. I didn't know 
if they wanted a slot at Dublin. This is probably closer to framework 
and modeling than to signaling issues.

All the above have been uploaded. I'll send an update with links once 
they are posted by the IETF. Also there was some discussion of a CCAMP 
sponsored sub-mailing list for WSON discussions any progress?

Thanks

Greg B.

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

Delivery-date: Wed, 09 Jul 2008 12:55:54 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 14:54:47 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Attila Takacs" <[email-masked]>, "Loa Andersson" <[email-masked]>, "ccamp" <[email-masked]>

attila,

once you are at it, can u explain the following "to properly setup the
remote data plane endpoints" ? what it actually means in the context:

"Such an example is protection switching of bidirectional
 connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under
 standardisation in IEEE).  In this case revertiveness needs to be
 signalled by RSVP-TE during LSP establishment to properly setup the
 remote data plane endpoint."

also do u need a V bit, or isn't the WTR time with a reserved value not
sufficient e.g. 0x0 ? when for inst. the locally configured timer would
be used (no timer signaled).

the revertive operation is associated to LSP right ? why did you pull
this into the 16-bit space for Link specific operation (before link
flags ?)

thx,
-d.
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Attila Takacs
> Sent: Wednesday, July 09, 2008 2:34 PM
> To: Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> Hi Loa,
>=20
> I assume a part of your comment/question relates to problems with
> reversion if LSP setup and holding priorities are mismatched. In this
> case the worker may be already deleted before the reversion would take
> place. This is certainly an interesting question...
>=20
> ...at a first thought an explicit revertive bit may be used=20
> to override
> the priorities for LSPs with revertive protection.
>=20
> Best regards,
> Attila
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Loa Andersson [mailto:[email-masked]]=20
> > Sent: Wednesday, July 09, 2008 12:01 PM
> > To: ccamp; Attila Takacs
> > Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> >=20
> > Attila,
> >=20
> > a neat draft that does what it sets out to do. For the moment=20
> > I've no actual comments on the draft itself (might have when=20
> > I'd time to think about in detail), but more meta-question.
> >=20
> > It is not a given that the revertive behavior always is=20
> > beneficial. In networks that are very dynamic it might be=20
> > optional to revert, let the traffic stay on the protecting=20
> > path or replace them altogether.
> >=20
> > Wouldn't it be interesting to discuss more in detail when a=20
> > revertive behavior is needed/wanted and when it is not.
> >=20
> > /Loa
> >=20
> > [email-masked] wrote:
> > > A New Internet-Draft is available from the on-line=20
> > Internet-Drafts directories.
> > >=20
> > > 	Title           : GMPLS RSVP-TE recovery extension for=20
> > data plane initiated reversion
> > > 	Author(s)       : A. Takacs, B. Tremblay
> > > 	Filename        : draft-takacs-ccamp-revertive-ps-00.txt
> > > 	Pages           : 11
> > > 	Date            : 2008-07-06
> > >=20
> > > RSVP-TE recovery extensions are specified in [RFC4872] and=20
> > [RFC4873].
> > > Currently these extensions cannot signal request for revertive=20
> > > protection to the remote endpoint.  This document defines a=20
> > new bit to=20
> > > signal this request and a new field to specify a wait-to-restore=20
> > > interval.Requirements Language
> > >=20
> > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",=20
> "SHALL NOT",=20
> > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20
> > "OPTIONAL" in this=20
> > > document are to be interpreted as described in
> > >=20
> > > A URL for this Internet-Draft is:
> > >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > > .txt
> > >=20
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >=20
> > > Below is the data which will enable a MIME compliant mail reader=20
> > > implementation to automatically retrieve the ASCII version of the=20
> > > Internet-Draft.
> > >=20
> > >=20
> > >=20
> >=20
> ----------------------------------------------------------------------
> > > --
> > >=20
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >=20
> >=20
> > --
> > Loa Andersson
> >=20
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  [email-masked]
> >                                             [email-masked]
> >=20
>=20
>=20

Delivery-date: Wed, 09 Jul 2008 12:36:23 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 14:34:06 +0200
From: "Attila Takacs" <[email-masked]>
To: "Loa Andersson" <[email-masked]>, "ccamp" <[email-masked]>

Hi Loa,

I assume a part of your comment/question relates to problems with
reversion if LSP setup and holding priorities are mismatched. In this
case the worker may be already deleted before the reversion would take
place. This is certainly an interesting question...

...at a first thought an explicit revertive bit may be used to override
the priorities for LSPs with revertive protection.

Best regards,
Attila

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]=20
> Sent: Wednesday, July 09, 2008 12:01 PM
> To: ccamp; Attila Takacs
> Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> Attila,
>=20
> a neat draft that does what it sets out to do. For the moment=20
> I've no actual comments on the draft itself (might have when=20
> I'd time to think about in detail), but more meta-question.
>=20
> It is not a given that the revertive behavior always is=20
> beneficial. In networks that are very dynamic it might be=20
> optional to revert, let the traffic stay on the protecting=20
> path or replace them altogether.
>=20
> Wouldn't it be interesting to discuss more in detail when a=20
> revertive behavior is needed/wanted and when it is not.
>=20
> /Loa
>=20
> [email-masked] wrote:
> > A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> >=20
> > 	Title           : GMPLS RSVP-TE recovery extension for=20
> data plane initiated reversion
> > 	Author(s)       : A. Takacs, B. Tremblay
> > 	Filename        : draft-takacs-ccamp-revertive-ps-00.txt
> > 	Pages           : 11
> > 	Date            : 2008-07-06
> >=20
> > RSVP-TE recovery extensions are specified in [RFC4872] and=20
> [RFC4873].
> > Currently these extensions cannot signal request for revertive=20
> > protection to the remote endpoint.  This document defines a=20
> new bit to=20
> > signal this request and a new field to specify a wait-to-restore=20
> > interval.Requirements Language
> >=20
> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
> > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20
> "OPTIONAL" in this=20
> > document are to be interpreted as described in
> >=20
> > A URL for this Internet-Draft is:
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > .txt
> >=20
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >=20
> > Below is the data which will enable a MIME compliant mail reader=20
> > implementation to automatically retrieve the ASCII version of the=20
> > Internet-Draft.
> >=20
> >=20
> >=20
> ----------------------------------------------------------------------
> > --
> >=20
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                             [email-masked]
>=20

Delivery-date: Wed, 09 Jul 2008 10:03:45 +0000
Date: Wed, 09 Jul 2008 12:01:22 +0200
From: Loa Andersson <[email-masked]>
To: ccamp <[email-masked]>,  "Attila Takacs (IJ/ETH)" <[email-masked]>
Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt

Attila,

a neat draft that does what it sets out to do. For the moment I've no
actual comments on the draft itself (might have when I'd time to think
about in detail), but more meta-question.

It is not a given that the revertive behavior always is beneficial. In
networks that are very dynamic it might be optional to revert, let the
traffic stay on the protecting path or replace them altogether.

Wouldn't it be interesting to discuss more in detail when a revertive
behavior is needed/wanted and when it is not.

/Loa

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : GMPLS RSVP-TE recovery extension for data plane initiated reversion
> 	Author(s)       : A. Takacs, B. Tremblay
> 	Filename        : draft-takacs-ccamp-revertive-ps-00.txt
> 	Pages           : 11
> 	Date            : 2008-07-06
> 
> RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873].
> Currently these extensions cannot signal request for revertive
> protection to the remote endpoint.  This document defines a new bit
> to signal this request and a new field to specify a wait-to-restore
> interval.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-takacs-ccamp-revertive-ps-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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Tue, 08 Jul 2008 17:32:14 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-vcat-lcas-05.txt 
Date: Tue,  8 Jul 2008 10:30: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		: Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
	Author(s)	: G. Bernstein
	Filename	: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt
	Pages		: 21
	Date		: 2008-7-8
	
This document describes requirements for, and use of, the Generalized 
   Multi-Protocol Label Switching (GMPLS) control plane in conjunction    with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing 
   mechanism and its companion Link Capacity Adjustment Scheme (LCAS) 
   which can be used for hitless dynamic resizing of the inverse 
   multiplex group.  These techniques apply to Optical Transport Network 
   (OTN), Synchronous Optical Network (SONET), Synchronous Digital 
   Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.

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

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

--NextPart--

Delivery-date: Mon, 07 Jul 2008 10:34:13 +0000
To: [email-masked]
Cc: [email-masked]
Subject: Draft about The Constraint Information Overview on WDM Switch Optical Network
From: [email-masked]
Date: Mon, 7 Jul 2008 17:25:56 +0800

--=_mixed 00341A364825747F_=
Content-Type: multipart/alternative; boundary="=_alternative 00341A364825747F_="

--=_alternative 00341A364825747F_=
Content-Type: text/plain; charset="US-ASCII"

Dear All,

With this document we would like to share with you the overview of WDM 
switch network constraints information, In addition we declared the the 
mechnism of link connectivity verification on WDM switch network.

This is a new draft, welcome everyone to discuss and contrbiute your 
special suggestion. We are appreciating any of your contribution.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--=_alternative 00341A364825747F_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Dear All,</font>
<br>
<br><font size=2 face="sans-serif">With this document we would like to
share with you the overview of WDM switch network constraints information,
In addition we declared the the mechnism of link connectivity verification
on WDM switch network.</font>
<br>
<br><font size=2 face="sans-serif">This is a new draft, welcome everyone
to discuss and contrbiute your special suggestion. We are appreciating
any of your contribution.</font>
<br>
<br><br><pre>
--------------------------------------------------------
ZTE&nbsp;Information&nbsp;Security&nbsp;Notice:&nbsp;The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;mail&nbsp;is&nbsp;solely&nbsp;property&nbsp;of&nbsp;the&nbsp;sender's&nbsp;organization.&nbsp;This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidential.&nbsp;Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to&nbsp;maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to&nbsp;disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication&nbsp;to&nbsp;others.
This&nbsp;email&nbsp;and&nbsp;any&nbsp;files&nbsp;transmitted&nbsp;with&nbsp;it&nbsp;are&nbsp;confidential&nbsp;and&nbsp;intended&nbsp;solely&nbsp;for&nbsp;the&nbsp;use&nbsp;of&nbsp;the&nbsp;individual&nbsp;or&nbsp;entity&nbsp;to&nbsp;whom&nbsp;they&nbsp;are&nbsp;addressed.&nbsp;If&nbsp;you&nbsp;have&nbsp;received&nbsp;this&nbsp;email&nbsp;in&nbsp;error&nbsp;please&nbsp;notify&nbsp;the&nbsp;originator&nbsp;of&nbsp;the&nbsp;message.&nbsp;Any&nbsp;views&nbsp;expressed&nbsp;in&nbsp;this&nbsp;message&nbsp;are&nbsp;those&nbsp;of&nbsp;the&nbsp;individual&nbsp;sender.
This&nbsp;message&nbsp;has&nbsp;been&nbsp;scanned&nbsp;for&nbsp;viruses&nbsp;and&nbsp;Spam&nbsp;by&nbsp;ZTE&nbsp;Anti-Spam&nbsp;system.
</pre>
--=_alternative 00341A364825747F_=--

--=_mixed 00341A364825747F_=
Content-Type: text/plain; name="draft-kang-ccamp-wdm-switch-info-00.txt"
Content-Disposition: attachment; filename="draft-kang-ccamp-wdm-switch-info-00.txt"
Content-Transfer-Encoding: quoted-printable

Network Working Group                                     Zhihong Kang =0A =
                                                          Zhenyu Wang =0A  =
                                                            Feng Gao =0AInt=
ernet Draft                                                     ZTE =0AInte=
nded status:                                          July 7, 2008 =0AExpir=
es: Jan 2009 =0A =0A                                      =0A      Link Con=
nectivity and Common Constraint Information Extension to =0A               =
   GMPLS for WDM Switched Optical Networks =0A                  draft-kang-=
ccamp-WDM-switch-info-00.txt =0A=0A=0AStatus of this Memo =0A=0A   By submi=
tting this Internet-Draft, each author represents that       =0A   any appl=
icable patent or other IPR claims of which he or she is       =0A   aware h=
ave been or will be disclosed, and any of which he or she       =0A   becom=
es aware will be disclosed, in accordance with Section 6 of       =0A   BCP=
 79. =0A=0A   Internet-Drafts are working documents of the Internet Enginee=
ring =0A   Task Force (IETF), its areas, and its working groups.  Note that=
 =0A   other groups may also distribute working documents as Internet-Draft=
s. =0A=0A   Internet-Drafts are draft documents valid for a maximum of six =
months =0A   and may be updated, replaced, or obsoleted by other documents =
at any =0A   time.  It is inappropriate to use Internet-Drafts as reference=
 =0A   material or to cite them other than as "work in progress." =0A=0A   =
The list of current Internet-Drafts can be accessed at =0A   http://www.iet=
f.org/ietf/1id-abstracts.txt =0A=0A   The list of Internet-Draft Shadow Dir=
ectories can be accessed at =0A   http://www.ietf.org/shadow.html =0A=0A   =
This Internet-Draft will expire on Fail 7, 0000. =0A=0ACopyright Notice =0A=
=0A   Copyright (C) The IETF Trust (0000). =0A=0AAbstract =0A=0A   This doc=
ument provides the mechanism of link connectivity =0A   verification and th=
e constraint information extension to route for =0A   static light path com=
putation and selection in WDM network. =0A=0A =0A =0A =0AZhihong           =
     Expires January 7, 2009                [Page 1] =0A=0C=0AInternet-Draf=
t   Constraints Overview For WDM Switched Optical Network   Jul 2008 =0A   =
 =0A=0AConventions used in this document =0A=0A   The key words "MUST", "MU=
ST NOT", "REQUIRED", "SHALL", "SHALL NOT", =0A   "SHOULD", "SHOULD NOT", "R=
ECOMMENDED", "MAY", and "OPTIONAL" in this =0A   document are to be interpr=
eted as described in RFC-2119 =0A        . =0A=0ATable of Contents =0A=0A  =
  =0A   1. Introduction................................................2 =
=0A   2. Terminology.................................................4 =0A =
  3. Link Verification...........................................4 =0A   4.=
 Constraint Information......................................5 =0A      4.1=
. WDM Link...............................................5 =0A      4.2. WD=
M Link Constraint....................................5 =0A      4.3. OCH Co=
nstraint.........................................6 =0A      4.4. Tunable La=
ser..........................................6 =0A   5. Information Model..=
........................................6 =0A      5.1. Link Information..=
....................................6 =0A      5.2. Lambda Group ID.......=
................................7 =0A      5.3. Wavelength Label..........=
............................9 =0A   6. Application to OSPF GMPLS extension=
s........................9 =0A      6.1. Link Sub-TLVs.....................=
....................9 =0A         6.1.1. Maximum of optical channels sub-T=
LV...............9 =0A         6.1.2. Link Constraint sub-TLV..............=
............9 =0A         6.1.3. Wavelength Availability,Switch Capability=
 Sub-TLV15 =0A         6.1.4. Reachable OTU Sub-TLV........................=
...16 =0A   7. Security Considerations....................................=
17 =0A   8. IANA Considerations........................................18 =
=0A   9. Acknowledgments............................................18     =
          =0A   10. Acknowledgments........................................=
..18 =0A   11. References................................................1=
8 =0A      11.1. Normative References.................................18 =
=0A      11.2. Informative References...............................18 =0A =
  Author's Addresses............................................19 =0A   In=
tellectual Property Statement...............................19 =0A   Discla=
imer of Validity........................................20 =0A    =0A1. Int=
roduction =0A=0A   This document provides foundational information model Ap=
pling ASON to =0A   WDM network, we called the series of function aggregati=
on for ASON =0A   applied to WDM "WASON" (WDM Automatic Switch Optical Netw=
ork). This =0A   likewise includes automatic discovery, route, and signalin=
g. But the =0A   current standard RFC cannot completely support WASON imple=
mentation, =0A   it is well-know that RWA is the key problem in WASON. Ther=
e are =0A =0A =0AKang                     Expires Jan, 2009                =
   [Page 2] =0A=0C=0AInternet-Draft   Constraints Overview For WDM Switched=
 Optical Network   Jul 2008 =0A    =0A=0A   certain constraints in the ligh=
t path computation and selection =0A   process, this is the root of RWA pro=
blem. This document provides the =0A   constraint character abstracting to =
information model for combined =0A   RWA. =0A=0A   At the same time, the me=
chanism of automatic discovery for WASON have =0A   not definitely been def=
ined, In SDH, J0 trace correlation or test =0A   message sent in band over =
DCC provide the mechanism of link =0A   connectivity verification. In WDM n=
etwork, we recommend that OSC =0A   channel (which is defined in G.709) cou=
ld be the mechanism of link =0A   connectivity verification between adjacen=
t nodes. =0A=0A   In DWDM network, there are certain specific constraints w=
hich are =0A   different from other circuit switched network such as Time D=
ivision =0A   Multiplexing (TDM). The most obvious constraint is that the =
=0A   wavelength must be consistent in the light path, which is called =0A =
  "wavelength continuity" constraint. Even though there are certain =0A   "=
wavelength switch" capabilities by O-E-O way, but which cannot =0A   suppor=
t full switch because of the electronic matrix capability =0A   limitation.=
 At the same time between two TE links in one node may not =0A   be connect=
ed to carry traffic, which depend on the inner light path =0A   between the=
se two links is whether connected through the fiber., =0A   especially for =
multi directional ROADM equipments, and the client =0A   traffic also need =
to know the inner optical path to the TE link. All =0A   of these constrain=
ts need to face and figure out. This document start =0A   form the combined=
 RWA way to describe information model extend to =0A   route application, t=
his is considered that the restoration time in =0A   optical network have r=
elatively strict restriction, hopefully static =0A   path computation and s=
election could be satisfied to end-to-to =0A   restoration time. The link a=
nd wavelength channel constraints need to =0A   be described as the explica=
ble information flooded in the network. =0A   The link constraints informat=
ion mainly consists of two parts, one is =0A   the connectivity with other =
links, the other is the arrival =0A   information to the tributary side (Ad=
d and Drop port in ROADM, called =0A   OTU). =0A=0A   This document prefer =
to the combined RWA way and provide enough =0A   resource information for s=
tatic path computation and selection, and =0A   this is also consistent wit=
h the distributed signaling way to setup =0A   end-to-end connection via mu=
ltiple light paths attempt. So this =0A   document is the supplementary for=
 the automatic discovery mechanism =0A   in WASON, and mainly focus on all =
of the constraint information =0A   description and efficient encodings of =
information used for route =0A   flood. =0A=0A=0A=0A =0A =0AKang           =
          Expires Jan, 2009                   [Page 3] =0A=0C=0AInternet-Dr=
aft   Constraints Overview For WDM Switched Optical Network   Jul 2008 =0A =
   =0A=0A2. Terminology =0A=0A   ASON: Automatic Switch Optical Network =0A=
=0A   DWDM: Dense Wavelength Division Multiplexing =0A=0A   WASON: WDM Auto=
matic Switch Optical Network =0A=0A   RWA: Route and Wavelength Assignment =
=0A=0A   DCC: Data Communication Channel =0A=0A   OSC: Optical Supervisory =
Channel =0A=0A   ROADM: Reconfigurable Optical Add/Drop Multiplexer =0A=0A =
  O-E-O: Optical-Electronic-Optical =0A=0A   SDH: Synchronous digital hiera=
rchy =0A=0A   SONET: Synchronous Optical Network =0A=0A   OTU: Optical Tran=
sponder Unit =0A=0A3. Link Verification =0A=0A   Link verification is used =
to verify the physical connectivity of the =0A   data links and to exchange=
 the Interface Ids of the data links. The =0A   data links between adjacent=
 nodes in WDM network also need the =0A   transport medium to verify the co=
nnectivity and exchange the =0A   interface Ids of data plane. Then synchro=
nize the data links to form =0A   TE link used for path computation and sig=
naling. RFC4207 have =0A   significantly defined the mechanisms of link con=
nectivity applicable =0A   to SDH/SONET. But for WDM system, there is no si=
gnificant definition =0A   for the link connectivity verification mechanism=
. OSC channel is as =0A   the natural and specific transport channel embedd=
ed in the DWM link. =0A   So this document defines the new link verificatio=
n mechanism used for =0A   WDM link. The following is the two mechanism def=
inition. =0A=0A   One is that Test message is sent over OSC channel and Tes=
tStatus =0A   messages sent back over the control channel. The Test Message=
 is =0A   defined in [RFC4204]. =0A=0A   The other is that the OSC channel =
is used to send and receive Trace =0A   Message. The Test Message is not tr=
ansmitted over OSC channel (i.e., =0A   over the data link), but is sent ov=
er the control channel and =0A=0A =0A =0AKang                     Expires J=
an, 2009                   [Page 4] =0A=0C=0AInternet-Draft   Constraints O=
verview For WDM Switched Optical Network   Jul 2008 =0A    =0A=0A   correla=
ted for consistency to the received Trace Message from OSC =0A   channel. =
=0A=0A   The content of Trace Message is unique in the network. It could be=
 =0A   the combination of local interface Id and Node Id. =0A=0A   The proc=
ess of link connectivity verification between adjacent WDM =0A   nodes is c=
onsistent with SDH/SONET, this can be referred to [RFC4204] =0A   and [RFC4=
207]. =0A=0A4. Constraint Information =0A=0A   WDM Link Bandwidth =0A=0A   =
Link Constraint Character =0A=0A   Wavelength Continuity Constraint =0A=0A =
  O-E-O Wavelength Switch Capability =0A=0A   Tunable Laser =0A=0A4.1. WDM =
Link =0A=0A   The bandwidth of WDM link should be concerned as the number o=
f =0A   wavelength, could not be counted as signal rates because the =0A   =
wavelength cannot be restricted to carry certain rates of signal, or =0A   =
certain frame type of signal. =0A=0A   Consider to interlayer, Wavelength c=
hannel layer is used to be server =0A   layer path to carry client traffic,=
 such as GE multiplexing. =0A=0A4.2. WDM Link Constraint =0A=0A   There are=
 certain constraints to set up end-to-end connection even =0A   though ther=
e are available bandwidths in one light path. The =0A   tributary side (We =
called OTU) of Ingress and Egress node need to =0A   know the arrival capab=
ility to the TE link. It is not that the =0A   tributary side can arrive up=
 to all of TE links, and down from all of =0A   TE links. The TE links on t=
he two sides of Transmit node may not =0A   completely have the capability =
to connect to transmit traffic. These =0A   constraints exist in DWM node a=
s the optical signal flow must be =0A   connected from the inner of node. T=
his is very different from circuit =0A   switch network which make use of i=
ntegrated circuit design to get =0A   electronic signals to mutual connecti=
on. If TE links on the two sides =0A   of Transmit node don't get optical i=
nner connection, the traffic =0A   carried on one wavelength can not pass t=
hrough the node from one side =0A =0A =0AKang                     Expires J=
an, 2009                   [Page 5] =0A=0C=0AInternet-Draft   Constraints O=
verview For WDM Switched Optical Network   Jul 2008 =0A    =0A=0A   to the =
other side. The constraint on the WDM link challenge the =0A   traditional =
route computation algorithm based on the available =0A   bandwidth of TE li=
nk. =0A=0A4.3. OCH Constraint =0A=0A   It is well-known that the wavelength=
 basically need to keep =0A   consistent in the light path, this is called =
"Wavelength continuity" =0A   constraint. Even though O-E-O can add certain=
 "wavelength switch" =0A   capability to the system, but the electronic mat=
rix in the DWM =0A   equipment do not completely have the full switch capab=
ility. =0A=0A   So wavelength availability and switch capability informatio=
n is =0A   important to analyze the availability of light path from end to =
end. =0A=0A4.4. Tunable Laser =0A=0A   The tributary transmitter laser is t=
unable, this add certain =0A   flexibility to path computation and selectio=
n process. Ingress and =0A   egress node can add and drop traffic in the ex=
tent of tunable =0A   wavelength from the reachable TE links. The transmitt=
er tuning =0A   information is one factor to take into account during the l=
ight path =0A   computation and selection, and connection set up. =0A=0A5. =
Information Model =0A=0A5.1. Link Information =0A=0A   WDM link information=
 derived from RFC3630 and RFC4203, and add new =0A   sub-elements constrain=
ts to link information model: =0A=0A   (a) Maximum of optical channels (wav=
elength), which is the bandwidth =0A   of WDM link. =0A=0A   (b) Link direc=
tion, this is used to account for the bit map position =0A   in the link co=
nstraint information, this is one global unique Id =0A   assigned in the no=
de. =0A=0A   (c) Link constraint information, which represent the connectiv=
ity =0A   with other links, and was indicated by the bit map, the bit posit=
ion =0A   represents the connectivity with one direction link. =0A=0A   (d)=
 Wavelength availability, which represent the state of the =0A   correspond=
ing optical wavelength channel. =0A=0A   (e) Wavelength switch capability, =
one set of wavelength aggregation =0A   could be switched via electronic ma=
trix. The optical signals carried =0A =0A =0AKang                     Expir=
es Jan, 2009                   [Page 6] =0A=0C=0AInternet-Draft   Constrain=
ts Overview For WDM Switched Optical Network   Jul 2008 =0A    =0A=0A   in =
the wavelength can flow to or flow out from the same electronic =0A   matri=
x unit after optical-electronic-optical change, all of these =0A   waveleng=
ths could switch. One global unique ID named "Lambda Group =0A   Id" repres=
ents one electronic matrix unit. The Lambda Group Id is the =0A   identific=
ation of the aggregation of wavelengths in which the optical =0A   signals =
flow to or flow out from the same matrix unit. =0A=0A   Lambda Group Id rep=
resent the aggregation of wavelength set, the =0A   wavelengths with same L=
ambda Group Id can be mutually switched via O-=0A   E-O. The special value =
0 represent the optical signal carried in the =0A   wavelength only can pas=
s via the same wavelength. =0A=0A   Wavelength switch capability can be ide=
ntified by Lambda Group Id, =0A   which was carried with Wavelength availab=
ility information. =0A=0A   (f) Reachable tributary (OTU) information, whic=
h describe the =0A   aggregation of Reachable OTU, and for every Reachable =
OTU, which also =0A   indicate out the available wavelength set. The inform=
ation also can =0A   be got via the communication between ingress and egres=
s nodes before =0A   initiate call connection setup. =0A=0A   Note: only (a=
) are necessary for WDM link, others are used for static =0A   path computa=
tion and assemble signaling. =0A=0A5.2. Lambda Group ID =0A=0A   +------+  =
                                                +------+             =0A=0A=
   |      | =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=A6=CB1            =A6=CB5+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D |      | =0A=0A   + DWDM + =3D+=3D+=3D+=3D+=3D+=3D+=
=A6=CB2|    +------+      |=A6=CB6+=3D+=3D+=3D+=3D+=3D + DWDM + =0A=0A   | =
 1   | =3D+=3D+=3D+=3D+=A6=CB3|   +=3D+=3D |      | =3D+=3D+=3D+   |=A6=CB7=
+=3D+=3D+=3D |   2  | =0A=0A   +------+        |   +=3D+=3D+=3D+=3D +MATRIX=
| =3D+=3D+=3D+=3D+=3D+   |      +------+ =0A=0A                   +=3D+=3D+=
=3D+=3D+=3D+=3D |   1  | =3D+=3D+=3D+=3D+=3D+=3D+=3D+ =0A=0A               =
                 +------+ =0A=0A    =0A=0A    =0A=0A    =0A=0A    =0A =0A =
=0AKang                     Expires Jan, 2009                   [Page 7] =
=0A=0C=0AInternet-Draft   Constraints Overview For WDM Switched Optical Net=
work   Jul 2008 =0A    =0A=0A    =0A=0A   +------+                         =
                         +------+             =0A=0A   |      | =3D+=3D+=3D=
+=3D+=3D+=3D+=3D+=3D+=A6=CB1            =A6=CB3+=3D+=3D+=3D+=3D+=3D+=3D+=3D=
 |      | =0A=0A   + DWDM + =3D+=3D+=3D+=3D+=3D+=3D+=A6=CB3|    +------+   =
   |=A6=CB5+=3D+=3D+=3D+=3D+=3D + DWDM + =0A=0A   |  3   | =3D+=3D+=3D+=3D+=
=A6=CB4|   +=3D+=3D |      | =3D+=3D+=3D+   |=A6=CB7+=3D+=3D+=3D |   4  | =
=0A=0A   +------+        |   +=3D+=3D+=3D+=3D +MATRIX| =3D+=3D+=3D+=3D+=3D+=
   |      +------+ =0A=0A                   +=3D+=3D+=3D+=3D+=3D+=3D |   2 =
 | =3D+=3D+=3D+=3D+=3D+=3D+=3D+ =0A=0A                                +----=
--+ =0A=0A                        Figure 1 O-E-O Switch Model =0A=0A   The =
Lambda Group ID is identification of the aggregation of =0A   Wavelength se=
t in which the wavelengths could be mutually switched, =0A   and is also th=
e identification of O-E-O switch capability. Here don't =0A   consider the =
asymmetric switch matrix. =0A=0A   The figure showed above, the link from D=
WDM1 have three lambdas (=A6=CB1, =0A    =A6=CB2, =A6=CB3) flow to the matr=
ix unit1, the link from DWDM1 have three =0A   lambdas (=A6=CB5, =A6=CB6, =
=A6=CB7) flow to the matrix unit1, they could be switched. =0A   Likewise t=
he link from DWDM3 have three lambdas (=A6=CB1, =A6=CB3, =A6=CB4) flow to =
=0A   the matrix unit2, the link from DWDM4 have three lambdas (=A6=CB3, =
=A6=CB5, =A6=CB7) =0A   flow to the matrix unit2, they could be switched. =
=0A=0A   For the lambdas (=A6=CB1, =A6=CB2, =A6=CB3) of the link of DWDM1 a=
nd the lambdas (=A6=CB5, =0A    =A6=CB6, =A6=CB7) of the link of DWDM2, the=
 Lambda Group ID could assign to be =0A   1; =0A=0A   For the lambdas (=A6=
=CB1, =A6=CB3, =A6=CB4) of the link of DWDM3 and the lambdas (=A6=CB3, =0A =
   =A6=CB5, =A6=CB7) of the link of DWDM4, the Lambda Group ID could assign=
 to be =0A   2; =0A=0A   So the lambda group id is the identification of wa=
velength switch =0A   capability, and also is the identification of the agg=
regation of =0A   Wavelength set in which the wavelengths could be mutually=
 switched, =0A   and their lambda group ids are same. =0A=0A   The special =
value 0 lambda group id represent the optical signal =0A   carried in the w=
avelength only can pass via the same wavelength. Do =0A   not have the capa=
bility of O-E-O. =0A=0A =0A =0AKang                     Expires Jan, 2009  =
                 [Page 8] =0A=0C=0AInternet-Draft   Constraints Overview Fo=
r WDM Switched Optical Network   Jul 2008 =0A    =0A=0A5.3. Wavelength Labe=
l =0A=0A   This document makes frequent use of the lambda label format defi=
ned =0A   in [Otani] shown below: =0A=0A    0                   1          =
         2                   3  =0A=0A    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  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   |Grid | C.S   |S|    Reserved   |=
              n                |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   Grid is used to indicate which I=
TU-T grid specification is being used. =0A=0A   C.S. =3D Channel spacing us=
ed in a DWDM system, i.e., with a ITU-T =0A   G.694.1 grid. =0A=0A   S =3D =
Sign for the value of n, set to 1 for (-) and 0 for (+). =0A=0A   n =3D Use=
d to specify the frequency as 193.1THz +/- n*(channel spacing) =0A   where =
the + or - is chosen based on the sign (S) bit. =0A=0A6. Application to OSP=
F GMPLS extensions =0A=0A6.1. Link Sub-TLVs =0A=0A   As discussed in sectio=
n 5.1, some sub-TLVs need to characterize for =0A   WDM links. =0A=0A6.1.1.=
 Maximum of optical channels sub-TLV =0A=0A   Maximum of optical channels s=
ub-TLV specifies the maximum optical =0A   wavelength channels that can be =
used on this WDM link. The value can =0A   be 40, 80, 160, 192 etc. =0A=0A6=
.1.2. Link Constraint sub-TLV =0A=0A   There are two ways to show the link =
connectivity constraint with =0A   other links. One is the links including =
list, the second is the bit =0A   map to indicate the connectivity with oth=
er links. The second need to =0A   assign the unique direction Id for each =
link. The information carried =0A   in the link constraint is: =0A=0A      =
   0                   1                   2                   3  =0A =0A =
=0AKang                     Expires Jan, 2009                   [Page 9] =
=0A=0C=0AInternet-Draft   Constraints Overview For WDM Switched Optical Net=
work   Jul 2008 =0A    =0A=0A          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  =0A=0A         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A         |Dir|   Method  |   Dire=
ction   |   Num Links   |    Reserved   |  =0A=0A         +-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A         |         =
    Bit Map Word #1 Or Link Identifier 1              |  =0A=0A         +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A     =
    :                               :                               :  =0A=
=0A         :                               :                              =
 :  =0A=0A         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+  =0A=0A         |            Bit Map Word #N Or Link Identifier N=
               |  =0A=0A         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   Dir: 2 bits =0A=0A   0 - bidirectional, In=
dicate the connectivity from the link to other =0A   links bidirectional. =
=0A=0A   1 - Ingress, Indicate the connectivity to other links from the =0A=
   ingress port of the link to the egress ports of other links. =0A=0A   2 =
- Egress, Indicate the connectivity from the ingress ports of other =0A   l=
inks to the egress port of the link. =0A=0A   Method: 6 bits =0A=0A   0 - B=
it Map =0A=0A   1 - Link Set =0A=0A   Others - Reserved to be used later. =
=0A=0A   Direction: 8 bits =0A=0A   Direction is one unique Id assigned in =
the node, start from 1. This =0A   is different from link index, and is use=
d to account for bit position =0A   in the bit map carried in other links c=
onstraint sub-TLV. =0A=0A =0A =0AKang                     Expires Jan, 2009=
                  [Page 10] =0A=0C=0AInternet-Draft   Constraints Overview =
For WDM Switched Optical Network   Jul 2008 =0A    =0A=0A   Num Links: 8 bi=
ts =0A=0A   Num links tell us the number of link identifiers followed or th=
e =0A   number bits of link connectivity represented by the bit map. =0A=0A=
   Bit map have the same rule in the link constraint information in =0A   o=
rder that RWA algorithm can analyze the connectivity of links. Each =0A   b=
it in the bit map represents one specific link with value 1/0 =0A   indicat=
ing the constraint connectivity with the link. The bit =0A   position repre=
sent the specific link witch is its own, the value on =0A   this bit is 1. =
=0A=0A    A B C D E F G H I K J L M N O P Q R S       =0A=0A   +-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   | | | | | | | | | | | | | | | | |=
 | | | :::  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   =
 =0A=0A   The rule for bit map showed below, the link direction is used her=
e to =0A   indicate the bit position. =0A=0A    =0A=0A   Position Link Dire=
ction     Meaning =0A=0A   ------------------------------------------------=
--------------------- =0A=0A    A       1    indicate the connectivity betw=
een the link and specific link of direction Id 1 =0A=0A    B       2    ind=
icate the connectivity between the link and specific link of direction Id 2=
 =0A=0A    C       3    indicate the connectivity between the link and spec=
ific link of direction Id 3 =0A=0A    D       4    indicate the connectivit=
y between the link and specific link of direction Id 4 =0A=0A    E       5 =
  indicate the connectivity between the link and specific link of direction=
 Id 5 =0A=0A    F       6    indicate the connectivity between the link and=
 specific link of direction Id 6 =0A=0A    G       7    indicate the connec=
tivity between the link and specific link of direction Id 7 =0A=0A    H    =
   8    indicate the connectivity between the link and specific link of dir=
ection Id 8 =0A =0A =0AKang                     Expires Jan, 2009          =
        [Page 11] =0A=0C=0AInternet-Draft   Constraints Overview For WDM Sw=
itched Optical Network   Jul 2008 =0A    =0A=0A    I        9   indicate th=
e connectivity between the link and specific link of direction Id 9 =0A=0A =
   :               :                                    : =0A=0A    :      =
         :                                    : =0A=0A    :               :=
                                    : =0A=0A    :               :          =
                          : =0A=0A   --------------------------------------=
------------------------------- =0A=0A   For example: =0A=0A               =
                 V^ 2 =0A=0A                                || =0A=0A      =
                          || =0A=0A                                || =0A=
=0A                                || =0A=0A           1               +-+-=
+-+-+-+-+-+                 3 =0A=0A           <---------------|           =
  | ----------------< =0A=0A           >---------------+   ROADM     + ----=
------------> =0A=0A                          |             | =0A=0A       =
                   +-+-+-+-+-+-+-+ =0A=0A                                ||=
 =0A=0A                                || =0A=0A                           =
     || =0A=0A                                || =0A=0A                    =
            ^V 4 =0A=0A                        Figure 2 Example For WDM Lin=
ks =0A=0A=0A =0A =0AKang                     Expires Jan, 2009             =
     [Page 12] =0A=0C=0AInternet-Draft   Constraints Overview For WDM Switc=
hed Optical Network   Jul 2008 =0A    =0A=0A   There are four WDM links in =
the ROADM node, and the link direction =0A   Ids are respectively 1, 2, 3, =
4. Here ignore the detail of =0A   connectivity between the links. Assume t=
hat Link 1 bidirectional =0A   connect to Link 2, and Link 3 bidirectional =
connect to Link 4. =0A=0A   The constraint information in each link represe=
nt as follows: =0A=0A   Link of direction 1: =0A=0A    0                   =
1                   2                   3  =0A=0A    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 =0A=0A    +-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   | 0 |     1     |     =
  1       |       1       |    Reserved   |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   |                Lin=
k identifier of direction 2                 |  =0A=0A   +-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   Or: =0A=0A    0   =
                1                   2                   3  =0A=0A    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 =0A=0A    +-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   | 0 | =
    0     |       1       |       4       |    Reserved   |  =0A=0A   +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   |1|1=
|0|0|                                                       | =0A=0A   +-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   Link=
 of direction 2: =0A=0A    0                   1                   2       =
            3  =0A=0A    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 =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+  =0A=0A =0A =0AKang                     Expires Jan, 2009    =
              [Page 13] =0A=0C=0AInternet-Draft   Constraints Overview For =
WDM Switched Optical Network   Jul 2008 =0A    =0A=0A   | 0 |     1     |  =
     2       |       1       |    Reserved   |  =0A=0A   +-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   |                =
Link identifier of direction 1                 |  =0A=0A   +-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   Or: =0A=0A    0 =
                  1                   2                   3  =0A=0A    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 =0A=0A   +-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   | 0 |=
     0     |       2       |       4       |    Reserved   |  =0A=0A   +-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   |1|=
1|0|0|                                                       | =0A=0A   +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   Lin=
k of direction 3: =0A=0A    0                   1                   2      =
             3  =0A=0A    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 =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+  =0A=0A   | 0 |     1     |       3       |       1       | =
   Reserved   |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+  =0A=0A   |                Link identifier of direction 4 =
                |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+ =0A=0A   Or: =0A=0A    0                   1            =
       2                   3  =0A=0A    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 =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A =0A =0AKang                     Expires J=
an, 2009                  [Page 14] =0A=0C=0AInternet-Draft   Constraints O=
verview For WDM Switched Optical Network   Jul 2008 =0A    =0A=0A   | 0 |  =
   0     |       3       |       4       |    Reserved   |  =0A=0A   +-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   |0|0|=
1|1|                                                       | =0A=0A   +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   Link =
of direction 4: =0A=0A    0                   1                   2        =
           3  =0A=0A    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 =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+  =0A=0A   | 0 |     1     |       4       |       1       |   =
 Reserved   |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+  =0A=0A   |                Link identifier of direction 3   =
              |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+ =0A=0A   Or: =0A=0A    0                   1              =
     2                   3  =0A=0A    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 =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   | 0 |     0     |       4       |     =
  4       |    Reserved   |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   |0|0|1|1|                           =
                            | =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A6.1.3. Wavelength Availability,Switch C=
apability Sub-TLV =0A=0A   The information of optical wavelength channel in=
cludes the resource =0A   state, and description of switch capability via O=
-E-O. =0A=0A   Wavelength Availability, Switch Capability Set Sub-TLV forma=
t is =0A   given by: =0A =0A =0AKang                     Expires Jan, 2009 =
                 [Page 15] =0A=0C=0AInternet-Draft   Constraints Overview F=
or WDM Switched Optical Network   Jul 2008 =0A    =0A=0A    0              =
     1                   2                   3  =0A=0A    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 =0A=0A   +-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   |Grid | C.S   |S| =
   Reserved   |        Num Wavelengths        | =0A=0A   +-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   | N1 For Start Cen=
ter Frequency |Lambda Group Id|   State       | =0A=0A   +-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |    N2           =
              |Lambda Group Id|   State       |  =0A=0A   +-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |                =
..                                            |  =0A=0A   +-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =0A=0A   |Nn (Highest fr=
equency channels)|Lambda Group Id|   State       | =0A=0A   +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   Num Wavelengths=
 specifies the number of wavelengths followed in the =0A   sub-TLV. This is=
 generally equal to Maximum of optical channels. =0A=0A   Lambda group Id i=
ndicates the wavelength switch capability. =0A=0A   State indicates the res=
ource state of wavelength channel. 0 is free, =0A   1 is occupied. =0A=0A6.=
1.4. Reachable OTU Sub-TLV =0A=0A   The reachable OTU sub-TLV format is giv=
en by: =0A=0A   0                   1                   2                  =
 3  =0A=0A   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 =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+  =0A=0A   |                        Num Reachable OTUs                    =
 | =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+ =0A =0A =0AKang                     Expires Jan, 2009                  [=
Page 16] =0A=0C=0AInternet-Draft   Constraints Overview For WDM Switched Op=
tical Network   Jul 2008 =0A    =0A=0A   |                         OTU Iden=
tifier1                       | =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |             Num Suggested Lambda=
 For OTU Identifier1          |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |    Suggested Lambda #1        |=
     Suggested Lambda #2       | =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |            ...                |=
     Suggested Lambda #N       | =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |                ...             =
                               |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |                         OTU Id=
entifierN                       | =0A=0A    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |             Num Suggested Lam=
bda For OTU IdentifierN          |  =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |    Suggested Lambda #1      =
  |     Suggested Lambda #2       | =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   |            ...              =
  |     Suggested Lambda #N       | =0A=0A   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A   This sub-TLV gives out the rea=
chable OTU information and the =0A   suggested available lambdas could be d=
ropped traffic signal from the =0A   link to OTU, and can add client traffi=
c signal from OTU to the link. =0A=0A7. Security Considerations =0A=0A   Th=
is document has no requirement for a change to the security models =0A   wi=
thin GMPLS and associated protocols. =0A=0A=0A=0A =0A =0AKang              =
       Expires Jan, 2009                  [Page 17] =0A=0C=0AInternet-Draft=
   Constraints Overview For WDM Switched Optical Network   Jul 2008 =0A    =
=0A=0A8. IANA Considerations =0A=0A   No new values are specified in this d=
ocument. =0A=0A9. Acknowledgments =0A=0A   This document was prepared using=
 2-Word-v2.0.template.dot. =0A=0A10. References =0A=0A10.1. Normative Refer=
ences =0A=0A   [RFC3471] Berger, L., "Generalized Multi-Protocol Label Swit=
ching =0A             (GMPLS) Signaling Functional Description", RFC 3471, =
=0A             January 2003.  =0A=0A   [G.694.1] ITU-T Recommendation G.69=
4.1, "Spectral grids for WDM =0A             applications: DWDM frequency g=
rid", June, 2002.  =0A=0A   [RFC3630] Katz, D., Kompella, K., and D. Yeung,=
 "Traffic Engineering =0A             (TE) Extensions to OSPF Version 2", R=
FC 3630, September =0A             2003.  =0A=0A   [RFC4202] Kompella, K., =
Ed., and Y. Rekhter, Ed., "Routing Extensions =0A             in Support of=
 Generalized Multi-Protocol Label Switching =0A             (GMPLS)", RFC 4=
202, October 2005  =0A=0A   [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed=
., "OSPF Extensions in =0A             Support of Generalized Multi-Protoco=
l Label Switching =0A             (GMPLS)", RFC 4203, October 2005. =0A=0A1=
0.2. Informative References =0A=0A   [Otani]   T. Otani, H. Guo, K. Miyazak=
i, D. Caviglia, "Generalized =0A             Labels of Lambda-Switching Cap=
able Label Switching Routers =0A             (LSR)", work in progress: draf=
t-otani-ccamp-gmpls-lambda-=0A             labels-01.txt, November 2007. =
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A =0A =0AKang                     Expires Jan,=
 2009                  [Page 18] =0A=0C=0AInternet-Draft   Constraints Over=
view For WDM Switched Optical Network   Jul 2008 =0A    =0A=0AAuthor's Addr=
esses =0A=0A   Zhihong Kang =0A   ZTE Technologies Co., Ltd. =0A   12F, ZTE=
 Plaza, No.19 East HuaYuan Road, HaiDian District =0A      =0A   Phone: +86=
-10-82963984 =0A   Email: [email-masked] =0A    =0A   Zhenyu Wang =
=0A   ZTE Technologies Co., Ltd. =0A   12F, ZTE Plaza, No.19 East HuaYuan R=
oad, HaiDian District =0A      =0A   Phone: +86-10-82963987 =0A   Email: wa=
[email-masked] =0A    =0A   Feng Gao =0A   ZTE Technologies Co., Ltd=
. =0A   12F, ZTE Plaza, No.19 East HuaYuan Road, HaiDian District =0A      =
=0A   Phone: +86-10-82963984 =0A   Email: [email-masked] =0A=0AIntell=
ectual Property Statement =0A=0A   The IETF takes no position regarding the=
 validity or scope of any =0A   Intellectual Property Rights or other right=
s that might be claimed to =0A   pertain to the implementation or use of th=
e technology described in =0A   this document or the extent to which any li=
cense under such rights =0A   might or might not be available; nor does it =
represent that it has =0A   made any independent effort to identify any suc=
h rights.  Information =0A   on the procedures with respect to rights in RF=
C documents can be =0A   found in BCP 78 and BCP 79. =0A=0A   Copies of IPR=
 disclosures made to the IETF Secretariat and any =0A   assurances of licen=
ses to be made available, or the result of an =0A   attempt made to obtain =
a general license or permission for the use of =0A   such proprietary right=
s by implementers or users of this =0A   specification can be obtained from=
 the IETF on-line IPR repository at =0A   http://www.ietf.org/ipr. =0A=0A  =
 The IETF invites any interested party to bring to its attention any =0A   =
copyrights, patents or patent applications, or other proprietary =0A   righ=
ts that may cover technology that may be required to implement =0A   this s=
tandard.  Please address the information to the IETF at =0A   ietf-ipr@ietf=
.org. =0A=0A =0A =0AKang                     Expires Jan, 2009             =
     [Page 19] =0A=0C=0AInternet-Draft   Constraints Overview For WDM Switc=
hed Optical Network   Jul 2008 =0A    =0A=0ADisclaimer of Validity =0A=0A  =
 This document and the information contained herein are provided on an =0A =
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS =0A=
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND =
=0A   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS =
=0A   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=
 =0A   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED =
=0A   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =
=0A=0ACopyright Statement =0A=0A   Copyright (C) The IETF Trust (0000). =0A=
=0A   This document is subject to the rights, licenses and restrictions =0A=
   contained in BCP 78, and except as set forth therein, the authors =0A   =
retain all their rights. =0A=0AAcknowledgment =0A=0A   Funding for the RFC =
Editor function is currently provided by the =0A   Internet Society. =0A=0A=
    =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A =
=0A =0AKang                     Expires Jan, 2009                  [Page 20=
] =0A=0C=0A=
--=_mixed 00341A364825747F_=--

Delivery-date: Thu, 03 Jul 2008 16:30:43 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-mpls-graceful-shutdown-06.txt 
Date: Thu,  3 Jul 2008 09: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           : Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks
	Author(s)       : Z. Ali, et al.
	Filename        : draft-ietf-ccamp-mpls-graceful-shutdown-06.txt
	Pages           : 11
	Date            : 2008-07-03

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-06.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-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Thu, 03 Jul 2008 16:23:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Progress on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Thu, 3 Jul 2008 12:20:20 -0400
From: "Zafar Ali (zali)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Anca Zamfir (ancaz)" <[email-masked]>, "Newton, Jonathan" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

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

Hi Adrian, et al-=20

We have addressed all LC comments in the following version.=20
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutd
own-06.txt=20

Enclosed please also find a document that list all comments received
during LC and how they are addressed.=20

Thanks

Regards... Zafar=20

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]=20
> Sent: Saturday, June 21, 2008 10:21 AM
> To: Zafar Ali (zali); [email-masked]; Anca Zamfir (ancaz);=20
> Newton, Jonathan
> Cc: [email-masked]
> Subject: Progress on draft-ietf-ccamp-mpls-graceful-shutdown
>=20
> Authors,
>=20
> The WG last call ended on this draft on March 5th.
> Do you have plans to address the comments raised?
>=20
> If there are issues please let me know. We can possibly find=20
> someone to help with the editing work, or we can move the=20
> draft to dead state when it expires next month.
>=20
> Thanks,
> Adrian
> ----- Original Message -----
> From: "Zafar Ali (zali)" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; "Anca Zamfir (ancaz)" <[email-masked]>;=20
> "Newton, Jonathan" <[email-masked]>
> Sent: Monday, March 10, 2008 10:00 PM
> Subject: RE: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
>=20
>=20
> Adrian-
>=20
> On behalf of the authors, I am acking this action item on us.
>=20
> Thanks
>=20
> Regards... Zafar
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Adrian Farrel
> > Sent: Sunday, March 09, 2008 2:48 PM
> > To: [email-masked]
> > Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
> >
> > Hi,
> >
> > This last call generated a lot of questions, issues and=20
> discussions on=20
> > 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=20
> > summarising the issues raised. For each you can say whether=20
> resolved=20
> > (and how), or your plan for resolution.
> >
> > Thanks,
> > Adrian
> > ----- Original Message -----
> > From: "Adrian Farrel" <[email-masked]>
> > To: <[email-masked]>
> > 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
> > >
> > >
> > >
> >
> >
> >
> >
>=20
>=20
>=20

------_=_NextPart_001_01C8DD28.D4224D1A
Content-Type: application/msword;
	name="how_comments_are_addressed.doc"
Content-Transfer-Encoding: base64
Content-Description: how_comments_are_addressed.doc
Content-Disposition: attachment;
	filename="how_comments_are_addressed.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAXgAAAAAAAAAA
EAAAYAAAAAEAAAD+////AAAAAF0AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAA

------_=_NextPart_001_01C8DD28.D4224D1A--