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

From: [email-masked]
Date: Tue, 31 Jul 2007 18:08:33 -0700 (PDT)

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

                    [email-masked], 

                    [email-masked], [email-masked], 

                    [email-masked], [email-masked]

        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 [email-masked].  Requests to be

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

be sent to [email-masked].

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

an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]

        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 [email-masked].  Unless

specifically noted otherwise on the RFC itself, all RFCs are for

unlimited distribution.

Submissions for Requests for Comments should be sent to

[email-masked].  Please consult RFC 2223, Instructions to RFC

Authors, for further information.

The RFC Editor Team

USC/Information Sciences Institute

...

Delivery-date: Tue, 31 Jul 2007 11:42:47 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "tom.petch" <[email-masked]>, <[email-masked]>
Subject: Re: Draft liaison 2 : Notification of new RFCs
Date: Tue, 31 Jul 2007 12:40:57 +0100

Picky, picky, picky.

;-)

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

> ----- Original Message ----- 
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Cc: "Ross Callon" <[email-masked]>; "Scott Bradner" <[email-masked]>
> 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
>

Delivery-date: Tue, 31 Jul 2007 11:42:39 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "tom.petch" <[email-masked]>, <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, <[email-masked]>
Subject: Re: Proposed CCAMP recharter
Date: Tue, 31 Jul 2007 12:40:39 +0100

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

A
----- Original Message ----- 
From: "tom.petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; <[email-masked]>
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" <[email-masked]>
> To: <[email-masked]>
> Cc: "Ross Callon" <[email-masked]>; <[email-masked]>
> 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
>>
>>
>>
> 

Delivery-date: Tue, 31 Jul 2007 10:35:54 +0000
Reply-To: "tom.petch" <[email-masked]>
From: "tom.petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, <[email-masked]>
Subject: Re: Proposed CCAMP recharter
Date: Tue, 31 Jul 2007 10:04:40 +0200

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" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; <[email-masked]>
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 
> 
> 
> 

Delivery-date: Tue, 31 Jul 2007 10:35:47 +0000
Reply-To: "tom.petch" <[email-masked]>
From: "tom.petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: Re: Draft liaison 2 : Notification of new RFCs
Date: Tue, 31 Jul 2007 09:56:19 +0200

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; "Scott Bradner" <[email-masked]>
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

Delivery-date: Mon, 30 Jul 2007 19:18:09 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: CCAMP Note Takers
Date: Mon, 30 Jul 2007 20:16:02 +0100

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 

Delivery-date: Sun, 29 Jul 2007 12:16:25 +0000
Content-class: urn:content-classes:message
Subject: AW: [Pce] New draft on wavelength switched optical networks
Date: Sun, 29 Jul 2007 14:15:03 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

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:[email-masked]]=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 (510) 573-2237

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

Delivery-date: Sun, 29 Jul 2007 11:03:49 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Non-member submission from [Niko Sulkhanishvili <[email-masked]>]   
Date: Sun, 29 Jul 2007 12:00:39 +0100

> From: Niko Sulkhanishvili <[email-masked]>
> To: <[email-masked]>
> CC: <[email-masked]>
> 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:
> [email-masked]

Delivery-date: Fri, 27 Jul 2007 16:17:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Is fate-sharing a must for the bidirectional TE LSP?
Date: Fri, 27 Jul 2007 18:15:31 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Xu Xiaohu" <[email-masked]>, <[email-masked]>

Hi Steven.

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

Regards,

Julien

________________________________

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

Delivery-date: Fri, 27 Jul 2007 10:24:30 +0000
Date: Fri, 27 Jul 2007 12:20:24 +0200
From: Xu Xiaohu <[email-masked]>
Subject: Is fate-sharing a must for the bidirectional TE LSP?
To: [email-masked]

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

Delivery-date: Thu, 26 Jul 2007 22:55:17 +0000
Date: Fri, 27 Jul 2007 00:53:45 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC:  [email-masked], Ross Callon <[email-masked]>,  [email-masked]
Subject: Re: Proposed CCAMP recharter

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

Delivery-date: Thu, 26 Jul 2007 21:26:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, <[email-masked]>
Subject: Proposed CCAMP recharter
Date: Thu, 26 Jul 2007 22:25:20 +0100

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 

Delivery-date: Thu, 26 Jul 2007 20:43:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: RFC 4883 on Benchmarking Terminology for Resource ReservationCapable Routers
Date: Thu, 26 Jul 2007 21:40:47 +0100

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: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
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:    [email-masked],
>                    [email-masked],
>                    [email-masked],
>                    [email-masked]
>
>        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.

Delivery-date: Thu, 26 Jul 2007 20:29:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Draft liaison 2 : Notification of new RFCs
Date: Thu, 26 Jul 2007 21:20:27 +0100

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

Delivery-date: Thu, 26 Jul 2007 04:02:46 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Draft liaison for your review
Date: Thu, 26 Jul 2007 04:56:59 +0100

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 

Delivery-date: Wed, 25 Jul 2007 14:58:55 +0000
Date: Wed, 25 Jul 2007 16:56:57 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: reminder: ospf routing disc.

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.

Delivery-date: Tue, 24 Jul 2007 20:53:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Charter update
Date: Tue, 24 Jul 2007 21:51:18 +0100

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 

Delivery-date: Tue, 24 Jul 2007 18:31:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Updated agenda
Date: Tue, 24 Jul 2007 19:22:57 +0100

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 

Delivery-date: Tue, 24 Jul 2007 16:11:17 +0000
Date: Wed, 25 Jul 2007 00:10:35 +0800
From: MachChen 55527 <[email-masked]>
Subject: =?gb2312?B?u9i4tA==?=:Inter-AS OSPF/ISIS extensions
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]

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 

Delivery-date: Tue, 24 Jul 2007 15:50:47 +0000
Date: Tue, 24 Jul 2007 08:49:01 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Inter-AS OSPF/ISIS extensions

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

Delivery-date: Tue, 24 Jul 2007 01:51:46 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Missing slides
Date: Tue, 24 Jul 2007 02:48:23 +0100

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 

Delivery-date: Sun, 22 Jul 2007 18:14:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: slides
Date: Sun, 22 Jul 2007 19:11:40 +0100

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

Thanks,
Adrian

Delivery-date: Sun, 22 Jul 2007 01:06:22 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'MORTON, ALFRED C, JR. \(AL\), ATTLABS'" <[email-masked]>
Subject: Fw: [CCAMP] Application Performance Metrics BOF
Date: Sat, 21 Jul 2007 19:20:11 +0100

Heads up.

Adrian
----- Original Message ----- 
From: "Al Morton" <[email-masked]>
To: <[email-masked]>
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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ccamp
>

Delivery-date: Sat, 21 Jul 2007 15:14:51 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Agenda updated
Date: Sat, 21 Jul 2007 16:06:10 +0100

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

Delivery-date: Wed, 18 Jul 2007 22:33:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?
Date: Wed, 18 Jul 2007 23:19:47 +0100

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" <[email-masked]>
To: "Dan Li" <[email-masked]>; "ccamp" <[email-masked]>
Cc: "Deborah A. Brungard" <[email-masked]>; "Arun Satyanarayana" 
<[email-masked]>
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" <[email-masked]>
> To: "ccamp" <[email-masked]>
> Cc: "Deborah A. Brungard" <[email-masked]>; "Farrel, Adrian" 
> <[email-masked]>; "Arun Satyanarayana" <[email-masked]>
> 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
>
>
>
> 

