Subject: Re: [CCAMP] [PWE3] poll to make draft-busi-mpls-tp-oam-framework an mpls working group document

From: Nitin Bahadur <[email-masked]>
Date: Mon, 23 Mar 2009 00:00:13 -0700

Support.

On 3/19/09 5:48 AM, "Loa Andersson" <[email-masked]> wrote:

> Working Group,
> 
> 
> the authors of draft-busi-mpls-tp-oam-framework-02-02-1.txt has
> requested the document shall be accepted as a working group document.
> 
> This is a one week poll to see if there are support for making it a
> working group document, please respond to the mpls-tp mailing list
> before Wednesday March 26.
> 
> The document will be found at:
> 
> http://www.tla-group.com/~loa/draft-busi-mpls-tp-oam-framework-02-02-1.txt
> 
> Disclaimer: I've decided to start this poll even though the draft is not
> available from the IETF repository.
> 
> 
> /Loa

Delivery-date: Thu, 30 Apr 2009 21:31:09 +0000
Date: Thu, 30 Apr 2009 17:29:36 -0400
From: Lou Berger <[email-masked]>
To: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
CC: [email-masked]
Subject: Re: Working group last call: draft-ietf-ccamp-lsp-dppm-05

Authors,

I have some LC comments. I'll really only have general points:

- As always, please cleanup any idnits identified issues.

- In general it seems to me that for the performance metrics to be
   complete and fully useful a metric that quantifies data path
   availability relative to connection request and establishment is
   required.  In section 15 you do say:

    o  This document assumes that the correct procedures for installing
       the data plane are followed as described in [RFC3209], [RFC3471],
       and [RFC3473].  That is, by the time the egress receives and
       processes a Path message, it is safe for the egress to transmit
       data on the reverse path, and by the time the ingress receives and
       processes a Resv message it is safe for the ingress to transmit
       data on the forward path.  See [switch-programming] for detailed
      explanations. This document does not include any verification that
       the implementations of the control plane software are conformant,
       although such tests could be constructed with the use of suitable
       signal generation test equipment.  Note that, in implementing the
       tests described in this document a tester should be sure to
       measure the time taken for the control plane messages including
       the processing of those messages by the nodes under test.

   But I really don't think this is sufficient, and feel that data path
   metric parameters and related methodologies needs to be added to
   each of metrics/test cases.  If you'd like to indicate that
   these are OPTIONAL metric parameters, that is fine with me.
   But, IMO, the document is incomplete without them.  I have
   heard from others that they agree with this point too.  (I can
   try to get them to speak up publicly if this turns out to be
   necessary.)

- In the tests you treat all failures as an "undefined" result.  It
   seems to me that it would be more useful to identify and track
   (i.e., count) specific types of errors rather than just define
   all errors as "undefined" metrics.

- The document should be run through a spell checker, there are
   a number of spelling errors.

Lou

On 4/17/2009 12:25 PM, Lou Berger wrote:
>
> This email begins a two week working group last call on
> draft-ietf-ccamp-lsp-dppm-05.txt
>
> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-05
>
> Please send your comments to the list or the authors before the last
> call closes on May 1, 2009.
>
>
>
>
>

Delivery-date: Thu, 30 Apr 2009 20:58:45 +0000
Date: Thu, 30 Apr 2009 16:57:49 -0400
From: Lou Berger <[email-masked]>
To: [email-masked], [email-masked], [email-masked],  [email-masked]
CC: [email-masked]
Subject: Re: Working group last call: draft-ietf-ccamp-gmpls-ted-mib-05

Authors,

I have some fairly minor LC comments.  Also, we may get some late 
comments from a MIB "expert"...

- As always, please cleanup any idnits identified issues.

- Section 4:

 > To manage
 > MPLS/GMPLS TE attributes, MIB objects to indicate such MPLS/GMPLS TED
 >   is significant.

   The meaning of this sentence isn't clear, I suggest dropping it.

- Section 6:
 >   TE information is belonging to a node or a link, which is managed
   replace "is belonging" with "belongs".

- Section 7:
 >   teLinkIdAddrType OBJECT-TYPE
 >  ...
 >         " This object indicates the interface address type of the
 > designated router. Only values unknown(0), ipv4(1) or ipv6(2) must be
 > supported. "

   DR isn't quite right here, how about "This object indicates the
   address type of the TE Link ID."?

That's it (but I'm no MIB expert ;-).

Lou

On 4/17/2009 12:25 PM, Lou Berger wrote:
>
> This email begins a two week working group last call on
> draft-ietf-ccamp-gmpls-ted-mib-05.txt
>
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-05
>
> Please send your comments to the list or the authors before the last
> call closes on May 1, 2009.
>
>
>
>
>
>

Delivery-date: Thu, 30 Apr 2009 20:29:41 +0000
Date: Thu, 30 Apr 2009 16:27:01 -0400
From: Lou Berger <[email-masked]>
To: Dan Li <[email-masked]>, Xu Huiying <[email-masked]>,  [email-masked],  "Bardalai, Snigdho" <[email-masked]>, MEURIC Julien RD-CORE-LAN <[email-masked]>,  "Diego Caviglia (GA/ERI)" <[email-masked]>
CC: [email-masked]
Subject: Re: Working group last call: draft-ietf-ccamp-confirm-data-channel-status-02

Authors,

Here are some LC comments:

- Section 2.2:

 >   RSVP-TE restart processes [RFC3473], [RFC5063] define mechanisms
 >   where adjacent LSRs may resynchronize their control plane state to
 >   reinstate information about LSPs that have persisted in the data
 >   plane.

     The same can be said for RFC2205's (and consequently RFC3209's) soft
     state mechanisms.

- Section 2.3:
 >   operations on a cross-connect such as forced protection switch,
 >   red-line,

     Please provide references or definitions of "forced protection
     switch" and "red-line".

- Section 2.4:
 >   ... From the upstream's
 >   point of view ...

     Presumably you mean "upstream node's" point of view, i.e. "node" is
     missing.

- Section 3:
 >   The protocol extensions are intended

     Do you mean "The protocol extensions *defined in this document*"?

 >   the major factor to deal with.

     I don't understand this, do you mean "the major source of errors" or
     something else?

 >   As LMP is already used to verify data plane connectivity, it is
 >   considered to be an appropriate candidate to support this feature.

     This is a fairly major point as it defines the scope of
     use/applicability of this document.  I suggest that you repeat this
     point in both the abstract and introduction.

- Section 4.1:

 >   Three new messages are defined to check data channel status. Message
 >   Type numbers are found in Section 7.1.

     So why define new message types?  It seems that the same effect
     could have been obtained using new Channel_Status values in
     channelstatus messages.

- Section 4.1:

     How are the new messages to be encapsulated and sent?  Presumably
     the same as non-test messages, i.e., "run over the control channel,
     encapsulated in UDP with an LMP port number and IP addressing as
     defined in RFC4202".

     Also, don't you also need to specify out of order processing for the
     new messages? see the top of Page 24 in RFC4202.

- Section 4.1.1.:
 >    is found, this mismatch result SHOULD be reported to the management

    This "SHOULD" duplicates a requirement in section 5.  For many
    reasons it's not good practice to define the same requirement in two
    places and it's therefore typically avoided.  I suggest replacing
    "SHOULD be" with something like "is typically" or "is expected to
    be".

- Section 4.1.2.:
 >   status mismatch is found, the mismatch result SHOULD be reported to

    Same comment as Section 4.1.1.

- Section 4.2:

 >   0x0000 : The channel is available/free.
 >   0x0001 : The channel is cross-connected/allocated.

     What about when the channel / resource is unavailable due to being
     missing, removed, administratively off-line, failed, etc.?  Are
     different "unavailable" values warranted?  If not, perhaps
     "unavailable/in-use" is a better description than
     "cross-connected/allocated".

 >  Data Channel ID

    Isn't this field redundant with the DATA_LINK object's interface_ids?
    Please keep in mind that LMP already has a notion of data channels
    that are represented in the 4204/4209 CHANNEL_STATUS objects.  Am I
    missing something?

- Section 5:
 >  ... The RECEIVER also
 >      sends the ConfirmDataChannelStatusAck message which carries all
 >      the local end statuses of the requested data channels to the
 >      SENDER.

     If the DATA Channel ID remains, you'll need to define how it's used
     in this message.

 >   ..., and this
 >   information MAY be queried in the future.

     It seems that this clause is referring to behavior of (1) a
     management entity that is querying for mismatch state and (2) the
     node's support for this management entity.  As this document doesn't
     cover management considerations *at all* this clause should either be
     moved to a more complete "Management Considerations" section or be
     removed.

 >   The data channel status mismatch issue warned about by LMP may be
     I think you mean "identified" ---------^^^^^^^^^^^^
 >   automatically resolved by RSVP restart.

     The issue may also be resolved via RSVP soft state timeout.

 >   If the ConfirmDataChannelStatus message is not recognized by the
 >   RECEIVER, the RECEIVER will not send out an acknowledgement message

     spelling: "acknowledgment" -----------------^^^^^^^^^^^^^^^

 >   to the SENDER. In this case, if the ConfirmDataChannelStatusAck or
 >   ConfirmDataChannelStatusNack message is not received by the SENDER
 >   within the configured time, the SENDER SHOULD terminate the data
 >   channel confirmation procedure. A default value of 1 minutes is
 >   suggested for this timer.

     It might be worth identifying this "compatibility" case separately
     from the case where no ConfirmDataChannelStatusAck is received due
     to message loss.

Lou

On 4/17/2009 12:25 PM, Lou Berger wrote:
 >
 > This email begins a two week working group last call on
 > draft-ietf-ccamp-confirm-data-channel-status-02.txt
 >
 > 
http://tools.ietf.org/html/draft-ietf-ccamp-confirm-data-channel-status-02
 >
 > Please send your comments to the list or the authors before the last
 > call closes on May 1, 2009.
 >

Delivery-date: Fri, 24 Apr 2009 11:14:10 +0000
Date: Fri, 24 Apr 2009 13:12:15 +0200
From: Martin Vigoureux <[email-masked]>
Organization: Alcatel-Lucent
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: IETF 74 - MPLS WG minutes

all,

the minutes of the mpls wg sessions are available on-line:
http://tools.ietf.org/wg/mpls/minutes

Please have a look at them and let me know if you would like additional
details to be reflected.

Three slide sets are still missing, I'll contact the presenters
and upload them as soon as I receive them.

regards,
martin

Delivery-date: Fri, 24 Apr 2009 06:08:02 +0000
Date: Fri, 24 Apr 2009 14:01:02 +0800
From: Fatai Zhang <[email-masked]>
Subject: Re: Generalizing WSON information...
To: Diego Caviglia <[email-masked]>, Greg Bernstein <[email-masked]>, [email-masked]
Cc: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_OBVJCiL4l7SrdBfDYAhm1g)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64

--Boundary_(ID_OBVJCiL4l7SrdBfDYAhm1g)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: base64

--Boundary_(ID_OBVJCiL4l7SrdBfDYAhm1g)--

Delivery-date: Tue, 21 Apr 2009 18:27:14 +0000
Date: Tue, 21 Apr 2009 11:23:45 -0700
From: Greg Bernstein <[email-masked]>
To: ccamp <[email-masked]>
Subject: Updated WSON Impairments Framework Draft

Hello fellow CCAMPers, a new version of the WSON impairment framework 
draft can be found at:
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairments-04.txt
We have updated the language to conform more with that in G.698.1 and 
G.698.2. In addition we have changed
text to conform with the CCAMP/Q6 meeting notes where appropriate.

The tentative plan (my recollection) was for this document to be used in 
on going liaisons with ITU-T if we have rough agreement on the contents.

Regards

Greg B.

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

Delivery-date: Tue, 21 Apr 2009 13:17:46 +0000
From: Yechiel Rosengarten <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 21 Apr 2009 16:15:09 +0300
Subject: RE: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt 
Accept-Language: en-US
acceptlanguage: en-US

Hi
I would like to get some clarification:
By the end of procedure for scenario 1 its written:

   							.....	Note that if Node C=20
   restarts after this operation, the RecoveryPath message that it=20
   sends to Node B will not be matched with any state on Node B and=20
   will receive a PathTear as its response resulting in the teardown=20
   of the LSP at all downstream nodes.

How comes that node C, which is now the restarting node, sends RecoveryPath=
 that should be sent by downstream normal node?

Same question for the other scenarios that mention similar behavior.

Best Regards,

Yechiel Rosengarten
System Engineering
ECI Telecom Ltd
30 Hasivim St. Petach Tikva 49517 Israel
Tel:  +972 3 926 8794
Fax: +972 3 926 6200
e-mail: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of [email-masked]
Sent: Monday, May 19, 2008 7:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt=20

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 Worki=
ng Group of the IETF.

        Title           : Description of the RSVP-TE Graceful Restart Proce=
dures
        Author(s)       : D. Li
        Filename        : draft-ietf-ccamp-gr-description-03.txt
        Pages           : 19
        Date            : 2008-5-19

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-03.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: Fri, 17 Apr 2009 23:17:13 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-05.txt 
Date: Fri, 17 Apr 2009 16:15:01 -0700 (PDT)

--NextPart

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

	Title		: Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
	Author(s)	: D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Le Roux
	Filename	: draft-ietf-ccamp-gmpls-mln-extensions-05.txt
	Pages		: 22
	Date		: 2009-4-17
	
