RFC 4972 on Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership

[[e-mail]]

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



        

        RFC 4972



        Title:      Routing Extensions for Discovery of 

                    Multiprotocol (MPLS) Label Switch Router (LSR) 

                    Traffic Engineering (TE) Mesh Membership 

        Author:     JP. Vasseur, Ed.,

                    JL. Leroux, Ed.,

                    S. Yasukawa, S. Previdi,

                    P. Psenak, P. Mabbey

        Status:     Standards Track

        Date:       July 2007

        Mailbox:    [e-mail], 

                    [e-mail], 

                    [e-mail], [e-mail], 

                    [e-mail], [e-mail]

        Pages:      15

        Characters: 32044

        Updates/Obsoletes/SeeAlso:   None



        I-D Tag:    draft-ietf-ccamp-automesh-04.txt



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



The setup of a full mesh of Multi-Protocol Label Switching (MPLS)

Traffic Engineering (TE) Label Switched Paths (LSP) among a set of

Label Switch Routers (LSR) is a common deployment scenario of MPLS

Traffic Engineering either for bandwidth optimization, bandwidth

guarantees or fast rerouting with MPLS Fast Reroute.  Such deployment

may require the configuration of a potentially large number of TE

LSPs (on the order of the square of the number of LSRs).  This document

specifies Interior Gateway Protocol (IGP) routing extensions for

Intermediate System-to-Intermediate System (IS-IS) and Open Shortest

Path First (OSPF) so as to provide an automatic discovery of the set

of LSRs members of a mesh in order to automate the creation of such

mesh of TE LSPs.  [STANDARDS TRACK]



This document is a product of the Common Control and Measurement Plane

Working Group of the IETF.



This is now a Proposed Standard Protocol.



STANDARDS TRACK: This document specifies an Internet standards track

protocol for the Internet community,and requests discussion and suggestions

for improvements.Please refer to the current edition of the Internet

 Official Protocol Standards (STD 1) for the standardization state and

 status of this protocol.  Distribution of this memo is unlimited.



This announcement is sent to the IETF list and the RFC-DIST list.

Requests to be added to or deleted from the IETF distribution list

should be sent to [e-mail].  Requests to be

added to or deleted from the RFC-DIST distribution list should

be sent to [e-mail].



Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

an EMAIL message to [e-mail] with the message body 



help: ways_to_get_rfcs. For example:



        To: [e-mail]

        Subject: getting rfcs



        help: ways_to_get_rfcs



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.



Submissions for Requests for Comments should be sent to

[e-mail].  Please consult RFC 2223, Instructions to RFC

Authors, for further information.





The RFC Editor Team

USC/Information Sciences Institute



...









Envelope-to: [e-mail]
Delivery-date: Tue, 31 Jul 2007 11:42:47 +0000
Message-ID: <017e01c7d367$ab798ab0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "tom.petch" <[e-mail]>, <[e-mail]>
Subject: Re: Draft liaison 2 : Notification of new RFCs
Date: Tue, 31 Jul 2007 12:40:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Picky, picky, picky.

;-)

Adrian
----- Original Message ----- 
From: "tom.petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Tuesday, July 31, 2007 8:56 AM
Subject: Re: Draft liaison 2 : Notification of new RFCs


> ----- Original Message ----- 
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Cc: "Ross Callon" <[e-mail]>; "Scott Bradner" <[e-mail]>
> Sent: Thursday, July 26, 2007 10:20 PM
> Subject: Draft liaison 2 : Notification of new RFCs
>
>
>>
>> I think this is pretty non-controversial.
>>
>> Any comments?
>>
>> Adrian
>>
>> =======
>>
>> To: ITU-T SG15
>> From: IETF CCAMP
>> For Information
>>
>> The CCAMP working group of the IETF would like to inform you of
>> the publication of three new RFCs (Request for Comment) that may
>
> Three new RFC. Now let me see, that would be
>
> RFC4872 one
> RFC4873 two
> RFC4874 two point five
> RFC4875 two point seven five
> RFC4920 three
>
> Yup, that is three new RFC:-)
>
> Tom Petch
>
>> be relevant to your work.
>>
>> RFC 4872
>> Title
>>    RSVP-TE Extensions in Support of End-to-End
>>    Generalized Multi-Protocol Label Switching (GMPLS)
>>    Recovery
>> Abstract
>>    This document describes protocol-specific procedures and extensions
>>    for Generalized Multi-Protocol Label Switching (GMPLS) Resource
>>    ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to
>>    support end-to-end Label Switched Path (LSP) recovery that denotes
>>    protection and restoration.  A generic functional description of
>>    GMPLS recovery can be found in a companion document, RFC 4426.
>>
>> RFC 4873
>> Title
>>    GMPLS Segment Recovery
>> Abstract
>>    This document describes protocol specific procedures for GMPLS
>>    (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
>>    ReserVation Protocol - Traffic Engineering) signaling extensions to
>>    support label switched path (LSP) segment protection and restoration.
>>    These extensions are intended to complement and be consistent with
>>    the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).
>>    Implications and interactions with fast reroute are also addressed.
>>    This document also updates the handling of NOTIFY_REQUEST objects.
>>
>> RFC 4874
>> Title
>>    Exclude Routes - Extension to Resource ReserVation Protocol-
>>    Traffic Engineering (RSVP-TE)
>> Abstract
>>    This document specifies ways to communicate route exclusions during
>>    path setup using Resource ReserVation Protocol-Traffic Engineering
>>    (RSVP-TE).
>>
>>    The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
>>    Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
>>    Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
>>    Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
>>    abstract nodes and resources to be explicitly included in a path
>>    setup, but not to be explicitly excluded.
>>
>>    In some networks where precise explicit paths are not computed at the
>>    head end, it may be useful to specify and signal abstract nodes and
>>    resources that are to be explicitly excluded from routes.  These
>>    exclusions may apply to the whole path, or to parts of a path between
>>    two abstract nodes specified in an explicit path.  How Shared Risk
>>    Link Groups (SRLGs) can be excluded is also specified in this
>>    document.
>>
>> RFC 4875
>> Title
>>    Extensions to Resource Reservation Protocol - Traffic
>>    Engineering (RSVP-TE) for Point-to-Multipoint TE Label
>>    Switched Paths (LSPs)
>> Abstract
>>    This document describes extensions to Resource Reservation Protocol -
>>    Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered
>>    (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-
>>    Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
>>    networks.  The solution relies on RSVP-TE without requiring a
>>    multicast routing protocol in the Service Provider core.  Protocol
>>    elements and procedures for this solution are described.
>>
>>    There can be various applications for P2MP TE LSPs such as IP
>>    multicast.  Specification of how such applications will use a P2MP TE
>>    LSP is outside the scope of this document.
>>
>> RFC 4920
>> Title
>>    Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
>> Abstract
>>    In a distributed, constraint-based routing environment, the
>>    information used to compute a path may be out of date.  This means
>>    that Multiprotocol Label Switching (MPLS) and Generalized MPLS
>>    (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
>>    requests may be blocked by links or nodes without sufficient
>>    resources.  Crankback is a scheme whereby setup failure information
>>    is returned from the point of failure to allow new setup attempts to
>>    be made avoiding the blocked resources.  Crankback can also be
>>    applied to LSP recovery to indicate the location of the failed link
>>    or node.
>>
>>    This document specifies crankback signaling extensions for use in
>>    MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
>>    RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in
>>    "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
>>    Functional Description", RFC 3473.  These extensions mean that the
>>    LSP setup request can be retried on an alternate path that detours
>>    around blocked links or nodes.  This offers significant improvements
>>    in the successful setup and recovery ratios for LSPs, especially in
>>    situations where a large number of setup requests are triggered at
>>    the same time.
>>
>> All IETF RFCs can be downloaded for free from
>> http://www.ietf.org/rfc.html
>>
>> The current work plan and progress status of the CCAMP working group
>> can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html
>>
>> As always, the CCAMP working group welcomes questions and discussion
>> about all of its work from individuals or organisations.
>>
>> The CCAMP mailing list is open to anyone. Details of subscription can
>> be found on the CCAMP charter page.
>>
>> Best regards,
>> Adrian Farrel and Deborah Brungard
>> Co-chairs, IETF CCAMP Working Group
>





Envelope-to: [e-mail]
Delivery-date: Tue, 31 Jul 2007 11:42:39 +0000
Message-ID: <017d01c7d367$ab3b9750$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "tom.petch" <[e-mail]>, <[e-mail]>
Cc: "Ross Callon" <[e-mail]>, <[e-mail]>
Subject: Re: Proposed CCAMP recharter
Date: Tue, 31 Jul 2007 12:40:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Good catch.
Should be...
and MPLS and GRE,

A
----- Original Message ----- 
From: "tom.petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Cc: "Ross Callon" <[e-mail]>; <[e-mail]>
Sent: Tuesday, July 31, 2007 9:04 AM
Subject: Re: Proposed CCAMP recharter


> In the 'first paragraph', I am puzzled by the change from
> MPLS, GRE,
> to
> and MPLS GRE,
> which seems a material, semantic change; is this intended?
>
> Tom Petch
>
>
> ----- Original Message ----- 
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Cc: "Ross Callon" <[e-mail]>; <[e-mail]>
> Sent: Thursday, July 26, 2007 11:25 PM
> Subject: Proposed CCAMP recharter
>
>
>> Hi,
>>
>> As discussed at the meeting(s) we should consider a small recharter to 
>> put
>> the GELS work clearly in scope and to indicate that we will work with 
>> IEEE
>> 802.1 as necessary.
>>
>> We should take the opportunity to rejig the milestones, but noting that a
>> bunch of (overdue) milestones are about to be completed it is moot 
>> whether
>> we should rearrange them all. Basically, I am too lazy to do that and
>> propose just to change the ones that are further out.
>>
>> I would like to ask you all to look at this and comment. In particular: 
>> are
>> the document editors happy with these targets?
>>
>> ADs - your opinions too, please.
>>
>> The changes proposed are...
>> ===
>> First paragraph
>> OLD
>> The CCAMP working group coordinates the work within the IETF defining a
>> common control plane and a separate common measurement plane for physical
>> path and core tunneling technologies of Internet and telecom service
>> providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, ATM and 
>> Frame
>> Relay switches, MPLS, GRE, in cooperation with the MPLS WG.
>>
>> NEW
>> The CCAMP working group coordinates the work within the IETF defining a
>> common control plane and a separate common measurement plane for physical
>> path and core tunneling technologies of Internet and telecom service
>> providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, TDM 
>> switches,
>> Ethernet switches, ATM and Frame Relay switches, and MPLS GRE, in
>> cooperation with the MPLS WG.
>> ===
>> Final paragraph
>> OLD
>> In doing this work, the WG will work closely with at least the following
>> other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also 
>> cooperate
>> with the ITU-T.
>>
>> NEW
>> In doing this work, the WG will work closely with at least the following
>> other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also 
>> cooperate
>> with the ITU-T, and the IEEE 802.1.
>> ===
>> Milestones (only those changed or new)
>>
>> Aug 2007    First version WG I-D for Protocol solutions for MLN/MRN
>> Aug 2007    First version WG I-D GMPLS OAM Requirements
>> Sep 2007    Submit Informational I-D for Analysis of inter-domain issues 
>> for
>> disjoint and protected paths for IESG review
>> Sep 2007    Submit MPLS to GMPLS migration strategies I-D for IESG review
>> Sep 2007    Submit MPLS-GMPLS interworking requirements and solutions I-D
>> for IESG review
>> Sep 2007    First version WG I-Ds for control of Ethernet networks
>> Oct 2007    Submit Requirements for Multi-Layer and Multi-Region Networks
>> I-D for IESG review
>> Oct 2007    Submit Evaluation of existing protocols for MLN/MRN for IESG
>> review
>> Oct 2007    First version of WG I-D for additional MIB module to cover
>> RSVP-TE signaling extensions
>> Dec 2007    Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG 
>> review
>> Jan 2008    Submit ASON Routing solutions I-D for IESG review
>> Feb 2008    Submit GMPLS OAM Requirements I-D for IESG review
>> Mar 2008    Submit Protocol solutions for MLN/MRN I-D for IESG review
>> Apr 2008    Submit MIB module for RSVP-TE signaling extensions for MIB
>> doctor and IESG review
>> May 2008    Submit protocol extensions for control of Ethernet networks 
>> for
>> IESG review
>> Dec 2008    Recharter or close Working Group
>> ====
>>
>> Thanks,
>> Adrian
>>
>>
>>
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 31 Jul 2007 10:35:54 +0000
Message-ID: <026e01c7d355$1f846640$0601a8c0@pc6>
Reply-To: "tom.petch" <[e-mail]>
From: "tom.petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Ross Callon" <[e-mail]>, <[e-mail]>
Subject: Re: Proposed CCAMP recharter
Date: Tue, 31 Jul 2007 10:04:40 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

In the 'first paragraph', I am puzzled by the change from 
 MPLS, GRE,
to
 and MPLS GRE,
which seems a material, semantic change; is this intended?

Tom Petch


----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>; <[e-mail]>
Sent: Thursday, July 26, 2007 11:25 PM
Subject: Proposed CCAMP recharter


> Hi,
> 
> As discussed at the meeting(s) we should consider a small recharter to put 
> the GELS work clearly in scope and to indicate that we will work with IEEE 
> 802.1 as necessary.
> 
> We should take the opportunity to rejig the milestones, but noting that a 
> bunch of (overdue) milestones are about to be completed it is moot whether 
> we should rearrange them all. Basically, I am too lazy to do that and 
> propose just to change the ones that are further out.
> 
> I would like to ask you all to look at this and comment. In particular: are 
> the document editors happy with these targets?
> 
> ADs - your opinions too, please.
> 
> The changes proposed are...
> ===
> First paragraph
> OLD
> The CCAMP working group coordinates the work within the IETF defining a 
> common control plane and a separate common measurement plane for physical 
> path and core tunneling technologies of Internet and telecom service 
> providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, ATM and Frame 
> Relay switches, MPLS, GRE, in cooperation with the MPLS WG.
> 
> NEW
> The CCAMP working group coordinates the work within the IETF defining a 
> common control plane and a separate common measurement plane for physical 
> path and core tunneling technologies of Internet and telecom service 
> providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, TDM switches, 
> Ethernet switches, ATM and Frame Relay switches, and MPLS GRE, in 
> cooperation with the MPLS WG.
> ===
> Final paragraph
> OLD
> In doing this work, the WG will work closely with at least the following 
> other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate 
> with the ITU-T.
> 
> NEW
> In doing this work, the WG will work closely with at least the following 
> other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate 
> with the ITU-T, and the IEEE 802.1.
> ===
> Milestones (only those changed or new)
> 
> Aug 2007    First version WG I-D for Protocol solutions for MLN/MRN
> Aug 2007    First version WG I-D GMPLS OAM Requirements
> Sep 2007    Submit Informational I-D for Analysis of inter-domain issues for 
> disjoint and protected paths for IESG review
> Sep 2007    Submit MPLS to GMPLS migration strategies I-D for IESG review
> Sep 2007    Submit MPLS-GMPLS interworking requirements and solutions I-D 
> for IESG review
> Sep 2007    First version WG I-Ds for control of Ethernet networks
> Oct 2007    Submit Requirements for Multi-Layer and Multi-Region Networks 
> I-D for IESG review
> Oct 2007    Submit Evaluation of existing protocols for MLN/MRN for IESG 
> review
> Oct 2007    First version of WG I-D for additional MIB module to cover 
> RSVP-TE signaling extensions
> Dec 2007    Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
> Jan 2008    Submit ASON Routing solutions I-D for IESG review
> Feb 2008    Submit GMPLS OAM Requirements I-D for IESG review
> Mar 2008    Submit Protocol solutions for MLN/MRN I-D for IESG review
> Apr 2008    Submit MIB module for RSVP-TE signaling extensions for MIB 
> doctor and IESG review
> May 2008    Submit protocol extensions for control of Ethernet networks for 
> IESG review
> Dec 2008    Recharter or close Working Group
> ====
> 
> Thanks,
> Adrian 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 31 Jul 2007 10:35:47 +0000
Message-ID: <026b01c7d355$1d421760$0601a8c0@pc6>
Reply-To: "tom.petch" <[e-mail]>
From: "tom.petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: Re: Draft liaison 2 : Notification of new RFCs
Date: Tue, 31 Jul 2007 09:56:19 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>; "Scott Bradner" <[e-mail]>
Sent: Thursday, July 26, 2007 10:20 PM
Subject: Draft liaison 2 : Notification of new RFCs


> 
> I think this is pretty non-controversial.
> 
> Any comments?
> 
> Adrian
> 
> =======
> 
> To: ITU-T SG15
> From: IETF CCAMP
> For Information
> 
> The CCAMP working group of the IETF would like to inform you of
> the publication of three new RFCs (Request for Comment) that may

Three new RFC. Now let me see, that would be

RFC4872 one
RFC4873 two
RFC4874 two point five
RFC4875 two point seven five
RFC4920 three

Yup, that is three new RFC:-)

Tom Petch

> be relevant to your work.
> 
> RFC 4872
> Title
>    RSVP-TE Extensions in Support of End-to-End
>    Generalized Multi-Protocol Label Switching (GMPLS)
>    Recovery
> Abstract
>    This document describes protocol-specific procedures and extensions
>    for Generalized Multi-Protocol Label Switching (GMPLS) Resource
>    ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to
>    support end-to-end Label Switched Path (LSP) recovery that denotes
>    protection and restoration.  A generic functional description of
>    GMPLS recovery can be found in a companion document, RFC 4426.
> 
> RFC 4873
> Title
>    GMPLS Segment Recovery
> Abstract
>    This document describes protocol specific procedures for GMPLS
>    (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
>    ReserVation Protocol - Traffic Engineering) signaling extensions to
>    support label switched path (LSP) segment protection and restoration.
>    These extensions are intended to complement and be consistent with
>    the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).
>    Implications and interactions with fast reroute are also addressed.
>    This document also updates the handling of NOTIFY_REQUEST objects.
> 
> RFC 4874
> Title
>    Exclude Routes - Extension to Resource ReserVation Protocol-
>    Traffic Engineering (RSVP-TE)
> Abstract
>    This document specifies ways to communicate route exclusions during
>    path setup using Resource ReserVation Protocol-Traffic Engineering
>    (RSVP-TE).
> 
>    The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
>    Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
>    Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
>    Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
>    abstract nodes and resources to be explicitly included in a path
>    setup, but not to be explicitly excluded.
> 
>    In some networks where precise explicit paths are not computed at the
>    head end, it may be useful to specify and signal abstract nodes and
>    resources that are to be explicitly excluded from routes.  These
>    exclusions may apply to the whole path, or to parts of a path between
>    two abstract nodes specified in an explicit path.  How Shared Risk
>    Link Groups (SRLGs) can be excluded is also specified in this
>    document.
> 
> RFC 4875
> Title
>    Extensions to Resource Reservation Protocol - Traffic 
>    Engineering (RSVP-TE) for Point-to-Multipoint TE Label 
>    Switched Paths (LSPs)
> Abstract
>    This document describes extensions to Resource Reservation Protocol -
>    Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered
>    (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-
>    Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
>    networks.  The solution relies on RSVP-TE without requiring a
>    multicast routing protocol in the Service Provider core.  Protocol
>    elements and procedures for this solution are described.
> 
>    There can be various applications for P2MP TE LSPs such as IP
>    multicast.  Specification of how such applications will use a P2MP TE
>    LSP is outside the scope of this document.
> 
> RFC 4920
> Title
>    Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
> Abstract
>    In a distributed, constraint-based routing environment, the
>    information used to compute a path may be out of date.  This means
>    that Multiprotocol Label Switching (MPLS) and Generalized MPLS
>    (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
>    requests may be blocked by links or nodes without sufficient
>    resources.  Crankback is a scheme whereby setup failure information
>    is returned from the point of failure to allow new setup attempts to
>    be made avoiding the blocked resources.  Crankback can also be
>    applied to LSP recovery to indicate the location of the failed link
>    or node.
> 
>    This document specifies crankback signaling extensions for use in
>    MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
>    RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in
>    "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
>    Functional Description", RFC 3473.  These extensions mean that the
>    LSP setup request can be retried on an alternate path that detours
>    around blocked links or nodes.  This offers significant improvements
>    in the successful setup and recovery ratios for LSPs, especially in
>    situations where a large number of setup requests are triggered at
>    the same time.
> 
> All IETF RFCs can be downloaded for free from
> http://www.ietf.org/rfc.html
> 
> The current work plan and progress status of the CCAMP working group
> can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html
> 
> As always, the CCAMP working group welcomes questions and discussion
> about all of its work from individuals or organisations.
> 
> The CCAMP mailing list is open to anyone. Details of subscription can
> be found on the CCAMP charter page.
> 
> Best regards,
> Adrian Farrel and Deborah Brungard
> Co-chairs, IETF CCAMP Working Group



Envelope-to: [e-mail]
Delivery-date: Mon, 30 Jul 2007 19:18:09 +0000
Message-ID: <007a01c7d2de$15bb0820$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: CCAMP Note Takers
Date: Mon, 30 Jul 2007 20:16:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

A bunch of you kindly volunteered to take notes in Chicago.

Could you please send in your notes (to Deborah) in whatever form they are. 
Even a few hasty scribbles are a great help.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Sun, 29 Jul 2007 12:16:25 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Pce] New draft on wavelength switched optical networks
Date: Sun, 29 Jul 2007 14:15:03 +0200
Message-Id: <[e-mail]>
Thread-Topic: [Pce] New draft on wavelength switched optical networks
Thread-Index: Ace44kBWGI51s+KyS66O9uwz+WvwnwMaUN7gAyNtKiA=
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Greg,

this is a timely topic to be tackled for both the PCE and GMPLS WGs, and
well worth supporting. I would like to highlight that the renewed
interest in this work by carriers is sparked by the fact that there is
new optical equipment moving into the network, both in the core as well
as in the metro/aggregation area which needs management and
configuration. There is no intention to implement fast optical switching
at large scale, except during failure recovery and for planned
maintenance etc which would affect the IGP stability. Dimitri's remark
during the GMPLS WG meeting showed me that it might be necessary to
emphasize that position.

Regards,

Michael




-----Original Message-----
From: Greg Bernstein [mailto:[e-mail]]=20

Hi CCAMPer's and PCEr's, we have just published a new draft on the=20
"Applicability of GMPLS and PCE to Wavelength Switched Optical=20
Networks" =20
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
tched-00.txt=20
.

This draft looks at optical networks that include tunable lasers and=20
ROADM (reconfigurable optical add/drop multiplexers) with no or limited=20
wavelength conversion capability (these components are defined in the=20
draft).=20
These limitations lead to the RWA (routing and wavelength assignment)=20
problem which is a bit more demanding in terms of input information and=20
computation than other constrained path computation problems.  In the=20
draft we look at the implications for GMPLS signaling, GMPLS routing,=20
and PCE protocols and suggest some potential extensions to better=20
accommodate this application.

We'd appreciate feedback/collaboration on (a) overall interest in this=20
application, (b) requirements discussions, and (c) solution/extension=20
discussions.

Cheers

Greg B.

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



_______________________________________________
Pce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pce




Envelope-to: [e-mail]
Delivery-date: Sun, 29 Jul 2007 11:03:49 +0000
Message-ID: <00ae01c7d1cf$b9c1f4c0$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Non-member submission from [Niko Sulkhanishvili <[e-mail]>]   
Date: Sun, 29 Jul 2007 12:00:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

> From: Niko Sulkhanishvili <[e-mail]>
> To: <[e-mail]>
> CC: <[e-mail]>
> Subject: Hello
> Date: Sat, 28 Jul 2007 21:55:27 +0000
> 
> I have idea about Sonet/SDH One Way Transmission  Mode OWTM
> I think it's very useful for next generation networks.  Such method 
> (OWTM) use free resources from running data transmission network.
> In this case some function must added for multiplexing modules (for
> CS / PS) and protocols such as OSPF, xMPLS get more flexible
> functions.
> Such method also can used as  line protection for NG-SDH networks .
>
> If you interesting for this method, just inform me on my E-mail:
> [e-mail]





Envelope-to: [e-mail]
Delivery-date: Fri, 27 Jul 2007 16:17:35 +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: Is fate-sharing a must for the bidirectional TE LSP?
Date: Fri, 27 Jul 2007 18:15:31 +0200
Message-ID: <[e-mail]>
Thread-Topic: Is fate-sharing a must for the bidirectional TE LSP?
Thread-Index: AcfQN76MRxmHBlcHTc+PsCRk25NgxgALzCzw
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Xu Xiaohu" <[e-mail]>, <[e-mail]>

Hi Steven.

Please find some pieces of answer below. I hope it will help.

Regards,

Julien

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Xu Xiaohu

In the current PWE3 standard, although there is no requirement for
fate-sharing on the outer LSP tunnels, bidirectional service, including
CES, ATM and FR, can be supported well over PWE3. Is there some
difference between the service requirements on PWE3 and those on
bidirectional TE LSP?

 [JM] As you say, in PWE3 these are "service requirements", while when
talking about TE-LSPs, we are considering various layers, from packet
down to optical. As a results, requirements are different regarding the
layer you are considering and the operationnal constrains you have on
operating that specific layer.


With the deployment of P2MP TE LSP, the bandwidth consumption over a
link will become more asymmetric. The bidirectional TE LSP without
fate-sharing requirement will maximize the utilization of the total
network bandwidth resource because the forward LSP and backward LSP can
travel over the different physical paths.

 [JM] For instance, lambdas over a core network may be more likely to
have symmetrical needs than packet-based application over an aggregation
network. In the latter case, having different routes or bandwidths on
both direction could help optimization whereas in the former case,
lambdas are prefered to be co-routed in both directions, otherwise it
may become more complicated to operate and a mess for network planning.


Any comment is welcomed.

=20

=20

Best regards,

=20

Steven Xu

=20




Envelope-to: [e-mail]
Delivery-date: Fri, 27 Jul 2007 10:24:30 +0000
Date: Fri, 27 Jul 2007 12:20:24 +0200
From: Xu Xiaohu <[e-mail]>
Subject: Is fate-sharing a must for the bidirectional TE LSP?
To: [e-mail]
Message-id: <000601c7d037$c02271d0$[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_njwQDbkQEntZkVMrTMeBgA)"
Thread-index: AcfQN76MRxmHBlcHTc+PsCRk25Ngxg==

This is a multi-part message in MIME format.

--Boundary_(ID_njwQDbkQEntZkVMrTMeBgA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

In the current PWE3 standard, although there is no requirement for
fate-sharing on the outer LSP tunnels, bidirectional service, including CES,
ATM and FR, can be supported well over PWE3. Is there some difference
between the service requirements on PWE3 and those on bidirectional TE LSP?

 

With the deployment of P2MP TE LSP, the bandwidth consumption over a link
will become more asymmetric. The bidirectional TE LSP without fate-sharing
requirement will maximize the utilization of the total network bandwidth
resource because the forward LSP and backward LSP can travel over the
different physical paths.

 

Any comment is welcomed.

 

 

Best regards,

 

Steven Xu

 


--Boundary_(ID_njwQDbkQEntZkVMrTMeBgA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
 /* Page Definitions */
 @page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	layout-grid:15.6pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=ZH-CN link=blue vlink=purple style='text-justify-trim:punctuation'>

<div class=Section1 style='layout-grid:15.6pt'>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt'>In the current PWE3 standard, although there is no
requirement for fate-sharing on the outer LSP tunnels, bidirectional service,
including CES, ATM and FR, can be supported well over PWE3. Is there some
difference between the service requirements on PWE3 and those on bidirectional
TE LSP?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt'>With the deployment of P2MP TE LSP, the bandwidth consumption
over a link will become more asymmetric. The bidirectional TE LSP without
fate-sharing requirement will maximize the utilization of the total network bandwidth
resource because the forward LSP and backward LSP can travel over the different
physical paths.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt'>Any comment is welcomed.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='layout-grid-mode:char'><font size=1 face=Arial><span
lang=EN-US style='font-size:9.0pt;font-family:Arial'>Best regards,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal align=left style='text-align:left'><font size=1 face=Arial><span
lang=EN-US style='font-size:9.0pt;font-family:Arial'>Steven Xu<o:p></o:p></span></font></p>

<p class=MsoNormal align=left style='text-align:left'><font size=1 face=Arial><span
lang=EN-US style='font-size:9.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

<st1:place w:st="on"><st1:PlaceName w:st="on">
</body>

</html>

--Boundary_(ID_njwQDbkQEntZkVMrTMeBgA)--



Envelope-to: [e-mail]
Delivery-date: Thu, 26 Jul 2007 22:55:17 +0000
Message-ID: <[e-mail]>
Date: Fri, 27 Jul 2007 00:53:45 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail], Ross Callon <[e-mail]>,  [e-mail]
Subject: Re: Proposed CCAMP recharter
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

adrian

couple of points on editorship:

- MRN req + eval. should imho be ready by end Aug.

- concerning the i/w document i'd like to suggest referring to MPLS-TE 
(rather than MPLS) since applying only to RSVP-TE

- also you refer to a solution for the latter but we just have req. and 
a framework since so far -> are u sure solution would be ready by Sep'07
or alternatively the former doc shall be split and further discussed

we need also a milestone for input to the MPLS security doc. but not 
sure this has to be recorded

concerning the charter, two specific comments

- like also mentioned during the second meeting, clarifying the term 
Ethernet types would be suggested otherwise entering in an open-ended
discussion about what is allowed/not allowed, desired/not-desired, 
possible/not possible, etc. and probably focus on the analytical work 
here (something we should have probably done in the GELS context but 
did not happen) - side note here it was always felt useful to have 
operational use case described as well but that work did also never happen

- is this milestone also including Ethernet service signaling e.g. MEF ? 
in that case i would suggest to make a clear distinction here ?

thanks,
-d.

Adrian Farrel wrote:
> Hi,
> 
> As discussed at the meeting(s) we should consider a small recharter to 
> put the GELS work clearly in scope and to indicate that we will work 
> with IEEE 802.1 as necessary.
> 
> We should take the opportunity to rejig the milestones, but noting that 
> a bunch of (overdue) milestones are about to be completed it is moot 
> whether we should rearrange them all. Basically, I am too lazy to do 
> that and propose just to change the ones that are further out.
> 
> I would like to ask you all to look at this and comment. In particular: 
> are the document editors happy with these targets?
> 
> ADs - your opinions too, please.
> 
> The changes proposed are...
> ===
> First paragraph
> OLD
> The CCAMP working group coordinates the work within the IETF defining a 
> common control plane and a separate common measurement plane for 
> physical path and core tunneling technologies of Internet and telecom 
> service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, 
> ATM and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS WG.
> 
> NEW
> The CCAMP working group coordinates the work within the IETF defining a 
> common control plane and a separate common measurement plane for 
> physical path and core tunneling technologies of Internet and telecom 
> service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, 
> TDM switches, Ethernet switches, ATM and Frame Relay switches, and MPLS 
> GRE, in cooperation with the MPLS WG.
> ===
> Final paragraph
> OLD
> In doing this work, the WG will work closely with at least the following 
> other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also 
> cooperate with the ITU-T.
> 
> NEW
> In doing this work, the WG will work closely with at least the following 
> other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also 
> cooperate with the ITU-T, and the IEEE 802.1.
> ===
> Milestones (only those changed or new)
> 
> Aug 2007    First version WG I-D for Protocol solutions for MLN/MRN
> Aug 2007    First version WG I-D GMPLS OAM Requirements
> Sep 2007    Submit Informational I-D for Analysis of inter-domain issues 
> for disjoint and protected paths for IESG review
> Sep 2007    Submit MPLS to GMPLS migration strategies I-D for IESG review
> Sep 2007    Submit MPLS-GMPLS interworking requirements and solutions 
> I-D for IESG review
> Sep 2007    First version WG I-Ds for control of Ethernet networks
> Oct 2007    Submit Requirements for Multi-Layer and Multi-Region 
> Networks I-D for IESG review
> Oct 2007    Submit Evaluation of existing protocols for MLN/MRN for IESG 
> review
> Oct 2007    First version of WG I-D for additional MIB module to cover 
> RSVP-TE signaling extensions
> Dec 2007    Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
> Jan 2008    Submit ASON Routing solutions I-D for IESG review
> Feb 2008    Submit GMPLS OAM Requirements I-D for IESG review
> Mar 2008    Submit Protocol solutions for MLN/MRN I-D for IESG review
> Apr 2008    Submit MIB module for RSVP-TE signaling extensions for MIB 
> doctor and IESG review
> May 2008    Submit protocol extensions for control of Ethernet networks 
> for IESG review
> Dec 2008    Recharter or close Working Group
> ====
> 
> Thanks,
> Adrian
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 26 Jul 2007 21:26:14 +0000
Message-ID: <195301c7cfcb$7ae97760$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>, <[e-mail]>
Subject: Proposed CCAMP recharter
Date: Thu, 26 Jul 2007 22:25:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

As discussed at the meeting(s) we should consider a small recharter to put 
the GELS work clearly in scope and to indicate that we will work with IEEE 
802.1 as necessary.

We should take the opportunity to rejig the milestones, but noting that a 
bunch of (overdue) milestones are about to be completed it is moot whether 
we should rearrange them all. Basically, I am too lazy to do that and 
propose just to change the ones that are further out.

I would like to ask you all to look at this and comment. In particular: are 
the document editors happy with these targets?

ADs - your opinions too, please.

The changes proposed are...
===
First paragraph
OLD
The CCAMP working group coordinates the work within the IETF defining a 
common control plane and a separate common measurement plane for physical 
path and core tunneling technologies of Internet and telecom service 
providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, ATM and Frame 
Relay switches, MPLS, GRE, in cooperation with the MPLS WG.

NEW
The CCAMP working group coordinates the work within the IETF defining a 
common control plane and a separate common measurement plane for physical 
path and core tunneling technologies of Internet and telecom service 
providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, TDM switches, 
Ethernet switches, ATM and Frame Relay switches, and MPLS GRE, in 
cooperation with the MPLS WG.
===
Final paragraph
OLD
In doing this work, the WG will work closely with at least the following 
other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate 
with the ITU-T.

NEW
In doing this work, the WG will work closely with at least the following 
other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate 
with the ITU-T, and the IEEE 802.1.
===
Milestones (only those changed or new)

Aug 2007    First version WG I-D for Protocol solutions for MLN/MRN
Aug 2007    First version WG I-D GMPLS OAM Requirements
Sep 2007    Submit Informational I-D for Analysis of inter-domain issues for 
disjoint and protected paths for IESG review
Sep 2007    Submit MPLS to GMPLS migration strategies I-D for IESG review
Sep 2007    Submit MPLS-GMPLS interworking requirements and solutions I-D 
for IESG review
Sep 2007    First version WG I-Ds for control of Ethernet networks
Oct 2007    Submit Requirements for Multi-Layer and Multi-Region Networks 
I-D for IESG review
Oct 2007    Submit Evaluation of existing protocols for MLN/MRN for IESG 
review
Oct 2007    First version of WG I-D for additional MIB module to cover 
RSVP-TE signaling extensions
Dec 2007    Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
Jan 2008    Submit ASON Routing solutions I-D for IESG review
Feb 2008    Submit GMPLS OAM Requirements I-D for IESG review
Mar 2008    Submit Protocol solutions for MLN/MRN I-D for IESG review
Apr 2008    Submit MIB module for RSVP-TE signaling extensions for MIB 
doctor and IESG review
May 2008    Submit protocol extensions for control of Ethernet networks for 
IESG review
Dec 2008    Recharter or close Working Group
====

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Thu, 26 Jul 2007 20:43:34 +0000
Message-ID: <193601c7cfc5$864cb730$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: RFC 4883 on Benchmarking Terminology for Resource ReservationCapable Routers
Date: Thu, 26 Jul 2007 21:40:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

This is not intended to be directly relevant to us, but some of you may be 
interested to consider the direction and possible implications for RSVP-TE.

Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, July 25, 2007 5:01 PM
Subject: RFC 4883 on Benchmarking Terminology for Resource 
ReservationCapable Routers


> A new Request for Comments is now available in online RFC libraries.
>
>        RFC 4883
>
>        Title:      Benchmarking Terminology for Resource Reservation
>                    Capable Routers
>        Author:     G. Feher, K. Nemeth,
>                    A. Korn, I. Cselenyi
>        Status:     Informational
>        Date:       July 2007
>        Mailbox:    [e-mail],
>                    [e-mail],
>                    [e-mail],
>                    [e-mail]
>
>        Pages:      24
>        Characters: 54205
>        Updates/Obsoletes/SeeAlso:   None
>
>        I-D Tag:    draft-ietf-bmwg-benchres-term-08.txt
>        URL:        http://www.rfc-editor.org/rfc/rfc4883.txt
>
> The primary purpose of this document is to define terminology
> specific to the benchmarking of resource reservation signaling of
> Integrated Services (IntServ) IP routers.  These terms can be used in
> additional documents that define benchmarking methodologies for
> routers that support resource reservation or reporting formats for
> the benchmarking measurements.





Envelope-to: [e-mail]
Delivery-date: Thu, 26 Jul 2007 20:29:53 +0000
Message-ID: <191601c7cfc3$6a5fe3f0$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Draft liaison 2 : Notification of new RFCs
Date: Thu, 26 Jul 2007 21:20:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I think this is pretty non-controversial.

Any comments?

Adrian

=======

To: ITU-T SG15
From: IETF CCAMP
For Information

The CCAMP working group of the IETF would like to inform you of
the publication of three new RFCs (Request for Comment) that may
be relevant to your work.

RFC 4872
Title
   RSVP-TE Extensions in Support of End-to-End
   Generalized Multi-Protocol Label Switching (GMPLS)
   Recovery
Abstract
   This document describes protocol-specific procedures and extensions
   for Generalized Multi-Protocol Label Switching (GMPLS) Resource
   ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to
   support end-to-end Label Switched Path (LSP) recovery that denotes
   protection and restoration.  A generic functional description of
   GMPLS recovery can be found in a companion document, RFC 4426.

RFC 4873
Title
   GMPLS Segment Recovery
Abstract
   This document describes protocol specific procedures for GMPLS
   (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
   ReserVation Protocol - Traffic Engineering) signaling extensions to
   support label switched path (LSP) segment protection and restoration.
   These extensions are intended to complement and be consistent with
   the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).
   Implications and interactions with fast reroute are also addressed.
   This document also updates the handling of NOTIFY_REQUEST objects.

RFC 4874
Title
   Exclude Routes - Extension to Resource ReserVation Protocol-
   Traffic Engineering (RSVP-TE)
Abstract
   This document specifies ways to communicate route exclusions during
   path setup using Resource ReserVation Protocol-Traffic Engineering
   (RSVP-TE).

   The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
   Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
   Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
   abstract nodes and resources to be explicitly included in a path
   setup, but not to be explicitly excluded.

   In some networks where precise explicit paths are not computed at the
   head end, it may be useful to specify and signal abstract nodes and
   resources that are to be explicitly excluded from routes.  These
   exclusions may apply to the whole path, or to parts of a path between
   two abstract nodes specified in an explicit path.  How Shared Risk
   Link Groups (SRLGs) can be excluded is also specified in this
   document.

RFC 4875
Title
   Extensions to Resource Reservation Protocol - Traffic 
   Engineering (RSVP-TE) for Point-to-Multipoint TE Label 
   Switched Paths (LSPs)
Abstract
   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered
   (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-
   Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   networks.  The solution relies on RSVP-TE without requiring a
   multicast routing protocol in the Service Provider core.  Protocol
   elements and procedures for this solution are described.

   There can be various applications for P2MP TE LSPs such as IP
   multicast.  Specification of how such applications will use a P2MP TE
   LSP is outside the scope of this document.

RFC 4920
Title
   Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
Abstract
   In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date.  This means
   that Multiprotocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
   requests may be blocked by links or nodes without sufficient
   resources.  Crankback is a scheme whereby setup failure information
   is returned from the point of failure to allow new setup attempts to
   be made avoiding the blocked resources.  Crankback can also be
   applied to LSP recovery to indicate the location of the failed link
   or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
   RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in
   "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
   Functional Description", RFC 3473.  These extensions mean that the
   LSP setup request can be retried on an alternate path that detours
   around blocked links or nodes.  This offers significant improvements
   in the successful setup and recovery ratios for LSPs, especially in
   situations where a large number of setup requests are triggered at
   the same time.


All IETF RFCs can be downloaded for free from
http://www.ietf.org/rfc.html

The current work plan and progress status of the CCAMP working group
can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html

As always, the CCAMP working group welcomes questions and discussion
about all of its work from individuals or organisations.

The CCAMP mailing list is open to anyone. Details of subscription can
be found on the CCAMP charter page.

Best regards,
Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group






Envelope-to: [e-mail]
Delivery-date: Thu, 26 Jul 2007 04:02:46 +0000
Message-ID: <187101c7cf39$87bfd4d0$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Draft liaison for your review
Date: Thu, 26 Jul 2007 04:56:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We propose to send the following liaison to the ITU-T to reopen the 
conversation on ASON Routing Requirements.

Please let us know if we should change any of the wording.

Thanks,
Adrian and Deborah

===

To: ITU-T SG15
From: CCAMP Working Group
For Comment

The IETF CCAMP working group has become aware from the chair of ITU-T
Study Group 15 Working Party 3 that there are concerns within ITU-T Study
Group 15 regarding the correlation of the IETF RFCs and corresponding ITU
Recommendations.

The specific RFCs in question are:

RFC 4258
Requirements for Generalized Multi-Protocol Label Switching (GMPLS)
Routing for the Automatically Switched Optical Network (ASON)
http://www.ietf.org/rfc/rfc4258.txt

RFC 4652
Evaluation of Existing Routing Protocols against Automatic Switched
Optical Network (ASON) Routing Requirements
http://www.ietf.org/rfc/rfc4652.txt

We believe that there may have been some developments in the ITU-T
Recommendations (especially G.7715, G.7715.1, G.7715.2, and G.8080) that
may result in desired updates to the RFCs. We also understand that there
may be some long-standing concerns about some technical details in the
RFCs.

In the former case we would welcome pointers to the relevant sections in
the documents, and your analysis of what we should do with the
referenced material.

In the latter case we would appreciate a restatement of the concerns.
Given the previous attempts to ensure correlation between the work
of the two bodies, we would suggest that it may be advantageous to
present these concerns in new words, and providing as much
technical detail as possible.

Many thanks for your consideration of this issue.

Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-Chairs 





Envelope-to: [e-mail]
Delivery-date: Wed, 25 Jul 2007 14:58:55 +0000
Message-ID: <[e-mail]>
Date: Wed, 25 Jul 2007 16:56:57 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: reminder: ospf routing disc.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

folks

reminder for those interested in ospf ason routing
discussion

*** meeting at 11:30 AM at the IETF reg .desk ***

please read the following document to facilitate
discussion

<https://datatracker.ietf.org/liaison/326/>

-d.



Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jul 2007 20:53:37 +0000
Message-ID: <163601c7ce34$75fbb580$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Charter update
Date: Tue, 24 Jul 2007 21:51:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

All,

I have made some updates after today's meeting.

Please have a look at the proposed changes in 
http://www3.ietf.org/proceedings/07jul/slides/ccamp-20.ppt

I am particularly concerned to hear from document editors.
Can you promise to meet these dates? Do you need more time?
I am aware that engineers in our industry tend to me optimistic about 
deadlines! Please try to apply some realism to your estimates.

Discussion on the list or in the meeting on Wednesday.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jul 2007 18:31:54 +0000
Message-ID: <158001c7ce20$b4721840$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Updated agenda
Date: Tue, 24 Jul 2007 19:22:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We have updated Wednesday's agenda to add a short slot for Wataru to talk 
about his draft. Because this is a late addition, the slot is very short and 
discussion will be curtailed.

Thanks,
Adrian and Deborah 





Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jul 2007 16:11:17 +0000
Date: Wed, 25 Jul 2007 00:10:35 +0800
From: MachChen 55527 <[e-mail]>
Subject: =?gb2312?B?u9i4tA==?=:Inter-AS OSPF/ISIS extensions
To: Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: quoted-printable
Content-disposition: inline

Hi kompella=2C

OK=2C we will add such clarify in the next revision=2E

Best regards=2C
Mach


----- =D4=AD=D3=CA=BC=FE -----
=B7=A2=BC=FE=C8=CB=3A Kireeti Kompella =3Ckireeti=40juniper=2Enet=3E
=C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =C6=DF=D4=C2 24=C8=D5=2C 2007 =CF=C2=
=CE=E711=3A49
=D6=F7=CC=E2=3A Inter-AS OSPF/ISIS extensions

=3E So=2C I looked (again) at the OSPF draft=2C and I didn=27t see what I=
 =

=3E wanted=2E
=3E So=2C here=27s what I suggest=2C explicitly=3A
=3E =

=3E in section 2=2E1 of draft-ietf-ccamp-ospf-interas-te-extension=2C add=
=3A
=3E =

=3E   o No OSPF adjacencies are formed on the inter-AS link=2E
=3E =

=3E Add the following at the end of the first para of section 4=2E
=3E =

=3E     Hellos MUST NOT be exchanged (and consequently=2C an OSPF adjacen=
cy
=3E     MUST NOT be formed) over the inter-AS link=2E
=3E =

=3E (assuming=2C of course that there are no objections=2E)
=3E =

=3E Similar text should also be added to the ISIS draft=2E
=3E =

=3E Kireeti=2E
=3E -------
=3E =

=3E 



Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jul 2007 15:50:47 +0000
Date: Tue, 24 Jul 2007 08:49:01 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: Inter-AS OSPF/ISIS extensions
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

So, I looked (again) at the OSPF draft, and I didn't see what I wanted.

So, here's what I suggest, explicitly:

in section 2.1 of draft-ietf-ccamp-ospf-interas-te-extension, add:

   o No OSPF adjacencies are formed on the inter-AS link.

Add the following at the end of the first para of section 4.

     Hellos MUST NOT be exchanged (and consequently, an OSPF adjacency
     MUST NOT be formed) over the inter-AS link.

(assuming, of course that there are no objections.)

Similar text should also be added to the ISIS draft.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jul 2007 01:51:46 +0000
Message-ID: <14b501c7cd94$c0131b40$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Missing slides
Date: Tue, 24 Jul 2007 02:48:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I may have missed some slides mailed to me yesterday while my ISP in the UK 
was quite literally under water.

Can you please check http://www3.ietf.org/proceedings/07jul/agenda/ccamp.htm 
to see if your slides are posted and, if not, send them to me ASAP.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Sun, 22 Jul 2007 18:14:21 +0000
Message-ID: <12ae01c7cc8b$c4c87360$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: slides
Date: Sun, 22 Jul 2007 19:11:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Please send them in if you haven't already.
It is nice to get them posted before the meeting.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sun, 22 Jul 2007 01:06:22 +0000
Message-ID: <117a01c7cbc3$cdd15da0$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'MORTON, ALFRED C, JR. \(AL\), ATTLABS'" <[e-mail]>
Subject: Fw: [CCAMP] Application Performance Metrics BOF
Date: Sat, 21 Jul 2007 19:20:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Heads up.

Adrian
----- Original Message ----- 
From: "Al Morton" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, July 18, 2007 10:49 PM
Subject: [CCAMP] Application Performance Metrics BOF


> Folks in avt, bmwg, ccamp, ippm, and sipping,
> 
> If you're interested in performance metrics,
> please join in this BOF and give your opinion
> on future directions for this work.
> 
> http://www3.ietf.org/proceedings/07jul/agenda/apm.txt
> 
> regards,
> Al Morton
> Alan Clark
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ccamp
>




Envelope-to: [e-mail]
Delivery-date: Sat, 21 Jul 2007 15:14:51 +0000
Message-ID: <107701c7cba9$5ff21280$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Agenda updated
Date: Sat, 21 Jul 2007 16:06:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I've uploaded a new copy of the agenda at 
http://www3.ietf.org/proceedings/07jul/agenda/ccamp.htm

The only change is to add...

5a. IGP Extensions for Inter-AS TE Links (Mach, 10, 75/150)
Background reading
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-00.txt
http://www.ietf.org/internet-drafts/draft-chen-ccamp-isis-interas-te-extension-00.txt

The slides are starting to arrive and being uploaded as I get them.

Adrian





Envelope-to: [e-mail]
Delivery-date: Wed, 18 Jul 2007 22:33:53 +0000
Message-ID: <0cd501c7c98b$37ee9c10$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?
Date: Wed, 18 Jul 2007 23:19:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response
Content-Transfer-Encoding: 7bit

I hear no dissent.

We'll float the idea in front of the meeting in Chicago to give one last 
chance for any complaints and then move forwards immediately after Chicago.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Dan Li" <[e-mail]>; "ccamp" <[e-mail]>
Cc: "Deborah A. Brungard" <[e-mail]>; "Arun Satyanarayana" 
<[e-mail]>
Sent: Sunday, June 24, 2007 1:40 PM
Subject: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?


> Hi,
>
> In Prague we found that there was some support for this work, and no 
> opposition.
>
> There were questions regarding clarifying that the work does not define 
> new process or procedures, but explains how existing procedures (i.e. 
> draft-ietf-ccamp-rsvp-restart-ext-08.txt) can be applied in a variety of 
> situations. I think that this revision has included this clarification.
>
> There was a request to broaden the draft to cover all scenarios (not just 
> multi-node as before), and this has been done.
>
> There was concern about whether there was "service provider" interest in 
> this work. In fact, several of the hands raised to express interest worked 
> for service providers. But I am not personally convinced that this 
> Informational work needs strong support from that sector. More to the 
> point would be support from the vendors who need to agree how they will 
> operate draft-ietf-ccamp-rsvp-restart-ext.
>
> So, I'd like to ask the WG whether there is support to make this I-D a WG 
> draft.
> If we do, I would like to see it complete quite quickly. It would need:
> - review by vendors to make sure it is accurate
> - a bit more text on security issues
>
> Thanks,
> Adrian
>
> ----- Original Message ----- 
> From: "Dan Li" <[e-mail]>
> To: "ccamp" <[e-mail]>
> Cc: "Deborah A. Brungard" <[e-mail]>; "Farrel, Adrian" 
> <[e-mail]>; "Arun Satyanarayana" <[e-mail]>
> Sent: Friday, June 22, 2007 2:08 AM
> Subject: New draft: draft-li-ccamp-gr-description-00.txt
>
>
>> Dear CCAMPers,
>>
>> We have published a "new" I-D:
>> http://tools.ietf.org/wg/ccamp/draft-li-ccamp-gr-description-00.txt
>>
>> This I-D replaces the previous I-D 
>> http://tools.ietf.org/wg/ccamp/draft-li-ccamp-multinodes-gr-proc-01.txt.
>>
>> According to the discussion in Prague meeting, we have:
>> 1) Changed draft to be Informational. Mainly rewords the draft to make 
>> sure that it does not give instructions that could be interpreted as 
>> defining the procedures.
>> 2) The title of the I-D has been changed to "Description of the RSVP-TE 
>> Graceful Restart Procedures", in order to wide the scope of this I-D to 
>> include the single node graceful restart scenario.
>>
>> Best regards,
>> Dan Li
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Mon, 16 Jul 2007 16:17:09 +0000
Date: Mon, 16 Jul 2007 11:14:29 -0500
From: Young Lee <[e-mail]>
Subject: RE: New draft on wavelength switched optical networks
To: 'Greg Bernstein' <[e-mail]>, "'Bardalai, Snigdho'" <[e-mail]>
Cc: 'ccamp' <[e-mail]>, [e-mail]
Message-id: <000401c7c7c4$633da410$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Thread-index: AcfGLkFR3UPutvCdTr2jrCyQNCF4wwBkgjnw

Hi Snigdho,

Please see in-line for my comments.  Thanks.

Young

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Greg Bernstein
Sent: Saturday, July 14, 2007 10:46 AM
To: Bardalai, Snigdho
Cc: ccamp; Young Lee; [e-mail]
Subject: Re: New draft on wavelength switched optical networks

Hi Snigdho, good points and questions.  See comments below.

Regards

Greg B.

Bardalai, Snigdho wrote:
> Hi Greg,
>
> I believe your ID has presented some of the key points regarding
wavelength routing.
>
> I think we are still missing a few other issues that may have to be
considered.
> 1. Constraints related to the configuration of the ROADM switching
elements. For
>    example, transponders could be pre-wired to a specific port on the
ROADM, and hence
>    restricting the wavelengths that could be routed to that transponder.
>   
--> Yes. We touched on this only a bit but this is very important. There 
is a new draft (July 9, 2007) by Wataru. Imajuku, "Routing Extensions to 
Support Network Elements with Switching Constraint", 
draft-imajuku-ccamp-rtg-switching-constraint-02.txt. Which also hits 
some of these issues.  But this is an area that needs further 
requirements analysis.
It seems like we have at least:
(a) Internal switching topology constraints.  Such as you can't get to 
that port from this port. Illustrated in Wataru's draft.
(b) "Colored" interface related constraints where specific lambdas 
ingressing on a port will egress on a fixed port (not configurable). 
Like what you mention above.
(c) Wavelength converter based constraints such as we mention in our draft.
(d) ... Others? Or a better taxonomy than the above?

[Young] Agree with Greg. Wataru draft addressed the need to differentiate
interface types: (i) colored vs. (ii) colorless. 


> 2. When considering wavelength routing it may be important to consider
>    if regeneration of the signal is required. 
--> This kind of work was started by John Strand and Angela Chiu in 
RFC4054 on optical impairments related to routing.  Now since the 
publication the ITU-T has made a lot of progress in defining and 
characterizing various optical impairments so the time maybe about right 
to related some of this data plane work to the control plane. We 
originally were looking at this then saw some other gaps that needed 
filling.

[Young] The approach we have taken in regards to impairment issues in
wavelength optical switched network was to put on hold for now until we have
received enough interest in the current work. We (Greg and I) judged that
basic signaling and routing of the wavelengths should get kicked off before
we address optical impairment issues. 

But as you indicated, optical impairment issue is one of the key routing
constraints especially in the transparent optical network. We have not
forgotten this issue; but at this juncture, we'd like to pursue the issues
around the basic RWA issue first. Once this work is accepted in the
community, then we should pursue impairment issue. 


> Also, it may be equally important to
>    be able to specify, if and where reqeneration would be required during
signaling
>    (assuming an external entity such as a PCE can determine where the
regeneration can
>    be done).
>   
--> Yes.  We need regeneration capability information with our topology 
information which affects routing. Don't know that we'd need extensions 
to signaling, since once you've specified in the ERO to go through a 
regenerator element then you're done. At least for the fixed 
regenerators and those implicit in OEO switches.
>    

[Young]  One thing we should be careful, though, is routing scalability.
Previous attempts in this work have failed due to routing scalability issues
associated with the sheer amount of data that need to be advertised. But now
due to advancement of PCE, some of the information can be made available in
PCE (not necessarily via IGP) and PCE would handle path computation
constraints associated with regeneration and other optical impairment data. 

But before we jump into architectural alternatives, we should reach to an
agreement on the scope of essential data required to enable RWA. 

> It would be of much interest to me to learn what is your (and others)
opinion on these
> issues.
>
> Regards,
> Snigdho
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Greg Bernstein
> Sent: Wednesday, June 27, 2007 12:39 PM
> To: ccamp; [e-mail]
> Cc: Young Lee
> Subject: New draft on wavelength switched optical networks
>
>
> Hi CCAMPer's and PCEr's, we have just published a new draft on the 
> "Applicability of GMPLS and PCE to Wavelength Switched Optical 
> Networks"  
>
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switche
d-00.txt 
> .
>
> This draft looks at optical networks that include tunable lasers and 
> ROADM (reconfigurable optical add/drop multiplexers) with no or limited 
> wavelength conversion capability (these components are defined in the 
> draft). 
> These limitations lead to the RWA (routing and wavelength assignment) 
> problem which is a bit more demanding in terms of input information and 
> computation than other constrained path computation problems.  In the 
> draft we look at the implications for GMPLS signaling, GMPLS routing, 
> and PCE protocols and suggest some potential extensions to better 
> accommodate this application.
>
> We'd appreciate feedback/collaboration on (a) overall interest in this 
> application, (b) requirements discussions, and (c) solution/extension 
> discussions.
>
> Cheers
>
> Greg B.
>
>   

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








Envelope-to: [e-mail]
Delivery-date: Sun, 15 Jul 2007 04:25: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: New draft on wavelength switched optical networks
Date: Sat, 14 Jul 2007 23:23:01 -0500
Message-ID: <[e-mail]>
Thread-Topic: New draft on wavelength switched optical networks
Thread-index: AcfGLjQOpZOHmtDORVuhI2drEM2D4wAWowmw
From: "Bardalai, Snigdho" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>
Cc: "ccamp" <[e-mail]>, "Young Lee" <[e-mail]>, <[e-mail]>

Hi Greg,

Some more comments.....

Snigdho

-----Original Message-----
From: Greg Bernstein [mailto:[e-mail]]
Sent: Saturday, July 14, 2007 10:46 AM
To: Bardalai, Snigdho
Cc: ccamp; Young Lee; [e-mail]
Subject: Re: New draft on wavelength switched optical networks


Hi Snigdho, good points and questions.  See comments below.

Regards

Greg B.

Bardalai, Snigdho wrote:
> Hi Greg,
>
> I believe your ID has presented some of the key points regarding =
wavelength routing.
>
> I think we are still missing a few other issues that may have to be =
considered.
> 1. Constraints related to the configuration of the ROADM switching =
elements. For
>    example, transponders could be pre-wired to a specific port on the =
ROADM, and hence
>    restricting the wavelengths that could be routed to that =
transponder.
>  =20
--> Yes. We touched on this only a bit but this is very important. There =

is a new draft (July 9, 2007) by Wataru. Imajuku, "Routing Extensions to =

Support Network Elements with Switching Constraint",=20
draft-imajuku-ccamp-rtg-switching-constraint-02.txt. Which also hits=20
some of these issues.  But this is an area that needs further=20
requirements analysis.
It seems like we have at least:
(a) Internal switching topology constraints.  Such as you can't get to=20
that port from this port. Illustrated in Wataru's draft.
(b) "Colored" interface related constraints where specific lambdas=20
ingressing on a port will egress on a fixed port (not configurable).=20
Like what you mention above.
(c) Wavelength converter based constraints such as we mention in our =
draft.
(d) ... Others? Or a better taxonomy than the above?

[Snigdho] With O-E-O wavelength convertors additional constraints wrt to =

          the signal rate (2.5G or 10G) and other attributes related to =
the
          electrical signal will have to be taken into account.

> 2. When considering wavelength routing it may be important to consider
>    if regeneration of the signal is required.=20
--> This kind of work was started by John Strand and Angela Chiu in=20
RFC4054 on optical impairments related to routing.  Now since the=20
publication the ITU-T has made a lot of progress in defining and=20
characterizing various optical impairments so the time maybe about right =

to related some of this data plane work to the control plane. We=20
originally were looking at this then saw some other gaps that needed=20
filling.

[Snigdho] I tend to agree with your view on this. Could you elaborate on =
"gaps" ?

> Also, it may be equally important to
>    be able to specify, if and where reqeneration would be required =
during signaling
>    (assuming an external entity such as a PCE can determine where the =
regeneration can
>    be done).
>  =20
--> Yes.  We need regeneration capability information with our topology=20
information which affects routing. Don't know that we'd need extensions=20
to signaling, since once you've specified in the ERO to go through a=20
regenerator element then you're done. At least for the fixed=20
regenerators and those implicit in OEO switches.

[Snigdho] I think it is possible to have per wavelength O-E-O =
regeneration as well.
          Using this mode of operation, the selection of the =
regeneration site could
          become more flexible. So routing could pick a site that is =
suitable considering
          the optical impairment parameters whereas signaling could =
actually require
          a specific type of regeneration module to be existing at the =
site.

>   =20
> It would be of much interest to me to learn what is your (and others) =
opinion on these
> issues.
>
> Regards,
> Snigdho
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Greg Bernstein
> Sent: Wednesday, June 27, 2007 12:39 PM
> To: ccamp; [e-mail]
> Cc: Young Lee
> Subject: New draft on wavelength switched optical networks
>
>
> Hi CCAMPer's and PCEr's, we have just published a new draft on the=20
> "Applicability of GMPLS and PCE to Wavelength Switched Optical=20
> Networks" =20
> =
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit=
ched-00.txt=20
> .
>
> This draft looks at optical networks that include tunable lasers and=20
> ROADM (reconfigurable optical add/drop multiplexers) with no or =
limited=20
> wavelength conversion capability (these components are defined in the=20
> draft).=20
> These limitations lead to the RWA (routing and wavelength assignment)=20
> problem which is a bit more demanding in terms of input information =
and=20
> computation than other constrained path computation problems.  In the=20
> draft we look at the implications for GMPLS signaling, GMPLS routing,=20
> and PCE protocols and suggest some potential extensions to better=20
> accommodate this application.
>
> We'd appreciate feedback/collaboration on (a) overall interest in this =

> application, (b) requirements discussions, and (c) solution/extension=20
> discussions.
>
> Cheers
>
> Greg B.
>
>  =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]



Envelope-to: [e-mail]
Delivery-date: Sat, 14 Jul 2007 20:30:06 +0000
To: [e-mail], [e-mail]
Subject:  RFC 4920 on Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Sat, 14 Jul 2007 13:26:15 -0700 (PDT)

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



        

        RFC 4920



        Title:      Crankback Signaling Extensions for MPLS 

                    and GMPLS RSVP-TE 

        Author:     A. Farrel, Ed.,

                    A. Satyanarayana, A. Iwata,

                    N. Fujita, G. Ash

        Status:     Standards Track

        Date:       July 2007

        Mailbox:    [e-mail], 

                    [e-mail], 

                    [e-mail],  [e-mail], 

                    [e-mail]

        Pages:      38

        Characters: 88679

        Updates/Obsoletes/SeeAlso:   None



        I-D Tag:    draft-ietf-ccamp-crankback-06.txt



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



In a distributed, constraint-based routing environment, the

information used to compute a path may be out of date.  This means

that Multiprotocol Label Switching (MPLS) and Generalized MPLS

(GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup

requests may be blocked by links or nodes without sufficient

resources.  Crankback is a scheme whereby setup failure information is

returned from the point of failure to allow new setup attempts to be

made avoiding the blocked resources.  Crankback can also be applied to

LSP recovery to indicate the location of the failed link or node.



This document specifies crankback signaling extensions for use in MPLS

signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for

LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized

Multi-Protocol Label Switching (GMPLS) Signaling Functional

Description", RFC 3473.  These extensions mean that the LSP setup

request can be retried on an alternate path that detours around

blocked links or nodes.  This offers significant improvements

in the successful setup and recovery ratios for LSPs, especially in

situations where a large number of setup requests are triggered at the

same time.  [STANDARDS TRACK]



This document is a product of the Common Control and Measurement Plane

Working Group of the IETF.



This is now a Proposed Standard Protocol.



STANDARDS TRACK: This document specifies an Internet standards track

protocol for the Internet community,and requests discussion and suggestions

for improvements.Please refer to the current edition of the Internet

 Official Protocol Standards (STD 1) for the standardization state and

 status of this protocol.  Distribution of this memo is unlimited.



This announcement is sent to the IETF list and the RFC-DIST list.

Requests to be added to or deleted from the IETF distribution list

should be sent to [e-mail].  Requests to be

added to or deleted from the RFC-DIST distribution list should

be sent to [e-mail].



Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

an EMAIL message to [e-mail] with the message body 



help: ways_to_get_rfcs. For example:



        To: [e-mail]

        Subject: getting rfcs



        help: ways_to_get_rfcs



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.



Submissions for Requests for Comments should be sent to

[e-mail].  Please consult RFC 2223, Instructions to RFC

Authors, for further information.





The RFC Editor Team

USC/Information Sciences Institute



...







Envelope-to: [e-mail]
Delivery-date: Sat, 14 Jul 2007 15:48:37 +0000
Message-ID: <[e-mail]>
Date: Sat, 14 Jul 2007 08:46:11 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: "Bardalai, Snigdho" <[e-mail]>
CC: ccamp <[e-mail]>, Young Lee <[e-mail]>, [e-mail]
Subject: Re: New draft on wavelength switched optical networks
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Snigdho, good points and questions.  See comments below.

Regards

Greg B.

Bardalai, Snigdho wrote:
> Hi Greg,
>
> I believe your ID has presented some of the key points regarding wavelength routing.
>
> I think we are still missing a few other issues that may have to be considered.
> 1. Constraints related to the configuration of the ROADM switching elements. For
>    example, transponders could be pre-wired to a specific port on the ROADM, and hence
>    restricting the wavelengths that could be routed to that transponder.
>   
--> Yes. We touched on this only a bit but this is very important. There 
is a new draft (July 9, 2007) by Wataru. Imajuku, "Routing Extensions to 
Support Network Elements with Switching Constraint", 
draft-imajuku-ccamp-rtg-switching-constraint-02.txt. Which also hits 
some of these issues.  But this is an area that needs further 
requirements analysis.
It seems like we have at least:
(a) Internal switching topology constraints.  Such as you can't get to 
that port from this port. Illustrated in Wataru's draft.
(b) "Colored" interface related constraints where specific lambdas 
ingressing on a port will egress on a fixed port (not configurable). 
Like what you mention above.
(c) Wavelength converter based constraints such as we mention in our draft.
(d) ... Others? Or a better taxonomy than the above?
> 2. When considering wavelength routing it may be important to consider
>    if regeneration of the signal is required. 
--> This kind of work was started by John Strand and Angela Chiu in 
RFC4054 on optical impairments related to routing.  Now since the 
publication the ITU-T has made a lot of progress in defining and 
characterizing various optical impairments so the time maybe about right 
to related some of this data plane work to the control plane. We 
originally were looking at this then saw some other gaps that needed 
filling.
> Also, it may be equally important to
>    be able to specify, if and where reqeneration would be required during signaling
>    (assuming an external entity such as a PCE can determine where the regeneration can
>    be done).
>   
--> Yes.  We need regeneration capability information with our topology 
information which affects routing. Don't know that we'd need extensions 
to signaling, since once you've specified in the ERO to go through a 
regenerator element then you're done. At least for the fixed 
regenerators and those implicit in OEO switches.
>    
> It would be of much interest to me to learn what is your (and others) opinion on these
> issues.
>
> Regards,
> Snigdho
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Greg Bernstein
> Sent: Wednesday, June 27, 2007 12:39 PM
> To: ccamp; [e-mail]
> Cc: Young Lee
> Subject: New draft on wavelength switched optical networks
>
>
> Hi CCAMPer's and PCEr's, we have just published a new draft on the 
> "Applicability of GMPLS and PCE to Wavelength Switched Optical 
> Networks"  
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-00.txt 
> .
>
> This draft looks at optical networks that include tunable lasers and 
> ROADM (reconfigurable optical add/drop multiplexers) with no or limited 
> wavelength conversion capability (these components are defined in the 
> draft). 
> These limitations lead to the RWA (routing and wavelength assignment) 
> problem which is a bit more demanding in terms of input information and 
> computation than other constrained path computation problems.  In the 
> draft we look at the implications for GMPLS signaling, GMPLS routing, 
> and PCE protocols and suggest some potential extensions to better 
> accommodate this application.
>
> We'd appreciate feedback/collaboration on (a) overall interest in this 
> application, (b) requirements discussions, and (c) solution/extension 
> discussions.
>
> Cheers
>
> Greg B.
>
>   

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





Envelope-to: [e-mail]
Delivery-date: Sat, 14 Jul 2007 13:13:30 +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: New draft on wavelength switched optical networks
Date: Sat, 14 Jul 2007 08:10:09 -0500
Message-ID: <[e-mail]>
Thread-Topic: New draft on wavelength switched optical networks
Thread-index: Ace44xN2BKc9JhYiTZKVYQZA8GprxwNLmCug
From: "Bardalai, Snigdho" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>, "ccamp" <[e-mail]>, <[e-mail]>
Cc: "Young Lee" <[e-mail]>

Hi Greg,

I believe your ID has presented some of the key points regarding =
wavelength routing.

I think we are still missing a few other issues that may have to be =
considered.
1. Constraints related to the configuration of the ROADM switching =
elements. For
   example, transponders could be pre-wired to a specific port on the =
ROADM, and hence
   restricting the wavelengths that could be routed to that transponder.
2. When considering wavelength routing it may be important to consider
   if regeneration of the signal is required. Also, it may be equally =
important to
   be able to specify, if and where reqeneration would be required =
during signaling
   (assuming an external entity such as a PCE can determine where the =
regeneration can
   be done).
  =20
It would be of much interest to me to learn what is your (and others) =
opinion on these
issues.

Regards,
Snigdho

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Greg Bernstein
Sent: Wednesday, June 27, 2007 12:39 PM
To: ccamp; [e-mail]
Cc: Young Lee
Subject: New draft on wavelength switched optical networks


Hi CCAMPer's and PCEr's, we have just published a new draft on the=20
"Applicability of GMPLS and PCE to Wavelength Switched Optical=20
Networks" =20
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit=
ched-00.txt=20
.

This draft looks at optical networks that include tunable lasers and=20
ROADM (reconfigurable optical add/drop multiplexers) with no or limited=20
wavelength conversion capability (these components are defined in the=20
draft).=20
These limitations lead to the RWA (routing and wavelength assignment)=20
problem which is a bit more demanding in terms of input information and=20
computation than other constrained path computation problems.  In the=20
draft we look at the implications for GMPLS signaling, GMPLS routing,=20
and PCE protocols and suggest some potential extensions to better=20
accommodate this application.

We'd appreciate feedback/collaboration on (a) overall interest in this=20
application, (b) requirements discussions, and (c) solution/extension=20
discussions.

Cheers

Greg B.

--=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: Fri, 13 Jul 2007 18:17:19 +0000
Message-ID: <[e-mail]>
Date: Fri, 13 Jul 2007 11:14:21 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: MEURIC Julien RD-CORE-LAN <[e-mail]>
CC: Young Lee <[e-mail]>, ccamp <[e-mail]>, [e-mail]
Subject: Re: [Pce] New draft on wavelength switched optical networks
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Julien, good questions.  See comments below. 

Regards

Greg B.

MEURIC Julien RD-CORE-LAN wrote:
> Hi Greg.
>
> I'm really interested in this topic, but I think I've missed some points when reading your ID.
>
> For instance, I don't get why you consider the signal modulation format. I don't believe a single-vendor environment would require a negociation on modulation for a specific bandwidth, 
--> In the optical case as it is currently implemented I tend to agree 
with you here.  However in other systems negotiation of modulation 
format and such is more common.
> and I don't think modulation information would be enough for 2 different implementations to interwork on (analog) optical line.
>   
I was thinking along the lines of the relatively new ITU-T optical 
signal designations such as NRZ 2.5G, and RZ 40G defined in G.959.1.
I'm also, like most of the ITU-T recommendations, restricting the focus 
to digital signals over fiber. Not including impairment information for 
now, this should give us adequate information to understand the signals 
spectral characteristics for compatibility with wavelength selective 
switching elements and such.  At least this was the part of the point of 
the physical layers interfaces defined G.959.1. 

One thing that we might have not hit well enough is the compatibility of 
the end systems where the optical signals are demodulated. Its one thing 
to be able to switch the lambdas its another to demodulate them. Would 
we need more information or would this be covered in the PID?  For 
example if the PID indicates that the carried signal is a particular 
flavor of10G Ethernet that would be sufficient.  I'll review the current 
PID stuff as applied to lambda switching.
> Anyway, this work is a good start to highlight GMPLS and PCE lack to handle the different kinds of optical networks.
>
> Regards,
>
> Julien
>
>
> -----Original Message-----
> From: Greg Bernstein [mailto:[e-mail]] 
>
> Hi CCAMPer's and PCEr's, we have just published a new draft on the 
> "Applicability of GMPLS and PCE to Wavelength Switched Optical 
> Networks"  
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-00.txt 
> .
>
> This draft looks at optical networks that include tunable lasers and 
> ROADM (reconfigurable optical add/drop multiplexers) with no or limited 
> wavelength conversion capability (these components are defined in the 
> draft). 
> These limitations lead to the RWA (routing and wavelength assignment) 
> problem which is a bit more demanding in terms of input information and 
> computation than other constrained path computation problems.  In the 
> draft we look at the implications for GMPLS signaling, GMPLS routing, 
> and PCE protocols and suggest some potential extensions to better 
> accommodate this application.
>
> We'd appreciate feedback/collaboration on (a) overall interest in this 
> application, (b) requirements discussions, and (c) solution/extension 
> discussions.
>
> Cheers
>
> Greg B.
>
>   

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





Envelope-to: [e-mail]
Delivery-date: Fri, 13 Jul 2007 14:24:22 +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: [Pce] New draft on wavelength switched optical networks
Date: Fri, 13 Jul 2007 16:20:43 +0200
Message-ID: <[e-mail]>
Thread-Topic: [Pce] New draft on wavelength switched optical networks
Thread-Index: Ace44kBWGI51s+KyS66O9uwz+WvwnwMaUN7g
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>
Cc: "Young Lee" <[e-mail]>, "ccamp" <[e-mail]>, <[e-mail]>

Hi Greg.

I'm really interested in this topic, but I think I've missed some points =
when reading your ID.

For instance, I don't get why you consider the signal modulation format. =
I don't believe a single-vendor environment would require a negociation =
on modulation for a specific bandwidth, and I don't think modulation =
information would be enough for 2 different implementations to interwork =
on (analog) optical line.

Anyway, this work is a good start to highlight GMPLS and PCE lack to =
handle the different kinds of optical networks.

Regards,

Julien


-----Original Message-----
From: Greg Bernstein [mailto:[e-mail]]=20

Hi CCAMPer's and PCEr's, we have just published a new draft on the=20
"Applicability of GMPLS and PCE to Wavelength Switched Optical=20
Networks" =20
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit=
ched-00.txt=20
.

This draft looks at optical networks that include tunable lasers and=20
ROADM (reconfigurable optical add/drop multiplexers) with no or limited=20
wavelength conversion capability (these components are defined in the=20
draft).=20
These limitations lead to the RWA (routing and wavelength assignment)=20
problem which is a bit more demanding in terms of input information and=20
computation than other constrained path computation problems.  In the=20
draft we look at the implications for GMPLS signaling, GMPLS routing,=20
and PCE protocols and suggest some potential extensions to better=20
accommodate this application.

We'd appreciate feedback/collaboration on (a) overall interest in this=20
application, (b) requirements discussions, and (c) solution/extension=20
discussions.

Cheers

Greg B.

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



_______________________________________________
Pce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pce



Envelope-to: [e-mail]
Delivery-date: Fri, 13 Jul 2007 11:17:21 +0000
Message-Id: <[e-mail]>
Date: Fri, 13 Jul 2007 20:14:57 +0900
To: "PAPADIMITRIOU Dimitri" <[e-mail]>, <[e-mail]>
From: Tomonori TAKEDA <[e-mail]>
Subject: RE: I-D     ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dimitri,

Please see in-line.

At 16:43 07/07/13, PAPADIMITRIOU Dimitri wrote:
 >hi tomonori
 >
 >well ok, the whole discussion point boils down from
 >your side as i don't depart from RFC 4726 that is
 >informational in nature ?
 >
 >was 4726 expected to be forward looking ? knowing
 >there are no placeholders at IETF ?
 >
 >4726 states
 >
 >"the aim of this document is not to detail each of those techniques,
 > which are covered in separate documents referenced from the sections
 > of this document that introduce the techniques, but rather to propose
 > a framework for inter-domain MPLS Traffic Engineering."
 >
 >it does not state that nothing prevents additional
 >techniques to complement existing mechanisms known
 >at the time that RFC was produced

I agree. If there is a momentum, we should not close the door. I think it 
is up to the WG to decide.

We will add a note that this document is based on the existing framework 
(RFC4726), but does not intend to prevent development of additional 
techniques where appropriate.


Thanks,
Tomonori

 >-d.
 >
 >
 >
 >> -----Original Message-----
 >> From: Tomonori TAKEDA [mailto:[e-mail]]
 >> Sent: Friday, July 13, 2007 6:53 AM
 >> To: PAPADIMITRIOU Dimitri; [e-mail]
 >> Subject: RE: I-D
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>
 >> Hi Dimitri,
 >>
 >> Please see in-line.
 >>
 >> At 16:24 07/07/12, PAPADIMITRIOU Dimitri wrote:
 >>  >hi tomonori,
 >>  >
 >>  >> -----Original Message-----
 >>  >> From: Tomonori TAKEDA [mailto:[e-mail]]
 >>  >> Sent: Thursday, July 12, 2007 6:34 AM
 >>  >> To: PAPADIMITRIOU Dimitri; [e-mail]
 >>  >> Subject: RE: I-D
 >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>
 >>  >> Hi Dimitri,
 >>  >>
 >>  >> Please see in-line.
 >>  >>
 >>  >> At 19:54 07/07/10, PAPADIMITRIOU Dimitri wrote:
 >>  >>  >hi tomonori - see inline
 >>  >>  >
 >>  >>  >> -----Original Message-----
 >>  >>  >> From: Tomonori TAKEDA [mailto:[e-mail]]
 >>  >>  >> Sent: Tuesday, July 10, 2007 9:51 AM
 >>  >>  >> To: PAPADIMITRIOU Dimitri; [e-mail]
 >>  >>  >> Subject: RE: I-D
 >>  >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >>
 >>  >>  >> Hi Dimitri,
 >>  >>  >>
 >>  >>  >> Thanks for your comments.
 >>  >>  >>
 >>  >>  >> Please see in-line.
 >>  >>  >>
 >>  >>  >> At 06:10 07/07/10, PAPADIMITRIOU Dimitri wrote:
 >>  >>  >>  >tomonori
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>  >reading through this doc still unclear to me why there is
 >>  >>  >> no statement
 >>  >>  >>  >that says (at the end) that the sole issue is due to
 >>  >> the fact that
 >>  >>  >>  >ingress node do not see both protecting and working LSPs
 >>  >>  >> (by definition
 >>  >>  >>  >of diversity) and therefore across that domain, mechanisms
 >>  >>  >> are needed:
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>  >1. since the problem is only considered in its linear
 >>  >> version and
 >>  >>  >>  >associated protecting and working LSP are are both
 >>  >>  >> following the same
 >>  >>  >>  >sequence, one needs to resolve the intra-domain/intra-AS
 >>  >>  >> trap issue (at
 >>  >>  >>  >the SRLG/node/ link level) and prevent that that two
 >>  >>  >> ingress nodes (of
 >>  >>  >>  >the same domain) do not select the same egress node (of
 >>  >>  >> that domain) to
 >>  >>  >>  >reach the next domain for both protecting and working LSP ?
 >>  >>  >>
 >>  >>  >> This is true when there are only two border nodes (ingress
 >>  >>  >> and egress) for
 >>  >>  >> each domain (well, SRLG diversity where nodes/links in
 >>  >>  >> different domains
 >>  >>  >> belong to the same SRLG is a bit hard, though).
 >>  >>  >
 >>  >>  >this is what the diagrams and text infers
 >>  >>  >
 >>  >>  >generalizing the number of edges/inter-connection
 >>  >>  >adds an additional constraints (select 2 among N)
 >>  >>
 >>  >> Section 1.3 and section 2 state the problem space. This
 >>  >> document does not
 >>  >> restrict that the number of border nodes must be 2.
 >>  >
 >>  >exactly my point.
 >>  >
 >>  >there are lot's of "outside the scope" statement so
 >>  >imho you should have in this document a problem space
 >>  >section and a reduced problem space section that you
 >>  >actually cover by the analysis
 >>  >
 >>  >>  >> However, when there are more than two border nodes, we need
 >>  >>  >> to pick up a
 >>  >>  >> good pair of border nodes. Please see my separate email to
 >>  >>  >> Meral which
 >>  >>  >> shows such an example.
 >>  >>  >
 >>  >>  >idem keep in mind here that enlarging the problem
 >>  >>  >space and have a preferential selection between N
 >>  >>  >possible inter-domain links but achieve a non-
 >>  >>  >blocking situation is the base objective
 >>  >>  >
 >>  >>  >>  >2. when computation is not simultaneous per domain
 >>  >> (independently of
 >>  >>  >>  >whether sequentially distributed or centralized) and does
 >>  >>  >> not result in
 >>  >>  >>  >strict hops only (implicitly or explcitly), the only thing
 >>  >>  >> that remains
 >>  >>  >>  >possible is to condition the first LSP setup with
 >>  >>  >> additional constraints
 >>  >>  >>  >during its establishment
 >>  >>  >>
 >>  >>  >> I am not sure whether I understand correctly, but if
 >>  >> border nodes are
 >>  >>  >> already selected, the only thing that remains is to select
 >>  >>  >> the route within
 >>  >>  >> each domain.
 >>  >>  >
 >>  >>  >yes and the question boils down to the point mentioned
 >>  >>  >where intra-domain path comp. would result in blocking
 >>  >>  >the other
 >>  >>  >
 >>  >>  >i don't see any answer to the below point ? which is at
 >>  >>  >the end the reason of my comment - this doc bundles the
 >>  >>  >protocol independent analysis with a protocol dependent
 >>  >>  >analysis in the latter case one should consider possible
 >>  >>  >solution space and not pre-assume any specific limitation
 >>  >>
 >>  >> I think this document is based on existing framework (or
 >>  >> schemes), which is
 >>  >> RFC4726. RFC4726 states several schemes for inter-domain TE,
 >>  >> like domain
 >>  >> boundary computation (per-domain path computation) and PCE-based
 >>  >> computation (inter-domain collaborative path computation).
 >>  >
 >>  >apparently, this is not what's assumed in section 1.5
 >>  >
 >>  >"The description in this document of diverse LSP setup is
 >> agnostic in
 >>  >relation to the signaling option used, unless otherwise specified."
 >>
 >> Well, this is about signaling.
 >>
 >> In addition, what it says is that most description is
 >> agnostic to signaling
 >> options (i.e., schemes are well-applicable to various
 >> signaling options),
 >> not that the document is restricting that description should
 >> be agnostic to
 >> signaling options.
 >>
 >> Please look at the begining of section 1.3.
 >>
 >>     This document analyzes various schemes to realize
 >> Multiprotocol Label
 >>     Switching (MPLS) and Generalized MPLS (GMPLS) LSP
 >> recovery in multi-
 >>     domain networks based on the existing framework for
 >> multi-domain LSP
 >>     setup [RFC4726].
 >>
 >>  >> I think this document is not heavily dependent on protocols
 >>  >> (but dependent on existing framework).
 >>  >
 >>  >i should have been more specific, it does not dig into
 >>  >the signaling protocol details but pre-assumes that the
 >>  >exchanges for path comp. purposes would be exclusively
 >>  >based on PCE (if you look at the above comment you will
 >>  >see that such assumption is protocol dependent)
 >>
 >> For exchanges for path computation request/reply before
 >> signaling, yes, we
 >> mostly assume PCE, since PCE is, to my best knowledge, a
 >> well-described
 >> framework for inter-domain TE in RFC4726.
 >>
 >> There are other path computation techniques described in
 >> RFC4726, and we
 >> include such schemes as well. Please see Section 3.2, "Per
 >> domain path
 >> computation or inter-domain collaborative path computation" bullet.
 >>
 >>  >> - Is there any missing scheme (other than listed in
 >> sections 4 and 5)?
 >>  >
 >>  >a scheme that makes use of parallel associated segments
 >>  >(in each AS/area) before both end-to-end LSPs are setup
 >>
 >> I am not sure, but is this what section 4.3.2 says?
 >>
 >> If no, can you give me a reference where such framework is
 >> described (e.g.,
 >> in RFC4726)?
 >>
 >>
 >> Thanks,
 >> Tomonori
 >>
 >>  >> - Is there anything to add/modify for some schemes?
 >>  >> - Or something else?
 >>  >
 >>  >above, i mentioned the need for a section that is more
 >>  >specific about what the document covers in its analysis
 >>  >
 >>  >that analysis must be agnostic to the PC exchange and
 >>  >better see what are the key elements not wrt what these
 >>  >exchanges are involving (see point 1 here above) in
 >>  >terms of needed protocol mechanisms
 >>  >
 >>  >after this you can dig in the PC protocol details and
 >>  >other mechanisms that are existing or not.
 >>  >
 >>  >thanks,
 >>  >-d.
 >>  >> Thanks,
 >>  >> Tomonori
 >>  >>
 >>  >>  >thanks,
 >>  >>  >-d.
 >>  >>  >
 >>  >>  >> Thanks,
 >>  >>  >> Tomonori
 >>  >>  >>
 >>  >>  >>  >this would for me streamline this analysis in a protocol
 >>  >>  >> independent way
 >>  >>  >>  >(observe that point 2 is totally independent of whether
 >>  >>  >> PCEs are used or
 >>  >>  >>  >not)
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>  >now if a protocol analysis needs to be done it needs to
 >>  >>  >> account for call
 >>  >>  >>  >segments in which case and compared to BRPC the
 >>  >> discussion would be
 >>  >>  >>  >about sequential computation along the downstream or the
 >>  >>  >> upstream (or
 >>  >>  >>  >combination)
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>  >thanks,
 >>  >>  >>  >-d.
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>  >> -----Original Message-----
 >>  >>  >>  >> From: [e-mail]
 >>  >>  >>  >> [mailto:[e-mail]] On Behalf Of
 >> Tomonori TAKEDA
 >>  >>  >>  >> Sent: Monday, July 09, 2007 4:04 AM
 >>  >>  >>  >> To: [e-mail]
 >>  >>  >>  >> Subject: Fwd: I-D
 >>  >>  >>  >>
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >>  >>
 >>  >>  >>  >> Hi,
 >>  >>  >>  >>
 >>  >>  >>  >> A new version of inter-domain recovery analysis
 >> I-D have been
 >>  >>  >>  >> published.
 >>  >>  >>  >>
 >>  >>  >>  >> Here are major changes:
 >>  >>  >>  >> - Added text on security considerations section
 >>  >>  >>  >> - Cleaned up text marked "for further study"
 >> (various places)
 >>  >>  >>  >> - Added a reference to [PCEP-XRO]
 >>  >>  >>  >> - Enhanced text on computing diverse paths
 >> sequentially with
 >>  >>  >>  >> confidentiality
 >>  >>  >>  >>    (Section 5.4.1)
 >>  >>  >>  >> - Moved "terminology" section into "introduction" section
 >>  >>  >>  >> - Removed manageability considerations section
 >>  >>  >>  >> - Polished text
 >>  >>  >>  >>
 >>  >>  >>  >> Authors believe the document is now completed and
 >> ready for
 >>  >>  >>  >> WG last call.
 >>  >>  >>  >>
 >>  >>  >>  >> Thanks,
 >>  >>  >>  >> Tomonori
 >>  >>  >>  >>
 >>  >>  >>  >>  >To: [e-mail]
 >>  >>  >>  >>  >From: [e-mail]
 >>  >>  >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >>  >>  >>  >X-Spam-Score: 0.0 (/)
 >>  >>  >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >>  >>  >>  >Cc: [e-mail]
 >>  >>  >>  >>  >Subject: I-D
 >>  >>  >>  >>
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >>  >>  >X-BeenThere: [e-mail]
 >>  >>  >>  >>  >X-Mailman-Version: 2.1.5
 >>  >>  >>  >>  >Reply-To: [e-mail]
 >>  >>  >>  >>  >List-Id: i-d-announce.ietf.org
 >>  >>  >>  >>  >List-Unsubscribe:
 >>  >>  >>  >>
 >>  >>  >>  >>
 >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >>  >>  >> :[e-mail]?subject=unsubscribe>
 >>  >>  >>  >>  >List-Archive:
 >> <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >>  >>  >>  >List-Post: <mailto:[e-mail]>
 >>  >>  >>  >>  >List-Help:
 >>  >> <mailto:[e-mail]?subject=help>
 >>  >>  >>  >>  >List-Subscribe:
 >>  >>  >>  >>
 >>  >>  >>  >>
 >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >>  >>  >> :[e-mail]?subject=subscribe>
 >>  >>  >>  >>  >X-Junkmail: UCE(35)
 >>  >>  >>  >>  >X-Junkmail-Status: score=35/10,
 >> host=sfs2.omr.ecl.ntt.co.jp
 >>  >>  >>  >>  >X-Junkmail-SD-Raw:
 >>  >>  >>  >>
 >>  >>  >>  >>
 >> >score=suspect(0),refid=str=0001.0A090207.468E8745.0129,ss=2,f
 >>  >>  >>  >> gs=0,ip=156.154.16.145,so=2007-03-13
 >>  >>  >>  >>
 >>  >>  >>  >>  >10:31:19,dmn=5.3.14/2007-05-31
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >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		: Analysis of Inter-domain Label
 >>  >>  >>  >> Switched Path (LSP) Recovery
 >>  >>  >>  >>  >	Author(s)	: T. Takeda, et al.
 >>  >>  >>  >>  >	Filename	:
 >>  >>  >>  >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >>  >>  >	Pages		: 23
 >>  >>  >>  >>  >	Date		: 2007-7-6
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >This document analyzes various schemes to realize
 >>  >>  >>  >> Multiprotocol Label
 >>  >>  >>  >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label
 >>  >>  >> Switched Path
 >>  >>  >>  >>  >   (LSP) recovery in multi-domain networks based on
 >>  >> the existing
 >>  >>  >>  >>  >   framework for multi-domain LSPs.
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >   The main focus for this document is on establishing
 >>  >>  >> end-to-end
 >>  >>  >>  >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain
 >>  >>  >>  >> networks. It
 >>  >>  >>  >>  >   presents various diverse LSP setup schemes based
 >>  >> on existing
 >>  >>  >>  >>  >   functional elements.
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >A URL for this Internet-Draft is:
 >>  >>  >>  >>
 >>  >>  >>  >>
 >> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
 >>  >>  >>  >> main-recovery-analysis-01.txt
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >To remove yourself from the I-D Announcement list, send
 >>  >>  >> a message to
 >>  >>  >>  >>  >[e-mail] with the word
 >> unsubscribe in
 >>  >>  >>  >> the body of
 >>  >>  >>  >>  >the message.
 >>  >>  >>  >>  >You can also visit
 >>  >>  >>  >> https://www1.ietf.org/mailman/listinfo/I-D-announce
 >>  >>  >>  >>  >to change your subscription settings.
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >Internet-Drafts are also available by anonymous FTP.
 >>  >>  >> Login with the
 >>  >>  >>  >>  >username "anonymous" and a password of your e-mail
 >>  >>  >> address. After
 >>  >>  >>  >>  >logging in, type "cd internet-drafts" and then
 >>  >>  >>  >>  >"get
 >>  >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >A list of Internet-Drafts directories can be found in
 >>  >>  >>  >>  >http://www.ietf.org/shadow.html
 >>  >>  >>  >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >Internet-Drafts can also be obtained by e-mail.
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >Send a message to:
 >>  >>  >>  >>  >	[e-mail].
 >>  >>  >>  >>  >In the body type:
 >>  >>  >>  >>  >	"FILE
 >>  >>  >>  >>
 >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
 >>  >>  >>  >> is-01.txt".
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >NOTE:	The mail server at ietf.org can return
 >>  >> the document in
 >>  >>  >>  >>  >	MIME-encoded form by using the "mpack" utility.
 >>  >>  >>  To use this
 >>  >>  >>  >>  >	feature, insert the command "ENCODING mime"
 >>  >>  >> before the "FILE"
 >>  >>  >>  >>  >	command.  To decode the response(s), you will
 >>  >>  >> need "munpack" or
 >>  >>  >>  >>  >	a MIME-compliant mail reader.
 >> Different MIME-compliant
 >>  >>  >>  >> mail readers
 >>  >>  >>  >>  >	exhibit different behavior, especially
 >> when dealing with
 >>  >>  >>  >>  >	"multipart" MIME messages (i.e. documents which
 >>  >>  >> have been split
 >>  >>  >>  >>  >	up into multiple messages), so check your local
 >>  >>  >> documentation on
 >>  >>  >>  >>  >	how to manipulate these messages.
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >Below is the data which will enable a MIME
 >>  >> compliant mail reader
 >>  >>  >>  >>  >implementation to automatically retrieve the ASCII
 >>  >>  >> version of the
 >>  >>  >>  >>  >Internet-Draft.
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >Content-Type: text/plain
 >>  >>  >>  >>  >Content-ID: <[e-mail]>
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >ENCODING mime
 >>  >>  >>  >>  >FILE
 >>  >>  >>  >>
 >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
 >>  >>  >>  >> is-01.txt
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do>>
 >>  >>  >> main-recovery-analysis-01.txt>
 >>  >>  >>  >>  >_______________________________________________
 >>  >>  >>  >>  >I-D-Announce mailing list
 >>  >>  >>  >>  >[e-mail]
 >>  >>  >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >>  >>
 >>  >>  >>
 >>  >>
 >>  >>
 >>  >>
 >>
 >>
 >> 





Envelope-to: [e-mail]
Delivery-date: Fri, 13 Jul 2007 07:45:34 +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: I-D     ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Date: Fri, 13 Jul 2007 09:43:23 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D     ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Thread-Index: AcfFCdQHGXjgOzpoQ+WjOGwLqlL5RgAFu7tA
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Tomonori TAKEDA" <[e-mail]>, <[e-mail]>

hi tomonori

well ok, the whole discussion point boils down from=20
your side as i don't depart from RFC 4726 that is=20
informational in nature ?

was 4726 expected to be forward looking ? knowing=20
there are no placeholders at IETF ?

4726 states=20

"the aim of this document is not to detail each of those techniques,
 which are covered in separate documents referenced from the sections
 of this document that introduce the techniques, but rather to propose
 a framework for inter-domain MPLS Traffic Engineering."

it does not state that nothing prevents additional
techniques to complement existing mechanisms known
at the time that RFC was produced

-d.

=20

> -----Original Message-----
> From: Tomonori TAKEDA [mailto:[e-mail]]=20
> Sent: Friday, July 13, 2007 6:53 AM
> To: PAPADIMITRIOU Dimitri; [e-mail]
> Subject: RE: I-D=20
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt=20
>=20
> Hi Dimitri,
>=20
> Please see in-line.
>=20
> At 16:24 07/07/12, PAPADIMITRIOU Dimitri wrote:
>  >hi tomonori,
>  >
>  >> -----Original Message-----
>  >> From: Tomonori TAKEDA [mailto:[e-mail]]
>  >> Sent: Thursday, July 12, 2007 6:34 AM
>  >> To: PAPADIMITRIOU Dimitri; [e-mail]
>  >> Subject: RE: I-D
>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>
>  >> Hi Dimitri,
>  >>
>  >> Please see in-line.
>  >>
>  >> At 19:54 07/07/10, PAPADIMITRIOU Dimitri wrote:
>  >>  >hi tomonori - see inline
>  >>  >
>  >>  >> -----Original Message-----
>  >>  >> From: Tomonori TAKEDA [mailto:[e-mail]]
>  >>  >> Sent: Tuesday, July 10, 2007 9:51 AM
>  >>  >> To: PAPADIMITRIOU Dimitri; [e-mail]
>  >>  >> Subject: RE: I-D
>  >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >>
>  >>  >> Hi Dimitri,
>  >>  >>
>  >>  >> Thanks for your comments.
>  >>  >>
>  >>  >> Please see in-line.
>  >>  >>
>  >>  >> At 06:10 07/07/10, PAPADIMITRIOU Dimitri wrote:
>  >>  >>  >tomonori
>  >>  >>  >
>  >>  >>  >
>  >>  >>  >reading through this doc still unclear to me why there is
>  >>  >> no statement
>  >>  >>  >that says (at the end) that the sole issue is due to
>  >> the fact that
>  >>  >>  >ingress node do not see both protecting and working LSPs
>  >>  >> (by definition
>  >>  >>  >of diversity) and therefore across that domain, mechanisms
>  >>  >> are needed:
>  >>  >>  >
>  >>  >>  >
>  >>  >>  >1. since the problem is only considered in its linear
>  >> version and
>  >>  >>  >associated protecting and working LSP are are both
>  >>  >> following the same
>  >>  >>  >sequence, one needs to resolve the intra-domain/intra-AS
>  >>  >> trap issue (at
>  >>  >>  >the SRLG/node/ link level) and prevent that that two
>  >>  >> ingress nodes (of
>  >>  >>  >the same domain) do not select the same egress node (of
>  >>  >> that domain) to
>  >>  >>  >reach the next domain for both protecting and working LSP ?
>  >>  >>
>  >>  >> This is true when there are only two border nodes (ingress
>  >>  >> and egress) for
>  >>  >> each domain (well, SRLG diversity where nodes/links in
>  >>  >> different domains
>  >>  >> belong to the same SRLG is a bit hard, though).
>  >>  >
>  >>  >this is what the diagrams and text infers
>  >>  >
>  >>  >generalizing the number of edges/inter-connection
>  >>  >adds an additional constraints (select 2 among N)
>  >>
>  >> Section 1.3 and section 2 state the problem space. This
>  >> document does not
>  >> restrict that the number of border nodes must be 2.
>  >
>  >exactly my point.
>  >
>  >there are lot's of "outside the scope" statement so
>  >imho you should have in this document a problem space
>  >section and a reduced problem space section that you
>  >actually cover by the analysis
>  >
>  >>  >> However, when there are more than two border nodes, we need
>  >>  >> to pick up a
>  >>  >> good pair of border nodes. Please see my separate email to
>  >>  >> Meral which
>  >>  >> shows such an example.
>  >>  >
>  >>  >idem keep in mind here that enlarging the problem
>  >>  >space and have a preferential selection between N
>  >>  >possible inter-domain links but achieve a non-
>  >>  >blocking situation is the base objective
>  >>  >
>  >>  >>  >2. when computation is not simultaneous per domain
>  >> (independently of
>  >>  >>  >whether sequentially distributed or centralized) and does
>  >>  >> not result in
>  >>  >>  >strict hops only (implicitly or explcitly), the only thing
>  >>  >> that remains
>  >>  >>  >possible is to condition the first LSP setup with
>  >>  >> additional constraints
>  >>  >>  >during its establishment
>  >>  >>
>  >>  >> I am not sure whether I understand correctly, but if
>  >> border nodes are
>  >>  >> already selected, the only thing that remains is to select
>  >>  >> the route within
>  >>  >> each domain.
>  >>  >
>  >>  >yes and the question boils down to the point mentioned
>  >>  >where intra-domain path comp. would result in blocking
>  >>  >the other
>  >>  >
>  >>  >i don't see any answer to the below point ? which is at
>  >>  >the end the reason of my comment - this doc bundles the
>  >>  >protocol independent analysis with a protocol dependent
>  >>  >analysis in the latter case one should consider possible
>  >>  >solution space and not pre-assume any specific limitation
>  >>
>  >> I think this document is based on existing framework (or
>  >> schemes), which is
>  >> RFC4726. RFC4726 states several schemes for inter-domain TE,
>  >> like domain
>  >> boundary computation (per-domain path computation) and PCE-based
>  >> computation (inter-domain collaborative path computation).
>  >
>  >apparently, this is not what's assumed in section 1.5
>  >
>  >"The description in this document of diverse LSP setup is=20
> agnostic in
>  >relation to the signaling option used, unless otherwise specified."
>=20
> Well, this is about signaling.
>=20
> In addition, what it says is that most description is=20
> agnostic to signaling=20
> options (i.e., schemes are well-applicable to various=20
> signaling options),=20
> not that the document is restricting that description should=20
> be agnostic to=20
> signaling options.
>=20
> Please look at the begining of section 1.3.
>=20
>     This document analyzes various schemes to realize=20
> Multiprotocol Label
>     Switching (MPLS) and Generalized MPLS (GMPLS) LSP=20
> recovery in multi-
>     domain networks based on the existing framework for=20
> multi-domain LSP
>     setup [RFC4726].
>=20
>  >> I think this document is not heavily dependent on protocols
>  >> (but dependent on existing framework).
>  >
>  >i should have been more specific, it does not dig into
>  >the signaling protocol details but pre-assumes that the
>  >exchanges for path comp. purposes would be exclusively
>  >based on PCE (if you look at the above comment you will
>  >see that such assumption is protocol dependent)
>=20
> For exchanges for path computation request/reply before=20
> signaling, yes, we=20
> mostly assume PCE, since PCE is, to my best knowledge, a=20
> well-described=20
> framework for inter-domain TE in RFC4726.
>=20
> There are other path computation techniques described in=20
> RFC4726, and we=20
> include such schemes as well. Please see Section 3.2, "Per=20
> domain path=20
> computation or inter-domain collaborative path computation" bullet.
>=20
>  >> - Is there any missing scheme (other than listed in=20
> sections 4 and 5)?
>  >
>  >a scheme that makes use of parallel associated segments
>  >(in each AS/area) before both end-to-end LSPs are setup
>=20
> I am not sure, but is this what section 4.3.2 says?
>=20
> If no, can you give me a reference where such framework is=20
> described (e.g.,=20
> in RFC4726)?
>=20
>=20
> Thanks,
> Tomonori
>=20
>  >> - Is there anything to add/modify for some schemes?
>  >> - Or something else?
>  >
>  >above, i mentioned the need for a section that is more
>  >specific about what the document covers in its analysis
>  >
>  >that analysis must be agnostic to the PC exchange and
>  >better see what are the key elements not wrt what these
>  >exchanges are involving (see point 1 here above) in
>  >terms of needed protocol mechanisms
>  >
>  >after this you can dig in the PC protocol details and
>  >other mechanisms that are existing or not.
>  >
>  >thanks,
>  >-d.
>  >> Thanks,
>  >> Tomonori
>  >>
>  >>  >thanks,
>  >>  >-d.
>  >>  >
>  >>  >> Thanks,
>  >>  >> Tomonori
>  >>  >>
>  >>  >>  >this would for me streamline this analysis in a protocol
>  >>  >> independent way
>  >>  >>  >(observe that point 2 is totally independent of whether
>  >>  >> PCEs are used or
>  >>  >>  >not)
>  >>  >>  >
>  >>  >>  >
>  >>  >>  >now if a protocol analysis needs to be done it needs to
>  >>  >> account for call
>  >>  >>  >segments in which case and compared to BRPC the
>  >> discussion would be
>  >>  >>  >about sequential computation along the downstream or the
>  >>  >> upstream (or
>  >>  >>  >combination)
>  >>  >>  >
>  >>  >>  >
>  >>  >>  >thanks,
>  >>  >>  >-d.
>  >>  >>  >
>  >>  >>  >
>  >>  >>  >
>  >>  >>  >
>  >>  >>  >
>  >>  >>  >
>  >>  >>  >> -----Original Message-----
>  >>  >>  >> From: [e-mail]
>  >>  >>  >> [mailto:[e-mail]] On Behalf Of=20
> Tomonori TAKEDA
>  >>  >>  >> Sent: Monday, July 09, 2007 4:04 AM
>  >>  >>  >> To: [e-mail]
>  >>  >>  >> Subject: Fwd: I-D
>  >>  >>  >>=20
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >>  >>
>  >>  >>  >> Hi,
>  >>  >>  >>
>  >>  >>  >> A new version of inter-domain recovery analysis=20
> I-D have been
>  >>  >>  >> published.
>  >>  >>  >>
>  >>  >>  >> Here are major changes:
>  >>  >>  >> - Added text on security considerations section
>  >>  >>  >> - Cleaned up text marked "for further study"=20
> (various places)
>  >>  >>  >> - Added a reference to [PCEP-XRO]
>  >>  >>  >> - Enhanced text on computing diverse paths=20
> sequentially with
>  >>  >>  >> confidentiality
>  >>  >>  >>    (Section 5.4.1)
>  >>  >>  >> - Moved "terminology" section into "introduction" section
>  >>  >>  >> - Removed manageability considerations section
>  >>  >>  >> - Polished text
>  >>  >>  >>
>  >>  >>  >> Authors believe the document is now completed and=20
> ready for
>  >>  >>  >> WG last call.
>  >>  >>  >>
>  >>  >>  >> Thanks,
>  >>  >>  >> Tomonori
>  >>  >>  >>
>  >>  >>  >>  >To: [e-mail]
>  >>  >>  >>  >From: [e-mail]
>  >>  >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >>  >>  >>  >X-Spam-Score: 0.0 (/)
>  >>  >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >>  >>  >>  >Cc: [e-mail]
>  >>  >>  >>  >Subject: I-D
>  >>  >>  >>=20
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >>  >>  >X-BeenThere: [e-mail]
>  >>  >>  >>  >X-Mailman-Version: 2.1.5
>  >>  >>  >>  >Reply-To: [e-mail]
>  >>  >>  >>  >List-Id: i-d-announce.ietf.org
>  >>  >>  >>  >List-Unsubscribe:
>  >>  >>  >>
>  >>  >>  >>=20
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >>  >>  >> :[e-mail]?subject=3Dunsubscribe>
>  >>  >>  >>  >List-Archive:=20
> <http://www1.ietf.org/pipermail/i-d-announce>
>  >>  >>  >>  >List-Post: <mailto:[e-mail]>
>  >>  >>  >>  >List-Help:
>  >> <mailto:[e-mail]?subject=3Dhelp>
>  >>  >>  >>  >List-Subscribe:
>  >>  >>  >>
>  >>  >>  >>=20
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >>  >>  >> :[e-mail]?subject=3Dsubscribe>
>  >>  >>  >>  >X-Junkmail: UCE(35)
>  >>  >>  >>  >X-Junkmail-Status: score=3D35/10,=20
> host=3Dsfs2.omr.ecl.ntt.co.jp
>  >>  >>  >>  >X-Junkmail-SD-Raw:
>  >>  >>  >>
>  >>  >>  >>=20
> >score=3Dsuspect(0),refid=3Dstr=3D0001.0A090207.468E8745.0129,ss=3D2,f
>  >>  >>  >> gs=3D0,ip=3D156.154.16.145,so=3D2007-03-13
>  >>  >>  >>
>  >>  >>  >>  >10:31:19,dmn=3D5.3.14/2007-05-31
>  >>  >>  >>  >
>  >>  >>  >>  >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		: Analysis of Inter-domain Label
>  >>  >>  >> Switched Path (LSP) Recovery
>  >>  >>  >>  >	Author(s)	: T. Takeda, et al.
>  >>  >>  >>  >	Filename	:
>  >>  >>  >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >>  >>  >	Pages		: 23
>  >>  >>  >>  >	Date		: 2007-7-6
>  >>  >>  >>  >
>  >>  >>  >>  >This document analyzes various schemes to realize
>  >>  >>  >> Multiprotocol Label
>  >>  >>  >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label
>  >>  >> Switched Path
>  >>  >>  >>  >   (LSP) recovery in multi-domain networks based on
>  >> the existing
>  >>  >>  >>  >   framework for multi-domain LSPs.
>  >>  >>  >>  >
>  >>  >>  >>  >   The main focus for this document is on establishing
>  >>  >> end-to-end
>  >>  >>  >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain
>  >>  >>  >> networks. It
>  >>  >>  >>  >   presents various diverse LSP setup schemes based
>  >> on existing
>  >>  >>  >>  >   functional elements.
>  >>  >>  >>  >
>  >>  >>  >>  >A URL for this Internet-Draft is:
>  >>  >>  >>
>  >>  >>  >>=20
> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
>  >>  >>  >> main-recovery-analysis-01.txt
>  >>  >>  >>  >
>  >>  >>  >>  >To remove yourself from the I-D Announcement list, send
>  >>  >> a message to
>  >>  >>  >>  >[e-mail] with the word=20
> unsubscribe in
>  >>  >>  >> the body of
>  >>  >>  >>  >the message.
>  >>  >>  >>  >You can also visit
>  >>  >>  >> https://www1.ietf.org/mailman/listinfo/I-D-announce
>  >>  >>  >>  >to change your subscription settings.
>  >>  >>  >>  >
>  >>  >>  >>  >Internet-Drafts are also available by anonymous FTP.
>  >>  >> Login with the
>  >>  >>  >>  >username "anonymous" and a password of your e-mail
>  >>  >> address. After
>  >>  >>  >>  >logging in, type "cd internet-drafts" and then
>  >>  >>  >>  >"get
>  >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
>  >>  >>  >>  >
>  >>  >>  >>  >A list of Internet-Drafts directories can be found in
>  >>  >>  >>  >http://www.ietf.org/shadow.html
>  >>  >>  >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  >>  >>  >>  >
>  >>  >>  >>  >Internet-Drafts can also be obtained by e-mail.
>  >>  >>  >>  >
>  >>  >>  >>  >Send a message to:
>  >>  >>  >>  >	[e-mail].
>  >>  >>  >>  >In the body type:
>  >>  >>  >>  >	"FILE
>  >>  >>  >>=20
> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
>  >>  >>  >> is-01.txt".
>  >>  >>  >>  >
>  >>  >>  >>  >NOTE:	The mail server at ietf.org can return
>  >> the document in
>  >>  >>  >>  >	MIME-encoded form by using the "mpack" utility.
>  >>  >>  To use this
>  >>  >>  >>  >	feature, insert the command "ENCODING mime"
>  >>  >> before the "FILE"
>  >>  >>  >>  >	command.  To decode the response(s), you will
>  >>  >> need "munpack" or
>  >>  >>  >>  >	a MIME-compliant mail reader. =20
> Different MIME-compliant
>  >>  >>  >> mail readers
>  >>  >>  >>  >	exhibit different behavior, especially=20
> when dealing with
>  >>  >>  >>  >	"multipart" MIME messages (i.e. documents which
>  >>  >> have been split
>  >>  >>  >>  >	up into multiple messages), so check your local
>  >>  >> documentation on
>  >>  >>  >>  >	how to manipulate these messages.
>  >>  >>  >>  >
>  >>  >>  >>  >Below is the data which will enable a MIME
>  >> compliant mail reader
>  >>  >>  >>  >implementation to automatically retrieve the ASCII
>  >>  >> version of the
>  >>  >>  >>  >Internet-Draft.
>  >>  >>  >>  >
>  >>  >>  >>  >Content-Type: text/plain
>  >>  >>  >>  >Content-ID: <[e-mail]>
>  >>  >>  >>  >
>  >>  >>  >>  >ENCODING mime
>  >>  >>  >>  >FILE
>  >>  >>  >>=20
> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
>  >>  >>  >> is-01.txt
>  >>  >>  >>  >
>  >>  >>  >>  >
>  >>  >>  >>
>  >>  >>  >>
>  >> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do>>
>  >>  >> main-recovery-analysis-01.txt>
>  >>  >>  >>  >_______________________________________________
>  >>  >>  >>  >I-D-Announce mailing list
>  >>  >>  >>  >[e-mail]
>  >>  >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>
>  >>  >>
>  >>
>  >>
>  >>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 13 Jul 2007 04:56:45 +0000
Message-Id: <[e-mail]>
Date: Fri, 13 Jul 2007 13:53:28 +0900
To: "PAPADIMITRIOU Dimitri" <[e-mail]>, <[e-mail]>
From: Tomonori TAKEDA <[e-mail]>
Subject: RE: I-D    ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dimitri,

Please see in-line.

At 16:24 07/07/12, PAPADIMITRIOU Dimitri wrote:
 >hi tomonori,
 >
 >> -----Original Message-----
 >> From: Tomonori TAKEDA [mailto:[e-mail]]
 >> Sent: Thursday, July 12, 2007 6:34 AM
 >> To: PAPADIMITRIOU Dimitri; [e-mail]
 >> Subject: RE: I-D
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>
 >> Hi Dimitri,
 >>
 >> Please see in-line.
 >>
 >> At 19:54 07/07/10, PAPADIMITRIOU Dimitri wrote:
 >>  >hi tomonori - see inline
 >>  >
 >>  >> -----Original Message-----
 >>  >> From: Tomonori TAKEDA [mailto:[e-mail]]
 >>  >> Sent: Tuesday, July 10, 2007 9:51 AM
 >>  >> To: PAPADIMITRIOU Dimitri; [e-mail]
 >>  >> Subject: RE: I-D
 >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>
 >>  >> Hi Dimitri,
 >>  >>
 >>  >> Thanks for your comments.
 >>  >>
 >>  >> Please see in-line.
 >>  >>
 >>  >> At 06:10 07/07/10, PAPADIMITRIOU Dimitri wrote:
 >>  >>  >tomonori
 >>  >>  >
 >>  >>  >
 >>  >>  >reading through this doc still unclear to me why there is
 >>  >> no statement
 >>  >>  >that says (at the end) that the sole issue is due to
 >> the fact that
 >>  >>  >ingress node do not see both protecting and working LSPs
 >>  >> (by definition
 >>  >>  >of diversity) and therefore across that domain, mechanisms
 >>  >> are needed:
 >>  >>  >
 >>  >>  >
 >>  >>  >1. since the problem is only considered in its linear
 >> version and
 >>  >>  >associated protecting and working LSP are are both
 >>  >> following the same
 >>  >>  >sequence, one needs to resolve the intra-domain/intra-AS
 >>  >> trap issue (at
 >>  >>  >the SRLG/node/ link level) and prevent that that two
 >>  >> ingress nodes (of
 >>  >>  >the same domain) do not select the same egress node (of
 >>  >> that domain) to
 >>  >>  >reach the next domain for both protecting and working LSP ?
 >>  >>
 >>  >> This is true when there are only two border nodes (ingress
 >>  >> and egress) for
 >>  >> each domain (well, SRLG diversity where nodes/links in
 >>  >> different domains
 >>  >> belong to the same SRLG is a bit hard, though).
 >>  >
 >>  >this is what the diagrams and text infers
 >>  >
 >>  >generalizing the number of edges/inter-connection
 >>  >adds an additional constraints (select 2 among N)
 >>
 >> Section 1.3 and section 2 state the problem space. This
 >> document does not
 >> restrict that the number of border nodes must be 2.
 >
 >exactly my point.
 >
 >there are lot's of "outside the scope" statement so
 >imho you should have in this document a problem space
 >section and a reduced problem space section that you
 >actually cover by the analysis
 >
 >>  >> However, when there are more than two border nodes, we need
 >>  >> to pick up a
 >>  >> good pair of border nodes. Please see my separate email to
 >>  >> Meral which
 >>  >> shows such an example.
 >>  >
 >>  >idem keep in mind here that enlarging the problem
 >>  >space and have a preferential selection between N
 >>  >possible inter-domain links but achieve a non-
 >>  >blocking situation is the base objective
 >>  >
 >>  >>  >2. when computation is not simultaneous per domain
 >> (independently of
 >>  >>  >whether sequentially distributed or centralized) and does
 >>  >> not result in
 >>  >>  >strict hops only (implicitly or explcitly), the only thing
 >>  >> that remains
 >>  >>  >possible is to condition the first LSP setup with
 >>  >> additional constraints
 >>  >>  >during its establishment
 >>  >>
 >>  >> I am not sure whether I understand correctly, but if
 >> border nodes are
 >>  >> already selected, the only thing that remains is to select
 >>  >> the route within
 >>  >> each domain.
 >>  >
 >>  >yes and the question boils down to the point mentioned
 >>  >where intra-domain path comp. would result in blocking
 >>  >the other
 >>  >
 >>  >i don't see any answer to the below point ? which is at
 >>  >the end the reason of my comment - this doc bundles the
 >>  >protocol independent analysis with a protocol dependent
 >>  >analysis in the latter case one should consider possible
 >>  >solution space and not pre-assume any specific limitation
 >>
 >> I think this document is based on existing framework (or
 >> schemes), which is
 >> RFC4726. RFC4726 states several schemes for inter-domain TE,
 >> like domain
 >> boundary computation (per-domain path computation) and PCE-based
 >> computation (inter-domain collaborative path computation).
 >
 >apparently, this is not what's assumed in section 1.5
 >
 >"The description in this document of diverse LSP setup is agnostic in
 >relation to the signaling option used, unless otherwise specified."

Well, this is about signaling.

In addition, what it says is that most description is agnostic to signaling 
options (i.e., schemes are well-applicable to various signaling options), 
not that the document is restricting that description should be agnostic to 
signaling options.

Please look at the begining of section 1.3.

    This document analyzes various schemes to realize Multiprotocol Label
    Switching (MPLS) and Generalized MPLS (GMPLS) LSP recovery in multi-
    domain networks based on the existing framework for multi-domain LSP
    setup [RFC4726].

 >> I think this document is not heavily dependent on protocols
 >> (but dependent on existing framework).
 >
 >i should have been more specific, it does not dig into
 >the signaling protocol details but pre-assumes that the
 >exchanges for path comp. purposes would be exclusively
 >based on PCE (if you look at the above comment you will
 >see that such assumption is protocol dependent)

For exchanges for path computation request/reply before signaling, yes, we 
mostly assume PCE, since PCE is, to my best knowledge, a well-described 
framework for inter-domain TE in RFC4726.

There are other path computation techniques described in RFC4726, and we 
include such schemes as well. Please see Section 3.2, "Per domain path 
computation or inter-domain collaborative path computation" bullet.

 >> - Is there any missing scheme (other than listed in sections 4 and 5)?
 >
 >a scheme that makes use of parallel associated segments
 >(in each AS/area) before both end-to-end LSPs are setup

I am not sure, but is this what section 4.3.2 says?

If no, can you give me a reference where such framework is described (e.g., 
in RFC4726)?


Thanks,
Tomonori

 >> - Is there anything to add/modify for some schemes?
 >> - Or something else?
 >
 >above, i mentioned the need for a section that is more
 >specific about what the document covers in its analysis
 >
 >that analysis must be agnostic to the PC exchange and
 >better see what are the key elements not wrt what these
 >exchanges are involving (see point 1 here above) in
 >terms of needed protocol mechanisms
 >
 >after this you can dig in the PC protocol details and
 >other mechanisms that are existing or not.
 >
 >thanks,
 >-d.
 >> Thanks,
 >> Tomonori
 >>
 >>  >thanks,
 >>  >-d.
 >>  >
 >>  >> Thanks,
 >>  >> Tomonori
 >>  >>
 >>  >>  >this would for me streamline this analysis in a protocol
 >>  >> independent way
 >>  >>  >(observe that point 2 is totally independent of whether
 >>  >> PCEs are used or
 >>  >>  >not)
 >>  >>  >
 >>  >>  >
 >>  >>  >now if a protocol analysis needs to be done it needs to
 >>  >> account for call
 >>  >>  >segments in which case and compared to BRPC the
 >> discussion would be
 >>  >>  >about sequential computation along the downstream or the
 >>  >> upstream (or
 >>  >>  >combination)
 >>  >>  >
 >>  >>  >
 >>  >>  >thanks,
 >>  >>  >-d.
 >>  >>  >
 >>  >>  >
 >>  >>  >
 >>  >>  >
 >>  >>  >
 >>  >>  >
 >>  >>  >> -----Original Message-----
 >>  >>  >> From: [e-mail]
 >>  >>  >> [mailto:[e-mail]] On Behalf Of Tomonori TAKEDA
 >>  >>  >> Sent: Monday, July 09, 2007 4:04 AM
 >>  >>  >> To: [e-mail]
 >>  >>  >> Subject: Fwd: I-D
 >>  >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >>
 >>  >>  >> Hi,
 >>  >>  >>
 >>  >>  >> A new version of inter-domain recovery analysis I-D have been
 >>  >>  >> published.
 >>  >>  >>
 >>  >>  >> Here are major changes:
 >>  >>  >> - Added text on security considerations section
 >>  >>  >> - Cleaned up text marked "for further study" (various places)
 >>  >>  >> - Added a reference to [PCEP-XRO]
 >>  >>  >> - Enhanced text on computing diverse paths sequentially with
 >>  >>  >> confidentiality
 >>  >>  >>    (Section 5.4.1)
 >>  >>  >> - Moved "terminology" section into "introduction" section
 >>  >>  >> - Removed manageability considerations section
 >>  >>  >> - Polished text
 >>  >>  >>
 >>  >>  >> Authors believe the document is now completed and ready for
 >>  >>  >> WG last call.
 >>  >>  >>
 >>  >>  >> Thanks,
 >>  >>  >> Tomonori
 >>  >>  >>
 >>  >>  >>  >To: [e-mail]
 >>  >>  >>  >From: [e-mail]
 >>  >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >>  >>  >X-Spam-Score: 0.0 (/)
 >>  >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >>  >>  >Cc: [e-mail]
 >>  >>  >>  >Subject: I-D
 >>  >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >>  >X-BeenThere: [e-mail]
 >>  >>  >>  >X-Mailman-Version: 2.1.5
 >>  >>  >>  >Reply-To: [e-mail]
 >>  >>  >>  >List-Id: i-d-announce.ietf.org
 >>  >>  >>  >List-Unsubscribe:
 >>  >>  >>
 >>  >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >>  >> :[e-mail]?subject=unsubscribe>
 >>  >>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >>  >>  >List-Post: <mailto:[e-mail]>
 >>  >>  >>  >List-Help:
 >> <mailto:[e-mail]?subject=help>
 >>  >>  >>  >List-Subscribe:
 >>  >>  >>
 >>  >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >>  >> :[e-mail]?subject=subscribe>
 >>  >>  >>  >X-Junkmail: UCE(35)
 >>  >>  >>  >X-Junkmail-Status: score=35/10, host=sfs2.omr.ecl.ntt.co.jp
 >>  >>  >>  >X-Junkmail-SD-Raw:
 >>  >>  >>
 >>  >>  >> >score=suspect(0),refid=str=0001.0A090207.468E8745.0129,ss=2,f
 >>  >>  >> gs=0,ip=156.154.16.145,so=2007-03-13
 >>  >>  >>
 >>  >>  >>  >10:31:19,dmn=5.3.14/2007-05-31
 >>  >>  >>  >
 >>  >>  >>  >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		: Analysis of Inter-domain Label
 >>  >>  >> Switched Path (LSP) Recovery
 >>  >>  >>  >	Author(s)	: T. Takeda, et al.
 >>  >>  >>  >	Filename	:
 >>  >>  >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >>  >	Pages		: 23
 >>  >>  >>  >	Date		: 2007-7-6
 >>  >>  >>  >
 >>  >>  >>  >This document analyzes various schemes to realize
 >>  >>  >> Multiprotocol Label
 >>  >>  >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label
 >>  >> Switched Path
 >>  >>  >>  >   (LSP) recovery in multi-domain networks based on
 >> the existing
 >>  >>  >>  >   framework for multi-domain LSPs.
 >>  >>  >>  >
 >>  >>  >>  >   The main focus for this document is on establishing
 >>  >> end-to-end
 >>  >>  >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain
 >>  >>  >> networks. It
 >>  >>  >>  >   presents various diverse LSP setup schemes based
 >> on existing
 >>  >>  >>  >   functional elements.
 >>  >>  >>  >
 >>  >>  >>  >A URL for this Internet-Draft is:
 >>  >>  >>
 >>  >>  >> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
 >>  >>  >> main-recovery-analysis-01.txt
 >>  >>  >>  >
 >>  >>  >>  >To remove yourself from the I-D Announcement list, send
 >>  >> a message to
 >>  >>  >>  >[e-mail] with the word unsubscribe in
 >>  >>  >> the body of
 >>  >>  >>  >the message.
 >>  >>  >>  >You can also visit
 >>  >>  >> https://www1.ietf.org/mailman/listinfo/I-D-announce
 >>  >>  >>  >to change your subscription settings.
 >>  >>  >>  >
 >>  >>  >>  >Internet-Drafts are also available by anonymous FTP.
 >>  >> Login with the
 >>  >>  >>  >username "anonymous" and a password of your e-mail
 >>  >> address. After
 >>  >>  >>  >logging in, type "cd internet-drafts" and then
 >>  >>  >>  >"get
 >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >>  >>  >>  >
 >>  >>  >>  >A list of Internet-Drafts directories can be found in
 >>  >>  >>  >http://www.ietf.org/shadow.html
 >>  >>  >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >>  >>  >>  >
 >>  >>  >>  >Internet-Drafts can also be obtained by e-mail.
 >>  >>  >>  >
 >>  >>  >>  >Send a message to:
 >>  >>  >>  >	[e-mail].
 >>  >>  >>  >In the body type:
 >>  >>  >>  >	"FILE
 >>  >>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
 >>  >>  >> is-01.txt".
 >>  >>  >>  >
 >>  >>  >>  >NOTE:	The mail server at ietf.org can return
 >> the document in
 >>  >>  >>  >	MIME-encoded form by using the "mpack" utility.
 >>  >>  To use this
 >>  >>  >>  >	feature, insert the command "ENCODING mime"
 >>  >> before the "FILE"
 >>  >>  >>  >	command.  To decode the response(s), you will
 >>  >> need "munpack" or
 >>  >>  >>  >	a MIME-compliant mail reader.  Different MIME-compliant
 >>  >>  >> mail readers
 >>  >>  >>  >	exhibit different behavior, especially when dealing with
 >>  >>  >>  >	"multipart" MIME messages (i.e. documents which
 >>  >> have been split
 >>  >>  >>  >	up into multiple messages), so check your local
 >>  >> documentation on
 >>  >>  >>  >	how to manipulate these messages.
 >>  >>  >>  >
 >>  >>  >>  >Below is the data which will enable a MIME
 >> compliant mail reader
 >>  >>  >>  >implementation to automatically retrieve the ASCII
 >>  >> version of the
 >>  >>  >>  >Internet-Draft.
 >>  >>  >>  >
 >>  >>  >>  >Content-Type: text/plain
 >>  >>  >>  >Content-ID: <[e-mail]>
 >>  >>  >>  >
 >>  >>  >>  >ENCODING mime
 >>  >>  >>  >FILE
 >>  >>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
 >>  >>  >> is-01.txt
 >>  >>  >>  >
 >>  >>  >>  >
 >>  >>  >>
 >>  >>  >>
 >> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do>>
 >>  >> main-recovery-analysis-01.txt>
 >>  >>  >>  >_______________________________________________
 >>  >>  >>  >I-D-Announce mailing list
 >>  >>  >>  >[e-mail]
 >>  >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>  >>  >>
 >>  >>  >>
 >>  >>  >>
 >>  >>  >>
 >>  >>
 >>  >>
 >>
 >>
 >> 





Envelope-to: [e-mail]
Delivery-date: Thu, 12 Jul 2007 07:26:08 +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: I-D    ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Date: Thu, 12 Jul 2007 09:24:03 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D    ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Thread-Index: AcfEPeXE2rThCoTASmqMRGXt5e6WSgAEJ/Dg
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Tomonori TAKEDA" <[e-mail]>, <[e-mail]>

hi tomonori,

> -----Original Message-----
> From: Tomonori TAKEDA [mailto:[e-mail]]=20
> Sent: Thursday, July 12, 2007 6:34 AM
> To: PAPADIMITRIOU Dimitri; [e-mail]
> Subject: RE: I-D=20
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt=20
>=20
> Hi Dimitri,
>=20
> Please see in-line.
>=20
> At 19:54 07/07/10, PAPADIMITRIOU Dimitri wrote:
>  >hi tomonori - see inline
>  >
>  >> -----Original Message-----
>  >> From: Tomonori TAKEDA [mailto:[e-mail]]
>  >> Sent: Tuesday, July 10, 2007 9:51 AM
>  >> To: PAPADIMITRIOU Dimitri; [e-mail]
>  >> Subject: RE: I-D
>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>
>  >> Hi Dimitri,
>  >>
>  >> Thanks for your comments.
>  >>
>  >> Please see in-line.
>  >>
>  >> At 06:10 07/07/10, PAPADIMITRIOU Dimitri wrote:
>  >>  >tomonori
>  >>  >
>  >>  >
>  >>  >reading through this doc still unclear to me why there is
>  >> no statement
>  >>  >that says (at the end) that the sole issue is due to=20
> the fact that
>  >>  >ingress node do not see both protecting and working LSPs
>  >> (by definition
>  >>  >of diversity) and therefore across that domain, mechanisms
>  >> are needed:
>  >>  >
>  >>  >
>  >>  >1. since the problem is only considered in its linear=20
> version and
>  >>  >associated protecting and working LSP are are both
>  >> following the same
>  >>  >sequence, one needs to resolve the intra-domain/intra-AS
>  >> trap issue (at
>  >>  >the SRLG/node/ link level) and prevent that that two
>  >> ingress nodes (of
>  >>  >the same domain) do not select the same egress node (of
>  >> that domain) to
>  >>  >reach the next domain for both protecting and working LSP ?
>  >>
>  >> This is true when there are only two border nodes (ingress
>  >> and egress) for
>  >> each domain (well, SRLG diversity where nodes/links in
>  >> different domains
>  >> belong to the same SRLG is a bit hard, though).
>  >
>  >this is what the diagrams and text infers
>  >
>  >generalizing the number of edges/inter-connection
>  >adds an additional constraints (select 2 among N)
>=20
> Section 1.3 and section 2 state the problem space. This=20
> document does not=20
> restrict that the number of border nodes must be 2.

exactly my point.=20

there are lot's of "outside the scope" statement so
imho you should have in this document a problem space=20
section and a reduced problem space section that you
actually cover by the analysis

>  >> However, when there are more than two border nodes, we need
>  >> to pick up a
>  >> good pair of border nodes. Please see my separate email to
>  >> Meral which
>  >> shows such an example.
>  >
>  >idem keep in mind here that enlarging the problem
>  >space and have a preferential selection between N
>  >possible inter-domain links but achieve a non-
>  >blocking situation is the base objective
>  >
>  >>  >2. when computation is not simultaneous per domain=20
> (independently of
>  >>  >whether sequentially distributed or centralized) and does
>  >> not result in
>  >>  >strict hops only (implicitly or explcitly), the only thing
>  >> that remains
>  >>  >possible is to condition the first LSP setup with
>  >> additional constraints
>  >>  >during its establishment
>  >>
>  >> I am not sure whether I understand correctly, but if=20
> border nodes are
>  >> already selected, the only thing that remains is to select
>  >> the route within
>  >> each domain.
>  >
>  >yes and the question boils down to the point mentioned
>  >where intra-domain path comp. would result in blocking
>  >the other
>  >
>  >i don't see any answer to the below point ? which is at
>  >the end the reason of my comment - this doc bundles the
>  >protocol independent analysis with a protocol dependent
>  >analysis in the latter case one should consider possible
>  >solution space and not pre-assume any specific limitation
>=20
> I think this document is based on existing framework (or=20
> schemes), which is=20
> RFC4726. RFC4726 states several schemes for inter-domain TE,=20
> like domain=20
> boundary computation (per-domain path computation) and PCE-based=20
> computation (inter-domain collaborative path computation).

apparently, this is not what's assumed in section 1.5

"The description in this document of diverse LSP setup is agnostic in=20
relation to the signaling option used, unless otherwise specified."=20

> I think this document is not heavily dependent on protocols=20
> (but dependent on existing framework).

i should have been more specific, it does not dig into
the signaling protocol details but pre-assumes that the
exchanges for path comp. purposes would be exclusively
based on PCE (if you look at the above comment you will
see that such assumption is protocol dependent)

> - Is there any missing scheme (other than listed in sections 4 and 5)?

a scheme that makes use of parallel associated segments=20
(in each AS/area) before both end-to-end LSPs are setup

> - Is there anything to add/modify for some schemes?
> - Or something else?

above, i mentioned the need for a section that is more
specific about what the document covers in its analysis

that analysis must be agnostic to the PC exchange and
better see what are the key elements not wrt what these
exchanges are involving (see point 1 here above) in
terms of needed protocol mechanisms=20

after this you can dig in the PC protocol details and
other mechanisms that are existing or not.

thanks,
-d.
> Thanks,
> Tomonori
>=20
>  >thanks,
>  >-d.
>  >
>  >> Thanks,
>  >> Tomonori
>  >>
>  >>  >this would for me streamline this analysis in a protocol
>  >> independent way
>  >>  >(observe that point 2 is totally independent of whether
>  >> PCEs are used or
>  >>  >not)
>  >>  >
>  >>  >
>  >>  >now if a protocol analysis needs to be done it needs to
>  >> account for call
>  >>  >segments in which case and compared to BRPC the=20
> discussion would be
>  >>  >about sequential computation along the downstream or the
>  >> upstream (or
>  >>  >combination)
>  >>  >
>  >>  >
>  >>  >thanks,
>  >>  >-d.
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>  >> -----Original Message-----
>  >>  >> From: [e-mail]
>  >>  >> [mailto:[e-mail]] On Behalf Of Tomonori TAKEDA
>  >>  >> Sent: Monday, July 09, 2007 4:04 AM
>  >>  >> To: [e-mail]
>  >>  >> Subject: Fwd: I-D
>  >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >>
>  >>  >> Hi,
>  >>  >>
>  >>  >> A new version of inter-domain recovery analysis I-D have been
>  >>  >> published.
>  >>  >>
>  >>  >> Here are major changes:
>  >>  >> - Added text on security considerations section
>  >>  >> - Cleaned up text marked "for further study" (various places)
>  >>  >> - Added a reference to [PCEP-XRO]
>  >>  >> - Enhanced text on computing diverse paths sequentially with
>  >>  >> confidentiality
>  >>  >>    (Section 5.4.1)
>  >>  >> - Moved "terminology" section into "introduction" section
>  >>  >> - Removed manageability considerations section
>  >>  >> - Polished text
>  >>  >>
>  >>  >> Authors believe the document is now completed and ready for
>  >>  >> WG last call.
>  >>  >>
>  >>  >> Thanks,
>  >>  >> Tomonori
>  >>  >>
>  >>  >>  >To: [e-mail]
>  >>  >>  >From: [e-mail]
>  >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >>  >>  >X-Spam-Score: 0.0 (/)
>  >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >>  >>  >Cc: [e-mail]
>  >>  >>  >Subject: I-D
>  >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >>  >X-BeenThere: [e-mail]
>  >>  >>  >X-Mailman-Version: 2.1.5
>  >>  >>  >Reply-To: [e-mail]
>  >>  >>  >List-Id: i-d-announce.ietf.org
>  >>  >>  >List-Unsubscribe:
>  >>  >>
>  >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >>  >> :[e-mail]?subject=3Dunsubscribe>
>  >>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>  >>  >>  >List-Post: <mailto:[e-mail]>
>  >>  >>  >List-Help:=20
> <mailto:[e-mail]?subject=3Dhelp>
>  >>  >>  >List-Subscribe:
>  >>  >>
>  >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >>  >> :[e-mail]?subject=3Dsubscribe>
>  >>  >>  >X-Junkmail: UCE(35)
>  >>  >>  >X-Junkmail-Status: score=3D35/10, =
host=3Dsfs2.omr.ecl.ntt.co.jp
>  >>  >>  >X-Junkmail-SD-Raw:
>  >>  >>
>  >>  >> =
>score=3Dsuspect(0),refid=3Dstr=3D0001.0A090207.468E8745.0129,ss=3D2,f
>  >>  >> gs=3D0,ip=3D156.154.16.145,so=3D2007-03-13
>  >>  >>
>  >>  >>  >10:31:19,dmn=3D5.3.14/2007-05-31
>  >>  >>  >
>  >>  >>  >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		: Analysis of Inter-domain Label
>  >>  >> Switched Path (LSP) Recovery
>  >>  >>  >	Author(s)	: T. Takeda, et al.
>  >>  >>  >	Filename	:
>  >>  >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >>  >	Pages		: 23
>  >>  >>  >	Date		: 2007-7-6
>  >>  >>  >
>  >>  >>  >This document analyzes various schemes to realize
>  >>  >> Multiprotocol Label
>  >>  >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label
>  >> Switched Path
>  >>  >>  >   (LSP) recovery in multi-domain networks based on=20
> the existing
>  >>  >>  >   framework for multi-domain LSPs.
>  >>  >>  >
>  >>  >>  >   The main focus for this document is on establishing
>  >> end-to-end
>  >>  >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain
>  >>  >> networks. It
>  >>  >>  >   presents various diverse LSP setup schemes based=20
> on existing
>  >>  >>  >   functional elements.
>  >>  >>  >
>  >>  >>  >A URL for this Internet-Draft is:
>  >>  >>
>  >>  >> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
>  >>  >> main-recovery-analysis-01.txt
>  >>  >>  >
>  >>  >>  >To remove yourself from the I-D Announcement list, send
>  >> a message to
>  >>  >>  >[e-mail] with the word unsubscribe in
>  >>  >> the body of
>  >>  >>  >the message.
>  >>  >>  >You can also visit
>  >>  >> https://www1.ietf.org/mailman/listinfo/I-D-announce
>  >>  >>  >to change your subscription settings.
>  >>  >>  >
>  >>  >>  >Internet-Drafts are also available by anonymous FTP.
>  >> Login with the
>  >>  >>  >username "anonymous" and a password of your e-mail
>  >> address. After
>  >>  >>  >logging in, type "cd internet-drafts" and then
>  >>  >>  >"get=20
> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
>  >>  >>  >
>  >>  >>  >A list of Internet-Drafts directories can be found in
>  >>  >>  >http://www.ietf.org/shadow.html
>  >>  >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  >>  >>  >
>  >>  >>  >Internet-Drafts can also be obtained by e-mail.
>  >>  >>  >
>  >>  >>  >Send a message to:
>  >>  >>  >	[e-mail].
>  >>  >>  >In the body type:
>  >>  >>  >	"FILE
>  >>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
>  >>  >> is-01.txt".
>  >>  >>  >
>  >>  >>  >NOTE:	The mail server at ietf.org can return=20
> the document in
>  >>  >>  >	MIME-encoded form by using the "mpack" utility.
>  >>  To use this
>  >>  >>  >	feature, insert the command "ENCODING mime"
>  >> before the "FILE"
>  >>  >>  >	command.  To decode the response(s), you will
>  >> need "munpack" or
>  >>  >>  >	a MIME-compliant mail reader.  Different MIME-compliant
>  >>  >> mail readers
>  >>  >>  >	exhibit different behavior, especially when dealing with
>  >>  >>  >	"multipart" MIME messages (i.e. documents which
>  >> have been split
>  >>  >>  >	up into multiple messages), so check your local
>  >> documentation on
>  >>  >>  >	how to manipulate these messages.
>  >>  >>  >
>  >>  >>  >Below is the data which will enable a MIME=20
> compliant mail reader
>  >>  >>  >implementation to automatically retrieve the ASCII
>  >> version of the
>  >>  >>  >Internet-Draft.
>  >>  >>  >
>  >>  >>  >Content-Type: text/plain
>  >>  >>  >Content-ID: <[e-mail]>
>  >>  >>  >
>  >>  >>  >ENCODING mime
>  >>  >>  >FILE
>  >>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
>  >>  >> is-01.txt
>  >>  >>  >
>  >>  >>  >
>  >>  >>
>  >>  >>=20
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do>>
>  >> main-recovery-analysis-01.txt>
>  >>  >>  >_______________________________________________
>  >>  >>  >I-D-Announce mailing list
>  >>  >>  >[e-mail]
>  >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
>  >>  >>
>  >>  >>
>  >>  >>
>  >>  >>
>  >>
>  >>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Thu, 12 Jul 2007 04:36:55 +0000
Message-Id: <[e-mail]>
Date: Thu, 12 Jul 2007 13:33:43 +0900
To: "PAPADIMITRIOU Dimitri" <[e-mail]>, <[e-mail]>
From: Tomonori TAKEDA <[e-mail]>
Subject: RE: I-D   ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dimitri,

Please see in-line.

At 19:54 07/07/10, PAPADIMITRIOU Dimitri wrote:
 >hi tomonori - see inline
 >
 >> -----Original Message-----
 >> From: Tomonori TAKEDA [mailto:[e-mail]]
 >> Sent: Tuesday, July 10, 2007 9:51 AM
 >> To: PAPADIMITRIOU Dimitri; [e-mail]
 >> Subject: RE: I-D
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>
 >> Hi Dimitri,
 >>
 >> Thanks for your comments.
 >>
 >> Please see in-line.
 >>
 >> At 06:10 07/07/10, PAPADIMITRIOU Dimitri wrote:
 >>  >tomonori
 >>  >
 >>  >
 >>  >reading through this doc still unclear to me why there is
 >> no statement
 >>  >that says (at the end) that the sole issue is due to the fact that
 >>  >ingress node do not see both protecting and working LSPs
 >> (by definition
 >>  >of diversity) and therefore across that domain, mechanisms
 >> are needed:
 >>  >
 >>  >
 >>  >1. since the problem is only considered in its linear version and
 >>  >associated protecting and working LSP are are both
 >> following the same
 >>  >sequence, one needs to resolve the intra-domain/intra-AS
 >> trap issue (at
 >>  >the SRLG/node/ link level) and prevent that that two
 >> ingress nodes (of
 >>  >the same domain) do not select the same egress node (of
 >> that domain) to
 >>  >reach the next domain for both protecting and working LSP ?
 >>
 >> This is true when there are only two border nodes (ingress
 >> and egress) for
 >> each domain (well, SRLG diversity where nodes/links in
 >> different domains
 >> belong to the same SRLG is a bit hard, though).
 >
 >this is what the diagrams and text infers
 >
 >generalizing the number of edges/inter-connection
 >adds an additional constraints (select 2 among N)

Section 1.3 and section 2 state the problem space. This document does not 
restrict that the number of border nodes must be 2.

 >> However, when there are more than two border nodes, we need
 >> to pick up a
 >> good pair of border nodes. Please see my separate email to
 >> Meral which
 >> shows such an example.
 >
 >idem keep in mind here that enlarging the problem
 >space and have a preferential selection between N
 >possible inter-domain links but achieve a non-
 >blocking situation is the base objective
 >
 >>  >2. when computation is not simultaneous per domain (independently of
 >>  >whether sequentially distributed or centralized) and does
 >> not result in
 >>  >strict hops only (implicitly or explcitly), the only thing
 >> that remains
 >>  >possible is to condition the first LSP setup with
 >> additional constraints
 >>  >during its establishment
 >>
 >> I am not sure whether I understand correctly, but if border nodes are
 >> already selected, the only thing that remains is to select
 >> the route within
 >> each domain.
 >
 >yes and the question boils down to the point mentioned
 >where intra-domain path comp. would result in blocking
 >the other
 >
 >i don't see any answer to the below point ? which is at
 >the end the reason of my comment - this doc bundles the
 >protocol independent analysis with a protocol dependent
 >analysis in the latter case one should consider possible
 >solution space and not pre-assume any specific limitation

I think this document is based on existing framework (or schemes), which is 
RFC4726. RFC4726 states several schemes for inter-domain TE, like domain 
boundary computation (per-domain path computation) and PCE-based 
computation (inter-domain collaborative path computation).

I think this document is not heavily dependent on protocols (but dependent 
on existing framework).

- Is there any missing scheme (other than listed in sections 4 and 5)?
- Is there anything to add/modify for some schemes?
- Or something else?


Thanks,
Tomonori

 >thanks,
 >-d.
 >
 >> Thanks,
 >> Tomonori
 >>
 >>  >this would for me streamline this analysis in a protocol
 >> independent way
 >>  >(observe that point 2 is totally independent of whether
 >> PCEs are used or
 >>  >not)
 >>  >
 >>  >
 >>  >now if a protocol analysis needs to be done it needs to
 >> account for call
 >>  >segments in which case and compared to BRPC the discussion would be
 >>  >about sequential computation along the downstream or the
 >> upstream (or
 >>  >combination)
 >>  >
 >>  >
 >>  >thanks,
 >>  >-d.
 >>  >
 >>  >
 >>  >
 >>  >
 >>  >
 >>  >
 >>  >> -----Original Message-----
 >>  >> From: [e-mail]
 >>  >> [mailto:[e-mail]] On Behalf Of Tomonori TAKEDA
 >>  >> Sent: Monday, July 09, 2007 4:04 AM
 >>  >> To: [e-mail]
 >>  >> Subject: Fwd: I-D
 >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>
 >>  >> Hi,
 >>  >>
 >>  >> A new version of inter-domain recovery analysis I-D have been
 >>  >> published.
 >>  >>
 >>  >> Here are major changes:
 >>  >> - Added text on security considerations section
 >>  >> - Cleaned up text marked "for further study" (various places)
 >>  >> - Added a reference to [PCEP-XRO]
 >>  >> - Enhanced text on computing diverse paths sequentially with
 >>  >> confidentiality
 >>  >>    (Section 5.4.1)
 >>  >> - Moved "terminology" section into "introduction" section
 >>  >> - Removed manageability considerations section
 >>  >> - Polished text
 >>  >>
 >>  >> Authors believe the document is now completed and ready for
 >>  >> WG last call.
 >>  >>
 >>  >> Thanks,
 >>  >> Tomonori
 >>  >>
 >>  >>  >To: [e-mail]
 >>  >>  >From: [e-mail]
 >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >>  >X-Spam-Score: 0.0 (/)
 >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >>  >Cc: [e-mail]
 >>  >>  >Subject: I-D
 >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >X-BeenThere: [e-mail]
 >>  >>  >X-Mailman-Version: 2.1.5
 >>  >>  >Reply-To: [e-mail]
 >>  >>  >List-Id: i-d-announce.ietf.org
 >>  >>  >List-Unsubscribe:
 >>  >>
 >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >> :[e-mail]?subject=unsubscribe>
 >>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >>  >List-Post: <mailto:[e-mail]>
 >>  >>  >List-Help: <mailto:[e-mail]?subject=help>
 >>  >>  >List-Subscribe:
 >>  >>
 >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >> :[e-mail]?subject=subscribe>
 >>  >>  >X-Junkmail: UCE(35)
 >>  >>  >X-Junkmail-Status: score=35/10, host=sfs2.omr.ecl.ntt.co.jp
 >>  >>  >X-Junkmail-SD-Raw:
 >>  >>
 >>  >> >score=suspect(0),refid=str=0001.0A090207.468E8745.0129,ss=2,f
 >>  >> gs=0,ip=156.154.16.145,so=2007-03-13
 >>  >>
 >>  >>  >10:31:19,dmn=5.3.14/2007-05-31
 >>  >>  >
 >>  >>  >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		: Analysis of Inter-domain Label
 >>  >> Switched Path (LSP) Recovery
 >>  >>  >	Author(s)	: T. Takeda, et al.
 >>  >>  >	Filename	:
 >>  >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >	Pages		: 23
 >>  >>  >	Date		: 2007-7-6
 >>  >>  >
 >>  >>  >This document analyzes various schemes to realize
 >>  >> Multiprotocol Label
 >>  >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label
 >> Switched Path
 >>  >>  >   (LSP) recovery in multi-domain networks based on the existing
 >>  >>  >   framework for multi-domain LSPs.
 >>  >>  >
 >>  >>  >   The main focus for this document is on establishing
 >> end-to-end
 >>  >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain
 >>  >> networks. It
 >>  >>  >   presents various diverse LSP setup schemes based on existing
 >>  >>  >   functional elements.
 >>  >>  >
 >>  >>  >A URL for this Internet-Draft is:
 >>  >>
 >>  >> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
 >>  >> main-recovery-analysis-01.txt
 >>  >>  >
 >>  >>  >To remove yourself from the I-D Announcement list, send
 >> a message to
 >>  >>  >[e-mail] with the word unsubscribe in
 >>  >> the body of
 >>  >>  >the message.
 >>  >>  >You can also visit
 >>  >> https://www1.ietf.org/mailman/listinfo/I-D-announce
 >>  >>  >to change your subscription settings.
 >>  >>  >
 >>  >>  >Internet-Drafts are also available by anonymous FTP.
 >> Login with the
 >>  >>  >username "anonymous" and a password of your e-mail
 >> address. After
 >>  >>  >logging in, type "cd internet-drafts" and then
 >>  >>  >"get draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >>  >>  >
 >>  >>  >A list of Internet-Drafts directories can be found in
 >>  >>  >http://www.ietf.org/shadow.html
 >>  >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >>  >>  >
 >>  >>  >Internet-Drafts can also be obtained by e-mail.
 >>  >>  >
 >>  >>  >Send a message to:
 >>  >>  >	[e-mail].
 >>  >>  >In the body type:
 >>  >>  >	"FILE
 >>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
 >>  >> is-01.txt".
 >>  >>  >
 >>  >>  >NOTE:	The mail server at ietf.org can return the document in
 >>  >>  >	MIME-encoded form by using the "mpack" utility.
 >>  To use this
 >>  >>  >	feature, insert the command "ENCODING mime"
 >> before the "FILE"
 >>  >>  >	command.  To decode the response(s), you will
 >> need "munpack" or
 >>  >>  >	a MIME-compliant mail reader.  Different MIME-compliant
 >>  >> mail readers
 >>  >>  >	exhibit different behavior, especially when dealing with
 >>  >>  >	"multipart" MIME messages (i.e. documents which
 >> have been split
 >>  >>  >	up into multiple messages), so check your local
 >> documentation on
 >>  >>  >	how to manipulate these messages.
 >>  >>  >
 >>  >>  >Below is the data which will enable a MIME compliant mail reader
 >>  >>  >implementation to automatically retrieve the ASCII
 >> version of the
 >>  >>  >Internet-Draft.
 >>  >>  >
 >>  >>  >Content-Type: text/plain
 >>  >>  >Content-ID: <[e-mail]>
 >>  >>  >
 >>  >>  >ENCODING mime
 >>  >>  >FILE
 >>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
 >>  >> is-01.txt
 >>  >>  >
 >>  >>  >
 >>  >>
 >>  >> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do>>
 >> main-recovery-analysis-01.txt>
 >>  >>  >_______________________________________________
 >>  >>  >I-D-Announce mailing list
 >>  >>  >[e-mail]
 >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>  >>
 >>  >>
 >>  >>
 >>  >>
 >>
 >> 





Envelope-to: [e-mail]
Delivery-date: Wed, 11 Jul 2007 18:18:05 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ted-mib-02.txt 
Message-Id: <[e-mail]>
Date: Wed, 11 Jul 2007 14:15:02 -0400

--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		: Traffic Engineering Database Management Information Base in support of GMPLS
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-ted-mib-02.txt
	Pages		: 24
	Date		: 2007-7-11
	
This memo defines the Management Information Base (MIB) objects in 
   order to manage traffic engineering database (TED) information with 
   extension in support of Multi-protocol label switching (MPLS) as well 
   as Generalized MPLS (GMPLS) for use with network management protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ted-mib-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ted-mib-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ted-mib-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 11 Jul 2007 01:31:03 +0000
Date: Wed, 11 Jul 2007 10:26:28 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: new draft about signaling for a bidirectionl lightpath
From: Hiroaki Harai <[e-mail]>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Diego

I think that every way you said enables a bidirectional lambda LSP
although every has different aspect (no extension, signaling ext.,
routing ext., and computation).

No. 2 is a signaling extension. Without upstream label set, our
proposal works well because each intermediate node selects only
lambdas that are available in both directions.  However, with upstream
label set (i.e., more extension), the applicability is expanded.

Anyway, I also feel the lambda switching is becoming interesting again
after available lambda-related components are increased.

Best regards,
- Hiroaki

From: "Diego Caviglia (GA/ERI)" <[e-mail]>
Subject: RE: new draft about signaling for a bidirectionl lightpath
Date: Tue, 10 Jul 2007 08:52:17 +0200
Message-ID: <[e-mail]=
icsson.se>

> Hi Hiroaki,
>            I think that this is a real problem that can be addressed =
in several way:
> =

> 1 Label set and Upstream label + crankback: this should works but of =
course is not optimal;
> 2 The way you proposed with Upstream label set;
> 3 A modification to the routing protocol in order to advertise the av=
ailable lambdas;
> 4 A centralized PCE approach adding manually (or via modified routing=
 protocols) the lambda availability
> =

> The above should covers the lambda continuity problem but not the opt=
ical impairments one.
> =

> Seems that after some years of sleeping the Lambda switching is becom=
ing interesting again there are several drafts on this topic.
> =

> Best regards
> =

> Diego
> =

> =

> -----Original Message-----
> From: Hiroaki Harai [mailto:[e-mail]] =

> Sent: sabato 7 luglio 2007 4.01
> To: Diego Caviglia (GA/ERI); [e-mail]
> Subject: Re: new draft about signaling for a bidirectionl lightpath
> =

> Hi, Diego.
> =

> I think the usage that you mentioned (using label set and upstream
> label) is not enough by the following two reasons.
> =

> 1. [Non-support of multiple lambdas] Upstream label object conveys
>    only ONE label, which is likely to face lack of the same lambda as=

>    that in the previous link. We have high blocking probability for
>    LSP setup. If we convey multiple lambdas for upstream, the
>    probability would be reduced significantly (but, we cannot convey)=
.=

> =

>    Someone may want to change lambda in Upstream Label into other
>    lambda among lambdas in the Label Set when the lambda in Upstream
>    Label is not acceptable further. However, according to Section 3.1=

>    of RFC 3473, if label in Upstream Label is not acceptable, PathErr=

>    is generated.  Different from Suggested Label, we have no chance t=
o
>    change. So, using Upstream Label is not enough.
> =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>    3.1 Procedures (RFC 3473)
>    The process of establishing a bidirectional LSP follows the
>    establishment of a unidirectional LSP with some additions. To
>    support bidirectional LSPs an Upstream_Label object is added to th=
e
>    Path message. The Upstream_Label object MUST indicate a label that=

>    is valid for forwarding at the time the Path message is sent.
>    When a Path message containing an Upstream_Label object is
>    received, the receiver first verifies that the upstream label is
>    acceptable. If the label is not acceptable, the receiver MUST issu=
e
>    a PathErr message with a "Routing problem/Unacceptable label value=
"
>    indication. The generated PathErr message MAY include an Acceptabl=
e
>    Label Set, see Section 4.1.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> =

> 2. [Keep flexibility] The same lambda on both directions may not
>    reqested for some bidirectional LSPs different from the case in
>    this draft. In this case, once we pose the same lambda constraint
>    against upstream label, we lose flexiblity to setup LSPs by
>    different lambda in each direction.
> =

> Best regards,
> - Hiroaki   =

> =

> =

> =

> From: "Diego Caviglia (GA/ERI)" <[e-mail]>
> Subject: RE: new draft about signaling for a bidirectionl lightpath
> Date: Fri, 6 Jul 2007 15:00:13 +0200
> Message-ID: <[e-mail].=
ericsson.se>
> =

> > =

> > Hi Hiroaki,
> >            Not clear to me why the mechanism using label set with t=
he same lambda as the Upstream label is not enough here.   =

> > =

> > BR
> > =

> > Diego
> > =

> > =

> > =

> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Hiroaki Harai
> > Sent: venerd=EC 6 luglio 2007 3.10
> > To: [e-mail]
> > Subject: new draft about signaling for a bidirectionl lightpath
> > =

> > Hi everyone,
> > =

> > We posted a new draft about GMPLS signaling for a bidirectional
> > lightpath setup as follows.
> > http://www.ietf.org/internet-drafts/draft-xu-rsvpte-bidir-wave-00.t=
xt
> > =

> > =3D=3D=3D=3D=3D=3D
> > Title   : Extensions to GMPLS RSVP-TE for Bidirectional Lightpath w=
ith
> >           the Same Wavelength
> > Authors : S. Xu, H. Harai, and D. King
> > Filename: draft-xu-rsvpte-bidir-wave-00.txt
> > 	=

> > Abstract: For bidirectional lightpaths provisioning, in the case of=

> > optical nodes that do not support wavelength conversion, it would b=
e
> > necessary to use the same wavelength along the route on each
> > direction. In certain optical network scenarios, the use of the sam=
e
> > wavelength on both directions would be advantageous.  For instance,=

> > some type of ROADMs may add/drop the same wavelength
> > simultaneously. In another case, the users' optical end nodes are
> > equipped with fixed-wavelength transponders.
> > =

> > This document describes extensions to RSVP-TE signaling for =

> > bidirectional wavelength lightpaths that require the same wavelengt=
h on =

> > both directions. By using an LSP_ATTRIBUTES object defined in [RFC4=
420], =

> > the extensions enable the new type lightpaths to support the low co=
st =

> > configuration at users' optical end nodes.
> > =3D=3D=3D=3D=3D=3D
> > =

> > We believe that selecting a single wavelength on both directions fo=
r a
> > bidirectional LSP is very real. And our suggestion in this draft is=
 a
> > simple one.
> > =

> > We appreciate your comments and feedbacks.
> > =

> > With best regards,
> > Hiroaki
> > =

> > -------
> > Hiroaki Harai, Ph.D. (http://nag.nict.go.jp/)
> > Network Architecture Group, New Generation Network Research Center
> > National Institute of Information and Communications Technology (NI=
CT), JAPAN.
> > Email: [e-mail];  Phone: [phone];  FAX: [phone]-=
6680
> > =

> > =

> =




Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jul 2007 20:16:29 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-04.txt 
Message-Id: <[e-mail]>
Date: Tue, 10 Jul 2007 16:15:01 -0400

--NextPart

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

	Title		: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks
	Author(s)	: Z. Ali, et al.
	Filename	: draft-ietf-ccamp-mpls-graceful-shutdown-04.txt
	Pages		: 11
	Date		: 2007-7-10
	
MPLS-TE Graceful Shutdown is a method for explicitly notifying 
   the nodes in a Traffic Engineering (TE) enabled network that the 
   TE capability on a link or on an entire Label Switching Router 
   (LSR) is going to be disabled. MPLS-TE graceful shutdown 
   mechanisms are tailored toward addressing planned outage in the 
   network.  
    
   This document provides requirements and protocol mechanisms to 
   reduce/eliminate traffic disruption in the event of a planned 
   shutdown of a network resource. These operations are equally 
   applicable to both MPLS and its Generalized MPLS (GMPLS) 
   extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-mpls-graceful-shutdown-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jul 2007 18:17:51 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-eval-03.txt 
Message-Id: <[e-mail]>
Date: Tue, 10 Jul 2007 14:15:01 -0400

--NextPart

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

	Title		: Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)
	Author(s)	: D. Papadimitriou, J. Le Roux
	Filename	: draft-ietf-ccamp-gmpls-mln-eval-03.txt
	Pages		: 15
	Date		: 2007-7-10
	
This document provides an evaluation of Generalized Multi-Protocol 
   Label Switching (GMPLS) protocols and mechanisms against the 
   requirements for Multi-Layer Networks (MLN) and Multi-Region Networks 
   (MRN). In addition, this document identifies areas where additional 
   protocol extensions or procedures are needed to satisfy these 
   requirements, and provides guidelines for potential extensions.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-mln-eval-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jul 2007 10:57:28 +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: I-D   ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Date: Tue, 10 Jul 2007 12:54:18 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D   ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Thread-Index: AcfCxxaIns/RwJMORnKWHcg9lV9evAAEK9Mg
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Tomonori TAKEDA" <[e-mail]>, <[e-mail]>

hi tomonori - see inline=20

> -----Original Message-----
> From: Tomonori TAKEDA [mailto:[e-mail]]=20
> Sent: Tuesday, July 10, 2007 9:51 AM
> To: PAPADIMITRIOU Dimitri; [e-mail]
> Subject: RE: I-D=20
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt=20
>=20
> Hi Dimitri,
>=20
> Thanks for your comments.
>=20
> Please see in-line.
>=20
> At 06:10 07/07/10, PAPADIMITRIOU Dimitri wrote:
>  >tomonori
>  >
>  >
>  >reading through this doc still unclear to me why there is=20
> no statement
>  >that says (at the end) that the sole issue is due to the fact that
>  >ingress node do not see both protecting and working LSPs=20
> (by definition
>  >of diversity) and therefore across that domain, mechanisms=20
> are needed:
>  >
>  >
>  >1. since the problem is only considered in its linear version and
>  >associated protecting and working LSP are are both=20
> following the same
>  >sequence, one needs to resolve the intra-domain/intra-AS=20
> trap issue (at
>  >the SRLG/node/ link level) and prevent that that two=20
> ingress nodes (of
>  >the same domain) do not select the same egress node (of=20
> that domain) to
>  >reach the next domain for both protecting and working LSP ?
>=20
> This is true when there are only two border nodes (ingress=20
> and egress) for=20
> each domain (well, SRLG diversity where nodes/links in=20
> different domains=20
> belong to the same SRLG is a bit hard, though).

this is what the diagrams and text infers

generalizing the number of edges/inter-connection
adds an additional constraints (select 2 among N)

> However, when there are more than two border nodes, we need=20
> to pick up a=20
> good pair of border nodes. Please see my separate email to=20
> Meral which=20
> shows such an example.

idem keep in mind here that enlarging the problem=20
space and have a preferential selection between N
possible inter-domain links but achieve a non-
blocking situation is the base objective=20

>  >2. when computation is not simultaneous per domain (independently of
>  >whether sequentially distributed or centralized) and does=20
> not result in
>  >strict hops only (implicitly or explcitly), the only thing=20
> that remains
>  >possible is to condition the first LSP setup with=20
> additional constraints
>  >during its establishment
>=20
> I am not sure whether I understand correctly, but if border nodes are=20
> already selected, the only thing that remains is to select=20
> the route within=20
> each domain.

yes and the question boils down to the point mentioned
where intra-domain path comp. would result in blocking
the other
=20
i don't see any answer to the below point ? which is at
the end the reason of my comment - this doc bundles the
protocol independent analysis with a protocol dependent
analysis in the latter case one should consider possible
solution space and not pre-assume any specific limitation

thanks,
-d.

> Thanks,
> Tomonori
>=20
>  >this would for me streamline this analysis in a protocol=20
> independent way
>  >(observe that point 2 is totally independent of whether=20
> PCEs are used or
>  >not)
>  >
>  >
>  >now if a protocol analysis needs to be done it needs to=20
> account for call
>  >segments in which case and compared to BRPC the discussion would be
>  >about sequential computation along the downstream or the=20
> upstream (or
>  >combination)
>  >
>  >
>  >thanks,
>  >-d.
>  >
>  >
>  >
>  >
>  >
>  >
>  >> -----Original Message-----
>  >> From: [e-mail]
>  >> [mailto:[e-mail]] On Behalf Of Tomonori TAKEDA
>  >> Sent: Monday, July 09, 2007 4:04 AM
>  >> To: [e-mail]
>  >> Subject: Fwd: I-D
>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>
>  >> Hi,
>  >>
>  >> A new version of inter-domain recovery analysis I-D have been
>  >> published.
>  >>
>  >> Here are major changes:
>  >> - Added text on security considerations section
>  >> - Cleaned up text marked "for further study" (various places)
>  >> - Added a reference to [PCEP-XRO]
>  >> - Enhanced text on computing diverse paths sequentially with
>  >> confidentiality
>  >>    (Section 5.4.1)
>  >> - Moved "terminology" section into "introduction" section
>  >> - Removed manageability considerations section
>  >> - Polished text
>  >>
>  >> Authors believe the document is now completed and ready for
>  >> WG last call.
>  >>
>  >> Thanks,
>  >> Tomonori
>  >>
>  >>  >To: [e-mail]
>  >>  >From: [e-mail]
>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >>  >X-Spam-Score: 0.0 (/)
>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >>  >Cc: [e-mail]
>  >>  >Subject: I-D
>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >X-BeenThere: [e-mail]
>  >>  >X-Mailman-Version: 2.1.5
>  >>  >Reply-To: [e-mail]
>  >>  >List-Id: i-d-announce.ietf.org
>  >>  >List-Unsubscribe:
>  >>
>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >> :[e-mail]?subject=3Dunsubscribe>
>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>  >>  >List-Post: <mailto:[e-mail]>
>  >>  >List-Help: <mailto:[e-mail]?subject=3Dhelp>
>  >>  >List-Subscribe:
>  >>
>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >> :[e-mail]?subject=3Dsubscribe>
>  >>  >X-Junkmail: UCE(35)
>  >>  >X-Junkmail-Status: score=3D35/10, host=3Dsfs2.omr.ecl.ntt.co.jp
>  >>  >X-Junkmail-SD-Raw:
>  >>
>  >> =
>score=3Dsuspect(0),refid=3Dstr=3D0001.0A090207.468E8745.0129,ss=3D2,f
>  >> gs=3D0,ip=3D156.154.16.145,so=3D2007-03-13
>  >>
>  >>  >10:31:19,dmn=3D5.3.14/2007-05-31
>  >>  >
>  >>  >A New Internet-Draft is available from the on-line=20
> Internet-Drafts
>  >>  >directories.
>  >>  >This draft is a work item of the Common Control and
>  >> Measurement Plane
>  >>  >Working Group of the IETF.
>  >>  >
>  >>  >	Title		: Analysis of Inter-domain Label
>  >> Switched Path (LSP) Recovery
>  >>  >	Author(s)	: T. Takeda, et al.
>  >>  >	Filename	:
>  >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >	Pages		: 23
>  >>  >	Date		: 2007-7-6
>  >>  >
>  >>  >This document analyzes various schemes to realize
>  >> Multiprotocol Label
>  >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label=20
> Switched Path
>  >>  >   (LSP) recovery in multi-domain networks based on the existing
>  >>  >   framework for multi-domain LSPs.
>  >>  >
>  >>  >   The main focus for this document is on establishing=20
> end-to-end
>  >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain
>  >> networks. It
>  >>  >   presents various diverse LSP setup schemes based on existing
>  >>  >   functional elements.
>  >>  >
>  >>  >A URL for this Internet-Draft is:
>  >>
>  >> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
>  >> main-recovery-analysis-01.txt
>  >>  >
>  >>  >To remove yourself from the I-D Announcement list, send=20
> a message to
>  >>  >[e-mail] with the word unsubscribe in
>  >> the body of
>  >>  >the message.
>  >>  >You can also visit
>  >> https://www1.ietf.org/mailman/listinfo/I-D-announce
>  >>  >to change your subscription settings.
>  >>  >
>  >>  >Internet-Drafts are also available by anonymous FTP.=20
> Login with the
>  >>  >username "anonymous" and a password of your e-mail=20
> address. After
>  >>  >logging in, type "cd internet-drafts" and then
>  >>  >"get draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
>  >>  >
>  >>  >A list of Internet-Drafts directories can be found in
>  >>  >http://www.ietf.org/shadow.html
>  >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  >>  >
>  >>  >Internet-Drafts can also be obtained by e-mail.
>  >>  >
>  >>  >Send a message to:
>  >>  >	[e-mail].
>  >>  >In the body type:
>  >>  >	"FILE
>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
>  >> is-01.txt".
>  >>  >
>  >>  >NOTE:	The mail server at ietf.org can return the document in
>  >>  >	MIME-encoded form by using the "mpack" utility.=20
>  To use this
>  >>  >	feature, insert the command "ENCODING mime"=20
> before the "FILE"
>  >>  >	command.  To decode the response(s), you will=20
> need "munpack" or
>  >>  >	a MIME-compliant mail reader.  Different MIME-compliant
>  >> mail readers
>  >>  >	exhibit different behavior, especially when dealing with
>  >>  >	"multipart" MIME messages (i.e. documents which=20
> have been split
>  >>  >	up into multiple messages), so check your local=20
> documentation on
>  >>  >	how to manipulate these messages.
>  >>  >
>  >>  >Below is the data which will enable a MIME compliant mail reader
>  >>  >implementation to automatically retrieve the ASCII=20
> version of the
>  >>  >Internet-Draft.
>  >>  >
>  >>  >Content-Type: text/plain
>  >>  >Content-ID: <[e-mail]>
>  >>  >
>  >>  >ENCODING mime
>  >>  >FILE
>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
>  >> is-01.txt
>  >>  >
>  >>  >
>  >>
>  >> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do>>=20
> main-recovery-analysis-01.txt>
>  >>  >_______________________________________________
>  >>  >I-D-Announce mailing list
>  >>  >[e-mail]
>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
>  >>
>  >>
>  >>
>  >>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jul 2007 07:51:54 +0000
Message-Id: <[e-mail]>
Date: Tue, 10 Jul 2007 16:50:46 +0900
To: "PAPADIMITRIOU Dimitri" <[e-mail]>, <[e-mail]>
From: Tomonori TAKEDA <[e-mail]>
Subject: RE: I-D  ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dimitri,

Thanks for your comments.

Please see in-line.

At 06:10 07/07/10, PAPADIMITRIOU Dimitri wrote:
 >tomonori
 >
 >
 >reading through this doc still unclear to me why there is no statement
 >that says (at the end) that the sole issue is due to the fact that
 >ingress node do not see both protecting and working LSPs (by definition
 >of diversity) and therefore across that domain, mechanisms are needed:
 >
 >
 >1. since the problem is only considered in its linear version and
 >associated protecting and working LSP are are both following the same
 >sequence, one needs to resolve the intra-domain/intra-AS trap issue (at
 >the SRLG/node/ link level) and prevent that that two ingress nodes (of
 >the same domain) do not select the same egress node (of that domain) to
 >reach the next domain for both protecting and working LSP ?

This is true when there are only two border nodes (ingress and egress) for 
each domain (well, SRLG diversity where nodes/links in different domains 
belong to the same SRLG is a bit hard, though).

However, when there are more than two border nodes, we need to pick up a 
good pair of border nodes. Please see my separate email to Meral which 
shows such an example.

 >2. when computation is not simultaneous per domain (independently of
 >whether sequentially distributed or centralized) and does not result in
 >strict hops only (implicitly or explcitly), the only thing that remains
 >possible is to condition the first LSP setup with additional constraints
 >during its establishment

I am not sure whether I understand correctly, but if border nodes are 
already selected, the only thing that remains is to select the route within 
each domain.

Thanks,
Tomonori

 >this would for me streamline this analysis in a protocol independent way
 >(observe that point 2 is totally independent of whether PCEs are used or
 >not)
 >
 >
 >now if a protocol analysis needs to be done it needs to account for call
 >segments in which case and compared to BRPC the discussion would be
 >about sequential computation along the downstream or the upstream (or
 >combination)
 >
 >
 >thanks,
 >-d.
 >
 >
 >
 >
 >
 >
 >> -----Original Message-----
 >> From: [e-mail]
 >> [mailto:[e-mail]] On Behalf Of Tomonori TAKEDA
 >> Sent: Monday, July 09, 2007 4:04 AM
 >> To: [e-mail]
 >> Subject: Fwd: I-D
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>
 >> Hi,
 >>
 >> A new version of inter-domain recovery analysis I-D have been
 >> published.
 >>
 >> Here are major changes:
 >> - Added text on security considerations section
 >> - Cleaned up text marked "for further study" (various places)
 >> - Added a reference to [PCEP-XRO]
 >> - Enhanced text on computing diverse paths sequentially with
 >> confidentiality
 >>    (Section 5.4.1)
 >> - Moved "terminology" section into "introduction" section
 >> - Removed manageability considerations section
 >> - Polished text
 >>
 >> Authors believe the document is now completed and ready for
 >> WG last call.
 >>
 >> Thanks,
 >> Tomonori
 >>
 >>  >To: [e-mail]
 >>  >From: [e-mail]
 >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >X-Spam-Score: 0.0 (/)
 >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >Cc: [e-mail]
 >>  >Subject: I-D
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >X-BeenThere: [e-mail]
 >>  >X-Mailman-Version: 2.1.5
 >>  >Reply-To: [e-mail]
 >>  >List-Id: i-d-announce.ietf.org
 >>  >List-Unsubscribe:
 >>
 >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >> :[e-mail]?subject=unsubscribe>
 >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >List-Post: <mailto:[e-mail]>
 >>  >List-Help: <mailto:[e-mail]?subject=help>
 >>  >List-Subscribe:
 >>
 >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >> :[e-mail]?subject=subscribe>
 >>  >X-Junkmail: UCE(35)
 >>  >X-Junkmail-Status: score=35/10, host=sfs2.omr.ecl.ntt.co.jp
 >>  >X-Junkmail-SD-Raw:
 >>
 >> >score=suspect(0),refid=str=0001.0A090207.468E8745.0129,ss=2,f
 >> gs=0,ip=156.154.16.145,so=2007-03-13
 >>
 >>  >10:31:19,dmn=5.3.14/2007-05-31
 >>  >
 >>  >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		: Analysis of Inter-domain Label
 >> Switched Path (LSP) Recovery
 >>  >	Author(s)	: T. Takeda, et al.
 >>  >	Filename	:
 >> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >	Pages		: 23
 >>  >	Date		: 2007-7-6
 >>  >
 >>  >This document analyzes various schemes to realize
 >> Multiprotocol Label
 >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
 >>  >   (LSP) recovery in multi-domain networks based on the existing
 >>  >   framework for multi-domain LSPs.
 >>  >
 >>  >   The main focus for this document is on establishing end-to-end
 >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain
 >> networks. It
 >>  >   presents various diverse LSP setup schemes based on existing
 >>  >   functional elements.
 >>  >
 >>  >A URL for this Internet-Draft is:
 >>
 >> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
 >> main-recovery-analysis-01.txt
 >>  >
 >>  >To remove yourself from the I-D Announcement list, send a message to
 >>  >[e-mail] with the word unsubscribe in
 >> the body of
 >>  >the message.
 >>  >You can also visit
 >> https://www1.ietf.org/mailman/listinfo/I-D-announce
 >>  >to change your subscription settings.
 >>  >
 >>  >Internet-Drafts are also available by anonymous FTP. Login with the
 >>  >username "anonymous" and a password of your e-mail address. After
 >>  >logging in, type "cd internet-drafts" and then
 >>  >"get draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >>  >
 >>  >A list of Internet-Drafts directories can be found in
 >>  >http://www.ietf.org/shadow.html
 >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >>  >
 >>  >Internet-Drafts can also be obtained by e-mail.
 >>  >
 >>  >Send a message to:
 >>  >	[e-mail].
 >>  >In the body type:
 >>  >	"FILE
 >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
 >> is-01.txt".
 >>  >
 >>  >NOTE:	The mail server at ietf.org can return the document in
 >>  >	MIME-encoded form by using the "mpack" utility.  To use this
 >>  >	feature, insert the command "ENCODING mime" before the "FILE"
 >>  >	command.  To decode the response(s), you will need "munpack" or
 >>  >	a MIME-compliant mail reader.  Different MIME-compliant
 >> mail readers
 >>  >	exhibit different behavior, especially when dealing with
 >>  >	"multipart" MIME messages (i.e. documents which have been split
 >>  >	up into multiple messages), so check your local documentation on
 >>  >	how to manipulate these messages.
 >>  >
 >>  >Below is the data which will enable a MIME compliant mail reader
 >>  >implementation to automatically retrieve the ASCII version of the
 >>  >Internet-Draft.
 >>  >
 >>  >Content-Type: text/plain
 >>  >Content-ID: <[e-mail]>
 >>  >
 >>  >ENCODING mime
 >>  >FILE
 >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
 >> is-01.txt
 >>  >
 >>  >
 >>
 >> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do>> 
main-recovery-analysis-01.txt>
 >>  >_______________________________________________
 >>  >I-D-Announce mailing list
 >>  >[e-mail]
 >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>
 >>
 >>
 >> 





Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jul 2007 07:36:02 +0000
Message-Id: <[e-mail]>
Date: Tue, 10 Jul 2007 16:34:41 +0900
To: Meral Shirazipour <[e-mail]>
From: Tomonori TAKEDA <[e-mail]>
Subject: Re: Fwd: I-D   ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
Cc: "[e-mail]" <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Meral,

Please see in-line.

At 23:30 07/07/09, Meral Shirazipour wrote:
 >Dear Tomonori,
 >   Thank you for the explanation:
 >----------
 >>[Page 12]
 >>first paragraph:"This scheme cannot guarantee to establish diverse LSPs (even
 >>if they could exist) because the first LSP is established without
 >>consideration of the need for a diverse recovery LSP. Crankback [crankback]
 >>may be used in combination with this scheme in order to improve the
 >>possibility of successful diverse LSP setup."
 >>How can crankback on the protection LSP help if the problem is the already
 >>established working LSP ?!
 >
 >There are several causes why the recovery LSP can not be computed. In one
 >case, the recovery LSP can not be computed because the working LSP is
 >blocking (there is no way). In another case, the recovery LSP can not be
 >computed because the bad border node is selected, but crankback can fix
 >this. We are not saying that the first case can be fixed by crankback.
 >----------
 >
 >
 >
 > Just to make sure that I understood well, crankback is used when the entity
 >that determined the diverse recovery LSP had only access to an out of date
 >information that did not include the recently deployed working LSP ?

Out of date information is yet another case where the recovery LSP can not 
be computed. Crankback is also applicable when information is up-to-date 
(when there are more than two border nodes).

Here is an example.

     B----------E
   /              \
  /                \
A---C----------F---H
  \             |  /
   \            | /
     D----------G

- A,B,C,D belong to domain#1.
- E,F,G,H belong to domain#2.
- The working LSP is A->D->G->F->H.

Assume we are using per-domain sequential path computation, and trying to 
establish the recovery LSP from A to H.

For the recovery LSP, domain#1 may compute A->C. At domain#2 (or at F), we 
know that the recovery LSP can not be computed since the working LSP is 
blocking. Now crankback can fix this by notifying domain#1, and domain#1 
re-computes the recovery LSP as A->B.

Hope this clarifies.

Thanks,
Tomonori

 >Thanks again for taking the time...
 >
 >Warm Regards,
 >Meral
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >Selon Tomonori TAKEDA <[e-mail]>:
 >
 >> Hi Meral,
 >>
 >> Thanks for you comments. I copied CCAMP list here for sharing information.
 >>
 >> Please see in-line.
 >>
 >> At 13:07 07/07/09, Meral Shirazipour wrote:
 >>  >Dear Tomonori,
 >>  >   I just finished reading the draft. Below I have a few
 >> comments/suggestions,
 >>  >mainly regarding typos and clarity.
 >>  >
 >>  >Warm Regards,
 >>  >Meral
 >>  >
 >>  >[Page 2/16]
 >>  >5.4 Inter-domain Collaborate Path Computation....................16
 >>  >
 >>  >Maybe Collaborative would be better?!
 >>
 >> Thanks.
 >>
 >>  >[Page 4]
 >>  >section 1.2 Domain
 >>  >"In such a scenarios,..."
 >>  >
 >>  >Should be "In such scenarios" or "In such a scenario"
 >>
 >> Thanks.
 >>
 >>  >section 1.3 Document Scope , third paragraph
 >>  >"which can advantageously used"
 >>  >Should be "which can advantageously be used"
 >>
 >> Thanks.
 >>
 >>  >[Page 6/7]
 >>  >"Figure 2: Mesh Connectivity"  should be on page 6
 >>
 >> OK.
 >>
 >>  >[Page 9]
 >>  >"An example of such a scheme is Backward Recursive Pause Computation (BRPC)
 >>  >[brpc]"
 >>  >
 >>  >"Pause" should be replaced by "Path"
 >>
 >> Thanks.
 >>
 >>  >[Page 20]
 >>  >[brpc]:
 >>  >A Backward Recursive PCE-based Computation (BRPC) procedure to compute
 >>  >shortest inter-domain Traffic Engineering Label Switched Paths
 >>  >
 >>  >Path with S
 >>
 >> Thanks.
 >>
 >>  >[Page 12]
 >>  >first paragraph:"This scheme cannot guarantee to establish diverse LSPs
 >> (even if
 >>  >they could exist) because the first LSP is established without
 >> consideration of
 >>  >the need for a diverse recovery LSP. Crankback [crankback] may be used in
 >>  >combination with this scheme in order to improve the possibility of
 >> successful
 >>  >diverse LSP setup."
 >>  >
 >>  >How can crankback on the protection LSP help if the problem is the already
 >>  >established working LSP ?!
 >>
 >> There are several causes why the recovery LSP can not be computed. In one
 >> case, the recovery LSP can not be computed because the working LSP is
 >> blocking (there is no way). In another case, the recovery LSP can not be
 >> computed because the bad border node is selected, but crankback can fix
 >> this. We are not saying that the first case can be fixed by crankback.
 >>
 >> Thanks,
 >> Tomonori
 >>
 >>  >
 >>  >
 >>  >
 >>  >
 >>  >
 >>  >
 >>  >Selon Tomonori TAKEDA <[e-mail]>:
 >>  >
 >>  >> Hi,
 >>  >>
 >>  >> A new version of inter-domain recovery analysis I-D have been published.
 >>  >>
 >>  >> Here are major changes:
 >>  >> - Added text on security considerations section
 >>  >> - Cleaned up text marked "for further study" (various places)
 >>  >> - Added a reference to [PCEP-XRO]
 >>  >> - Enhanced text on computing diverse paths sequentially with
 >> confidentiality
 >>  >>    (Section 5.4.1)
 >>  >> - Moved "terminology" section into "introduction" section
 >>  >> - Removed manageability considerations section
 >>  >> - Polished text
 >>  >>
 >>  >> Authors believe the document is now completed and ready for WG last call.
 >>  >>
 >>  >> Thanks,
 >>  >> Tomonori
 >>  >>
 >>  >>  >To: [e-mail]
 >>  >>  >From: [e-mail]
 >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >>  >X-Spam-Score: 0.0 (/)
 >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >>  >Cc: [e-mail]
 >>  >>  >Subject: I-D
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >X-BeenThere: [e-mail]
 >>  >>  >X-Mailman-Version: 2.1.5
 >>  >>  >Reply-To: [e-mail]
 >>  >>  >List-Id: i-d-announce.ietf.org
 >>  >>  >List-Unsubscribe:
 >>  >>
 >>
 >>><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?subject=unsubscribe>
 >>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >>  >List-Post: <mailto:[e-mail]>
 >>  >>  >List-Help: <mailto:[e-mail]?subject=help>
 >>  >>  >List-Subscribe:
 >>  >>
 >>
 >>><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?subject=subscribe>
 >>  >>  >X-Junkmail: UCE(35)
 >>  >>  >X-Junkmail-Status: score=35/10, host=sfs2.omr.ecl.ntt.co.jp
 >>  >>  >X-Junkmail-SD-Raw:
 >>  >>
 >>
 >>>score=suspect(0),refid=str=0001.0A090207.468E8745.0129,ss=2,fgs=0,ip=156.154.16.145,so=2007-03-13
 >>  >>
 >>  >>  >10:31:19,dmn=5.3.14/2007-05-31
 >>  >>  >
 >>  >>  >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		: Analysis of Inter-domain Label Switched Path (LSP) Recovery
 >>  >>  >	Author(s)	: T. Takeda, et al.
 >>  >>  >	Filename	: draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >	Pages		: 23
 >>  >>  >	Date		: 2007-7-6
 >>  >>  >
 >>  >>  >This document analyzes various schemes to realize Multiprotocol Label
 >>  >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
 >>  >>  >   (LSP) recovery in multi-domain networks based on the existing
 >>  >>  >   framework for multi-domain LSPs.
 >>  >>  >
 >>  >>  >   The main focus for this document is on establishing end-to-end
 >>  >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain networks. It
 >>  >>  >   presents various diverse LSP setup schemes based on existing
 >>  >>  >   functional elements.
 >>  >>  >
 >>  >>  >A URL for this Internet-Draft is:
 >>  >>
 >>
 >>>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >
 >>  >>  >To remove yourself from the I-D Announcement list, send a message to
 >>  >>  >[e-mail] with the word unsubscribe in the body of
 >>  >>  >the message.
 >>  >>  >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
 >>  >>  >to change your subscription settings.
 >>  >>  >
 >>  >>  >Internet-Drafts are also available by anonymous FTP. Login with the
 >>  >>  >username "anonymous" and a password of your e-mail address. After
 >>  >>  >logging in, type "cd internet-drafts" and then
 >>  >>  >"get draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >>  >>  >
 >>  >>  >A list of Internet-Drafts directories can be found in
 >>  >>  >http://www.ietf.org/shadow.html
 >>  >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >>  >>  >
 >>  >>  >Internet-Drafts can also be obtained by e-mail.
 >>  >>  >
 >>  >>  >Send a message to:
 >>  >>  >	[e-mail].
 >>  >>  >In the body type:
 >>  >>  >	"FILE
 >>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >>  >>  >
 >>  >>  >NOTE:	The mail server at ietf.org can return the document in
 >>  >>  >	MIME-encoded form by using the "mpack" utility.  To use this
 >>  >>  >	feature, insert the command "ENCODING mime" before the "FILE"
 >>  >>  >	command.  To decode the response(s), you will need "munpack" or
 >>  >>  >	a MIME-compliant mail reader.  Different MIME-compliant mail readers
 >>  >>  >	exhibit different behavior, especially when dealing with
 >>  >>  >	"multipart" MIME messages (i.e. documents which have been split
 >>  >>  >	up into multiple messages), so check your local documentation on
 >>  >>  >	how to manipulate these messages.
 >>  >>  >
 >>  >>  >Below is the data which will enable a MIME compliant mail reader
 >>  >>  >implementation to automatically retrieve the ASCII version of the
 >>  >>  >Internet-Draft.
 >>  >>  >
 >>  >>  >Content-Type: text/plain
 >>  >>  >Content-ID: <[e-mail]>
 >>  >>  >
 >>  >>  >ENCODING mime
 >>  >>  >FILE
 >>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >
 >>  >>  >
 >>  >>
 >>
 >>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt>
 >>  >>  >_______________________________________________
 >>  >>  >I-D-Announce mailing list
 >>  >>  >[e-mail]
 >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>  >>
 >>  >>
 >>  >>
 >>  >>
 >>
 >>
 >>
 >> 





Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jul 2007 07:05:09 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C2C0.8B9CA9C7"
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Tue, 10 Jul 2007 09:04:21 +0200
Message-ID: <[e-mail]>
Thread-Topic: Switching Capability of Photonic Links with Transponder
Thread-Index: AcfCRqAqgtjidMiUQweBF1ahw9MIlwAeUyPw
From: "Diego Caviglia (GA/ERI)" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>, "Wataru Imajuku" <[e-mail]>
Cc: "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7C2C0.8B9CA9C7
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

SGkgR3JlZywgaGkgV2F0YXJ1LA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYXQg
aXMgZXhhY3RseSB3aGF0IEkgaGFkIGluIG1pbmQgd2l0aCBteSBlLW1haWwuICBJIHRoaW5rIHdl
IG5lZWQgdG8gZGlmZmVyZW50aWF0ZSDigJhjb2xvcmVk4oCZIGZyb20g4oCYY29sb3JsZXNz4oCZ
IGludGVyZmFjZXMgaW4gcm91dGluZyBwcm90b2NvbC4NCg0KIA0KDQpNb3Jlb3ZlciB3ZSBzaG91
bGQgYWxzbyB0aGluayBhYm91dCB0aGUgZmFjdCB0aGF0IGFuIGludGVyZmFjZSB0aGF0IGlzIGFi
bGUgdG8gY2hhbmdlIHRoZSBsYW1iZGEgKGYgSeKAmXZlIHVuZGVyc3Rvb2QgeW91ciBkZWZpbml0
aW9uIGFyZSB0aGUgb25lcyBjYWxsZWQg4oCYY29sb3JsZXNz4oCZKSBjYW4gZG8gdGhhdCBpbiB0
d28gZGlmZmVyZW50IHdheXM6DQoNCiANCg0KMSkgICAgICAgT0VPIHRoYXQgbWVhbnMgdGhlcmUg
aXMgYWxzbyByZWdlbmVyYXRpb24gb2YgdGhlIHNpZ25hbA0KDQoyKSAgICAgICBVc2luZyBub24g
bGluZWFyIGVmZmVjdCB0aGF0IG1lYW5zIHRoZXJlIGlzIG5vIHJlZ2VuZXJhdGlvbiBvZiB0aGUg
c2lnbmFsLg0KDQogDQoNCklNSE8gaXQgaXMgYWxzbyBpbXBvcnRhbnQgdG8gYWR2ZXJ0aXNlIHRo
aXMga2luZCBvZiBpbmZvcm1hdGlvbi4NCg0KIA0KDQpCUg0KDQoNCkRpZWdvDQoNCiANCg0KIA0K
DQogDQoNCkZyb206IEdyZWcgQmVybnN0ZWluIFttYWlsdG86Z3JlZ2JAZ3JvdHRvLW5ldHdvcmtp
bmcuY29tXSANClNlbnQ6IGx1bmVkw6wgOSBsdWdsaW8gMjAwNyAxOC4zMg0KVG86IFdhdGFydSBJ
bWFqdWt1DQpDYzogRGllZ28gQ2F2aWdsaWEgKEdBL0VSSSk7IE1FVVJJQyBKdWxpZW4gUkQtQ09S
RS1MQU47IGNjYW1wQG9wcy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFN3aXRjaGluZyBDYXBhYmls
aXR5IG9mIFBob3RvbmljIExpbmtzIHdpdGggVHJhbnNwb25kZXINCg0KIA0KDQpIaSBhbGwsIGNv
bmN1ciB3aXRoIFdhdGFydSdzIGNvbW1lbnRzLiAgSWYgeW91IGNoZWNrIG91dCBzb21lIG9mIHRo
ZSBvcHRpY2FsIHN1Yi1zeXN0ZW0vY29tcG9uZW50IHZlbmRvcnMgeW91J2xsIHNlZSBST0FETXMg
YW5kIHN3aXRjaGVzIHRoYXQgYXJlICJjb2xvcmVkIiBhbmQgImNvbG9ybGVzcyIuICAiQ29sb3Jl
ZCIgbWVhbmluZyB0aGF0IGEgd2F2ZWxlbmd0aCBpbmdyZXNzIG9uIG9uZSBwb3J0IGdldHMgbWFw
cGVkIHRvIGEgcGFydGljdWxhciBlZ3Jlc3MgcG9ydC4gICJDb2xvcmxlc3MiIG1lYW5pbmcgdGhh
dCB3ZSBjYW4gbWFwIGFuIGluZ3Jlc3Mgd2F2ZWxlbmd0aCBvbiBvbmUgcG9ydCB0byBhbiBlZ3Jl
c3MgcG9ydCBpcnJlc3BlY3RpdmUgb2YgY29sb3IuIA0KDQpIZW5jZSBpdCBzZWVtcyB3ZSd2ZSBn
b3Qgc29tZSBwcm9ibGVtIGFyZWEgIm1vZGVsaW5nIiB3b3JrLiBUaGVuIHdlIGNhbiBzZWUgYWJv
dXQgcG90ZW50aWFsIHJlcHJlc2VudGF0aW9ucy9zb2x1dGlvbnMuDQoNClJlZ2FyZHMNCg0KR3Jl
ZyBCLg0KDQpXYXRhcnUgSW1hanVrdSB3cm90ZTogDQoNCkhpLCBEaWVnbyBhbmQgSnVsaWVuDQog
DQogIk9FTyB0cmFuc3BvbmRlciB0aGF0IGNhbiBvbmx5IHBlcmZvcm0gZnJlcXVlbmN5IHN3aXRj
aGluZyBsYW1iZGExIO+/vWxhbWJkYSAyLiINCiANCiBJIHRoaW5rIHRoaXMgZGV2aWNlIHNob3Vs
ZCBiZSBhZHZlcnRpc2VkIGFzIGxhbWJkYSBzd2l0Y2ggY2FwYWJsZSwgaWYgdGhlIG9wdGljYWwg
c2lnbmFscyBzZW50IA0KZnJvbSB0aGlzIHRyYW5zcG9uZGVyIGFyZSBkaXJlY3RpbHkgY29ubmVj
dGllZCB0byBXRE0gbmV0d29ya3MgKHN1Y2ggYXMgUk9BRE0gcmluZyBvciB0cmFuc3BhcmVudCBP
WENzKS4NCiANCiBCdXQsIGl0IGlzIG5vdCBwcm9ibGVtIHRoaXMgaW50ZXJmYWNlIGlzIGFkdmVy
dGlzZWQgYXMgZmliZXIgc3dpdGNoIGNhcGFibGUsDQogaWYgdGhlIG9wdGljYWwgc2lnbmFsIHNl
bmQgZnJvbSB0aGUgdHJhbnNwb25kZXIgaXMgdGVybWluYXRlZCBieSBlbGVjdHJpY2FsIHJlY2ll
dmVyIGluIG5leHQgaG9wIG5vZGUuDQogDQogUGVyaGFwcywgaWYgd2UgcHJvcGVybHkgaW5jb3Jw
b3JhdGUgdGhpcyBjYXNlIGludG8gdGhlIEdNUExTIGZyYW1lIHdvcmssIEkgdGhpbmsgDQp3ZSBu
ZWVkIHRoZSBjb25jZXB0IG9mICJjb2xvcmVkIFRFLWxpbmsiIGFuZCAiY29sb3JsZXNzIFRFLWxp
bmsiIGV2ZW4gdG8gR01QTFMgY29udHJvbCBwbGFuZS4NCiBJbiBjb2xvcmxlZCBURS1MaW5rLCB0
aGUgc3dpdGNoaW5nIGNhcGFiaWxpdHkgaW4gYm90aCBlbmQgdGFrZSBjYXJlIHRoZSBjb2xvciBv
ZiBvcHRpY2FsIHNpZ25hbA0KZXZlbiBldmVuIGlmIG51bWJlciBvZiBvcHRpY2FsIHNpZ25hbCBp
biB0aGUgY29sZXJlZCBURS1saW5rIGlzIHVuaXR5Lg0KIA0KIEkgdGhpbmsgd2UgbmVlZCB1cGRh
dGVkIGRyYWZ0cyBkZXNjcmliaW5nIHBob3RvbmljIG5ldHdvcmtzIHdpdGggY29uc2lkZXJhdGlv
biBvZiByZWNlbnQgcHJvZ3Jlc3Mgb2YgDQpvcHRpY2FsIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMu
DQogDQogDQogIA0KDQoJICAgICAgICAgSG1tbW1tbSBub3Qgc3VyZSBteSBVbmRlcnN0YW5kaW5n
IG9mIHRoZSBsYW1iZGEgc3dpdGNoaW5nIGlzIHdoYXQgSeiHtGUgY2FsbGVkIHNwYXRpYWwgc3dp
dGNoaW5nIHRoYXQgaXMgbGFtYmRhMSBwb3J0QSDvv71sYW1iZGExIHBvcnRCIHdoYXQgaXMgbm90
IGNsZWFyIHRvIG1lIGlzIGhvdyBjYW4gYmUgYWR2ZXJ0aXNlZCBhbiBPRU8gdHJhbnNwb25kZXIg
dGhhdCBjYW4gb25seSBwZXJmb3JtIGZyZXF1ZW5jeSBzd2l0Y2hpbmcgbGFtYmRhMSDvv71sYW1i
ZGEgMi4NCgkgICAgDQoNCiANCiANCiANCkF0IDE1OjM5IDA3LzA3LzA1LCBEaWVnbyBDYXZpZ2xp
YSAoR0EvRVJJKSB3cm90ZToNCiANCiAgDQoNCglIaSBKdWxpZW4sDQoJIA0KCSAgICAgICAgIEht
bW1tbW0gbm90IHN1cmUgbXkgVW5kZXJzdGFuZGluZyBvZiB0aGUgbGFtYmRhIHN3aXRjaGluZyBp
cyB3aGF0IEnoh7RlIGNhbGxlZCBzcGF0aWFsIHN3aXRjaGluZyB0aGF0IGlzIGxhbWJkYTEgcG9y
dEEg77+9bGFtYmRhMSBwb3J0QiB3aGF0IGlzIG5vdCBjbGVhciB0byBtZSBpcyBob3cgY2FuIGJl
IGFkdmVydGlzZWQgYW4gT0VPIHRyYW5zcG9uZGVyIHRoYXQgY2FuIG9ubHkgcGVyZm9ybSBmcmVx
dWVuY3kgc3dpdGNoaW5nIGxhbWJkYTEg77+9bGFtYmRhIDIuDQoJIA0KCUFkcmlhbj8gRGViPyBB
bnlvbmUgZWxzZT8NCgkgDQoJQlINCgkgDQoJRGllZ28NCgkgDQoJLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCglGcm9tOiBNRVVSSUMgSnVsaWVuIFJELUNPUkUtTEFOIFs8bWFpbHRvOmp1bGll
bi5tZXVyaWNAb3JhbmdlLWZ0Z3JvdXAuY29tPiA8bWFpbHRvOmp1bGllbi5tZXVyaWNAb3Jhbmdl
LWZ0Z3JvdXAuY29tPiBtYWlsdG86anVsaWVuLm1ldXJpY0BvcmFuZ2UtZnRncm91cC5jb21dDQoJ
U2VudDogbWVyY29sZWTvv700IGx1Z2xpbyAyMDA3IDE4LjQ3DQoJVG86IERpZWdvIENhdmlnbGlh
IChHQS9FUkkpOyBjY2FtcEBvcHMuaWV0Zi5vcmcNCglTdWJqZWN0OiBSRTogU3dpdGNoaW5nIENh
cGFiaWxpdHkgb2YgUGhvdG9uaWMgTGlua3Mgd2l0aCBUcmFuc3BvbmRlcg0KCSANCglIaSBEaWVn
by4NCgkgDQoJSSBiZWxpZXZlIHdlIHNob3VsZCByZWZlciB0byB0aGUgSG9sbHkgUkZDIDM5NDUs
IGNoYXB0ZXIgMSwgdmVyc2UgMjoNCgkgDQoJLSAiTGFtYmRhIFN3aXRjaCBDYXBhYmxlIiBpbnRl
cmZhY2VzICJjYW4gb3BlcmF0ZSBhdCB0aGUgbGV2ZWwgb2YgYW4gKmluZGl2aWR1YWwgd2F2ZWxl
bmd0aCoiIFtvciBhICJncm91cCBvZiB3YXZlbGVuZ3RocyJdLCBtZWFuaW5nIHRoYXQgeW91IG1h
bmlwdWxhdGUgdmFsdWVzIG9mIHdhdmVsZW5ndGhzIChhcyBBVS00IG51bWJlcnMgW29yIEFVLTQg
cmFuZ2VzXSBmcm9tIGFuIFNESCBwb3J0QSB0byBTREggcG9ydEIpLCBsaWtlIGluIGEgUk9BRE07
DQoJIA0KCS0gIkZpYmVyLVN3aXRjaCBDYXBhYmxlIiBpbnRlcmZhY2VzICJjYW4gb3BlcmF0ZSBh
dCB0aGUgbGV2ZWwgb2YgYSBzaW5nbGUgb3IgbXVsdGlwbGUgKmZpYmVycyoiLCBtZWFuaW5nICpz
cGF0aWFsIHN3aXRjaGluZyogd2hlcmUgeW91IGRvbid0IGNvbnNpZGVyIHRoZSB0eXBlIG9mIHNp
Z25hbCB0aGF0IHBvcnRzIGNvbnZleSAoY291bGQgYmUgYW55dGhpbmcgbGlrZSBhIGJsYWNrIGFu
ZCB3aGl0ZSBzaWduYWwsIGEgd2F2ZWxlbmd0aCwgYSBXRE0gbXVsdGlwbGV4LCBzb21lIG9wdGlj
YWwgcGFja2V0cy4uLiksIGxpa2UgaW4gYSBPT08gUFhDLg0KCSANCglUbyBzdGljayB3aXRoIHN0
cmljdCB0ZXJtaW5vbGd5OiBsYW1iZGEgPSB3YXZlbGVuZ3RoID0gKHNwZWVkT2ZMaWdodCAvIGZy
ZXF1ZW5jeSkNCgkgDQoJU28gaWYgeW91IG5lZWQgdG8gZG8gImZyZXF1ZW5jeSBzd2l0Y2hpbmci
LCB0aGVuIGl0IGlzIHRoZSBzbyBjYWxsZWQgImxhbWJkYSBzd2l0Y2hpbmciLiA6LSkNCgkgDQoJ
QW55d2F5LCB0aGlzIGlzIG15IHVuZGVyc3RhbmRpbmcsIHNvIGlmIEknbSB3cm9uZyBvciBpZiBp
dCdzIGEgdm9jYWJ1bGFyeSBpc3N1ZSBiZWNhdXNlIHlvdSBmaW5kIHRoYXQgdGVybXMgYXJlIGlu
YXBwcm9wcmlhdGUsIHRoZW4gd2UnZCBiZXR0ZXIgYXNrIGZhdGhlciBBZHJpYW4gYW5kIHNpc3Rl
ciBEZWJvcmFoLg0KCSANCglDaGVlcnMsDQoJIA0KCUp1bGllbg0KCSANCgktLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KCSANCglGcm9tOiBEaWVnbyBDYXZpZ2xpYSAoR0EvRVJJKSBbPG1haWx0
bzpkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb20+IDxtYWlsdG86ZGllZ28uY2F2aWdsaWFAZXJp
Y3Nzb24uY29tPiBtYWlsdG86ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29tXSANCgkgDQoJSGkg
SnVsaWVuLA0KCSANCgkgICAgICAgICBBY3R1YWxseSBub3QgdGhlIFBYQyBJIGhhZCBpbiBtaW5k
IGlzIGFibGUgdG8gc3dpdGNoIGEgc2luZ2xlIGxhbWJkYSBJIGRpZG4ndCBidXQgdGhlIG11eC9k
ZW11eCBJbiB0aGUgcGljdHVyZSBzb3JyeS4NCgkgDQoJVGhlIHBvaW50IEkgZmFpbGVkIHRvIGls
bHVzdHJhdGUgaXMgdGhlIGFtYmlndWl0eSBvZiB0aGUgdGVybSAiTGFtYmRhIFN3aXRjaCBDYXBh
YmxlIiBnaXZlbiB0aGF0IHRoZXJlIHR3byBwb3NzaWJsZSB3YXlzIHRvIHN3aXRjaCBhIGxhbWJk
YS4gIA0KCSANCglUaGUgZmlyc3Qgb25lIGlzIHRoZSBzcGF0aWFsIG9uZTogKExhbWJkYTEgcG9y
dEEpIC0tPiAoTGFtYmRhMSBwb3J0QikgdGhpcyBpcyB0aGUgd2F5IGFuIGFsbCBvcHRpY2FsIHN3
aXRjaCB3b3JrcyBhbmQgdGhpcyB3aHkgdGhlcmUgaXMgdGhlIGxhbWJkYSBjb250aW51aXR5IGNv
bnN0cmFpbnQgaW4gcGhvdG9uaWMgbmV0d29ya3MuICANCgkgDQoJVGhlIHNlY29uZCBvbmUgaXMg
dGhlIGZyZXF1ZW5jeSBzd2l0Y2hpbmc6IChMYW1iZGExIHBvcnRBKSAtLT4gKExhbWJkYTIgcG9y
dEEpIHRoaXMgc3dpdGNoaW5nIGNhbiBiZSBkb25lIHZpYSBhIHRyYW5zcG9uZGVyIChPRU8pIGRl
dmljZS4gIA0KCSANCglPZiBjb3Vyc2UgaXMgcG9zc2libGUgdG8gbWl4IHRoZSB0d28gc3dpdGNo
aW5nIGhhdmluZyAoTGFtYmRhMSBwb3J0QSkgLS0+IChMYW1iZGEyIHBvcnRCKQ0KCSANCglNeSBp
bXByZXNzaW9uIGlzIHRoYXQgdGhlIGRlZmluaXRpb24gIkxhbWJkYSBTd2l0Y2ggQ2FwYWJsZSIg
cmVmZXJzIHRvIHRoZSBzcGF0aWFsIHN3aXRjaGluZyBhbmQgdGh1cyBJIGRvbid0IGtub3cgaG93
IHRvIG1vZGVsIHRoZSBmYWN0IHRoYXQgYWZ0ZXIvYmVmb3JlIGEgcGhvdG9uaWMgbWF0cml4IEkg
aGF2ZSBhIHRyYW5zcG9uZGVyLiAgDQoJIA0KCUkgaG9wZSBJJ3ZlIG1hZGUgbXkgcXVlc3Rpb24g
Y2xlYXJlci4NCgkgDQoJQmVzdCBSZWdhcmRzDQoJIA0KCURpZWdvDQoJIA0KCS0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQoJIA0KCUZyb206IE1FVVJJQyBKdWxpZW4gUkQtQ09SRS1MQU4gWzxt
YWlsdG86anVsaWVuLm1ldXJpY0BvcmFuZ2UtZnRncm91cC5jb20+IDxtYWlsdG86anVsaWVuLm1l
dXJpY0BvcmFuZ2UtZnRncm91cC5jb20+IG1haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS1mdGdy
b3VwLmNvbV0gDQoJIA0KCVNlbnQ6IG1hcnRlZO+/vTMgbHVnbGlvIDIwMDcgMTkuMjENCgkgDQoJ
VG86IERpZWdvIENhdmlnbGlhIChHQS9FUkkpOyBjY2FtcEBvcHMuaWV0Zi5vcmcNCgkgDQoJU3Vi
amVjdDogUkU6IFN3aXRjaGluZyBDYXBhYmlsaXR5IG9mIFBob3RvbmljIExpbmtzIHdpdGggVHJh
bnNwb25kZXINCgkgDQoJSGkgRGllZ28uDQoJIA0KCUlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHks
IHlvdXIgImxhbWJkYSBzd2l0Y2giIGJ5IGl0c2VsZiBpcyBhIFBYQyB0aGF0DQoJIA0KCWhhcyBv
bmx5ICJGaWJlci1Td2l0Y2ggQ2FwYWJsZSIgaW50ZXJmYWNlcy4gVGhlbiwgeW91IGFkZA0KCSAN
CglsYW1iZGEtY29udmVyc2lvbiBjYXJkcyB0byBpdC4gU28sIGNvcnJlY3QgbWUgaWYgSSdtIHdy
b25nICh5b3Ugb3INCgkgDQoJYW55b25lIGVsc2UpLCBidXQgd2hldGhlciB5b3UgZG8gYSBsYW1i
ZGEgY29udmVyc2lvbiBpbnNpZGUgYSBjYXJkIG9yIGluDQoJIA0KCWEgY29yZSBtYXRyaXgsIHRo
aXMgbmV3IGludGVyZmFjZSBvbiB5b3VyIGdsb2JhbCBkZXZpY2UgaXMgYWJsZSB0byB3b3JrDQoJ
IA0KCW9uIGxhbWJkYXMgYW55d2F5ICBbKGxhbWJkYSAxLCBwb3J0IEEpIC0tPiAobGFtYmRhMiwg
cG9ydCBCKV0uIEFzIGENCgkgDQoJcmVzdWx0LCB5b3UgbmVlZCB0byBhZHZlcnRpc2UgeW91ciBt
b3N0IGZsZXhpYmxlIGNhcGFiaWxpdHksIHdoaWNoIGlzDQoJIA0KCSJMYW1iZGEgU3dpdGNoIENh
cGFibGUiLg0KCSANCglJZiB5b3UgdXNlZCAiRlNDIiwgeW91IHdvdWxkbid0IGJlIGFibGUgdG8g
Y29udHJvbCB5b3VyICJsYW1iZGENCgkgDQoJc3dhcHBpbmciIGNhcmQsIGFzIExTUHMgYXJlIGxp
a2UgbGlzdHMgb2YgZmliZXJzIGFuZCBsYWJlbHMgYXJlbid0DQoJIA0KCXdhdmVsZW5ndGhzIGJ1
dCBwb3J0cy4NCgkgDQoJQnV0IG1heWJlIEkgZGlkbid0IGdldCB5b3VyIGFjdHVhbCBpc3N1ZS4N
CgkgDQoJTXkgMiBjZW50cywNCgkgDQoJSnVsaWVuDQoJIA0KCV9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoJIA0KCUZyb206IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbPG1haWx0
bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc+IDxtYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYu
b3JnPiBtYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXSBPbg0KCSANCglCZWhhbGYgT2Yg
RGllZ28gQ2F2aWdsaWEgKEdBL0VSSSkNCgkgDQoJSGkgYWxsLA0KCSANCgkgICAgICAgIEkndmUg
YSBkb3VidCBhYm91dCBob3cgdG8gbW9kZWwgdGhlIGZvbGxvd2luZyBzaXR1YXRpb24uDQoJIA0K
CSANCgkgDQoJIA0KCSANCgkgDQoJIA0KCSAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0KCSANCgkg
ICAgIHwgICAgICAgICAgICAgICAgIHwtLS0tLS0tKw0KCSANCgkgICAgIHwgICAgICAgICAgICAg
ICAgIHwgT0VPICAgfA0KCSANCgkgICAgIHwgICAgIExhbWJkYSAgICAgIHwtLS0tLS0tKw0KCSAN
CgkgICAgIHwgICAgIFN3aXRjaCAgICAgIHwNCgkgDQoJICAgICB8ICAgICAgICAgICAgICAgICB8
DQoJIA0KCSAgICAgfCAgICAgICAgICAgICAgICAgfA0KCSANCgkgICAgICstLS0tLS0tLS0tLS0t
LS0tLSsNCgkgDQoJICAgICANCgkgDQoJIA0KCSANCglUaGUgbm9kZSBpdHNlbGYgaXMgYWJsZSB0
byBjcm9zcyBjb25uZWN0IG9ubHkgdGhlIExhbWJkYSB3aGlsZSB0aGUNCgkgDQoJaW50ZXJmYWNl
IGhhcyBhIE9FTyB0cmFuc3BvbmRlciB0aGF0IGlzIGFibGUgdG8gY2hhbmdlIHRoZSBsYW1iZGEN
CgkgDQoJZnJlcXVlbmN5LiAgSW4gdGhpcyBjYXNlIHRoZXJlIGFyZSB0d28gZGlmZmVyZW50ICdz
d2l0Y2hpbmcgY2FwYWJpbGl0eScNCgkgDQoJdGhlIHNwYXRpYWwgb25lIHRoYXQgaXMgcGVyZm9y
bWVkIGJ5IHRoZSBzd2l0Y2ggKGxhbWJkYSAxLCBwb3J0IEEpIC0tPg0KCSANCgkobGFtYmRhMSwg
cG9ydCBCKSBhbmQgdGhlIGZyZXF1ZW5jeSBzd2l0Y2hpbmcgaXMgZG9uZSBieSB0aGUgT0VPDQoJ
IA0KCXRyYW5zcG9uZGVyLiAgV2l0Y2gga2luZCBvZiBpbnRlcmZhY2Ugc3dpdGNoaW5nIGNhcGFi
aWxpdHkgSSBoYXZlIHRvDQoJIA0KCWFkdmVydGlzZT8NCgkgDQoJIA0KCSANCglCUg0KCSANCglE
aWVnbw0KCSANCgkgDQoJIA0KCURpZWdvIENhdmlnbGlhDQoJIA0KCVByb2R1Y3QgTGluZSBPTiBC
Qk4NCgkgDQoJUEEgQnJvYWRiYW5kIEJORVQNCgkgDQoJIA0KCSANCglNYXJjb25pIFMucC5BDQoJ
IA0KCUVyaWNzc29uIEdsb2JhbCBQcm9kdWN0IENlbnRlciAtIEl0YWx5DQoJIA0KCVZpYSBBbmFn
bmluYSwyMDMNCgkgDQoJMDAxOCwgUm9tYSAsIEl0YWx5DQoJIA0KCXd3dy5lcmljc3Nvbi5jb20g
PDxodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8+IDxodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8+IGh0
dHA6Ly93d3cuZXJpY3Nzb24uY29tLz4gDQoJIA0KCSANCgkgDQoJT2ZmaWNlOiAgKzM5IDAxMCA2
MDAgMzczNg0KCSANCglGYXg6ICszOSAwMTAgNjAwIDM0OTMNCgkgDQoJTW9iaWxlOiArMzkgMzM1
IDcxODE3NjINCgkgDQoJRW1haWw6IGRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbSAgDQoJIA0K
CVRoaXMgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBm
b3IgdGhlDQoJIA0KCWFkZHJlc3NlZShzKS4gQW55IHVuYXV0aG9yaXplZCByZXZpZXcsIHVzZSwg
ZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24NCgkgDQoJaXMgcHJvaGliaXRlZC4gSWYgeW91IGJl
bGlldmUgdGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNlbnQgdG8geW91IGluDQoJIA0KCWVycm9yLCBw
bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHlpbmcgdG8gdGhpcyB0cmFuc21pc3Npb24g
YW5kDQoJIA0KCWRlbGV0ZSB0aGUgbWVzc2FnZSB3aXRob3V0IGRpc2Nsb3NpbmcgaXQuIFRoYW5r
IHlvdS4NCgkgDQoJRS1tYWlsIGluY2x1ZGluZyBhdHRhY2htZW50cyBpcyBzdXNjZXB0aWJsZSB0
byBkYXRhIGNvcnJ1cHRpb24sDQoJIA0KCWludGVyY2VwdGlvbiwgdW5hdXRob3JpemVkIGFtZW5k
bWVudCwgdGFtcGVyaW5nIGFuZCB2aXJ1c2VzLCBhbmQgd2Ugb25seQ0KCSANCglzZW5kIGFuZCBy
ZWNlaXZlIGVtYWlscyBvbiB0aGUgYmFzaXMgdGhhdCB3ZSBhcmUgbm90IGxpYWJsZSBmb3IgYW55
IHN1Y2gNCgkgDQoJY29ycnVwdGlvbiwgaW50ZXJjZXB0aW9uLCBhbWVuZG1lbnQsIHRhbXBlcmlu
ZyBvciB2aXJ1c2VzIG9yIGFueQ0KCSANCgljb25zZXF1ZW5jZXMgdGhlcmVvZi4NCgkgDQoJIA0K
CSAgICANCg0KIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV2F0YXJ1
IEltYWp1a3VATlRUIE5ldHdvcmsgSW5ub3ZhdGlvbiBMYWJzDQpURUw6ICs4MS00Ni04NTktNDMx
NQ0KRkFYOiArODEtNDYtODU5LTU1NDENCiANCiANCiANCiANCiAgDQoNCg0KDQoNCg0KLS0gDQo9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkRyIEdy
ZWcgQmVybnN0ZWluLCBHcm90dG8gTmV0d29ya2luZyAoNTEwKSA1NzMtMjIzNw0KIA0K

------_=_NextPart_001_01C7C2C0.8B9CA9C7
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz
ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi
IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6
dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3
LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQoNCjxtZXRhIG5hbWU9R2VuZXJhdG9y
IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxvOlNtYXJ0
VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNt
YXJ0dGFncyINCiBuYW1lPSJTdGF0ZSIvPg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0i
dXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9IkNpdHki
Lz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j
b206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJjb3VudHJ5LXJlZ2lvbiIvPg0KPG86U21hcnRU
YWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21h
cnR0YWdzIg0KIG5hbWU9IlBsYWNlVHlwZSIvPg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVy
aT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9IlBs
YWNlTmFtZSIvPg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWlj
cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9InBsYWNlIi8+DQo8IS0tW2lmICFt
c29dPg0KPHN0eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVybCgjZGVmYXVsdCNpZW9vdWkpIH0NCjwv
c3R5bGU+DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25z
ICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToy
IDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcmlhbCBV
bmljb2RlIE1TIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBQR290aGljIjt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OiJcQEFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg
MiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgUEdvdGhpYyI7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjAgMCAw
IDAgMCAwIDAgMCAwIDA7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJNUyBQR290aGlj
IjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw
ZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
O30NCnByZQ0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCWNvbG9yOmJsYWNrO30NCnNw
YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OkFyaWFsOw0KCWNvbG9yOm5hdnk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIu
MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu
U2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBs
aXN0IGwwDQoJe21zby1saXN0LWlkOjIyOTQ3ODk0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K
CW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDI3MTQ1NzA0IC03NTg4OTYzNCA2NzY5ODcxMyA2NzY5
ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx
NTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZl
bC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFy
Z2luLWJvdHRvbTowY207fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s
PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNo
YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPXdo
aXRlIGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPWJsdWU+DQoNCjxkaXYgY2xhc3M9U2VjdGlv
bjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFy
aWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29s
b3I6bmF2eSc+SGkgR3JlZywgaGkgV2F0YXJ1LDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+
DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6
bmF2eSc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7DQpUaGF0IGlzIGV4YWN0bHkgd2hhdCBJIGhhZCBpbiBtaW5kIHdpdGggbXkgZS1tYWlsLiAm
bmJzcDtJIHRoaW5rIHdlIG5lZWQgdG8NCmRpZmZlcmVudGlhdGUg4oCYY29sb3JlZOKAmSBmcm9t
IOKAmGNvbG9ybGVzc+KAmSBpbnRlcmZhY2VzIGluIHJvdXRpbmcgcHJvdG9jb2wuPG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj
b2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250
LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1B
cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv
bG9yOm5hdnknPk1vcmVvdmVyIHdlIHNob3VsZCBhbHNvIHRoaW5rIGFib3V0IHRoZQ0KZmFjdCB0
aGF0IGFuIGludGVyZmFjZSB0aGF0IGlzIGFibGUgdG8gY2hhbmdlIHRoZSBsYW1iZGEgKGYgSeKA
mXZlIHVuZGVyc3Rvb2QNCnlvdXIgZGVmaW5pdGlvbiBhcmUgdGhlIG9uZXMgY2FsbGVkIOKAmGNv
bG9ybGVzc+KAmSkgY2FuIGRvIHRoYXQgaW4gdHdvIGRpZmZlcmVudA0Kd2F5czo8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv
bG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQt
ZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48
L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQt
aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlz
dHNdPjxmb250DQpzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsOw0KY29sb3I6bmF2eSc+PHNwYW4gc3R5bGU9
J21zby1saXN0Oklnbm9yZSc+MSk8Zm9udCBzaXplPTEgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48
c3Bhbg0Kc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250
PjwhW2VuZGlmXT48Zm9udA0Kc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOm5hdnknPk9FTyB0
aGF0IG1lYW5zIHRoZXJlIGlzIGFsc28gcmVnZW5lcmF0aW9uIG9mIHRoZSBzaWduYWw8bzpwPjwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp
bi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8x
Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udA0Kc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1Bcmlh
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9y
Om5hdnknPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIpPGZvbnQgc2l6ZT0xIGZhY2U9
IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCnN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t
YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvZm9udD48
L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQNCnNpemU9MiBjb2xvcj1uYXZ5IGZh
Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7
DQpjb2xvcjpuYXZ5Jz5Vc2luZyBub24gbGluZWFyIGVmZmVjdCB0aGF0IG1lYW5zIHRoZXJlIGlz
IG5vIHJlZ2VuZXJhdGlvbiBvZiB0aGUNCnNpZ25hbC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1B
cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv
bG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz
PU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+SU1ITyBp
dCBpcyBhbHNvIGltcG9ydGFudCB0byBhZHZlcnRpc2UNCnRoaXMga2luZCBvZiBpbmZvcm1hdGlv
bi48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv
bnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K
MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9
bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1p
bHk6QXJpYWw7Y29sb3I6bmF2eSc+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8
cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkn
Pjxicj4NCkRpZWdvPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPHAg
Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBQR290aGlj
Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6d2luZG93dGV4dCc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250
IHNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBQR290aGljIj48c3Bhbg0Kc3R5bGU9J2ZvbnQt
c2l6ZToxMi4wcHQ7Y29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m
b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFjayBm
YWNlPSJNUyBQR290aGljIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6d2lu
ZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9
TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MiBjb2xvcj1ibGFjayBmYWNlPVRhaG9tYT48c3Bhbg0K
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hO2NvbG9yOndpbmRvd3Rl
eHQ7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udA0Kc2l6ZT0y
IGNvbG9yPWJsYWNrIGZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlRhaG9tYTsNCmNvbG9yOndpbmRvd3RleHQnPiBHcmVnIEJlcm5zdGVpbiBbbWFp
bHRvOmdyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNvbV0gPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2Zv
bnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gbHVuZWQmaWdyYXZlOyA5IGx1Z2xpbyAy
MDA3IDE4LjMyPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bh
bj48L2I+IFdhdGFydSBJbWFqdWt1PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJv
bGQnPkNjOjwvc3Bhbj48L2I+IERpZWdvIENhdmlnbGlhIChHQS9FUkkpOw0KTUVVUklDIEp1bGll
biBSRC1DT1JFLUxBTjsgY2NhbXBAb3BzLmlldGYub3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2Zv
bnQtd2VpZ2h0OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFN3aXRjaGluZyBDYXBhYmls
aXR5DQpvZiBQaG90b25pYyBMaW5rcyB3aXRoIFRyYW5zcG9uZGVyPC9zcGFuPjwvZm9udD48Zm9u
dCBjb2xvcj1ibGFjaz48c3Bhbg0Kc3R5bGU9J2NvbG9yOndpbmRvd3RleHQnPjxvOnA+PC9vOnA+
PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg
c2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIFBHb3RoaWMiPjxzcGFuDQpzdHlsZT0nZm9udC1z
aXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh
c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBQR290aGljIj48
c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkhpIGFsbCwgY29uY3VyIHdpdGggV2F0YXJ1
J3MgY29tbWVudHMuPC9zcGFuPjwvZm9udD48Zm9udA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48
c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48
L2ZvbnQ+DQpJZiB5b3UgY2hlY2sgb3V0IHNvbWUgb2YgdGhlIG9wdGljYWwgc3ViLXN5c3RlbS9j
b21wb25lbnQgdmVuZG9ycyB5b3UnbGwgc2VlDQpST0FETXMgYW5kIHN3aXRjaGVzIHRoYXQgYXJl
ICZxdW90O2NvbG9yZWQmcXVvdDsgYW5kICZxdW90O2NvbG9ybGVzcyZxdW90Oy48Zm9udA0KZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+DQomcXVvdDtDb2xvcmVkJnF1b3Q7IG1lYW5pbmcg
dGhhdCBhIHdhdmVsZW5ndGggaW5ncmVzcyBvbiBvbmUgcG9ydCBnZXRzIG1hcHBlZA0KdG8gYSBw
YXJ0aWN1bGFyIGVncmVzcyBwb3J0Ljxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4N
CnN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9u
dD4NCiZxdW90O0NvbG9ybGVzcyZxdW90OyBtZWFuaW5nIHRoYXQgd2UgY2FuIG1hcCBhbiBpbmdy
ZXNzIHdhdmVsZW5ndGggb24gb25lIHBvcnQNCnRvIGFuIGVncmVzcyBwb3J0IGlycmVzcGVjdGl2
ZSBvZiBjb2xvci4gPGJyPg0KPGJyPg0KSGVuY2UgaXQgc2VlbXMgd2UndmUgZ290IHNvbWUgcHJv
YmxlbSBhcmVhICZxdW90O21vZGVsaW5nJnF1b3Q7IHdvcmsuIFRoZW4gd2UNCmNhbiBzZWUgYWJv
dXQgcG90ZW50aWFsIHJlcHJlc2VudGF0aW9ucy9zb2x1dGlvbnMuPGJyPg0KPGJyPg0KUmVnYXJk
czxicj4NCjxicj4NCkdyZWcgQi48YnI+DQo8YnI+DQpXYXRhcnUgSW1hanVrdSB3cm90ZTogPG86
cD48L286cD48L3A+DQoNCjxwcmUgd3JhcD0iIj48Zm9udCBzaXplPTMgY29sb3I9YmxhY2sgZmFj
ZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5IaSwgRGllZ28g
YW5kIEp1bGllbjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250IHNpemU9
Mw0KY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy
LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTIuMHB0Jz4gJnF1b3Q7T0VPIHRyYW5zcG9uZGVyIHRoYXQgY2FuIG9ubHkgcGVyZm9ybSBmcmVx
dWVuY3kgc3dpdGNoaW5nIGxhbWJkYTEgPC9zcGFuPjwvZm9udD48Zm9udA0KZmFjZT0iQXJpYWwg
VW5pY29kZSBNUyI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCBVbmljb2RlIE1TIic+
77+9PC9zcGFuPjwvZm9udD5sYW1iZGEgMi4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGZv
bnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48
Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMi4wcHQnPiBJIHRoaW5rIHRoaXMgZGV2aWNlIHNob3VsZCBiZSBhZHZlcnRpc2Vk
IGFzIGxhbWJkYSBzd2l0Y2ggY2FwYWJsZSwgaWYgdGhlIG9wdGljYWwgc2lnbmFscyBzZW50IDxv
OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9Ymxh
Y2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+ZnJvbSB0
aGlzIHRyYW5zcG9uZGVyIGFyZSBkaXJlY3RpbHkgY29ubmVjdGllZCB0byBXRE0gbmV0d29ya3Mg
KHN1Y2ggYXMgUk9BRE0gcmluZyBvciB0cmFuc3BhcmVudCBPWENzKS48bzpwPjwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdv
dGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMg
R290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+IEJ1dCwgaXQgaXMgbm90IHBy
b2JsZW0gdGhpcyBpbnRlcmZhY2UgaXMgYWR2ZXJ0aXNlZCBhcyBmaWJlciBzd2l0Y2ggY2FwYWJs
ZSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9y
PWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiBp
ZiB0aGUgb3B0aWNhbCBzaWduYWwgc2VuZCBmcm9tIHRoZSB0cmFuc3BvbmRlciBpcyB0ZXJtaW5h
dGVkIGJ5IGVsZWN0cmljYWwgcmVjaWV2ZXIgaW4gbmV4dCBob3Agbm9kZS48bzpwPjwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1T
IEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0i
TVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+IFBlcmhhcHMsIGlmIHdl
IHByb3Blcmx5IGluY29ycG9yYXRlIHRoaXMgY2FzZSBpbnRvIHRoZSBHTVBMUyBmcmFtZSB3b3Jr
LCBJIHRoaW5rIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXpl
PTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy
LjBwdCc+d2UgbmVlZCB0aGUgY29uY2VwdCBvZiAmcXVvdDtjb2xvcmVkIFRFLWxpbmsmcXVvdDsg
YW5kICZxdW90O2NvbG9ybGVzcyBURS1saW5rJnF1b3Q7IGV2ZW4gdG8gR01QTFMgY29udHJvbCBw
bGFuZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNv
bG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn
PiBJbiBjb2xvcmxlZCBURS1MaW5rLCB0aGUgc3dpdGNoaW5nIGNhcGFiaWxpdHkgaW4gYm90aCBl
bmQgdGFrZSBjYXJlIHRoZSBjb2xvciBvZiBvcHRpY2FsIHNpZ25hbDxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290
aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+ZXZlbiBldmVuIGlmIG51bWJlciBv
ZiBvcHRpY2FsIHNpZ25hbCBpbiB0aGUgY29sZXJlZCBURS1saW5rIGlzIHVuaXR5LjxvOnA+PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFj
ZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBm
YWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4gSSB0aGluayB3
ZSBuZWVkIHVwZGF0ZWQgZHJhZnRzIGRlc2NyaWJpbmcgcGhvdG9uaWMgbmV0d29ya3Mgd2l0aCBj
b25zaWRlcmF0aW9uIG9mIHJlY2VudCBwcm9ncmVzcyBvZiA8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPm9wdGljYWwgdHJhbnNwb3J0IHRlY2hub2xv
Z2llcy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNv
bG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMg
Y29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw
dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9
MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIu
MHB0Jz4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8YmxvY2txdW90
ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0JyB0eXBlPWNpdGU+
PHByZSB3cmFwPSIiPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhtbW1tbW0gbm90IHN1cmUgbXkgVW5kZXJzdGFuZGluZyBv
ZiB0aGUgbGFtYmRhIHN3aXRjaGluZyBpcyB3aGF0IEk8c3Bhbg0KbGFuZz1KQT7oh7Q8L3NwYW4+
ZSBjYWxsZWQgc3BhdGlhbCBzd2l0Y2hpbmcgdGhhdCBpcyBsYW1iZGExIHBvcnRBIDwvc3Bhbj48
L2ZvbnQ+PGZvbnQNCmZhY2U9IkFyaWFsIFVuaWNvZGUgTVMiPjxzcGFuIHN0eWxlPSdmb250LWZh
bWlseToiQXJpYWwgVW5pY29kZSBNUyInPu+/vTwvc3Bhbj48L2ZvbnQ+bGFtYmRhMSBwb3J0QiB3
aGF0IGlzIG5vdCBjbGVhciB0byBtZSBpcyBob3cgY2FuIGJlIGFkdmVydGlzZWQgYW4gT0VPIHRy
YW5zcG9uZGVyIHRoYXQgY2FuIG9ubHkgcGVyZm9ybSBmcmVxdWVuY3kgc3dpdGNoaW5nIGxhbWJk
YTEgPGZvbnQNCmZhY2U9IkFyaWFsIFVuaWNvZGUgTVMiPjxzcGFuIHN0eWxlPSdmb250LWZhbWls
eToiQXJpYWwgVW5pY29kZSBNUyInPu+/vTwvc3Bhbj48L2ZvbnQ+bGFtYmRhIDIuPG86cD48L286
cD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48L2Jsb2NrcXVvdGU+DQoNCjxwcmUgd3JhcD0iIj48Zm9u
dCBzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48
Zm9udCBzaXplPTMgY29sb3I9YmxhY2sNCmZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMi4wcHQnPiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9u
dA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEyLjBwdCc+QXQgMTU6MzkgMDcvMDcvMDUsIERpZWdvIENhdmlnbGlhIChHQS9FUkkp
IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMg
Y29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw
dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9
MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIu
MHB0Jz4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8YmxvY2txdW90
ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0JyB0eXBlPWNpdGU+
PHByZSB3cmFwPSIiPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+SGkgSnVsaWVuLDxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290
aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBH
b3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSG1tbW1tbSBub3Qgc3VyZSBteSBVbmRlcnN0
YW5kaW5nIG9mIHRoZSBsYW1iZGEgc3dpdGNoaW5nIGlzIHdoYXQgSTxzcGFuDQpsYW5nPUpBPuiH
tDwvc3Bhbj5lIGNhbGxlZCBzcGF0aWFsIHN3aXRjaGluZyB0aGF0IGlzIGxhbWJkYTEgcG9ydEEg
PC9zcGFuPjwvZm9udD48Zm9udA0KZmFjZT0iQXJpYWwgVW5pY29kZSBNUyI+PHNwYW4gc3R5bGU9
J2ZvbnQtZmFtaWx5OiJBcmlhbCBVbmljb2RlIE1TIic+77+9PC9zcGFuPjwvZm9udD5sYW1iZGEx
IHBvcnRCIHdoYXQgaXMgbm90IGNsZWFyIHRvIG1lIGlzIGhvdyBjYW4gYmUgYWR2ZXJ0aXNlZCBh
biBPRU8gdHJhbnNwb25kZXIgdGhhdCBjYW4gb25seSBwZXJmb3JtIGZyZXF1ZW5jeSBzd2l0Y2hp
bmcgbGFtYmRhMSA8Zm9udA0KZmFjZT0iQXJpYWwgVW5pY29kZSBNUyI+PHNwYW4gc3R5bGU9J2Zv
bnQtZmFtaWx5OiJBcmlhbCBVbmljb2RlIE1TIic+77+9PC9zcGFuPjwvZm9udD5sYW1iZGEgMi48
bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBH
b3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48c3QxOkNpdHkNCnc6c3Q9Im9uIj48c3QxOnBsYWNlIHc6
c3Q9Im9uIj48Zm9udCBzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3Bhbg0K
ICBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+QWRyaWFuPC9zcGFuPjwvZm9udD48L3N0MTpwbGFj
ZT48L3N0MTpDaXR5Pj8gRGViPyBBbnlvbmUgZWxzZT88bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGZv
bnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48
Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMi4wcHQnPkJSPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZv
bnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48
Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMi4wcHQnPkRpZWdvPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+
PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy
ZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMi4wcHQnPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJN
UyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5Gcm9tOiBNRVVSSUMgSnVs
aWVuIFJELUNPUkUtTEFOIFs8YQ0KaHJlZj0ibWFpbHRvOmp1bGllbi5tZXVyaWNAb3JhbmdlLWZ0
Z3JvdXAuY29tIj4mbHQ7bWFpbHRvOmp1bGllbi5tZXVyaWNAb3JhbmdlLWZ0Z3JvdXAuY29tJmd0
OzwvYT48YQ0KaHJlZj0ibWFpbHRvOmp1bGllbi5tZXVyaWNAb3JhbmdlLWZ0Z3JvdXAuY29tIj5t
YWlsdG86anVsaWVuLm1ldXJpY0BvcmFuZ2UtZnRncm91cC5jb208L2E+XTxvOnA+PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMg
R290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+U2VudDogbWVyY29sZWQ8L3Nw
YW4+PC9mb250Pjxmb250DQpmYWNlPSJBcmlhbCBVbmljb2RlIE1TIj48c3BhbiBzdHlsZT0nZm9u
dC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiJz7vv708L3NwYW4+PC9mb250PjQgbHVnbGlvIDIw
MDcgMTguNDc8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBm
YWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5UbzogRGllZ28g
Q2F2aWdsaWEgKEdBL0VSSSk7IDxhDQpocmVmPSJtYWlsdG86Y2NhbXBAb3BzLmlldGYub3JnIj5j
Y2FtcEBvcHMuaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+
PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTIuMHB0Jz5TdWJqZWN0OiBSRTogU3dpdGNoaW5nIENhcGFiaWxpdHkgb2YgUGhv
dG9uaWMgTGlua3Mgd2l0aCBUcmFuc3BvbmRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5IaSBEaWVnby48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGlj
Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+SSBiZWxpZXZlIHdlIHNob3VsZCByZWZl
ciB0byB0aGUgSG9sbHkgUkZDIDM5NDUsIGNoYXB0ZXIgMSwgdmVyc2UgMjo8bzpwPjwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1T
IEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0i
TVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+LSAmcXVvdDtMYW1iZGEg
U3dpdGNoIENhcGFibGUmcXVvdDsgaW50ZXJmYWNlcyAmcXVvdDtjYW4gb3BlcmF0ZSBhdCB0aGUg
bGV2ZWwgb2YgYW4gKmluZGl2aWR1YWwgd2F2ZWxlbmd0aComcXVvdDsgW29yIGEgJnF1b3Q7Z3Jv
dXAgb2Ygd2F2ZWxlbmd0aHMmcXVvdDtdLCBtZWFuaW5nIHRoYXQgeW91IG1hbmlwdWxhdGUgdmFs
dWVzIG9mIHdhdmVsZW5ndGhzIChhcyBBVS00IG51bWJlcnMgW29yIEFVLTQgcmFuZ2VzXSBmcm9t
IGFuIFNESCBwb3J0QSB0byBTREggcG9ydEIpLCBsaWtlIGluIGEgUk9BRE07PG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJN
UyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9
Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPi0gJnF1b3Q7RmliZXIt
U3dpdGNoIENhcGFibGUmcXVvdDsgaW50ZXJmYWNlcyAmcXVvdDtjYW4gb3BlcmF0ZSBhdCB0aGUg
bGV2ZWwgb2YgYSBzaW5nbGUgb3IgbXVsdGlwbGUgKmZpYmVycyomcXVvdDssIG1lYW5pbmcgKnNw
YXRpYWwgc3dpdGNoaW5nKiB3aGVyZSB5b3UgZG9uJ3QgY29uc2lkZXIgdGhlIHR5cGUgb2Ygc2ln
bmFsIHRoYXQgcG9ydHMgY29udmV5IChjb3VsZCBiZSBhbnl0aGluZyBsaWtlIGEgYmxhY2sgYW5k
IHdoaXRlIHNpZ25hbCwgYSB3YXZlbGVuZ3RoLCBhIFdETSBtdWx0aXBsZXgsIHNvbWUgb3B0aWNh
bCBwYWNrZXRzLi4uKSwgbGlrZSBpbiBhIE9PTyBQWEMuPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPlRvIHN0aWNrIHdpdGggc3RyaWN0IHRlcm1p
bm9sZ3k6IGxhbWJkYSA9IHdhdmVsZW5ndGggPSAoc3BlZWRPZkxpZ2h0IC8gZnJlcXVlbmN5KTxv
OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9Ymxh
Y2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1i
bGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5TbyBp
ZiB5b3UgbmVlZCB0byBkbyAmcXVvdDtmcmVxdWVuY3kgc3dpdGNoaW5nJnF1b3Q7LCB0aGVuIGl0
IGlzIHRoZSBzbyBjYWxsZWQgJnF1b3Q7bGFtYmRhIHN3aXRjaGluZyZxdW90Oy4gOi0pPG86cD48
L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBm
YWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNr
IGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkFueXdheSwg
dGhpcyBpcyBteSB1bmRlcnN0YW5kaW5nLCBzbyBpZiBJJ20gd3Jvbmcgb3IgaWYgaXQncyBhIHZv
Y2FidWxhcnkgaXNzdWUgYmVjYXVzZSB5b3UgZmluZCB0aGF0IHRlcm1zIGFyZSBpbmFwcHJvcHJp
YXRlLCB0aGVuIHdlJ2QgYmV0dGVyIGFzayBmYXRoZXIgQWRyaWFuIGFuZCBzaXN0ZXIgRGVib3Jh
aC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9y
PWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29s
b3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+
Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMg
Y29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw
dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9
MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIu
MHB0Jz5KdWxpZW48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6
ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz
aXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEyLjBwdCc+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGlj
Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+RnJvbTogRGllZ28gQ2F2aWdsaWEgKEdB
L0VSSSkgWzxhDQpocmVmPSJtYWlsdG86ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29tIj4mbHQ7
bWFpbHRvOmRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbSZndDs8L2E+PGENCmhyZWY9Im1haWx0
bzpkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb20iPm1haWx0bzpkaWVnby5jYXZpZ2xpYUBlcmlj
c3Nvbi5jb208L2E+XSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0K
c2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250
DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjEyLjBwdCc+SGkgSnVsaWVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJl
Pjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxw
cmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTIuMHB0Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgQWN0dWFsbHkgbm90IHRoZSBQWEMgSSBoYWQgaW4gbWluZCBpcyBhYmxlIHRv
IHN3aXRjaCBhIHNpbmdsZSBsYW1iZGEgSSBkaWRuJ3QgYnV0IHRoZSBtdXgvZGVtdXggSW4gdGhl
IHBpY3R1cmUgc29ycnkuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN
CnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9u
dA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMi4wcHQnPlRoZSBwb2ludCBJIGZhaWxlZCB0byBpbGx1c3RyYXRlIGlzIHRoZSBhbWJp
Z3VpdHkgb2YgdGhlIHRlcm0gJnF1b3Q7TGFtYmRhIFN3aXRjaCBDYXBhYmxlJnF1b3Q7IGdpdmVu
IHRoYXQgdGhlcmUgdHdvIHBvc3NpYmxlIHdheXMgdG8gc3dpdGNoIGEgbGFtYmRhLiZuYnNwOyA8
bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJs
YWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9
YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhl
IGZpcnN0IG9uZSBpcyB0aGUgc3BhdGlhbCBvbmU6IChMYW1iZGExIHBvcnRBKSAtLSZndDsgKExh
bWJkYTEgcG9ydEIpIHRoaXMgaXMgdGhlIHdheSBhbiBhbGwgb3B0aWNhbCBzd2l0Y2ggd29ya3Mg
YW5kIHRoaXMgd2h5IHRoZXJlIGlzIHRoZSBsYW1iZGEgY29udGludWl0eSBjb25zdHJhaW50IGlu
IHBob3RvbmljIG5ldHdvcmtzLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhlIHNlY29uZCBvbmUgaXMgdGhlIGZyZXF1ZW5jeSBz
d2l0Y2hpbmc6IChMYW1iZGExIHBvcnRBKSAtLSZndDsgKExhbWJkYTIgcG9ydEEpIHRoaXMgc3dp
dGNoaW5nIGNhbiBiZSBkb25lIHZpYSBhIHRyYW5zcG9uZGVyIChPRU8pIGRldmljZS4mbmJzcDsg
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1i
bGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9y
PWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPk9m
IGNvdXJzZSBpcyBwb3NzaWJsZSB0byBtaXggdGhlIHR3byBzd2l0Y2hpbmcgaGF2aW5nIChMYW1i
ZGExIHBvcnRBKSAtLSZndDsgKExhbWJkYTIgcG9ydEIpPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPk15IGltcHJlc3Npb24gaXMgdGhhdCB0aGUg
ZGVmaW5pdGlvbiAmcXVvdDtMYW1iZGEgU3dpdGNoIENhcGFibGUmcXVvdDsgcmVmZXJzIHRvIHRo
ZSBzcGF0aWFsIHN3aXRjaGluZyBhbmQgdGh1cyBJIGRvbid0IGtub3cgaG93IHRvIG1vZGVsIHRo
ZSBmYWN0IHRoYXQgYWZ0ZXIvYmVmb3JlIGEgcGhvdG9uaWMgbWF0cml4IEkgaGF2ZSBhIHRyYW5z
cG9uZGVyLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0K
c2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250
DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjEyLjBwdCc+SSBob3BlIEkndmUgbWFkZSBteSBxdWVzdGlvbiBjbGVhcmVyLjxvOnA+PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFj
ZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBm
YWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5CZXN0IFJlZ2Fy
ZHM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9y
PWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29s
b3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+
RGllZ288bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNv
bG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMg
Y29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw
dCc+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
cmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+RnJvbTogTUVVUklDIEp1bGllbiBSRC1DT1JFLUxB
TiBbPGENCmhyZWY9Im1haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS1mdGdyb3VwLmNvbSI+Jmx0
O21haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS1mdGdyb3VwLmNvbSZndDs8L2E+PGENCmhyZWY9
Im1haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS1mdGdyb3VwLmNvbSI+bWFpbHRvOmp1bGllbi5t
ZXVyaWNAb3JhbmdlLWZ0Z3JvdXAuY29tPC9hPl0gPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPlNlbnQ6IG1hcnRlZDwvc3Bhbj48L2ZvbnQ+PGZv
bnQNCmZhY2U9IkFyaWFsIFVuaWNvZGUgTVMiPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp
YWwgVW5pY29kZSBNUyInPu+/vTwvc3Bhbj48L2ZvbnQ+MyBsdWdsaW8gMjAwNyAxOS4yMTxvOnA+
PC9vOnA+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhp
YyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290
aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VG86IERpZWdvIENhdmlnbGlhIChH
QS9FUkkpOyA8YQ0KaHJlZj0ibWFpbHRvOmNjYW1wQG9wcy5pZXRmLm9yZyI+Y2NhbXBAb3BzLmll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXpl
PTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy
LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTIuMHB0Jz5TdWJqZWN0OiBSRTogU3dpdGNoaW5nIENhcGFiaWxpdHkgb2YgUGhvdG9uaWMgTGlu
a3Mgd2l0aCBUcmFuc3BvbmRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+
PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTIuMHB0Jz5IaSBEaWVnby48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEyLjBwdCc+SWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91ciAm
cXVvdDtsYW1iZGEgc3dpdGNoJnF1b3Q7IGJ5IGl0c2VsZiBpcyBhIFBYQyB0aGF0PG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNl
PSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZh
Y2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPmhhcyBvbmx5ICZx
dW90O0ZpYmVyLVN3aXRjaCBDYXBhYmxlJnF1b3Q7IGludGVyZmFjZXMuIFRoZW4sIHlvdSBhZGQ8
bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJs
YWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9
YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+bGFt
YmRhLWNvbnZlcnNpb24gY2FyZHMgdG8gaXQuIFNvLCBjb3JyZWN0IG1lIGlmIEknbSB3cm9uZyAo
eW91IG9yPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBj
b2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0
Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0z
IGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w
cHQnPmFueW9uZSBlbHNlKSwgYnV0IHdoZXRoZXIgeW91IGRvIGEgbGFtYmRhIGNvbnZlcnNpb24g
aW5zaWRlIGEgY2FyZCBvciBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+
PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTIuMHB0Jz5hIGNvcmUgbWF0cml4LCB0aGlzIG5ldyBpbnRlcmZhY2Ugb24geW91
ciBnbG9iYWwgZGV2aWNlIGlzIGFibGUgdG8gd29yazxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5vbiBsYW1iZGFzIGFueXdheSZuYnNwOyBbKGxh
bWJkYSAxLCBwb3J0IEEpIC0tJmd0OyAobGFtYmRhMiwgcG9ydCBCKV0uIEFzIGE8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9
Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFj
ZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+cmVzdWx0LCB5b3Ug
bmVlZCB0byBhZHZlcnRpc2UgeW91ciBtb3N0IGZsZXhpYmxlIGNhcGFiaWxpdHksIHdoaWNoIGlz
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1i
bGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9y
PWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZx
dW90O0xhbWJkYSBTd2l0Y2ggQ2FwYWJsZSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+SWYgeW91IHVzZWQgJnF1b3Q7RlNDJnF1b3Q7
LCB5b3Ugd291bGRuJ3QgYmUgYWJsZSB0byBjb250cm9sIHlvdXIgJnF1b3Q7bGFtYmRhPG86cD48
L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBm
YWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNr
IGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPnN3YXBwaW5n
JnF1b3Q7IGNhcmQsIGFzIExTUHMgYXJlIGxpa2UgbGlzdHMgb2YgZmliZXJzIGFuZCBsYWJlbHMg
YXJlbid0PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBj
b2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0
Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0z
IGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w
cHQnPndhdmVsZW5ndGhzIGJ1dCBwb3J0cy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEyLjBwdCc+QnV0IG1heWJlIEkgZGlkbid0IGdldCB5b3VyIGFjdHVh
bCBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0z
IGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w
cHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXpl
PTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy
LjBwdCc+TXkgMiBjZW50cyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9u
dA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEyLjBwdCc+SnVsaWVuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+
PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy
ZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMi4wcHQnPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48
L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBm
YWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNr
IGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkZyb206IDxh
DQpocmVmPSJtYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnIj5vd25lci1jY2FtcEBvcHMu
aWV0Zi5vcmc8L2E+IFs8YQ0KaHJlZj0ibWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyI+
Jmx0O21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9hPjxhDQpocmVmPSJtYWls
dG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnIj5tYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYu
b3JnPC9hPl0gT248bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6
ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz
aXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEyLjBwdCc+QmVoYWxmIE9mIERpZWdvIENhdmlnbGlhIChHQS9FUkkpPG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBH
b3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1T
IEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkhpIGFsbCw8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9
Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFj
ZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkndmUgYSBkb3VidCBhYm91dCBob3cgdG8g
bW9kZWwgdGhlIGZvbGxvd2luZyBzaXR1YXRpb24uPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m
b250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMi
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhp
YyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290
aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBH
b3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1T
IEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyArLS0tLS0tLS0tLS0tLS0tLS0rPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJl
PjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
cmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwtLS0tLS0tKzxvOnA+PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMg
R290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJN
UyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE9FTyZu
YnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0K
c2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IExhbWJkYSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8LS0tLS0tLSs8bzpwPjwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZh
Y2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sg
ZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3dpdGNoJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy
ZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48
cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEyLjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+
PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3Ro
aWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdv
dGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyArLS0tLS0tLS0tLS0tLS0tLS0rPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxw
cmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9
Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFj
ZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBm
YWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNr
IGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPlRoZSBub2Rl
IGl0c2VsZiBpcyBhYmxlIHRvIGNyb3NzIGNvbm5lY3Qgb25seSB0aGUgTGFtYmRhIHdoaWxlIHRo
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9
YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xv
cj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5p
bnRlcmZhY2UgaGFzIGEgT0VPIHRyYW5zcG9uZGVyIHRoYXQgaXMgYWJsZSB0byBjaGFuZ2UgdGhl
IGxhbWJkYTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMg
Y29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw
dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9
MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIu
MHB0Jz5mcmVxdWVuY3kuJm5ic3A7IEluIHRoaXMgY2FzZSB0aGVyZSBhcmUgdHdvIGRpZmZlcmVu
dCAnc3dpdGNoaW5nIGNhcGFiaWxpdHknPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxw
cmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPnRoZSBzcGF0aWFsIG9uZSB0aGF0IGlzIHBlcmZvcm1lZCBi
eSB0aGUgc3dpdGNoIChsYW1iZGEgMSwgcG9ydCBBKSAtLSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhp
YyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290
aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+KGxhbWJkYTEsIHBvcnQgQikgYW5k
IHRoZSBmcmVxdWVuY3kgc3dpdGNoaW5nIGlzIGRvbmUgYnkgdGhlIE9FTzxvOnA+PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMg
R290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJN
UyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz50cmFuc3BvbmRlci4mbmJz
cDsgV2l0Y2gga2luZCBvZiBpbnRlcmZhY2Ugc3dpdGNoaW5nIGNhcGFiaWxpdHkgSSBoYXZlIHRv
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1i
bGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9y
PWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPmFk
dmVydGlzZT88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0z
IGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w
cHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXpl
PTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy
LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0K
c2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMi4wcHQnPkJSPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0K
c2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMi4wcHQnPkRpZWdvPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN
CnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9u
dA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+
PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTIuMHB0Jz5EaWVnbyBDYXZpZ2xpYTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5Qcm9kdWN0IDxzdDE6cGxhY2UNCnc6c3Q9Im9u
Ij48c3QxOkNpdHkgdzpzdD0ib24iPkxpbmU8L3N0MTpDaXR5PiA8c3QxOlN0YXRlIHc6c3Q9Im9u
Ij5PTjwvc3QxOlN0YXRlPjwvc3QxOnBsYWNlPiBCQk48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+UEEgQnJvYWRiYW5kIEJORVQ8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9
Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFj
ZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBm
YWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNr
IGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPk1hcmNvbmkg
Uy5wLkE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNv
bG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMg
Y29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw
dCc+RXJpY3Nzb24gR2xvYmFsIDxzdDE6UGxhY2VOYW1lDQp3OnN0PSJvbiI+UHJvZHVjdDwvc3Qx
OlBsYWNlTmFtZT4gPHN0MTpQbGFjZVR5cGUgdzpzdD0ib24iPkNlbnRlcjwvc3QxOlBsYWNlVHlw
ZT4gLSA8c3QxOmNvdW50cnktcmVnaW9uDQp3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+
SXRhbHk8L3N0MTpwbGFjZT48L3N0MTpjb3VudHJ5LXJlZ2lvbj48bzpwPjwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhp
YyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290
aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VmlhIEFuYWduaW5hLDIwMzxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sg
ZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFj
ayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4wMDE4LCBS
b21hICwgPHN0MTpjb3VudHJ5LXJlZ2lvbg0KdzpzdD0ib24iPjxzdDE6cGxhY2UgdzpzdD0ib24i
Pkl0YWx5PC9zdDE6cGxhY2U+PC9zdDE6Y291bnRyeS1yZWdpb24+PG86cD48L286cD48L3NwYW4+
PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3Ro
aWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdv
dGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxhDQpocmVmPSJodHRwOi8vd3d3
LmVyaWNzc29uLmNvbSI+d3d3LmVyaWNzc29uLmNvbTwvYT4gJmx0OzxhDQpocmVmPSJodHRwOi8v
d3d3LmVyaWNzc29uLmNvbS8iPiZsdDtodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8mZ3Q7PC9hPjxh
DQpocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8iPmh0dHA6Ly93d3cuZXJpY3Nzb24uY29t
LzwvYT4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXpl
PTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy
LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0K
c2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250
DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjEyLjBwdCc+T2ZmaWNlOiZuYnNwOyArMzkgMDEwIDYwMCAzNzM2PG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBH
b3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1T
IEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkZheDogKzM5IDAxMCA2MDAg
MzQ5MzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29s
b3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PHN0MTpDaXR5DQp3OnN0
PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9
Ik1TIEdvdGhpYyI+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPk1vYmlsZTwvc3Bh
bj48L2ZvbnQ+PC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT46ICszOSAzMzUgNzE4MTc2MjxvOnA+PC9v
OnA+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGlj
Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+RW1haWw6IDxhDQpocmVmPSJtYWlsdG86
ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29tIj5kaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb208
L2E+Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXpl
PTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy
LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTIuMHB0Jz5UaGlzIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBz
b2xlbHkgZm9yIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz
aXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN
CnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTIuMHB0Jz5hZGRyZXNzZWUocykuIEFueSB1bmF1dGhvcml6ZWQgcmV2aWV3LCB1c2UsIGRp
c2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxw
cmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPmlzIHByb2hpYml0ZWQuIElmIHlvdSBiZWxpZXZlIHRoaXMg
bWVzc2FnZSBoYXMgYmVlbiBzZW50IHRvIHlvdSBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5lcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyIGJ5IHJlcGx5aW5nIHRvIHRoaXMgdHJhbnNtaXNzaW9uIGFuZDxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290
aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBH
b3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5kZWxldGUgdGhlIG1lc3NhZ2Ug
d2l0aG91dCBkaXNjbG9zaW5nIGl0LiBUaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkUtbWFpbCBpbmNsdWRpbmcgYXR0YWNobWVu
dHMgaXMgc3VzY2VwdGlibGUgdG8gZGF0YSBjb3JydXB0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGlj
Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3Ro
aWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5pbnRlcmNlcHRpb24sIHVuYXV0aG9y
aXplZCBhbWVuZG1lbnQsIHRhbXBlcmluZyBhbmQgdmlydXNlcywgYW5kIHdlIG9ubHk8bzpwPjwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZh
Y2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sg
ZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+c2VuZCBhbmQg
cmVjZWl2ZSBlbWFpbHMgb24gdGhlIGJhc2lzIHRoYXQgd2UgYXJlIG5vdCBsaWFibGUgZm9yIGFu
eSBzdWNoPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MyBj
b2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0
Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0z
IGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w
cHQnPmNvcnJ1cHRpb24sIGludGVyY2VwdGlvbiwgYW1lbmRtZW50LCB0YW1wZXJpbmcgb3Igdmly
dXNlcyBvciBhbnk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6
ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz
aXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEyLjBwdCc+Y29uc2VxdWVuY2VzIHRoZXJlb2YuPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48L2Jsb2NrcXVvdGU+DQoNCjxwcmUgd3JhcD0iIj48Zm9u
dCBzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48
Zm9udCBzaXplPTMgY29sb3I9YmxhY2sNCmZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMi4wcHQnPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpw
PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNr
IGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPldhdGFydSBJ
bWFqdWt1QE5UVCBOZXR3b3JrIElubm92YXRpb24gTGFiczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VEVMOiArODEtNDYtODU5LTQzMTU8bzpwPjwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZh
Y2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkZBWDogKzgxLTQ2
LTg1OS01NTQxPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9
MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIu
MHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6
ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz
aXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGljIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN
CnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9u
dA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMi4wcHQnPiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQoNCjxw
IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgUEdvdGhp
YyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48YnI+DQo8YnI+DQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cHJlPjxmb250IHNpemU9MyBjb2xvcj1ibGFjayBmYWNl
PSJNUyBHb3RoaWMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4tLSA8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9
Ik1TIEdvdGhpYyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPj09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iTVMgR290aGlj
Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+RHIgR3JlZyBCZXJuc3RlaW4sIEdyb3R0
byBOZXR3b3JraW5nICg1MTApIDU3My0yMjM3PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJl
PjxwcmU+PGZvbnQNCnNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJNUyBHb3RoaWMiPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
cmU+PC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K

------_=_NextPart_001_01C7C2C0.8B9CA9C7--



Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jul 2007 06:55:27 +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: new draft about signaling for a bidirectionl lightpath
Date: Tue, 10 Jul 2007 08:52:17 +0200
Message-ID: <[e-mail]>
Thread-Topic: new draft about signaling for a bidirectionl lightpath
Thread-Index: AcfAOu8SSG0RZRFtS+OKtUGX0oGvIgCgKesg
From: "Diego Caviglia (GA/ERI)" <[e-mail]>
To: "Hiroaki Harai" <[e-mail]>, <[e-mail]>

Hi Hiroaki,
           I think that this is a real problem that can be addressed in =
several way:

1 Label set and Upstream label + crankback: this should works but of =
course is not optimal;
2 The way you proposed with Upstream label set;
3 A modification to the routing protocol in order to advertise the =
available lambdas;
4 A centralized PCE approach adding manually (or via modified routing =
protocols) the lambda availability

The above should covers the lambda continuity problem but not the =
optical impairments one.

Seems that after some years of sleeping the Lambda switching is becoming =
interesting again there are several drafts on this topic.

Best regards

Diego


-----Original Message-----
From: Hiroaki Harai [mailto:[e-mail]]=20
Sent: sabato 7 luglio 2007 4.01
To: Diego Caviglia (GA/ERI); [e-mail]
Subject: Re: new draft about signaling for a bidirectionl lightpath

Hi, Diego.

I think the usage that you mentioned (using label set and upstream
label) is not enough by the following two reasons.

1. [Non-support of multiple lambdas] Upstream label object conveys
   only ONE label, which is likely to face lack of the same lambda as
   that in the previous link. We have high blocking probability for
   LSP setup. If we convey multiple lambdas for upstream, the
   probability would be reduced significantly (but, we cannot convey).

   Someone may want to change lambda in Upstream Label into other
   lambda among lambdas in the Label Set when the lambda in Upstream
   Label is not acceptable further. However, according to Section 3.1
   of RFC 3473, if label in Upstream Label is not acceptable, PathErr
   is generated.  Different from Suggested Label, we have no chance to
   change. So, using Upstream Label is not enough.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

   3.1 Procedures (RFC 3473)
   The process of establishing a bidirectional LSP follows the
   establishment of a unidirectional LSP with some additions. To
   support bidirectional LSPs an Upstream_Label object is added to the
   Path message. The Upstream_Label object MUST indicate a label that
   is valid for forwarding at the time the Path message is sent.
   When a Path message containing an Upstream_Label object is
   received, the receiver first verifies that the upstream label is
   acceptable. If the label is not acceptable, the receiver MUST issue
   a PathErr message with a "Routing problem/Unacceptable label value"
   indication. The generated PathErr message MAY include an Acceptable
   Label Set, see Section 4.1.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


2. [Keep flexibility] The same lambda on both directions may not
   reqested for some bidirectional LSPs different from the case in
   this draft. In this case, once we pose the same lambda constraint
   against upstream label, we lose flexiblity to setup LSPs by
   different lambda in each direction.

Best regards,
- Hiroaki  =20



From: "Diego Caviglia (GA/ERI)" <[e-mail]>
Subject: RE: new draft about signaling for a bidirectionl lightpath
Date: Fri, 6 Jul 2007 15:00:13 +0200
Message-ID: =
<[e-mail]>

>=20
> Hi Hiroaki,
>            Not clear to me why the mechanism using label set with the =
same lambda as the Upstream label is not enough here.  =20
>=20
> BR
>=20
> Diego
>=20
>=20
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On =
Behalf Of Hiroaki Harai
> Sent: venerd=EC 6 luglio 2007 3.10
> To: [e-mail]
> Subject: new draft about signaling for a bidirectionl lightpath
>=20
> Hi everyone,
>=20
> We posted a new draft about GMPLS signaling for a bidirectional
> lightpath setup as follows.
> http://www.ietf.org/internet-drafts/draft-xu-rsvpte-bidir-wave-00.txt
>=20
> =3D=3D=3D=3D=3D=3D
> Title   : Extensions to GMPLS RSVP-TE for Bidirectional Lightpath with
>           the Same Wavelength
> Authors : S. Xu, H. Harai, and D. King
> Filename: draft-xu-rsvpte-bidir-wave-00.txt
> =09
> Abstract: For bidirectional lightpaths provisioning, in the case of
> optical nodes that do not support wavelength conversion, it would be
> necessary to use the same wavelength along the route on each
> direction. In certain optical network scenarios, the use of the same
> wavelength on both directions would be advantageous.  For instance,
> some type of ROADMs may add/drop the same wavelength
> simultaneously. In another case, the users' optical end nodes are
> equipped with fixed-wavelength transponders.
>=20
> This document describes extensions to RSVP-TE signaling for=20
> bidirectional wavelength lightpaths that require the same wavelength =
on=20
> both directions. By using an LSP_ATTRIBUTES object defined in =
[RFC4420],=20
> the extensions enable the new type lightpaths to support the low cost=20
> configuration at users' optical end nodes.
> =3D=3D=3D=3D=3D=3D
>=20
> We believe that selecting a single wavelength on both directions for a
> bidirectional LSP is very real. And our suggestion in this draft is a
> simple one.
>=20
> We appreciate your comments and feedbacks.
>=20
> With best regards,
> Hiroaki
>=20
> -------
> Hiroaki Harai, Ph.D. (http://nag.nict.go.jp/)
> Network Architecture Group, New Generation Network Research Center
> National Institute of Information and Communications Technology =
(NICT), JAPAN.
> Email: [e-mail];  Phone: [phone];  FAX: =
[phone]
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 21:48:10 +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: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Date: Mon, 9 Jul 2007 23:46:29 +0200
Message-ID: <[e-mail]>
Thread-Topic: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Thread-Index: Ace/Iv/wATkVETcSTT+CAQmeajDxfgBrSD/wAFqvezAAAaANEAADKfYgAACtxsAABPVCIAACS8cg
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Hassan Sheikh \(hassans\)" <[e-mail]>, "Igor Bryskin" <[e-mail]>, "Zafar Ali \(zali\)" <[e-mail]>, "Lou Berger" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Tomohiro Otani" <[e-mail]>

=20

> -----Original Message-----
> From: Hassan Sheikh (hassans) [mailto:[e-mail]]=20
> Sent: Monday, July 09, 2007 10:15 PM
> To: PAPADIMITRIOU Dimitri; Igor Bryskin; Zafar Ali (zali);=20
> Lou Berger; Igor Bryskin; [e-mail]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Tomohiro Otani
> Subject: RE: Follow-up on comments on=20
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
>=20
>=20
> There are two problems with "gratuitous ARP" that I have encountered
> while testing:
> 1- It is not 100% reliable and these message can get lost /dropped
> unless both ends of the link are fully operational.

the same would happen with any other in-band messaging
that share the same end-points (side note what do you=20
mean by "both ends of the link are fully operational")

> 2- What happens when ARP cache times out - i.e no activity on the data
> plane. Then we need another mechanism to kick start and=20
> populate the ARP entries.

do i well understand here that one could have a case=20
where local ARP cashes could clear within X min w/o
any packet being exchanged ?

assuming that would be the case (is that really the
case outside any test/demo context) are you going to=20
re-signal the LSP just to be sure that the ARP cache=20
entry stays up ?=20

> What is being asked here is to associate the GMPLS LSP=20
> (considered to a
> p-p link) endpoints with an ARP entry just like you would for a native
> Ethernet link. In this case, we would like to remove the dependency on
> the underlying Ethernet layer. This case is applicable when the GMPLS
> LSP is setup over an Ethernet link.

if my understanding of the problem described by Zafar is
correct, the case described is not GMPLS over an Ethernet=20
link but GMPLS LSP setup resulting in an Ethernet link=20

> Thx
> hassan
>=20
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri
> [mailto:[e-mail]]=20
> Sent: Monday, July 09, 2007 2:39 PM
> To: Igor Bryskin; Zafar Ali (zali); Lou Berger; Igor Bryskin;
> [e-mail]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> (hassans);
> Tomohiro Otani
> Subject: RE: Follow-up on comments on
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
>=20
> igor,=20
>=20
> actually, we have ARP (or ND in case of v6) for address resolution
>=20
> the whole discussion point for me (reading the material from zafar) is
> that he wants to remove a dependency about IPv4 running over Ethernet
> that is (by definition not dependent of GMPLS but) resulting from the
> use of GMPLS to establish the LSP X with GPID =3D Ethernet (Eth over =
X)=20
>=20
> now, i am still not sure why zafar doesn't propose the use of
> "gratuitous ARP" once the Ethernet i/f is up ?
>=20
> thanks,
> -d.
>=20
>=20
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Igor Bryskin [mailto:[e-mail]]
> > Sent: Monday, July 09, 2007 7:32 PM
> > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger;=20
> Igor Bryskin;
>=20
> > [e-mail]
> > Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> > (hassans); Tomohiro Otani
> > Subject: RE: Follow-up on comments on=20
> > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> >=20
> > Dimitri,
> >=20
> > What I was saying is that if a client layer IP uses a server layer=20
> > Ethernet than the server layer should know what the Layer=20
> Information
> > (LI) overhead to put on client's Adapted Information (AI),=20
> I mean this
>=20
> > information belongs to Ethernet, not to IP, and it is not IP's=20
> > business to identify this information. And as you pointed=20
> out a pair=20
> > of IP routers could be inter-connected by Ethernet trail, while=20
> > another pair by SDH trail and it is not IP's business to=20
> determine LI=20
> > in either of server layers. So, how is it different from=20
> what you say?
> >=20
> > Igor
> >=20
> > -----Original Message-----
> > From: PAPADIMITRIOU Dimitri
> > [mailto:[e-mail]]
> > Sent: Monday, July 09, 2007 12:18 PM
> > To: Igor Bryskin; Zafar Ali (zali); Lou Berger; Igor Bryskin;=20
> > [e-mail]
> > Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> > (hassans); Tomohiro Otani
> > Subject: RE: Follow-up on comments on
> > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> >=20
> > =20
> >=20
> >=20
> >=20
> > sorry but we don't discuss about any over Ethernet here but between=20
> > two IP/MPLS LSR
> >=20
> > hence, what is different here from two LSRs interconnected by an=20
> > Ethernet link over X ?
> >=20
> > zafar can you clarify this point ? because from what i read in your=20
> > draft it is because the address to be resolved creates an issue but=20
> > why should that be different from what you see today between two=20
> > Ethernet hosts connected back-to-back ?
> >=20
> > -d.
> > =20
> >=20
> > > -----Original Message-----
> > > From: Igor Bryskin [mailto:[e-mail]]
> > > Sent: Monday, July 09, 2007 5:46 PM
> > > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor=20
> > > Bryskin; [e-mail]
> > > Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> > > (hassans); Tomohiro Otani
> > > Subject: RE: Follow-up on comments on=20
> > > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> > >=20
> > > Zafar,
> > >=20
> > > Let's look at your situation with eyes of an ITU-T folk :=3D)
> > >=20
> > > Your client layer is IP, and your server layer (the one
> > that provides
> > > connectivity between IP routers) is Ethernet. This means=20
> that a link
>=20
> > > in IP layer is provided by a connection in Ethernet layer. The
> > MAC header
> > > you need to encapsulate your IP CI is a label of the Ethernet=20
> > > connection and should be learned via signaling before the=20
> connection
>=20
> > > is used. Note also that IP layer is not the only client=20
> of Ethernet,
>=20
> > > for example, Ethernet-in-Ethernet is quite possible, so you can't=20
> > > rely
> > on protocols
> > > like ARP.=20
> > >=20
> > > Cheers,
> > > Igor
> > >=20
> > > -----Original Message-----
> > > From: [e-mail]=20
> [mailto:[e-mail]] On=20
> > > Behalf Of PAPADIMITRIOU Dimitri
> > > Sent: Saturday, July 07, 2007 3:54 PM
> > > To: Zafar Ali (zali); Lou Berger; Igor Bryskin; [e-mail]
> > > Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> > > (hassans); Tomohiro Otani
> > > Subject: RE: Follow-up on comments on=20
> > > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> > >=20
> > > zafar
> > >=20
> > > it is the other way around, because you have different
> > subnets you can
> > > not make use of existing mechanisms
> > >=20
> > > "The solution we are pushing for is that we need a mechanism that=20
> > > allows us to resolve ARP directly for the GMPLS tunnel ip=20
> addresses.
>=20
> > > This removes any dependency on the underlying Ethernet=20
> links or the=20
> > > addressing scheme that is used for TE links i.e. numbered
> > links in the
> > > same or different subnets."
> > >=20
> > > hence the first question is why shall this be different ?
> > >=20
> > > -d.
> > >=20
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Zafar Ali (zali)
> > > > Sent: Thursday, July 05, 2007 6:39 PM
> > > > To: Lou Berger; Igor Bryskin; [e-mail]
> > > > Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> > > > (hassans); Tomohiro Otani
> > > > Subject: Follow-up on comments on=20
> > > > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> > > >=20
> > > > Hi Lou, Igor, ccamper, et al,
> > > > =20
> > > > Here is a follow-up on our AI from last WG meeting on=20
> the comments
>=20
> > > > received on=20
> > > >=20
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt. We are=20
> > > > planning to revise the document based on your feedback.
> > > > Please advise if you have any further comment/ suggestion.=20
> > > > =20
> > > > The issue is focused around the use of the GMPLS tunnel as a=20
> > > > point-to-point link using Ethernet TE links. Unlike pos links=20
> > > > where a L2 adjacency resolution is not required, the Ethernet=20
> > > > links require that the ARP be resolved (aka Layer 2 MAC
> > > > address) before any forwarding works on this link. It is not a=20
> > > > case of broken implementation. We (router vendors) cannot work=20
> > > > around ARP. What we need to do is to provide clear direction or=20
> > > > recommendation for vendors on how to ARP for GMPLS controlled=20
> > > > Ethernet interfaces. Or else, all vendors will=20
> implement whatever=20
> > > > ARP mechanism works for them in terms of forwarding.=20
> E.g., there=20
> > > > is an interop issue between Juniper and Cisco (from a fwding=20
> > > > perspective) when Ethernet links are used (Both do=20
> ARP). We had to
>=20
> > > > find workarounds to make things work (at ISO Core and=20
> in private=20
> > > > testing). The same will be the case between Cisco, Juniper and=20
> > > > other vendors.
> > > > =20
> > > > The solution we are pushing for is that we need a=20
> mechanism that=20
> > > > allows us to resolve ARP directly for the GMPLS tunnel ip=20
> > > > addresses. This removes any dependency on the=20
> underlying Ethernet=20
> > > > links or the addressing scheme that is used for TE links i.e.=20
> > > > numbered links in the same or different subnets.
> > > > =20
> > > > In the following, we describe the situation with=20
> numbered Ethernet
>=20
> > > > links and Unnumbered Ethernet links (the assumption is that the=20
> > > > GMPLS tunnel is a ipv4 numbered link in both
> > instances).
> > > > =20
> > > > Consider the scenario
> > > > =20
> > > > <----------------------------------------------GMPLS
> > > > Tunnel------------------------------------------>
> > > > =20
> > > > RTR1 <------GE data link/TE link -----> OXC <------ GE data=20
> > > > link/TE link -----> RTR2
> > > >                   segment # 1                                =20
> > > >   segment # 2
> > > > There are two instance to consider:
> > > > =20
> > > > (a) When numbered TE links are used but segment # 1 and=20
> segment #=20
> > > > 2 are in different subnets (valid scenario)
> > > >      In this situation we really have no way of resolving ARP=20
> > > > using the addresses of the underlying TE link Ethernet=20
> links w/o=20
> > > > using static ARP entries. The issue is that the subnets are=20
> > > > different so the ARP request received by RTR2 from RTR1 will be=20
> > > > rejected as it is not known to RTR2 and vice versa.
> > > > Instead, if the ARP request if for the GMPLS tunnel=20
> instead then=20
> > > > there should be no problem as the GMPLS tunnel is p-p link with=20
> > > > IPV4 addresses in the same subnet.
> > > > Verdict: If we have the ARP resolution mechanism tied in to the=20
> > > > GMPLS tunnel interfaces addresses then there is no issue or=20
> > > > dependency
> > > > =20
> > > > (a) When numbered TE links are used and segment # 1 and=20
> segment #=20
> > > > 2 are in the same subnet.
> > > >      In this setup the GMPLS Tunnel can inherit and use the=20
> > > > ethernet link address for ARP resolution and there is=20
> no issue as=20
> > > > both segments are in the same subnet. The problem in this=20
> > > > situation is that we need to resolve the ARP for the
> > > > ipv4 addresses for the GMPLS tunnel (considered as a p-p
> > > > link) as opposed to inherit it from the underlying Ethernet
> > > TE links.
> > > > Verdict:  In this situation the ARP resolution=20
> mechanism should be
>=20
> > > > developed for the GMPLS tunnel address.
> > > > =20
> > > > (c) The third scenario is when the GMPLS tunnel is numbered but=20
> > > > the TE links are Unnumbered.
> > > >      In this case we are again faced with the same issue of
> > > > L2 ARP adjacency resolution between RTR1 and RTR2. RTR2 will=20
> > > > reject the ARP request for RTR1 when it does not find the=20
> > > > Unnumbered address (used by RTR1) in its FWDing database.
> > > > This issue would not be encountered if we were=20
> resolving the ARP=20
> > > > on GMPLS tunnel address.
> > > > Verdict: ARP resolution mechanism is required for GMPLS tunnel.
> > > > =20
> > > > (d) We also need to make sure that when the tunnel-id is unnum,=20
> > > > vendor implementation honor ARP request using loopback=20
> addresses.=20
> > > > We have also faced interop issue in this scenario.
> > > > =20
> > > > Thanks
> > > > =20
> > > > Regards... Hassan and Zafar
> > > >=20
> > >=20
> > >=20
> >=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 21:32:25 +0000
Message-ID: <[e-mail]>
Date: Mon, 09 Jul 2007 17:27:16 +0200
From: Huub van Helvoort <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: Dan Li <[e-mail]>, ccamp <[e-mail]>,  "Deborah A. Brungard" <[e-mail]>
Subject: Re: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I support this I-D to become WG-draft.

Cheers, Huub.

=====================
Adrian Farrel wrote:
> Hi,
> 
> In Prague we found that there was some support for this work, and no 
> opposition.
> 
> There were questions regarding clarifying that the work does not define 
> new process or procedures, but explains how existing procedures (i.e. 
> draft-ietf-ccamp-rsvp-restart-ext-08.txt) can be applied in a variety of 
> situations. I think that this revision has included this clarification.
> 
> There was a request to broaden the draft to cover all scenarios (not 
> just multi-node as before), and this has been done.
> 
> There was concern about whether there was "service provider" interest in 
> this work. In fact, several of the hands raised to express interest 
> worked for service providers. But I am not personally convinced that 
> this Informational work needs strong support from that sector. More to 
> the point would be support from the vendors who need to agree how they 
> will operate draft-ietf-ccamp-rsvp-restart-ext.
> 
> So, I'd like to ask the WG whether there is support to make this I-D a 
> WG draft.
> If we do, I would like to see it complete quite quickly. It would need:
> - review by vendors to make sure it is accurate
> - a bit more text on security issues
> 
> Thanks,
> Adrian
> 
> ----- Original Message ----- From: "Dan Li" <[e-mail]>
> To: "ccamp" <[e-mail]>
> Cc: "Deborah A. Brungard" <[e-mail]>; "Farrel, Adrian" 
> <[e-mail]>; "Arun Satyanarayana" <[e-mail]>
> Sent: Friday, June 22, 2007 2:08 AM
> Subject: New draft: draft-li-ccamp-gr-description-00.txt
> 
> 
>> Dear CCAMPers,
>>
>> We have published a "new" I-D:
>> http://tools.ietf.org/wg/ccamp/draft-li-ccamp-gr-description-00.txt
>>
>> This I-D replaces the previous I-D 
>> http://tools.ietf.org/wg/ccamp/draft-li-ccamp-multinodes-gr-proc-01.txt.
>>
>> According to the discussion in Prague meeting, we have:
>> 1) Changed draft to be Informational. Mainly rewords the draft to make 
>> sure that it does not give instructions that could be interpreted as 
>> defining the procedures.
>> 2) The title of the I-D has been changed to "Description of the 
>> RSVP-TE Graceful Restart Procedures", in order to wide the scope of 
>> this I-D to include the single node graceful restart scenario.
>>
>> Best regards,
>> Dan Li 
> 
> 
> 
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 21:13:17 +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: I-D  ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Date: Mon, 9 Jul 2007 23:10:47 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D  ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Thread-Index: AcfBzteD35sQEXiCT6OuSZcuBb3BtQAjN7rg
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Tomonori TAKEDA" <[e-mail]>, <[e-mail]>

tomonori


reading through this doc still unclear to me why there is no statement
that says (at the end) that the sole issue is due to the fact that
ingress node do not see both protecting and working LSPs (by definition
of diversity) and therefore across that domain, mechanisms are needed:


1. since the problem is only considered in its linear version and
associated protecting and working LSP are are both following the same
sequence, one needs to resolve the intra-domain/intra-AS trap issue (at
the SRLG/node/ link level) and prevent that that two ingress nodes (of
the same domain) do not select the same egress node (of that domain) to
reach the next domain for both protecting and working LSP ?


2. when computation is not simultaneous per domain (independently of
whether sequentially distributed or centralized) and does not result in
strict hops only (implicitly or explcitly), the only thing that remains
possible is to condition the first LSP setup with additional constraints
during its establishment


this would for me streamline this analysis in a protocol independent way
(observe that point 2 is totally independent of whether PCEs are used or
not)


now if a protocol analysis needs to be done it needs to account for call
segments in which case and compared to BRPC the discussion would be
about sequential computation along the downstream or the upstream (or
combination)


thanks,
-d.






> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Tomonori TAKEDA
> Sent: Monday, July 09, 2007 4:04 AM
> To: [e-mail]
> Subject: Fwd: I-D=20
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt=20
>=20
> Hi,
>=20
> A new version of inter-domain recovery analysis I-D have been=20
> published.
>=20
> Here are major changes:
> - Added text on security considerations section
> - Cleaned up text marked "for further study" (various places)
> - Added a reference to [PCEP-XRO]
> - Enhanced text on computing diverse paths sequentially with=20
> confidentiality
>    (Section 5.4.1)
> - Moved "terminology" section into "introduction" section
> - Removed manageability considerations section
> - Polished text
>=20
> Authors believe the document is now completed and ready for=20
> WG last call.
>=20
> Thanks,
> Tomonori
>=20
>  >To: [e-mail]
>  >From: [e-mail]
>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >X-Spam-Score: 0.0 (/)
>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >Cc: [e-mail]
>  >Subject: I-D=20
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >X-BeenThere: [e-mail]
>  >X-Mailman-Version: 2.1.5
>  >Reply-To: [e-mail]
>  >List-Id: i-d-announce.ietf.org
>  >List-Unsubscribe:
> =20
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
> :[e-mail]?subject=3Dunsubscribe>
>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>  >List-Post: <mailto:[e-mail]>
>  >List-Help: <mailto:[e-mail]?subject=3Dhelp>
>  >List-Subscribe:
> =20
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
> :[e-mail]?subject=3Dsubscribe>
>  >X-Junkmail: UCE(35)
>  >X-Junkmail-Status: score=3D35/10, host=3Dsfs2.omr.ecl.ntt.co.jp
>  >X-Junkmail-SD-Raw:
> =20
> >score=3Dsuspect(0),refid=3Dstr=3D0001.0A090207.468E8745.0129,ss=3D2,f
> gs=3D0,ip=3D156.154.16.145,so=3D2007-03-13=20
>=20
>  >10:31:19,dmn=3D5.3.14/2007-05-31
>  >
>  >A New Internet-Draft is available from the on-line Internet-Drafts
>  >directories.
>  >This draft is a work item of the Common Control and=20
> Measurement Plane
>  >Working Group of the IETF.
>  >
>  >	Title		: Analysis of Inter-domain Label=20
> Switched Path (LSP) Recovery
>  >	Author(s)	: T. Takeda, et al.
>  >	Filename	:=20
> draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >	Pages		: 23
>  >	Date		: 2007-7-6
>  >
>  >This document analyzes various schemes to realize=20
> Multiprotocol Label
>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
>  >   (LSP) recovery in multi-domain networks based on the existing
>  >   framework for multi-domain LSPs.
>  >
>  >   The main focus for this document is on establishing end-to-end
>  >   diverse Traffic Engineering (TE) LSPs in multi-domain=20
> networks. It
>  >   presents various diverse LSP setup schemes based on existing
>  >   functional elements.
>  >
>  >A URL for this Internet-Draft is:
> =20
> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
> main-recovery-analysis-01.txt
>  >
>  >To remove yourself from the I-D Announcement list, send a message to
>  >[e-mail] with the word unsubscribe in=20
> the body of
>  >the message.
>  >You can also visit=20
> https://www1.ietf.org/mailman/listinfo/I-D-announce
>  >to change your subscription settings.
>  >
>  >Internet-Drafts are also available by anonymous FTP. Login with the
>  >username "anonymous" and a password of your e-mail address. After
>  >logging in, type "cd internet-drafts" and then
>  >"get draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
>  >
>  >A list of Internet-Drafts directories can be found in
>  >http://www.ietf.org/shadow.html
>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  >
>  >Internet-Drafts can also be obtained by e-mail.
>  >
>  >Send a message to:
>  >	[e-mail].
>  >In the body type:
>  >	"FILE=20
> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
> is-01.txt".
>  >
>  >NOTE:	The mail server at ietf.org can return the document in
>  >	MIME-encoded form by using the "mpack" utility.  To use this
>  >	feature, insert the command "ENCODING mime" before the "FILE"
>  >	command.  To decode the response(s), you will need "munpack" or
>  >	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
>  >	exhibit different behavior, especially when dealing with
>  >	"multipart" MIME messages (i.e. documents which have been split
>  >	up into multiple messages), so check your local documentation on
>  >	how to manipulate these messages.
>  >
>  >Below is the data which will enable a MIME compliant mail reader
>  >implementation to automatically retrieve the ASCII version of the
>  >Internet-Draft.
>  >
>  >Content-Type: text/plain
>  >Content-ID: <[e-mail]>
>  >
>  >ENCODING mime
>  >FILE=20
> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analys
> is-01.txt
>  >
>  >
> =20
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-do
> main-recovery-analysis-01.txt>
>  >_______________________________________________
>  >I-D-Announce mailing list
>  >[e-mail]
>  >https://www1.ietf.org/mailman/listinfo/i-d-announce=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 18:43:36 +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: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Date: Mon, 9 Jul 2007 20:39:20 +0200
Message-ID: <[e-mail]>
Thread-Topic: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Thread-Index: Ace/Iv/wATkVETcSTT+CAQmeajDxfgBrSD/wAFqvezAAAaANEAADKfYgAACtxsA=
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, "Zafar Ali \(zali\)" <[e-mail]>, "Lou Berger" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Hassan Sheikh \(hassans\)" <[e-mail]>, "Tomohiro Otani" <[e-mail]>

igor,=20

actually, we have ARP (or ND in case of v6) for address resolution

the whole discussion point for me (reading the material from zafar) is
that he wants to remove a dependency about IPv4 running over Ethernet
that is (by definition not dependent of GMPLS but) resulting from the
use of GMPLS to establish the LSP X with GPID =3D Ethernet (Eth over X)=20

now, i am still not sure why zafar doesn't propose the use of
"gratuitous ARP" once the Ethernet i/f is up ?

thanks,
-d.






> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]=20
> Sent: Monday, July 09, 2007 7:32 PM
> To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor=20
> Bryskin; [e-mail]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> (hassans); Tomohiro Otani
> Subject: RE: Follow-up on comments on=20
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
>=20
> Dimitri,
>=20
> What I was saying is that if a client layer IP uses a server layer
> Ethernet than the server layer should know what the Layer Information
> (LI) overhead to put on client's Adapted Information (AI), I mean this
> information belongs to Ethernet, not to IP, and it is not=20
> IP's business
> to identify this information. And as you pointed out a pair of IP
> routers could be inter-connected by Ethernet trail, while another pair
> by SDH trail and it is not IP's business to determine LI in either of
> server layers. So, how is it different from what you say?
>=20
> Igor
>=20
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri
> [mailto:[e-mail]]=20
> Sent: Monday, July 09, 2007 12:18 PM
> To: Igor Bryskin; Zafar Ali (zali); Lou Berger; Igor Bryskin;
> [e-mail]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> (hassans);
> Tomohiro Otani
> Subject: RE: Follow-up on comments on
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
>=20
> =20
>=20
>=20
>=20
> sorry but we don't discuss about any over Ethernet here=20
> but between two IP/MPLS LSR =20
>=20
> hence, what is different here from two LSRs interconnected=20
> by an Ethernet link over X ?
>=20
> zafar can you clarify this point ? because from what i=20
> read in your draft it is because the address to be resolved
> creates an issue but why should that be different from=20
> what you see today between two Ethernet hosts connected
> back-to-back ?
>=20
> -d.
> =20
>=20
> > -----Original Message-----
> > From: Igor Bryskin [mailto:[e-mail]]=20
> > Sent: Monday, July 09, 2007 5:46 PM
> > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor=20
> > Bryskin; [e-mail]
> > Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> > (hassans); Tomohiro Otani
> > Subject: RE: Follow-up on comments on=20
> > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> >=20
> > Zafar,
> >=20
> > Let's look at your situation with eyes of an ITU-T folk :=3D)
> >=20
> > Your client layer is IP, and your server layer (the one=20
> that provides
> > connectivity between IP routers) is Ethernet. This means that=20
> > a link in
> > IP layer is provided by a connection in Ethernet layer. The=20
> MAC header
> > you need to encapsulate your IP CI is a label of the Ethernet=20
> > connection
> > and should be learned via signaling before the connection is=20
> > used. Note
> > also that IP layer is not the only client of Ethernet, for example,
> > Ethernet-in-Ethernet is quite possible, so you can't rely=20
> on protocols
> > like ARP.=20
> >=20
> > Cheers,
> > Igor
> >=20
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of PAPADIMITRIOU Dimitri
> > Sent: Saturday, July 07, 2007 3:54 PM
> > To: Zafar Ali (zali); Lou Berger; Igor Bryskin; [e-mail]
> > Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> > (hassans);
> > Tomohiro Otani
> > Subject: RE: Follow-up on comments on
> > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> >=20
> > zafar
> >=20
> > it is the other way around, because you have different=20
> subnets you can
> > not make use of existing mechanisms
> >=20
> > "The solution we are pushing for is that we need a mechanism=20
> > that allows
> > us to resolve ARP directly for the GMPLS tunnel ip addresses. This
> > removes any dependency on the underlying Ethernet links or the
> > addressing scheme that is used for TE links i.e. numbered=20
> links in the
> > same or different subnets."
> >=20
> > hence the first question is why shall this be different ?
> >=20
> > -d.
> >=20
> > > -----Original Message-----
> > > From: [e-mail]=20
> > > [mailto:[e-mail]] On Behalf Of Zafar Ali (zali)
> > > Sent: Thursday, July 05, 2007 6:39 PM
> > > To: Lou Berger; Igor Bryskin; [e-mail]
> > > Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> > > (hassans); Tomohiro Otani
> > > Subject: Follow-up on comments on=20
> > > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> > >=20
> > > Hi Lou, Igor, ccamper, et al,=20
> > > =20
> > > Here is a follow-up on our AI from last WG meeting on the=20
> > > comments received on=20
> > > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt. We=20
> > > are planning to revise the document based on your feedback.=20
> > > Please advise if you have any further comment/ suggestion.=20
> > > =20
> > > The issue is focused around the use of the GMPLS tunnel as a=20
> > > point-to-point link using Ethernet TE links. Unlike pos links=20
> > > where a L2 adjacency resolution is not required, the Ethernet=20
> > > links require that the ARP be resolved (aka Layer 2 MAC=20
> > > address) before any forwarding works on this link. It is not=20
> > > a case of broken implementation. We (router vendors) cannot=20
> > > work around ARP. What we need to do is to provide clear=20
> > > direction or recommendation for vendors on how to ARP for=20
> > > GMPLS controlled Ethernet interfaces. Or else, all vendors=20
> > > will implement whatever ARP mechanism works for them in terms=20
> > > of forwarding. E.g., there is an interop issue between=20
> > > Juniper and Cisco (from a fwding perspective) when Ethernet=20
> > > links are used (Both do ARP). We had to find workarounds to=20
> > > make things work (at ISO Core and in private testing). The=20
> > > same will be the case between Cisco, Juniper and other vendors.=20
> > > =20
> > > The solution we are pushing for is that we need a mechanism=20
> > > that allows us to resolve ARP directly for the GMPLS tunnel=20
> > > ip addresses. This removes any dependency on the underlying=20
> > > Ethernet links or the addressing scheme that is used for TE=20
> > > links i.e. numbered links in the same or different subnets.
> > > =20
> > > In the following, we describe the situation with numbered=20
> > > Ethernet links and Unnumbered Ethernet links (the assumption=20
> > > is that the GMPLS tunnel is a ipv4 numbered link in both=20
> instances).
> > > =20
> > > Consider the scenario=20
> > > =20
> > > <----------------------------------------------GMPLS=20
> > > Tunnel------------------------------------------>
> > > =20
> > > RTR1 <------GE data link/TE link -----> OXC <------ GE data=20
> > > link/TE link -----> RTR2
> > >                   segment # 1                                =20
> > >   segment # 2
> > > There are two instance to consider:
> > > =20
> > > (a) When numbered TE links are used but segment # 1 and=20
> > > segment # 2 are in different subnets (valid scenario)
> > >      In this situation we really have no way of resolving ARP=20
> > > using the addresses of the underlying TE link Ethernet links=20
> > > w/o using static ARP entries. The issue is that the subnets=20
> > > are different so the ARP request received by RTR2 from RTR1=20
> > > will be rejected as it is not known to RTR2 and vice versa.=20
> > > Instead, if the ARP request if for the GMPLS tunnel instead=20
> > > then there should be no problem as the GMPLS tunnel is p-p=20
> > > link with IPV4 addresses in the same subnet.
> > > Verdict: If we have the ARP resolution mechanism tied in to=20
> > > the GMPLS tunnel interfaces addresses then there is no issue=20
> > > or dependency=20
> > > =20
> > > (a) When numbered TE links are used and segment # 1 and=20
> > > segment # 2 are in the same subnet.=20
> > >      In this setup the GMPLS Tunnel can inherit and use the=20
> > > ethernet link address for ARP resolution and there is no=20
> > > issue as both segments are in the same subnet. The problem in=20
> > > this situation is that we need to resolve the ARP for the=20
> > > ipv4 addresses for the GMPLS tunnel (considered as a p-p=20
> > > link) as opposed to inherit it from the underlying Ethernet=20
> > TE links.
> > > Verdict:  In this situation the ARP resolution mechanism=20
> > > should be developed for the GMPLS tunnel address.
> > > =20
> > > (c) The third scenario is when the GMPLS tunnel is numbered=20
> > > but the TE links are Unnumbered.
> > >      In this case we are again faced with the same issue of=20
> > > L2 ARP adjacency resolution between RTR1 and RTR2. RTR2 will=20
> > > reject the ARP request for RTR1 when it does not find the=20
> > > Unnumbered address (used by RTR1) in its FWDing database.=20
> > > This issue would not be encountered if we were resolving the=20
> > > ARP on GMPLS tunnel address.
> > > Verdict: ARP resolution mechanism is required for GMPLS tunnel.
> > > =20
> > > (d) We also need to make sure that when the tunnel-id is=20
> > > unnum, vendor implementation honor ARP request using loopback=20
> > > addresses. We have also faced interop issue in this scenario.=20
> > > =20
> > > Thanks
> > > =20
> > > Regards... Hassan and Zafar=20
> > >=20
> >=20
> >=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 16:32:24 +0000
Message-ID: <[e-mail]>
Date: Mon, 09 Jul 2007 09:31:30 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Wataru Imajuku <[e-mail]>
CC: "Diego Caviglia (GA/ERI)" <[e-mail]>, MEURIC Julien RD-CORE-LAN <[e-mail]>, [e-mail]
Subject: Re: Switching Capability of Photonic Links with Transponder
Content-Type: multipart/alternative; boundary="------------090908040705060501020202"

This is a multi-part message in MIME format.
--------------090908040705060501020202
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi all, concur with Wataru's comments. If you check out some of the
optical sub-system/component vendors you'll see ROADMs and switches that
are "colored" and "colorless". "Colored" meaning that a wavelength
ingress on one port gets mapped to a particular egress port. "Colorless"
meaning that we can map an ingress wavelength on one port to an egress
port irrespective of color.

Hence it seems we've got some problem area "modeling" work. Then we can
see about potential representations/solutions.

Regards

Greg B.

Wataru Imajuku wrote:
> Hi, Diego and Julien
>
>  "OEO transponder that can only perform frequency switching lambda1 ?lambda 2."
>
>  I think this device should be advertised as lambda switch capable, if the optical signals sent 
> from this transponder are directily connectied to WDM networks (such as ROADM ring or transparent OXCs).
>
>  But, it is not problem this interface is advertised as fiber switch capable,
>  if the optical signal send from the transponder is terminated by electrical reciever in next hop node.
>
>  Perhaps, if we properly incorporate this case into the GMPLS frame work, I think 
> we need the concept of "colored TE-link" and "colorless TE-link" even to GMPLS control plane.
>  In colorled TE-Link, the switching capability in both end take care the color of optical signal
> even even if number of optical signal in the colered TE-link is unity.
>
>  I think we need updated drafts describing photonic networks with consideration of recent progress of 
> optical transport technologies.
>
>
>   
>>          Hmmmmmm not sure my Understanding of the lambda switching is what I$BCW(Be called spatial switching that is lambda1 portA ?lambda1 portB what is not clear to me is how can be advertised an OEO transponder that can only perform frequency switching lambda1 ?lambda 2.
>>     
>
>  
>
> At 15:39 07/07/05, Diego Caviglia (GA/ERI) wrote:
>
>   
>> Hi Julien,
>>
>>          Hmmmmmm not sure my Understanding of the lambda switching is what I$BCW(Be called spatial switching that is lambda1 portA ?lambda1 portB what is not clear to me is how can be advertised an OEO transponder that can only perform frequency switching lambda1 ?lambda 2.
>>
>> Adrian? Deb? Anyone else?
>>
>> BR
>>
>> Diego
>>
>> -----Original Message-----
>> From: MEURIC Julien RD-CORE-LAN [<mailto:[e-mail]>mailto:[e-mail]]
>> Sent: mercoled?4 luglio 2007 18.47
>> To: Diego Caviglia (GA/ERI); [e-mail]
>> Subject: RE: Switching Capability of Photonic Links with Transponder
>>
>> Hi Diego.
>>
>> I believe we should refer to the Holly RFC 3945, chapter 1, verse 2:
>>
>> - "Lambda Switch Capable" interfaces "can operate at the level of an *individual wavelength*" [or a "group of wavelengths"], meaning that you manipulate values of wavelengths (as AU-4 numbers [or AU-4 ranges] from an SDH portA to SDH portB), like in a ROADM;
>>
>> - "Fiber-Switch Capable" interfaces "can operate at the level of a single or multiple *fibers*", meaning *spatial switching* where you don't consider the type of signal that ports convey (could be anything like a black and white signal, a wavelength, a WDM multiplex, some optical packets...), like in a OOO PXC.
>>
>> To stick with strict terminolgy: lambda = wavelength = (speedOfLight / frequency)
>>
>> So if you need to do "frequency switching", then it is the so called "lambda switching". :-)
>>
>> Anyway, this is my understanding, so if I'm wrong or if it's a vocabulary issue because you find that terms are inappropriate, then we'd better ask father Adrian and sister Deborah.
>>
>> Cheers,
>>
>> Julien
>>
>> -----Original Message-----
>>
>> From: Diego Caviglia (GA/ERI) [<mailto:[e-mail]>mailto:[e-mail]] 
>>
>> Hi Julien,
>>
>>          Actually not the PXC I had in mind is able to switch a single lambda I didn't but the mux/demux In the picture sorry.
>>
>> The point I failed to illustrate is the ambiguity of the term "Lambda Switch Capable" given that there two possible ways to switch a lambda.  
>>
>> The first one is the spatial one: (Lambda1 portA) --> (Lambda1 portB) this is the way an all optical switch works and this why there is the lambda continuity constraint in photonic networks.  
>>
>> The second one is the frequency switching: (Lambda1 portA) --> (Lambda2 portA) this switching can be done via a transponder (OEO) device.  
>>
>> Of course is possible to mix the two switching having (Lambda1 portA) --> (Lambda2 portB)
>>
>> My impression is that the definition "Lambda Switch Capable" refers to the spatial switching and thus I don't know how to model the fact that after/before a photonic matrix I have a transponder.  
>>
>> I hope I've made my question clearer.
>>
>> Best Regards
>>
>> Diego
>>
>> -----Original Message-----
>>
>> From: MEURIC Julien RD-CORE-LAN [<mailto:[e-mail]>mailto:[e-mail]] 
>>
>> Sent: marted?3 luglio 2007 19.21
>>
>> To: Diego Caviglia (GA/ERI); [e-mail]
>>
>> Subject: RE: Switching Capability of Photonic Links with Transponder
>>
>> Hi Diego.
>>
>> If I understand correctly, your "lambda switch" by itself is a PXC that
>>
>> has only "Fiber-Switch Capable" interfaces. Then, you add
>>
>> lambda-conversion cards to it. So, correct me if I'm wrong (you or
>>
>> anyone else), but whether you do a lambda conversion inside a card or in
>>
>> a core matrix, this new interface on your global device is able to work
>>
>> on lambdas anyway  [(lambda 1, port A) --> (lambda2, port B)]. As a
>>
>> result, you need to advertise your most flexible capability, which is
>>
>> "Lambda Switch Capable".
>>
>> If you used "FSC", you wouldn't be able to control your "lambda
>>
>> swapping" card, as LSPs are like lists of fibers and labels aren't
>>
>> wavelengths but ports.
>>
>> But maybe I didn't get your actual issue.
>>
>> My 2 cents,
>>
>> Julien
>>
>> ________________________________
>>
>> From: [e-mail] [<mailto:[e-mail]>mailto:[e-mail]] On
>>
>> Behalf Of Diego Caviglia (GA/ERI)
>>
>> Hi all,
>>
>>         I've a doubt about how to model the following situation.
>>
>>
>>
>>
>>
>>
>>
>>      +-----------------+
>>
>>      |                 |-------+
>>
>>      |                 | OEO   |
>>
>>      |     Lambda      |-------+
>>
>>      |     Switch      |
>>
>>      |                 |
>>
>>      |                 |
>>
>>      +-----------------+
>>
>>      
>>
>>
>>
>> The node itself is able to cross connect only the Lambda while the
>>
>> interface has a OEO transponder that is able to change the lambda
>>
>> frequency.  In this case there are two different 'switching capability'
>>
>> the spatial one that is performed by the switch (lambda 1, port A) -->
>>
>> (lambda1, port B) and the frequency switching is done by the OEO
>>
>> transponder.  Witch kind of interface switching capability I have to
>>
>> advertise?
>>
>>
>>
>> BR
>>
>> Diego
>>
>>
>>
>> Diego Caviglia
>>
>> Product Line ON BBN
>>
>> PA Broadband BNET
>>
>>
>>
>> Marconi S.p.A
>>
>> Ericsson Global Product Center - Italy
>>
>> Via Anagnina,203
>>
>> 0018, Roma , Italy
>>
>> www.ericsson.com <<http://www.ericsson.com/>http://www.ericsson.com/> 
>>
>>
>>
>> Office:  [phone]
>>
>> Fax: [phone]
>>
>> Mobile: [phone]
>>
>> Email: [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.
>>
>> E-mail including attachments is susceptible to data corruption,
>>
>> interception, unauthorized amendment, tampering and viruses, and we only
>>
>> send and receive emails on the basis that we are not liable for any such
>>
>> corruption, interception, amendment, tampering or viruses or any
>>
>> consequences thereof.
>>
>>
>>     
>
> -------------------------------------
> Wataru Imajuku@NTT Network Innovation Labs
> TEL: [phone]
> FAX: [phone]
>
>
>
>
>   

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



--------------090908040705060501020202
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-2022-JP"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi all, concur with Wataru's comments.&nbsp; If you check out some of the
optical sub-system/component vendors you'll see ROADMs and switches
that are "colored" and "colorless".&nbsp; "Colored" meaning that a
wavelength ingress on one port gets mapped to a particular egress
port.&nbsp; "Colorless" meaning that we can map an ingress wavelength on one
port to an egress port irrespective of color. <br>
<br>
Hence it seems we've got some problem area "modeling" work. Then we can
see about potential representations/solutions.<br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
Wataru Imajuku wrote:
<blockquote
 cite="mid:[e-mail]"
 type="cite">
  <pre wrap="">Hi, Diego and Julien

 "OEO transponder that can only perform frequency switching lambda1 &#65533;lambda 2."

 I think this device should be advertised as lambda switch capable, if the optical signals sent 
from this transponder are directily connectied to WDM networks (such as ROADM ring or transparent OXCs).

 But, it is not problem this interface is advertised as fiber switch capable,
 if the optical signal send from the transponder is terminated by electrical reciever in next hop node.

 Perhaps, if we properly incorporate this case into the GMPLS frame work, I think 
we need the concept of "colored TE-link" and "colorless TE-link" even to GMPLS control plane.
 In colorled TE-Link, the switching capability in both end take care the color of optical signal
even even if number of optical signal in the colered TE-link is unity.

 I think we need updated drafts describing photonic networks with consideration of recent progress of 
optical transport technologies.


  </pre>
  <blockquote type="cite">
    <pre wrap="">         Hmmmmmm not sure my Understanding of the lambda switching is what I$BCW(Be called spatial switching that is lambda1 portA &#65533;lambda1 portB what is not clear to me is how can be advertised an OEO transponder that can only perform frequency switching lambda1 &#65533;lambda 2.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
 

At 15:39 07/07/05, Diego Caviglia (GA/ERI) wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi Julien,

         Hmmmmmm not sure my Understanding of the lambda switching is what I$BCW(Be called spatial switching that is lambda1 portA &#65533;lambda1 portB what is not clear to me is how can be advertised an OEO transponder that can only perform frequency switching lambda1 &#65533;lambda 2.

Adrian? Deb? Anyone else?

BR

Diego

-----Original Message-----
From: MEURIC Julien RD-CORE-LAN [<a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;mailto:[e-mail]&gt;</a><a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
Sent: mercoled&#65533;4 luglio 2007 18.47
To: Diego Caviglia (GA/ERI); <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Subject: RE: Switching Capability of Photonic Links with Transponder

Hi Diego.

I believe we should refer to the Holly RFC 3945, chapter 1, verse 2:

- "Lambda Switch Capable" interfaces "can operate at the level of an *individual wavelength*" [or a "group of wavelengths"], meaning that you manipulate values of wavelengths (as AU-4 numbers [or AU-4 ranges] from an SDH portA to SDH portB), like in a ROADM;

- "Fiber-Switch Capable" interfaces "can operate at the level of a single or multiple *fibers*", meaning *spatial switching* where you don't consider the type of signal that ports convey (could be anything like a black and white signal, a wavelength, a WDM multiplex, some optical packets...), like in a OOO PXC.

To stick with strict terminolgy: lambda = wavelength = (speedOfLight / frequency)

So if you need to do "frequency switching", then it is the so called "lambda switching". :-)

Anyway, this is my understanding, so if I'm wrong or if it's a vocabulary issue because you find that terms are inappropriate, then we'd better ask father Adrian and sister Deborah.

Cheers,

Julien

-----Original Message-----

From: Diego Caviglia (GA/ERI) [<a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;mailto:[e-mail]&gt;</a><a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>] 

Hi Julien,

         Actually not the PXC I had in mind is able to switch a single lambda I didn't but the mux/demux In the picture sorry.

The point I failed to illustrate is the ambiguity of the term "Lambda Switch Capable" given that there two possible ways to switch a lambda.  

The first one is the spatial one: (Lambda1 portA) --&gt; (Lambda1 portB) this is the way an all optical switch works and this why there is the lambda continuity constraint in photonic networks.  

The second one is the frequency switching: (Lambda1 portA) --&gt; (Lambda2 portA) this switching can be done via a transponder (OEO) device.  

Of course is possible to mix the two switching having (Lambda1 portA) --&gt; (Lambda2 portB)

My impression is that the definition "Lambda Switch Capable" refers to the spatial switching and thus I don't know how to model the fact that after/before a photonic matrix I have a transponder.  

I hope I've made my question clearer.

Best Regards

Diego

-----Original Message-----

From: MEURIC Julien RD-CORE-LAN [<a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;mailto:[e-mail]&gt;</a><a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>] 

Sent: marted&#65533;3 luglio 2007 19.21

To: Diego Caviglia (GA/ERI); <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>

Subject: RE: Switching Capability of Photonic Links with Transponder

Hi Diego.

If I understand correctly, your "lambda switch" by itself is a PXC that

has only "Fiber-Switch Capable" interfaces. Then, you add

lambda-conversion cards to it. So, correct me if I'm wrong (you or

anyone else), but whether you do a lambda conversion inside a card or in

a core matrix, this new interface on your global device is able to work

on lambdas anyway  [(lambda 1, port A) --&gt; (lambda2, port B)]. As a

result, you need to advertise your most flexible capability, which is

"Lambda Switch Capable".

If you used "FSC", you wouldn't be able to control your "lambda

swapping" card, as LSPs are like lists of fibers and labels aren't

wavelengths but ports.

But maybe I didn't get your actual issue.

My 2 cents,

Julien

________________________________

From: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> [<a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;mailto:[e-mail]&gt;</a><a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>] On

Behalf Of Diego Caviglia (GA/ERI)

Hi all,

        I've a doubt about how to model the following situation.







     +-----------------+

     |                 |-------+

     |                 | OEO   |

     |     Lambda      |-------+

     |     Switch      |

     |                 |

     |                 |

     +-----------------+

     



The node itself is able to cross connect only the Lambda while the

interface has a OEO transponder that is able to change the lambda

frequency.  In this case there are two different 'switching capability'

the spatial one that is performed by the switch (lambda 1, port A) --&gt;

(lambda1, port B) and the frequency switching is done by the OEO

transponder.  Witch kind of interface switching capability I have to

advertise?



BR

Diego



Diego Caviglia

Product Line ON BBN

PA Broadband BNET



Marconi S.p.A

Ericsson Global Product Center - Italy

Via Anagnina,203

0018, Roma , Italy

<a class="moz-txt-link-abbreviated" href="http://www.ericsson.com">www.ericsson.com</a> &lt;<a class="moz-txt-link-rfc2396E" href="http://www.ericsson.com/">&lt;http://www.ericsson.com/&gt;</a><a class="moz-txt-link-freetext" href="http://www.ericsson.com/">http://www.ericsson.com/</a>&gt; 



Office:  [phone]

Fax: [phone]

Mobile: [phone]

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

E-mail including attachments is susceptible to data corruption,

interception, unauthorized amendment, tampering and viruses, and we only

send and receive emails on the basis that we are not liable for any such

corruption, interception, amendment, tampering or viruses or any

consequences thereof.


    </pre>
  </blockquote>
  <pre wrap=""><!---->
-------------------------------------
Wataru Imajuku@NTT Network Innovation Labs
TEL: [phone]
FAX: [phone]




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

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

--------------090908040705060501020202--



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 16:19:48 +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: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Date: Mon, 9 Jul 2007 18:17:42 +0200
Message-ID: <[e-mail]>
Thread-Topic: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Thread-Index: Ace/Iv/wATkVETcSTT+CAQmeajDxfgBrSD/wAFqvezAAAaANEA==
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, "Zafar Ali \(zali\)" <[e-mail]>, "Lou Berger" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Hassan Sheikh \(hassans\)" <[e-mail]>, "Tomohiro Otani" <[e-mail]>

=20



sorry but we don't discuss about any over Ethernet here=20
but between two IP/MPLS LSR =20

hence, what is different here from two LSRs interconnected=20
by an Ethernet link over X ?

zafar can you clarify this point ? because from what i=20
read in your draft it is because the address to be resolved
creates an issue but why should that be different from=20
what you see today between two Ethernet hosts connected
back-to-back ?

-d.
=20

> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]=20
> Sent: Monday, July 09, 2007 5:46 PM
> To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor=20
> Bryskin; [e-mail]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> (hassans); Tomohiro Otani
> Subject: RE: Follow-up on comments on=20
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
>=20
> Zafar,
>=20
> Let's look at your situation with eyes of an ITU-T folk :=3D)
>=20
> Your client layer is IP, and your server layer (the one that provides
> connectivity between IP routers) is Ethernet. This means that=20
> a link in
> IP layer is provided by a connection in Ethernet layer. The MAC header
> you need to encapsulate your IP CI is a label of the Ethernet=20
> connection
> and should be learned via signaling before the connection is=20
> used. Note
> also that IP layer is not the only client of Ethernet, for example,
> Ethernet-in-Ethernet is quite possible, so you can't rely on protocols
> like ARP.=20
>=20
> Cheers,
> Igor
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of PAPADIMITRIOU Dimitri
> Sent: Saturday, July 07, 2007 3:54 PM
> To: Zafar Ali (zali); Lou Berger; Igor Bryskin; [e-mail]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> (hassans);
> Tomohiro Otani
> Subject: RE: Follow-up on comments on
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
>=20
> zafar
>=20
> it is the other way around, because you have different subnets you can
> not make use of existing mechanisms
>=20
> "The solution we are pushing for is that we need a mechanism=20
> that allows
> us to resolve ARP directly for the GMPLS tunnel ip addresses. This
> removes any dependency on the underlying Ethernet links or the
> addressing scheme that is used for TE links i.e. numbered links in the
> same or different subnets."
>=20
> hence the first question is why shall this be different ?
>=20
> -d.
>=20
> > -----Original Message-----
> > From: [e-mail]=20
> > [mailto:[e-mail]] On Behalf Of Zafar Ali (zali)
> > Sent: Thursday, July 05, 2007 6:39 PM
> > To: Lou Berger; Igor Bryskin; [e-mail]
> > Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> > (hassans); Tomohiro Otani
> > Subject: Follow-up on comments on=20
> > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> >=20
> > Hi Lou, Igor, ccamper, et al,=20
> > =20
> > Here is a follow-up on our AI from last WG meeting on the=20
> > comments received on=20
> > draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt. We=20
> > are planning to revise the document based on your feedback.=20
> > Please advise if you have any further comment/ suggestion.=20
> > =20
> > The issue is focused around the use of the GMPLS tunnel as a=20
> > point-to-point link using Ethernet TE links. Unlike pos links=20
> > where a L2 adjacency resolution is not required, the Ethernet=20
> > links require that the ARP be resolved (aka Layer 2 MAC=20
> > address) before any forwarding works on this link. It is not=20
> > a case of broken implementation. We (router vendors) cannot=20
> > work around ARP. What we need to do is to provide clear=20
> > direction or recommendation for vendors on how to ARP for=20
> > GMPLS controlled Ethernet interfaces. Or else, all vendors=20
> > will implement whatever ARP mechanism works for them in terms=20
> > of forwarding. E.g., there is an interop issue between=20
> > Juniper and Cisco (from a fwding perspective) when Ethernet=20
> > links are used (Both do ARP). We had to find workarounds to=20
> > make things work (at ISO Core and in private testing). The=20
> > same will be the case between Cisco, Juniper and other vendors.=20
> > =20
> > The solution we are pushing for is that we need a mechanism=20
> > that allows us to resolve ARP directly for the GMPLS tunnel=20
> > ip addresses. This removes any dependency on the underlying=20
> > Ethernet links or the addressing scheme that is used for TE=20
> > links i.e. numbered links in the same or different subnets.
> > =20
> > In the following, we describe the situation with numbered=20
> > Ethernet links and Unnumbered Ethernet links (the assumption=20
> > is that the GMPLS tunnel is a ipv4 numbered link in both instances).
> > =20
> > Consider the scenario=20
> > =20
> > <----------------------------------------------GMPLS=20
> > Tunnel------------------------------------------>
> > =20
> > RTR1 <------GE data link/TE link -----> OXC <------ GE data=20
> > link/TE link -----> RTR2
> >                   segment # 1                                =20
> >   segment # 2
> > There are two instance to consider:
> > =20
> > (a) When numbered TE links are used but segment # 1 and=20
> > segment # 2 are in different subnets (valid scenario)
> >      In this situation we really have no way of resolving ARP=20
> > using the addresses of the underlying TE link Ethernet links=20
> > w/o using static ARP entries. The issue is that the subnets=20
> > are different so the ARP request received by RTR2 from RTR1=20
> > will be rejected as it is not known to RTR2 and vice versa.=20
> > Instead, if the ARP request if for the GMPLS tunnel instead=20
> > then there should be no problem as the GMPLS tunnel is p-p=20
> > link with IPV4 addresses in the same subnet.
> > Verdict: If we have the ARP resolution mechanism tied in to=20
> > the GMPLS tunnel interfaces addresses then there is no issue=20
> > or dependency=20
> > =20
> > (a) When numbered TE links are used and segment # 1 and=20
> > segment # 2 are in the same subnet.=20
> >      In this setup the GMPLS Tunnel can inherit and use the=20
> > ethernet link address for ARP resolution and there is no=20
> > issue as both segments are in the same subnet. The problem in=20
> > this situation is that we need to resolve the ARP for the=20
> > ipv4 addresses for the GMPLS tunnel (considered as a p-p=20
> > link) as opposed to inherit it from the underlying Ethernet=20
> TE links.
> > Verdict:  In this situation the ARP resolution mechanism=20
> > should be developed for the GMPLS tunnel address.
> > =20
> > (c) The third scenario is when the GMPLS tunnel is numbered=20
> > but the TE links are Unnumbered.
> >      In this case we are again faced with the same issue of=20
> > L2 ARP adjacency resolution between RTR1 and RTR2. RTR2 will=20
> > reject the ARP request for RTR1 when it does not find the=20
> > Unnumbered address (used by RTR1) in its FWDing database.=20
> > This issue would not be encountered if we were resolving the=20
> > ARP on GMPLS tunnel address.
> > Verdict: ARP resolution mechanism is required for GMPLS tunnel.
> > =20
> > (d) We also need to make sure that when the tunnel-id is=20
> > unnum, vendor implementation honor ARP request using loopback=20
> > addresses. We have also faced interop issue in this scenario.=20
> > =20
> > Thanks
> > =20
> > Regards... Hassan and Zafar=20
> >=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 14:34:07 +0000
Message-ID: <[e-mail]>
Date: Mon, 09 Jul 2007 10:30:58 -0400
From: Meral Shirazipour <[e-mail]>
To: Tomonori TAKEDA <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: Fwd: I-D   ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.3

Dear Tomonori,
   Thank you for the explanation:
----------
>[Page 12]
>first paragraph:"This scheme cannot guarantee to establish diverse LSPs (even
>if they could exist) because the first LSP is established without
>consideration of the need for a diverse recovery LSP. Crankback [crankback]
>may be used in combination with this scheme in order to improve the
>possibility of successful diverse LSP setup."
>How can crankback on the protection LSP help if the problem is the already
>established working LSP ?!

There are several causes why the recovery LSP can not be computed. In one
case, the recovery LSP can not be computed because the working LSP is
blocking (there is no way). In another case, the recovery LSP can not be
computed because the bad border node is selected, but crankback can fix
this. We are not saying that the first case can be fixed by crankback.
----------



 Just to make sure that I understood well, crankback is used when the entity
that determined the diverse recovery LSP had only access to an out of date
information that did not include the recently deployed working LSP ?

Thanks again for taking the time...

Warm Regards,
Meral









Selon Tomonori TAKEDA <[e-mail]>:

> Hi Meral,
>
> Thanks for you comments. I copied CCAMP list here for sharing information.
>
> Please see in-line.
>
> At 13:07 07/07/09, Meral Shirazipour wrote:
>  >Dear Tomonori,
>  >   I just finished reading the draft. Below I have a few
> comments/suggestions,
>  >mainly regarding typos and clarity.
>  >
>  >Warm Regards,
>  >Meral
>  >
>  >[Page 2/16]
>  >5.4 Inter-domain Collaborate Path Computation....................16
>  >
>  >Maybe Collaborative would be better?!
>
> Thanks.
>
>  >[Page 4]
>  >section 1.2 Domain
>  >"In such a scenarios,..."
>  >
>  >Should be "In such scenarios" or "In such a scenario"
>
> Thanks.
>
>  >section 1.3 Document Scope , third paragraph
>  >"which can advantageously used"
>  >Should be "which can advantageously be used"
>
> Thanks.
>
>  >[Page 6/7]
>  >"Figure 2: Mesh Connectivity"  should be on page 6
>
> OK.
>
>  >[Page 9]
>  >"An example of such a scheme is Backward Recursive Pause Computation (BRPC)
>  >[brpc]"
>  >
>  >"Pause" should be replaced by "Path"
>
> Thanks.
>
>  >[Page 20]
>  >[brpc]:
>  >A Backward Recursive PCE-based Computation (BRPC) procedure to compute
>  >shortest inter-domain Traffic Engineering Label Switched Paths
>  >
>  >Path with S
>
> Thanks.
>
>  >[Page 12]
>  >first paragraph:"This scheme cannot guarantee to establish diverse LSPs
> (even if
>  >they could exist) because the first LSP is established without
> consideration of
>  >the need for a diverse recovery LSP. Crankback [crankback] may be used in
>  >combination with this scheme in order to improve the possibility of
> successful
>  >diverse LSP setup."
>  >
>  >How can crankback on the protection LSP help if the problem is the already
>  >established working LSP ?!
>
> There are several causes why the recovery LSP can not be computed. In one
> case, the recovery LSP can not be computed because the working LSP is
> blocking (there is no way). In another case, the recovery LSP can not be
> computed because the bad border node is selected, but crankback can fix
> this. We are not saying that the first case can be fixed by crankback.
>
> Thanks,
> Tomonori
>
>  >
>  >
>  >
>  >
>  >
>  >
>  >Selon Tomonori TAKEDA <[e-mail]>:
>  >
>  >> Hi,
>  >>
>  >> A new version of inter-domain recovery analysis I-D have been published.
>  >>
>  >> Here are major changes:
>  >> - Added text on security considerations section
>  >> - Cleaned up text marked "for further study" (various places)
>  >> - Added a reference to [PCEP-XRO]
>  >> - Enhanced text on computing diverse paths sequentially with
> confidentiality
>  >>    (Section 5.4.1)
>  >> - Moved "terminology" section into "introduction" section
>  >> - Removed manageability considerations section
>  >> - Polished text
>  >>
>  >> Authors believe the document is now completed and ready for WG last call.
>  >>
>  >> Thanks,
>  >> Tomonori
>  >>
>  >>  >To: [e-mail]
>  >>  >From: [e-mail]
>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >>  >X-Spam-Score: 0.0 (/)
>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >>  >Cc: [e-mail]
>  >>  >Subject: I-D
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >X-BeenThere: [e-mail]
>  >>  >X-Mailman-Version: 2.1.5
>  >>  >Reply-To: [e-mail]
>  >>  >List-Id: i-d-announce.ietf.org
>  >>  >List-Unsubscribe:
>  >>
> 
>><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?subject=unsubscribe>
>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>  >>  >List-Post: <mailto:[e-mail]>
>  >>  >List-Help: <mailto:[e-mail]?subject=help>
>  >>  >List-Subscribe:
>  >>
> 
>><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?subject=subscribe>
>  >>  >X-Junkmail: UCE(35)
>  >>  >X-Junkmail-Status: score=35/10, host=sfs2.omr.ecl.ntt.co.jp
>  >>  >X-Junkmail-SD-Raw:
>  >>
> 
>>score=suspect(0),refid=str=0001.0A090207.468E8745.0129,ss=2,fgs=0,ip=156.154.16.145,so=2007-03-13
>  >>
>  >>  >10:31:19,dmn=5.3.14/2007-05-31
>  >>  >
>  >>  >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		: Analysis of Inter-domain Label Switched Path (LSP) Recovery
>  >>  >	Author(s)	: T. Takeda, et al.
>  >>  >	Filename	: draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >	Pages		: 23
>  >>  >	Date		: 2007-7-6
>  >>  >
>  >>  >This document analyzes various schemes to realize Multiprotocol Label
>  >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
>  >>  >   (LSP) recovery in multi-domain networks based on the existing
>  >>  >   framework for multi-domain LSPs.
>  >>  >
>  >>  >   The main focus for this document is on establishing end-to-end
>  >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain networks. It
>  >>  >   presents various diverse LSP setup schemes based on existing
>  >>  >   functional elements.
>  >>  >
>  >>  >A URL for this Internet-Draft is:
>  >>
> 
>>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >
>  >>  >To remove yourself from the I-D Announcement list, send a message to
>  >>  >[e-mail] with the word unsubscribe in the body of
>  >>  >the message.
>  >>  >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>  >>  >to change your subscription settings.
>  >>  >
>  >>  >Internet-Drafts are also available by anonymous FTP. Login with the
>  >>  >username "anonymous" and a password of your e-mail address. After
>  >>  >logging in, type "cd internet-drafts" and then
>  >>  >"get draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
>  >>  >
>  >>  >A list of Internet-Drafts directories can be found in
>  >>  >http://www.ietf.org/shadow.html
>  >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  >>  >
>  >>  >Internet-Drafts can also be obtained by e-mail.
>  >>  >
>  >>  >Send a message to:
>  >>  >	[e-mail].
>  >>  >In the body type:
>  >>  >	"FILE
>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
>  >>  >
>  >>  >NOTE:	The mail server at ietf.org can return the document in
>  >>  >	MIME-encoded form by using the "mpack" utility.  To use this
>  >>  >	feature, insert the command "ENCODING mime" before the "FILE"
>  >>  >	command.  To decode the response(s), you will need "munpack" or
>  >>  >	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>  >>  >	exhibit different behavior, especially when dealing with
>  >>  >	"multipart" MIME messages (i.e. documents which have been split
>  >>  >	up into multiple messages), so check your local documentation on
>  >>  >	how to manipulate these messages.
>  >>  >
>  >>  >Below is the data which will enable a MIME compliant mail reader
>  >>  >implementation to automatically retrieve the ASCII version of the
>  >>  >Internet-Draft.
>  >>  >
>  >>  >Content-Type: text/plain
>  >>  >Content-ID: <[e-mail]>
>  >>  >
>  >>  >ENCODING mime
>  >>  >FILE
>  >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >
>  >>  >
>  >>
> 
>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt>
>  >>  >_______________________________________________
>  >>  >I-D-Announce mailing list
>  >>  >[e-mail]
>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
>  >>
>  >>
>  >>
>  >>
>
>
>
>






Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 11:23:23 +0000
Message-Id: <[e-mail]>
Date: Mon, 09 Jul 2007 20:21:58 +0900
To: "Diego Caviglia (GA/ERI)" <[e-mail]>, "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: RE: Switching Capability of Photonic Links with Transponder
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

Hi, Diego and Julien

 "OEO transponder that can only perform frequency switching lambda1 $B_
(Blambda 2."

 I think this device should be advertised as lambda switch capable, if the optical signals sent 
from this transponder are directily connectied to WDM networks (such as ROADM ring or transparent OXCs).

 But, it is not problem this interface is advertised as fiber switch capable,
 if the optical signal send from the transponder is terminated by electrical reciever in next hop node.

 Perhaps, if we properly incorporate this case into the GMPLS frame work, I think 
we need the concept of "colored TE-link" and "colorless TE-link" even to GMPLS control plane.
 In colorled TE-Link, the switching capability in both end take care the color of optical signal
even even if number of optical signal in the colered TE-link is unity.

 I think we need updated drafts describing photonic networks with consideration of recent progress of 
optical transport technologies.


>          Hmmmmmm not sure my Understanding of the lambda switching is what I$BCW(Be called spatial switching that is lambda1 portA $B_
(Blambda1 portB what is not clear to me is how can be advertised an OEO transponder that can only perform frequency switching lambda1 $B_
(Blambda 2.

 

At 15:39 07/07/05, Diego Caviglia (GA/ERI) wrote:

>Hi Julien,
>
>          Hmmmmmm not sure my Understanding of the lambda switching is what I$BCW(Be called spatial switching that is lambda1 portA $B_
(Blambda1 portB what is not clear to me is how can be advertised an OEO transponder that can only perform frequency switching lambda1 $B_
(Blambda 2.
>
>Adrian? Deb? Anyone else?
>
>BR
>
>Diego
>
>-----Original Message-----
>From: MEURIC Julien RD-CORE-LAN [<mailto:[e-mail]>mailto:[e-mail]]
>Sent: mercoled$Bw
(B4 luglio 2007 18.47
>To: Diego Caviglia (GA/ERI); [e-mail]
>Subject: RE: Switching Capability of Photonic Links with Transponder
>
>Hi Diego.
>
>I believe we should refer to the Holly RFC 3945, chapter 1, verse 2:
>
>- "Lambda Switch Capable" interfaces "can operate at the level of an *individual wavelength*" [or a "group of wavelengths"], meaning that you manipulate values of wavelengths (as AU-4 numbers [or AU-4 ranges] from an SDH portA to SDH portB), like in a ROADM;
>
>- "Fiber-Switch Capable" interfaces "can operate at the level of a single or multiple *fibers*", meaning *spatial switching* where you don't consider the type of signal that ports convey (could be anything like a black and white signal, a wavelength, a WDM multiplex, some optical packets...), like in a OOO PXC.
>
>To stick with strict terminolgy: lambda = wavelength = (speedOfLight / frequency)
>
>So if you need to do "frequency switching", then it is the so called "lambda switching". :-)
>
>Anyway, this is my understanding, so if I'm wrong or if it's a vocabulary issue because you find that terms are inappropriate, then we'd better ask father Adrian and sister Deborah.
>
>Cheers,
>
>Julien
>
>-----Original Message-----
>
>From: Diego Caviglia (GA/ERI) [<mailto:[e-mail]>mailto:[e-mail]] 
>
>Hi Julien,
>
>          Actually not the PXC I had in mind is able to switch a single lambda I didn't but the mux/demux In the picture sorry.
>
>The point I failed to illustrate is the ambiguity of the term "Lambda Switch Capable" given that there two possible ways to switch a lambda.  
>
>The first one is the spatial one: (Lambda1 portA) --> (Lambda1 portB) this is the way an all optical switch works and this why there is the lambda continuity constraint in photonic networks.  
>
>The second one is the frequency switching: (Lambda1 portA) --> (Lambda2 portA) this switching can be done via a transponder (OEO) device.  
>
>Of course is possible to mix the two switching having (Lambda1 portA) --> (Lambda2 portB)
>
>My impression is that the definition "Lambda Switch Capable" refers to the spatial switching and thus I don't know how to model the fact that after/before a photonic matrix I have a transponder.  
>
>I hope I've made my question clearer.
>
>Best Regards
>
>Diego
>
>-----Original Message-----
>
>From: MEURIC Julien RD-CORE-LAN [<mailto:[e-mail]>mailto:[e-mail]] 
>
>Sent: marted$Bw
(B3 luglio 2007 19.21
>
>To: Diego Caviglia (GA/ERI); [e-mail]
>
>Subject: RE: Switching Capability of Photonic Links with Transponder
>
>Hi Diego.
>
>If I understand correctly, your "lambda switch" by itself is a PXC that
>
>has only "Fiber-Switch Capable" interfaces. Then, you add
>
>lambda-conversion cards to it. So, correct me if I'm wrong (you or
>
>anyone else), but whether you do a lambda conversion inside a card or in
>
>a core matrix, this new interface on your global device is able to work
>
>on lambdas anyway  [(lambda 1, port A) --> (lambda2, port B)]. As a
>
>result, you need to advertise your most flexible capability, which is
>
>"Lambda Switch Capable".
>
>If you used "FSC", you wouldn't be able to control your "lambda
>
>swapping" card, as LSPs are like lists of fibers and labels aren't
>
>wavelengths but ports.
>
>But maybe I didn't get your actual issue.
>
>My 2 cents,
>
>Julien
>
>________________________________
>
>From: [e-mail] [<mailto:[e-mail]>mailto:[e-mail]] On
>
>Behalf Of Diego Caviglia (GA/ERI)
>
>Hi all,
>
>         I've a doubt about how to model the following situation.
>
> 
>
> 
>
> 
>
>      +-----------------+
>
>      |                 |-------+
>
>      |                 | OEO   |
>
>      |     Lambda      |-------+
>
>      |     Switch      |
>
>      |                 |
>
>      |                 |
>
>      +-----------------+
>
>      
>
> 
>
>The node itself is able to cross connect only the Lambda while the
>
>interface has a OEO transponder that is able to change the lambda
>
>frequency.  In this case there are two different 'switching capability'
>
>the spatial one that is performed by the switch (lambda 1, port A) -->
>
>(lambda1, port B) and the frequency switching is done by the OEO
>
>transponder.  Witch kind of interface switching capability I have to
>
>advertise?
>
> 
>
>BR
>
>Diego
>
> 
>
>Diego Caviglia
>
>Product Line ON BBN
>
>PA Broadband BNET
>
> 
>
>Marconi S.p.A
>
>Ericsson Global Product Center - Italy
>
>Via Anagnina,203
>
>0018, Roma , Italy
>
>www.ericsson.com <<http://www.ericsson.com/>http://www.ericsson.com/> 
>
> 
>
>Office:  [phone]
>
>Fax: [phone]
>
>Mobile: [phone]
>
>Email: [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.
>
>E-mail including attachments is susceptible to data corruption,
>
>interception, unauthorized amendment, tampering and viruses, and we only
>
>send and receive emails on the basis that we are not liable for any such
>
>corruption, interception, amendment, tampering or viruses or any
>
>consequences thereof.
>
> 

-------------------------------------
Wataru Imajuku@NTT Network Innovation Labs
TEL: [phone]
FAX: [phone]





Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 07:37:48 +0000
Message-Id: <[e-mail]>
Date: Mon, 09 Jul 2007 16:35:04 +0900
To: Meral Shirazipour <[e-mail]>
From: Tomonori TAKEDA <[e-mail]>
Subject: Re: Fwd: I-D  ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Meral,

Thanks for you comments. I copied CCAMP list here for sharing information.

Please see in-line.

At 13:07 07/07/09, Meral Shirazipour wrote:
 >Dear Tomonori,
 >   I just finished reading the draft. Below I have a few comments/suggestions,
 >mainly regarding typos and clarity.
 >
 >Warm Regards,
 >Meral
 >
 >[Page 2/16]
 >5.4 Inter-domain Collaborate Path Computation....................16
 >
 >Maybe Collaborative would be better?!

Thanks.

 >[Page 4]
 >section 1.2 Domain
 >"In such a scenarios,..."
 >
 >Should be "In such scenarios" or "In such a scenario"

Thanks.

 >section 1.3 Document Scope , third paragraph
 >"which can advantageously used"
 >Should be "which can advantageously be used"

Thanks.

 >[Page 6/7]
 >"Figure 2: Mesh Connectivity"  should be on page 6

OK.

 >[Page 9]
 >"An example of such a scheme is Backward Recursive Pause Computation (BRPC)
 >[brpc]"
 >
 >"Pause" should be replaced by "Path"

Thanks.

 >[Page 20]
 >[brpc]:
 >A Backward Recursive PCE-based Computation (BRPC) procedure to compute
 >shortest inter-domain Traffic Engineering Label Switched Paths
 >
 >Path with S

Thanks.

 >[Page 12]
 >first paragraph:"This scheme cannot guarantee to establish diverse LSPs (even if
 >they could exist) because the first LSP is established without consideration of
 >the need for a diverse recovery LSP. Crankback [crankback] may be used in
 >combination with this scheme in order to improve the possibility of successful
 >diverse LSP setup."
 >
 >How can crankback on the protection LSP help if the problem is the already
 >established working LSP ?!

There are several causes why the recovery LSP can not be computed. In one 
case, the recovery LSP can not be computed because the working LSP is 
blocking (there is no way). In another case, the recovery LSP can not be 
computed because the bad border node is selected, but crankback can fix 
this. We are not saying that the first case can be fixed by crankback.

Thanks,
Tomonori

 >
 >
 >
 >
 >
 >
 >Selon Tomonori TAKEDA <[e-mail]>:
 >
 >> Hi,
 >>
 >> A new version of inter-domain recovery analysis I-D have been published.
 >>
 >> Here are major changes:
 >> - Added text on security considerations section
 >> - Cleaned up text marked "for further study" (various places)
 >> - Added a reference to [PCEP-XRO]
 >> - Enhanced text on computing diverse paths sequentially with confidentiality
 >>    (Section 5.4.1)
 >> - Moved "terminology" section into "introduction" section
 >> - Removed manageability considerations section
 >> - Polished text
 >>
 >> Authors believe the document is now completed and ready for WG last call.
 >>
 >> Thanks,
 >> Tomonori
 >>
 >>  >To: [e-mail]
 >>  >From: [e-mail]
 >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >X-Spam-Score: 0.0 (/)
 >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >Cc: [e-mail]
 >>  >Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >X-BeenThere: [e-mail]
 >>  >X-Mailman-Version: 2.1.5
 >>  >Reply-To: [e-mail]
 >>  >List-Id: i-d-announce.ietf.org
 >>  >List-Unsubscribe:
 >>
 >><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?subject=unsubscribe>
 >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >List-Post: <mailto:[e-mail]>
 >>  >List-Help: <mailto:[e-mail]?subject=help>
 >>  >List-Subscribe:
 >>
 >><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?subject=subscribe>
 >>  >X-Junkmail: UCE(35)
 >>  >X-Junkmail-Status: score=35/10, host=sfs2.omr.ecl.ntt.co.jp
 >>  >X-Junkmail-SD-Raw:
 >>
 >>score=suspect(0),refid=str=0001.0A090207.468E8745.0129,ss=2,fgs=0,ip=156.154.16.145,so=2007-03-13
 >>
 >>  >10:31:19,dmn=5.3.14/2007-05-31
 >>  >
 >>  >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		: Analysis of Inter-domain Label Switched Path (LSP) Recovery
 >>  >	Author(s)	: T. Takeda, et al.
 >>  >	Filename	: draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >	Pages		: 23
 >>  >	Date		: 2007-7-6
 >>  >
 >>  >This document analyzes various schemes to realize Multiprotocol Label
 >>  >   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
 >>  >   (LSP) recovery in multi-domain networks based on the existing
 >>  >   framework for multi-domain LSPs.
 >>  >
 >>  >   The main focus for this document is on establishing end-to-end
 >>  >   diverse Traffic Engineering (TE) LSPs in multi-domain networks. It
 >>  >   presents various diverse LSP setup schemes based on existing
 >>  >   functional elements.
 >>  >
 >>  >A URL for this Internet-Draft is:
 >>
 >>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >
 >>  >To remove yourself from the I-D Announcement list, send a message to
 >>  >[e-mail] with the word unsubscribe in the body of
 >>  >the message.
 >>  >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
 >>  >to change your subscription settings.
 >>  >
 >>  >Internet-Drafts are also available by anonymous FTP. Login with the
 >>  >username "anonymous" and a password of your e-mail address. After
 >>  >logging in, type "cd internet-drafts" and then
 >>  >"get draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >>  >
 >>  >A list of Internet-Drafts directories can be found in
 >>  >http://www.ietf.org/shadow.html
 >>  >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >>  >
 >>  >Internet-Drafts can also be obtained by e-mail.
 >>  >
 >>  >Send a message to:
 >>  >	[e-mail].
 >>  >In the body type:
 >>  >	"FILE
 >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >>  >
 >>  >NOTE:	The mail server at ietf.org can return the document in
 >>  >	MIME-encoded form by using the "mpack" utility.  To use this
 >>  >	feature, insert the command "ENCODING mime" before the "FILE"
 >>  >	command.  To decode the response(s), you will need "munpack" or
 >>  >	a MIME-compliant mail reader.  Different MIME-compliant mail readers
 >>  >	exhibit different behavior, especially when dealing with
 >>  >	"multipart" MIME messages (i.e. documents which have been split
 >>  >	up into multiple messages), so check your local documentation on
 >>  >	how to manipulate these messages.
 >>  >
 >>  >Below is the data which will enable a MIME compliant mail reader
 >>  >implementation to automatically retrieve the ASCII version of the
 >>  >Internet-Draft.
 >>  >
 >>  >Content-Type: text/plain
 >>  >Content-ID: <[e-mail]>
 >>  >
 >>  >ENCODING mime
 >>  >FILE
 >> /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >
 >>  >
 >>
 >><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt>
 >>  >_______________________________________________
 >>  >I-D-Announce mailing list
 >>  >[e-mail]
 >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>
 >>
 >>
 >> 





Envelope-to: [e-mail]
Delivery-date: Mon, 09 Jul 2007 02:14:02 +0000
Message-Id: <[e-mail]>
Date: Mon, 09 Jul 2007 11:04:03 +0900
To: [e-mail]
From: Tomonori TAKEDA <[e-mail]>
Subject: Fwd: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

A new version of inter-domain recovery analysis I-D have been published.

Here are major changes:
- Added text on security considerations section
- Cleaned up text marked "for further study" (various places)
- Added a reference to [PCEP-XRO]
- Enhanced text on computing diverse paths sequentially with confidentiality
   (Section 5.4.1)
- Moved "terminology" section into "introduction" section
- Removed manageability considerations section
- Polished text

Authors believe the document is now completed and ready for WG last call.

Thanks,
Tomonori

 >To: [e-mail]
 >From: [e-mail]
 >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >X-Spam-Score: 0.0 (/)
 >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >Cc: [e-mail]
 >Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >X-BeenThere: [e-mail]
 >X-Mailman-Version: 2.1.5
 >Reply-To: [e-mail]
 >List-Id: i-d-announce.ietf.org
 >List-Unsubscribe:
 ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?subject=unsubscribe>
 >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >List-Post: <mailto:[e-mail]>
 >List-Help: <mailto:[e-mail]?subject=help>
 >List-Subscribe:
 ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[e-mail]?subject=subscribe>
 >X-Junkmail: UCE(35)
 >X-Junkmail-Status: score=35/10, host=sfs2.omr.ecl.ntt.co.jp
 >X-Junkmail-SD-Raw:
 >score=suspect(0),refid=str=0001.0A090207.468E8745.0129,ss=2,fgs=0,ip=156.154.16.145,so=2007-03-13 

 >10:31:19,dmn=5.3.14/2007-05-31
 >
 >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		: Analysis of Inter-domain Label Switched Path (LSP) Recovery
 >	Author(s)	: T. Takeda, et al.
 >	Filename	: draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >	Pages		: 23
 >	Date		: 2007-7-6
 >
 >This document analyzes various schemes to realize Multiprotocol Label
 >   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
 >   (LSP) recovery in multi-domain networks based on the existing
 >   framework for multi-domain LSPs.
 >
 >   The main focus for this document is on establishing end-to-end
 >   diverse Traffic Engineering (TE) LSPs in multi-domain networks. It
 >   presents various diverse LSP setup schemes based on existing
 >   functional elements.
 >
 >A URL for this Internet-Draft is:
 >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >
 >To remove yourself from the I-D Announcement list, send a message to
 >[e-mail] with the word unsubscribe in the body of
 >the message.
 >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
 >to change your subscription settings.
 >
 >Internet-Drafts are also available by anonymous FTP. Login with the
 >username "anonymous" and a password of your e-mail address. After
 >logging in, type "cd internet-drafts" and then
 >"get draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >
 >A list of Internet-Drafts directories can be found in
 >http://www.ietf.org/shadow.html
 >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >
 >Internet-Drafts can also be obtained by e-mail.
 >
 >Send a message to:
 >	[e-mail].
 >In the body type:
 >	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt".
 >
 >NOTE:	The mail server at ietf.org can return the document in
 >	MIME-encoded form by using the "mpack" utility.  To use this
 >	feature, insert the command "ENCODING mime" before the "FILE"
 >	command.  To decode the response(s), you will need "munpack" or
 >	a MIME-compliant mail reader.  Different MIME-compliant mail readers
 >	exhibit different behavior, especially when dealing with
 >	"multipart" MIME messages (i.e. documents which have been split
 >	up into multiple messages), so check your local documentation on
 >	how to manipulate these messages.
 >
 >Below is the data which will enable a MIME compliant mail reader
 >implementation to automatically retrieve the ASCII version of the
 >Internet-Draft.
 >
 >Content-Type: text/plain
 >Content-ID: <[e-mail]>
 >
 >ENCODING mime
 >FILE /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >
 >
 ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt>
 >_______________________________________________
 >I-D-Announce mailing list
 >[e-mail]
 >https://www1.ietf.org/mailman/listinfo/i-d-announce 





Envelope-to: [e-mail]
Delivery-date: Sun, 08 Jul 2007 19:13:36 +0000
Message-ID: <[e-mail]>
Date: Sun, 08 Jul 2007 12:11:18 -0700
From: Arun Satyanarayana <[e-mail]>
Organization: Cisco Systems
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>, ccamp <[e-mail]>
CC: Dan Li <[e-mail]>, "Deborah A. Brungard" <[e-mail]>, "Arun Satyanarayana (asatyana)" <[e-mail]>
Subject: Re: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2498; t=1183921880; x=1184785880; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Arun=20Satyanarayana=20<[e-mail]> |Subject:=20Re=3A=20Support=20for=20draft-li-ccamp-gr-description-00.txt= 20as=20WG=20I-D? |Sender:=20; bh=j+2LCUZZ2LCNlkNPFLx1PD85nFhk/rGlrz4pWbMmNW8=; b=VuIQR6pbdro8FIOLLCk7YXIQYsLs4u7nZN/8Vucalr0pdP0IRbO6o/R48KtxAosg25290iL1 VBfxdOM027tVrpfU7aJU2dwQ23xkeDl1i+n0aSk9PMhooit4rXQybAQX;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );

I support this I-D as a WG doc.

(am a co-author).

Thanks,
Arun
==============================================================
Adrian Farrel wrote:

> Hi,
> 
> In Prague we found that there was some support for this work, and no 
> opposition.
> 
> There were questions regarding clarifying that the work does not define 
> new process or procedures, but explains how existing procedures (i.e. 
> draft-ietf-ccamp-rsvp-restart-ext-08.txt) can be applied in a variety of 
> situations. I think that this revision has included this clarification.
> 
> There was a request to broaden the draft to cover all scenarios (not 
> just multi-node as before), and this has been done.
> 
> There was concern about whether there was "service provider" interest in 
> this work. In fact, several of the hands raised to express interest 
> worked for service providers. But I am not personally convinced that 
> this Informational work needs strong support from that sector. More to 
> the point would be support from the vendors who need to agree how they 
> will operate draft-ietf-ccamp-rsvp-restart-ext.
> 
> So, I'd like to ask the WG whether there is support to make this I-D a 
> WG draft.
> If we do, I would like to see it complete quite quickly. It would need:
> - review by vendors to make sure it is accurate
> - a bit more text on security issues
> 
> Thanks,
> Adrian
> 
> ----- Original Message ----- From: "Dan Li" <[e-mail]>
> To: "ccamp" <[e-mail]>
> Cc: "Deborah A. Brungard" <[e-mail]>; "Farrel, Adrian" 
> <[e-mail]>; "Arun Satyanarayana" <[e-mail]>
> Sent: Friday, June 22, 2007 2:08 AM
> Subject: New draft: draft-li-ccamp-gr-description-00.txt
> 
> 
>> Dear CCAMPers,
>>
>> We have published a "new" I-D:
>> http://tools.ietf.org/wg/ccamp/draft-li-ccamp-gr-description-00.txt
>>
>> This I-D replaces the previous I-D 
>> http://tools.ietf.org/wg/ccamp/draft-li-ccamp-multinodes-gr-proc-01.txt.
>>
>> According to the discussion in Prague meeting, we have:
>> 1) Changed draft to be Informational. Mainly rewords the draft to make 
>> sure that it does not give instructions that could be interpreted as 
>> defining the procedures.
>> 2) The title of the I-D has been changed to "Description of the 
>> RSVP-TE Graceful Restart Procedures", in order to wide the scope of 
>> this I-D to include the single node graceful restart scenario.
>>
>> Best regards,
>> Dan Li 
> 



Envelope-to: [e-mail]
Delivery-date: Sun, 08 Jul 2007 15:22:51 +0000
Date: Sun, 08 Jul 2007 23:17:21 +0800
From: Dan Li <[e-mail]>
Subject: Re: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?
To: Adrian Farrel <[e-mail]>, ccamp <[e-mail]>
Cc: "Deborah A. Brungard" <[e-mail]>, Arun Satyanarayana <[e-mail]>
Message-id: <003e01c7c173$7dbb3890$6401a8c0@dan>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=response
Content-transfer-encoding: 7BIT

Hi,

As a co-author of this draft, I should say YES!

Thanks,

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Dan Li" <[e-mail]>; "ccamp" <[e-mail]>
Cc: "Deborah A. Brungard" <[e-mail]>; "Arun Satyanarayana" 
<[e-mail]>
Sent: Sunday, June 24, 2007 8:40 PM
Subject: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?


> Hi,
>
> In Prague we found that there was some support for this work, and no 
> opposition.
>
> There were questions regarding clarifying that the work does not define 
> new process or procedures, but explains how existing procedures (i.e. 
> draft-ietf-ccamp-rsvp-restart-ext-08.txt) can be applied in a variety of 
> situations. I think that this revision has included this clarification.
>
> There was a request to broaden the draft to cover all scenarios (not just 
> multi-node as before), and this has been done.
>
> There was concern about whether there was "service provider" interest in 
> this work. In fact, several of the hands raised to express interest worked 
> for service providers. But I am not personally convinced that this 
> Informational work needs strong support from that sector. More to the 
> point would be support from the vendors who need to agree how they will 
> operate draft-ietf-ccamp-rsvp-restart-ext.
>
> So, I'd like to ask the WG whether there is support to make this I-D a WG 
> draft.
> If we do, I would like to see it complete quite quickly. It would need:
> - review by vendors to make sure it is accurate
> - a bit more text on security issues
>
> Thanks,
> Adrian
>
> ----- Original Message ----- 
> From: "Dan Li" <[e-mail]>
> To: "ccamp" <[e-mail]>
> Cc: "Deborah A. Brungard" <[e-mail]>; "Farrel, Adrian" 
> <[e-mail]>; "Arun Satyanarayana" <[e-mail]>
> Sent: Friday, June 22, 2007 2:08 AM
> Subject: New draft: draft-li-ccamp-gr-description-00.txt
>
>
>> Dear CCAMPers,
>>
>> We have published a "new" I-D:
>> http://tools.ietf.org/wg/ccamp/draft-li-ccamp-gr-description-00.txt
>>
>> This I-D replaces the previous I-D 
>> http://tools.ietf.org/wg/ccamp/draft-li-ccamp-multinodes-gr-proc-01.txt.
>>
>> According to the discussion in Prague meeting, we have:
>> 1) Changed draft to be Informational. Mainly rewords the draft to make 
>> sure that it does not give instructions that could be interpreted as 
>> defining the procedures.
>> 2) The title of the I-D has been changed to "Description of the RSVP-TE 
>> Graceful Restart Procedures", in order to wide the scope of this I-D to 
>> include the single node graceful restart scenario.
>>
>> Best regards,
>> Dan Li
>
>
> 




Envelope-to: [e-mail]
Delivery-date: Sun, 08 Jul 2007 10:30:26 +0000
Message-ID: <043001c7c14a$933c9430$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: First draft agenda published
Date: Sun, 8 Jul 2007 11:23:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi all,

We have posted a first draft agenda at 
http://www3.ietf.org/proceedings/07jul/agenda/ccamp.htm

Please have a look and let us know what you think.

- What else should be included?
- What things are in the wrong order?
- What should be moved between the two sessions?

Presenters should feel free to send their slides as soon as possible. As 
usual, getting your slides to us one or two days before the meeting is a 
courtesy to everyone especially those for whom English is not a native 
language.

Thanks,

Deborah and Adrian 





Envelope-to: [e-mail]
Delivery-date: Sat, 07 Jul 2007 19:57:34 +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: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Date: Sat, 7 Jul 2007 21:53:57 +0200
Message-ID: <[e-mail]>
Thread-Topic: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Thread-Index: Ace/Iv/wATkVETcSTT+CAQmeajDxfgBrSD/w
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Zafar Ali \(zali\)" <[e-mail]>, "Lou Berger" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Hassan Sheikh \(hassans\)" <[e-mail]>, "Tomohiro Otani" <[e-mail]>

zafar

it is the other way around, because you have different subnets you can
not make use of existing mechanisms

"The solution we are pushing for is that we need a mechanism that allows
us to resolve ARP directly for the GMPLS tunnel ip addresses. This
removes any dependency on the underlying Ethernet links or the
addressing scheme that is used for TE links i.e. numbered links in the
same or different subnets."

hence the first question is why shall this be different ?

-d.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Zafar Ali (zali)
> Sent: Thursday, July 05, 2007 6:39 PM
> To: Lou Berger; Igor Bryskin; [e-mail]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh=20
> (hassans); Tomohiro Otani
> Subject: Follow-up on comments on=20
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
>=20
> Hi Lou, Igor, ccamper, et al,=20
> =20
> Here is a follow-up on our AI from last WG meeting on the=20
> comments received on=20
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt. We=20
> are planning to revise the document based on your feedback.=20
> Please advise if you have any further comment/ suggestion.=20
> =20
> The issue is focused around the use of the GMPLS tunnel as a=20
> point-to-point link using Ethernet TE links. Unlike pos links=20
> where a L2 adjacency resolution is not required, the Ethernet=20
> links require that the ARP be resolved (aka Layer 2 MAC=20
> address) before any forwarding works on this link. It is not=20
> a case of broken implementation. We (router vendors) cannot=20
> work around ARP. What we need to do is to provide clear=20
> direction or recommendation for vendors on how to ARP for=20
> GMPLS controlled Ethernet interfaces. Or else, all vendors=20
> will implement whatever ARP mechanism works for them in terms=20
> of forwarding. E.g., there is an interop issue between=20
> Juniper and Cisco (from a fwding perspective) when Ethernet=20
> links are used (Both do ARP). We had to find workarounds to=20
> make things work (at ISO Core and in private testing). The=20
> same will be the case between Cisco, Juniper and other vendors.=20
> =20
> The solution we are pushing for is that we need a mechanism=20
> that allows us to resolve ARP directly for the GMPLS tunnel=20
> ip addresses. This removes any dependency on the underlying=20
> Ethernet links or the addressing scheme that is used for TE=20
> links i.e. numbered links in the same or different subnets.
> =20
> In the following, we describe the situation with numbered=20
> Ethernet links and Unnumbered Ethernet links (the assumption=20
> is that the GMPLS tunnel is a ipv4 numbered link in both instances).
> =20
> Consider the scenario=20
> =20
> <----------------------------------------------GMPLS=20
> Tunnel------------------------------------------>
> =20
> RTR1 <------GE data link/TE link -----> OXC <------ GE data=20
> link/TE link -----> RTR2
>                   segment # 1                                =20
>   segment # 2
> There are two instance to consider:
> =20
> (a) When numbered TE links are used but segment # 1 and=20
> segment # 2 are in different subnets (valid scenario)
>      In this situation we really have no way of resolving ARP=20
> using the addresses of the underlying TE link Ethernet links=20
> w/o using static ARP entries. The issue is that the subnets=20
> are different so the ARP request received by RTR2 from RTR1=20
> will be rejected as it is not known to RTR2 and vice versa.=20
> Instead, if the ARP request if for the GMPLS tunnel instead=20
> then there should be no problem as the GMPLS tunnel is p-p=20
> link with IPV4 addresses in the same subnet.
> Verdict: If we have the ARP resolution mechanism tied in to=20
> the GMPLS tunnel interfaces addresses then there is no issue=20
> or dependency=20
> =20
> (a) When numbered TE links are used and segment # 1 and=20
> segment # 2 are in the same subnet.=20
>      In this setup the GMPLS Tunnel can inherit and use the=20
> ethernet link address for ARP resolution and there is no=20
> issue as both segments are in the same subnet. The problem in=20
> this situation is that we need to resolve the ARP for the=20
> ipv4 addresses for the GMPLS tunnel (considered as a p-p=20
> link) as opposed to inherit it from the underlying Ethernet TE links.
> Verdict:  In this situation the ARP resolution mechanism=20
> should be developed for the GMPLS tunnel address.
> =20
> (c) The third scenario is when the GMPLS tunnel is numbered=20
> but the TE links are Unnumbered.
>      In this case we are again faced with the same issue of=20
> L2 ARP adjacency resolution between RTR1 and RTR2. RTR2 will=20
> reject the ARP request for RTR1 when it does not find the=20
> Unnumbered address (used by RTR1) in its FWDing database.=20
> This issue would not be encountered if we were resolving the=20
> ARP on GMPLS tunnel address.
> Verdict: ARP resolution mechanism is required for GMPLS tunnel.
> =20
> (d) We also need to make sure that when the tunnel-id is=20
> unnum, vendor implementation honor ARP request using loopback=20
> addresses. We have also faced interop issue in this scenario.=20
> =20
> Thanks
> =20
> Regards... Hassan and Zafar=20
>=20



Envelope-to: [e-mail]
Delivery-date: Sat, 07 Jul 2007 13:48:04 +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: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt 
Date: Sat, 7 Jul 2007 15:44:25 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt 
Thread-Index: AcesKq7ne8EWLsq6RrS4zGU/bWo/UQUcZBHQ
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Zafar Ali" <[e-mail]>, <[e-mail]>
Cc: "Jean Philippe Vasseur" <[e-mail]>, "Anca Zamfir" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>

adrian

the new error sub-code for the RSVP error-code "Routing=20
Problem" (24) [RSVP-TE] is:=20
    =20
       9 (TBA)   Local component link maintenance required=20

overlaps with the already defined Routing Problem

       9 =3D MPLS label allocation failure         [RFC3209]

this said if one does want to achieve certain consistency
it should be defined as a error value should be defined as
a sub-code of the Notify Error code (25)

  7 =3D Local link maintenance required            [RFC4736]
  8 =3D Local node maintenance required            [RFC4736]  =20

thanks,
-d.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Monday, June 11, 2007 3:12 PM
> To: Zafar Ali; [e-mail]
> Cc: 'Jean Philippe Vasseur'; 'Anca Zamfir';=20
> [e-mail]; Brungard, Deborah A, ALABS
> Subject: Re: I-D=20
> ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt=20
>=20
> Hi,
>=20
> The authors have indicated that this draft is complete and=20
> ready for WG last=20
> call.
>=20
> As is now our customary ritual, the chairs have done a=20
> pre-last call review.=20
> In this case, I am the lucky reviewer.
>=20
> Although the changes below are relatively minor in substance,=20
> they are many.=20
> I feel it would be helpful to reviewers in last call if you=20
> could provide an=20
> update with these issues fixed. As soon as I see it published we can=20
> initiate last call (subject to the Chicago meeting not=20
> getting in the way).
>=20
> Thanks,
> Adrian
>=20
> =3D=3D=3D
> "GMPLS" in title, abstract, and first use in main text.
> Unfortunately, "GMPLS" is still not a recognised term in the=20
> wider IETF.
> You must, therefore, expand the acronym where it first occurs.
> =3D=3D=3D
> Abstract line 1
> s/shutdown/Shutdown/
> =3D=3D=3D
> Abstract para 1
> s/towards/toward/
> =3D=3D=3D
> Abstract para 1
> s/addressing the planned/addressing planned/
> =3D=3D=3D
> Abstract
> "These operations are equally
>    applicable for both MPLS and its GMPLS extensions."
> If so, why have you named the document as you have.
> Wouldn't a better name have been:
> Graceful Shutdown in MPLS and Generalized MPLS Traffic=20
> Engineering Networks
> =3D=3D=3D
> Conventions used in this document
> Section contains a reference to "[i]" that is not resolved.
> =3D=3D=3D
> Contents table
> Formatting is scrappy
> =3D=3D=3D
> 1. Terminology
> s/LSR - Label Switching Device./LSR - Label Switching Router./
> =3D=3D=3D
> 1. Terminology
> "LSP - An MPLS Label Switched Path"
> What happened to GMPLS?
> =3D=3D=3D
> 1. Terminology
> The definition for "Head-end or Ingress node:" is very hard=20
> to read and, I=20
> suspect, non-intuitive. Redefining "head-end" to mean=20
> "sometimes also a=20
> transit node" will really fry people's minds! If you need a=20
> term for a node=20
> that performs a specific function, I suggest that you create=20
> a new term=20
> rather than overloading an existing one.
> =3D=3D=3D
> 1. Terminology
> "GMPLS - The term GMPLS is used in this document to refer to both
>  classic MPLS, as well as the GMPLS extensions to MPLS."
> You mean LDP?
> =3D=3D=3D
> 1. Terminology
> TE Link
> a. You need to provide an expansion of FA-LSP, and probably a=20
> reference
> b. Your definition has not caught all of the possible uses of=20
> a TE link=20
> (such
>    as link bundles). Perhaps you want to use a generic definition?
> =3D=3D=3D
> 2. Introduction
> "disable Traffic Engineering on a TE Link"
> This begs the question: what is traffic engineering?
> Are you disabling TE on the link, or are you disabling data=20
> traffic on the=20
> link?
> I think some work throughout the document to clarify the=20
> difference between:
> - the impact of disabling a link (viz. traffic cannot flow)
> and
> - disabling TE advertisement (viz. the link's capacity is=20
> withdrawn from the=20
> TED).
> The latter being the way to gracefully advertise the former.
> =3D=3D=3D
> 2. Introduction  para 1
> s/graceful reroute/gracefully reroute/
> =3D=3D=3D
> 2. Introduction
> "The node initiating the graceful shutdown condition
>    SHOULD delay the removal of the resources for forwarding, for
>    some period determined by local policy."
> The point is not the delay. The point is the delay between=20
> disabling the=20
> resource in the control plane and removing the resource for=20
> forwarding.
> Can you clarify, please.
> =3D=3D=3D
> 2. Introduction para 2
> s/allow control/allow the control/
> =3D=3D=3D
> 2. Introduction para 2
> "Similarly, trigger for the graceful
>    shutdown event is a local matter at the node initiating the
>    graceful shutdown."
> a. Similarly to what?
> b. s/trigger/the trigger/
> =3D=3D=3D
> 2. Introduction
> "traditional shutdown operation of an interface"
> I like this phrase.
> My family have been shutting down interfaces for generations. We use=20
> traditional techniques involving spun grass and a hand axe.
> =3D=3D=3D
> 2. Introduction
> Last line
> s/node/nodes/
> =3D=3D=3D
> Section 3.
> Formatting is broken.
> Indentation and bullets.
> =3D=3D=3D
> Section 3  2nd requirement
> This reads a bit odd. Would it be better as:
>=20
> - Once an operator has initiated graceful shutdown of a network
> resource, no new TE LSPs may be set up that use the resource.
> Any signaling message for a new LSP that explicitly specifies the
> resource, or that would require the use of the resource due to
> local constraints, must be rejected as if the resource were
> unavailable.
>=20
> - It is desirable for new LSP setup attempts that would be rejected
> because of graceful shutdown of a resource (as described in the
> previous requirement) to avoid any attempt to use the resource by
> selecting an alternate route or other resources.
> =3D=3D=3D
> Section 3
> "   - It is required to reduce/eliminate traffic disruption on the
>    LSP(s) using the network resources which are about to be
>    shutdown."
> Is this the requirement, or is the requirement to give the=20
> ingress the=20
> opportunity to perform this function if policy and=20
> configuration require it,=20
> and if network resources allow?
> =3D=3D=3D
> Section 3
> "   - In order to make rerouting effective, it is required to
>    communicate information about the TE resource under graceful
>    shutdown."
> I know what you mean, but you have been terribly=20
> non-specific. Communicate=20
> what information from whom to whom?
> It is probably:
> - the fact that the resource is being shut down
> - from the node where the resource is located
> - to all other network nodes
> =3D=3D=3D
> Page 4 (and several other places)
> Excessive page throws
> =3D=3D=3D
> Section 4.1
>   "Setup request for new LSPs over the TE resource being gracefully
>    shutdown SHOULD be rejected using the existing mechanisms that
>    are applied when the TE resource is not available."
> Are you sure that you don't want to reject the setup using=20
> one of your new=20
> error codes?
> =3D=3D=3D
> Section 4.1.1
>    The "local
>    TE link maintenance required" error code is defined in [PATH-
>    REOPT].
> s/local TE link/local link/
> In the whole of this section, and the rest of the document, please be=20
> careful to distinguish Error Codes and Error Values. In this=20
> case you are=20
> talking about an Error Value that is associated with the=20
> "Notify" Error=20
> Code. It is necessary to describe both fields.
> =3D=3D=3D
> Section 4.1.1
> Suddenly you are abbreviating to "GS". I think that is inadvisable.
> =3D=3D=3D
> General question.
> Would it help the ingress or PLR if the PathErr reporting=20
> imminent graceful=20
> shutdown included additional information such as the likely=20
> time of shutdown=20
> in the data plane, and the likely time of restart?
> We do have mechanisms for this function in RFC 4783.
> =3D=3D=3D
> Section 4.1.1
>    When a head-end LSR receives a Path Error (or Notify) message
>    with sub-code "Local Maintenance on TE Link required Flag", it
>    SHOULD immediately trigger a make-before-break procedure. A head-
>    end node SHOULD avoid the IP address contained in the PathErr (or
>    Notify message) when performing path computation for the new LSP.
> a. The name of the subcode continues to mutate :-)
> b. The first SHOULD is *entirely* a matter of local policy.=20
> It is a MAY.
> c. The second SHOULD is ambiguous as you haven't told us which
>    IP address is contained in the PathErr. Since the Error Value is
>    related to a TE Link, presumably it is the TE link IP address. But
>    what if it is a node being shut down? What if it is only a lambda
>    being shut down?
>    Can you not use some more informative fields and reason codes
>    as provided in draft-ietf-ccamp-crankback-06.txt or RFC4872?
> d. Please be consistent and use "Path Error" or "PathErr". I=20
> prefer the
>    second.
> =3D=3D=3D
> Section 4.1.1
>    If the resource being gracefully shutdown is on the Path of the
>    protecting LSP/ local detour, the branch node/ PLR reroutes the
>    protecting LSP/ local detour just a head-end LSR would reroute
>    any other LSP.
> Need to tidy up the text.
> But what are you saying? One LSP is the same as another, and=20
> reroute takes=20
> place from the head end. That is all.
> =3D=3D=3D
> Section 4.1.2
>    RSVP error-code "Routing Problem" (24) [RSVP-TE] is
>    needed:
>          9 (TBA)   Local component link maintenance required
> Why is this a subcode of Routing Problem, when you have used=20
> a subcode of=20
> Notify for the case of the whole TE link?
> More importantly, the use of Routing Problem is likely to=20
> cause us to run=20
> into questions about whether the upstream transit nodes will=20
> panic and tear=20
> the LSP or not. Using the Notify Error Code is a much safer approach.
> =3D=3D=3D
> Section 4.1.2
>    The head-end LSR MAY still use the IP address
>    contained in the Path Error or Notify message in performing path
>    computation for rerouting the LSP. This is because, this address
>    is an IP address of the component link and the flag is an
>    implicit indication that the TE link may still have capacity to
>    admit new LSPs.
> If the IP address is the address of the component link being=20
> shut down, then=20
> it cannot be used in the new path. If, however, the address=20
> is the address=20
> of the link bundle, then it can still be used.
> =3D=3D=3D
> Important
> I think you are missing an element of procedure that applies=20
> at the node=20
> doing shut down.
> please state clearly which addresses are placed in which fields when=20
> reporting graceful shutdown for a:
> - node
> - te link
> - component link
> - label resource
> =3D=3D=3D
> Section 4.1.2
>    However, if the ERO is computed such that it also
>    provides details of the component link selection(s) along the
>    Path, the component link selection with IP address contained in
>    the Path Error or Notify message SHOULD be avoided.
> The use of "SHOULD" implies that there may be a good reason=20
> to continue to=20
> use the address. Please supply the text
> "MAY continue to use it in order to ...."
> =3D=3D=3D
> Section 4.1.3
> Doesn't give enough information to the head end to avoid the=20
> problem node in=20
> its reroute computations.
> Perhaps you need to reorder your document to say that the IGP=20
> pieces happen=20
> first, and the shutdown node should wait to allow the IGP to=20
> converge before=20
> sending out PathErr and or Notify?
> =3D=3D=3D
> Section 4.2.1
> Why not include also specifying Minimum LSP Bandwidth as=20
> greater than the=20
> available bandwidth and greater than the maximum LSP bandwidth?
> This goes further than "discouraging" the use of the TE link,=20
> it makes it=20
> impossible to use even for zero-bandwidth LSPs.
> I'm pretty sure this was discussed several times in the WG.
> =3D=3D=3D
> Section 4.2.1
>    Neighbors of the node where graceful shutdown procedure is in
>    progress SHOULD continue to advertise the actual unreserved
>    bandwidth of the TE links from the neighbors to that node,
>    without any routing adjacency change.
> Doesn't this mean that the TE link is only shut down in one=20
> direction? So=20
> unidirectional LSPs would still try to use the link.
> =3D=3D=3D
> Section 5
> I don't think you will get this past the Security ADs.
> What happens if graceful shutdown is:
> - spoofed
> - hidden (i.e. the signaling or routing is blocked)
> You have not mentioned the IGP security.
> it might be a good idea to include a reference to Luyuan's draft.
> =3D=3D=3D
> Section 6
> You need to give IANA far clearer instructions than this.
> Please look at a recent RFC for an example.
> I suggest RFC 4873 section 9.5
> =3D=3D=3D
> References
> Personally, I like references to RFCs to use the RFC numbers=20
> as this is far=20
> quicker to look up. But you don't have to make this change.
> =3D=3D=3D
>=20
>=20
> ----- Original Message -----=20
> From: <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Friday, June 08, 2007 8:50 PM
> Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt
>=20
>=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=20
> Measurement Plane=20
> > Working Group of the IETF.
> >
> > Title : Graceful Shutdown in GMPLS Traffic Engineering Networks
> > Author(s) : Z. Ali, et al.
> > Filename : draft-ietf-ccamp-mpls-graceful-shutdown-03.txt
> > Pages : 9
> > Date : 2007-6-8
> >
> > GMPLS-TE Graceful shutdown is a method for explicitly notifying
> >   the nodes in a Traffic Engineering (TE) enabled network that the
> >   TE capability on a link or on an entire Label Switching Router
> >   (LSR) is going to be disabled. GMPLS-TE graceful shutdown
> >   mechanisms are tailored towards addressing the planned outage in
> >   the network.
> >
> >   This document provides requirements and protocol mechanisms so as
> >   to reduce/eliminate traffic disruption in the event of a planned
> >   shutdown of a network resource. These operations are equally
> >   applicable for both MPLS and its GMPLS extensions.
> >
> > A URL for this Internet-Draft is:
> >=20
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-grac
> eful-shutdown-03.txt
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Sat, 07 Jul 2007 02:06:20 +0000
Date: Sat, 07 Jul 2007 11:01:16 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: new draft about signaling for a bidirectionl lightpath
From: Hiroaki Harai <[e-mail]>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Diego.

I think the usage that you mentioned (using label set and upstream
label) is not enough by the following two reasons.

1. [Non-support of multiple lambdas] Upstream label object conveys
   only ONE label, which is likely to face lack of the same lambda as
   that in the previous link. We have high blocking probability for
   LSP setup. If we convey multiple lambdas for upstream, the
   probability would be reduced significantly (but, we cannot convey).

   Someone may want to change lambda in Upstream Label into other
   lambda among lambdas in the Label Set when the lambda in Upstream
   Label is not acceptable further. However, according to Section 3.1
   of RFC 3473, if label in Upstream Label is not acceptable, PathErr
   is generated.  Different from Suggested Label, we have no chance to
   change. So, using Upstream Label is not enough.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
   3.1 Procedures (RFC 3473)
   The process of establishing a bidirectional LSP follows the
   establishment of a unidirectional LSP with some additions. To
   support bidirectional LSPs an Upstream_Label object is added to the
   Path message. The Upstream_Label object MUST indicate a label that
   is valid for forwarding at the time the Path message is sent.
   When a Path message containing an Upstream_Label object is
   received, the receiver first verifies that the upstream label is
   acceptable. If the label is not acceptable, the receiver MUST issue
   a PathErr message with a "Routing problem/Unacceptable label value"
   indication. The generated PathErr message MAY include an Acceptable
   Label Set, see Section 4.1.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

2. [Keep flexibility] The same lambda on both directions may not
   reqested for some bidirectional LSPs different from the case in
   this draft. In this case, once we pose the same lambda constraint
   against upstream label, we lose flexiblity to setup LSPs by
   different lambda in each direction.

Best regards,
- Hiroaki   =




From: "Diego Caviglia (GA/ERI)" <[e-mail]>
Subject: RE: new draft about signaling for a bidirectionl lightpath
Date: Fri, 6 Jul 2007 15:00:13 +0200
Message-ID: <[e-mail]=
icsson.se>

> =

> Hi Hiroaki,
>            Not clear to me why the mechanism using label set with the=
 same lambda as the Upstream label is not enough here.   =

> =

> BR
> =

> Diego
> =

> =

> =

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On B=
ehalf Of Hiroaki Harai
> Sent: venerd=EC 6 luglio 2007 3.10
> To: [e-mail]
> Subject: new draft about signaling for a bidirectionl lightpath
> =

> Hi everyone,
> =

> We posted a new draft about GMPLS signaling for a bidirectional
> lightpath setup as follows.
> http://www.ietf.org/internet-drafts/draft-xu-rsvpte-bidir-wave-00.txt=

> =

> =3D=3D=3D=3D=3D=3D
> Title   : Extensions to GMPLS RSVP-TE for Bidirectional Lightpath wit=
h
>           the Same Wavelength
> Authors : S. Xu, H. Harai, and D. King
> Filename: draft-xu-rsvpte-bidir-wave-00.txt
> 	=

> Abstract: For bidirectional lightpaths provisioning, in the case of
> optical nodes that do not support wavelength conversion, it would be
> necessary to use the same wavelength along the route on each
> direction. In certain optical network scenarios, the use of the same
> wavelength on both directions would be advantageous.  For instance,
> some type of ROADMs may add/drop the same wavelength
> simultaneously. In another case, the users' optical end nodes are
> equipped with fixed-wavelength transponders.
> =

> This document describes extensions to RSVP-TE signaling for =

> bidirectional wavelength lightpaths that require the same wavelength =
on =

> both directions. By using an LSP_ATTRIBUTES object defined in [RFC442=
0], =

> the extensions enable the new type lightpaths to support the low cost=
 =

> configuration at users' optical end nodes.
> =3D=3D=3D=3D=3D=3D
> =

> We believe that selecting a single wavelength on both directions for =
a
> bidirectional LSP is very real. And our suggestion in this draft is a=

> simple one.
> =

> We appreciate your comments and feedbacks.
> =

> With best regards,
> Hiroaki
> =

> -------
> Hiroaki Harai, Ph.D. (http://nag.nict.go.jp/)
> Network Architecture Group, New Generation Network Research Center
> National Institute of Information and Communications Technology (NICT=
), JAPAN.
> Email: [e-mail];  Phone: [phone];  FAX: [phone]=
80
> =

> =




Envelope-to: [e-mail]
Delivery-date: Fri, 06 Jul 2007 18:17:41 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D  ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Message-Id: <[e-mail]>
Date: Fri, 06 Jul 2007 14:15:01 -0400

--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		: Analysis of Inter-domain Label Switched Path (LSP) Recovery
	Author(s)	: T. Takeda, et al.
	Filename	: draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
	Pages		: 23
	Date		: 2007-7-6
	
This document analyzes various schemes to realize Multiprotocol Label 
   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path 
   (LSP) recovery in multi-domain networks based on the existing 
   framework for multi-domain LSPs. 
    
   The main focus for this document is on establishing end-to-end 
   diverse Traffic Engineering (TE) LSPs in multi-domain networks. It 
   presents various diverse LSP setup schemes based on existing 
   functional elements.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Fri, 06 Jul 2007 13:01:32 +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: new draft about signaling for a bidirectionl lightpath
Date: Fri, 6 Jul 2007 15:00:13 +0200
Message-ID: <[e-mail]>
Thread-Topic: new draft about signaling for a bidirectionl lightpath
Thread-Index: Ace/a6UcPgSZJDi0RMqz73OkzjeiCwAWX3Iw
From: "Diego Caviglia (GA/ERI)" <[e-mail]>
To: "Hiroaki Harai" <[e-mail]>, <[e-mail]>

Hi Hiroaki,
           Not clear to me why the mechanism using label set with the =
same lambda as the Upstream label is not enough here.  =20

BR

Diego



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On =
Behalf Of Hiroaki Harai
Sent: venerd=EC 6 luglio 2007 3.10
To: [e-mail]
Subject: new draft about signaling for a bidirectionl lightpath

Hi everyone,

We posted a new draft about GMPLS signaling for a bidirectional
lightpath setup as follows.
http://www.ietf.org/internet-drafts/draft-xu-rsvpte-bidir-wave-00.txt

=3D=3D=3D=3D=3D=3D
Title   : Extensions to GMPLS RSVP-TE for Bidirectional Lightpath with
          the Same Wavelength
Authors : S. Xu, H. Harai, and D. King
Filename: draft-xu-rsvpte-bidir-wave-00.txt
=09
Abstract: For bidirectional lightpaths provisioning, in the case of
optical nodes that do not support wavelength conversion, it would be
necessary to use the same wavelength along the route on each
direction. In certain optical network scenarios, the use of the same
wavelength on both directions would be advantageous.  For instance,
some type of ROADMs may add/drop the same wavelength
simultaneously. In another case, the users' optical end nodes are
equipped with fixed-wavelength transponders.

This document describes extensions to RSVP-TE signaling for=20
bidirectional wavelength lightpaths that require the same wavelength on=20
both directions. By using an LSP_ATTRIBUTES object defined in [RFC4420], =

the extensions enable the new type lightpaths to support the low cost=20
configuration at users' optical end nodes.
=3D=3D=3D=3D=3D=3D

We believe that selecting a single wavelength on both directions for a
bidirectional LSP is very real. And our suggestion in this draft is a
simple one.

We appreciate your comments and feedbacks.

With best regards,
Hiroaki

-------
Hiroaki Harai, Ph.D. (http://nag.nict.go.jp/)
Network Architecture Group, New Generation Network Research Center
National Institute of Information and Communications Technology (NICT), =
JAPAN.
Email: [e-mail];  Phone: [phone];  FAX: [phone]




Envelope-to: [e-mail]
Delivery-date: Fri, 06 Jul 2007 12:48:01 +0000
Date: Fri, 06 Jul 2007 08:44:37 -0400
To: "Diego Caviglia (GA/ERI)" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: RE: Switching Capability of Photonic Links with Transponder
Cc: "Greg Bernstein" <[e-mail]>,<[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>

Diego,
         Other than possibly not using SDH=20
encoding, it sounds like your situation is=20
equivalent to the case described in Section 3.5=20
of RFC4202.  No? Keep in mind that it's the=20
effective switching capability as represented on=20
an *interface* that is advertised.

Lou

At 03:14 AM 7/6/2007, Diego Caviglia (GA/ERI) wrote:

>Hi Greg,
>             Yes the interface is a single=20
> lambda and then there should be a DWDM Line=20
> system or could be as you said a RODAM.
>
>Great mind have similar thought J J
>
>BR
>
>Diego
>
>From: Greg Bernstein [mailto:[e-mail]]
>Sent: gioved=EC 5 luglio 2007 18.39
>To: Diego Caviglia (GA/ERI)
>Cc: [e-mail]
>Subject: Re: Switching Capability of Photonic Links with Transponder
>
>Hi Diego, looks like we've been thinking about similar issues lately.
>First, I want to nail down the interfaces on your lambda switch below.
>Are they:
>(a) WDM interfaces, i.e., with multiple lambda's coming in and out.
>(b) single wavelength interfaces
>(c) a combination of the two, e.g., like in a=20
>ADM (or ROADM) where we have line side (WDM) and drop side single=
 wavelength.
>
>On terminology instead of "frequency switching"=20
>can we call it by its more typical name=20
>"wavelength conversion" to avoid confusion with=20
>"lambda switching" (since lambda's and=20
>frequencies have a 1-1 correspondence and both=20
>are used to describe optical signals in ITU-T recommendations).
>
>Given where the OEO is located I'd say that=20
>particular interface is a single wavelength.
>
>Regards
>
>Greg B.
>
>Diego Caviglia (GA/ERI) wrote:
>Hi all,
>          I=92ve a doubt about how to model the following situation.
>
>
>
>       +-----------------+
>       |                 |-------+
>       |                 | OEO   |
>       |     Lambda      |-------+
>       |     Switch      |
>       |                 |
>       |                 |
>       +-----------------+
>
>
>The node itself is able to cross connect only=20
>the Lambda while the interface has a OEO=20
>transponder that is able to change the lambda=20
>frequency.  In this case there are two different=20
>=91switching capability=92 the spatial one that is=20
>performed by the switch (lambda 1, port A) -->=20
>(lambda1, port B) and the frequency switching is=20
>done by the OEO transponder.  Witch kind of=20
>interface switching capability I have to advertise?
>
>BR
>
>Diego
>
>Diego Caviglia
>Product Line ON BBN
>PA Broadband BNET
>
>Marconi S.p.A
>Ericsson Global Product Center - Italy
>Via Anagnina,203
>0018, Roma , Italy
><http://www.ericsson.com/>www.ericsson.com
>
>Office:  [phone]
>Fax: [phone]
>Mobile: [phone]
>Email: <mailto:[e-mail]>[e-mail]
>This communication is confidential and intended=20
>solely for the addressee(s). Any unauthorized=20
>review, use, disclosure or distribution is=20
>prohibited. If you believe this message has been=20
>sent to you in error, please notify the sender=20
>by replying to this transmission and delete the=20
>message without disclosing it. Thank you.
>
>E-mail including attachments is susceptible to=20
>data corruption, interception, unauthorized=20
>amendment, tampering and viruses, and we only=20
>send and receive emails on the basis that we are=20
>not liable for any such corruption,=20
>interception, amendment, tampering or viruses or any consequences thereof.
>
>
>
>
>--
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=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: Fri, 06 Jul 2007 07:17:13 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BF9D.407E465A"
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Fri, 6 Jul 2007 09:14:09 +0200
Message-ID: <[e-mail]>
Thread-Topic: Switching Capability of Photonic Links with Transponder
Thread-Index: Ace/IwYIhyQQYNhwSquQ5Y8j0o+H8gAeeWiA
From: "Diego Caviglia (GA/ERI)" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>
Cc: <[e-mail]>

This is a multi-part message in MIME format.

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

Hi Greg,

            Yes the interface is a single lambda and then there should =
be a DWDM Line system or could be as you said a RODAM.

=20

Great mind have similar thought :-) :-)

=20

BR

=20

Diego

=20

From: Greg Bernstein [mailto:[e-mail]]=20
Sent: gioved=EC 5 luglio 2007 18.39
To: Diego Caviglia (GA/ERI)
Cc: [e-mail]
Subject: Re: Switching Capability of Photonic Links with Transponder

=20

Hi Diego, looks like we've been thinking about similar issues lately.
First, I want to nail down the interfaces on your lambda switch below.
Are they:
(a) WDM interfaces, i.e., with multiple lambda's coming in and out.
(b) single wavelength interfaces
(c) a combination of the two, e.g., like in a ADM (or ROADM) where we =
have line side (WDM) and drop side single wavelength.

On terminology instead of "frequency switching" can we call it by its =
more typical name "wavelength conversion" to avoid confusion with =
"lambda switching" (since lambda's and frequencies have a 1-1 =
correspondence and both are used to describe optical signals in ITU-T =
recommendations).

Given where the OEO is located I'd say that particular interface is a =
single wavelength.

Regards

Greg B.

Diego Caviglia (GA/ERI) wrote:=20

Hi all,

         I've a doubt about how to model the following situation.

=20

=20

=20

      +-----------------+

      |                 |-------+

      |                 | OEO   |

      |     Lambda      |-------+

      |     Switch      |

      |                 |

      |                 |

      +-----------------+

     =20

=20

The node itself is able to cross connect only the Lambda while the =
interface has a OEO transponder that is able to change the lambda =
frequency.  In this case there are two different 'switching capability' =
the spatial one that is performed by the switch (lambda 1, port A) --> =
(lambda1, port B) and the frequency switching is done by the OEO =
transponder.  Witch kind of interface switching capability I have to =
advertise?

=20

BR


Diego

=20

Diego Caviglia

Product Line ON BBN

PA Broadband BNET

=20

Marconi S.p.A

Ericsson Global Product Center - Italy

Via Anagnina,203

0018, Roma , Italy

www.ericsson.com <http://www.ericsson.com/>=20

=20

Office:  [phone]

Fax: [phone]

Mobile: [phone]

Email: [e-mail] =20

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.

E-mail including attachments is susceptible to data corruption, =
interception, unauthorized amendment, tampering and viruses, and we only =
send and receive emails on the basis that we are not liable for any such =
corruption, interception, amendment, tampering or viruses or any =
consequences thereof.

=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

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblue face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:blue;font-weight:bold'=
>Hi
Greg,<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblue face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:blue;font-weight:bold'=
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Yes the interface is a single lambda and then there should be a DWDM =
Line system
or could be as you said a RODAM.<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblue face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:blue;font-weight:bold'=
><o:p>&nbsp;</o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblue face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:blue;font-weight:bold'=
>Great mind
have similar thought </span></font></b><b><font size=3D2 color=3Dblue
face=3DWingdings><span =
style=3D'font-size:10.0pt;font-family:Wingdings;color:blue;
font-weight:bold'>J</span></font></b><b><font size=3D2 color=3Dblue =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:blue;font-weight:bold'=
> </span></font></b><b><font
size=3D2 color=3Dblue face=3DWingdings><span =
style=3D'font-size:10.0pt;font-family:
Wingdings;color:blue;font-weight:bold'>J</span></font></b><b><font =
size=3D2
color=3Dblue face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:blue;font-weight:bold'><o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblue face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:blue;font-weight:bold'=
><o:p>&nbsp;</o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblue face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:blue;font-weight:bold'=
>BR<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblue face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:blue;font-weight:bold'=
><o:p>&nbsp;</o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblue face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:blue;font-weight:bold'=
>Diego<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'><o:p>&nbsp;</o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> Greg Bernstein [mailto:[e-mail]] =
<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> gioved=EC 5 luglio =
2007 18.39<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Diego Caviglia =
(GA/ERI)<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Switching =
Capability
of Photonic Links with Transponder</span></font><font =
color=3Dblack><span
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

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

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Hi Diego, looks like we've been thinking =
about similar
issues lately.<br>
First, I want to nail down the interfaces on your lambda switch =
below.<br>
Are they:<br>
(a) WDM interfaces, i.e., with multiple lambda's coming in and out.<br>
(b) single wavelength interfaces<br>
(c) a combination of the two, e.g., like in a ADM (or ROADM) where we =
have line
side (WDM) and drop side single wavelength.<br>
<br>
On terminology instead of &quot;frequency switching&quot; can we call it =
by its
more typical name &quot;wavelength conversion&quot; to avoid confusion =
with
&quot;lambda switching&quot; (since lambda's and frequencies have a 1-1
correspondence and both are used to describe optical signals in ITU-T
recommendations).<br>
<br>
Given where the OEO is located I'd say that particular interface is a =
single
wavelength.<br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
Diego Caviglia (GA/ERI) wrote: <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'><u1:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"country-region"><u1:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PlaceType"><u1:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PlaceName"><u1:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"State"><u1:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"><u1:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"></u1:SmartTagType></u1:SmartTagType></u1:SmartTagType></u1=
:SmartTagType></u1:SmartTagType></u1:SmartTagType>Hi
all,<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;
I&#8217;ve a doubt about how to model the following =
situation.<u1:p></u1:p></span></font><o:p></o:p></p>

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

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------+<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|-------+<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
| OEO&nbsp;&nbsp; |<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; Lambda&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|-------+<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; Switch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------+<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><u1:p>&nbsp;</u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The node itself is =
able to
cross connect only the Lambda while the interface has a OEO transponder =
that is
able to change the lambda frequency. &nbsp;In this case there are two =
different
&#8216;switching capability&#8217; the spatial one that is performed by =
the
switch (lambda 1, port A) --&gt; (lambda1, port B) and the frequency =
switching
is done by the OEO transponder. &nbsp;Witch kind of interface switching
capability I have to =
advertise?<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><u1:p>&nbsp;</u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>BR<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
Diego<u1:p></u1:p></span></font><o:p></o:p></p>

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dblack =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Diego =
Caviglia</span></font></b></strong><u1:p></u1:p><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial'>Product <st1:place =
u2:st=3D"on"><st1:City u2:st=3D"on"><st1:place
w:st=3D"on"><st1:City w:st=3D"on">Line</st1:City></st1:City> <u3:City =
u4:st=3D"on"><u3:place u4:st=3D"on"><st1:State u2:st=3D"on"><st1:State
 w:st=3D"on">ON</st1:State></u3:place></st1:State></st1:place> =
</u3:City></st1:place>BBN</span></font><o:p></o:p></p>

<u1:p></u1:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial'>PA Broadband =
BNET</span></font><o:p></o:p></p>

<u1:p></u1:p>

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Marconi =
S.p.A</span></font></b></strong><u1:p></u1:p><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Ericsson Global <st1:PlaceName =
u2:st=3D"on"><st1:PlaceName
w:st=3D"on">Product</st1:PlaceName></st1:PlaceName> <st1:PlaceType =
u2:st=3D"on"><st1:PlaceType
w:st=3D"on">Center</st1:PlaceType></st1:PlaceType> - <st1:country-region =
u2:st=3D"on"><st1:place u2:st=3D"on"><st1:country-region
w:st=3D"on"><st1:place =
w:st=3D"on">Italy</st1:place></st1:country-region></st1:place></st1:count=
ry-region></span></font><u1:p></u1:p><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Via =
Anagnina,203</span></font><u1:p></u1:p><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DIT
style=3D'font-size:10.0pt;font-family:Arial'>0018, Roma , =
Italy</span></font><o:p></o:p></p>

<u1:p></u1:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial'><a =
href=3D"http://www.ericsson.com/"
title=3D"http://www.ericsson.com/" moz-do-not-send=3Dtrue><span =
lang=3DIT><span
title=3D"http://www.ericsson.com/">www.ericsson.com</span></span></a></sp=
an></font><o:p></o:p></p>

<u1:p></u1:p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DIT
style=3D'font-size:10.0pt;font-family:Arial'>Office:&nbsp; [phone] =
3736</span></font><o:p></o:p></p>

<u1:p></u1:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DFR
style=3D'font-size:10.0pt;font-family:Arial'>Fax: [phone] =
3493</span></font><o:p></o:p></p>

<u1:p></u1:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DFR
style=3D'font-size:10.0pt;font-family:Arial'>Mobile: +39 335 =
7181762</span></font><o:p></o:p></p>

<u1:p></u1:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DFR
style=3D'font-size:10.0pt;font-family:Arial'>Email: <a
href=3D"mailto:[e-mail]" =
moz-do-not-send=3Dtrue>[e-mail]</a>&nbsp;</span></font=
><span
lang=3DFR>&nbsp;<u1:p></u1:p></span><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D1 color=3Dgray face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:7.5pt;font-family:Arial;color:gray'>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.<br>
<br>
E-mail including attachments is susceptible to data corruption, =
interception,
unauthorized amendment, tampering and viruses, and we only send and =
receive
emails on the basis that we are not liable for any such corruption,
interception, amendment, tampering or viruses or any consequences =
thereof.</span></font><o:p></o:p></p>

<u1:p></u1:p>

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

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

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

</body>

</html>

------_=_NextPart_001_01C7BF9D.407E465A--



Envelope-to: [e-mail]
Delivery-date: Fri, 06 Jul 2007 07:17:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BF9D.5B807536"
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Fri, 6 Jul 2007 09:14:55 +0200
Message-ID: <[e-mail]>
Thread-Topic: Switching Capability of Photonic Links with Transponder
Thread-Index: Ace/JFVnzUcKpKvJSCCBEsSc5rvhNwAePMWw
From: "Diego Caviglia (GA/ERI)" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>
Cc: "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

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

Hi Greg,

             I'll have a look to the ID thanks.

=20

Best regards

=20

Diego

=20

Diego Caviglia

From: Greg Bernstein [mailto:[e-mail]]=20
Sent: gioved=EC 5 luglio 2007 18.49
To: Diego Caviglia (GA/ERI)
Cc: MEURIC Julien RD-CORE-LAN; [e-mail]
Subject: Re: Switching Capability of Photonic Links with Transponder

=20

Hi Diego, looking at MPLS and GMPLS particularly applied to =
SONET/SDH/G.709 we see that most switches are assumed to be able to =
convert any ingress label to any egress label (within say some range).  =
In the case of lambda switching without wavelength converters (your =
O-E-O transponder) we do not have this capability (labels map to =
lambdas). Hence this could also be interpreted as an additional =
constraint on the switch. I don't think we currently have a way to =
represent this in our routing protocols.  Please take a look at the =
draft =
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit=
ched-00.txt  that Young Lee and I put together.  It seems to us that =
some extensions to GMPLS maybe necessary to address your application.  =
If I interpret it correctly ;-)=20

Regards

Greg B.

Diego Caviglia (GA/ERI) wrote:=20

=20

Hi Julien,

          Hmmmmmm not sure my Understanding of the lambda switching is =
what I've called spatial switching that is lambda1 portA --> lambda1 =
portB what is not clear to me is how can be advertised an OEO =
transponder that can only perform frequency switching lambda1 --> lambda =
2.

Adrian? Deb? Anyone else?

BR

Diego

-----Original Message-----
From: MEURIC Julien RD-CORE-LAN =
[mailto:[e-mail]]
Sent: mercoled=EC 4 luglio 2007 18.47
To: Diego Caviglia (GA/ERI); [e-mail]
Subject: RE: Switching Capability of Photonic Links with Transponder

Hi Diego.

I believe we should refer to the Holly RFC 3945, chapter 1, verse 2:

- "Lambda Switch Capable" interfaces "can operate at the level of an =
*individual wavelength*" [or a "group of wavelengths"], meaning that you =
manipulate values of wavelengths (as AU-4 numbers [or AU-4 ranges] from =
an SDH portA to SDH portB), like in a ROADM;

- "Fiber-Switch Capable" interfaces "can operate at the level of a =
single or multiple *fibers*", meaning *spatial switching* where you =
don't consider the type of signal that ports convey (could be anything =
like a black and white signal, a wavelength, a WDM multiplex, some =
optical packets...), like in a OOO PXC.

To stick with strict terminolgy: lambda =3D wavelength =3D (speedOfLight =
/ frequency)

So if you need to do "frequency switching", then it is the so called =
"lambda switching". :-)

Anyway, this is my understanding, so if I'm wrong or if it's a =
vocabulary issue because you find that terms are inappropriate, then =
we'd better ask father Adrian and sister Deborah.

Cheers,

Julien

=20

-----Original Message-----

From: Diego Caviglia (GA/ERI) [mailto:[e-mail]]=20

Hi Julien,

          Actually not the PXC I had in mind is able to switch a single =
lambda I didn't but the mux/demux In the picture sorry.

The point I failed to illustrate is the ambiguity of the term "Lambda =
Switch Capable" given that there two possible ways to switch a lambda. =20

The first one is the spatial one: (Lambda1 portA) --> (Lambda1 portB) =
this is the way an all optical switch works and this why there is the =
lambda continuity constraint in photonic networks. =20

The second one is the frequency switching: (Lambda1 portA) --> (Lambda2 =
portA) this switching can be done via a transponder (OEO) device. =20

Of course is possible to mix the two switching having (Lambda1 portA) =
--> (Lambda2 portB)

My impression is that the definition "Lambda Switch Capable" refers to =
the spatial switching and thus I don't know how to model the fact that =
after/before a photonic matrix I have a transponder. =20

I hope I've made my question clearer.

Best Regards

Diego

-----Original Message-----

From: MEURIC Julien RD-CORE-LAN =
[mailto:[e-mail]]=20

Sent: marted=EC 3 luglio 2007 19.21

To: Diego Caviglia (GA/ERI); [e-mail]

Subject: RE: Switching Capability of Photonic Links with Transponder

Hi Diego.

If I understand correctly, your "lambda switch" by itself is a PXC that

has only "Fiber-Switch Capable" interfaces. Then, you add

lambda-conversion cards to it. So, correct me if I'm wrong (you or

anyone else), but whether you do a lambda conversion inside a card or in

a core matrix, this new interface on your global device is able to work

on lambdas anyway  [(lambda 1, port A) --> (lambda2, port B)]. As a

result, you need to advertise your most flexible capability, which is

"Lambda Switch Capable".

If you used "FSC", you wouldn't be able to control your "lambda

swapping" card, as LSPs are like lists of fibers and labels aren't

wavelengths but ports.

But maybe I didn't get your actual issue.

My 2 cents,

Julien

________________________________

From: [e-mail] [mailto:[e-mail]] On

Behalf Of Diego Caviglia (GA/ERI)

Hi all,

         I've a doubt about how to model the following situation.

=20

=20

=20

      +-----------------+

      |                 |-------+

      |                 | OEO   |

      |     Lambda      |-------+

      |     Switch      |

      |                 |

      |                 |

      +-----------------+

     =20

=20

The node itself is able to cross connect only the Lambda while the

interface has a OEO transponder that is able to change the lambda

frequency.  In this case there are two different 'switching capability'

the spatial one that is performed by the switch (lambda 1, port A) -->

(lambda1, port B) and the frequency switching is done by the OEO

transponder.  Witch kind of interface switching capability I have to

advertise?

=20

BR

=20

Diego

=20

Diego Caviglia

Product Line ON BBN

PA Broadband BNET

=20

Marconi S.p.A

Ericsson Global Product Center - Italy

Via Anagnina,203

0018, Roma , Italy

www.ericsson.com <http://www.ericsson.com/>=20

=20

Office:  [phone]

Fax: [phone]

Mobile: [phone]

Email: [e-mail] =20

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.

E-mail including attachments is susceptible to data corruption,

interception, unauthorized amendment, tampering and viruses, and we only

send and receive emails on the basis that we are not liable for any such

corruption, interception, amendment, tampering or viruses or any

consequences thereof.

=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

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<title>RE: Switching Capability of Photonic Links with =
Transponder</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 I&#8217;ll have a look to the
ID thanks.<o:p></o:p></span></font></p>

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

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

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

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dblack =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Diego =
Caviglia</span></font></b></strong></u1:PersonName><font
color=3Dblack><span =
style=3D'color:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> Greg Bernstein [mailto:[e-mail]] =
<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> gioved=EC 5 luglio =
2007 18.49<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Diego Caviglia =
(GA/ERI)<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> MEURIC Julien =
RD-CORE-LAN;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Switching =
Capability
of Photonic Links with Transponder</span></font><font =
color=3Dblack><span
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

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

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Hi Diego, looking at MPLS and GMPLS =
particularly
applied to SONET/SDH/G.709 we see that most switches are assumed to be =
able to convert
any ingress label to any egress label (within say some range).&nbsp; In =
the
case of lambda switching without wavelength converters (your O-E-O =
transponder)
we do not have this capability (labels map to lambdas). Hence this could =
also
be interpreted as an additional constraint on the switch. I don't think =
we
currently have a way to represent this in our routing protocols.&nbsp; =
Please
take a look at the draft <a
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelen=
gth-switched-00.txt">http://www.ietf.org/internet-drafts/draft-bernstein-=
ccamp-wavelength-switched-00.txt</a>&nbsp;
that Young Lee and I put together.&nbsp; It seems to us that some =
extensions to
GMPLS maybe necessary to address your application.&nbsp; If I interpret =
it
correctly <span class=3Dmoz-smiley-s3>;-) </span><br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
Diego Caviglia (GA/ERI) wrote: <o:p></o:p></span></font></p>

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

<!-- Converted from text/rtf format -->

<p><a name=3D"" moz-do-not-send=3Dtrue><font size=3D2 color=3Dblack =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Hi =
Julien,</span></font></a><o:p></o:p></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;
Hmmmmmm not sure my Understanding of the lambda switching is what =
I&#8217;ve
called spatial switching that is lambda1 portA </span></font><font
face=3DWingdings><span style=3D'font-family:Wingdings'>=E0</span></font> =
lambda1
portB what is not clear to me is how can be advertised an OEO =
transponder that
can only perform frequency switching lambda1 <font =
face=3DWingdings><span
style=3D'font-family:Wingdings'>=E0</span></font> lambda =
2.<o:p></o:p></p>

<p><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font size=3D3 =
color=3Dblack
  face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Adrian</span></font></st1:place></st1:City>?
Deb? Anyone else?<o:p></o:p></p>

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

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Diego</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>-----Original Message-----<br>
From: MEURIC Julien RD-CORE-LAN [<a
href=3D"mailto:[e-mail]" =
moz-do-not-send=3Dtrue>mailto:[e-mail]</a>]<br>
Sent: mercoled=EC 4 luglio 2007 18.47<br>
To: Diego Caviglia (GA/ERI); <a =
href=3D"mailto:[e-mail]">[e-mail]</a><br>
Subject: RE: Switching Capability of Photonic Links with =
Transponder</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Hi Diego.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>I believe we should refer to the Holly RFC =
3945,
chapter 1, verse 2:</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>- &quot;Lambda Switch Capable&quot; =
interfaces
&quot;can operate at the level of an *individual wavelength*&quot; [or a
&quot;group of wavelengths&quot;], meaning that you manipulate values of
wavelengths (as AU-4 numbers [or AU-4 ranges] from an SDH portA to SDH =
portB),
like in a ROADM;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>- &quot;Fiber-Switch Capable&quot; interfaces
&quot;can operate at the level of a single or multiple *fibers*&quot;, =
meaning
*spatial switching* where you don't consider the type of signal that =
ports
convey (could be anything like a black and white signal, a wavelength, a =
WDM
multiplex, some optical packets...), like in a OOO =
PXC.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>To stick with strict terminolgy: lambda =3D =
wavelength
=3D (speedOfLight / frequency)</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>So if you need to do &quot;frequency
switching&quot;, then it is the so called &quot;lambda switching&quot;. =
:-)</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Anyway, this is my understanding, so if I'm =
wrong or
if it's a vocabulary issue because you find that terms are =
inappropriate, then
we'd better ask father Adrian and sister =
Deborah.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Cheers,</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Julien</span></font><o:p></o:p></p>

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

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>-----Original =
Message-----</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>From: Diego Caviglia (GA/ERI) [<a
href=3D"mailto:[e-mail]" =
moz-do-not-send=3Dtrue>mailto:[e-mail]</a>]
</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Hi Julien,</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Actually not the PXC I had in mind is able to switch a single lambda I =
didn't
but the mux/demux In the picture sorry.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>The point I failed to illustrate is the =
ambiguity of
the term &quot;Lambda Switch Capable&quot; given that there two possible =
ways
to switch a lambda.&nbsp; </span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>The first one is the spatial one: (Lambda1 =
portA) --&gt;
(Lambda1 portB) this is the way an all optical switch works and this why =
there
is the lambda continuity constraint in photonic networks.&nbsp; =
</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>The second one is the frequency switching: =
(Lambda1
portA) --&gt; (Lambda2 portA) this switching can be done via a =
transponder
(OEO) device.&nbsp; </span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Of course is possible to mix the two =
switching
having (Lambda1 portA) --&gt; (Lambda2 =
portB)</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>My impression is that the definition =
&quot;Lambda
Switch Capable&quot; refers to the spatial switching and thus I don't =
know how
to model the fact that after/before a photonic matrix I have a
transponder.&nbsp; </span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>I hope I've made my question =
clearer.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Best Regards</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Diego</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>-----Original =
Message-----</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>From: MEURIC Julien RD-CORE-LAN [<a
href=3D"mailto:[e-mail]" =
moz-do-not-send=3Dtrue>mailto:[e-mail]</a>]
</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Sent: marted=EC 3 luglio 2007 =
19.21</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>To: Diego Caviglia (GA/ERI); <a
href=3D"mailto:[e-mail]">[e-mail]</a></span></font><o=
:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Subject: RE: Switching Capability of Photonic =
Links
with Transponder</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Hi Diego.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>If I understand correctly, your &quot;lambda
switch&quot; by itself is a PXC that</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>has only &quot;Fiber-Switch Capable&quot;
interfaces. Then, you add</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>lambda-conversion cards to it. So, correct me =
if I'm
wrong (you or</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>anyone else), but whether you do a lambda =
conversion
inside a card or in</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>a core matrix, this new interface on your =
global
device is able to work</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>on lambdas anyway&nbsp; [(lambda 1, port A) =
--&gt;
(lambda2, port B)]. As a</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>result, you need to advertise your most =
flexible
capability, which is</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&quot;Lambda Switch =
Capable&quot;.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>If you used &quot;FSC&quot;, you wouldn't be =
able to
control your &quot;lambda</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>swapping&quot; card, as LSPs are like lists =
of
fibers and labels aren't</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>wavelengths but =
ports.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>But maybe I didn't get your actual =
issue.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>My 2 cents,</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Julien</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier =
New"'>________________________________</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>From: <a =
href=3D"mailto:[e-mail]">[e-mail]</a>
[<a href=3D"mailto:[e-mail]" =
moz-do-not-send=3Dtrue>mailto:[e-mail]</a>]
On</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Behalf Of Diego Caviglia =
(GA/ERI)</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Hi all,</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
I've a doubt about how to model the following =
situation.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+-----------------+</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|-------+</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
| OEO&nbsp;&nbsp; |</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; Lambda&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|-------+</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; Switch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+-----------------+</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>The node itself is able to cross connect only =
the
Lambda while the</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>interface has a OEO transponder that is able =
to
change the lambda</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>frequency.&nbsp; In this case there are two
different 'switching capability'</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>the spatial one that is performed by the =
switch
(lambda 1, port A) --&gt;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>(lambda1, port B) and the frequency switching =
is
done by the OEO</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>transponder.&nbsp; Witch kind of interface =
switching
capability I have to</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>advertise?</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>BR</span></font><o:p></o:p></p>

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

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Diego</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Diego Caviglia</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Product <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Line</st1:City>
 <st1:State w:st=3D"on">ON</st1:State></st1:place> =
BBN</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>PA Broadband =
BNET</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Marconi S.p.A</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Ericsson Global <st1:PlaceName =
w:st=3D"on">Product</st1:PlaceName>
<st1:PlaceType w:st=3D"on">Center</st1:PlaceType> - <st1:country-region =
w:st=3D"on"><st1:place
 =
w:st=3D"on">Italy</st1:place></st1:country-region></span></font><o:p></o:=
p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Via Anagnina,203</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>0018, Roma , <st1:country-region =
w:st=3D"on"><st1:place
 =
w:st=3D"on">Italy</st1:place></st1:country-region></span></font><o:p></o:=
p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><a =
href=3D"http://www.ericsson.com">www.ericsson.com</a>
&lt;<a href=3D"http://www.ericsson.com/" =
moz-do-not-send=3Dtrue>http://www.ericsson.com/</a>&gt;
</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Office:&nbsp; [phone] =
3736</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Fax: [phone] =
3493</span></font><o:p></o:p></p>

<p><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font size=3D2 =
color=3Dblack
  face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Mobile</span></font></st1:place></st1:City><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>:
[phone]</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Email: <a =
href=3D"mailto:[e-mail]">[e-mail]</=
a>&nbsp;
</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>This communication is confidential and =
intended
solely for the</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>addressee(s). Any unauthorized review, use,
disclosure or distribution</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>is prohibited. If you believe this message =
has been
sent to you in</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>error, please notify the sender by replying =
to this
transmission and</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>delete the message without disclosing it. =
Thank you.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>E-mail including attachments is susceptible =
to data
corruption,</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>interception, unauthorized amendment, =
tampering and
viruses, and we only</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>send and receive emails on the basis that we =
are not
liable for any such</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>corruption, interception, amendment, =
tampering or
viruses or any</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>consequences =
thereof.</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font><o:p></o:p></p>

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

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

</body>

</html>

------_=_NextPart_001_01C7BF9D.5B807536--



Envelope-to: [e-mail]
Delivery-date: Fri, 06 Jul 2007 01:12:23 +0000
Date: Fri, 06 Jul 2007 10:10:16 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: new draft about signaling for a bidirectionl lightpath
From: Hiroaki Harai <[e-mail]>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi everyone,

We posted a new draft about GMPLS signaling for a bidirectional
lightpath setup as follows.
http://www.ietf.org/internet-drafts/draft-xu-rsvpte-bidir-wave-00.txt

======
Title   : Extensions to GMPLS RSVP-TE for Bidirectional Lightpath with
          the Same Wavelength
Authors : S. Xu, H. Harai, and D. King
Filename: draft-xu-rsvpte-bidir-wave-00.txt
	
Abstract: For bidirectional lightpaths provisioning, in the case of
optical nodes that do not support wavelength conversion, it would be
necessary to use the same wavelength along the route on each
direction. In certain optical network scenarios, the use of the same
wavelength on both directions would be advantageous.  For instance,
some type of ROADMs may add/drop the same wavelength
simultaneously. In another case, the users' optical end nodes are
equipped with fixed-wavelength transponders.

This document describes extensions to RSVP-TE signaling for 
bidirectional wavelength lightpaths that require the same wavelength on 
both directions. By using an LSP_ATTRIBUTES object defined in [RFC4420], 
the extensions enable the new type lightpaths to support the low cost 
configuration at users' optical end nodes.
======

We believe that selecting a single wavelength on both directions for a
bidirectional LSP is very real. And our suggestion in this draft is a
simple one.

We appreciate your comments and feedbacks.

With best regards,
Hiroaki

-------
Hiroaki Harai, Ph.D. (http://nag.nict.go.jp/)
Network Architecture Group, New Generation Network Research Center
National Institute of Information and Communications Technology (NICT), JAPAN.
Email: [e-mail];  Phone: [phone];  FAX: [phone]



Envelope-to: [e-mail]
Delivery-date: Fri, 06 Jul 2007 01:08:50 +0000
Message-ID: <015b01c7bf52$ff29c720$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Liaison situation
Date: Thu, 5 Jul 2007 23:22:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I have been a bit lax about following up with liaisons.

The CCAMP correspondence page at www.olddog.co.uk/ccamp.htm has been updated 
to show all of the recent incoming and outgoing correspondence.

We send a bunch of responses to the ITU-T in April and May, and these have 
generated some responses that need our attention. In addition, we have a 
couple of response that we need to generate that we have started on, but 
need to complete.

We need to send responses on

- VCAT/LCAS
   https://datatracker.ietf.org/documents/LIAISON/file418.doc
  Greg drafted some text.
  We need to polish it and send it.

- Multi-layer networking
  https://datatracker.ietf.org/documents/LIAISON/file432.doc
  Specific questions we should address before WG last call

- ASON routing loop prevention
  https://datatracker.ietf.org/documents/LIAISON/file448.doc
  More discussion about the OSPF solution

- GMPLS Calls
   https://datatracker.ietf.org/documents/LIAISON/file450.doc
   A couple of points to consider when we apply this work to ASON

- OTN-T work plan
   https://datatracker.ietf.org/documents/LIAISON/file451.doc
   For out comments

We should also send a liaison to update on the progress of OSPF ASON 
routing.

Any help would be welcomed.

Adrian 





Envelope-to: [e-mail]
Delivery-date: Thu, 05 Jul 2007 22:18:01 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt 
Message-Id: <[e-mail]>
Date: Thu, 05 Jul 2007 18:15:02 -0400

--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		: Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks
	Author(s)	: K. Kumaki
	Filename	: draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt
	Pages		: 13
	Date		: 2007-7-5
	
Operation of an Multiprotocol Label Switching (MPLS) traffic 
   engineering (TE) network as a client network to a Generalized MPLS 
   (GMPLS) network has enhanced operational capabilities compared to 
   those provided by a co-existent protocol model (ships in the night). 
    
   The GMPLS network may be a packet or a non-packet network, and may 
   itself be a multi-layer network supporting both packet and non-packet 
   technologies. A MPLS-TE Label Switched Path (LSP) originates and 
   terminates on an MPLS Label Switching Router (LSR). The GMPLS network 
   provides transp   This document describes a framework and Service Provider requirements 
   for operating MPLS-TE networks over GMPLS networks. 
arent transport for the end-to-end MPLS-TE LSP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Thu, 05 Jul 2007 16:55:03 +0000
Message-ID: <[e-mail]>
Date: Thu, 05 Jul 2007 09:48:30 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: "Diego Caviglia (GA/ERI)" <[e-mail]>
CC: MEURIC Julien RD-CORE-LAN <[e-mail]>, [e-mail]
Subject: Re: Switching Capability of Photonic Links with Transponder
Content-Type: multipart/alternative; boundary="------------030503060300070107070602"

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

Hi Diego, looking at MPLS and GMPLS particularly applied to 
SONET/SDH/G.709 we see that most switches are assumed to be able to 
convert any ingress label to any egress label (within say some range).  
In the case of lambda switching without wavelength converters (your 
O-E-O transponder) we do not have this capability (labels map to 
lambdas). Hence this could also be interpreted as an additional 
constraint on the switch. I don't think we currently have a way to 
represent this in our routing protocols.  Please take a look at the 
draft 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-00.txt  
that Young Lee and I put together.  It seems to us that some extensions 
to GMPLS maybe necessary to address your application.  If I interpret it 
correctly ;-)

Regards

Greg B.

Diego Caviglia (GA/ERI) wrote:
>
> Hi Julien,
>
>           Hmmmmmm not sure my Understanding of the lambda switching is 
> what I've called spatial switching that is lambda1 portA à lambda1 
> portB what is not clear to me is how can be advertised an OEO 
> transponder that can only perform frequency switching lambda1 à lambda 2.
>
> Adrian? Deb? Anyone else?
>
> BR
>
> Diego
>
> -----Original Message-----
> From: MEURIC Julien RD-CORE-LAN [mailto:[e-mail]]
> Sent: mercoledì 4 luglio 2007 18.47
> To: Diego Caviglia (GA/ERI); [e-mail]
> Subject: RE: Switching Capability of Photonic Links with Transponder
>
> Hi Diego.
>
> I believe we should refer to the Holly RFC 3945, chapter 1, verse 2:
>
> - "Lambda Switch Capable" interfaces "can operate at the level of an 
> *individual wavelength*" [or a "group of wavelengths"], meaning that 
> you manipulate values of wavelengths (as AU-4 numbers [or AU-4 ranges] 
> from an SDH portA to SDH portB), like in a ROADM;
>
> - "Fiber-Switch Capable" interfaces "can operate at the level of a 
> single or multiple *fibers*", meaning *spatial switching* where you 
> don't consider the type of signal that ports convey (could be anything 
> like a black and white signal, a wavelength, a WDM multiplex, some 
> optical packets...), like in a OOO PXC.
>
> To stick with strict terminolgy: lambda = wavelength = (speedOfLight / 
> frequency)
>
> So if you need to do "frequency switching", then it is the so called 
> "lambda switching". :-)
>
> Anyway, this is my understanding, so if I'm wrong or if it's a 
> vocabulary issue because you find that terms are inappropriate, then 
> we'd better ask father Adrian and sister Deborah.
>
> Cheers,
>
> Julien
>
>
> -----Original Message-----
>
> From: Diego Caviglia (GA/ERI) [mailto:[e-mail]]
>
> Hi Julien,
>
>           Actually not the PXC I had in mind is able to switch a 
> single lambda I didn't but the mux/demux In the picture sorry.
>
> The point I failed to illustrate is the ambiguity of the term "Lambda 
> Switch Capable" given that there two possible ways to switch a lambda. 
>
> The first one is the spatial one: (Lambda1 portA) --> (Lambda1 portB) 
> this is the way an all optical switch works and this why there is the 
> lambda continuity constraint in photonic networks. 
>
> The second one is the frequency switching: (Lambda1 portA) --> 
> (Lambda2 portA) this switching can be done via a transponder (OEO) 
> device. 
>
> Of course is possible to mix the two switching having (Lambda1 portA) 
> --> (Lambda2 portB)
>
> My impression is that the definition "Lambda Switch Capable" refers to 
> the spatial switching and thus I don't know how to model the fact that 
> after/before a photonic matrix I have a transponder. 
>
> I hope I've made my question clearer.
>
> Best Regards
>
> Diego
>
> -----Original Message-----
>
> From: MEURIC Julien RD-CORE-LAN [mailto:[e-mail]]
>
> Sent: martedì 3 luglio 2007 19.21
>
> To: Diego Caviglia (GA/ERI); [e-mail]
>
> Subject: RE: Switching Capability of Photonic Links with Transponder
>
> Hi Diego.
>
> If I understand correctly, your "lambda switch" by itself is a PXC that
>
> has only "Fiber-Switch Capable" interfaces. Then, you add
>
> lambda-conversion cards to it. So, correct me if I'm wrong (you or
>
> anyone else), but whether you do a lambda conversion inside a card or in
>
> a core matrix, this new interface on your global device is able to work
>
> on lambdas anyway  [(lambda 1, port A) --> (lambda2, port B)]. As a
>
> result, you need to advertise your most flexible capability, which is
>
> "Lambda Switch Capable".
>
> If you used "FSC", you wouldn't be able to control your "lambda
>
> swapping" card, as LSPs are like lists of fibers and labels aren't
>
> wavelengths but ports.
>
> But maybe I didn't get your actual issue.
>
> My 2 cents,
>
> Julien
>
> ________________________________
>
> From: [e-mail] [mailto:[e-mail]] On
>
> Behalf Of Diego Caviglia (GA/ERI)
>
> Hi all,
>
>          I've a doubt about how to model the following situation.
>
>  
>
>  
>
>  
>
>       +-----------------+
>
>       |                 |-------+
>
>       |                 | OEO   |
>
>       |     Lambda      |-------+
>
>       |     Switch      |
>
>       |                 |
>
>       |                 |
>
>       +-----------------+
>
>      
>
>  
>
> The node itself is able to cross connect only the Lambda while the
>
> interface has a OEO transponder that is able to change the lambda
>
> frequency.  In this case there are two different 'switching capability'
>
> the spatial one that is performed by the switch (lambda 1, port A) -->
>
> (lambda1, port B) and the frequency switching is done by the OEO
>
> transponder.  Witch kind of interface switching capability I have to
>
> advertise?
>
>  
>
> BR
>
>
> Diego
>
>  
>
> Diego Caviglia
>
> Product Line ON BBN
>
> PA Broadband BNET
>
>  
>
> Marconi S.p.A
>
> Ericsson Global Product Center - Italy
>
> Via Anagnina,203
>
> 0018, Roma , Italy
>
> www.ericsson.com <http://www.ericsson.com/>
>
>  
>
> Office:  [phone]
>
> Fax: [phone]
>
> Mobile: [phone]
>
> Email: [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.
>
> E-mail including attachments is susceptible to data corruption,
>
> interception, unauthorized amendment, tampering and viruses, and we only
>
> send and receive emails on the basis that we are not liable for any such
>
> corruption, interception, amendment, tampering or viruses or any
>
> consequences thereof.
>
>  
>

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



--------------030503060300070107070602
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, looking at MPLS and GMPLS particularly applied to
SONET/SDH/G.709 we see that most switches are assumed to be able to
convert any ingress label to any egress label (within say some range).&nbsp;
In the case of lambda switching without wavelength converters (your
O-E-O transponder) we do not have this capability (labels map to
lambdas). Hence this could also be interpreted as an additional
constraint on the switch. I don't think we currently have a way to
represent this in our routing protocols.&nbsp; Please take a look at the
draft <a class="moz-txt-link-freetext"
 href="http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-00.txt">http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-00.txt</a>&nbsp;
that Young Lee and I put together.&nbsp; It seems to us that some extensions
to GMPLS maybe necessary to address your application.&nbsp; If I interpret
it correctly <span class="moz-smiley-s3"><span> ;-) </span></span><br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
Diego Caviglia (GA/ERI) wrote:
<blockquote
 cite="mid:[e-mail]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 6.5.7652.24">
  <title>RE: Switching Capability of Photonic Links with Transponder</title>
<!-- Converted from text/rtf format -->
  <br>
  <p align="left"><span lang="en-us"></span><a moz-do-not-send="true"
 name=""><span lang="en-us"><font face="Courier New" size="2">Hi Julien,</font></span></a></p>
  <p align="left"><span lang="en-us">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hmmmmmm not sure my</span><span
 lang="en-us"> Understanding of the lambda switching is what I&#8217;ve
called spatial switching that is lambda1 portA <font face="Wingdings"
 size="3">&agrave;</font></span><span lang="en-us"></span><span lang="en-us">
lambda1 portB what is not clear to me is how can be advertised an OEO
transponder that can only perform frequency switching lambda1 <font
 face="Wingdings" size="3">&agrave;</font></span><span lang="en-us"></span><span
 lang="en-us"> lambda 2.</span></p>
  <p align="left"><span lang="en-us">Adrian? Deb? Anyone else?</span></p>
  <p align="left"><span lang="en-us">BR</span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Diego</font></span><span
 lang="en-us"></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">-----Original
Message-----<br>
From: MEURIC Julien RD-CORE-LAN [<a moz-do-not-send="true"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]<br>
Sent: mercoled&igrave; 4 luglio 2007 18.47<br>
To: Diego Caviglia (GA/ERI); <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a><br>
Subject: RE: Switching Capability of Photonic Links with Transponder</font></span><span
 lang="en-us"></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Hi
Diego.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">I
believe we should refer to the Holly RFC 3945, chapter 1, verse 2:</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">-
"Lambda Switch Capable" interfaces "can operate at the level of an
*individual wavelength*" [or a "group of wavelengths"], meaning that
you manipulate values of wavelengths (as AU-4 numbers [or AU-4 ranges]
from an SDH portA to SDH portB), like in a ROADM;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">-
"Fiber-Switch Capable" interfaces "can operate at the level of a single
or multiple *fibers*", meaning *spatial switching* where you don't
consider the type of signal that ports convey (could be anything like a
black and white signal, a wavelength, a WDM multiplex, some optical
packets...), like in a OOO PXC.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">To
stick with strict terminolgy: lambda = wavelength = (speedOfLight /
frequency)</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">So
if you need to do "frequency switching", then it is the so called
"lambda switching". :-)</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Anyway,
this is my understanding, so if I'm wrong or if it's a vocabulary issue
because you find that terms are inappropriate, then we'd better ask
father Adrian and sister Deborah.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Cheers,</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Julien</font></span></p>
  <br>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">-----Original
Message-----</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">From:
Diego Caviglia (GA/ERI) [<a moz-do-not-send="true"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
  </font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Hi
Julien,</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Actually not the PXC I had in mind is able to switch a single lambda I
didn't but the mux/demux In the picture sorry.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">The
point I failed to illustrate is the ambiguity of the term "Lambda
Switch Capable" given that there two possible ways to switch a lambda.&nbsp;
  </font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">The
first one is the spatial one: (Lambda1 portA) --&gt; (Lambda1 portB)
this is the way an all optical switch works and this why there is the
lambda continuity constraint in photonic networks.&nbsp; </font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">The
second one is the frequency switching: (Lambda1 portA) --&gt; (Lambda2
portA) this switching can be done via a transponder (OEO) device.&nbsp; </font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Of
course is possible to mix the two switching having (Lambda1 portA)
--&gt; (Lambda2 portB)</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">My
impression is that the definition "Lambda Switch Capable" refers to the
spatial switching and thus I don't know how to model the fact that
after/before a photonic matrix I have a transponder.&nbsp; </font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">I
hope I've made my question clearer.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Best
Regards</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Diego</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">-----Original
Message-----</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">From:
MEURIC Julien RD-CORE-LAN [<a moz-do-not-send="true"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
  </font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Sent:
marted&igrave; 3 luglio 2007 19.21</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">To:
Diego Caviglia (GA/ERI); <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a></font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Subject:
RE: Switching Capability of Photonic Links with Transponder</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Hi
Diego.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">If
I understand correctly, your "lambda switch" by itself is a PXC that</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">has
only "Fiber-Switch Capable" interfaces. Then, you add</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">lambda-conversion
cards to it. So, correct me if I'm wrong (you or</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">anyone
else), but whether you do a lambda conversion inside a card or in</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">a
core matrix, this new interface on your global device is able to work</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">on
lambdas anyway&nbsp; [(lambda 1, port A) --&gt; (lambda2, port B)]. As a</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">result,
you need to advertise your most flexible capability, which is</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">"Lambda
Switch Capable".</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">If
you used "FSC", you wouldn't be able to control your "lambda</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">swapping"
card, as LSPs are like lists of fibers and labels aren't</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">wavelengths
but ports.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">But
maybe I didn't get your actual issue.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">My
2 cents,</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Julien</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">________________________________</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">From:
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> [<a moz-do-not-send="true"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
On</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Behalf
Of Diego Caviglia (GA/ERI)</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Hi
all,</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
I've a doubt about how to model the following situation.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------+</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |-------+</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | OEO&nbsp;&nbsp; |</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; Lambda&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |-------+</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; Switch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------+</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  </font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">The
node itself is able to cross connect only the Lambda while the</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">interface
has a OEO transponder that is able to change the lambda</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">frequency.&nbsp;
In this case there are two different 'switching capability'</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">the
spatial one that is performed by the switch (lambda 1, port A) --&gt;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">(lambda1,
port B) and the frequency switching is done by the OEO</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">transponder.&nbsp;
Witch kind of interface switching capability I have to</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">advertise?</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">BR</font></span></p>
  <br>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Diego</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Diego
Caviglia</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Product
Line ON BBN</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">PA
Broadband BNET</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Marconi
S.p.A</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Ericsson
Global Product Center - Italy</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Via
Anagnina,203</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">0018,
Roma , Italy</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2"><a class="moz-txt-link-abbreviated" href="http://www.ericsson.com">www.ericsson.com</a>
&lt;<a moz-do-not-send="true" href="http://www.ericsson.com/">http://www.ericsson.com/</a>&gt;
  </font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Office:&nbsp;
[phone]</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Fax:
[phone]</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Mobile:
[phone]</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Email:
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>&nbsp; </font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">This
communication is confidential and intended solely for the</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">addressee(s).
Any unauthorized review, use, disclosure or distribution</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">is
prohibited. If you believe this message has been sent to you in</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">error,
please notify the sender by replying to this transmission and</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">delete
the message without disclosing it. Thank you.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">E-mail
including attachments is susceptible to data corruption,</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">interception,
unauthorized amendment, tampering and viruses, and we only</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">send
and receive emails on the basis that we are not liable for any such</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">corruption,
interception, amendment, tampering or viruses or any</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">consequences
thereof.</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">&nbsp;</font></span></p>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]

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

--------------030503060300070107070602--



Envelope-to: [e-mail]
Delivery-date: Thu, 05 Jul 2007 16:53:29 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BF23.0096A019"
Subject: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Date: Thu, 5 Jul 2007 12:39:04 -0400
Message-ID: <[e-mail]>
Thread-Topic: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Thread-Index: Ace/Iv/wATkVETcSTT+CAQmeajDxfg==
From: "Zafar Ali \(zali\)" <[e-mail]>
To: "Lou Berger" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Hassan Sheikh \(hassans\)" <[e-mail]>, "Tomohiro Otani" <[e-mail]>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14939; t=1183653569; x=1184517569; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20<[e-mail]> |Subject:=20Follow-up=20on=20comments=20on=20draft-ali-arp-over-gmpls-con trolled-ethernet-psc-i-03.txt |Sender:=20; bh=BxmDQ3+vYlbl2VFX4N1ixDI5PWN/D7LwvfooVtXU9OE=; b=lP4N0PongHWw9/aEFxNAnbJLTVfTdO9ZJgNiDIjb7O+zfRsk2ALlvMh83RxhfZHcCtwV1T6Q URa9iK2lRGuBmSGXhzu8ksrb+vVWrYQbTyXOizcnYU3TT+kooP0SXoHI;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass (si g from cisco.com/sjdkim3002 verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7BF23.0096A019
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Lou, Igor, ccamper, et al,=20
=20
Here is a follow-up on our AI from last WG meeting on the comments
received on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt.
We are planning to revise the document based on your feedback. Please
advise if you have any further comment/ suggestion.=20
=20
The issue is focused around the use of the GMPLS tunnel as a
point-to-point link using Ethernet TE links. Unlike pos links where a L2
adjacency resolution is not required, the Ethernet links require that
the ARP be resolved (aka Layer 2 MAC address) before any forwarding
works on this link. It is not a case of broken implementation. We
(router vendors) cannot work around ARP. What we need to do is to
provide clear direction or recommendation for vendors on how to ARP for
GMPLS controlled Ethernet interfaces. Or else, all vendors will
implement whatever ARP mechanism works for them in terms of forwarding.
E.g., there is an interop issue between Juniper and Cisco (from a fwding
perspective) when Ethernet links are used (Both do ARP). We had to find
workarounds to make things work (at ISO Core and in private testing).
The same will be the case between Cisco, Juniper and other vendors.=20
=20
The solution we are pushing for is that we need a mechanism that allows
us to resolve ARP directly for the GMPLS tunnel ip addresses. This
removes any dependency on the underlying Ethernet links or the
addressing scheme that is used for TE links i.e. numbered links in the
same or different subnets.
=20
In the following, we describe the situation with numbered Ethernet links
and Unnumbered Ethernet links (the assumption is that the GMPLS tunnel
is a ipv4 numbered link in both instances).
=20
Consider the scenario=20
=20
<----------------------------------------------GMPLS
Tunnel------------------------------------------>
=20
RTR1 <------GE data link/TE link -----> OXC <------ GE data link/TE link
-----> RTR2
                  segment # 1                                   segment
# 2
There are two instance to consider:
=20
(a) When numbered TE links are used but segment # 1 and segment # 2 are
in different subnets (valid scenario)
     In this situation we really have no way of resolving ARP using the
addresses of the underlying TE link Ethernet links w/o using static ARP
entries. The issue is that the subnets are different so the ARP request
received by RTR2 from RTR1 will be rejected as it is not known to RTR2
and vice versa. Instead, if the ARP request if for the GMPLS tunnel
instead then there should be no problem as the GMPLS tunnel is p-p link
with IPV4 addresses in the same subnet.
Verdict: If we have the ARP resolution mechanism tied in to the GMPLS
tunnel interfaces addresses then there is no issue or dependency=20
=20
(a) When numbered TE links are used and segment # 1 and segment # 2 are
in the same subnet.=20
     In this setup the GMPLS Tunnel can inherit and use the ethernet
link address for ARP resolution and there is no issue as both segments
are in the same subnet. The problem in this situation is that we need to
resolve the ARP for the ipv4 addresses for the GMPLS tunnel (considered
as a p-p link) as opposed to inherit it from the underlying Ethernet TE
links.
Verdict:  In this situation the ARP resolution mechanism should be
developed for the GMPLS tunnel address.
=20
(c) The third scenario is when the GMPLS tunnel is numbered but the TE
links are Unnumbered.
     In this case we are again faced with the same issue of L2 ARP
adjacency resolution between RTR1 and RTR2. RTR2 will reject the ARP
request for RTR1 when it does not find the Unnumbered address (used by
RTR1) in its FWDing database. This issue would not be encountered if we
were resolving the ARP on GMPLS tunnel address.
Verdict: ARP resolution mechanism is required for GMPLS tunnel.
=20
(d) We also need to make sure that when the tunnel-id is unnum, vendor
implementation honor ARP request using loopback addresses. We have also
faced interop issue in this scenario.=20
=20
Thanks
=20
Regards... Hassan and Zafar=20

------_=_NextPart_001_01C7BF23.0096A019
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1561" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D097161016-05072007>Hi =
Lou, Igor,=20
ccamper, et al, </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D097161016-05072007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D097161016-05072007>Here =
is a follow-up=20
on our AI from last WG meeting on the comments received on=20
draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt. We are =
planning to=20
revise the document based on your feedback. Please advise if you have =
any=20
further comment/ suggestion. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D097161016-05072007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D097161016-05072007><FONT face=3DArial =
size=3D2><SPAN=20
class=3D031093514-05072007>The issue is focused around the use of the =
GMPLS=20
tunnel&nbsp;as a point-to-point link using Ethernet TE links. Unlike pos =
links=20
where a L2 adjacency resolution is not required, the Ethernet links =
require that=20
the ARP be resolved (aka Layer 2 MAC address) before any forwarding =
works on=20
this link. <SPAN class=3D031093514-05072007><SPAN=20
class=3D097161016-05072007>I</SPAN>t is not a&nbsp;<SPAN=20
class=3D097161016-05072007>case of </SPAN>broken implementation<SPAN=20
class=3D097161016-05072007>. We (router vendors) cannot work around ARP. =
What we=20
need to do is to provide&nbsp;</SPAN>clear direction or recommendation =
for=20
vendors<SPAN class=3D097161016-05072007> on how to ARP for GMPLS =
controlled=20
Ethernet interfaces</SPAN>.&nbsp;<SPAN class=3D097161016-05072007>Or =
else,=20
a</SPAN>ll vendors will implement whatever ARP mechanism </SPAN><SPAN=20
class=3D031093514-05072007>works for them in terms of =
forwarding.&nbsp;E.g., there=20
is&nbsp;<SPAN class=3D097161016-05072007>an </SPAN>interop&nbsp;<SPAN=20
class=3D097161016-05072007>issue </SPAN>between Juniper and Cisco (from =
a fwding=20
perspective) when</SPAN><SPAN class=3D031093514-05072007> Ethernet links =
are used=20
(Both do ARP). We had to find workarounds&nbsp;to make things work<SPAN=20
class=3D097161016-05072007> (at ISO Core and in private testing)</SPAN>. =
The same=20
will be the case between Cisco, Juniper and other vendors.<SPAN=20
class=3D097161016-05072007> =
</SPAN></SPAN></SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT><SPAN class=3D097161016-05072007><FONT face=3DArial =
size=3D2><SPAN=20
class=3D031093514-05072007></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D097161016-05072007><FONT face=3DArial =
size=3D2><SPAN=20
class=3D031093514-05072007>The solution we are pushing for is that we =
need a=20
mechanism that allows us to resolve ARP directly for the GMPLS tunnel ip =

addresses. This removes any dependency on the underlying Ethernet links =
or the=20
addressing scheme that is used for TE links i.e. numbered links in the =
same or=20
different subnets.</SPAN></FONT></DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D031093514-05072007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D097161016-05072007>In the following, we</SPAN>&nbsp;describe the =
situation=20
with numbered Ethernet links and Unnumbered&nbsp;Ethernet links (the =
assumption=20
is that the GMPLS tunnel is a ipv4 numbered link in both instances)<SPAN =

class=3D097161016-05072007>.</SPAN></FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D031093514-05072007>Consider the=20
scenario </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007>&lt;------------------------------------------=
----GMPLS=20
Tunnel------------------------------------------&gt;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D031093514-05072007>RTR1 =
&lt;------GE=20
data link/TE link&nbsp;-----&gt; OXC &lt;------ GE data link/TE link =
-----&gt;=20
RTR2</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;segment=20
#=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
segment # 2</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D031093514-05072007>There =
are two=20
instance<SPAN class=3D097161016-05072007> to =
consider</SPAN>:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007></SPAN></FONT>&nbsp;</DIV><SPAN=20
class=3D031093514-05072007>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D031093514-05072007>(<SPAN =

class=3D097161016-05072007>a</SPAN>) When numbered TE links are used but =
segment #=20
1 and segment # 2 are in different subnets (valid =
scenario)</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007>&nbsp;&nbsp;&nbsp;&nbsp; In this situation we =
really=20
have no way of resolving ARP using the addresses of the underlying TE =
link=20
Ethernet links w/o using static ARP entries. The issue&nbsp;<SPAN=20
class=3D097161016-05072007>i</SPAN>s</SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
class=3D031093514-05072007> that the subnets are different so the ARP =
request=20
received by RTR2 from RTR1 will be rejected as it is not known to RTR2 =
and vice=20
versa. Instead, if the ARP</SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
class=3D031093514-05072007> request if for the GMPLS tunnel instead then =
there=20
should be no problem as the GMPLS tunnel is p-p link with IPV4 addresses =
in the=20
same subnet.</SPAN></FONT></DIV>
<DIV><SPAN class=3D031093514-05072007><FONT face=3DArial><FONT=20
size=3D2><STRONG>Verdict:</STRONG> If we have the ARP resolution =
mechanism tied in=20
to the GMPLS tunnel interfaces&nbsp;addresses then there is no issue or=20
dependency </FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D031093514-05072007></SPAN><SPAN=20
class=3D031093514-05072007></SPAN></FONT></FONT>&nbsp;</DIV></SPAN></DIV>=

<DIV><SPAN class=3D031093514-05072007>
<DIV>(a) When numbered TE links are used and segment # 1 and segment # 2 =
are in=20
the same subnet. </SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D031093514-05072007>&nbsp;&nbsp;&nbsp;&nbsp; In this setup the =
GMPLS Tunnel=20
can inherit and use the ethernet&nbsp;</SPAN><SPAN =
class=3D031093514-05072007>link=20
address for ARP resolution and there is no issue as both segments are in =
the=20
same subnet.&nbsp;</SPAN></FONT></FONT><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D031093514-05072007>The problem in this situation is that =
we&nbsp;need to=20
resolve&nbsp;</SPAN><SPAN class=3D031093514-05072007>the ARP for the =
ipv4=20
addresses for the GMPLS tunnel (considered as a p-p link) as opposed to =
inherit=20
it&nbsp;</SPAN></FONT></FONT><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007>from the underlying Ethernet TE=20
links.</SPAN></FONT></DIV>
<DIV><SPAN class=3D031093514-05072007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D097161016-05072007><STRONG><SPAN =
class=3D031093514-05072007><FONT=20
face=3DArial><FONT=20
size=3D2><STRONG>Verdict:</STRONG></FONT></FONT></SPAN>&nbsp;</STRONG></S=
PAN>&nbsp;In=20
this situation the ARP resolution mechanism should be developed for the =
GMPLS=20
tunnel address.</FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D031093514-05072007>(c) =
The third=20
scenario is when the GMPLS tunnel is numbered but the TE links are=20
Unnumbered.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007>&nbsp;&nbsp;&nbsp;&nbsp; In this case we are =
again=20
faced with the same issue of L2 ARP adjacency resolution between RTR1 =
and RTR2.=20
RTR2 will reject the ARP request for RTR1 when =
it&nbsp;</SPAN></FONT><FONT=20
face=3DArial size=3D2><SPAN class=3D031093514-05072007>does not find the =
Unnumbered=20
address (used by RTR1) in its FWDing database. This issue would not be=20
encountered if we were resolving the ARP on GMPLS</SPAN></FONT><FONT =
face=3DArial=20
size=3D2><SPAN class=3D031093514-05072007> tunnel =
address.</SPAN></FONT></DIV>
<DIV><SPAN class=3D031093514-05072007><FONT face=3DArial><FONT=20
size=3D2><STRONG>Verdict:</STRONG> ARP resolution mechanism is required =
for GMPLS=20
tunnel.</FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D031093514-05072007></SPAN></FONT><FONT=20
face=3DArial size=3D2><SPAN =
class=3D031093514-05072007></SPAN></FONT><FONT=20
face=3DArial><FONT size=3D2><SPAN class=3D031093514-05072007><SPAN=20
class=3D097161016-05072007>(d) We also need to make sure that when the =
tunnel-id=20
is unnum, vendor implementation honor ARP request using loopback =
addresses. We=20
have also faced interop issue in this scenario.=20
</SPAN></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D031093514-05072007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D031093514-05072007><SPAN=20
class=3D097161016-05072007>Thanks</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D031093514-05072007><SPAN=20
class=3D097161016-05072007></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D031093514-05072007><SPAN=20
class=3D097161016-05072007>Regards... Hassan and Zafar=20
</SPAN></SPAN></FONT></DIV></SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C7BF23.0096A019--



Envelope-to: [e-mail]
Delivery-date: Thu, 05 Jul 2007 16:52:08 +0000
Message-ID: <[e-mail]>
Date: Thu, 05 Jul 2007 09:39:09 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: "Diego Caviglia (GA/ERI)" <[e-mail]>
CC: [e-mail]
Subject: Re: Switching Capability of Photonic Links with Transponder
Content-Type: multipart/alternative; boundary="------------040306020202000908070009"

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

Hi Diego, looks like we've been thinking about similar issues lately.
First, I want to nail down the interfaces on your lambda switch below.
Are they:
(a) WDM interfaces, i.e., with multiple lambda's coming in and out.
(b) single wavelength interfaces
(c) a combination of the two, e.g., like in a ADM (or ROADM) where we 
have line side (WDM) and drop side single wavelength.

On terminology instead of "frequency switching" can we call it by its 
more typical name "wavelength conversion" to avoid confusion with 
"lambda switching" (since lambda's and frequencies have a 1-1 
correspondence and both are used to describe optical signals in ITU-T 
recommendations).

Given where the OEO is located I'd say that particular interface is a 
single wavelength.

Regards

Greg B.

Diego Caviglia (GA/ERI) wrote:
>
> Hi all,
>
>          I've a doubt about how to model the following situation.
>
>  
>
>  
>
>  
>
>       +-----------------+
>
>       |                 |-------+
>
>       |                 | OEO   |
>
>       |     Lambda      |-------+
>
>       |     Switch      |
>
>       |                 |
>
>       |                 |
>
>       +-----------------+
>
>      
>
>  
>
> The node itself is able to cross connect only the Lambda while the 
> interface has a OEO transponder that is able to change the lambda 
> frequency.  In this case there are two different 'switching 
> capability' the spatial one that is performed by the switch (lambda 1, 
> port A) --> (lambda1, port B) and the frequency switching is done by 
> the OEO transponder.  Witch kind of interface switching capability I 
> have to advertise?
>
>  
>
> BR
>
>
> Diego
>
>  
>
> **Diego Caviglia**
>
> Product Line ON BBN
>
> PA Broadband BNET
>
>  
>
> **Marconi S.p.A**
>
> Ericsson Global Product Center - Italy
>
> Via Anagnina,203
>
> 0018, Roma , Italy
>
> www.ericsson.com <http://www.ericsson.com/>
>
>  
>
> Office:  [phone]
>
> Fax: [phone]
>
> Mobile: [phone]
>
> Email: [e-mail] <mailto:[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.
>
> E-mail including attachments is susceptible to data corruption, 
> interception, unauthorized amendment, tampering and viruses, and we 
> only send and receive emails on the basis that we are not liable for 
> any such corruption, interception, amendment, tampering or viruses or 
> any consequences thereof.
>
>  
>

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



--------------040306020202000908070009
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, looks like we've been thinking about similar issues lately.<br>
First, I want to nail down the interfaces on your lambda switch below.<br>
Are they:<br>
(a) WDM interfaces, i.e., with multiple lambda's coming in and out.<br>
(b) single wavelength interfaces<br>
(c) a combination of the two, e.g., like in a ADM (or ROADM) where we
have line side (WDM) and drop side single wavelength.<br>
<br>
On terminology instead of "frequency switching" can we call it by its
more typical name "wavelength conversion" to avoid confusion with
"lambda switching" (since lambda's and frequencies have a 1-1
correspondence and both are used to describe optical signals in ITU-T
recommendations).<br>
<br>
Given where the OEO is located I'd say that particular interface is a
single wavelength.<br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
Diego Caviglia (GA/ERI) wrote:
<blockquote
 cite="mid:[e-mail]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="Microsoft Word 11 (filtered medium)">
  <o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="country-region">
  <o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PlaceType"><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PlaceName">
  <o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="State"><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City">
  <o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
  <style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
  </style></o:SmartTagType></o:SmartTagType></o:SmartTagType></o:SmartTagType></o:SmartTagType></o:SmartTagType>
  <div class="Section1">
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Hi all,<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I&#8217;ve
a doubt about how to model the following situation.<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------+<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |-------+<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
OEO&nbsp;&nbsp; |<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
Lambda&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |-------+<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
Switch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------+<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">The node itself
is able to cross connect only the
Lambda while the interface has a OEO transponder that is able to change
the
lambda frequency. &nbsp;In this case there are two different &#8216;switching
capability&#8217; the spatial one that is performed by the switch (lambda 1,
port A) --&gt; (lambda1, port B) and the frequency switching is done by
the OEO
transponder. &nbsp;Witch kind of interface switching capability I have to
advertise?<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;">BR<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Courier New" size="2"><span
 style="font-size: 10pt; font-family: &quot;Courier New&quot;;"><br>
Diego<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal" style=""><strong><b><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;" lang="EN-GB">Diego
Caviglia</span></font></b></strong><o:p></o:p></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;" lang="EN-GB">Product
  <st1:place w:st="on"><st1:City w:st="on">Line</st1:City> <u1:City
 u2:st="on"><u1:place u2:st="on"><st1:State w:st="on">ON</st1:State></u1:place>
  </u1:City></st1:place>BBN</span></font><span lang="EN-GB"><o:p></o:p></span></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;" lang="EN-GB">PA
Broadband BNET</span></font><span lang="EN-GB"><o:p></o:p></span></p>
  <p class="MsoNormal" style=""><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;" lang="EN-GB">&nbsp;<o:p></o:p></span></font></p>
  <p class="MsoNormal" style=""><strong><b><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Marconi
S.p.A</span></font></b></strong><o:p></o:p></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Ericsson
Global <st1:PlaceName w:st="on">Product</st1:PlaceName> <st1:PlaceType
 w:st="on">Center</st1:PlaceType>
- <st1:country-region w:st="on"><st1:place w:st="on">Italy</st1:place></st1:country-region></span></font><o:p></o:p></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Via
Anagnina,203</span></font><o:p></o:p></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;" lang="IT">0018,
Roma , Italy</span></font><span lang="IT"><o:p></o:p></span></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;" lang="EN-GB"><a
 moz-do-not-send="true" href="http://www.ericsson.com/"
 title="http://www.ericsson.com/"><span lang="IT"><span
 title="http://www.ericsson.com/">www.ericsson.com</span></span></a></span></font><span
 lang="IT"><o:p></o:p></span></p>
  <p class="MsoNormal" style=""><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;" lang="IT">&nbsp;<o:p></o:p></span></font></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;" lang="IT">Office:&nbsp;
[phone]</span></font><span lang="IT"><o:p></o:p></span></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;" lang="FR">Fax:
[phone]</span></font><span lang="IT"><o:p></o:p></span></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;" lang="FR">Mobile:
[phone]</span></font><span lang="IT"><o:p></o:p></span></p>
  <p class="MsoNormal" style=""><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;" lang="FR">Email:
  <a moz-do-not-send="true" href="mailto:[e-mail]">[e-mail]</a>&nbsp;</span></font><span
 lang="FR">&nbsp;<o:p></o:p></span></p>
  <p class="MsoNormal" style=""><font color="gray" face="Arial" size="1"><span
 style="font-size: 7.5pt; font-family: Arial; color: gray;" lang="EN-GB">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.<br>
  <br>
E-mail including attachments is susceptible to data corruption,
interception,
unauthorized amendment, tampering and viruses, and we only send and
receive
emails on the basis that we are not liable for any such corruption,
interception, amendment, tampering or viruses or any consequences
thereof.</span></font><font color="gray" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: gray;" lang="EN-GB"><o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  </div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]

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

--------------040306020202000908070009--



Envelope-to: [e-mail]
Delivery-date: Thu, 05 Jul 2007 06:44:14 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BECF.7BF24BBF"
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Thu, 5 Jul 2007 08:39:59 +0200
Message-ID: <[e-mail]>
Thread-Topic: Switching Capability of Photonic Links with Transponder
Thread-Index: Ace9Qa6ZTl3jS1bxRCKUK9yWDVtLnAATdoXQAB5NhOAAAuz8EAAuiQKA
From: "Diego Caviglia (GA/ERI)" <[e-mail]>
To: "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

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


Hi Julien,
          Hmmmmmm not sure my Understanding of the lambda switching is =
what I've called spatial switching that is lambda1 portA --> lambda1 =
portB what is not clear to me is how can be advertised an OEO =
transponder that can only perform frequency switching lambda1 --> lambda =
2.

Adrian? Deb? Anyone else?

BR

Diego
-----Original Message-----
From: MEURIC Julien RD-CORE-LAN =
[mailto:[e-mail]]=20
Sent: mercoled=EC 4 luglio 2007 18.47
To: Diego Caviglia (GA/ERI); [e-mail]
Subject: RE: Switching Capability of Photonic Links with Transponder

Hi Diego.

I believe we should refer to the Holly RFC 3945, chapter 1, verse 2:
- "Lambda Switch Capable" interfaces "can operate at the level of an =
*individual wavelength*" [or a "group of wavelengths"], meaning that you =
manipulate values of wavelengths (as AU-4 numbers [or AU-4 ranges] from =
an SDH portA to SDH portB), like in a ROADM;
- "Fiber-Switch Capable" interfaces "can operate at the level of a =
single or multiple *fibers*", meaning *spatial switching* where you =
don't consider the type of signal that ports convey (could be anything =
like a black and white signal, a wavelength, a WDM multiplex, some =
optical packets...), like in a OOO PXC.

To stick with strict terminolgy: lambda =3D wavelength =3D (speedOfLight =
/ frequency)
So if you need to do "frequency switching", then it is the so called =
"lambda switching". :-)

Anyway, this is my understanding, so if I'm wrong or if it's a =
vocabulary issue because you find that terms are inappropriate, then =
we'd better ask father Adrian and sister Deborah.

Cheers,

Julien


-----Original Message-----
From: Diego Caviglia (GA/ERI) [mailto:[e-mail]]=20

Hi Julien,
          Actually not the PXC I had in mind is able to switch a single =
lambda I didn't but the mux/demux In the picture sorry.

The point I failed to illustrate is the ambiguity of the term "Lambda =
Switch Capable" given that there two possible ways to switch a lambda. =20

The first one is the spatial one: (Lambda1 portA) --> (Lambda1 portB) =
this is the way an all optical switch works and this why there is the =
lambda continuity constraint in photonic networks. =20

The second one is the frequency switching: (Lambda1 portA) --> (Lambda2 =
portA) this switching can be done via a transponder (OEO) device. =20

Of course is possible to mix the two switching having (Lambda1 portA) =
--> (Lambda2 portB)

My impression is that the definition "Lambda Switch Capable" refers to =
the spatial switching and thus I don't know how to model the fact that =
after/before a photonic matrix I have a transponder. =20

I hope I've made my question clearer.

Best Regards

Diego

-----Original Message-----
From: MEURIC Julien RD-CORE-LAN =
[mailto:[e-mail]]=20
Sent: marted=EC 3 luglio 2007 19.21
To: Diego Caviglia (GA/ERI); [e-mail]
Subject: RE: Switching Capability of Photonic Links with Transponder

Hi Diego.

If I understand correctly, your "lambda switch" by itself is a PXC that
has only "Fiber-Switch Capable" interfaces. Then, you add
lambda-conversion cards to it. So, correct me if I'm wrong (you or
anyone else), but whether you do a lambda conversion inside a card or in
a core matrix, this new interface on your global device is able to work
on lambdas anyway  [(lambda 1, port A) --> (lambda2, port B)]. As a
result, you need to advertise your most flexible capability, which is
"Lambda Switch Capable".
If you used "FSC", you wouldn't be able to control your "lambda
swapping" card, as LSPs are like lists of fibers and labels aren't
wavelengths but ports.

But maybe I didn't get your actual issue.

My 2 cents,

Julien

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia (GA/ERI)

Hi all,

         I've a doubt about how to model the following situation.

=20

=20

=20

      +-----------------+

      |                 |-------+

      |                 | OEO   |

      |     Lambda      |-------+

      |     Switch      |

      |                 |

      |                 |

      +-----------------+

     =20

=20

The node itself is able to cross connect only the Lambda while the
interface has a OEO transponder that is able to change the lambda
frequency.  In this case there are two different 'switching capability'
the spatial one that is performed by the switch (lambda 1, port A) -->
(lambda1, port B) and the frequency switching is done by the OEO
transponder.  Witch kind of interface switching capability I have to
advertise?

=20

BR


Diego

=20

Diego Caviglia

Product Line ON BBN

PA Broadband BNET

=20

Marconi S.p.A

Ericsson Global Product Center - Italy

Via Anagnina,203

0018, Roma , Italy

www.ericsson.com <http://www.ericsson.com/>=20

=20

Office:  [phone]

Fax: [phone]

Mobile: [phone]

Email: [e-mail] =20

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.

E-mail including attachments is susceptible to data corruption,
interception, unauthorized amendment, tampering and viruses, and we only
send and receive emails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

=20


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: Switching Capability of Photonic Links with =
Transponder</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"></SPAN><A NAME=3D""><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">Hi =
Julien,</FONT></SPAN></A></P>

<P ALIGN=3DLEFT><SPAN =
LANG=3D"en-us">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Hmmmmmm not sure my</SPAN><SPAN LANG=3D"en-us"> Understanding of the =
lambda switching is what I&#8217;ve called spatial switching that is =
lambda1 portA <FONT FACE=3D"Wingdings" =
SIZE=3D3>&#224;</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> lambda1 portB what is not clear to me is how can be =
advertised an OEO transponder that can only perform frequency switching =
lambda1 <FONT FACE=3D"Wingdings" SIZE=3D3>&#224;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> lambda 2.</SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us">Adrian? Deb? Anyone =
else?</SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us">BR</SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Diego</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">-----Original Message-----<BR>
From: MEURIC Julien RD-CORE-LAN [<A =
HREF=3D"mailto:[e-mail]">mailto:julien.meuric@ora=
nge-ftgroup.com</A>]<BR>
Sent: mercoled=EC 4 luglio 2007 18.47<BR>
To: Diego Caviglia (GA/ERI); [e-mail]<BR>
Subject: RE: Switching Capability of Photonic Links with =
Transponder</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hi Diego.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">I believe we should refer to the Holly RFC 3945, chapter 1, verse =
2:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">- &quot;Lambda Switch Capable&quot; interfaces &quot;can operate at =
the level of an *individual wavelength*&quot; [or a &quot;group of =
wavelengths&quot;], meaning that you manipulate values of wavelengths =
(as AU-4 numbers [or AU-4 ranges] from an SDH portA to SDH portB), like =
in a ROADM;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">- &quot;Fiber-Switch Capable&quot; interfaces &quot;can operate at =
the level of a single or multiple *fibers*&quot;, meaning *spatial =
switching* where you don't consider the type of signal that ports convey =
(could be anything like a black and white signal, a wavelength, a WDM =
multiplex, some optical packets...), like in a OOO =
PXC.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">To stick with strict terminolgy: lambda =3D wavelength =3D =
(speedOfLight / frequency)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">So if you need to do &quot;frequency switching&quot;, then it is =
the so called &quot;lambda switching&quot;. :-)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Anyway, this is my understanding, so if I'm wrong or if it's a =
vocabulary issue because you find that terms are inappropriate, then =
we'd better ask father Adrian and sister Deborah.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Cheers,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Julien</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">-----Original Message-----</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">From: Diego Caviglia (GA/ERI) [<A =
HREF=3D"mailto:[e-mail]">mailto:diego.caviglia@ericsso=
n.com</A>] </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hi Julien,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Actually not =
the PXC I had in mind is able to switch a single lambda I didn't but the =
mux/demux In the picture sorry.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">The point I failed to illustrate is the ambiguity of the term =
&quot;Lambda Switch Capable&quot; given that there two possible ways to =
switch a lambda.&nbsp; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">The first one is the spatial one: (Lambda1 portA) --&gt; (Lambda1 =
portB) this is the way an all optical switch works and this why there is =
the lambda continuity constraint in photonic networks.&nbsp; =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">The second one is the frequency switching: (Lambda1 portA) --&gt; =
(Lambda2 portA) this switching can be done via a transponder (OEO) =
device.&nbsp; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Of course is possible to mix the two switching having (Lambda1 =
portA) --&gt; (Lambda2 portB)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">My impression is that the definition &quot;Lambda Switch =
Capable&quot; refers to the spatial switching and thus I don't know how =
to model the fact that after/before a photonic matrix I have a =
transponder.&nbsp; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">I hope I've made my question clearer.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Best Regards</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Diego</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">-----Original Message-----</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">From: MEURIC Julien RD-CORE-LAN [<A =
HREF=3D"mailto:[e-mail]">mailto:julien.meuric@ora=
nge-ftgroup.com</A>] </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Sent: marted=EC 3 luglio 2007 19.21</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">To: Diego Caviglia (GA/ERI); [e-mail]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Subject: RE: Switching Capability of Photonic Links with =
Transponder</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hi Diego.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">If I understand correctly, your &quot;lambda switch&quot; by itself =
is a PXC that</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">has only &quot;Fiber-Switch Capable&quot; interfaces. Then, you =
add</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">lambda-conversion cards to it. So, correct me if I'm wrong (you =
or</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">anyone else), but whether you do a lambda conversion inside a card =
or in</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">a core matrix, this new interface on your global device is able to =
work</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">on lambdas anyway&nbsp; [(lambda 1, port A) --&gt; (lambda2, port =
B)]. As a</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">result, you need to advertise your most flexible capability, which =
is</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&quot;Lambda Switch Capable&quot;.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">If you used &quot;FSC&quot;, you wouldn't be able to control your =
&quot;lambda</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">swapping&quot; card, as LSPs are like lists of fibers and labels =
aren't</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">wavelengths but ports.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">But maybe I didn't get your actual issue.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">My 2 cents,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Julien</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">________________________________</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]<=
/A>] On</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Behalf Of Diego Caviglia (GA/ERI)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hi all,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I've a doubt about =
how to model the following situation.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+-----------------+</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; |-------+</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; | OEO&nbsp;&nbsp; |</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; =
Lambda&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |-------+</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; =
Switch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; |</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; |</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+-----------------+</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">The node itself is able to cross connect only the Lambda while =
the</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">interface has a OEO transponder that is able to change the =
lambda</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">frequency.&nbsp; In this case there are two different 'switching =
capability'</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">the spatial one that is performed by the switch (lambda 1, port A) =
--&gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">(lambda1, port B) and the frequency switching is done by the =
OEO</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">transponder.&nbsp; Witch kind of interface switching capability I =
have to</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">advertise?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">BR</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Diego</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Diego Caviglia</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Product Line ON BBN</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">PA Broadband BNET</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Marconi S.p.A</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Ericsson Global Product Center - Italy</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Via Anagnina,203</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">0018, Roma , Italy</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">www.ericsson.com &lt;<A =
HREF=3D"http://www.ericsson.com/">http://www.ericsson.com/</A>&gt; =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Office:&nbsp; [phone]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Fax: [phone]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Mobile: [phone]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Email: [e-mail]&nbsp; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">This communication is confidential and intended solely for =
the</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">addressee(s). Any unauthorized review, use, disclosure or =
distribution</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">is prohibited. If you believe this message has been sent to you =
in</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">error, please notify the sender by replying to this transmission =
and</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">delete the message without disclosing it. Thank =
you.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">E-mail including attachments is susceptible to data =
corruption,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">interception, unauthorized amendment, tampering and viruses, and we =
only</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">send and receive emails on the basis that we are not liable for any =
such</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">corruption, interception, amendment, tampering or viruses or =
any</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">consequences thereof.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;</FONT></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C7BECF.7BF24BBF--



Envelope-to: [e-mail]
Delivery-date: Wed, 04 Jul 2007 16:49:12 +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: Switching Capability of Photonic Links with Transponder
Date: Wed, 4 Jul 2007 18:46:34 +0200
Message-ID: <[e-mail]>
Thread-Topic: Switching Capability of Photonic Links with Transponder
Thread-Index: Ace9Qa6ZTl3jS1bxRCKUK9yWDVtLnAATdoXQAB5NhOAAAuz8EA==
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Diego Caviglia \(GA/ERI\)" <[e-mail]>, <[e-mail]>

Hi Diego.

I believe we should refer to the Holly RFC 3945, chapter 1, verse 2:
- "Lambda Switch Capable" interfaces "can operate at the level of an =
*individual wavelength*" [or a "group of wavelengths"], meaning that you =
manipulate values of wavelengths (as AU-4 numbers [or AU-4 ranges] from =
an SDH portA to SDH portB), like in a ROADM;
- "Fiber-Switch Capable" interfaces "can operate at the level of a =
single or multiple *fibers*", meaning *spatial switching* where you =
don't consider the type of signal that ports convey (could be anything =
like a black and white signal, a wavelength, a WDM multiplex, some =
optical packets...), like in a OOO PXC.

To stick with strict terminolgy: lambda =3D wavelength =3D (speedOfLight =
/ frequency)
So if you need to do "frequency switching", then it is the so called =
"lambda switching". :-)

Anyway, this is my understanding, so if I'm wrong or if it's a =
vocabulary issue because you find that terms are inappropriate, then =
we'd better ask father Adrian and sister Deborah.

Cheers,

Julien


-----Original Message-----
From: Diego Caviglia (GA/ERI) [mailto:[e-mail]]=20

Hi Julien,
          Actually not the PXC I had in mind is able to switch a single =
lambda I didn't but the mux/demux In the picture sorry.

The point I failed to illustrate is the ambiguity of the term "Lambda =
Switch Capable" given that there two possible ways to switch a lambda. =20

The first one is the spatial one: (Lambda1 portA) --> (Lambda1 portB) =
this is the way an all optical switch works and this why there is the =
lambda continuity constraint in photonic networks. =20

The second one is the frequency switching: (Lambda1 portA) --> (Lambda2 =
portA) this switching can be done via a transponder (OEO) device. =20

Of course is possible to mix the two switching having (Lambda1 portA) =
--> (Lambda2 portB)

My impression is that the definition "Lambda Switch Capable" refers to =
the spatial switching and thus I don't know how to model the fact that =
after/before a photonic matrix I have a transponder. =20

I hope I've made my question clearer.

Best Regards

Diego

-----Original Message-----
From: MEURIC Julien RD-CORE-LAN =
[mailto:[e-mail]]=20
Sent: marted=EC 3 luglio 2007 19.21
To: Diego Caviglia (GA/ERI); [e-mail]
Subject: RE: Switching Capability of Photonic Links with Transponder

Hi Diego.

If I understand correctly, your "lambda switch" by itself is a PXC that
has only "Fiber-Switch Capable" interfaces. Then, you add
lambda-conversion cards to it. So, correct me if I'm wrong (you or
anyone else), but whether you do a lambda conversion inside a card or in
a core matrix, this new interface on your global device is able to work
on lambdas anyway  [(lambda 1, port A) --> (lambda2, port B)]. As a
result, you need to advertise your most flexible capability, which is
"Lambda Switch Capable".
If you used "FSC", you wouldn't be able to control your "lambda
swapping" card, as LSPs are like lists of fibers and labels aren't
wavelengths but ports.

But maybe I didn't get your actual issue.

My 2 cents,

Julien

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia (GA/ERI)

Hi all,

         I've a doubt about how to model the following situation.

=20

=20

=20

      +-----------------+

      |                 |-------+

      |                 | OEO   |

      |     Lambda      |-------+

      |     Switch      |

      |                 |

      |                 |

      +-----------------+

     =20

=20

The node itself is able to cross connect only the Lambda while the
interface has a OEO transponder that is able to change the lambda
frequency.  In this case there are two different 'switching capability'
the spatial one that is performed by the switch (lambda 1, port A) -->
(lambda1, port B) and the frequency switching is done by the OEO
transponder.  Witch kind of interface switching capability I have to
advertise?

=20

BR


Diego

=20

Diego Caviglia

Product Line ON BBN

PA Broadband BNET

=20

Marconi S.p.A

Ericsson Global Product Center - Italy

Via Anagnina,203

0018, Roma , Italy

www.ericsson.com <http://www.ericsson.com/>=20

=20

Office:  [phone]

Fax: [phone]

Mobile: [phone]

Email: [e-mail] =20

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.

E-mail including attachments is susceptible to data corruption,
interception, unauthorized amendment, tampering and viruses, and we only
send and receive emails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

=20




Envelope-to: [e-mail]
Delivery-date: Wed, 04 Jul 2007 07:10:55 +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: Switching Capability of Photonic Links with Transponder
Date: Wed, 4 Jul 2007 09:08:16 +0200
Message-ID: <[e-mail]>
Thread-Topic: Switching Capability of Photonic Links with Transponder
Thread-Index: Ace9Qa6ZTl3jS1bxRCKUK9yWDVtLnAATdoXQAB5NhOA=
From: "Diego Caviglia (GA/ERI)" <[e-mail]>
To: "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>

Hi Julien,
          Actually not the PXC I had in mind is able to switch a single =
lambda I didn't but the mux/demux In the picture sorry.

The point I failed to illustrate is the ambiguity of the term "Lambda =
Switch Capable" given that there two possible ways to switch a lambda. =20

The first one is the spatial one: (Lambda1 portA) --> (Lambda1 portB) =
this is the way an all optical switch works and this why there is the =
lambda continuity constraint in photonic networks. =20

The second one is the frequency switching: (Lambda1 portA) --> (Lambda2 =
portA) this switching can be done via a transponder (OEO) device. =20

Of course is possible to mix the two switching having (Lambda1 portA) =
--> (Lambda2 portB)

My impression is that the definition "Lambda Switch Capable" refers to =
the spatial switching and thus I don't know how to model the fact that =
after/before a photonic matrix I have a transponder. =20

I hope I've made my question clearer.

Best Regards

Diego

-----Original Message-----
From: MEURIC Julien RD-CORE-LAN =
[mailto:[e-mail]]=20
Sent: marted=EC 3 luglio 2007 19.21
To: Diego Caviglia (GA/ERI); [e-mail]
Subject: RE: Switching Capability of Photonic Links with Transponder

Hi Diego.

If I understand correctly, your "lambda switch" by itself is a PXC that
has only "Fiber-Switch Capable" interfaces. Then, you add
lambda-conversion cards to it. So, correct me if I'm wrong (you or
anyone else), but whether you do a lambda conversion inside a card or in
a core matrix, this new interface on your global device is able to work
on lambdas anyway  [(lambda 1, port A) --> (lambda2, port B)]. As a
result, you need to advertise your most flexible capability, which is
"Lambda Switch Capable".
If you used "FSC", you wouldn't be able to control your "lambda
swapping" card, as LSPs are like lists of fibers and labels aren't
wavelengths but ports.

But maybe I didn't get your actual issue.

My 2 cents,

Julien

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia (GA/ERI)

Hi all,

         I've a doubt about how to model the following situation.

=20

=20

=20

      +-----------------+

      |                 |-------+

      |                 | OEO   |

      |     Lambda      |-------+

      |     Switch      |

      |                 |

      |                 |

      +-----------------+

     =20

=20

The node itself is able to cross connect only the Lambda while the
interface has a OEO transponder that is able to change the lambda
frequency.  In this case there are two different 'switching capability'
the spatial one that is performed by the switch (lambda 1, port A) -->
(lambda1, port B) and the frequency switching is done by the OEO
transponder.  Witch kind of interface switching capability I have to
advertise?

=20

BR


Diego

=20

Diego Caviglia

Product Line ON BBN

PA Broadband BNET

=20

Marconi S.p.A

Ericsson Global Product Center - Italy

Via Anagnina,203

0018, Roma , Italy

www.ericsson.com <http://www.ericsson.com/>=20

=20

Office:  [phone]

Fax: [phone]

Mobile: [phone]

Email: [e-mail] =20

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.

E-mail including attachments is susceptible to data corruption,
interception, unauthorized amendment, tampering and viruses, and we only
send and receive emails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

=20




Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jul 2007 18:16:48 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-09.txt 
Message-Id: <[e-mail]>
Date: Tue, 03 Jul 2007 14:15:02 -0400

--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		: Extensions to GMPLS RSVP Graceful Restart
	Author(s)	: A. Satyanarayana, R. Rahman
	Filename	: draft-ietf-ccamp-rsvp-restart-ext-09.txt
	Pages		: 24
	Date		: 2007-7-3
	
This document describes extensions to the RSVP Graceful Restart
   mechanisms defined in RFC 3473.  The extensions enable the recovery
   of RSVP signaling state based on the Path message last sent by the
   node being restarted.

   Previously defined Graceful Restart mechanisms, also called recovery
   from nodal faults, permit recovery of signaling state from adjacent
   nodes when the data plane has retained the associated forwarding
   state across a restart.  Those mechanisms do not fully support
   signaling state recovery on ingress nodes or recovery of all RSVP
   objects.

   The extensions defined in this document build on the RSVP Hello
   extensions defined in RFC 3209, and extensions for state recovery on
   nodal faults defined in RFC 3473.  Using these extensions the
   restarting node can recover all previously transmitted Path state

   including the Explicit Route Object and the downstream (outgoing)
   interface identifiers.  The extensions can also be used to recover
   signaling state after the restart of an ingress node.

   These extensions are not used to create or restore data plane state.

   The extensions optionally support the use of Summary Refresh, defined
   in RFC 2961, to reduce the number of messages exchanged during the
   Recovery Phase when the restarting node has recovered signaling state
   locally for one or more LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rsvp-restart-ext-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jul 2007 17:22:37 +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: Switching Capability of Photonic Links with Transponder
Date: Tue, 3 Jul 2007 19:20:33 +0200
Message-ID: <[e-mail]>
Thread-Topic: Switching Capability of Photonic Links with Transponder
Thread-Index: Ace9Qa6ZTl3jS1bxRCKUK9yWDVtLnAATdoXQ
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Diego Caviglia \(GA/ERI\)" <[e-mail]>, <[e-mail]>

Hi Diego.

If I understand correctly, your "lambda switch" by itself is a PXC that
has only "Fiber-Switch Capable" interfaces. Then, you add
lambda-conversion cards to it. So, correct me if I'm wrong (you or
anyone else), but whether you do a lambda conversion inside a card or in
a core matrix, this new interface on your global device is able to work
on lambdas anyway  [(lambda 1, port A) --> (lambda2, port B)]. As a
result, you need to advertise your most flexible capability, which is
"Lambda Switch Capable".
If you used "FSC", you wouldn't be able to control your "lambda
swapping" card, as LSPs are like lists of fibers and labels aren't
wavelengths but ports.

But maybe I didn't get your actual issue.

My 2 cents,

Julien

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia (GA/ERI)

Hi all,

         I've a doubt about how to model the following situation.

=20

=20

=20

      +-----------------+

      |                 |-------+

      |                 | OEO   |

      |     Lambda      |-------+

      |     Switch      |

      |                 |

      |                 |

      +-----------------+

     =20

=20

The node itself is able to cross connect only the Lambda while the
interface has a OEO transponder that is able to change the lambda
frequency.  In this case there are two different 'switching capability'
the spatial one that is performed by the switch (lambda 1, port A) -->
(lambda1, port B) and the frequency switching is done by the OEO
transponder.  Witch kind of interface switching capability I have to
advertise?

=20

BR


Diego

=20

Diego Caviglia

Product Line ON BBN

PA Broadband BNET

=20

Marconi S.p.A

Ericsson Global Product Center - Italy

Via Anagnina,203

0018, Roma , Italy

www.ericsson.com <http://www.ericsson.com/>=20

=20

Office:  [phone]

Fax: [phone]

Mobile: [phone]

Email: [e-mail] =20

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.

E-mail including attachments is susceptible to data corruption,
interception, unauthorized amendment, tampering and viruses, and we only
send and receive emails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

=20




Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jul 2007 07:17:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BD41.AFA8F18A"
Subject: Switching Capability of Photonic Links with Transponder
Date: Tue, 3 Jul 2007 09:13:40 +0200
Message-ID: <[e-mail]>
Thread-Topic: Switching Capability of Photonic Links with Transponder
Thread-Index: Ace9Qa6ZTl3jS1bxRCKUK9yWDVtLnA==
From: "Diego Caviglia (GA/ERI)" <[e-mail]>
To: <[e-mail]>

This is a multi-part message in MIME format.

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

Hi all,

         I've a doubt about how to model the following situation.

=20

=20

=20

      +-----------------+

      |                 |-------+

      |                 | OEO   |

      |     Lambda      |-------+

      |     Switch      |

      |                 |

      |                 |

      +-----------------+

     =20

=20

The node itself is able to cross connect only the Lambda while the
interface has a OEO transponder that is able to change the lambda
frequency.  In this case there are two different 'switching capability'
the spatial one that is performed by the switch (lambda 1, port A) -->
(lambda1, port B) and the frequency switching is done by the OEO
transponder.  Witch kind of interface switching capability I have to
advertise?

=20

BR


Diego

=20

Diego Caviglia

Product Line ON BBN

PA Broadband BNET

=20

Marconi S.p.A

Ericsson Global Product Center - Italy

Via Anagnina,203

0018, Roma , Italy

www.ericsson.com <http://www.ericsson.com/>=20

=20

Office:  [phone]

Fax: [phone]

Mobile: [phone]

Email: [e-mail] =20

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.

E-mail including attachments is susceptible to data corruption,
interception, unauthorized amendment, tampering and viruses, and we only
send and receive emails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

=20


------_=_NextPart_001_01C7BD41.AFA8F18A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I&#8217;ve
a doubt about how to model the following =
situation.<o:p></o:p></span></font></p>

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

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

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

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; |-------+<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; |
OEO&nbsp;&nbsp; |<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp; Lambda&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|-------+<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp; Switch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|<o:p></o:p></span></font></p>

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

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

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

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

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>The node itself is able to cross connect only =
the
Lambda while the interface has a OEO transponder that is able to change =
the
lambda frequency. &nbsp;In this case there are two different =
&#8216;switching
capability&#8217; the spatial one that is performed by the switch =
(lambda 1,
port A) --&gt; (lambda1, port B) and the frequency switching is done by =
the OEO
transponder. &nbsp;Witch kind of interface switching capability I have =
to
advertise?<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>BR<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><br>
Diego<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><b><=
font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Diego
Caviglia</span></font></b></strong></u1:PersonName><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Product
<st1:place w:st=3D"on"><st1:City w:st=3D"on">Line</st1:City> <u1:City =
u2:st=3D"on"><u1:place u2:st=3D"on"><st1:State
 w:st=3D"on">ON</st1:State></st1:place> =
</u1:place></u1:City>BBN</span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>PA
Broadband BNET</span></font><span lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D3 face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><b><=
font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Marconi
S.p.A</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Ericsson
Global <st1:PlaceName w:st=3D"on">Product</st1:PlaceName> <st1:PlaceType =
w:st=3D"on">Center</st1:PlaceType>
- <st1:country-region w:st=3D"on"><st1:place =
w:st=3D"on">Italy</st1:place></st1:country-region></span></font><o:p></o:=
p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Via
Anagnina,203</span></font><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DIT =
style=3D'font-size:10.0pt;font-family:Arial'>0018,
Roma , Italy</span></font><span lang=3DIT><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'><a
href=3D"http://www.ericsson.com/" =
title=3D"http://www.ericsson.com/"><span lang=3DIT><span
title=3D"http://www.ericsson.com/">www.ericsson.com</span></span></a></sp=
an></font><span
lang=3DIT><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D3 face=3D"Times New Roman"><span lang=3DIT =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DIT =
style=3D'font-size:10.0pt;font-family:Arial'>Office:&nbsp;
[phone]</span></font><span lang=3DIT><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DFR =
style=3D'font-size:10.0pt;font-family:Arial'>Fax:
[phone]</span></font><span lang=3DIT><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DFR =
style=3D'font-size:10.0pt;font-family:Arial'>Mobile:
[phone]</span></font><span lang=3DIT><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DFR =
style=3D'font-size:10.0pt;font-family:Arial'>Email:
<a =
href=3D"mailto:[e-mail]">[e-mail]</=
a>&nbsp;</span></font><span
lang=3DFR>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D1 color=3Dgray face=3DArial><span lang=3DEN-GB =
style=3D'font-size:7.5pt;
font-family:Arial;color:gray'>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.<br>
<br>
E-mail including attachments is susceptible to data corruption, =
interception,
unauthorized amendment, tampering and viruses, and we only send and =
receive
emails on the basis that we are not liable for any such corruption,
interception, amendment, tampering or viruses or any consequences =
thereof.</span></font><font
size=3D2 color=3Dgray face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:Arial;color:gray'><o:p></o:p></span></font></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C7BD41.AFA8F18A--