Delivery-date: Mon, 16 Jul 2007 16:17:09 +0000
Date: Mon, 16 Jul 2007 11:14:29 -0500
From: Young Lee <[email-masked]>
Subject: RE: New draft on wavelength switched optical networks
To: 'Greg Bernstein' <[email-masked]>, "'Bardalai, Snigdho'" <[email-masked]>
Cc: 'ccamp' <[email-masked]>, [email-masked]

Hi Snigdho,

Please see in-line for my comments.  Thanks.

Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Bernstein
Sent: Saturday, July 14, 2007 10:46 AM
To: Bardalai, Snigdho
Cc: ccamp; Young Lee; [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Greg Bernstein
> Sent: Wednesday, June 27, 2007 12:39 PM
> To: ccamp; [email-masked]
> 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 (510) 573-2237

Delivery-date: Sun, 15 Jul 2007 04:25:48 +0000
Content-class: urn:content-classes:message
Subject: RE: New draft on wavelength switched optical networks
Date: Sat, 14 Jul 2007 23:23:01 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Cc: "ccamp" <[email-masked]>, "Young Lee" <[email-masked]>, <[email-masked]>

Hi Greg,

Some more comments.....

Snigdho

-----Original Message-----
From: Greg Bernstein [mailto:[email-masked]]
Sent: Saturday, July 14, 2007 10:46 AM
To: Bardalai, Snigdho
Cc: ccamp; Young Lee; [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Greg Bernstein
> Sent: Wednesday, June 27, 2007 12:39 PM
> To: ccamp; [email-masked]
> 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 (510) 573-2237

Envelope-to: [email-masked]
Delivery-date: Sat, 14 Jul 2007 20:30:06 +0000
To: [email-masked], [email-masked]
Subject:  RFC 4920 on Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
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:    [email-masked], 

                    [email-masked], 

                    [email-masked],  [email-masked], 

                    [email-masked]

        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 [email-masked].  Requests to be

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

be sent to [email-masked].

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

an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]

        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 [email-masked].  Unless

specifically noted otherwise on the RFC itself, all RFCs are for

unlimited distribution.

Submissions for Requests for Comments should be sent to

[email-masked].  Please consult RFC 2223, Instructions to RFC

Authors, for further information.

The RFC Editor Team

USC/Information Sciences Institute

...

Delivery-date: Sat, 14 Jul 2007 15:48:37 +0000
Date: Sat, 14 Jul 2007 08:46:11 -0700
From: Greg Bernstein <[email-masked]>
To: "Bardalai, Snigdho" <[email-masked]>
CC: ccamp <[email-masked]>, Young Lee <[email-masked]>, [email-masked]
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?
> 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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Greg Bernstein
> Sent: Wednesday, June 27, 2007 12:39 PM
> To: ccamp; [email-masked]
> 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 (510) 573-2237

Delivery-date: Sat, 14 Jul 2007 13:13:30 +0000
Content-class: urn:content-classes:message
Subject: RE: New draft on wavelength switched optical networks
Date: Sat, 14 Jul 2007 08:10:09 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, "ccamp" <[email-masked]>, <[email-masked]>
Cc: "Young Lee" <[email-masked]>

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: [email-masked] [mailto:[email-masked]]On
Behalf Of Greg Bernstein
Sent: Wednesday, June 27, 2007 12:39 PM
To: ccamp; [email-masked]
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 (510) 573-2237

Delivery-date: Fri, 13 Jul 2007 18:17:19 +0000
Date: Fri, 13 Jul 2007 11:14:21 -0700
From: Greg Bernstein <[email-masked]>
To: MEURIC Julien RD-CORE-LAN <[email-masked]>
CC: Young Lee <[email-masked]>, ccamp <[email-masked]>, [email-masked]
Subject: Re: [Pce] New draft on wavelength switched optical networks

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:[email-masked]] 
>
> 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 (510) 573-2237

Delivery-date: Fri, 13 Jul 2007 14:24:22 +0000
Content-class: urn:content-classes:message
Subject: RE: [Pce] New draft on wavelength switched optical networks
Date: Fri, 13 Jul 2007 16:20:43 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Cc: "Young Lee" <[email-masked]>, "ccamp" <[email-masked]>, <[email-masked]>

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:[email-masked]]=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 (510) 573-2237

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

Delivery-date: Fri, 13 Jul 2007 11:17:21 +0000
Date: Fri, 13 Jul 2007 20:14:57 +0900
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, <[email-masked]>
From: Tomonori TAKEDA <[email-masked]>
Subject: RE: I-D     ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 

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:[email-masked]]
 >> Sent: Friday, July 13, 2007 6:53 AM
 >> To: PAPADIMITRIOU Dimitri; [email-masked]
 >> 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:[email-masked]]
 >>  >> Sent: Thursday, July 12, 2007 6:34 AM
 >>  >> To: PAPADIMITRIOU Dimitri; [email-masked]
 >>  >> 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:[email-masked]]
 >>  >>  >> Sent: Tuesday, July 10, 2007 9:51 AM
 >>  >>  >> To: PAPADIMITRIOU Dimitri; [email-masked]
 >>  >>  >> 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: [email-masked]
 >>  >>  >>  >> [mailto:[email-masked]] On Behalf Of
 >> Tomonori TAKEDA
 >>  >>  >>  >> Sent: Monday, July 09, 2007 4:04 AM
 >>  >>  >>  >> To: [email-masked]
 >>  >>  >>  >> 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: [email-masked]
 >>  >>  >>  >>  >From: [email-masked]
 >>  >>  >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >>  >>  >>  >X-Spam-Score: 0.0 (/)
 >>  >>  >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >>  >>  >>  >Cc: [email-masked]
 >>  >>  >>  >>  >Subject: I-D
 >>  >>  >>  >>
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >>  >>  >X-BeenThere: [email-masked]
 >>  >>  >>  >>  >X-Mailman-Version: 2.1.5
 >>  >>  >>  >>  >Reply-To: [email-masked]
 >>  >>  >>  >>  >List-Id: i-d-announce.ietf.org
 >>  >>  >>  >>  >List-Unsubscribe:
 >>  >>  >>  >>
 >>  >>  >>  >>
 >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >>  >>  >> :[email-masked]?subject=unsubscribe>
 >>  >>  >>  >>  >List-Archive:
 >> <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >>  >>  >>  >List-Post: <mailto:[email-masked]>
 >>  >>  >>  >>  >List-Help:
 >>  >> <mailto:[email-masked]?subject=help>
 >>  >>  >>  >>  >List-Subscribe:
 >>  >>  >>  >>
 >>  >>  >>  >>
 >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >>  >>  >> :[email-masked]?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
 >>  >>  >>  >>  >[email-masked] 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:
 >>  >>  >>  >>  >	[email-masked].
 >>  >>  >>  >>  >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: <[email-masked]>
 >>  >>  >>  >>  >
 >>  >>  >>  >>  >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
 >>  >>  >>  >>  >[email-masked]
 >>  >>  >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >>  >>  >>
 >>  >>  >>
 >>  >>  >>
 >>  >>
 >>  >>
 >>  >>
 >>
 >>
 >> 

