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

[Nitin Bahadur <[e-mail]>]

Support.

On 3/19/09 5:48 AM, "Loa Andersson" <[e-mail]> 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


Envelope-to: [e-mail]
Delivery-date: Thu, 30 Apr 2009 21:31:09 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=SNVoXJ7tKu0YZYyXPFKawW+m40kYzfrn5rvpkezU91IbkE8+WtslDa/EEBAladpq/oIaolwaBtQXMoS6B0vYsv4wmZ8ZfIXdUZ+LgTtgbxNVf4GqiGsidWaajCGTaoR8;
Message-ID: <[e-mail]>
Date: Thu, 30 Apr 2009 17:29:36 -0400
From: Lou Berger <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail],  [e-mail], [e-mail], [e-mail],  [e-mail], [e-mail], [e-mail]
CC: [e-mail]
Subject: Re: Working group last call: draft-ietf-ccamp-lsp-dppm-05
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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



Envelope-to: [e-mail]
Delivery-date: Thu, 30 Apr 2009 20:58:45 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Fg3ogovMv7O867OsPmQmUDtCsM9kVhvaGb17Xq4NyOxLTa+0jIyWgwM9hY9a6bxJsNsGTFliiHlWUosiXTxnEOQx7gy/t36WySNnTdEZ+84jOqkZo5xIIhkTEf6jFt0w;
Message-ID: <[e-mail]>
Date: Thu, 30 Apr 2009 16:57:49 -0400
From: Lou Berger <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail],  [e-mail]
CC: [e-mail]
Subject: Re: Working group last call: draft-ietf-ccamp-gmpls-ted-mib-05
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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



Envelope-to: [e-mail]
Delivery-date: Thu, 30 Apr 2009 20:29:41 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=l9gdFCUwAkdU0bEzQj+kVS4snIEk8DMrgADcSPuDy4zV2rvhKE1DkQHVCUkThEp392+aPIPILzEdYohNfb4RlZlsARVvbE9Ol6g1QOUrZqtp9eWZLnY2IAwzq5o7Muzm;
Message-ID: <[e-mail]>
Date: Thu, 30 Apr 2009 16:27:01 -0400
From: Lou Berger <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2
MIME-Version: 1.0
To: Dan Li <[e-mail]>, Xu Huiying <[e-mail]>,  [e-mail],  "Bardalai, Snigdho" <[e-mail]>, MEURIC Julien RD-CORE-LAN <[e-mail]>,  "Diego Caviglia (GA/ERI)" <[e-mail]>
CC: [e-mail]
Subject: Re: Working group last call: draft-ietf-ccamp-confirm-data-channel-status-02
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Fri, 24 Apr 2009 11:14:10 +0000
Message-ID: <[e-mail]>
Date: Fri, 24 Apr 2009 13:12:15 +0200
From: Martin Vigoureux <[e-mail]>
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: IETF 74 - MPLS WG minutes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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



Envelope-to: [e-mail]
Delivery-date: Fri, 24 Apr 2009 06:08:02 +0000
Date: Fri, 24 Apr 2009 14:01:02 +0800
From: Fatai Zhang <[e-mail]>
Subject: Re: Generalizing WSON information...
To: Diego Caviglia <[e-mail]>, Greg Bernstein <[e-mail]>, [e-mail]
Cc: [e-mail]
Message-id: <023101c9c4a2$0c174f10$[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_OBVJCiL4l7SrdBfDYAhm1g)"

This is a multi-part message in MIME format.

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