There are specific requirements for the support of networks 
comprising Label Switching Routers (LSR) participating in different data plane switching layers controlled by a single Generalized Multi 
Protocol Label Switching (GMPLS) control plane instance, referred to 
as GMPLS Multi-Layer Networks/Multi-Region Networks (MLN/MRN).  
        
This document defines extensions to GMPLS routing and signaling 
protocols so as to support the operation of GMPLS Multi-Layer/Multi-
Region Networks. It covers the elements of a single GMPLS control 
plane instance controlling multiple LSP regions or layers within a 
single TE domain.

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

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

--NextPart--

Delivery-date: Fri, 17 Apr 2009 23:03:33 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-08.txt 
Date: Fri, 17 Apr 2009 16:00:01 -0700 (PDT)

--NextPart

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

	Title		: Ethernet Traffic Parameters
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-ethernet-traffic-parameters-08.txt
	Pages		: 14
	Date		: 2009-4-17
	
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-08.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-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Fri, 17 Apr 2009 16:28:56 +0000
Date: Fri, 17 Apr 2009 12:25:56 -0400
From: Lou Berger <[email-masked]>
To: [email-masked]
Subject: Working group last call: draft-ietf-ccamp-gmpls-ted-mib-05

This email begins a two week working group last call on 
draft-ietf-ccamp-gmpls-ted-mib-05.txt

http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-05

Please send your comments to the list or the authors before the last 
call closes on May 1, 2009.

Delivery-date: Fri, 17 Apr 2009 16:28:47 +0000
Date: Fri, 17 Apr 2009 12:25:49 -0400
From: Lou Berger <[email-masked]>
To: [email-masked]
Subject: Working group last call: draft-ietf-ccamp-lsp-dppm-05

This email begins a two week working group last call on 
draft-ietf-ccamp-lsp-dppm-05.txt

http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-05

Please send your comments to the list or the authors before the last 
call closes on May 1, 2009.

Delivery-date: Fri, 17 Apr 2009 16:28:39 +0000
Date: Fri, 17 Apr 2009 12:25:33 -0400
From: Lou Berger <[email-masked]>
To: [email-masked]
Subject: Working group last call: draft-ietf-ccamp-pc-spc-rsvpte-ext-02

This email begins a two week working group last call on 
draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt

http://tools.ietf.org/html/draft-ietf-ccamp-pc-spc-rsvpte-ext-02

Please send your comments to the list or the authors before the last 
call closes on May 1, 2009.

Delivery-date: Fri, 17 Apr 2009 16:28:33 +0000
Date: Fri, 17 Apr 2009 12:25:07 -0400
From: Lou Berger <[email-masked]>
To: [email-masked]
Subject: Working group last call: draft-ietf-ccamp-confirm-data-channel-status-02

This email begins a two week working group last call on 
draft-ietf-ccamp-confirm-data-channel-status-02.txt

http://tools.ietf.org/html/draft-ietf-ccamp-confirm-data-channel-status-02

Please send your comments to the list or the authors before the last 
call closes on May 1, 2009.

Delivery-date: Thu, 16 Apr 2009 16:45:15 +0000
Date: Thu, 16 Apr 2009 09:44:18 -0700
From: Greg Bernstein <[email-masked]>
To: ccamp <[email-masked]>
Subject: Formalizing WSON a bit with ITU-T definitions...

Hello fellow CCAMPers and in particular those interested in WSON. Recent
discussions with ITU-T Study Group 15, Question 6 (Q 6/15) on 
impairments have
also pointed us to documents that can help in resolving some old issues 
in the
non-impairment case.

In particular we've had the following open issues:
(a) What should the optical signal that we are dealing with be called?
(b) Is there more than one type of optical signal?
(c) What parameters do we need to define this optical signal?

While we've all had a good notion of what we've meant by "light paths". The
problem is that CCAMP doesn't define physical layer signals so we need 
to point
to other documents. Our friends at Q6 pointed us at the following ITU-T
documents:

[1]     G.698.1 Multichannel DWDM applications with single-channel optical
         interfaces (12/2006)
[2]     G.698.2    Amplified multichannel DWDM applications with single 
channel
        optical interfaces (07/2007)
[3]    G.959.1    Optical transport network physical layer interfaces 
(03/2006)

For Wavelength Switched Optical Networks (WSONs), references [1] and [2] are
what we need since they specify single channel interfaces into multi-channel
WDM networks. They use definitions from reference [3].

 From these we get the following definitions:
(1) Optical Tributary Signal [3] -- A single channel signal that is placed
    within an optical channel for transport across the optical network. 
This seems
    to be the "thing" that we are switching in WSONs.
(2) A variety of optical tributary signal classes based on modulation 
format and
    bit rate range [3]:
    (a) optical tributary signal class NRZ 1.25G
    (b) optical tributary signal class NRZ 2.5G
    (c) optical tributary signal class NRZ 10G
    (d) optical tributary signal class NRZ 40G
    (e) optical tributary signal class RZ 40G