Delivery-date: Fri, 13 Jul 2007 07:45:34 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D     ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Date: Fri, 13 Jul 2007 09:43:23 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Tomonori TAKEDA" <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
> Sent: Friday, July 13, 2007 6:53 AM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> 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:[email-masked]]
>  >> Sent: Thursday, July 12, 2007 6:34 AM
>  >> To: PAPADIMITRIOU Dimitri; [email-masked]
>  >> 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:[email-masked]]
>  >>  >> Sent: Tuesday, July 10, 2007 9:51 AM
>  >>  >> To: PAPADIMITRIOU Dimitri; [email-masked]
>  >>  >> 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: [email-masked]
>  >>  >>  >> [mailto:[email-masked]] On Behalf Of=20
> Tomonori TAKEDA
>  >>  >>  >> Sent: Monday, July 09, 2007 4:04 AM
>  >>  >>  >> To: [email-masked]
>  >>  >>  >> 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: [email-masked]
>  >>  >>  >>  >From: [email-masked]
>  >>  >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >>  >>  >>  >X-Spam-Score: 0.0 (/)
>  >>  >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >>  >>  >>  >Cc: [email-masked]
>  >>  >>  >>  >Subject: I-D
>  >>  >>  >>=20
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >>  >>  >X-BeenThere: [email-masked]
>  >>  >>  >>  >X-Mailman-Version: 2.1.5
>  >>  >>  >>  >Reply-To: [email-masked]
>  >>  >>  >>  >List-Id: i-d-announce.ietf.org
>  >>  >>  >>  >List-Unsubscribe:
>  >>  >>  >>
>  >>  >>  >>=20
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >>  >>  >> :[email-masked]?subject=3Dunsubscribe>
>  >>  >>  >>  >List-Archive:=20
> <http://www1.ietf.org/pipermail/i-d-announce>
>  >>  >>  >>  >List-Post: <mailto:[email-masked]>
>  >>  >>  >>  >List-Help:
>  >> <mailto:[email-masked]?subject=3Dhelp>
>  >>  >>  >>  >List-Subscribe:
>  >>  >>  >>
>  >>  >>  >>=20
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >>  >>  >> :[email-masked]?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
>  >>  >>  >>  >[email-masked] 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:
>  >>  >>  >>  >	[email-masked].
>  >>  >>  >>  >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: <[email-masked]>
>  >>  >>  >>  >
>  >>  >>  >>  >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
>  >>  >>  >>  >[email-masked]
>  >>  >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>
>  >>  >>
>  >>
>  >>
>  >>=20
>=20
>=20
>=20

Delivery-date: Fri, 13 Jul 2007 04:56:45 +0000
Date: Fri, 13 Jul 2007 13:53:28 +0900
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, <[email-masked]>
From: Tomonori TAKEDA <[email-masked]>
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:[email-masked]]
 >> Sent: Thursday, July 12, 2007 6:34 AM
 >> To: PAPADIMITRIOU Dimitri; [email-masked]
 >> 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:[email-masked]]
 >>  >> Sent: Tuesday, July 10, 2007 9:51 AM
 >>  >> To: PAPADIMITRIOU Dimitri; [email-masked]
 >>  >> 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: [email-masked]
 >>  >>  >> [mailto:[email-masked]] On Behalf Of Tomonori TAKEDA
 >>  >>  >> Sent: Monday, July 09, 2007 4:04 AM
 >>  >>  >> To: [email-masked]
 >>  >>  >> 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: [email-masked]
 >>  >>  >>  >From: [email-masked]
 >>  >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >>  >>  >X-Spam-Score: 0.0 (/)
 >>  >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >>  >>  >Cc: [email-masked]
 >>  >>  >>  >Subject: I-D
 >>  >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >>  >X-BeenThere: [email-masked]
 >>  >>  >>  >X-Mailman-Version: 2.1.5
 >>  >>  >>  >Reply-To: [email-masked]
 >>  >>  >>  >List-Id: i-d-announce.ietf.org
 >>  >>  >>  >List-Unsubscribe:
 >>  >>  >>
 >>  >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >>  >> :[email-masked]?subject=unsubscribe>
 >>  >>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >>  >>  >List-Post: <mailto:[email-masked]>
 >>  >>  >>  >List-Help:
 >> <mailto:[email-masked]?subject=help>
 >>  >>  >>  >List-Subscribe:
 >>  >>  >>
 >>  >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >>  >> :[email-masked]?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
 >>  >>  >>  >[email-masked] 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:
 >>  >>  >>  >	[email-masked].
 >>  >>  >>  >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: <[email-masked]>
 >>  >>  >>  >
 >>  >>  >>  >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
 >>  >>  >>  >[email-masked]
 >>  >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>  >>  >>
 >>  >>  >>
 >>  >>  >>
 >>  >>  >>
 >>  >>
 >>  >>
 >>
 >>
 >> 

Delivery-date: Thu, 12 Jul 2007 07:26:08 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D    ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Date: Thu, 12 Jul 2007 09:24:03 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Tomonori TAKEDA" <[email-masked]>, <[email-masked]>

hi tomonori,

> -----Original Message-----
> From: Tomonori TAKEDA [mailto:[email-masked]]=20
> Sent: Thursday, July 12, 2007 6:34 AM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> 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:[email-masked]]
>  >> Sent: Tuesday, July 10, 2007 9:51 AM
>  >> To: PAPADIMITRIOU Dimitri; [email-masked]
>  >> 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: [email-masked]
>  >>  >> [mailto:[email-masked]] On Behalf Of Tomonori TAKEDA
>  >>  >> Sent: Monday, July 09, 2007 4:04 AM
>  >>  >> To: [email-masked]
>  >>  >> 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: [email-masked]
>  >>  >>  >From: [email-masked]
>  >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >>  >>  >X-Spam-Score: 0.0 (/)
>  >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >>  >>  >Cc: [email-masked]
>  >>  >>  >Subject: I-D
>  >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >>  >X-BeenThere: [email-masked]
>  >>  >>  >X-Mailman-Version: 2.1.5
>  >>  >>  >Reply-To: [email-masked]
>  >>  >>  >List-Id: i-d-announce.ietf.org
>  >>  >>  >List-Unsubscribe:
>  >>  >>
>  >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >>  >> :[email-masked]?subject=3Dunsubscribe>
>  >>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>  >>  >>  >List-Post: <mailto:[email-masked]>
>  >>  >>  >List-Help:=20
> <mailto:[email-masked]?subject=3Dhelp>
>  >>  >>  >List-Subscribe:
>  >>  >>
>  >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >>  >> :[email-masked]?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
>  >>  >>  >[email-masked] 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:
>  >>  >>  >	[email-masked].
>  >>  >>  >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: <[email-masked]>
>  >>  >>  >
>  >>  >>  >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
>  >>  >>  >[email-masked]
>  >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
>  >>  >>
>  >>  >>
>  >>  >>
>  >>  >>
>  >>
>  >>=20
>=20
>=20
>=20