SGkgYWxsLA0KDQpWZXJ5IGludGVyZXN0aW5nLg0KDQpGb3IgdGhlIHJlYWwgaW1wbGVtZW50YXRp
b25zLCBJIHRoaW5rIHdlIGhhdmUgdG8gbWVldCB0aGUgc2NlbmFyaW9zIHRoYXQgTVMtU1BSaW5n
IGlzIHVzZWQgaW4gR01QTFMgbmV0d29ya3MsIGJlY2F1c2UgdGhlIGRpZmZlcmVudCAgc2Vydmlj
ZXMgbmVlZCBkaWZmZXJlbnQgUW9QLiBUaGVyZWZvcmUsIGhvdyB0byBkZWFsIHdpdGggdGhlIGlz
c3VlcyBhYm91dCB0aGUgaW50ZXJ3b3JraW5nIGJldHdlZW4gR01QTFMgUiZQIGFuZCBNUy1TUFJp
bmcgcHJvdGVjdGlvbiBpcyB2ZXJ5IGltcG9ydGFudCwgZS5nLiwgdGltZS1zbG90IGNvbnRpbnVp
dHkgYW5kIEdNUExTIGNvbnRyb2wgcGxhbmUgc2hvdWxkIGtub3cgd2hlbiB0byB0cmlnZ2VyIHJl
Y292ZXJ5IG9yIG5vdCBhcyBzb29uIGFzIHBvc3NpYmxlIChmb3IgZXhhbXBsZSwgR01QTFMgY29u
dHJvbCBwbGFuZSBzaG91bGQgbm90IHRyaWdnZXIgcmVjb3Zlcnkgd2hlbiBNUy1TUFJpbmcgaGFz
IHRoZSBwcm90ZWN0aW9uIGNhcGFiaWxpdHksIG9uIHRoZSBvdGhlciBoYW5kICxHTVBMUyBzaG91
bGQgdHJpZ2dlciByZWNvdmVyeSBBU0FQIHdoZW4gdGhlcmUgaXMgbm8gcHJvdGVjdGlvbiBjYXBh
YmlsaXR5IGZvciBNUy1TUFJpbmcpLg0KDQpJIGFncmVlIHdpdGggRGllZ28gdGhhdCB3ZSBzaG91
bGQgcmVzb2x2ZSB0aGVzZSBpc3N1ZXMgZnJvbSB0aGUgR01QTFMvQ0NBTVAgcGVyc3BlY3RpdmUu
DQoNCg0KDQpUaGFua3MNCg0KRmF0YWkNCiANCkFkdmFuY2VkIFRlY2hub2xvZ3kgRGVwYXJ0bWVu
dA0KV2lyZWxpbmUgTmV0d29ya2luZyBCdXNpbmVzcyBVbml0DQpIdWF3ZWkgVGVjaG5vbG9naWVz
IENvLiwgTFRELg0KSHVhd2VpIEJhc2UsIEJhbnRpYW4sIExvbmdnYW5nLA0KU2hlbnpoZW4gNTE4
MTI5IFAuUi5DaGluYQ0KVGVsOiArODYtNzU1LTI4OTcyOTEyDQpGYXg6ICs4Ni03NTUtMjg5NzI5
MzUNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogRGllZ28gQ2F2aWds
aWEgDQogIFRvOiBHcmVnIEJlcm5zdGVpbiA7IGp1bGllbi5tZXVyaWNAb3JhbmdlLWZ0Z3JvdXAu
Y29tIA0KICBDYzogY2NhbXBAb3BzLmlldGYub3JnIA0KICBTZW50OiBUaHVyc2RheSwgQXByaWwg
MTYsIDIwMDkgMzo0MyBQTQ0KICBTdWJqZWN0OiBSRTogR2VuZXJhbGl6aW5nIFdTT04gaW5mb3Jt
YXRpb24uLi4NCg0KDQogIEhpIGFsbCwNCiAgICAgICAgICBJIHRoaW5rIHRoYXQgdGhpcyBpcyBh
biBpbnRlcmVzdGluZyB0b3BpYyB0byBtb3ZlIG9uLCBtYXkgYmUgdGhpcyB0aW1lIHdlIGNhbiBz
b2x2ZSB0aGUgaXNzdWUgb2YgTVMtU1BSaW5nIGludGVyd29ya2luZyB3aXRoIEdNUExTIGNvbnRy
b2wgcGxhbmUgdGhhdCB3ZSB3ZXJlIGFibGUgdG8gc29sdmUgc29tZSB0aW1lcyBhZ28uDQoNCiAg
TWF5IGJlIHdlIGNhbiByZXN1bWUgdGhlIElEIGFib3V0IHRoZSBNUy1TUFJpbmcgd2UgZGlkIHNv
bWUgdGltZSBhZ28gYW5kIHRyeSB0byBlbGFib3JhdGUgYSBnZW5lcmFsaXphdGlvbi4NCg0KICBC
Ug0KDQogIERpZWdvDQoNCiAgIA0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCiAgRGllZ28gQ2F2aWdsaWENCiAgU3RyYXRlZ2ljIFByb2R1Y3QgTWFuYWdlcg0K
ICBCcm9hZGJhbmQgTmV0d29ya3MsIFBMIEJyb2FkYmFuZCBPcHRpY2FsIE5ldHdvcmsgDQogIEVy
aWNzc29uIFRlbGVjb211bmljYXppb25pIFMucC5BLiAoVEVJKQ0KICBWaWEgQS4gTmVncm9uZSAx
L0EgICAgICAgICAgICAgICAgICAgICAgICAgICBPZmZpY2U6ICArMzkgMDEwIDYwMCAzNzM2DQog
IDE2MTUzLCBHZW5vdmEsIEl0YWx5ICAgICAgICAgICAgICAgICAgICAgICAgICBGYXg6ICszOSAw
MTAgNjAwIDM1NzcNCiAgQmxvY2sgRSBMZXZlbCA0ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIE1vYmlsZTogKzM5IDMzNSA3MTgxNzYyDQogIHd3dy5lcmljc3Nvbi5jb20gICAgICAg
ICAgICAgICAgICAgICAgIGRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbQ0KICBUaGlzIGNvbW11
bmljYXRpb24gaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRy
ZXNzZWUocykuIEFueSB1bmF1dGhvcml6ZWQgcmV2aWV3LCB1c2UsIGRpc2Nsb3N1cmUgb3IgZGlz
dHJpYnV0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlvdSBiZWxpZXZlIHRoaXMgbWVzc2FnZSBoYXMg
YmVlbiBzZW50IHRvIHlvdSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJl
cGx5aW5nIHRvIHRoaXMgdHJhbnNtaXNzaW9uIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2Ugd2l0aG91
dCBkaXNjbG9zaW5nIGl0LiBUaGFuayB5b3UuDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCg0KICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogID4gRnJvbTogb3du
ZXItY2NhbXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXSBP
biBCZWhhbGYNCiAgPiBPZiBHcmVnIEJlcm5zdGVpbg0KICA+IFNlbnQ6IG1lcmNvbGVk7CAxNSBh
cHJpbGUgMjAwOSAxOS4wMg0KICA+IFRvOiBqdWxpZW4ubWV1cmljQG9yYW5nZS1mdGdyb3VwLmNv
bQ0KICA+IENjOiBjY2FtcEBvcHMuaWV0Zi5vcmcNCiAgPiBTdWJqZWN0OiBSZTogR2VuZXJhbGl6
aW5nIFdTT04gaW5mb3JtYXRpb24uLi4NCiAgPiANCiAgPiBIaSBKdWxpZW4sIGludGVyZXN0aW5n
IHBvaW50LiBJdCBkaWQgc2VlbSBsaWtlIG9sZGVyIFNESCBlcXVpcG1lbnQgZGlkDQogID4gaGF2
ZSBhICJ0aW1lLXNsb3QgY29udGludWl0eSBjb25zdHJhaW50IiwgYnV0IEkgbmV2ZXIgZGlyZWN0
bHkgZGVhbHQNCiAgPiB3aXRoIHRob3NlIHN5c3RlbXMuIFRoZXJlIHdhcyBzb21lIHdvcmsgYSB3
aGlsZSBhZ28gb24gTVMtU1BSaW5nIChEaWVnbz8pLg0KICA+IE1heWJlIHdlIG5lZWQgdG8gdGhp
bmsgdXAgYSBsZXZlbCwgYXMgeW91IHNhaWQgaW4gdGhlIHVzdWFsIEdNUExTLCBNUExTDQogID4g
Y2FzZXMgZnVsbCBsYWJlbCBzd2FwcGluZyBpcyBhIHR5cGljYWwgY2FwYWJpbGl0eS4gU2hvdWxk
IHdlIGJlIGV4cGxpY2l0DQogID4gaW4gdGhlIFdTT04gY2FzZSAobWF5YmUgd2l0aCB0aGUgY29u
bmVjdGl2aXR5IG1hdHJpeCkgaW4gaW5kaWNhdGluZyB0aGF0DQogID4gdGhpcyBtYXkgb3IgbWF5
IG5vdCBiZSB0aGUgY2FzZT8gUmlnaHQgbm93IHdlIGFyZSBiZWluZyBpbXBsaWNpdCBhYm91dA0K
ICA+IHRoaXMgbGFjayBvZiB3YXZlbGVuZ3RoIChsYWJlbCkgY29udmVyc2lvbiBjYXBhYmlsaXR5
Lg0KICA+IA0KICA+IFRoZSBub3Rpb24gb2YgdGhlIHNoYXJlZCB3YXZlbGVuZ3RoIGNvbnZlcnRl
ciBwb29scyBhbmQgdGhlIGFjY29tcGFueWluZw0KICA+IGRldGFpbHMgc2VlbSB2ZXJ5IFdTT04g
c3BlY2lmaWMuIEJ1dCB0aGUgZmFjdCB0aGF0IGEgc3dpdGNoIG9yIG11eCBjYW4ndA0KICA+IHBl
cmZvcm0gbGFiZWwgZXhjaGFuZ2Ugc2VlbXMgYSBmYWlybHkgZ2VuZXJhbCBub3Rpb24gdGhhdCB3
ZSBjb3VsZCBncm91cA0KICA+IHdpdGggb3RoZXIgZ2VuZXJhbGl6YWJsZSBpbmZvcm1hdGlvbi4u
Lg0KICA+IA0KICA+IEJlc3QgUmVnYXJkcw0KICA+IA0KICA+IEdyZWcNCiAgPiANCiAgPiBqdWxp
ZW4ubWV1cmljQG9yYW5nZS1mdGdyb3VwLmNvbSB3cm90ZToNCiAgPiA+IEhpIEdyZWcuDQogID4g
Pg0KICA+ID4gSnVzdCBhIHNtYWxsIGNvbW1lbnQgb24gV2F2ZWxlbmd0aCBDb252ZXJ0ZXIgUG9v
bCBpbiBzZWN0aW9uIDMuMi4gSW4NCiAgPiBzb21lIG90aGVyIEdNUExTIGNvbnRleHRzLCB0aGlz
IG1heSBiZSBtb2RlbGxlZCBhcyBhIGxhYmVsIHN3YXBwaW5nDQogID4gY2FwYWJpbGl0eSwgd2hp
Y2ggaXMgYSBjb21tb24gZW5vdWdoIHRvIGJlIGNvbnNpZGVyZWQgYXMgIkdlbmVyYWxpemFibGUi
DQogID4gKGl0J3MgZXZlbiBhIHR5cGljYWwgY2FzZSB0aGF0IGJlY29tZXMgYW4gZXhjZXB0aW9u
IGR1ZSB0byBvdXIgbGFiZWwNCiAgPiBjb250aW51aXR5IGNvbnN0cmFpbnQpLiBIb3dldmVyLCBh
cyBmb3Igc2V2ZXJhbCBvdGhlciBwYXJhbWV0ZXJzLCBJIGRvbid0DQogID4gdGhpbmsgdGhlcmUg
aXMgYW4gYWN0dWFsIG5lZWQgZm9yIGl0ICh0aGlzIGlzIGFscmVhZHkgdGhlIGRlZmF1bHQpOyBi
dXQNCiAgPiBtYXliZSB3ZSBjb3VsZCBpbWFnaW5lIHNvbWUgTVMtU1BSaW5nIG9wZXJhdGlvbnMg
aW4gU09ORVQvU0RILg0KICA+ID4NCiAgPiA+IFJlZ2FyZHMsDQogID4gPg0KICA+ID4gSnVsaWVu
DQogID4gPg0KICA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgPiA+IEZyb206IG93
bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZ10g
T24NCiAgPiBCZWhhbGYgT2YgR3JlZyBCZXJuc3RlaW4NCiAgPiA+IFNlbnQ6IFR1ZXNkYXksIEFw
cmlsIDE0LCAyMDA5IDY6MzIgUE0NCiAgPiA+IFRvOiBjY2FtcA0KICA+ID4gU3ViamVjdDogR2Vu
ZXJhbGl6aW5nIFdTT04gaW5mb3JtYXRpb24uLi4NCiAgPiA+DQogID4gPiBIZWxsbyBmZWxsb3cg
Q0NBTVBlcnMsIGF0IHRoZSA3NHRoIElFVEYgbWVldGluZyBpbiBTYW4gRnJhbmNpc2NvIHRoZQ0K
ICA+ID4gcXVlc3Rpb24NCiAgPiA+IGNhbWUgdXAgYXMgdG8gd2hhdCBpZiBhbnkgb2YgdGhlIFdT
T04gcGF0aCBjb21wdXRhdGlvbiBpbmZvcm1hdGlvbiBtb2RlbA0KICA+ID4gd291bGQNCiAgPiA+
IGJlIHVzZWZ1bCBpbiBvdGhlciB0ZWNobm9sb2dpZXMuIEJlbG93IGlzIGEgZmlyc3QgYXR0ZW1w
dCBhdCBzdWNoIGFuDQogID4gPiBhc3Nlc21lbnQNCiAgPiA+IGJhc2VkIG9uIHRoZSBjdXJyZW50
IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1jY2FtcC1yd2EtaW5mby0wMi50eHQuDQogID4gPiBFeGlz
dGluZyBHTVBMUw0KICA+ID4gc3RhbmRhcmQgaW5mb3JtYXRpb24gaXMgbm90IGluY2x1ZGVkLg0K
ICA+ID4NCiAgPiA+ICBGcm9tIHNlY3Rpb24gMy4yIE5vZGUgSW5mb3JtYXRpb246DQogID4gPg0K
ICA+ID4gU3dpdGNoZWQgQ29ubmVjdGl2aXR5IE1hdHJpeDogR2VuZXJhbGl6YWJsZTpZZXMuIFRo
aXMgY2FuIGJlIHVzZWQgdG8NCiAgPiA+IG1vZGVsIGFueQ0KICA+ID4gdHlwZSBvZiBhc3ltZXRy
aWNhbCBzd2l0Y2ggaW4gYW55IHRlY2hub2xvZ3kuIENhdmVhdDogQmVzaWRlcyBvcHRpY2FsIGlz
DQogID4gPiB0aGVyZQ0KICA+ID4gYW55IGN1cnJlbnQgcHJvZHVjdHMgdGhhdCBjYW4gbWFrZSB1
c2Ugb2YgdGhpcz8NCiAgPiA+DQogID4gPiBGaXhlZCBDb25uZWN0aXZpdHkgTWF0cml4OiBHZW5l
cmFsaXphYmxlOiBZZXMuIFRoaXMgY2FuIGJlIHVzZWQgdG8gbW9kZWwNCiAgPiA+IGZpeGVkDQog
ID4gPiBjb25uZWN0aXZpdHkgYmV0d2VlbiBwb3J0cy4gQ2F2ZWF0OiBJcyB0aGVyZSBhbnkgbmVl
ZCBvdXRzaWRlIG9wdGljYWw/DQogID4gPg0KICA+ID4gV2F2ZWxlbmd0aCBDb252ZXJ0ZXIgUG9v
bDogR2VuZXJhbGx5IHVzZWZ1bDogTm8uIFRoaXMgaXMgdmVyeQ0KICA+IGFwcGxpY2F0aW9uDQog
ID4gPiBzcGVjaWZpYyB0byBvcHRpY2FsIHN3aXRjaGluZyBzeXN0ZW1zLg0KICA+ID4NCiAgPiA+
ICBGcm9tIHNlY3Rpb24gMy4zIExpbmsgSW5mb3JtYXRpb246DQogID4gPg0KICA+ID4gU3dpdGNo
ZWQgYW5kIEZpeGVkIFBvcnQgV2F2ZWxlbmd0aCAobGFiZWwpIFJlc3RyaWN0aW9uczogR2VuZXJh
bGx5DQogID4gdXNlZnVsOiBJDQogID4gPiBkb24ndCB0aGluayBzbyBidXQgb3BlbiB0byBleGFt
cGxlcy4gVGhlc2UgY29uc3RyYWludHMgbXVzdCBiZSBzaGFyZWQgaW4NCiAgPiB0aGUNCiAgPiA+
IFdTT04gY2FzZSBmb3IgdHdvIHJlYXNvbnM6IChhKSB0aGUgd2F2ZWxlbmd0aCBjb250aW51aXR5
IGNvbnN0cmFpbnQNCiAgPiByZXF1aXJlcw0KICA+ID4gZ2xvYmFsIGxhYmVsIGFzc2lnbm1lbnQs
IChiKSBXU09OIGRldmljZXMgcHJlc2VudCBtYW55IGRpZmZlcmVudCB0eXBlcw0KICA+IG9mDQog
ID4gPiB3YXZlbGVuZ3RoIGNvbnN0cmFpbnRzLiBOb3RlIHRoYXQgd2l0aG91dCByZXF1aXJlbWVu
dCAoYSkgdGhlbiAoYikNCiAgPiA+IGRvZXNuJ3QgbmVlZA0KICA+ID4gdG8gYmUgc2hhcmVkIHNp
bmNlIGxvY2FsIGxhYmVsICh3YXZlbGVuZ3RoKSBhc3NpZ25tZW50IHdvdWxkIHN1ZmZpY2UuDQog
ID4gPg0KICA+ID4gIEZyb20gc2VjdGlvbiAzLjQgIER5bmFtaWMgTGluayBpbmZvcm1hdGlvbg0K
ICA+ID4NCiAgPiA+IEF2YWlsYWJsZSBXYXZlbGVuZ3RocyAobGFiZWxzKTogR2VuZXJhbGx5IHVz
ZWZ1bD8gV2UgbmVlZCBkZXRhaWxlZA0KICA+ID4gd2F2ZWxlbmd0aA0KICA+ID4gYXZhaWxhYmls
aXR5IGluZm9ybWF0aW9uIGR1ZSB0byB0aGUgd2F2ZWxlbmd0aCBjb250aW51aXR5IGNvbnN0cmFp
bnQuDQogID4gPiBXYXkgYmFjaw0KICA+ID4gaW4gdGhlIG9sZCBkYXlzIG1hbnkgb2YgdXMgaW1w
bGVtZW50ZWQgYml0IG1hcHMgdG8gdHJhY2sgU09ORVQvU0RIIHRpbWUNCiAgPiA+IHNsb3RzDQog
ID4gPiBidXQgdGhpcyBuZXZlciBtYWRlIGl0IGludG8gdGhlIHN0YW5kYXJkcy4gQW55IGludGVy
ZXN0IGluIHRoYXQgbm93Pw0KICA+IE90aGVyDQogID4gPiBleGFtcGxlcz8NCiAgPiA+DQogID4g
PiBTaGFyZWQgQmFja3VwIFdhdmVsZW5ndGhzIChsYWJlbHMpOiBTaW1pbGFyIHRvIHRoZSBhYm92
ZSBidXQgdXNlZCBpbg0KICA+ID4gZWZmaWNpZW50DQogID4gPiBzaGFyZWQgbWVzaCBiYWNrdXAg
cGF0aCBjb21wdXRhdGlvbi4NCiAgPiA+DQogID4gPiAgRnJvbSBzZWN0aW9uIDMuNSBEeW5hbWlj
IE5vZGUgSW5mb3JtYXRpb24NCiAgPiA+DQogID4gPiBXYXZlbGVuZ3RoIENvbnZlcnRlciBQb29s
IFN0YXR1czogTm90IGdlbmVyYWxseSBhcHBsaWNhYmxlLiBUb28NCiAgPiBhcHBsaWNhdGlvbg0K
ICA+ID4gc3BlY2lmaWMuDQogID4gPg0KICA+ID4gQ29tbWVudHMgYXBwcmVjaWF0ZWQNCiAgPiA+
DQogID4gPiBHcmVnDQogID4gPg0KICA+ID4NCiAgPiANCiAgPiAtLQ0KICA+ID09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICA+IERyIEdyZWcgQmVy
bnN0ZWluLCBHcm90dG8gTmV0d29ya2luZyAoNTEwKSA1NzMtMjIzNw0KICA+IA0KICA+IA0KDQo=

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

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M
IDYuMDAuMjkwMC4zNDkyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE
Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkhpIGFsbCw8
L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0K
PERJVj48Rk9OVCBmYWNlPUFyaWFsPlZlcnkgaW50ZXJlc3RpbmcuPC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B
cmlhbD5Gb3IgdGhlIHJlYWwgaW1wbGVtZW50YXRpb25zLCBJIHRoaW5rJm5ic3A7d2UmbmJzcDto
YXZlIHRvIA0KbWVldCB0aGUgc2NlbmFyaW9zIHRoYXQgTVMtU1BSaW5nIGlzIHVzZWQgaW4gR01Q
TFMgbmV0d29ya3MsIGJlY2F1c2UgDQp0aGUmbmJzcDtkaWZmZXJlbnQmbmJzcDsgc2VydmljZXMg
bmVlZCBkaWZmZXJlbnQgUW9QLiBUaGVyZWZvcmUsIGhvdyB0byBkZWFsIA0Kd2l0aCB0aGUgaXNz
dWVzIGFib3V0IHRoZSBpbnRlcndvcmtpbmcgYmV0d2VlbiBHTVBMUyBSJmFtcDtQIGFuZCBNUy1T
UFJpbmcgDQpwcm90ZWN0aW9uIGlzIHZlcnkgaW1wb3J0YW50LCBlLmcuLCB0aW1lLXNsb3QgY29u
dGludWl0eSBhbmQgR01QTFMgY29udHJvbCBwbGFuZSANCnNob3VsZCBrbm93Jm5ic3A7d2hlbiB0
byB0cmlnZ2VyIHJlY292ZXJ5IG9yIG5vdCBhcyBzb29uIGFzIHBvc3NpYmxlIChmb3IgDQpleGFt
cGxlLCBHTVBMUyBjb250cm9sIHBsYW5lIHNob3VsZCBub3QmbmJzcDt0cmlnZ2VyIHJlY292ZXJ5
IHdoZW4gTVMtU1BSaW5nIGhhcyANCnRoZSBwcm90ZWN0aW9uIGNhcGFiaWxpdHksIG9uIHRoZSBv
dGhlciBoYW5kICxHTVBMUyBzaG91bGQgdHJpZ2dlciByZWNvdmVyeSBBU0FQIA0Kd2hlbiB0aGVy
ZSBpcyBubyBwcm90ZWN0aW9uIGNhcGFiaWxpdHkgZm9yIE1TLVNQUmluZykuPC9GT05UPjwvRElW
Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg
ZmFjZT1BcmlhbD5JIGFncmVlIHdpdGggRGllZ28gdGhhdCB3ZSZuYnNwO3Nob3VsZCByZXNvbHZl
IHRoZXNlIA0KaXNzdWVzIGZyb20gdGhlIEdNUExTL0NDQU1QIHBlcnNwZWN0aXZlLjwvRk9OVD48
L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG
T05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs
PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9
QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5GYXRhaTxCUj4mbmJzcDs8QlI+QWR2YW5j
ZWQgVGVjaG5vbG9neSBEZXBhcnRtZW50PEJSPldpcmVsaW5lIE5ldHdvcmtpbmcgDQpCdXNpbmVz
cyBVbml0PEJSPkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMVEQuPEJSPkh1YXdlaSBCYXNlLCBC
YW50aWFuLCANCkxvbmdnYW5nLDxCUj5TaGVuemhlbiA1MTgxMjkgUC5SLkNoaW5hPEJSPlRlbDog
Kzg2LTc1NS0yODk3MjkxMjxCUj5GYXg6IA0KKzg2LTc1NS0yODk3MjkzNTwvRElWPg0KPEJMT0NL
UVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFS
R0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklH
SFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0t
LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5E
OiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2si
PjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29tIA0K
ICBocmVmPSJtYWlsdG86ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29tIj5EaWVnbyBDYXZpZ2xp
YTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48
Qj5Ubzo8L0I+IDxBIHRpdGxlPWdyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNvbSANCiAgaHJlZj0i
bWFpbHRvOmdyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNvbSI+R3JlZyBCZXJuc3RlaW48L0E+IDsg
PEEgDQogIHRpdGxlPWp1bGllbi5tZXVyaWNAb3JhbmdlLWZ0Z3JvdXAuY29tIA0KICBocmVmPSJt
YWlsdG86anVsaWVuLm1ldXJpY0BvcmFuZ2UtZnRncm91cC5jb20iPmp1bGllbi5tZXVyaWNAb3Jh
bmdlLWZ0Z3JvdXAuY29tPC9BPiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAm
IzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPWNjYW1wQG9wcy5pZXRmLm9yZyAN
CiAgaHJlZj0ibWFpbHRvOmNjYW1wQG9wcy5pZXRmLm9yZyI+Y2NhbXBAb3BzLmlldGYub3JnPC9B
PiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNl
bnQ6PC9CPiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMzo0MyBQTTwvRElWPg0KICA8RElWIHN0
eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJFOiBHZW5l
cmFsaXppbmcgV1NPTiANCiAgaW5mb3JtYXRpb24uLi48L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+
SGkgYWxsLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0
aGluayANCiAgdGhhdCB0aGlzIGlzIGFuIGludGVyZXN0aW5nIHRvcGljIHRvIG1vdmUgb24sIG1h
eSBiZSB0aGlzIHRpbWUgd2UgY2FuIHNvbHZlIA0KICB0aGUgaXNzdWUgb2YgTVMtU1BSaW5nIGlu
dGVyd29ya2luZyB3aXRoIEdNUExTIGNvbnRyb2wgcGxhbmUgdGhhdCB3ZSB3ZXJlIGFibGUgDQog
IHRvIHNvbHZlIHNvbWUgdGltZXMgYWdvLjxCUj48QlI+TWF5IGJlIHdlIGNhbiByZXN1bWUgdGhl
IElEIGFib3V0IHRoZSANCiAgTVMtU1BSaW5nIHdlIGRpZCBzb21lIHRpbWUgYWdvIGFuZCB0cnkg
dG8gZWxhYm9yYXRlIGEgDQogIGdlbmVyYWxpemF0aW9uLjxCUj48QlI+QlI8QlI+PEJSPkRpZWdv
PEJSPjxCUj4mbmJzcDs8QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPEJSPkRpZWdvIA0KICBDYXZpZ2xpYTxCUj5TdHJhdGVnaWMgUHJvZHVjdCBNYW5hZ2VyPEJS
PkJyb2FkYmFuZCBOZXR3b3JrcywgUEwgQnJvYWRiYW5kIA0KICBPcHRpY2FsIE5ldHdvcmsgPEJS
PkVyaWNzc29uIFRlbGVjb211bmljYXppb25pIFMucC5BLiAoVEVJKTxCUj5WaWEgQS4gTmVncm9u
ZSANCiAgMS9BJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBP
ZmZpY2U6Jm5ic3A7ICszOSAwMTAgNjAwIDM3MzY8QlI+MTYxNTMsIEdlbm92YSwgDQogIEl0YWx5
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBGYXg6ICszOSAwMTAgNjAw
IDM1Nzc8QlI+QmxvY2sgRSBMZXZlbCANCiAgNCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN
CiAgTW9iaWxlOiArMzkgMzM1IDcxODE3NjI8QlI+PEEgDQogIGhyZWY9Imh0dHA6Ly93d3cuZXJp
Y3Nzb24uY29tIj53d3cuZXJpY3Nzb24uY29tPC9BPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEEg
DQogIGhyZWY9Im1haWx0bzpkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb20iPmRpZWdvLmNhdmln
bGlhQGVyaWNzc29uLmNvbTwvQT48QlI+VGhpcyANCiAgY29tbXVuaWNhdGlvbiBpcyBjb25maWRl
bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gQW55IA0KICB1
bmF1dGhvcml6ZWQgcmV2aWV3LCB1c2UsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIGlzIHBy
b2hpYml0ZWQuIElmIHlvdSANCiAgYmVsaWV2ZSB0aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2VudCB0
byB5b3UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciANCiAgYnkgcmVwbHlpbmcg
dG8gdGhpcyB0cmFuc21pc3Npb24gYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSB3aXRob3V0IGRpc2Ns
b3NpbmcgaXQuIA0KICBUaGFuayB5b3UuPEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPEJSPjxCUj48QlI+Jmd0OyAtLS0tLU9yaWdpbmFsIA0KICBNZXNzYWdlLS0tLS08QlI+Jmd0
OyBGcm9tOiA8QSANCiAgaHJlZj0ibWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyI+b3du
ZXItY2NhbXBAb3BzLmlldGYub3JnPC9BPiANCiAgW21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0
Zi5vcmddIE9uIEJlaGFsZjxCUj4mZ3Q7IE9mIEdyZWcgQmVybnN0ZWluPEJSPiZndDsgDQogIFNl
bnQ6IG1lcmNvbGVk7CAxNSBhcHJpbGUgMjAwOSAxOS4wMjxCUj4mZ3Q7IFRvOiA8QSANCiAgaHJl
Zj0ibWFpbHRvOmp1bGllbi5tZXVyaWNAb3JhbmdlLWZ0Z3JvdXAuY29tIj5qdWxpZW4ubWV1cmlj
QG9yYW5nZS1mdGdyb3VwLmNvbTwvQT48QlI+Jmd0OyANCiAgQ2M6IDxBIGhyZWY9Im1haWx0bzpj
Y2FtcEBvcHMuaWV0Zi5vcmciPmNjYW1wQG9wcy5pZXRmLm9yZzwvQT48QlI+Jmd0OyANCiAgU3Vi
amVjdDogUmU6IEdlbmVyYWxpemluZyBXU09OIGluZm9ybWF0aW9uLi4uPEJSPiZndDsgPEJSPiZn
dDsgSGkgSnVsaWVuLCANCiAgaW50ZXJlc3RpbmcgcG9pbnQuIEl0IGRpZCBzZWVtIGxpa2Ugb2xk
ZXIgU0RIIGVxdWlwbWVudCBkaWQ8QlI+Jmd0OyBoYXZlIGEgDQogICJ0aW1lLXNsb3QgY29udGlu
dWl0eSBjb25zdHJhaW50IiwgYnV0IEkgbmV2ZXIgZGlyZWN0bHkgZGVhbHQ8QlI+Jmd0OyB3aXRo
IA0KICB0aG9zZSBzeXN0ZW1zLiBUaGVyZSB3YXMgc29tZSB3b3JrIGEgd2hpbGUgYWdvIG9uIE1T
LVNQUmluZyAoRGllZ28/KS48QlI+Jmd0OyANCiAgTWF5YmUgd2UgbmVlZCB0byB0aGluayB1cCBh
IGxldmVsLCBhcyB5b3Ugc2FpZCBpbiB0aGUgdXN1YWwgR01QTFMsIA0KICBNUExTPEJSPiZndDsg
Y2FzZXMgZnVsbCBsYWJlbCBzd2FwcGluZyBpcyBhIHR5cGljYWwgY2FwYWJpbGl0eS4gU2hvdWxk
IHdlIGJlIA0KICBleHBsaWNpdDxCUj4mZ3Q7IGluIHRoZSBXU09OIGNhc2UgKG1heWJlIHdpdGgg
dGhlIGNvbm5lY3Rpdml0eSBtYXRyaXgpIGluIA0KICBpbmRpY2F0aW5nIHRoYXQ8QlI+Jmd0OyB0
aGlzIG1heSBvciBtYXkgbm90IGJlIHRoZSBjYXNlPyBSaWdodCBub3cgd2UgYXJlIA0KICBiZWlu
ZyBpbXBsaWNpdCBhYm91dDxCUj4mZ3Q7IHRoaXMgbGFjayBvZiB3YXZlbGVuZ3RoIChsYWJlbCkg
Y29udmVyc2lvbiANCiAgY2FwYWJpbGl0eS48QlI+Jmd0OyA8QlI+Jmd0OyBUaGUgbm90aW9uIG9m
IHRoZSBzaGFyZWQgd2F2ZWxlbmd0aCBjb252ZXJ0ZXIgDQogIHBvb2xzIGFuZCB0aGUgYWNjb21w
YW55aW5nPEJSPiZndDsgZGV0YWlscyBzZWVtIHZlcnkgV1NPTiBzcGVjaWZpYy4gQnV0IHRoZSAN
CiAgZmFjdCB0aGF0IGEgc3dpdGNoIG9yIG11eCBjYW4ndDxCUj4mZ3Q7IHBlcmZvcm0gbGFiZWwg
ZXhjaGFuZ2Ugc2VlbXMgYSBmYWlybHkgDQogIGdlbmVyYWwgbm90aW9uIHRoYXQgd2UgY291bGQg
Z3JvdXA8QlI+Jmd0OyB3aXRoIG90aGVyIGdlbmVyYWxpemFibGUgDQogIGluZm9ybWF0aW9uLi4u
PEJSPiZndDsgPEJSPiZndDsgQmVzdCBSZWdhcmRzPEJSPiZndDsgPEJSPiZndDsgR3JlZzxCUj4m
Z3Q7IA0KICA8QlI+Jmd0OyA8QSANCiAgaHJlZj0ibWFpbHRvOmp1bGllbi5tZXVyaWNAb3Jhbmdl
LWZ0Z3JvdXAuY29tIj5qdWxpZW4ubWV1cmljQG9yYW5nZS1mdGdyb3VwLmNvbTwvQT4gDQogIHdy
b3RlOjxCUj4mZ3Q7ICZndDsgSGkgR3JlZy48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBKdXN0
IGEgc21hbGwgY29tbWVudCBvbiANCiAgV2F2ZWxlbmd0aCBDb252ZXJ0ZXIgUG9vbCBpbiBzZWN0
aW9uIDMuMi4gSW48QlI+Jmd0OyBzb21lIG90aGVyIEdNUExTIA0KICBjb250ZXh0cywgdGhpcyBt
YXkgYmUgbW9kZWxsZWQgYXMgYSBsYWJlbCBzd2FwcGluZzxCUj4mZ3Q7IGNhcGFiaWxpdHksIHdo
aWNoIA0KICBpcyBhIGNvbW1vbiBlbm91Z2ggdG8gYmUgY29uc2lkZXJlZCBhcyAiR2VuZXJhbGl6
YWJsZSI8QlI+Jmd0OyAoaXQncyBldmVuIGEgDQogIHR5cGljYWwgY2FzZSB0aGF0IGJlY29tZXMg
YW4gZXhjZXB0aW9uIGR1ZSB0byBvdXIgbGFiZWw8QlI+Jmd0OyBjb250aW51aXR5IA0KICBjb25z
dHJhaW50KS4gSG93ZXZlciwgYXMgZm9yIHNldmVyYWwgb3RoZXIgcGFyYW1ldGVycywgSSBkb24n
dDxCUj4mZ3Q7IHRoaW5rIA0KICB0aGVyZSBpcyBhbiBhY3R1YWwgbmVlZCBmb3IgaXQgKHRoaXMg
aXMgYWxyZWFkeSB0aGUgZGVmYXVsdCk7IGJ1dDxCUj4mZ3Q7IA0KICBtYXliZSB3ZSBjb3VsZCBp
bWFnaW5lIHNvbWUgTVMtU1BSaW5nIG9wZXJhdGlvbnMgaW4gU09ORVQvU0RILjxCUj4mZ3Q7IA0K
ICAmZ3Q7PEJSPiZndDsgJmd0OyBSZWdhcmRzLDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IEp1
bGllbjxCUj4mZ3Q7IA0KICAmZ3Q7PEJSPiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTxCUj4mZ3Q7ICZndDsgRnJvbTogPEEgDQogIGhyZWY9Im1haWx0bzpvd25lci1jY2FtcEBv
cHMuaWV0Zi5vcmciPm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvQT4gDQogIFttYWlsdG86b3du
ZXItY2NhbXBAb3BzLmlldGYub3JnXSBPbjxCUj4mZ3Q7IEJlaGFsZiBPZiBHcmVnIEJlcm5zdGVp
bjxCUj4mZ3Q7IA0KICAmZ3Q7IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE0LCAyMDA5IDY6MzIgUE08
QlI+Jmd0OyAmZ3Q7IFRvOiBjY2FtcDxCUj4mZ3Q7ICZndDsgDQogIFN1YmplY3Q6IEdlbmVyYWxp
emluZyBXU09OIGluZm9ybWF0aW9uLi4uPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSGVsbG8g
DQogIGZlbGxvdyBDQ0FNUGVycywgYXQgdGhlIDc0dGggSUVURiBtZWV0aW5nIGluIFNhbiBGcmFu
Y2lzY28gdGhlPEJSPiZndDsgJmd0OyANCiAgcXVlc3Rpb248QlI+Jmd0OyAmZ3Q7IGNhbWUgdXAg
YXMgdG8gd2hhdCBpZiBhbnkgb2YgdGhlIFdTT04gcGF0aCBjb21wdXRhdGlvbiANCiAgaW5mb3Jt
YXRpb24gbW9kZWw8QlI+Jmd0OyAmZ3Q7IHdvdWxkPEJSPiZndDsgJmd0OyBiZSB1c2VmdWwgaW4g
b3RoZXIgDQogIHRlY2hub2xvZ2llcy4gQmVsb3cgaXMgYSBmaXJzdCBhdHRlbXB0IGF0IHN1Y2gg
YW48QlI+Jmd0OyAmZ3Q7IA0KICBhc3Nlc21lbnQ8QlI+Jmd0OyAmZ3Q7IGJhc2VkIG9uIHRoZSBj
dXJyZW50IHZlcnNpb24gb2YgDQogIGRyYWZ0LWlldGYtY2NhbXAtcndhLWluZm8tMDIudHh0LjxC
Uj4mZ3Q7ICZndDsgRXhpc3RpbmcgR01QTFM8QlI+Jmd0OyAmZ3Q7IA0KICBzdGFuZGFyZCBpbmZv
cm1hdGlvbiBpcyBub3QgaW5jbHVkZWQuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsmbmJzcDsg
RnJvbSANCiAgc2VjdGlvbiAzLjIgTm9kZSBJbmZvcm1hdGlvbjo8QlI+Jmd0OyAmZ3Q7PEJSPiZn
dDsgJmd0OyBTd2l0Y2hlZCBDb25uZWN0aXZpdHkgDQogIE1hdHJpeDogR2VuZXJhbGl6YWJsZTpZ
ZXMuIFRoaXMgY2FuIGJlIHVzZWQgdG88QlI+Jmd0OyAmZ3Q7IG1vZGVsIGFueTxCUj4mZ3Q7IA0K
ICAmZ3Q7IHR5cGUgb2YgYXN5bWV0cmljYWwgc3dpdGNoIGluIGFueSB0ZWNobm9sb2d5LiBDYXZl
YXQ6IEJlc2lkZXMgb3B0aWNhbCANCiAgaXM8QlI+Jmd0OyAmZ3Q7IHRoZXJlPEJSPiZndDsgJmd0
OyBhbnkgY3VycmVudCBwcm9kdWN0cyB0aGF0IGNhbiBtYWtlIHVzZSBvZiANCiAgdGhpcz88QlI+
Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBGaXhlZCBDb25uZWN0aXZpdHkgTWF0cml4OiBHZW5lcmFs
aXphYmxlOiBZZXMuIA0KICBUaGlzIGNhbiBiZSB1c2VkIHRvIG1vZGVsPEJSPiZndDsgJmd0OyBm
aXhlZDxCUj4mZ3Q7ICZndDsgY29ubmVjdGl2aXR5IGJldHdlZW4gDQogIHBvcnRzLiBDYXZlYXQ6
IElzIHRoZXJlIGFueSBuZWVkIG91dHNpZGUgb3B0aWNhbD88QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg
Jmd0OyANCiAgV2F2ZWxlbmd0aCBDb252ZXJ0ZXIgUG9vbDogR2VuZXJhbGx5IHVzZWZ1bDogTm8u
IFRoaXMgaXMgdmVyeTxCUj4mZ3Q7IA0KICBhcHBsaWNhdGlvbjxCUj4mZ3Q7ICZndDsgc3BlY2lm
aWMgdG8gb3B0aWNhbCBzd2l0Y2hpbmcgc3lzdGVtcy48QlI+Jmd0OyANCiAgJmd0OzxCUj4mZ3Q7
ICZndDsmbmJzcDsgRnJvbSBzZWN0aW9uIDMuMyBMaW5rIEluZm9ybWF0aW9uOjxCUj4mZ3Q7IA0K
ICAmZ3Q7PEJSPiZndDsgJmd0OyBTd2l0Y2hlZCBhbmQgRml4ZWQgUG9ydCBXYXZlbGVuZ3RoIChs
YWJlbCkgUmVzdHJpY3Rpb25zOiANCiAgR2VuZXJhbGx5PEJSPiZndDsgdXNlZnVsOiBJPEJSPiZn
dDsgJmd0OyBkb24ndCB0aGluayBzbyBidXQgb3BlbiB0byBleGFtcGxlcy4gDQogIFRoZXNlIGNv
bnN0cmFpbnRzIG11c3QgYmUgc2hhcmVkIGluPEJSPiZndDsgdGhlPEJSPiZndDsgJmd0OyBXU09O
IGNhc2UgZm9yIHR3byANCiAgcmVhc29uczogKGEpIHRoZSB3YXZlbGVuZ3RoIGNvbnRpbnVpdHkg
Y29uc3RyYWludDxCUj4mZ3Q7IHJlcXVpcmVzPEJSPiZndDsgDQogICZndDsgZ2xvYmFsIGxhYmVs
IGFzc2lnbm1lbnQsIChiKSBXU09OIGRldmljZXMgcHJlc2VudCBtYW55IGRpZmZlcmVudCANCiAg
dHlwZXM8QlI+Jmd0OyBvZjxCUj4mZ3Q7ICZndDsgd2F2ZWxlbmd0aCBjb25zdHJhaW50cy4gTm90
ZSB0aGF0IHdpdGhvdXQgDQogIHJlcXVpcmVtZW50IChhKSB0aGVuIChiKTxCUj4mZ3Q7ICZndDsg
ZG9lc24ndCBuZWVkPEJSPiZndDsgJmd0OyB0byBiZSBzaGFyZWQgDQogIHNpbmNlIGxvY2FsIGxh
YmVsICh3YXZlbGVuZ3RoKSBhc3NpZ25tZW50IHdvdWxkIHN1ZmZpY2UuPEJSPiZndDsgJmd0OzxC
Uj4mZ3Q7IA0KICAmZ3Q7Jm5ic3A7IEZyb20gc2VjdGlvbiAzLjQmbmJzcDsgRHluYW1pYyBMaW5r
IGluZm9ybWF0aW9uPEJSPiZndDsgDQogICZndDs8QlI+Jmd0OyAmZ3Q7IEF2YWlsYWJsZSBXYXZl
bGVuZ3RocyAobGFiZWxzKTogR2VuZXJhbGx5IHVzZWZ1bD8gV2UgbmVlZCANCiAgZGV0YWlsZWQ8
QlI+Jmd0OyAmZ3Q7IHdhdmVsZW5ndGg8QlI+Jmd0OyAmZ3Q7IGF2YWlsYWJpbGl0eSBpbmZvcm1h
dGlvbiBkdWUgdG8gDQogIHRoZSB3YXZlbGVuZ3RoIGNvbnRpbnVpdHkgY29uc3RyYWludC48QlI+
Jmd0OyAmZ3Q7IFdheSBiYWNrPEJSPiZndDsgJmd0OyBpbiANCiAgdGhlIG9sZCBkYXlzIG1hbnkg
b2YgdXMgaW1wbGVtZW50ZWQgYml0IG1hcHMgdG8gdHJhY2sgU09ORVQvU0RIIHRpbWU8QlI+Jmd0
OyANCiAgJmd0OyBzbG90czxCUj4mZ3Q7ICZndDsgYnV0IHRoaXMgbmV2ZXIgbWFkZSBpdCBpbnRv
IHRoZSBzdGFuZGFyZHMuIEFueSANCiAgaW50ZXJlc3QgaW4gdGhhdCBub3c/PEJSPiZndDsgT3Ro
ZXI8QlI+Jmd0OyAmZ3Q7IGV4YW1wbGVzPzxCUj4mZ3Q7IA0KICAmZ3Q7PEJSPiZndDsgJmd0OyBT
aGFyZWQgQmFja3VwIFdhdmVsZW5ndGhzIChsYWJlbHMpOiBTaW1pbGFyIHRvIHRoZSBhYm92ZSBi
dXQgDQogIHVzZWQgaW48QlI+Jmd0OyAmZ3Q7IGVmZmljaWVudDxCUj4mZ3Q7ICZndDsgc2hhcmVk
IG1lc2ggYmFja3VwIHBhdGggDQogIGNvbXB1dGF0aW9uLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAm
Z3Q7Jm5ic3A7IEZyb20gc2VjdGlvbiAzLjUgRHluYW1pYyBOb2RlIA0KICBJbmZvcm1hdGlvbjxC
Uj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFdhdmVsZW5ndGggQ29udmVydGVyIFBvb2wgU3RhdHVz
OiBOb3QgDQogIGdlbmVyYWxseSBhcHBsaWNhYmxlLiBUb288QlI+Jmd0OyBhcHBsaWNhdGlvbjxC
Uj4mZ3Q7ICZndDsgc3BlY2lmaWMuPEJSPiZndDsgDQogICZndDs8QlI+Jmd0OyAmZ3Q7IENvbW1l
bnRzIGFwcHJlY2lhdGVkPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgR3JlZzxCUj4mZ3Q7IA0K
ICAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7IDxCUj4mZ3Q7IC0tPEJSPiZndDsgDQogID09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxCUj4mZ3Q7IERy
IEdyZWcgQmVybnN0ZWluLCANCiAgR3JvdHRvIE5ldHdvcmtpbmcgKDUxMCkgNTczLTIyMzc8QlI+
Jmd0OyA8QlI+Jmd0OyANCjxCUj48QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo=