(3) Although [1] and [2] are primarily concerned with impairments they 
specify a
    number of non-impairment related parameters:
    (a) Minimum channel spacing (incorporated into CCAMP G.694.1 labels)
    (b) Bit-rate/line coding of optical tributary signals. Note that [2]
        section 7.1.2 specifies that the exact bit rate needs to be
        specified.
    (c) FEC enabled
    (d) Minimum and Maximum central frequency in THz (we've got this in the
        WSON framework and info model, but we'll check the name).

We propose to update the WSON Framework (CCAMP WG) document
(draft-ietf-ccamp-rwa-wson-framework-02.txt) with this formalism and
definitions. Any comments, suggestions?

Best Regards

Greg, Young, and WSON co-authors

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

Delivery-date: Thu, 16 Apr 2009 16:29:05 +0000
Date: Thu, 16 Apr 2009 09:28:05 -0700
From: Greg Bernstein <[email-masked]>
To: Diego Caviglia <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Generalizing WSON information...

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

Hi Diego and all, looking at the old MS-SPRing drafts I'm picking up the 
following:

(a) MS-SPRing nodes (switches) are not required to provide Time slot 
interchange (TSI).  A property of the switches.(generalizes WSON)
(b) Time slot continuity is required for correct operation of the 
restoration protocol. A property of the LSP. (generalizes WSON)
(c) A need to disseminate ring map information (RingID,  Ring Node #) 
--> More of a generalization of existing GMPLS info on protection?

what I didn't see but wondered about is:
(d) Time slot availability on ring links. Wouldn't you need this to 
perform the time slot continuity constrained path computation. 
(generalizing RWA concept and WSON available wavelengths).
(e) In my past we dealt with trans-oceanic applications and it seemed 
like some of these constraints were loosened a bit because of the longer 
time period and differing switching points. Comments?

Other items?  Other applications?

Best Regards

Greg

Diego Caviglia wrote:
> Hi all,
>         I think that this is an interesting topic to move on, may be this time we can solve the issue of MS-SPRing interworking with GMPLS control plane that we were able to solve some times ago.
>
> May be we can resume the ID about the MS-SPRing we did some time ago and try to elaborate a generalization.
>
> BR
>
> Diego
>
>  
> __________________________________________
> Diego Caviglia
> Strategic Product Manager
> Broadband Networks, PL Broadband Optical Network 
> Ericsson Telecomunicazioni S.p.A. (TEI)
> Via A. Negrone 1/A                           Office:  +39 010 600 3736
> 16153, Genova, Italy                          Fax: +39 010 600 3577
> Block E Level 4                                  Mobile: +39 335 7181762
> www.ericsson.com                       [email-masked]
> This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
> ________________________________
>
>
>   
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Greg Bernstein
>> Sent: mercoledì 15 aprile 2009 19.02
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: Generalizing WSON information...
>>
>> Hi Julien, interesting point. It did seem like older SDH equipment did
>> have a "time-slot continuity constraint", but I never directly dealt
>> with those systems. There was some work a while ago on MS-SPRing (Diego?).
>> Maybe we need to think up a level, as you said in the usual GMPLS, MPLS
>> cases full label swapping is a typical capability. Should we be explicit
>> in the WSON case (maybe with the connectivity matrix) in indicating that
>> this may or may not be the case? Right now we are being implicit about
>> this lack of wavelength (label) conversion capability.
>>
>> The notion of the shared wavelength converter pools and the accompanying
>> details seem very WSON specific. But the fact that a switch or mux can't
>> perform label exchange seems a fairly general notion that we could group
>> with other generalizable information...
>>
>> Best Regards
>>
>> Greg
>>
>> [email-masked] wrote:
>>     
>>> Hi Greg.
>>>
>>> Just a small comment on Wavelength Converter Pool in section 3.2. In
>>>       
>> some other GMPLS contexts, this may be modelled as a label swapping
>> capability, which is a common enough to be considered as "Generalizable"
>> (it's even a typical case that becomes an exception due to our label
>> continuity constraint). However, as for several other parameters, I don't
>> think there is an actual need for it (this is already the default); but
>> maybe we could imagine some MS-SPRing operations in SONET/SDH.
>>     
>>> Regards,
>>>
>>> Julien
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>>       
>> Behalf Of Greg Bernstein
>>     
>>> Sent: Tuesday, April 14, 2009 6:32 PM
>>> To: ccamp
>>> Subject: Generalizing WSON information...
>>>
>>> Hello fellow CCAMPers, at the 74th IETF meeting in San Francisco the
>>> question
>>> came up as to what if any of the WSON path computation information model
>>> would
>>> be useful in other technologies. Below is a first attempt at such an
>>> assesment
>>> based on the current version of draft-ietf-ccamp-rwa-info-02.txt.
>>> Existing GMPLS
>>> standard information is not included.
>>>
>>>  From section 3.2 Node Information:
>>>
>>> Switched Connectivity Matrix: Generalizable:Yes. This can be used to
>>> model any
>>> type of asymetrical switch in any technology. Caveat: Besides optical is
>>> there
>>> any current products that can make use of this?
>>>
>>> Fixed Connectivity Matrix: Generalizable: Yes. This can be used to model
>>> fixed
>>> connectivity between ports. Caveat: Is there any need outside optical?
>>>
>>> Wavelength Converter Pool: Generally useful: No. This is very
>>>       
>> application
>>     
>>> specific to optical switching systems.
>>>
>>>  From section 3.3 Link Information:
>>>
>>> Switched and Fixed Port Wavelength (label) Restrictions: Generally
>>>       
>> useful: I
>>     
>>> don't think so but open to examples. These constraints must be shared in
>>>       
>> the
>>     
>>> WSON case for two reasons: (a) the wavelength continuity constraint
>>>       
>> requires
>>     
>>> global label assignment, (b) WSON devices present many different types
>>>       
>> of
>>     
>>> wavelength constraints. Note that without requirement (a) then (b)
>>> doesn't need
>>> to be shared since local label (wavelength) assignment would suffice.
>>>
>>>  From section 3.4  Dynamic Link information
>>>
>>> Available Wavelengths (labels): Generally useful? We need detailed
>>> wavelength
>>> availability information due to the wavelength continuity constraint.
>>> Way back
>>> in the old days many of us implemented bit maps to track SONET/SDH time
>>> slots
>>> but this never made it into the standards. Any interest in that now?
>>>       
>> Other
>>     
>>> examples?
>>>
>>> Shared Backup Wavelengths (labels): Similar to the above but used in
>>> efficient
>>> shared mesh backup path computation.
>>>
>>>  From section 3.5 Dynamic Node Information
>>>
>>> Wavelength Converter Pool Status: Not generally applicable. Too
>>>       
>> application
>>     
>>> specific.
>>>
>>> Comments appreciated
>>>
>>> Greg
>>>
>>>
>>>       
>> --
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>>
>>     
>
>
>
>   

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

--------------080505090404050902050009
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 Diego and all, looking at the old MS-SPRing drafts I'm picking up
the following:<br>
<br>
(a) MS-SPRing nodes (switches) are not required to provide Time slot
interchange (TSI).&nbsp; A property of the switches.(generalizes WSON)<br>
(b) Time slot continuity is required for correct operation of the
restoration protocol. A property of the LSP. (generalizes WSON)<br>
(c) A need to disseminate ring map information (RingID,&nbsp; Ring Node #)
--&gt; More of a generalization of existing GMPLS info on protection?<br>
<br>
what I didn't see but wondered about is:<br>
(d) Time slot availability on ring links. Wouldn't you need this to
perform the time slot continuity constrained path computation.
(generalizing RWA concept and WSON available wavelengths).<br>
(e) In my past we dealt with trans-oceanic applications and it seemed
like some of these constraints were loosened a bit because of the
longer time period and differing switching points. Comments?<br>
<br>
Other items?&nbsp; Other applications?<br>
<br>
Best Regards<br>
<br>
Greg<br>
<br>
<br>
Diego Caviglia wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Hi all,
        I think that this is an interesting topic to move on, may be this time we can solve the issue of MS-SPRing interworking with GMPLS control plane that we were able to solve some times ago.

May be we can resume the ID about the MS-SPRing we did some time ago and try to elaborate a generalization.

BR

Diego

__________________________________________
Diego Caviglia
Strategic Product Manager
Broadband Networks, PL Broadband Optical Network 
Ericsson Telecomunicazioni S.p.A. (TEI)
Via A. Negrone 1/A                           Office:  +39 010 600 3736
16153, Genova, Italy                          Fax: +39 010 600 3577
Block E Level 4                                  Mobile: +39 335 7181762
<a class="moz-txt-link-abbreviated" href="http://www.ericsson.com">www.ericsson.com</a>                       <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
________________________________

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf
Of Greg Bernstein
Sent: mercoled&igrave; 15 aprile 2009 19.02
To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: Re: Generalizing WSON information...

Hi Julien, interesting point. It did seem like older SDH equipment did
have a "time-slot continuity constraint", but I never directly dealt
with those systems. There was some work a while ago on MS-SPRing (Diego?).
Maybe we need to think up a level, as you said in the usual GMPLS, MPLS
cases full label swapping is a typical capability. Should we be explicit
in the WSON case (maybe with the connectivity matrix) in indicating that
this may or may not be the case? Right now we are being implicit about
this lack of wavelength (label) conversion capability.

The notion of the shared wavelength converter pools and the accompanying
details seem very WSON specific. But the fact that a switch or mux can't
perform label exchange seems a fairly general notion that we could group
with other generalizable information...

Best Regards

Greg

<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi Greg.

Just a small comment on Wavelength Converter Pool in section 3.2. In
      </pre>
    </blockquote>
    <pre wrap="">some other GMPLS contexts, this may be modelled as a label swapping
capability, which is a common enough to be considered as "Generalizable"
(it's even a typical case that becomes an exception due to our label
continuity constraint). However, as for several other parameters, I don't
think there is an actual need for it (this is already the default); but
maybe we could imagine some MS-SPRing operations in SONET/SDH.
    </pre>
    <blockquote type="cite">
      <pre wrap="">Regards,

Julien

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] On
      </pre>
    </blockquote>
    <pre wrap="">Behalf Of Greg Bernstein
    </pre>
    <blockquote type="cite">
      <pre wrap="">Sent: Tuesday, April 14, 2009 6:32 PM
To: ccamp
Subject: Generalizing WSON information...

Hello fellow CCAMPers, at the 74th IETF meeting in San Francisco the
question
came up as to what if any of the WSON path computation information model
would
be useful in other technologies. Below is a first attempt at such an
assesment
based on the current version of draft-ietf-ccamp-rwa-info-02.txt.
Existing GMPLS
standard information is not included.

 From section 3.2 Node Information:

Switched Connectivity Matrix: Generalizable:Yes. This can be used to
model any
type of asymetrical switch in any technology. Caveat: Besides optical is
there
any current products that can make use of this?

Fixed Connectivity Matrix: Generalizable: Yes. This can be used to model
fixed
connectivity between ports. Caveat: Is there any need outside optical?

Wavelength Converter Pool: Generally useful: No. This is very
      </pre>
    </blockquote>
    <pre wrap="">application
    </pre>
    <blockquote type="cite">
      <pre wrap="">specific to optical switching systems.

 From section 3.3 Link Information:

Switched and Fixed Port Wavelength (label) Restrictions: Generally
      </pre>
    </blockquote>
    <pre wrap="">useful: I
    </pre>
    <blockquote type="cite">
      <pre wrap="">don't think so but open to examples. These constraints must be shared in
      </pre>
    </blockquote>
    <pre wrap="">the
    </pre>
    <blockquote type="cite">
      <pre wrap="">WSON case for two reasons: (a) the wavelength continuity constraint
      </pre>
    </blockquote>
    <pre wrap="">requires
    </pre>
    <blockquote type="cite">
      <pre wrap="">global label assignment, (b) WSON devices present many different types
      </pre>
    </blockquote>
    <pre wrap="">of
    </pre>
    <blockquote type="cite">
      <pre wrap="">wavelength constraints. Note that without requirement (a) then (b)
doesn't need
to be shared since local label (wavelength) assignment would suffice.

 From section 3.4  Dynamic Link information

Available Wavelengths (labels): Generally useful? We need detailed
wavelength
availability information due to the wavelength continuity constraint.
Way back
in the old days many of us implemented bit maps to track SONET/SDH time
slots
but this never made it into the standards. Any interest in that now?
      </pre>
    </blockquote>
    <pre wrap="">Other
    </pre>
    <blockquote type="cite">
      <pre wrap="">examples?

Shared Backup Wavelengths (labels): Similar to the above but used in
efficient
shared mesh backup path computation.

 From section 3.5 Dynamic Node Information

Wavelength Converter Pool Status: Not generally applicable. Too
      </pre>
    </blockquote>
    <pre wrap="">application
    </pre>
    <blockquote type="cite">
      <pre wrap="">specific.

Comments appreciated

Greg

      </pre>
    </blockquote>
    <pre wrap="">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

    </pre>
  </blockquote>
  <pre wrap=""><!---->

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

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

--------------080505090404050902050009--

Delivery-date: Thu, 16 Apr 2009 16:20:44 +0000
From: "Sadler, Jonathan B." <[email-masked]>
To: Greg Bernstein <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Thu, 16 Apr 2009 11:19:58 -0500
Subject: RE: Generalizing WSON information...
Accept-Language: en-US
acceptlanguage: en-US

Its also this older SDH equipment that had limitations with respect to the =
"vector" of a connection -- that is, connections could only go from drop to=
 line or line to line, but couldn't go drop to drop.  Some other older devi=
ces also had limitations on which ports could be paired for the purposes of=
 protection.

These limitations could be handled as a part of the "switch connectivity ma=
trix".

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Greg Bernstein
Sent: Wednesday, April 15, 2009 12:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Generalizing WSON information...

Hi Julien, interesting point. It did seem like older SDH equipment did=20
have a "time-slot continuity constraint", but I never directly dealt=20
with those systems. There was some work a while ago on MS-SPRing (Diego?).
Maybe we need to think up a level, as you said in the usual GMPLS, MPLS=20
cases full label swapping is a typical capability. Should we be explicit=20
in the WSON case (maybe with the connectivity matrix) in indicating that=20
this may or may not be the case? Right now we are being implicit about=20
this lack of wavelength (label) conversion capability.

The notion of the shared wavelength converter pools and the accompanying=20
details seem very WSON specific. But the fact that a switch or mux can't=20
perform label exchange seems a fairly general notion that we could group=20
with other generalizable information...

Best Regards

Greg

[email-masked] wrote:
> Hi Greg.
>
> Just a small comment on Wavelength Converter Pool in section 3.2. In some=
 other GMPLS contexts, this may be modelled as a label swapping capability,=
 which is a common enough to be considered as "Generalizable" (it's even a =
typical case that becomes an exception due to our label continuity constrai=
nt). However, as for several other parameters, I don't think there is an ac=
tual need for it (this is already the default); but maybe we could imagine =
some MS-SPRing operations in SONET/SDH.
>
> Regards,
>
> Julien
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behal=
f Of Greg Bernstein
> Sent: Tuesday, April 14, 2009 6:32 PM
> To: ccamp
> Subject: Generalizing WSON information...
>
> Hello fellow CCAMPers, at the 74th IETF meeting in San Francisco the=20
> question
> came up as to what if any of the WSON path computation information model=20
> would
> be useful in other technologies. Below is a first attempt at such an=20
> assesment
> based on the current version of draft-ietf-ccamp-rwa-info-02.txt.=20
> Existing GMPLS
> standard information is not included.
>
>  From section 3.2 Node Information:
>
> Switched Connectivity Matrix: Generalizable:Yes. This can be used to=20
> model any
> type of asymetrical switch in any technology. Caveat: Besides optical is=20
> there
> any current products that can make use of this?
>
> Fixed Connectivity Matrix: Generalizable: Yes. This can be used to model=20
> fixed
> connectivity between ports. Caveat: Is there any need outside optical?
>
> Wavelength Converter Pool: Generally useful: No. This is very application
> specific to optical switching systems.
>
>  From section 3.3 Link Information:
>
> Switched and Fixed Port Wavelength (label) Restrictions: Generally useful=
: I
> don't think so but open to examples. These constraints must be shared in =
the
> WSON case for two reasons: (a) the wavelength continuity constraint requi=
res
> global label assignment, (b) WSON devices present many different types of
> wavelength constraints. Note that without requirement (a) then (b)=20
> doesn't need
> to be shared since local label (wavelength) assignment would suffice.
>
>  From section 3.4  Dynamic Link information
>
> Available Wavelengths (labels): Generally useful? We need detailed=20
> wavelength
> availability information due to the wavelength continuity constraint.=20
> Way back
> in the old days many of us implemented bit maps to track SONET/SDH time=20
> slots
> but this never made it into the standards. Any interest in that now? Other
> examples?
>
> Shared Backup Wavelengths (labels): Similar to the above but used in=20
> efficient
> shared mesh backup path computation.
>
>  From section 3.5 Dynamic Node Information
>
> Wavelength Converter Pool Status: Not generally applicable. Too applicati=
on
> specific.
> Comments appreciated
> Greg
>  =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

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

Delivery-date: Thu, 16 Apr 2009 16:18:24 +0000
From: "Sadler, Jonathan B." <[email-masked]>
To: Greg Bernstein <[email-masked]>, "Drake, John E" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 16 Apr 2009 11:17:39 -0500
Subject: RE: Generalizing WSON information...
Accept-Language: en-US
acceptlanguage: en-US

I prefer this approach, as it also allows for mixing links that have and do=
n't have this restriction.

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Greg Bernstein
Sent: Thursday, April 16, 2009 11:11 AM
To: Drake, John E
Cc: [email-masked]; [email-masked]
Subject: Re: Generalizing WSON information...

Sounds like one way to encode the wavelength converter pool resource=20
state. Other ideas?

Regards

Greg

Drake, John E wrote:
> Greg,
>
> The work on switching capabilities, RFC4202, assumes a pool of node
> resources shared among links and was advertised as a link capability.
> When a given pool of resources was exhausted, the corresponding link
> capability was withdrawn for all links.
>
> Thanks,
>
> John=20
>
>  =20
>> -----Original Message-----
>> From: Greg Bernstein [mailto:[email-masked]]=20
>> Sent: Wednesday, April 15, 2009 10:02 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: Generalizing WSON information...
>>
>> Hi Julien, interesting point. It did seem like older SDH=20
>> equipment did have a "time-slot continuity constraint", but I=20
>> never directly dealt with those systems. There was some work=20
>> a while ago on MS-SPRing (Diego?).
>> Maybe we need to think up a level, as you said in the usual=20
>> GMPLS, MPLS cases full label swapping is a typical=20
>> capability. Should we be explicit in the WSON case (maybe=20
>> with the connectivity matrix) in indicating that this may or=20
>> may not be the case? Right now we are being implicit about=20
>> this lack of wavelength (label) conversion capability.
>>
>> The notion of the shared wavelength converter pools and the=20
>> accompanying details seem very WSON specific. But the fact=20
>> that a switch or mux can't perform label exchange seems a=20
>> fairly general notion that we could group with other=20
>> generalizable information...
>>
>> Best Regards
>>
>> Greg
>>
>> [email-masked] wrote:
>>    =20
>>> Hi Greg.
>>>
>>> Just a small comment on Wavelength Converter Pool in=20
>>>      =20
>> section 3.2. In some other GMPLS contexts, this may be=20
>> modelled as a label swapping capability, which is a common=20
>> enough to be considered as "Generalizable" (it's even a=20
>> typical case that becomes an exception due to our label=20
>> continuity constraint). However, as for several other=20
>> parameters, I don't think there is an actual need for it=20
>> (this is already the default); but maybe we could imagine=20
>> some MS-SPRing operations in SONET/SDH.
>>    =20
>>> Regards,
>>>
>>> Julien
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On=20
>>> Behalf Of Greg Bernstein
>>> Sent: Tuesday, April 14, 2009 6:32 PM
>>> To: ccamp
>>> Subject: Generalizing WSON information...
>>>
>>> Hello fellow CCAMPers, at the 74th IETF meeting in San=20
>>>      =20
>> Francisco the=20
>>    =20
>>> question came up as to what if any of the WSON path computation=20
>>> information model would be useful in other technologies. Below is a=20
>>> first attempt at such an assesment based on the current version of=20
>>> draft-ietf-ccamp-rwa-info-02.txt.
>>> Existing GMPLS
>>> standard information is not included.
>>>
>>>  From section 3.2 Node Information:
>>>
>>> Switched Connectivity Matrix: Generalizable:Yes. This can=20
>>>      =20
>> be used to=20
>>    =20
>>> model any type of asymetrical switch in any technology. Caveat:=20
>>> Besides optical is there any current products that can make use of=20
>>> this?
>>>
>>> Fixed Connectivity Matrix: Generalizable: Yes. This can be used to=20
>>> model fixed connectivity between ports. Caveat: Is there any need=20
>>> outside optical?
>>>
>>> Wavelength Converter Pool: Generally useful: No. This is very=20
>>> application specific to optical switching systems.
>>>
>>>  From section 3.3 Link Information:
>>>
>>> Switched and Fixed Port Wavelength (label) Restrictions: Generally=20
>>> useful: I don't think so but open to examples. These=20
>>>      =20
>> constraints must=20
>>    =20
>>> be shared in the WSON case for two reasons: (a) the wavelength=20
>>> continuity constraint requires global label assignment, (b) WSON=20
>>> devices present many different types of wavelength=20
>>>      =20
>> constraints. Note=20
>>    =20
>>> that without requirement (a) then (b) doesn't need to be=20
>>>      =20
>> shared since=20
>>    =20
>>> local label (wavelength) assignment would suffice.
>>>
>>>  From section 3.4  Dynamic Link information
>>>
>>> Available Wavelengths (labels): Generally useful? We need detailed=20
>>> wavelength availability information due to the wavelength=20
>>>      =20
>> continuity=20
>>    =20
>>> constraint.
>>> Way back
>>> in the old days many of us implemented bit maps to track SONET/SDH=20
>>> time slots but this never made it into the standards. Any=20
>>>      =20
>> interest in=20
>>    =20
>>> that now? Other examples?
>>>
>>> Shared Backup Wavelengths (labels): Similar to the above=20
>>>      =20
>> but used in=20
>>    =20
>>> efficient shared mesh backup path computation.
>>>
>>>  From section 3.5 Dynamic Node Information
>>>
>>> Wavelength Converter Pool Status: Not generally applicable. Too=20
>>> application specific.
>>>
>>> Comments appreciated
>>>
>>> Greg
>>>
>>>  =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

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

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

Delivery-date: Thu, 16 Apr 2009 16:12:59 +0000
Date: Thu, 16 Apr 2009 09:10:44 -0700
From: Greg Bernstein <[email-masked]>
To: "Drake, John E" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Generalizing WSON information...

Sounds like one way to encode the wavelength converter pool resource 
state. Other ideas?

Regards

Greg

Drake, John E wrote:
> Greg,
>
> The work on switching capabilities, RFC4202, assumes a pool of node
> resources shared among links and was advertised as a link capability.
> When a given pool of resources was exhausted, the corresponding link
> capability was withdrawn for all links.
>
> Thanks,
>
> John 
>
>   
>> -----Original Message-----
>> From: Greg Bernstein [mailto:[email-masked]] 
>> Sent: Wednesday, April 15, 2009 10:02 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: Generalizing WSON information...
>>
>> Hi Julien, interesting point. It did seem like older SDH 
>> equipment did have a "time-slot continuity constraint", but I 
>> never directly dealt with those systems. There was some work 
>> a while ago on MS-SPRing (Diego?).
>> Maybe we need to think up a level, as you said in the usual 
>> GMPLS, MPLS cases full label swapping is a typical 
>> capability. Should we be explicit in the WSON case (maybe 
>> with the connectivity matrix) in indicating that this may or 
>> may not be the case? Right now we are being implicit about 
>> this lack of wavelength (label) conversion capability.
>>
>> The notion of the shared wavelength converter pools and the 
>> accompanying details seem very WSON specific. But the fact 
>> that a switch or mux can't perform label exchange seems a 
>> fairly general notion that we could group with other 
>> generalizable information...
>>
>> Best Regards
>>
>> Greg
>>
>> [email-masked] wrote:
>>     
>>> Hi Greg.
>>>
>>> Just a small comment on Wavelength Converter Pool in 
>>>       
>> section 3.2. In some other GMPLS contexts, this may be 
>> modelled as a label swapping capability, which is a common 
>> enough to be considered as "Generalizable" (it's even a 
>> typical case that becomes an exception due to our label 
>> continuity constraint). However, as for several other 
>> parameters, I don't think there is an actual need for it 
>> (this is already the default); but maybe we could imagine 
>> some MS-SPRing operations in SONET/SDH.
>>     
>>> Regards,
>>>
>>> Julien
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Greg Bernstein
>>> Sent: Tuesday, April 14, 2009 6:32 PM
>>> To: ccamp
>>> Subject: Generalizing WSON information...
>>>
>>> Hello fellow CCAMPers, at the 74th IETF meeting in San 
>>>       
>> Francisco the 
>>     
>>> question came up as to what if any of the WSON path computation 
>>> information model would be useful in other technologies. Below is a 
>>> first attempt at such an assesment based on the current version of 
>>> draft-ietf-ccamp-rwa-info-02.txt.
>>> Existing GMPLS
>>> standard information is not included.
>>>
>>>  From section 3.2 Node Information:
>>>
>>> Switched Connectivity Matrix: Generalizable:Yes. This can 
>>>       
>> be used to 
>>     
>>> model any type of asymetrical switch in any technology. Caveat: 
>>> Besides optical is there any current products that can make use of 
>>> this?
>>>
>>> Fixed Connectivity Matrix: Generalizable: Yes. This can be used to 
>>> model fixed connectivity between ports. Caveat: Is there any need 
>>> outside optical?
>>>
>>> Wavelength Converter Pool: Generally useful: No. This is very 
>>> application specific to optical switching systems.
>>>
>>>  From section 3.3 Link Information:
>>>
>>> Switched and Fixed Port Wavelength (label) Restrictions: Generally 
>>> useful: I don't think so but open to examples. These 
>>>       
>> constraints must 
>>     
>>> be shared in the WSON case for two reasons: (a) the wavelength 
>>> continuity constraint requires global label assignment, (b) WSON 
>>> devices present many different types of wavelength 
>>>       
>> constraints. Note 
>>     
>>> that without requirement (a) then (b) doesn't need to be 
>>>       
>> shared since 
>>     
>>> local label (wavelength) assignment would suffice.
>>>
>>>  From section 3.4  Dynamic Link information
>>>
>>> Available Wavelengths (labels): Generally useful? We need detailed 
>>> wavelength availability information due to the wavelength 
>>>       
>> continuity 
>>     
>>> constraint.
>>> Way back
>>> in the old days many of us implemented bit maps to track SONET/SDH 
>>> time slots but this never made it into the standards. Any 
>>>       
>> interest in 
>>     
>>> that now? Other examples?
>>>
>>> Shared Backup Wavelengths (labels): Similar to the above 
>>>       
>> but used in 
>>     
>>> efficient shared mesh backup path computation.
>>>
>>>  From section 3.5 Dynamic Node Information
>>>
>>> Wavelength Converter Pool Status: Not generally applicable. Too 
>>> application specific.
>>>
>>> Comments appreciated
>>>
>>> Greg
>>>
>>>   
>>>       
>> --
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>>
>>
>>
>>     
>
>   

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

Delivery-date: Thu, 16 Apr 2009 07:52:20 +0000
Content-class: urn:content-classes:message
Subject: RE: Generalizing WSON information...
Date: Thu, 16 Apr 2009 09:43:40 +0200
From: "Diego Caviglia" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi all,
        I think that this is an interesting topic to move on, may be =
this time we can solve the issue of MS-SPRing interworking with GMPLS =
control plane that we were able to solve some times ago.

May be we can resume the ID about the MS-SPRing we did some time ago and =
try to elaborate a generalization.

BR

Diego

=20
__________________________________________
Diego Caviglia
Strategic Product Manager
Broadband Networks, PL Broadband Optical Network=20
Ericsson Telecomunicazioni S.p.A. (TEI)
Via A. Negrone 1/A                           Office:  +39 010 600 3736
16153, Genova, Italy                          Fax: +39 010 600 3577
Block E Level 4                                  Mobile: +39 335 7181762
www.ericsson.com                       [email-masked]
This communication is confidential and intended solely for the =
addressee(s). Any unauthorized review, use, disclosure or distribution =
is prohibited. If you believe this message has been sent to you in =
error, please notify the sender by replying to this transmission and =
delete the message without disclosing it. Thank you.
________________________________

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On =
Behalf
> Of Greg Bernstein
> Sent: mercoled=EC 15 aprile 2009 19.02
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Generalizing WSON information...
>=20
> Hi Julien, interesting point. It did seem like older SDH equipment did
> have a "time-slot continuity constraint", but I never directly dealt
> with those systems. There was some work a while ago on MS-SPRing =
(Diego?).
> Maybe we need to think up a level, as you said in the usual GMPLS, =
MPLS
> cases full label swapping is a typical capability. Should we be =
explicit
> in the WSON case (maybe with the connectivity matrix) in indicating =
that
> this may or may not be the case? Right now we are being implicit about
> this lack of wavelength (label) conversion capability.
>=20
> The notion of the shared wavelength converter pools and the =
accompanying
> details seem very WSON specific. But the fact that a switch or mux =
can't
> perform label exchange seems a fairly general notion that we could =
group
> with other generalizable information...
>=20
> Best Regards
>=20
> Greg
>=20
> [email-masked] wrote:
> > Hi Greg.
> >
> > Just a small comment on Wavelength Converter Pool in section 3.2. In
> some other GMPLS contexts, this may be modelled as a label swapping
> capability, which is a common enough to be considered as =
"Generalizable"
> (it's even a typical case that becomes an exception due to our label
> continuity constraint). However, as for several other parameters, I =
don't
> think there is an actual need for it (this is already the default); =
but
> maybe we could imagine some MS-SPRing operations in SONET/SDH.
> >
> > Regards,
> >
> > Julien
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Greg Bernstein
> > Sent: Tuesday, April 14, 2009 6:32 PM
> > To: ccamp
> > Subject: Generalizing WSON information...
> >
> > Hello fellow CCAMPers, at the 74th IETF meeting in San Francisco the
> > question
> > came up as to what if any of the WSON path computation information =
model
> > would
> > be useful in other technologies. Below is a first attempt at such an
> > assesment
> > based on the current version of draft-ietf-ccamp-rwa-info-02.txt.
> > Existing GMPLS
> > standard information is not included.
> >
> >  From section 3.2 Node Information:
> >
> > Switched Connectivity Matrix: Generalizable:Yes. This can be used to
> > model any
> > type of asymetrical switch in any technology. Caveat: Besides =
optical is
> > there
> > any current products that can make use of this?
> >
> > Fixed Connectivity Matrix: Generalizable: Yes. This can be used to =
model
> > fixed
> > connectivity between ports. Caveat: Is there any need outside =
optical?
> >
> > Wavelength Converter Pool: Generally useful: No. This is very
> application
> > specific to optical switching systems.
> >
> >  From section 3.3 Link Information:
> >
> > Switched and Fixed Port Wavelength (label) Restrictions: Generally
> useful: I
> > don't think so but open to examples. These constraints must be =
shared in
> the
> > WSON case for two reasons: (a) the wavelength continuity constraint
> requires
> > global label assignment, (b) WSON devices present many different =
types
> of
> > wavelength constraints. Note that without requirement (a) then (b)
> > doesn't need
> > to be shared since local label (wavelength) assignment would =
suffice.
> >
> >  From section 3.4  Dynamic Link information
> >
> > Available Wavelengths (labels): Generally useful? We need detailed
> > wavelength
> > availability information due to the wavelength continuity =
constraint.
> > Way back
> > in the old days many of us implemented bit maps to track SONET/SDH =
time
> > slots
> > but this never made it into the standards. Any interest in that now?
> Other
> > examples?
> >
> > Shared Backup Wavelengths (labels): Similar to the above but used in
> > efficient
> > shared mesh backup path computation.
> >
> >  From section 3.5 Dynamic Node Information
> >
> > Wavelength Converter Pool Status: Not generally applicable. Too
> application
> > specific.
> >
> > Comments appreciated
> >
> > Greg
> >
> >
>=20
> --
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>=20
>=20

Delivery-date: Wed, 15 Apr 2009 18:04:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Generalizing WSON information...
Date: Wed, 15 Apr 2009 11:02:26 -0700
From: "Drake, John E" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Greg,

The work on switching capabilities, RFC4202, assumes a pool of node
resources shared among links and was advertised as a link capability.
When a given pool of resources was exhausted, the corresponding link
capability was withdrawn for all links.

Thanks,

John=20

> -----Original Message-----
> From: Greg Bernstein [mailto:[email-masked]]=20
> Sent: Wednesday, April 15, 2009 10:02 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Generalizing WSON information...
>=20
> Hi Julien, interesting point. It did seem like older SDH=20
> equipment did have a "time-slot continuity constraint", but I=20
> never directly dealt with those systems. There was some work=20
> a while ago on MS-SPRing (Diego?).
> Maybe we need to think up a level, as you said in the usual=20
> GMPLS, MPLS cases full label swapping is a typical=20
> capability. Should we be explicit in the WSON case (maybe=20
> with the connectivity matrix) in indicating that this may or=20
> may not be the case? Right now we are being implicit about=20
> this lack of wavelength (label) conversion capability.
>=20
> The notion of the shared wavelength converter pools and the=20
> accompanying details seem very WSON specific. But the fact=20
> that a switch or mux can't perform label exchange seems a=20
> fairly general notion that we could group with other=20
> generalizable information...
>=20
> Best Regards
>=20
> Greg
>=20
> [email-masked] wrote:
> > Hi Greg.
> >
> > Just a small comment on Wavelength Converter Pool in=20
> section 3.2. In some other GMPLS contexts, this may be=20
> modelled as a label swapping capability, which is a common=20
> enough to be considered as "Generalizable" (it's even a=20
> typical case that becomes an exception due to our label=20
> continuity constraint). However, as for several other=20
> parameters, I don't think there is an actual need for it=20
> (this is already the default); but maybe we could imagine=20
> some MS-SPRing operations in SONET/SDH.
> >
> > Regards,
> >
> > Julien
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On=20
> > Behalf Of Greg Bernstein
> > Sent: Tuesday, April 14, 2009 6:32 PM
> > To: ccamp
> > Subject: Generalizing WSON information...
> >
> > Hello fellow CCAMPers, at the 74th IETF meeting in San=20
> Francisco the=20
> > question came up as to what if any of the WSON path computation=20
> > information model would be useful in other technologies. Below is a=20
> > first attempt at such an assesment based on the current version of=20
> > draft-ietf-ccamp-rwa-info-02.txt.
> > Existing GMPLS
> > standard information is not included.
> >
> >  From section 3.2 Node Information:
> >
> > Switched Connectivity Matrix: Generalizable:Yes. This can=20
> be used to=20
> > model any type of asymetrical switch in any technology. Caveat:=20
> > Besides optical is there any current products that can make use of=20
> > this?
> >
> > Fixed Connectivity Matrix: Generalizable: Yes. This can be used to=20
> > model fixed connectivity between ports. Caveat: Is there any need=20
> > outside optical?
> >
> > Wavelength Converter Pool: Generally useful: No. This is very=20
> > application specific to optical switching systems.
> >
> >  From section 3.3 Link Information:
> >
> > Switched and Fixed Port Wavelength (label) Restrictions: Generally=20
> > useful: I don't think so but open to examples. These=20
> constraints must=20
> > be shared in the WSON case for two reasons: (a) the wavelength=20
> > continuity constraint requires global label assignment, (b) WSON=20
> > devices present many different types of wavelength=20
> constraints. Note=20
> > that without requirement (a) then (b) doesn't need to be=20
> shared since=20
> > local label (wavelength) assignment would suffice.
> >
> >  From section 3.4  Dynamic Link information
> >
> > Available Wavelengths (labels): Generally useful? We need detailed=20
> > wavelength availability information due to the wavelength=20
> continuity=20
> > constraint.
> > Way back
> > in the old days many of us implemented bit maps to track SONET/SDH=20
> > time slots but this never made it into the standards. Any=20
> interest in=20
> > that now? Other examples?
> >
> > Shared Backup Wavelengths (labels): Similar to the above=20
> but used in=20
> > efficient shared mesh backup path computation.
> >
> >  From section 3.5 Dynamic Node Information
> >
> > Wavelength Converter Pool Status: Not generally applicable. Too=20
> > application specific.
> >
> > Comments appreciated
> >
> > Greg
> >
> >  =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
>=20
>=20

Delivery-date: Wed, 15 Apr 2009 17:32:35 +0000
Date: Wed, 15 Apr 2009 19:31:31 +0200
From: Huub van Helvoort <[email-masked]>
Reply-To: [email-masked]
To: Greg Bernstein <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Generalizing WSON information...

Hi Greg,

You wrote:

> Hi Julien, interesting point. It did seem like older SDH equipment did 
> have a "time-slot continuity constraint", but I never directly dealt 
> with those systems. There was some work a while ago on MS-SPRing (Diego?).

And Huub!
Normally in MS-SPRing a timeslot (e.g. VC-4) that is not dropped in
a node is passed through and re-uses the same timeslot number on all
spans it traverses.
This makes the ring-maps in each ring-node simple.

Cheers, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

Delivery-date: Wed, 15 Apr 2009 17:03:22 +0000
Date: Wed, 15 Apr 2009 10:01:41 -0700
From: Greg Bernstein <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Generalizing WSON information...

Hi Julien, interesting point. It did seem like older SDH equipment did 
have a "time-slot continuity constraint", but I never directly dealt 
with those systems. There was some work a while ago on MS-SPRing (Diego?).
Maybe we need to think up a level, as you said in the usual GMPLS, MPLS 
cases full label swapping is a typical capability. Should we be explicit 
in the WSON case (maybe with the connectivity matrix) in indicating that 
this may or may not be the case? Right now we are being implicit about 
this lack of wavelength (label) conversion capability.

The notion of the shared wavelength converter pools and the accompanying 
details seem very WSON specific. But the fact that a switch or mux can't 
perform label exchange seems a fairly general notion that we could group 
with other generalizable information...

Best Regards

Greg

[email-masked] wrote:
> Hi Greg.
>
> Just a small comment on Wavelength Converter Pool in section 3.2. In some other GMPLS contexts, this may be modelled as a label swapping capability, which is a common enough to be considered as "Generalizable" (it's even a typical case that becomes an exception due to our label continuity constraint). However, as for several other parameters, I don't think there is an actual need for it (this is already the default); but maybe we could imagine some MS-SPRing operations in SONET/SDH.
>
> Regards,
>
> Julien
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Bernstein
> Sent: Tuesday, April 14, 2009 6:32 PM
> To: ccamp
> Subject: Generalizing WSON information...
>
> Hello fellow CCAMPers, at the 74th IETF meeting in San Francisco the 
> question
> came up as to what if any of the WSON path computation information model 
> would
> be useful in other technologies. Below is a first attempt at such an 
> assesment
> based on the current version of draft-ietf-ccamp-rwa-info-02.txt. 
> Existing GMPLS
> standard information is not included.
>
>  From section 3.2 Node Information:
>
> Switched Connectivity Matrix: Generalizable:Yes. This can be used to 
> model any
> type of asymetrical switch in any technology. Caveat: Besides optical is 
> there
> any current products that can make use of this?
>
> Fixed Connectivity Matrix: Generalizable: Yes. This can be used to model 
> fixed
> connectivity between ports. Caveat: Is there any need outside optical?
>
> Wavelength Converter Pool: Generally useful: No. This is very application
> specific to optical switching systems.
>
>  From section 3.3 Link Information:
>
> Switched and Fixed Port Wavelength (label) Restrictions: Generally useful: I
> don't think so but open to examples. These constraints must be shared in the
> WSON case for two reasons: (a) the wavelength continuity constraint requires
> global label assignment, (b) WSON devices present many different types of
> wavelength constraints. Note that without requirement (a) then (b) 
> doesn't need
> to be shared since local label (wavelength) assignment would suffice.
>
>  From section 3.4  Dynamic Link information
>
> Available Wavelengths (labels): Generally useful? We need detailed 
> wavelength
> availability information due to the wavelength continuity constraint. 
> Way back
> in the old days many of us implemented bit maps to track SONET/SDH time 
> slots
> but this never made it into the standards. Any interest in that now? Other
> examples?
>
> Shared Backup Wavelengths (labels): Similar to the above but used in 
> efficient
> shared mesh backup path computation.
>
>  From section 3.5 Dynamic Node Information
>
> Wavelength Converter Pool Status: Not generally applicable. Too application
> specific.
>
> Comments appreciated
>
> Greg
>
>   

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

Delivery-date: Wed, 15 Apr 2009 10:10:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Generalizing WSON information...
Date: Wed, 15 Apr 2009 12:08:17 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Greg.

Just a small comment on Wavelength Converter Pool in section 3.2. In =
some other GMPLS contexts, this may be modelled as a label swapping =
capability, which is a common enough to be considered as "Generalizable" =
(it's even a typical case that becomes an exception due to our label =
continuity constraint). However, as for several other parameters, I =
don't think there is an actual need for it (this is already the =
default); but maybe we could imagine some MS-SPRing operations in =
SONET/SDH.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Greg Bernstein
Sent: Tuesday, April 14, 2009 6:32 PM
To: ccamp
Subject: Generalizing WSON information...

Hello fellow CCAMPers, at the 74th IETF meeting in San Francisco the=20
question
came up as to what if any of the WSON path computation information model =

would
be useful in other technologies. Below is a first attempt at such an=20
assesment
based on the current version of draft-ietf-ccamp-rwa-info-02.txt.=20
Existing GMPLS
standard information is not included.

 From section 3.2 Node Information:

Switched Connectivity Matrix: Generalizable:Yes. This can be used to=20
model any
type of asymetrical switch in any technology. Caveat: Besides optical is =

there
any current products that can make use of this?

Fixed Connectivity Matrix: Generalizable: Yes. This can be used to model =

fixed
connectivity between ports. Caveat: Is there any need outside optical?

Wavelength Converter Pool: Generally useful: No. This is very =
application
specific to optical switching systems.

 From section 3.3 Link Information:

Switched and Fixed Port Wavelength (label) Restrictions: Generally =
useful: I
don't think so but open to examples. These constraints must be shared in =
the
WSON case for two reasons: (a) the wavelength continuity constraint =
requires
global label assignment, (b) WSON devices present many different types =
of
wavelength constraints. Note that without requirement (a) then (b)=20
doesn't need
to be shared since local label (wavelength) assignment would suffice.

 From section 3.4  Dynamic Link information

Available Wavelengths (labels): Generally useful? We need detailed=20
wavelength
availability information due to the wavelength continuity constraint.=20
Way back
in the old days many of us implemented bit maps to track SONET/SDH time=20
slots
but this never made it into the standards. Any interest in that now? =
Other
examples?

Shared Backup Wavelengths (labels): Similar to the above but used in=20
efficient
shared mesh backup path computation.

 From section 3.5 Dynamic Node Information

Wavelength Converter Pool Status: Not generally applicable. Too =
application
specific.

Comments appreciated

Greg

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

Delivery-date: Tue, 14 Apr 2009 16:33:21 +0000
Date: Tue, 14 Apr 2009 09:31:53 -0700
From: Greg Bernstein <[email-masked]>
To: ccamp <[email-masked]>
Subject: Generalizing WSON information...

Hello fellow CCAMPers, at the 74th IETF meeting in San Francisco the 
question
came up as to what if any of the WSON path computation information model 
would
be useful in other technologies. Below is a first attempt at such an 
assesment
based on the current version of draft-ietf-ccamp-rwa-info-02.txt. 
Existing GMPLS
standard information is not included.

 From section 3.2 Node Information:

Switched Connectivity Matrix: Generalizable:Yes. This can be used to 
model any
type of asymetrical switch in any technology. Caveat: Besides optical is 
there
any current products that can make use of this?

Fixed Connectivity Matrix: Generalizable: Yes. This can be used to model 
fixed
connectivity between ports. Caveat: Is there any need outside optical?

Wavelength Converter Pool: Generally useful: No. This is very application
specific to optical switching systems.

 From section 3.3 Link Information:

Switched and Fixed Port Wavelength (label) Restrictions: Generally useful: I
don't think so but open to examples. These constraints must be shared in the
WSON case for two reasons: (a) the wavelength continuity constraint requires
global label assignment, (b) WSON devices present many different types of
wavelength constraints. Note that without requirement (a) then (b) 
doesn't need
to be shared since local label (wavelength) assignment would suffice.

 From section 3.4  Dynamic Link information

Available Wavelengths (labels): Generally useful? We need detailed 
wavelength
availability information due to the wavelength continuity constraint. 
Way back
in the old days many of us implemented bit maps to track SONET/SDH time 
slots
but this never made it into the standards. Any interest in that now? Other
examples?

Shared Backup Wavelengths (labels): Similar to the above but used in 
efficient
shared mesh backup path computation.

 From section 3.5 Dynamic Node Information

Wavelength Converter Pool Status: Not generally applicable. Too application
specific.

Comments appreciated

Greg

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

Delivery-date: Tue, 14 Apr 2009 15:00:43 +0000
Content-class: urn:content-classes:message
Subject: RE: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Date: Tue, 14 Apr 2009 16:49:04 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Remi Theillaud" <[email-masked]>
Cc: <[email-masked]>

oops:

read "The node attribute TLV must appear in exactly one TE LSA =
originated for a --TE-- router.".

---

Remi,

By not changing the encoding rules of sub-TLVs within a given TE LSA =
that rule has to be relaxed in the sense "The node attribute TLV must =
appear in exactly one TE LSA originated by a --TE-- router.".=20

Thanks,
-dimitri.
________________________________

	From: Remi Theillaud [mailto:[email-masked]]=20
	Sent: Tuesday, April 14, 2009 4:37 PM
	To: PAPADIMITRIOU Dimitri
	Cc: [email-masked]
	Subject: Re: One question about =
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
=09
=09
	   Dimitri,
=09
	   I understand the sentence "The node attribute TLV must appear in =
exactly one TE LSA originated by a router." as meaning that a router is =
not allowed to originate multiple LSAs specifying a node attribute TLV.
=09
	   Thanks for your quick answers,
	   R=E9mi
=09
=09
	-------- Original Message --------
	Subject: Re: One question about =
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
	From: PAPADIMITRIOU Dimitri <[email-masked]> =
<mailto:[email-masked]>=20
	To: Remi Theillaud <[email-masked]> =
<mailto:[email-masked]>=20
	CC: [email-masked]
	Date: 14/04/2009 16:28
=09

		Don't we say the same thing ? Quoting this doc.:
		=20
		 " The node attribute TLV must appear in exactly one TE LSA originated
		   by a router. Further only one node attribute TLV must be advertised
		   in such a LSA. A node attribute TLV must carry at most one Node =
IPv4
		   Local Address sub-TLV and at most one Node IPv6 Local Address sub-
		   TLV."
		=20
		Hence, to your question:
	=09
		 =20

			Should a Local TE Router-ID sub-TLV be encoded=20
			*before* each Node IPv4/IPv6 Local Prefix Sub-TLV?=20
			   =20

	=09
		it is a one to one correspondance in each of these LSAs.
		-d.
	=09
	=09
		 =20

			-----Original Message-----
			From: Remi Theillaud [mailto:[email-masked]]=20
			Sent: Tuesday, April 14, 2009 4:23 PM
			To: PAPADIMITRIOU Dimitri
			Cc: [email-masked]
			Subject: Re: One question about=20
			draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
		=09
		=09
			   Hi Dimitri,
		=09
			   I thought about it, but=20
			draft-ietf-ospf-te-node-addr-05.txt section=20
			4.2 states "The node attribute TLV must appear in exactly one TE LSA=20
			originated by a router. Further only one node attribute TLV must be=20
			advertised in such a LSA." So it does seem possible for a router to=20
			advertise multiple LSAs specifying a node attribute TLV.
		=09
			   Thanks,
			   R=E9mi
		=09
		=09
			-------- Original Message --------
			Subject: Re: One question about=20
			draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
			From: PAPADIMITRIOU Dimitri <[email-masked]> =
<mailto:[email-masked]>=20
			To: Remi Theillaud <[email-masked]> =
<mailto:[email-masked]> ,=20
			[email-masked]
			Date: 14/04/2009 16:06
			   =20

				hi remi: the encoding follows=20
				     =20

			http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-ad
			dr-05.txt=20
			<http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-a
			ddr-05.txt> =
<http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-05.txt>=
 ; hence, you will find only one TE Router ID=20
			sub-TLV (together with one Node IPv4 / IPv6 Local Prefix=20
			sub-TLV) per top level node attribute TLV per opaque LSA and=20
			have multiple TE LSAs.
			   =20

				=20
				thanks,
				-dimitri.
			=09
			=09
				________________________________
			=09
					From: [email-masked]=20
				     =20

			[mailto:[email-masked]] On Behalf Of Remi Theillaud
			   =20

					Sent: Tuesday, April 14, 2009 3:43 PM
					To: [email-masked]
					Subject: One question about=20
				     =20

			draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
			   =20

				=09
				=09
			=09
					  Hi CCAMP,=20
				=09
					  One question about=20
				     =20

			draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt.=20
			   =20

					  This draft defines a new Node-Attribute sub-TLV=20
				     =20

			(Local TE Router-ID sub-TLV) as "optional sub-TLV for scoping=20
			reachability per TE Router-ID".=20
			   =20

					  How does this scoping occur when a router advertises=20
				     =20

			reachability information on behalf of multiple TE Router IDs?=20
			   =20

					  Should a Local TE Router-ID sub-TLV be encoded=20
				     =20

			*before* each Node IPv4/IPv6 Local Prefix Sub-TLV?=20
			   =20

					 =20
					  Regards,=20
					  R=E9mi=20
				=09
			=09
			=09
				 =20
				     =20

			--=20
		=09
			------------------------------------------
		=09
			R=E9mi Theillaud
			Senior Consultant
		=09
			Marben Products
			176 rue Jean Jaures
			92800 Puteaux
			France
		=09
			Tel : +33 (0)1 7962 1022
			Fax : +33 (0)1 7962 1001
			[email-masked]
			www.marben-products.com =20
		=09
		=09
			   =20

	=09
		 =20

	--=20
=09
	------------------------------------------
=09
	R=E9mi Theillaud
	Senior Consultant
=09
	Marben Products
	176 rue Jean Jaures
	92800 Puteaux
	France
=09
	Tel : +33 (0)1 7962 1022
	Fax : +33 (0)1 7962 1001
	[email-masked]
	www.marben-products.com =20
=09

Delivery-date: Tue, 14 Apr 2009 14:46:51 +0000
Content-class: urn:content-classes:message
Subject: RE: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Date: Tue, 14 Apr 2009 16:45:35 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Remi Theillaud" <[email-masked]>
Cc: <[email-masked]>

Remi,

By not changing the encoding rules of sub-TLVs within a given TE LSA =
that rule has to be relaxed in the sense "The node attribute TLV must =
appear in exactly one TE LSA originated by a --TE-- router.".=20

Thanks,
-dimitri.
________________________________

	From: Remi Theillaud [mailto:[email-masked]]=20
	Sent: Tuesday, April 14, 2009 4:37 PM
	To: PAPADIMITRIOU Dimitri
	Cc: [email-masked]
	Subject: Re: One question about =
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
=09
=09
	   Dimitri,
=09
	   I understand the sentence "The node attribute TLV must appear in =
exactly one TE LSA originated by a router." as meaning that a router is =
not allowed to originate multiple LSAs specifying a node attribute TLV.
=09
	   Thanks for your quick answers,
	   R=E9mi
=09
=09
	-------- Original Message --------
	Subject: Re: One question about =
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
	From: PAPADIMITRIOU Dimitri <[email-masked]> =
<mailto:[email-masked]>=20
	To: Remi Theillaud <[email-masked]> =
<mailto:[email-masked]>=20
	CC: [email-masked]
	Date: 14/04/2009 16:28
=09

		Don't we say the same thing ? Quoting this doc.:
		=20
		 " The node attribute TLV must appear in exactly one TE LSA originated
		   by a router. Further only one node attribute TLV must be advertised
		   in such a LSA. A node attribute TLV must carry at most one Node =
IPv4
		   Local Address sub-TLV and at most one Node IPv6 Local Address sub-
		   TLV."
		=20
		Hence, to your question:
	=09
		 =20

			Should a Local TE Router-ID sub-TLV be encoded=20
			*before* each Node IPv4/IPv6 Local Prefix Sub-TLV?=20
			   =20

	=09
		it is a one to one correspondance in each of these LSAs.
		-d.
	=09
	=09
		 =20

			-----Original Message-----
			From: Remi Theillaud [mailto:[email-masked]]=20
			Sent: Tuesday, April 14, 2009 4:23 PM
			To: PAPADIMITRIOU Dimitri
			Cc: [email-masked]
			Subject: Re: One question about=20
			draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
		=09
		=09
			   Hi Dimitri,
		=09
			   I thought about it, but=20
			draft-ietf-ospf-te-node-addr-05.txt section=20
			4.2 states "The node attribute TLV must appear in exactly one TE LSA=20
			originated by a router. Further only one node attribute TLV must be=20
			advertised in such a LSA." So it does seem possible for a router to=20
			advertise multiple LSAs specifying a node attribute TLV.
		=09
			   Thanks,
			   R=E9mi
		=09
		=09
			-------- Original Message --------
			Subject: Re: One question about=20
			draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
			From: PAPADIMITRIOU Dimitri <[email-masked]> =
<mailto:[email-masked]>=20
			To: Remi Theillaud <[email-masked]> =
<mailto:[email-masked]> ,=20
			[email-masked]
			Date: 14/04/2009 16:06
			   =20

				hi remi: the encoding follows=20
				     =20

			http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-ad
			dr-05.txt=20
			<http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-a
			ddr-05.txt> =
<http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-05.txt>=
 ; hence, you will find only one TE Router ID=20
			sub-TLV (together with one Node IPv4 / IPv6 Local Prefix=20
			sub-TLV) per top level node attribute TLV per opaque LSA and=20
			have multiple TE LSAs.
			   =20

				=20
				thanks,
				-dimitri.
			=09
			=09
				________________________________
			=09
					From: [email-masked]=20
				     =20

			[mailto:[email-masked]] On Behalf Of Remi Theillaud
			   =20

					Sent: Tuesday, April 14, 2009 3:43 PM
					To: [email-masked]
					Subject: One question about=20
				     =20

			draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
			   =20

				=09
				=09
			=09
					  Hi CCAMP,=20
				=09
					  One question about=20
				     =20

			draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt.=20
			   =20

					  This draft defines a new Node-Attribute sub-TLV=20
				     =20

			(Local TE Router-ID sub-TLV) as "optional sub-TLV for scoping=20
			reachability per TE Router-ID".=20
			   =20

					  How does this scoping occur when a router advertises=20
				     =20

			reachability information on behalf of multiple TE Router IDs?=20
			   =20

					  Should a Local TE Router-ID sub-TLV be encoded=20
				     =20

			*before* each Node IPv4/IPv6 Local Prefix Sub-TLV?=20
			   =20

					 =20
					  Regards,=20
					  R=E9mi=20
				=09
			=09
			=09
				 =20
				     =20

			--=20
		=09
			------------------------------------------
		=09
			R=E9mi Theillaud
			Senior Consultant
		=09
			Marben Products
			176 rue Jean Jaures
			92800 Puteaux
			France
		=09
			Tel : +33 (0)1 7962 1022
			Fax : +33 (0)1 7962 1001
			[email-masked]
			www.marben-products.com =20
		=09
		=09
			   =20

	=09
		 =20

	--=20
=09
	------------------------------------------
=09
	R=E9mi Theillaud
	Senior Consultant
=09
	Marben Products
	176 rue Jean Jaures
	92800 Puteaux
	France
=09
	Tel : +33 (0)1 7962 1022
	Fax : +33 (0)1 7962 1001
	[email-masked]
	www.marben-products.com =20
=09

Delivery-date: Tue, 14 Apr 2009 14:37:41 +0000
Date: Tue, 14 Apr 2009 16:36:45 +0200
From: Remi Theillaud <[email-masked]>
To: PAPADIMITRIOU Dimitri <[email-masked]>
CC: [email-masked]
Subject: Re: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt

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

   Dimitri,

   I understand the sentence "The node attribute TLV must appear in 
exactly one TE LSA originated by a router." as meaning that a router is 
not allowed to originate multiple LSAs specifying a node attribute TLV.

   Thanks for your quick answers,
   Rémi

-------- Original Message --------
Subject: Re: One question about 
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
From: PAPADIMITRIOU Dimitri <[email-masked]>
To: Remi Theillaud <[email-masked]>
CC: [email-masked]
Date: 14/04/2009 16:28
> Don't we say the same thing ? Quoting this doc.:
>  
>  " The node attribute TLV must appear in exactly one TE LSA originated
>    by a router. Further only one node attribute TLV must be advertised
>    in such a LSA. A node attribute TLV must carry at most one Node IPv4
>    Local Address sub-TLV and at most one Node IPv6 Local Address sub-
>    TLV."
>  
> Hence, to your question:
>
>   
>> Should a Local TE Router-ID sub-TLV be encoded 
>> *before* each Node IPv4/IPv6 Local Prefix Sub-TLV? 
>>     
>
> it is a one to one correspondance in each of these LSAs.
> -d.
>
>
>   
>> -----Original Message-----
>> From: Remi Theillaud [mailto:[email-masked]] 
>> Sent: Tuesday, April 14, 2009 4:23 PM
>> To: PAPADIMITRIOU Dimitri
>> Cc: [email-masked]
>> Subject: Re: One question about 
>> draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
>>
>>
>>    Hi Dimitri,
>>
>>    I thought about it, but 
>> draft-ietf-ospf-te-node-addr-05.txt section 
>> 4.2 states "The node attribute TLV must appear in exactly one TE LSA 
>> originated by a router. Further only one node attribute TLV must be 
>> advertised in such a LSA." So it does seem possible for a router to 
>> advertise multiple LSAs specifying a node attribute TLV.
>>
>>    Thanks,
>>    Rémi
>>
>>
>> -------- Original Message --------
>> Subject: Re: One question about 
>> draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
>> From: PAPADIMITRIOU Dimitri <[email-masked]>
>> To: Remi Theillaud <[email-masked]>, 
>> [email-masked]
>> Date: 14/04/2009 16:06
>>     
>>> hi remi: the encoding follows 
>>>       
>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-ad
>> dr-05.txt 
>> <http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-a
>> ddr-05.txt>; hence, you will find only one TE Router ID 
>> sub-TLV (together with one Node IPv4 / IPv6 Local Prefix 
>> sub-TLV) per top level node attribute TLV per opaque LSA and 
>> have multiple TE LSAs.
>>     
>>>  
>>> thanks,
>>> -dimitri.
>>>
>>>
>>> ________________________________
>>>
>>> 	From: [email-masked] 
>>>       
>> [mailto:[email-masked]] On Behalf Of Remi Theillaud
>>     
>>> 	Sent: Tuesday, April 14, 2009 3:43 PM
>>> 	To: [email-masked]
>>> 	Subject: One question about 
>>>       
>> draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
>>     
>>> 	
>>> 	
>>>
>>> 	  Hi CCAMP, 
>>> 	
>>> 	  One question about 
>>>       
>> draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt. 
>>     
>>> 	  This draft defines a new Node-Attribute sub-TLV 
>>>       
>> (Local TE Router-ID sub-TLV) as "optional sub-TLV for scoping 
>> reachability per TE Router-ID". 
>>     
>>> 	  How does this scoping occur when a router advertises 
>>>       
>> reachability information on behalf of multiple TE Router IDs? 
>>     
>>> 	  Should a Local TE Router-ID sub-TLV be encoded 
>>>       
>> *before* each Node IPv4/IPv6 Local Prefix Sub-TLV? 
>>     
>>> 	  
>>> 	  Regards, 
>>> 	  Rémi 
>>> 	
>>>
>>>
>>>   
>>>       
>> -- 
>>
>> ------------------------------------------
>>
>> Rémi Theillaud
>> Senior Consultant
>>
>> Marben Products
>> 176 rue Jean Jaures
>> 92800 Puteaux
>> France
>>
>> Tel : +33 (0)1 7962 1022
>> Fax : +33 (0)1 7962 1001
>> [email-masked]
>> www.marben-products.com  
>>
>>
>>     
>
>   

-- 

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

Rémi Theillaud
Senior Consultant

Marben Products
176 rue Jean Jaures
92800 Puteaux
France

Tel : +33 (0)1 7962 1022
Fax : +33 (0)1 7962 1001
[email-masked]
www.marben-products.com  

--------------070102070704030100010406
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">
&nbsp;&nbsp; Dimitri,<br>
<br>
&nbsp;&nbsp; I understand the sentence "The node attribute TLV must appear in
exactly one TE LSA originated by a router." as meaning that a router is
not allowed to originate multiple LSAs specifying a node attribute TLV.<br>
<br>
&nbsp;&nbsp; Thanks for your quick answers,<br>
&nbsp;&nbsp; R&eacute;mi<br>
<br>
<br>
-------- Original Message --------<br>
Subject: Re: One question about
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt<br>
From: PAPADIMITRIOU Dimitri
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
To: Remi Theillaud <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
CC: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
Date: 14/04/2009 16:28<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Don't we say the same thing ? Quoting this doc.:
 
 " The node attribute TLV must appear in exactly one TE LSA originated
   by a router. Further only one node attribute TLV must be advertised
   in such a LSA. A node attribute TLV must carry at most one Node IPv4
   Local Address sub-TLV and at most one Node IPv6 Local Address sub-
   TLV."
 
Hence, to your question:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Should a Local TE Router-ID sub-TLV be encoded 
*before* each Node IPv4/IPv6 Local Prefix Sub-TLV? 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
it is a one to one correspondance in each of these LSAs.
-d.

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: Remi Theillaud [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] 
Sent: Tuesday, April 14, 2009 4:23 PM
To: PAPADIMITRIOU Dimitri
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: Re: One question about 
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt

   Hi Dimitri,

   I thought about it, but 
draft-ietf-ospf-te-node-addr-05.txt section 
4.2 states "The node attribute TLV must appear in exactly one TE LSA 
originated by a router. Further only one node attribute TLV must be 
advertised in such a LSA." So it does seem possible for a router to 
advertise multiple LSAs specifying a node attribute TLV.

   Thanks,
   R&eacute;mi

-------- Original Message --------
Subject: Re: One question about 
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
From: PAPADIMITRIOU Dimitri <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
To: Remi Theillaud <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>, 
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Date: 14/04/2009 16:06
    </pre>
    <blockquote type="cite">
      <pre wrap="">hi remi: the encoding follows 
      </pre>
    </blockquote>
    <pre wrap=""><a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-ad">http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-ad</a>
dr-05.txt 
<a class="moz-txt-link-rfc2396E" href="http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-05.txt">&lt;http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-a
ddr-05.txt&gt;</a>; hence, you will find only one TE Router ID 
sub-TLV (together with one Node IPv4 / IPv6 Local Prefix 
sub-TLV) per top level node attribute TLV per opaque LSA and 
have multiple TE LSAs.
    </pre>
    <blockquote type="cite">
      <pre wrap=""> 
thanks,
-dimitri.

________________________________

	From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> 
      </pre>
    </blockquote>
    <pre wrap="">[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of Remi Theillaud
    </pre>
    <blockquote type="cite">
      <pre wrap="">	Sent: Tuesday, April 14, 2009 3:43 PM
	To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
	Subject: One question about 
      </pre>
    </blockquote>
    <pre wrap="">draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
    </pre>
    <blockquote type="cite">
      <pre wrap="">	

	  Hi CCAMP, 
	
	  One question about 
      </pre>
    </blockquote>
    <pre wrap="">draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt. 
    </pre>
    <blockquote type="cite">
      <pre wrap="">	  This draft defines a new Node-Attribute sub-TLV 
      </pre>
    </blockquote>
    <pre wrap="">(Local TE Router-ID sub-TLV) as "optional sub-TLV for scoping 
reachability per TE Router-ID". 
    </pre>
    <blockquote type="cite">
      <pre wrap="">	  How does this scoping occur when a router advertises 
      </pre>
    </blockquote>
    <pre wrap="">reachability information on behalf of multiple TE Router IDs? 
    </pre>
    <blockquote type="cite">
      <pre wrap="">	  Should a Local TE Router-ID sub-TLV be encoded 
      </pre>
    </blockquote>
    <pre wrap="">*before* each Node IPv4/IPv6 Local Prefix Sub-TLV? 
    </pre>
    <blockquote type="cite">
      <pre wrap="">	  
	  Regards, 
	  R&eacute;mi 

      </pre>
    </blockquote>
    <pre wrap="">-- 

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

R&eacute;mi Theillaud
Senior Consultant

Marben Products
176 rue Jean Jaures
92800 Puteaux
France

Tel : +33 (0)1 7962 1022
Fax : +33 (0)1 7962 1001
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-abbreviated" href="http://www.marben-products.com">www.marben-products.com</a>  

    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 

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

R&eacute;mi Theillaud
Senior Consultant

Marben Products
176 rue Jean Jaures
92800 Puteaux
France

Tel : +33 (0)1 7962 1022
Fax : +33 (0)1 7962 1001
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-abbreviated" href="http://www.marben-products.com">www.marben-products.com</a>  
</pre>
</body>
</html>

--------------070102070704030100010406--

Delivery-date: Tue, 14 Apr 2009 14:28:54 +0000
Content-class: urn:content-classes:message
Subject: RE: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Date: Tue, 14 Apr 2009 16:28:20 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Remi Theillaud" <[email-masked]>
Cc: <[email-masked]>

Don't we say the same thing ? Quoting this doc.:
=20
 " The node attribute TLV must appear in exactly one TE LSA originated
   by a router. Further only one node attribute TLV must be advertised
   in such a LSA. A node attribute TLV must carry at most one Node IPv4
   Local Address sub-TLV and at most one Node IPv6 Local Address sub-
   TLV."
=20
Hence, to your question:

> Should a Local TE Router-ID sub-TLV be encoded=20
> *before* each Node IPv4/IPv6 Local Prefix Sub-TLV?=20

it is a one to one correspondance in each of these LSAs.
-d.

> -----Original Message-----
> From: Remi Theillaud [mailto:[email-masked]]=20
> Sent: Tuesday, April 14, 2009 4:23 PM
> To: PAPADIMITRIOU Dimitri
> Cc: [email-masked]
> Subject: Re: One question about=20
> draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
>=20
>=20
>    Hi Dimitri,
>=20
>    I thought about it, but=20
> draft-ietf-ospf-te-node-addr-05.txt section=20
> 4.2 states "The node attribute TLV must appear in exactly one TE LSA=20
> originated by a router. Further only one node attribute TLV must be=20
> advertised in such a LSA." So it does seem possible for a router to=20
> advertise multiple LSAs specifying a node attribute TLV.
>=20
>    Thanks,
>    R=E9mi
>=20
>=20
> -------- Original Message --------
> Subject: Re: One question about=20
> draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
> From: PAPADIMITRIOU Dimitri <[email-masked]>
> To: Remi Theillaud <[email-masked]>,=20
> [email-masked]
> Date: 14/04/2009 16:06
> > hi remi: the encoding follows=20
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-ad
> dr-05.txt=20
> <http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-a
> ddr-05.txt>; hence, you will find only one TE Router ID=20
> sub-TLV (together with one Node IPv4 / IPv6 Local Prefix=20
> sub-TLV) per top level node attribute TLV per opaque LSA and=20
> have multiple TE LSAs.
> > =20
> > thanks,
> > -dimitri.
> >
> >
> > ________________________________
> >
> > 	From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Remi Theillaud
> > 	Sent: Tuesday, April 14, 2009 3:43 PM
> > 	To: [email-masked]
> > 	Subject: One question about=20
> draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
> > =09
> > =09
> >
> > 	  Hi CCAMP,=20
> > =09
> > 	  One question about=20
> draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt.=20
> > 	  This draft defines a new Node-Attribute sub-TLV=20
> (Local TE Router-ID sub-TLV) as "optional sub-TLV for scoping=20
> reachability per TE Router-ID".=20
> > 	  How does this scoping occur when a router advertises=20
> reachability information on behalf of multiple TE Router IDs?=20
> > 	  Should a Local TE Router-ID sub-TLV be encoded=20
> *before* each Node IPv4/IPv6 Local Prefix Sub-TLV?=20
> > 	 =20
> > 	  Regards,=20
> > 	  R=E9mi=20
> > =09
> >
> >
> >  =20
>=20
> --=20
>=20
> ------------------------------------------
>=20
> R=E9mi Theillaud
> Senior Consultant
>=20
> Marben Products
> 176 rue Jean Jaures
> 92800 Puteaux
> France
>=20
> Tel : +33 (0)1 7962 1022
> Fax : +33 (0)1 7962 1001
> [email-masked]
> www.marben-products.com =20
>=20
>=20

Delivery-date: Tue, 14 Apr 2009 14:24:17 +0000
Date: Tue, 14 Apr 2009 16:23:13 +0200
From: Remi Theillaud <[email-masked]>
To: PAPADIMITRIOU Dimitri <[email-masked]>
CC: [email-masked]
Subject: Re: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt

   Hi Dimitri,

   I thought about it, but draft-ietf-ospf-te-node-addr-05.txt section 
4.2 states "The node attribute TLV must appear in exactly one TE LSA 
originated by a router. Further only one node attribute TLV must be 
advertised in such a LSA." So it does seem possible for a router to 
advertise multiple LSAs specifying a node attribute TLV.

   Thanks,
   Rémi

-------- Original Message --------
Subject: Re: One question about 
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
From: PAPADIMITRIOU Dimitri <[email-masked]>
To: Remi Theillaud <[email-masked]>, [email-masked]
Date: 14/04/2009 16:06
> hi remi: the encoding follows http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-05.txt <http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-05.txt>; hence, you will find only one TE Router ID sub-TLV (together with one Node IPv4 / IPv6 Local Prefix sub-TLV) per top level node attribute TLV per opaque LSA and have multiple TE LSAs.
>  
> thanks,
> -dimitri.
>
>
> ________________________________
>
> 	From: [email-masked] [mailto:[email-masked]] On Behalf Of Remi Theillaud
> 	Sent: Tuesday, April 14, 2009 3:43 PM
> 	To: [email-masked]
> 	Subject: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
> 	
> 	
>
> 	  Hi CCAMP, 
> 	
> 	  One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt. 
> 	  This draft defines a new Node-Attribute sub-TLV (Local TE Router-ID sub-TLV) as "optional sub-TLV for scoping reachability per TE Router-ID". 
> 	  How does this scoping occur when a router advertises reachability information on behalf of multiple TE Router IDs? 
> 	  Should a Local TE Router-ID sub-TLV be encoded *before* each Node IPv4/IPv6 Local Prefix Sub-TLV? 
> 	  
> 	  Regards, 
> 	  Rémi 
> 	
>
>
>   

-- 

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

Rémi Theillaud
Senior Consultant

Marben Products
176 rue Jean Jaures
92800 Puteaux
France

Tel : +33 (0)1 7962 1022
Fax : +33 (0)1 7962 1001
[email-masked]
www.marben-products.com  

Delivery-date: Tue, 14 Apr 2009 14:07:48 +0000
Content-class: urn:content-classes:message
Subject: RE: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Date: Tue, 14 Apr 2009 16:06:46 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Remi Theillaud" <[email-masked]>, <[email-masked]>

hi remi: the encoding follows =
http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-05.txt =
<http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-05.txt>=
; hence, you will find only one TE Router ID sub-TLV (together with one =
Node IPv4 / IPv6 Local Prefix sub-TLV) per top level node attribute TLV =
per opaque LSA and have multiple TE LSAs.
=20
thanks,
-dimitri.

________________________________

	From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Remi Theillaud
	Sent: Tuesday, April 14, 2009 3:43 PM
	To: [email-masked]
	Subject: One question about =
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
=09
=09

	  Hi CCAMP,=20
=09
	  One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt.=20
	  This draft defines a new Node-Attribute sub-TLV (Local TE Router-ID =
sub-TLV) as "optional sub-TLV for scoping reachability per TE =
Router-ID".=20
	  How does this scoping occur when a router advertises reachability =
information on behalf of multiple TE Router IDs?=20
	  Should a Local TE Router-ID sub-TLV be encoded *before* each Node =
IPv4/IPv6 Local Prefix Sub-TLV?=20
	 =20
	  Regards,=20
	  R=E9mi=20
=09

Delivery-date: Tue, 14 Apr 2009 13:45:12 +0000
Date: Tue, 14 Apr 2009 15:42:37 +0200
From: Remi Theillaud <[email-masked]>
To: [email-masked]
Subject: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt

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

  Hi CCAMP,

  One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt.
  This draft defines a new Node-Attribute sub-TLV (Local TE Router-ID 
sub-TLV) as "optional sub-TLV for scoping reachability per TE Router-ID".
  How does this scoping occur when a router advertises reachability 
information on behalf of multiple TE Router IDs?
  Should a Local TE Router-ID sub-TLV be encoded *before* each Node 
IPv4/IPv6 Local Prefix Sub-TLV?
 
  Regards,
  Rémi

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
&nbsp; Hi CCAMP,
<br>
<br>
&nbsp; One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt.
<br>
&nbsp; This draft defines a new Node-Attribute sub-TLV (Local TE Router-ID
sub-TLV) as "optional sub-TLV for scoping reachability per TE
Router-ID".
<br>
&nbsp; How does this scoping occur when a router advertises reachability
information on behalf of multiple TE Router IDs?
<br>
&nbsp; Should a Local TE Router-ID sub-TLV be encoded <b
 class="moz-txt-star"><span class="moz-txt-tag">*</span>before<span
 class="moz-txt-tag">*</span></b> each Node IPv4/IPv6 Local Prefix
Sub-TLV?
<br>
&nbsp;
<br>
&nbsp; Regards,
<br>
&nbsp; R&eacute;mi
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>

--------------060609040003040409050506--

Envelope-to: [email-masked]
Delivery-date: Mon, 13 Apr 2009 17:53:27 +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: Protocol Action: 'RSVP Extensions for Path Key Support'  to Proposed Standard 
Message-Id: <[email-masked]>
Date: Mon, 13 Apr 2009 10:49:20 -0700 (PDT)

The IESG has approved the following document:

- 'RSVP Extensions for Path Key Support '
   <draft-ietf-ccamp-path-key-ero-04.txt> as a Proposed Standard

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

The IESG contact persons are Ross Callon and Adrian Farrel.

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

Technical Summary

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

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

   This document describes how to carry Path Key Subobjects in the
   Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs)
   and Record Route Object (RROs) so as to facilitate confidentiality in
   the signaling of inter-domain TE LSPs.

Working Group Summary

   Good consensus reported (see PROTO writeup by Deborah Brungard). 
   The draft was reviewed in last call by the CCAMP and PCE working
   groups, as well as IETF last call. 

   A last-minute question was raised on the number of bits assigned
   to the path key ID (should 16 be extended to 32). This was resolved
   in discussions on the PCE mailing list, and it was decided to leave
   it at 16 consistent with draft-ietf-pce-path-key-05.txt.

Document Quality

   There are several interoperable implementations of 
   draft-ietf-pce-path-key-05.txt. These implementations are of 
   no value without the extensions defined in this draft (since a
   computed path is of no value if you can't signal it).

   There is one known experimental implementation of the
   extensions defined in this draft.

Personnel

   Deborah Brungard is the Document Shepherd. Ross Callon is the
   responsible AD.

Delivery-date: Sat, 11 Apr 2009 06:53:11 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Date: Tue, 7 Apr 2009 15:15:02 -0700
CC: <[email-masked]>
Reply-To: <[email-masked]>

--NextPart
Content-Type: text/plain

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           : OSPFv2 Routing Protocols Extensions for ASON Routing
	Author(s)       : D. Papadimitriou
	Filename        : draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
	Pages           : 27
	Date            : 2009-04-07

The ITU-T has defined an architecture and requirements for operating
an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite
is designed to provide a control plane for a range of network
technologies including optical networks such as time division
multiplexing (TDM) networks including SONET/SDH and Optical Transport
Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of
ASON routing, and an evaluation of existing GMPLS routing protocols
are provided in other documents. This document defines to the OSPFv2
Link State Routing Protocol to meet the routing requirements for
routing in an ASON.

D.Papadimitriou et al. - Expires October 2009

 [page 1]

draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt

April 2009

Note that this work is scoped to the requirements and evaluation
expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
current when those documents were written. Future extensions of
revisions of this work may be necessary if the ITU-T Recommendations
are revised or if new requirements are introduced into a revision of
RFC 4258.

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

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

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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

--NextPart--

Delivery-date: Sat, 11 Apr 2009 06:53:03 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Date: Tue, 7 Apr 2009 15:15:02 -0700
CC: <[email-masked]>
Reply-To: <[email-masked]>

--NextPart
Content-Type: text/plain

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           : OSPFv2 Routing Protocols Extensions for ASON Routing
	Author(s)       : D. Papadimitriou
	Filename        : draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
	Pages           : 27
	Date            : 2009-04-07

The ITU-T has defined an architecture and requirements for operating
an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite
is designed to provide a control plane for a range of network
technologies including optical networks such as time division
multiplexing (TDM) networks including SONET/SDH and Optical Transport
Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of
ASON routing, and an evaluation of existing GMPLS routing protocols
are provided in other documents. This document defines to the OSPFv2
Link State Routing Protocol to meet the routing requirements for
routing in an ASON.

D.Papadimitriou et al. - Expires October 2009

 [page 1]

draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt

April 2009

Note that this work is scoped to the requirements and evaluation
expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
current when those documents were written. Future extensions of
revisions of this work may be necessary if the ITU-T Recommendations
are revised or if new requirements are introduced into a revision of
RFC 4258.

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

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

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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

--NextPart--

Delivery-date: Sat, 11 Apr 2009 06:52:52 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Date: Tue, 7 Apr 2009 15:15:02 -0700
CC: <[email-masked]>
Reply-To: <[email-masked]>

--NextPart
Content-Type: text/plain

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           : OSPFv2 Routing Protocols Extensions for ASON Routing
	Author(s)       : D. Papadimitriou
	Filename        : draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
	Pages           : 27
	Date            : 2009-04-07

The ITU-T has defined an architecture and requirements for operating
an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite
is designed to provide a control plane for a range of network
technologies including optical networks such as time division
multiplexing (TDM) networks including SONET/SDH and Optical Transport
Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of
ASON routing, and an evaluation of existing GMPLS routing protocols
are provided in other documents. This document defines to the OSPFv2
Link State Routing Protocol to meet the routing requirements for
routing in an ASON.

D.Papadimitriou et al. - Expires October 2009

 [page 1]

draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt

April 2009

Note that this work is scoped to the requirements and evaluation
expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
current when those documents were written. Future extensions of
revisions of this work may be necessary if the ITU-T Recommendations
are revised or if new requirements are introduced into a revision of
RFC 4258.

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

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

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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

--NextPart--

Delivery-date: Fri, 10 Apr 2009 17:33:46 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-07.txt 
Date: Fri, 10 Apr 2009 10:30:01 -0700 (PDT)

--NextPart

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

	Title		: Ethernet Traffic Parameters
	Author(s)	: D. Papadimitriou, I. Property
	Filename	: draft-ietf-ccamp-ethernet-traffic-parameters-07.txt
	Pages		: 13
	Date		: 2009-4-10
	
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-07.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-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Tue, 07 Apr 2009 22:36:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Date: Tue, 7 Apr 2009 23:32:41 +0100

FYI, Dimitri and I worked on this to address IETF last call comments and 
questions from IANA.

No changes of substance although the recommended/suggested IANA values did 
change a bit.

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 07, 2009 11:15 PM
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.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           : OSPFv2 Routing Protocols Extensions for ASON Routing
> Author(s)       : D. Papadimitriou
> Filename        : draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
> Pages           : 27
> Date            : 2009-04-07
>
> The ITU-T has defined an architecture and requirements for operating
> an Automatically Switched Optical Network (ASON).
>
> The Generalized Multiprotocol Label Switching (GMPLS) protocol suite
> is designed to provide a control plane for a range of network
> technologies including optical networks such as time division
> multiplexing (TDM) networks including SONET/SDH and Optical Transport
> Networks (OTNs), and lambda switching optical networks.
>
> The requirements for GMPLS routing to satisfy the requirements of
> ASON routing, and an evaluation of existing GMPLS routing protocols
> are provided in other documents. This document defines to the OSPFv2
> Link State Routing Protocol to meet the routing requirements for
> routing in an ASON.
>
>
> D.Papadimitriou et al. - Expires October 2009
>
>
>
>
>
> [page 1]
>
> draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
>
>
>
>
> April 2009
>
> Note that this work is scoped to the requirements and evaluation
> expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
> current when those documents were written. Future extensions of
> revisions of this work may be necessary if the ITU-T Recommendations
> are revised or if new requirements are introduced into a revision of
> RFC 4258.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-08.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
> 

Delivery-date: Tue, 07 Apr 2009 22:18:30 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Date: Tue,  7 Apr 2009 15:15:02 -0700 (PDT)

--NextPart

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

	Title           : OSPFv2 Routing Protocols Extensions for ASON Routing
	Author(s)       : D. Papadimitriou
	Filename        : draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
	Pages           : 27
	Date            : 2009-04-07

The ITU-T has defined an architecture and requirements for operating
an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite
is designed to provide a control plane for a range of network
technologies including optical networks such as time division
multiplexing (TDM) networks including SONET/SDH and Optical Transport
Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of
ASON routing, and an evaluation of existing GMPLS routing protocols
are provided in other documents. This document defines to the OSPFv2
Link State Routing Protocol to meet the routing requirements for
routing in an ASON.

D.Papadimitriou et al. - Expires October 2009

 [page 1]

draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt

April 2009

Note that this work is scoped to the requirements and evaluation
expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
current when those documents were written. Future extensions of
revisions of this work may be necessary if the ITU-T Recommendations
are revised or if new requirements are introduced into a revision of
RFC 4258.

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

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

--NextPart--

Delivery-date: Mon, 06 Apr 2009 19:39:19 +0000
Content-class: urn:content-classes:message
Subject: MPLS2009 - CALL FOR PRESENTATIONS
Date: Mon, 6 Apr 2009 13:49:40 -0400
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

The MPLS 2009 International Conference, the 12th Annual International
Conference on MPLS and Related Technologies, will be held October 25 -
28, 2009, in Washington, DC. The Technical Program Committee is
soliciting an abstract summarizing a proposed presentation representing
original/unpublished work covering cutting-edge topics. The deadline is
May 8, 2009.

Presentations addressing new technologies and operational experience are
being solicited from network equipment vendors, service/transport
providers, the research community, government agencies, and enterprise
users.=20

If you are interested in further information or want to submit a
presentation
abstract, please see the following URL:

http://www.isocore.com/mpls2009/call_for_papers/cfp.htm=20

In particular, these topics are of interest for CCAMP:
*	Migration to a unified MPLS/GMPLS architecture for packet
networks=20
*	Multi-layer networks and integration with non-packet
technologies
*	Non-MPLS based Carrier/Metro Ethernet services
*	GMPLS Applications (L1 VPNs, ASON, Optical Internetworking,
NNI/UNI)
*	GMPLS Experience in Research Networks
*	GMPLS control plane resilience, scaling and robustness
*	GMPLS interaction with routing protocols =20
Regards,

Deborah

Envelope-to: [email-masked]
Delivery-date: Fri, 03 Apr 2009 23:49:09 +0000
To: [email-masked], [email-masked]
Subject: RFC 5493 on Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Networ
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Fri,  3 Apr 2009 16:46:37 -0700 (PDT)

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

        RFC 5493

        Title:      Requirements for the Conversion between 
                    Permanent Connections and Switched Connections in 
                    a Generalized Multiprotocol Label Switching (GMPLS) 
                    Network
        Author:     D. Caviglia, D. Bramanti,
                    D. Li, D. McDysan
        Status:     Informational
        Date:       April 2009
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked], [email-masked]
        Pages:      11
        Characters: 21991
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-pc-and-sc-reqs-06.txt

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

>From a carrier perspective, the possibility of turning a permanent
connection (PC) into a soft permanent connection (SPC) and vice
versa, without actually affecting data plane traffic being carried
over it, is a valuable option.  In other terms, such operation can be
seen as a way of transferring the ownership and control of an
existing and in-use data plane connection between the management
plane and the control plane, leaving its data plane state untouched.

This memo sets out the requirements for such procedures within a
Generalized Multiprotocol Label Switching (GMPLS) network.  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: Fri, 03 Apr 2009 22:06:31 +0000
Date: Fri, 03 Apr 2009 18:05:19 -0400
From: Lou Berger <[email-masked]>
To: [email-masked]
CC: "Brungard, Deborah A, ALABS" <[email-masked]>,  Lou Berger <[email-masked]>
Subject: Poll on RFC4873 segment-recording-desired flag 

All,
	Nic Neate correctly pointed out in our last meeting that the 
segment-recording-desired flag identified in RFC4673 was never formally 
assigned a value.  The flag is identified to be carried in the 
SESSION_ATTRIBUTE object.  The current set of defined SESSION_ATTRIBUTE 
object flags is available under the IANA "Session Attribute Object 
Flags" registry, see http://www.iana.org/assignments/rsvp-te-parameters/.

The Chairs of the WG intend to work with IANA for correct this omission 
and get a value assigned for the flag.  We would like to ask that those 
who have implemented RFC 4873, to inform us of what value they are 
currently using.  Our intent is then to ask IANA for assignment of the 
most used (and available) value.  Your response may be public or private 
at your choosing.  Private responses should go to either or both WG 
chairs.  All responses will be summarized (without identifying 
information) on the CCAMP WG mail list.

If you have an RFC 4873 implementation we ask that you provide the 
following information:

1.  Organization:
1.1   Organization url(s):

2.  Status:
2.1     [ ] Development
2.2     [ ] Alpha
2.3     [ ] Beta
2.4     [ ] Product
2.5     [ ] Other (describe):

3. Object Used
3.1     [ ] SESSION_ATTRIBUTE object
3.1.1      [  ] C-type - 1   LSP_TUNNEL_RA
3.1.2      [  ] C-type - 7   LSP Tunnel
3.2     [ ] Other (describe):
3.2.1      [  ] C-type - describe):

4. Value used object
4.1   [   ] Value used in SESSION_ATTRIBUTE object flags field
4.2   [   ] Value used in other object or field (describe)

5. Privacy
      Yes    No
5.1  [  ]   [  ]  May we publish your identity and Organization?

Thank you,
Lou (and Deborah)

Delivery-date: Fri, 03 Apr 2009 21:21:34 +0000
Date: Fri, 03 Apr 2009 17:19:07 -0400
From: Lou Berger <[email-masked]>
To: [email-masked]
CC: "Brungard, Deborah A, ALABS" <[email-masked]>,  Lou Berger <[email-masked]>, Dan King <[email-masked]>
Subject: IETF 74 CCAMP draft minutes available

All,

Thanks in large part to the efforts of our new WG Secretary, Daniel 
King, the draft minutes from the CCAMP WG sessions in San Francisco have 
been uploaded and are available from:
	http://www.ietf.org/proceedings/09mar/minutes/ccamp.htm

Please take a look and send any comments or corrections you believe 
should be reflected in the minutes.  There are a few names that are 
missing, so help identifying your comments would be particularly 
appreciated.

Please provide comments by the end of next week (March 10) so that final 
minutes can be published the subsequent week.

Much thanks,
Lou (and Deborah)