Delivery-date: Thu, 12 Jul 2007 04:36:55 +0000
Date: Thu, 12 Jul 2007 13:33:43 +0900
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, <[email-masked]>
From: Tomonori TAKEDA <[email-masked]>
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:[email-masked]]
 >> Sent: Tuesday, July 10, 2007 9:51 AM
 >> To: PAPADIMITRIOU Dimitri; [email-masked]
 >> 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: [email-masked]
 >>  >> [mailto:[email-masked]] On Behalf Of Tomonori TAKEDA
 >>  >> Sent: Monday, July 09, 2007 4:04 AM
 >>  >> To: [email-masked]
 >>  >> 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: [email-masked]
 >>  >>  >From: [email-masked]
 >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >>  >X-Spam-Score: 0.0 (/)
 >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >>  >Cc: [email-masked]
 >>  >>  >Subject: I-D
 >>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >X-BeenThere: [email-masked]
 >>  >>  >X-Mailman-Version: 2.1.5
 >>  >>  >Reply-To: [email-masked]
 >>  >>  >List-Id: i-d-announce.ietf.org
 >>  >>  >List-Unsubscribe:
 >>  >>
 >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >> :[email-masked]?subject=unsubscribe>
 >>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >>  >List-Post: <mailto:[email-masked]>
 >>  >>  >List-Help: <mailto:[email-masked]?subject=help>
 >>  >>  >List-Subscribe:
 >>  >>
 >>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >>  >> :[email-masked]?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
 >>  >>  >[email-masked] 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:
 >>  >>  >	[email-masked].
 >>  >>  >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: <[email-masked]>
 >>  >>  >
 >>  >>  >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
 >>  >>  >[email-masked]
 >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>  >>
 >>  >>
 >>  >>
 >>  >>
 >>
 >> 

Delivery-date: Wed, 11 Jul 2007 18:18:05 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ted-mib-02.txt 
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 11 Jul 2007 01:31:03 +0000
Date: Wed, 11 Jul 2007 10:26:28 +0900 (JST)
To: [email-masked]
Cc: [email-masked]
Subject: Re: new draft about signaling for a bidirectionl lightpath
From: Hiroaki Harai <[email-masked]>

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)" <[email-masked]>
Subject: RE: new draft about signaling for a bidirectionl lightpath
Date: Tue, 10 Jul 2007 08:52:17 +0200
Message-ID: <[email-masked]=
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:[email-masked]] =

> Sent: sabato 7 luglio 2007 4.01
> To: Diego Caviglia (GA/ERI); [email-masked]
> 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)" <[email-masked]>
> Subject: RE: new draft about signaling for a bidirectionl lightpath
> Date: Fri, 6 Jul 2007 15:00:13 +0200
> Message-ID: <[email-masked].=
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: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Hiroaki Harai
> > Sent: venerd=EC 6 luglio 2007 3.10
> > To: [email-masked]
> > 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: [email-masked];  Phone: +81-42-327-5418;  FAX: +81-42-327-=
6680
> > =

> > =

> =

Delivery-date: Tue, 10 Jul 2007 20:16:29 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-04.txt 
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 10 Jul 2007 18:17:51 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-eval-03.txt 
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 10 Jul 2007 10:57:28 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D   ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Date: Tue, 10 Jul 2007 12:54:18 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Tomonori TAKEDA" <[email-masked]>, <[email-masked]>

hi tomonori - see inline=20

> -----Original Message-----
> From: Tomonori TAKEDA [mailto:[email-masked]]=20
> Sent: Tuesday, July 10, 2007 9:51 AM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> 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: [email-masked]
>  >> [mailto:[email-masked]] On Behalf Of Tomonori TAKEDA
>  >> Sent: Monday, July 09, 2007 4:04 AM
>  >> To: [email-masked]
>  >> 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: [email-masked]
>  >>  >From: [email-masked]
>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >>  >X-Spam-Score: 0.0 (/)
>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >>  >Cc: [email-masked]
>  >>  >Subject: I-D
>  >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >X-BeenThere: [email-masked]
>  >>  >X-Mailman-Version: 2.1.5
>  >>  >Reply-To: [email-masked]
>  >>  >List-Id: i-d-announce.ietf.org
>  >>  >List-Unsubscribe:
>  >>
>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >> :[email-masked]?subject=3Dunsubscribe>
>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>  >>  >List-Post: <mailto:[email-masked]>
>  >>  >List-Help: <mailto:[email-masked]?subject=3Dhelp>
>  >>  >List-Subscribe:
>  >>
>  >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
>  >> :[email-masked]?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
>  >>  >[email-masked] 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:
>  >>  >	[email-masked].
>  >>  >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: <[email-masked]>
>  >>  >
>  >>  >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
>  >>  >[email-masked]
>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
>  >>
>  >>
>  >>
>  >>=20
>=20
>=20
>=20

Delivery-date: Tue, 10 Jul 2007 07:51:54 +0000
Date: Tue, 10 Jul 2007 16:50:46 +0900
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, <[email-masked]>
From: Tomonori TAKEDA <[email-masked]>
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).

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: [email-masked]
 >> [mailto:[email-masked]] On Behalf Of Tomonori TAKEDA
 >> Sent: Monday, July 09, 2007 4:04 AM
 >> To: [email-masked]
 >> 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: [email-masked]
 >>  >From: [email-masked]
 >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >X-Spam-Score: 0.0 (/)
 >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >Cc: [email-masked]
 >>  >Subject: I-D
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >X-BeenThere: [email-masked]
 >>  >X-Mailman-Version: 2.1.5
 >>  >Reply-To: [email-masked]
 >>  >List-Id: i-d-announce.ietf.org
 >>  >List-Unsubscribe:
 >>
 >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >> :[email-masked]?subject=unsubscribe>
 >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >List-Post: <mailto:[email-masked]>
 >>  >List-Help: <mailto:[email-masked]?subject=help>
 >>  >List-Subscribe:
 >>
 >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
 >> :[email-masked]?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
 >>  >[email-masked] 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:
 >>  >	[email-masked].
 >>  >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: <[email-masked]>
 >>  >
 >>  >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
 >>  >[email-masked]
 >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>
 >>
 >>
 >> 

Delivery-date: Tue, 10 Jul 2007 07:36:02 +0000
Date: Tue, 10 Jul 2007 16:34:41 +0900
To: Meral Shirazipour <[email-masked]>
From: Tomonori TAKEDA <[email-masked]>
Subject: Re: Fwd: I-D   ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
Cc: "[email-masked]" <[email-masked]>, [email-masked]

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 <[email-masked]>:
 >
 >> 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 <[email-masked]>:
 >>  >
 >>  >> 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: [email-masked]
 >>  >>  >From: [email-masked]
 >>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >>  >X-Spam-Score: 0.0 (/)
 >>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >>  >Cc: [email-masked]
 >>  >>  >Subject: I-D
 >> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >>  >X-BeenThere: [email-masked]
 >>  >>  >X-Mailman-Version: 2.1.5
 >>  >>  >Reply-To: [email-masked]
 >>  >>  >List-Id: i-d-announce.ietf.org
 >>  >>  >List-Unsubscribe:
 >>  >>
 >>
 >>><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=unsubscribe>
 >>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >>  >List-Post: <mailto:[email-masked]>
 >>  >>  >List-Help: <mailto:[email-masked]?subject=help>
 >>  >>  >List-Subscribe:
 >>  >>
 >>
 >>><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?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
 >>  >>  >[email-masked] 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:
 >>  >>  >	[email-masked].
 >>  >>  >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: <[email-masked]>
 >>  >>  >
 >>  >>  >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
 >>  >>  >[email-masked]
 >>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>  >>
 >>  >>
 >>  >>
 >>  >>
 >>
 >>
 >>
 >> 