--Boundary_(ID_OBVJCiL4l7SrdBfDYAhm1g)--



Envelope-to: [e-mail]
Delivery-date: Tue, 21 Apr 2009 18:27:14 +0000
Message-ID: <[e-mail]>
Date: Tue, 21 Apr 2009 11:23:45 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: ccamp <[e-mail]>
Subject: Updated WSON Impairments Framework Draft
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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





Envelope-to: [e-mail]
Delivery-date: Tue, 21 Apr 2009 13:17:46 +0000
From: Yechiel Rosengarten <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Tue, 21 Apr 2009 16:15:09 +0300
Subject: RE: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt 
Thread-Topic: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt 
Thread-Index: Aci5znz+u2xxeM60RmyR3fLjaArEpyrIc99A
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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:  [phone]
Fax: [phone]
e-mail: [e-mail]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf =
Of [e-mail]
Sent: Monday, May 19, 2008 7:30 PM
To: [e-mail]
Cc: [e-mail]
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.



Envelope-to: [e-mail]
Delivery-date: Fri, 17 Apr 2009 23:17:13 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-05.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
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:	<[e-mail]>

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Fri, 17 Apr 2009 23:03:33 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
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:	<[e-mail]>

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Fri, 17 Apr 2009 16:28:56 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=wTZRR8f1IaVp0fj91WmkuuVdtOoUvrn9l+b94twaBqOfMuyyfoqd0DRaansi2f5cYa772qyD1JRTjcRBB18tK5r/ARsmQDVINh9P+fdQe3R1pDnpq9deaYQvY8XXIinA;
Message-ID: <[e-mail]>
Date: Fri, 17 Apr 2009 12:25:56 -0400
From: Lou Berger <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: [e-mail]
Subject: Working group last call: draft-ietf-ccamp-gmpls-ted-mib-05
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.





Envelope-to: [e-mail]
Delivery-date: Fri, 17 Apr 2009 16:28:47 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=oDFwONU9rLs2sumLJX6iRSil3QpTu60LMrjYxvYSHtu17wJq19kSCeRd2DQQvRegIclob88pK8HePhAb0az9wOfTISSqu+UBUkG4DgQkYwDjjc6e8fbrdpof2VG3LiHE;
Message-ID: <[e-mail]>
Date: Fri, 17 Apr 2009 12:25:49 -0400
From: Lou Berger <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: [e-mail]
Subject: Working group last call: draft-ietf-ccamp-lsp-dppm-05
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.




Envelope-to: [e-mail]
Delivery-date: Fri, 17 Apr 2009 16:28:39 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ZYDMdEH52xTrCcEGvI8v7Iih1MiROBKGBdE00jb68ShgWEMg6IDW9m7mNuyZSt6ngFOIOLMPfeJFFajldDcLF94BF84fmjIbqMGo7XORsxi3a0grfX8wzxu3DVDwwLB2;
Message-ID: <[e-mail]>
Date: Fri, 17 Apr 2009 12:25:33 -0400
From: Lou Berger <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: [e-mail]
Subject: Working group last call: draft-ietf-ccamp-pc-spc-rsvpte-ext-02
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.