Delivery-date: Tue, 10 Jul 2007 07:05:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Tue, 10 Jul 2007 09:04:21 +0200
From: "Diego Caviglia (GA/ERI)" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, "Wataru Imajuku" <[email-masked]>
Cc: "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

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

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

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

Delivery-date: Tue, 10 Jul 2007 06:55:27 +0000
Content-class: urn:content-classes:message
Subject: RE: new draft about signaling for a bidirectionl lightpath
Date: Tue, 10 Jul 2007 08:52:17 +0200
From: "Diego Caviglia (GA/ERI)" <[email-masked]>
To: "Hiroaki Harai" <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
Sent: sabato 7 luglio 2007 4.01
To: Diego Caviglia (GA/ERI); [email-masked]
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)" <[email-masked]>
Subject: RE: new draft about signaling for a bidirectionl lightpath
Date: Fri, 6 Jul 2007 15:00:13 +0200
Message-ID: =
<[email-masked]>

>=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: [email-masked] [mailto:[email-masked]] On =
Behalf Of Hiroaki Harai
> Sent: venerd=EC 6 luglio 2007 3.10
> To: [email-masked]
> 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: [email-masked];  Phone: +81-42-327-5418;  FAX: =
+81-42-327-6680
>=20
>=20

Delivery-date: Mon, 09 Jul 2007 21:48:10 +0000
Content-class: urn:content-classes:message
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
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Hassan Sheikh \(hassans\)" <[email-masked]>, "Igor Bryskin" <[email-masked]>, "Zafar Ali \(zali\)" <[email-masked]>, "Lou Berger" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Tomohiro Otani" <[email-masked]>

=20

> -----Original Message-----
> From: Hassan Sheikh (hassans) [mailto:[email-masked]]=20
> Sent: Monday, July 09, 2007 10:15 PM
> To: PAPADIMITRIOU Dimitri; Igor Bryskin; Zafar Ali (zali);=20
> Lou Berger; Igor Bryskin; [email-masked]
> 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:[email-masked]]=20
> Sent: Monday, July 09, 2007 2:39 PM
> To: Igor Bryskin; Zafar Ali (zali); Lou Berger; Igor Bryskin;
> [email-masked]
> 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:[email-masked]]
> > Sent: Monday, July 09, 2007 7:32 PM
> > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger;=20
> Igor Bryskin;
>=20
> > [email-masked]
> > 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:[email-masked]]
> > Sent: Monday, July 09, 2007 12:18 PM
> > To: Igor Bryskin; Zafar Ali (zali); Lou Berger; Igor Bryskin;=20
> > [email-masked]
> > 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:[email-masked]]
> > > Sent: Monday, July 09, 2007 5:46 PM
> > > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor=20
> > > Bryskin; [email-masked]
> > > 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: [email-masked]=20
> [mailto:[email-masked]] On=20
> > > Behalf Of PAPADIMITRIOU Dimitri
> > > Sent: Saturday, July 07, 2007 3:54 PM
> > > To: Zafar Ali (zali); Lou Berger; Igor Bryskin; [email-masked]
> > > 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: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
> > > > Sent: Thursday, July 05, 2007 6:39 PM
> > > > To: Lou Berger; Igor Bryskin; [email-masked]
> > > > 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

Delivery-date: Mon, 09 Jul 2007 21:32:25 +0000
Date: Mon, 09 Jul 2007 17:27:16 +0200
From: Huub van Helvoort <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: Dan Li <[email-masked]>, ccamp <[email-masked]>,  "Deborah A. Brungard" <[email-masked]>
Subject: Re: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?

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" <[email-masked]>
> To: "ccamp" <[email-masked]>
> Cc: "Deborah A. Brungard" <[email-masked]>; "Farrel, Adrian" 
> <[email-masked]>; "Arun Satyanarayana" <[email-masked]>
> 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...

Delivery-date: Mon, 09 Jul 2007 21:13:17 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D  ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Date: Mon, 9 Jul 2007 23:10:47 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Tomonori TAKEDA" <[email-masked]>, <[email-masked]>

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: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Tomonori TAKEDA
> Sent: Monday, July 09, 2007 4:04 AM
> To: [email-masked]
> 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: [email-masked]
>  >From: [email-masked]
>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >X-Spam-Score: 0.0 (/)
>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >Cc: [email-masked]
>  >Subject: I-D=20
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >X-BeenThere: [email-masked]
>  >X-Mailman-Version: 2.1.5
>  >Reply-To: [email-masked]
>  >List-Id: i-d-announce.ietf.org
>  >List-Unsubscribe:
> =20
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
> :[email-masked]?subject=3Dunsubscribe>
>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>  >List-Post: <mailto:[email-masked]>
>  >List-Help: <mailto:[email-masked]?subject=3Dhelp>
>  >List-Subscribe:
> =20
> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto
> :[email-masked]?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
>  >[email-masked] 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:
>  >	[email-masked].
>  >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: <[email-masked]>
>  >
>  >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
>  >[email-masked]
>  >https://www1.ietf.org/mailman/listinfo/i-d-announce=20
>=20
>=20
>=20
>=20

Delivery-date: Mon, 09 Jul 2007 18:43:36 +0000
Content-class: urn:content-classes:message
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
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Zafar Ali \(zali\)" <[email-masked]>, "Lou Berger" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Hassan Sheikh \(hassans\)" <[email-masked]>, "Tomohiro Otani" <[email-masked]>

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:[email-masked]]=20
> Sent: Monday, July 09, 2007 7:32 PM
> To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor=20
> Bryskin; [email-masked]
> 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:[email-masked]]=20
> Sent: Monday, July 09, 2007 12:18 PM
> To: Igor Bryskin; Zafar Ali (zali); Lou Berger; Igor Bryskin;
> [email-masked]
> 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:[email-masked]]=20
> > Sent: Monday, July 09, 2007 5:46 PM
> > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor=20
> > Bryskin; [email-masked]
> > 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: [email-masked] [mailto:[email-masked]] On
> > Behalf Of PAPADIMITRIOU Dimitri
> > Sent: Saturday, July 07, 2007 3:54 PM
> > To: Zafar Ali (zali); Lou Berger; Igor Bryskin; [email-masked]
> > 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: [email-masked]=20
> > > [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
> > > Sent: Thursday, July 05, 2007 6:39 PM
> > > To: Lou Berger; Igor Bryskin; [email-masked]
> > > 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

Delivery-date: Mon, 09 Jul 2007 16:32:24 +0000
Date: Mon, 09 Jul 2007 09:31:30 -0700
From: Greg Bernstein <[email-masked]>
To: Wataru Imajuku <[email-masked]>
CC: "Diego Caviglia (GA/ERI)" <[email-masked]>, MEURIC Julien RD-CORE-LAN <[email-masked]>, [email-masked]
Subject: Re: Switching Capability of Photonic Links with Transponder

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:[email-masked]>mailto:[email-masked]]
>> Sent: mercoled?4 luglio 2007 18.47
>> To: Diego Caviglia (GA/ERI); [email-masked]
>> 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:[email-masked]>mailto:[email-masked]] 
>>
>> 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:[email-masked]>mailto:[email-masked]] 
>>
>> Sent: marted?3 luglio 2007 19.21
>>
>> To: Diego Caviglia (GA/ERI); [email-masked]
>>
>> 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: [email-masked] [<mailto:[email-masked]>mailto:[email-masked]] 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:  +39 010 600 3736
>>
>> Fax: +39 010 600 3493
>>
>> Mobile: +39 335 7181762
>>
>> Email: [email-masked]  
>>
>> This communication is confidential and intended solely for the
>>
>> addressee(s). Any unauthorized review, use, disclosure or distribution
>>
>> is prohibited. If you believe this message has been sent to you in
>>
>> error, please notify the sender by replying to this transmission and
>>
>> delete the message without disclosing it. Thank you.
>>
>> 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: +81-46-859-4315
> FAX: +81-46-859-5541
>
>
>
>
>   

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