Envelope-to: [e-mail]
Delivery-date: Fri, 17 Apr 2009 16:28:33 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=g+yQtvdxlgeYZ07n9O10741r6iW1F/U8VLCuu6ow3VxDHk7/yNSrc/KecuJOzwk/jRQCiN0okR0S6My7FBmmDaX/MGH1ALKXUFxLQCxoxKFZsDOTGfH9FHodu0ZAehQz;
Message-ID: <[e-mail]>
Date: Fri, 17 Apr 2009 12:25:07 -0400
From: Lou Berger <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: [e-mail]
Subject: Working group last call: draft-ietf-ccamp-confirm-data-channel-status-02
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.





Envelope-to: [e-mail]
Delivery-date: Thu, 16 Apr 2009 16:45:15 +0000
Message-ID: <[e-mail]>
Date: Thu, 16 Apr 2009 09:44:18 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: ccamp <[e-mail]>
Subject: Formalizing WSON a bit with ITU-T definitions...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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





Envelope-to: [e-mail]
Delivery-date: Thu, 16 Apr 2009 16:29:05 +0000
Message-ID: <[e-mail]>
Date: Thu, 16 Apr 2009 09:28:05 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Diego Caviglia <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Generalizing WSON information...
Content-Type: multipart/alternative; boundary="------------080505090404050902050009"

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:  [phone]
> 16153, Genova, Italy                          Fax: [phone]
> Block E Level 4                                  Mobile: [phone]
> www.ericsson.com                       [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Greg Bernstein
>> Sent: mercoledì 15 aprile 2009 19.02
>> To: [e-mail]
>> Cc: [e-mail]
>> 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
>>
>> [e-mail] 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: [e-mail] [mailto:[e-mail]] 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 [phone]
>>
>>
>>     
>
>
>
>   

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



--------------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:[e-mail]"
 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:  [phone]
16153, Genova, Italy                          Fax: [phone]
Block E Level 4                                  Mobile: [phone]
<a class="moz-txt-link-abbreviated" href="http://www.ericsson.com">www.ericsson.com</a>                       <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</a> [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>] On Behalf
Of Greg Bernstein
Sent: mercoled&igrave; 15 aprile 2009 19.02
To: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</a> [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</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 [phone]


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


  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]

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

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



Envelope-to: [e-mail]
Delivery-date: Thu, 16 Apr 2009 16:20:44 +0000
From: "Sadler, Jonathan B." <[e-mail]>
To: Greg Bernstein <[e-mail]>, "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Thu, 16 Apr 2009 11:19:58 -0500
Subject: RE: Generalizing WSON information...
Thread-Topic: Generalizing WSON information...
Thread-Index: Acm97E0buGc0Z2txTvSRKRvbvJg4LwAwpecQ
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

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: [e-mail] [mailto:[e-mail]] On Behalf =
Of Greg Bernstein
Sent: Wednesday, April 15, 2009 12:02 PM
To: [e-mail]
Cc: [e-mail]
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

[e-mail] 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: [e-mail] [mailto:[e-mail]] 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 [phone]

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



Envelope-to: [e-mail]
Delivery-date: Thu, 16 Apr 2009 16:18:24 +0000
From: "Sadler, Jonathan B." <[e-mail]>
To: Greg Bernstein <[e-mail]>, "Drake, John E" <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 16 Apr 2009 11:17:39 -0500
Subject: RE: Generalizing WSON information...
Thread-Topic: Generalizing WSON information...
Thread-Index: Acm+rnRdZ3ySXdGrT9KhwQ/sbC4IBAAAFkOA
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

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: [e-mail] [mailto:[e-mail]] On Behalf =
Of Greg Bernstein
Sent: Thursday, April 16, 2009 11:11 AM
To: Drake, John E
Cc: [e-mail]; [e-mail]
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:[e-mail]]=20
>> Sent: Wednesday, April 15, 2009 10:02 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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
>>
>> [e-mail] 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: [e-mail] [mailto:[e-mail]] 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 [phone]
>>
>>
>>
>>
>>    =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 [phone]

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



Envelope-to: [e-mail]
Delivery-date: Thu, 16 Apr 2009 16:12:59 +0000
Message-ID: <[e-mail]>
Date: Thu, 16 Apr 2009 09:10:44 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Drake, John E" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Generalizing WSON information...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:[e-mail]] 
>> Sent: Wednesday, April 15, 2009 10:02 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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
>>
>> [e-mail] 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: [e-mail] [mailto:[e-mail]] 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 [phone]
>>
>>
>>
>>
>>     
>
>   

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





Envelope-to: [e-mail]
Delivery-date: Thu, 16 Apr 2009 07:52:20 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Generalizing WSON information...
Date: Thu, 16 Apr 2009 09:43:40 +0200
Message-ID: <[e-mail]>
Thread-Topic: Generalizing WSON information...
Thread-Index: Acm97JZfl/n0YxVCTI6wjKmIxYoldwAefvFA
From: "Diego Caviglia" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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:  [phone]
16153, Genova, Italy                          Fax: [phone]
Block E Level 4                                  Mobile: [phone]
www.ericsson.com                       [e-mail]
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: [e-mail] [mailto:[e-mail]] On =
Behalf
> Of Greg Bernstein
> Sent: mercoled=EC 15 aprile 2009 19.02
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail] 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: [e-mail] [mailto:[e-mail]] 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 [phone]
>=20
>=20