--------------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:[email-masked]"
 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:[email-masked]">&lt;mailto:[email-masked]&gt;</a><a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]
Sent: mercoled&#65533;4 luglio 2007 18.47
To: Diego Caviglia (GA/ERI); <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</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:[email-masked]">&lt;mailto:[email-masked]&gt;</a><a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</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:[email-masked]">&lt;mailto:[email-masked]&gt;</a><a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] 

Sent: marted&#65533;3 luglio 2007 19.21

To: Diego Caviglia (GA/ERI); <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</a> [<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;mailto:[email-masked]&gt;</a><a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</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:  +39 010 600 3736

Fax: +39 010 600 3493

Mobile: +39 335 7181762

Email: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>  

This communication is confidential and intended solely for the

addressee(s). Any unauthorized review, use, disclosure or distribution

is prohibited. If you believe this message has been sent to you in

error, please notify the sender by replying to this transmission and

delete the message without disclosing it. Thank you.

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: +81-46-859-4315
FAX: +81-46-859-5541

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

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

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

Delivery-date: Mon, 09 Jul 2007 16:19:48 +0000
Content-class: urn:content-classes:message
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
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Zafar Ali \(zali\)" <[email-masked]>, "Lou Berger" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Hassan Sheikh \(hassans\)" <[email-masked]>, "Tomohiro Otani" <[email-masked]>

=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:[email-masked]]=20
> Sent: Monday, July 09, 2007 5:46 PM
> To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor=20
> Bryskin; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On
> Behalf Of PAPADIMITRIOU Dimitri
> Sent: Saturday, July 07, 2007 3:54 PM
> To: Zafar Ali (zali); Lou Berger; Igor Bryskin; [email-masked]
> 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: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
> > Sent: Thursday, July 05, 2007 6:39 PM
> > To: Lou Berger; Igor Bryskin; [email-masked]
> > 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

Delivery-date: Mon, 09 Jul 2007 14:34:07 +0000
Date: Mon, 09 Jul 2007 10:30:58 -0400
From: Meral Shirazipour <[email-masked]>
To: Tomonori TAKEDA <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Fwd: I-D   ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt

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

> 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 <[email-masked]>:
>  >
>  >> 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: [email-masked]
>  >>  >From: [email-masked]
>  >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
>  >>  >X-Spam-Score: 0.0 (/)
>  >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
>  >>  >Cc: [email-masked]
>  >>  >Subject: I-D
> ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
>  >>  >X-BeenThere: [email-masked]
>  >>  >X-Mailman-Version: 2.1.5
>  >>  >Reply-To: [email-masked]
>  >>  >List-Id: i-d-announce.ietf.org
>  >>  >List-Unsubscribe:
>  >>
> 
>><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=unsubscribe>
>  >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>  >>  >List-Post: <mailto:[email-masked]>
>  >>  >List-Help: <mailto:[email-masked]?subject=help>
>  >>  >List-Subscribe:
>  >>
> 
>><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?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
>  >>  >[email-masked] 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:
>  >>  >	[email-masked].
>  >>  >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: <[email-masked]>
>  >>  >
>  >>  >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
>  >>  >[email-masked]
>  >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
>  >>
>  >>
>  >>
>  >>
>
>
>
>