Envelope-to: [e-mail]
Delivery-date: Wed, 15 Apr 2009 18:04:16 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Generalizing WSON information...
Date: Wed, 15 Apr 2009 11:02:26 -0700
Message-ID: <[e-mail]>
Thread-Topic: Generalizing WSON information...
Thread-Index: Acm97TV6OcSfR77sQKCUChL1qlCGBAABcScg
From: "Drake, John E" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=20
> Sent: Wednesday, April 15, 2009 10:02 AM
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail] 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: [e-mail] [mailto:[e-mail]] 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 [phone]
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Apr 2009 17:32:35 +0000
Message-ID: <[e-mail]>
Date: Wed, 15 Apr 2009 19:31:31 +0200
From: Huub van Helvoort <[e-mail]>
Reply-To: [e-mail]
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Greg Bernstein <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Generalizing WSON information...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Apr 2009 17:03:22 +0000
Message-ID: <[e-mail]>
Date: Wed, 15 Apr 2009 10:01:41 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Generalizing WSON information...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

[e-mail] 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: [e-mail] [mailto:[e-mail]] 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 [phone]





Envelope-to: [e-mail]
Delivery-date: Wed, 15 Apr 2009 10:10:47 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Generalizing WSON information...
Date: Wed, 15 Apr 2009 12:08:17 +0200
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026065E7A23@ftrdmel2>
Thread-Topic: Generalizing WSON information...
Thread-Index: Acm9Hzo6wwYG+CCmQNeS3KGuV9plRAAj3pRQ
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>

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: [e-mail] [mailto:[e-mail]] 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 [phone]







Envelope-to: [e-mail]
Delivery-date: Tue, 14 Apr 2009 16:33:21 +0000
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 09:31:53 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: ccamp <[e-mail]>
Subject: Generalizing WSON information...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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





Envelope-to: [e-mail]
Delivery-date: Tue, 14 Apr 2009 15:00:43 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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
Message-ID: <[e-mail]>
Thread-Topic: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Thread-Index: Acm9DnIAHP66l4yrTNegoaLpKwMhEAAAGdtA
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Remi Theillaud" <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=20
	Sent: Tuesday, April 14, 2009 4:37 PM
	To: PAPADIMITRIOU Dimitri
	Cc: [e-mail]
	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 <[e-mail]> =
<mailto:[e-mail]>=20
	To: Remi Theillaud <[e-mail]> =
<mailto:[e-mail]>=20
	CC: [e-mail]
	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:[e-mail]]=20
			Sent: Tuesday, April 14, 2009 4:23 PM
			To: PAPADIMITRIOU Dimitri
			Cc: [e-mail]
			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 <[e-mail]> =
<mailto:[e-mail]>=20
			To: Remi Theillaud <[e-mail]> =
<mailto:[e-mail]> ,=20
			[e-mail]
			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: [e-mail]=20
				     =20

			[mailto:[e-mail]] On Behalf Of Remi Theillaud
			   =20

					Sent: Tuesday, April 14, 2009 3:43 PM
					To: [e-mail]
					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 : [phone]
			Fax : [phone]
			[e-mail]
			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 : [phone]
	Fax : [phone]
	[e-mail]
	www.marben-products.com =20
=09





Envelope-to: [e-mail]
Delivery-date: Tue, 14 Apr 2009 14:46:51 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Date: Tue, 14 Apr 2009 16:45:35 +0200
Message-ID: <[e-mail]>
Thread-Topic: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Thread-Index: Acm9DnIAHP66l4yrTNegoaLpKwMhEAAAGdtA
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Remi Theillaud" <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=20
	Sent: Tuesday, April 14, 2009 4:37 PM
	To: PAPADIMITRIOU Dimitri
	Cc: [e-mail]
	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 <[e-mail]> =
<mailto:[e-mail]>=20
	To: Remi Theillaud <[e-mail]> =
<mailto:[e-mail]>=20
	CC: [e-mail]
	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:[e-mail]]=20
			Sent: Tuesday, April 14, 2009 4:23 PM
			To: PAPADIMITRIOU Dimitri
			Cc: [e-mail]
			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 <[e-mail]> =
<mailto:[e-mail]>=20
			To: Remi Theillaud <[e-mail]> =
<mailto:[e-mail]> ,=20
			[e-mail]
			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: [e-mail]=20
				     =20

			[mailto:[e-mail]] On Behalf Of Remi Theillaud
			   =20

					Sent: Tuesday, April 14, 2009 3:43 PM
					To: [e-mail]
					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 : [phone]
			Fax : [phone]
			[e-mail]
			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 : [phone]
	Fax : [phone]
	[e-mail]
	www.marben-products.com =20
=09




Envelope-to: [e-mail]
Delivery-date: Tue, 14 Apr 2009 14:37:41 +0000
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 16:36:45 +0200
From: Remi Theillaud <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: PAPADIMITRIOU Dimitri <[e-mail]>
CC: [e-mail]
Subject: Re: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Content-Type: multipart/alternative; boundary="------------070102070704030100010406"

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 <[e-mail]>
To: Remi Theillaud <[e-mail]>
CC: [e-mail]
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:[e-mail]] 
>> Sent: Tuesday, April 14, 2009 4:23 PM
>> To: PAPADIMITRIOU Dimitri
>> Cc: [e-mail]
>> 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 <[e-mail]>
>> To: Remi Theillaud <[e-mail]>, 
>> [e-mail]
>> 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: [e-mail] 
>>>       
>> [mailto:[e-mail]] On Behalf Of Remi Theillaud
>>     
>>> 	Sent: Tuesday, April 14, 2009 3:43 PM
>>> 	To: [e-mail]
>>> 	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 : [phone]
>> Fax : [phone]
>> [e-mail]
>> www.marben-products.com  
>>
>>
>>     
>
>   