Delivery-date: Mon, 09 Jul 2007 11:23:23 +0000
Date: Mon, 09 Jul 2007 20:21:58 +0900
To: "Diego Caviglia (GA/ERI)" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>
From: Wataru Imajuku <[email-masked]>
Subject: RE: Switching Capability of Photonic Links with Transponder

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:[email-masked]>mailto:[email-masked]]
>Sent: mercoled$Bw(B4 luglio 2007 18.47
>To: Diego Caviglia (GA/ERI); [email-masked]
>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:[email-masked]>mailto:[email-masked]] 
>
>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:[email-masked]>mailto:[email-masked]] 
>
>Sent: marted$Bw(B3 luglio 2007 19.21
>
>To: Diego Caviglia (GA/ERI); [email-masked]
>
>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: [email-masked] [<mailto:[email-masked]>mailto:[email-masked]] 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:  +39 010 600 3736
>
>Fax: +39 010 600 3493
>
>Mobile: +39 335 7181762
>
>Email: [email-masked]  
>
>This communication is confidential and intended solely for the
>
>addressee(s). Any unauthorized review, use, disclosure or distribution
>
>is prohibited. If you believe this message has been sent to you in
>
>error, please notify the sender by replying to this transmission and
>
>delete the message without disclosing it. Thank you.
>
>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: +81-46-859-4315
FAX: +81-46-859-5541

Delivery-date: Mon, 09 Jul 2007 07:37:48 +0000
Date: Mon, 09 Jul 2007 16:35:04 +0900
To: Meral Shirazipour <[email-masked]>
From: Tomonori TAKEDA <[email-masked]>
Subject: Re: Fwd: I-D  ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
Cc: [email-masked]

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 <[email-masked]>:
 >
 >> 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: [email-masked]
 >>  >From: [email-masked]
 >>  >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >>  >X-Spam-Score: 0.0 (/)
 >>  >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >>  >Cc: [email-masked]
 >>  >Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >>  >X-BeenThere: [email-masked]
 >>  >X-Mailman-Version: 2.1.5
 >>  >Reply-To: [email-masked]
 >>  >List-Id: i-d-announce.ietf.org
 >>  >List-Unsubscribe:
 >>
 >><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=unsubscribe>
 >>  >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >>  >List-Post: <mailto:[email-masked]>
 >>  >List-Help: <mailto:[email-masked]?subject=help>
 >>  >List-Subscribe:
 >>
 >><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?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
 >>  >[email-masked] 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:
 >>  >	[email-masked].
 >>  >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: <[email-masked]>
 >>  >
 >>  >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
 >>  >[email-masked]
 >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >>
 >>
 >>
 >> 

Delivery-date: Mon, 09 Jul 2007 02:14:02 +0000
Date: Mon, 09 Jul 2007 11:04:03 +0900
To: [email-masked]
From: Tomonori TAKEDA <[email-masked]>
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: [email-masked]
 >From: [email-masked]
 >Date: Fri, 06 Jul 2007 14:15:01 -0400
 >X-Spam-Score: 0.0 (/)
 >X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
 >Cc: [email-masked]
 >Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt
 >X-BeenThere: [email-masked]
 >X-Mailman-Version: 2.1.5
 >Reply-To: [email-masked]
 >List-Id: i-d-announce.ietf.org
 >List-Unsubscribe:
 ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=unsubscribe>
 >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
 >List-Post: <mailto:[email-masked]>
 >List-Help: <mailto:[email-masked]?subject=help>
 >List-Subscribe:
 ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?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
 >[email-masked] 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:
 >	[email-masked].
 >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: <[email-masked]>
 >
 >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
 >[email-masked]
 >https://www1.ietf.org/mailman/listinfo/i-d-announce 

Delivery-date: Sun, 08 Jul 2007 19:13:36 +0000
Date: Sun, 08 Jul 2007 12:11:18 -0700
From: Arun Satyanarayana <[email-masked]>
Organization: Cisco Systems
To: Adrian Farrel <[email-masked]>, ccamp <[email-masked]>
CC: Dan Li <[email-masked]>, "Deborah A. Brungard" <[email-masked]>, "Arun Satyanarayana (asatyana)" <[email-masked]>
Subject: Re: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?

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" <[email-masked]>
> To: "ccamp" <[email-masked]>
> Cc: "Deborah A. Brungard" <[email-masked]>; "Farrel, Adrian" 
> <[email-masked]>; "Arun Satyanarayana" <[email-masked]>
> 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 
> 

Delivery-date: Sun, 08 Jul 2007 15:22:51 +0000
Date: Sun, 08 Jul 2007 23:17:21 +0800
From: Dan Li <[email-masked]>
Subject: Re: Support for draft-li-ccamp-gr-description-00.txt as WG I-D?
To: Adrian Farrel <[email-masked]>, ccamp <[email-masked]>
Cc: "Deborah A. Brungard" <[email-masked]>, Arun Satyanarayana <[email-masked]>

Hi,

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

Thanks,

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Dan Li" <[email-masked]>; "ccamp" <[email-masked]>
Cc: "Deborah A. Brungard" <[email-masked]>; "Arun Satyanarayana" 
<[email-masked]>
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" <[email-masked]>
> To: "ccamp" <[email-masked]>
> Cc: "Deborah A. Brungard" <[email-masked]>; "Farrel, Adrian" 
> <[email-masked]>; "Arun Satyanarayana" <[email-masked]>
> 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
>
>
> 

Delivery-date: Sun, 08 Jul 2007 10:30:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: First draft agenda published
Date: Sun, 8 Jul 2007 11:23:46 +0100

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 

Delivery-date: Sat, 07 Jul 2007 19:57:34 +0000
Content-class: urn:content-classes:message
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
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Zafar Ali \(zali\)" <[email-masked]>, "Lou Berger" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Hassan Sheikh \(hassans\)" <[email-masked]>, "Tomohiro Otani" <[email-masked]>

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: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
> Sent: Thursday, July 05, 2007 6:39 PM
> To: Lou Berger; Igor Bryskin; [email-masked]
> 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

Delivery-date: Sat, 07 Jul 2007 13:48:04 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt 
Date: Sat, 7 Jul 2007 15:44:25 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Zafar Ali" <[email-masked]>, <[email-masked]>
Cc: "Jean Philippe Vasseur" <[email-masked]>, "Anca Zamfir" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>

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: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Monday, June 11, 2007 3:12 PM
> To: Zafar Ali; [email-masked]
> Cc: 'Jean Philippe Vasseur'; 'Anca Zamfir';=20
> [email-masked]; 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: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> 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

Delivery-date: Sat, 07 Jul 2007 02:06:20 +0000
Date: Sat, 07 Jul 2007 11:01:16 +0900 (JST)
To: [email-masked], [email-masked]
Subject: Re: new draft about signaling for a bidirectionl lightpath
From: Hiroaki Harai <[email-masked]>

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)" <[email-masked]>
Subject: RE: new draft about signaling for a bidirectionl lightpath
Date: Fri, 6 Jul 2007 15:00:13 +0200
Message-ID: <[email-masked]=
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: [email-masked] [mailto:[email-masked]] On B=
ehalf Of Hiroaki Harai
> Sent: venerd=EC 6 luglio 2007 3.10
> To: [email-masked]
> 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: [email-masked];  Phone: +81-42-327-5418;  FAX: +81-42-327-66=
80
> =

> =

Delivery-date: Fri, 06 Jul 2007 18:17:41 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D  ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 06 Jul 2007 13:01:32 +0000
Content-class: urn:content-classes:message
Subject: RE: new draft about signaling for a bidirectionl lightpath
Date: Fri, 6 Jul 2007 15:00:13 +0200
From: "Diego Caviglia (GA/ERI)" <[email-masked]>
To: "Hiroaki Harai" <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On =
Behalf Of Hiroaki Harai
Sent: venerd=EC 6 luglio 2007 3.10
To: [email-masked]
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: [email-masked];  Phone: +81-42-327-5418;  FAX: +81-42-327-6680

Delivery-date: Fri, 06 Jul 2007 12:48:01 +0000
Date: Fri, 06 Jul 2007 08:44:37 -0400
To: "Diego Caviglia (GA/ERI)" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Switching Capability of Photonic Links with Transponder
Cc: "Greg Bernstein" <[email-masked]>,<[email-masked]>

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:[email-masked]]
>Sent: gioved=EC 5 luglio 2007 18.39
>To: Diego Caviglia (GA/ERI)
>Cc: [email-masked]
>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:  +39 010 600 3736
>Fax: +39 010 600 3493
>Mobile: +39 335 7181762
>Email: <mailto:[email-masked]>[email-masked]
>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 (510) 573-2237
>
>

Delivery-date: Fri, 06 Jul 2007 07:17:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Fri, 6 Jul 2007 09:14:09 +0200
From: "Diego Caviglia (GA/ERI)" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Cc: <[email-masked]>

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:[email-masked]]=20
Sent: gioved=EC 5 luglio 2007 18.39
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]
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:  +39 010 600 3736

Fax: +39 010 600 3493

Mobile: +39 335 7181762

Email: [email-masked] =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 (510) 573-2237
=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:[email-masked]] =
<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> =
[email-masked]<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; +39 010 600 =
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: +39 010 600 =
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:[email-masked]" =
moz-do-not-send=3Dtrue>[email-masked]</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--

Delivery-date: Fri, 06 Jul 2007 07:17:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Fri, 6 Jul 2007 09:14:55 +0200
From: "Diego Caviglia (GA/ERI)" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Cc: "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
Sent: gioved=EC 5 luglio 2007 18.49
To: Diego Caviglia (GA/ERI)
Cc: MEURIC Julien RD-CORE-LAN; [email-masked]
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:[email-masked]]
Sent: mercoled=EC 4 luglio 2007 18.47
To: Diego Caviglia (GA/ERI); [email-masked]
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:[email-masked]]=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:[email-masked]]=20

Sent: marted=EC 3 luglio 2007 19.21

To: Diego Caviglia (GA/ERI); [email-masked]

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: [email-masked] [mailto:[email-masked]] 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:  +39 010 600 3736

Fax: +39 010 600 3493

Mobile: +39 335 7181762