-- 

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

Rémi Theillaud
Senior Consultant

Marben Products
176 rue Jean Jaures
92800 Puteaux
France

Tel : [phone]
Fax : [phone]
[e-mail]
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:[e-mail]">&lt;[e-mail]&gt;</a><br>
To: Remi Theillaud <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a><br>
CC: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a><br>
Date: 14/04/2009 16:28<br>
<blockquote
 cite="mid:[e-mail]"
 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:[e-mail]">mailto:[e-mail]</a>] 
Sent: Tuesday, April 14, 2009 4:23 PM
To: PAPADIMITRIOU Dimitri
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</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:[e-mail]">&lt;[e-mail]&gt;</a>
To: Remi Theillaud <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>, 
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</a> 
      </pre>
    </blockquote>
    <pre wrap="">[<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</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:[e-mail]">[e-mail]</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 : [phone]
Fax : [phone]
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</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 : [phone]
Fax : [phone]
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
<a class="moz-txt-link-abbreviated" href="http://www.marben-products.com">www.marben-products.com</a>  
</pre>
</body>
</html>

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



Envelope-to: [e-mail]
Delivery-date: Tue, 14 Apr 2009 14:28:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Date: Tue, 14 Apr 2009 16:28:20 +0200
Message-ID: <[e-mail]>
Thread-Topic: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Thread-Index: Acm9DI5rJBkpuS2VR9+1KZv1jZj0TwAADf/g
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Remi Theillaud" <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=20
> Sent: Tuesday, April 14, 2009 4:23 PM
> To: PAPADIMITRIOU Dimitri
> Cc: [e-mail]
> 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 <[e-mail]>
> To: Remi Theillaud <[e-mail]>,=20
> [e-mail]
> 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: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Remi Theillaud
> > 	Sent: Tuesday, April 14, 2009 3:43 PM
> > 	To: [e-mail]
> > 	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 : [phone]
> Fax : [phone]
> [e-mail]
> www.marben-products.com =20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Tue, 14 Apr 2009 14:24:17 +0000
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 16:23:13 +0200
From: Remi Theillaud <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: PAPADIMITRIOU Dimitri <[e-mail]>
CC: [e-mail]
Subject: Re: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

   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 <[e-mail]>
To: Remi Theillaud <[e-mail]>, [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of Remi Theillaud
> 	Sent: Tuesday, April 14, 2009 3:43 PM
> 	To: [e-mail]
> 	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 : [phone]
Fax : [phone]
[e-mail]
www.marben-products.com  




Envelope-to: [e-mail]
Delivery-date: Tue, 14 Apr 2009 14:07:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Date: Tue, 14 Apr 2009 16:06:46 +0200
Message-ID: <[e-mail]>
Thread-Topic: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Thread-Index: Acm9CMFP0njNMNseSDqSZaqOI1zosQAALhwA
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Remi Theillaud" <[e-mail]>, <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Remi Theillaud
	Sent: Tuesday, April 14, 2009 3:43 PM
	To: [e-mail]
	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




Envelope-to: [e-mail]
Delivery-date: Tue, 14 Apr 2009 13:45:12 +0000
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 15:42:37 +0200
From: Remi Theillaud <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: [e-mail]
Subject: One question about draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Content-Type: multipart/alternative; boundary="------------060609040003040409050506"

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: [e-mail]
Delivery-date: Mon, 13 Apr 2009 17:53:27 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>,  ccamp mailing list <[e-mail]>,  ccamp chair <[e-mail]>
Subject: Protocol Action: 'RSVP Extensions for Path Key Support'  to Proposed Standard 
Message-Id: <[e-mail]>
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.




Envelope-to: [e-mail]
Delivery-date: Sat, 11 Apr 2009 06:53:11 +0000
From: <[e-mail]>
To: <[e-mail]>
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Content-Type: multipart/mixed; boundary="NextPart"
MIME-Version: 1.0
Message-ID: <[e-mail]>
Date: Tue, 7 Apr 2009 15:15:02 -0700
CC: <[e-mail]>
Reply-To: <[e-mail]>
Received-SPF: Pass (tk5-exgwy-e802.partners.extranet.microsoft.com: domain of [e-mail] designates 64.170.98.32 as permitted sender) receiver=tk5-exgwy-e802.partners.extranet.microsoft.com; client-ip=64.170.98.32; helo=mail143-tx2-R.bigfish.com;

--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: <[e-mail]>


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

_______________________________________________
I-D-Announce mailing list
[e-mail]
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--



Envelope-to: [e-mail]
Delivery-date: Sat, 11 Apr 2009 06:53:03 +0000
From: <[e-mail]>
To: <[e-mail]>
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Content-Type: multipart/mixed; boundary="NextPart"
MIME-Version: 1.0
Message-ID: <[e-mail]>
Date: Tue, 7 Apr 2009 15:15:02 -0700
CC: <[e-mail]>
Reply-To: <[e-mail]>
Received-SPF: Pass (tk5-exgwy-e802.partners.extranet.microsoft.com: domain of [e-mail] designates 64.170.98.32 as permitted sender) receiver=tk5-exgwy-e802.partners.extranet.microsoft.com; client-ip=64.170.98.32; helo=mail177-tx2-R.bigfish.com;

--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: <[e-mail]>


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

_______________________________________________
I-D-Announce mailing list
[e-mail]
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--



Envelope-to: [e-mail]
Delivery-date: Sat, 11 Apr 2009 06:52:52 +0000
From: <[e-mail]>
To: <[e-mail]>
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Content-Type: multipart/mixed; boundary="NextPart"
MIME-Version: 1.0
Message-ID: <[e-mail]>
Date: Tue, 7 Apr 2009 15:15:02 -0700
CC: <[e-mail]>
Reply-To: <[e-mail]>
Received-SPF: Pass (SVC-EXGWY-E802.partners.extranet.microsoft.com: domain of [e-mail] designates 64.170.98.32 as permitted sender) receiver=SVC-EXGWY-E802.partners.extranet.microsoft.com; client-ip=64.170.98.32; helo=mail141-tx2-R.bigfish.com;

--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: <[e-mail]>


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

_______________________________________________
I-D-Announce mailing list
[e-mail]
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--



Envelope-to: [e-mail]
Delivery-date: Fri, 10 Apr 2009 17:33:46 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
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:	<[e-mail]>

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Apr 2009 22:36:43 +0000
Message-ID: <CD66A4B12E854E79B8D8A858B12EC153@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Date: Tue, 7 Apr 2009 23:32:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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
> [e-mail]
> 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
> 




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Apr 2009 22:18:30 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
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:     <[e-mail]>

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Mon, 06 Apr 2009 19:39:19 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: MPLS2009 - CALL FOR PRESENTATIONS
Date: Mon, 6 Apr 2009 13:49:40 -0400
Message-ID: <[e-mail]>
Thread-Topic: MPLS2009 - CALL FOR PRESENTATIONS
Thread-Index: Acm24A+sdt8Wv6BcT9SAdUoM2aPNVQ==
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>

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: [e-mail]
Delivery-date: Fri, 03 Apr 2009 23:49:09 +0000
To: [e-mail], [e-mail]
Subject: RFC 5493 on Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Networ
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
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:    [e-mail], 
                    [e-mail], 
                    [e-mail], [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute





Envelope-to: [e-mail]
Delivery-date: Fri, 03 Apr 2009 22:06:31 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=s022N+c92UKdU74w/vFYH1YPw+fVVC3LMBJdRg6TdnEhiE+81rHQwSJjzLFHjzxnmUHElF/+CGT+huAvDSNoTwzbDnDKrImn1k1CR0qvzQ8vJe60TBVZY3mFtN24EeuO;
Message-ID: <[e-mail]>
Date: Fri, 03 Apr 2009 18:05:19 -0400
From: Lou Berger <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: [e-mail]
CC: "Brungard, Deborah A, ALABS" <[e-mail]>,  Lou Berger <[e-mail]>
Subject: Poll on RFC4873 segment-recording-desired flag 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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)



Envelope-to: [e-mail]
Delivery-date: Fri, 03 Apr 2009 21:21:34 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=XRzEASUnouMn8lSO/8PVmHjtXSg3VvXyDuk+iXYHhwRfpM5tKAfYSar3f71JNItgEjdk3p6bXB6Qcu6hHPn9SUpyfL2UrMCRn4qdHTyb4MP9Zb6NdPLsnppgdOKF1Ruv;
Message-ID: <[e-mail]>
Date: Fri, 03 Apr 2009 17:19:07 -0400
From: Lou Berger <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: [e-mail]
CC: "Brungard, Deborah A, ALABS" <[e-mail]>,  Lou Berger <[e-mail]>, Dan King <[e-mail]>
Subject: IETF 74 CCAMP draft minutes available
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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)