Email: [email-masked] =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 (510) 573-2237
=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:[email-masked]] =
<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;
[email-masked]<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:[email-masked]" =
moz-do-not-send=3Dtrue>mailto:[email-masked]</a>]<br>
Sent: mercoled=EC 4 luglio 2007 18.47<br>
To: Diego Caviglia (GA/ERI); <a =
href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]" =
moz-do-not-send=3Dtrue>mailto:[email-masked]</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:[email-masked]" =
moz-do-not-send=3Dtrue>mailto:[email-masked]</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:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</a>
[<a href=3D"mailto:[email-masked]" =
moz-do-not-send=3Dtrue>mailto:[email-masked]</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; +39 010 600 =
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: +39 010 600 =
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"'>:
+39 335 7181762</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:[email-masked]">[email-masked]</=
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--

Delivery-date: Fri, 06 Jul 2007 01:12:23 +0000
Date: Fri, 06 Jul 2007 10:10:16 +0900 (JST)
To: [email-masked]
Subject: new draft about signaling for a bidirectionl lightpath
From: Hiroaki Harai <[email-masked]>

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: [email-masked];  Phone: +81-42-327-5418;  FAX: +81-42-327-6680

Delivery-date: Fri, 06 Jul 2007 01:08:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Liaison situation
Date: Thu, 5 Jul 2007 23:22:35 +0100

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 

Delivery-date: Thu, 05 Jul 2007 22:18:01 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt 
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 05 Jul 2007 16:55:03 +0000
Date: Thu, 05 Jul 2007 09:48:30 -0700
From: Greg Bernstein <[email-masked]>
To: "Diego Caviglia (GA/ERI)" <[email-masked]>
CC: MEURIC Julien RD-CORE-LAN <[email-masked]>, [email-masked]
Subject: Re: Switching Capability of Photonic Links with Transponder

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:[email-masked]]
> Sent: mercoledì 4 luglio 2007 18.47
> To: Diego Caviglia (GA/ERI); [email-masked]
> 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:[email-masked]]
>
> 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:[email-masked]]
>
> Sent: martedì 3 luglio 2007 19.21
>
> To: Diego Caviglia (GA/ERI); [email-masked]
>
> 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: [email-masked] [mailto:[email-masked]] 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:  +39 010 600 3736
>
> Fax: +39 010 600 3493
>
> Mobile: +39 335 7181762
>
> Email: [email-masked] 
>
> This communication is confidential and intended solely for the
>
> addressee(s). Any unauthorized review, use, disclosure or distribution
>
> is prohibited. If you believe this message has been sent to you in
>
> error, please notify the sender by replying to this transmission and
>
> delete the message without disclosing it. Thank you.
>
> 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 (510) 573-2237

--------------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:[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 6.5.7652.24">
  <title>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:[email-masked]">mailto:[email-masked]</a>]<br>
Sent: mercoled&igrave; 4 luglio 2007 18.47<br>
To: Diego Caviglia (GA/ERI); <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</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:[email-masked]">mailto:[email-masked]</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:[email-masked]">mailto:[email-masked]</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:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</a> [<a moz-do-not-send="true"
 href="mailto:[email-masked]">mailto:[email-masked]</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;
+39 010 600 3736</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Fax:
+39 010 600 3493</font></span></p>
  <p align="left"><span lang="en-us"><font face="Courier New" size="2">Mobile:
+39 335 7181762</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:[email-masked]">[email-masked]</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 (510) 573-2237

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

--------------030503060300070107070602--

Delivery-date: Thu, 05 Jul 2007 16:53:29 +0000
Content-class: urn:content-classes:message
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
From: "Zafar Ali \(zali\)" <[email-masked]>
To: "Lou Berger" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Hassan Sheikh \(hassans\)" <[email-masked]>, "Tomohiro Otani" <[email-masked]>

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

Delivery-date: Thu, 05 Jul 2007 16:52:08 +0000
Date: Thu, 05 Jul 2007 09:39:09 -0700
From: Greg Bernstein <[email-masked]>
To: "Diego Caviglia (GA/ERI)" <[email-masked]>
CC: [email-masked]
Subject: Re: Switching Capability of Photonic Links with Transponder

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:  +39 010 600 3736
>
> Fax: +39 010 600 3493
>
> Mobile: +39 335 7181762
>
> Email: [email-masked] <mailto:[email-masked]>  
>
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
>
> 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 (510) 573-2237

--------------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:[email-masked]"
 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;
+39 010 600 3736</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:
+39 010 600 3493</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:
+39 335 7181762</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:[email-masked]">[email-masked]</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 (510) 573-2237

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

--------------040306020202000908070009--

Delivery-date: Thu, 05 Jul 2007 06:44:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Thu, 5 Jul 2007 08:39:59 +0200
From: "Diego Caviglia (GA/ERI)" <[email-masked]>
To: "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
Sent: mercoled=EC 4 luglio 2007 18.47
To: Diego Caviglia (GA/ERI); [email-masked]
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:[email-masked]]=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:[email-masked]]=20
Sent: marted=EC 3 luglio 2007 19.21
To: Diego Caviglia (GA/ERI); [email-masked]
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: [email-masked] [mailto:[email-masked]] 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:  +39 010 600 3736

Fax: +39 010 600 3493

Mobile: +39 335 7181762

Email: [email-masked] =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:[email-masked]">mailto:julien.meuric@ora=
nge-ftgroup.com</A>]<BR>
Sent: mercoled=EC 4 luglio 2007 18.47<BR>
To: Diego Caviglia (GA/ERI); [email-masked]<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:[email-masked]">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:[email-masked]">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); [email-masked]</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: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]<=
/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; +39 010 600 3736</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Fax: +39 010 600 3493</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Mobile: +39 335 7181762</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Email: [email-masked]&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--

Delivery-date: Wed, 04 Jul 2007 16:49:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Wed, 4 Jul 2007 18:46:34 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Diego Caviglia \(GA/ERI\)" <[email-masked]>, <[email-masked]>

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:[email-masked]]=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:[email-masked]]=20
Sent: marted=EC 3 luglio 2007 19.21
To: Diego Caviglia (GA/ERI); [email-masked]
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: [email-masked] [mailto:[email-masked]] 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:  +39 010 600 3736

Fax: +39 010 600 3493

Mobile: +39 335 7181762

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

Delivery-date: Wed, 04 Jul 2007 07:10:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Wed, 4 Jul 2007 09:08:16 +0200
From: "Diego Caviglia (GA/ERI)" <[email-masked]>
To: "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
Sent: marted=EC 3 luglio 2007 19.21
To: Diego Caviglia (GA/ERI); [email-masked]
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: [email-masked] [mailto:[email-masked]] 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:  +39 010 600 3736

Fax: +39 010 600 3493

Mobile: +39 335 7181762

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

Delivery-date: Tue, 03 Jul 2007 18:16:48 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-09.txt 
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 03 Jul 2007 17:22:37 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching Capability of Photonic Links with Transponder
Date: Tue, 3 Jul 2007 19:20:33 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Diego Caviglia \(GA/ERI\)" <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] 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:  +39 010 600 3736

Fax: +39 010 600 3493

Mobile: +39 335 7181762

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

Delivery-date: Tue, 03 Jul 2007 07:17:08 +0000
Content-class: urn:content-classes:message
Subject: Switching Capability of Photonic Links with Transponder
Date: Tue, 3 Jul 2007 09:13:40 +0200
From: "Diego Caviglia (GA/ERI)" <[email-masked]>
To: <[email-masked]>

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:  +39 010 600 3736

Fax: +39 010 600 3493

Mobile: +39 335 7181762

Email: [email-masked] =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;
+39 010 600 3736</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:
+39 010 600 3493</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:
+39 335 7181762</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:[email-masked]">[email-masked]</=
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--