Proposed liaison response to ITU-T SG15 on their work plan

["Adrian Farrel" <[e-mail]>]

All,

Please comment on this proposed liaison response.
I would like to send it on July 8th.

Thanks,
Adrian
========

To: ITU-T Study Group 15
From: IETF CCAMP Working Group
Subject: Response to your liaison on the SG15 OTNT Standardization Work
Plan
For: Information

The CCAMP working group would like to thank Study Group 15 for sharing
their current OTNT Standardization Work Plan. This has been made available
to the CCAMP participants.

We note that the work plan is kept updated for free download at
http://www.itu.int/itudoc/itu-t/com15/otn/index.html and thank the ITU-T
for this courtesy.

We would like to draw your attention to the following updates to your list
of RFCs and Internet-Drafts relevant to GMPLS and the ASON control plane.
We are sure that you will want to update your documentation accordingly.

Up-to-date information on CCAMP Internet-Drafts and RFCs can always be
found at http://www.ietf.org/html.charters/ccamp-charter.html with more
detail tracked at http://www.olddog.co.uk/ccamp-drafts.htm

Further drafts and RFCs will no doubt apply to the work you plan for the
MPLS transport network. We are sure you will want to contact the MPLS
working group for an up-to-date list.

draft-ietf-ccamp-gmpls-tc-mib-07.txt
    Definitions of Textual Conventions for Generalized Multiprotocol Label
Switching (GMPLS) Management

draft-ietf-ccamp-gmpls-lsr-mib-08.txt
    Generalized Multiprotocol Label Switching (GMPLS) Label Switching
Router (LSR) Management Information Base

draft-ietf-ccamp-gmpls-te-mib-09.txt
    Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management Information Base

draft-ietf-ccamp-crankback-05.txt
    Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE

draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
     Requirements for Generalized MPLS (GMPLS) Routing for Automatically
Switched Optical Network (ASON)

draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt
     Evaluation of existing Routing Protocols against ASON routing
requirements

draft-ietf-ccamp-gmpls-segment-recovery-02.txt
     GMPLS Based Segment Recovery

draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt
     Node ID based RSVP Hello: A Clarification Statement

draft-ietf-ccamp-loose-path-reopt-01.txt
     Reoptimization of Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) loosely routed Label Switch Path (LSP)

draft-ietf-ccamp-transport-lmp-02.txt
      A Transport Network View of the Link Management Protocol

draft-ietf-ccamp-rsvp-restart-ext-02.txt
      Extensions to GMPLS RSVP Graceful Restart

draft-ietf-ccamp-inter-domain-framework-03.txt
      A Framework for Inter-Domain MPLS Traffic Engineering

RFC 4054
     Impairments and Other Constraints on Optical Layer Routing

draft-ash-pce-architecture-01.txt
     Path Computation Element (PCE) Architecture

draft-ietf-mpls-lsp-hierarchy-08.txt
      LSP Hierarchy with Generalized MPLS TE

draft-ietf-mpls-bundle-06.txt
      Link Bundling in MPLS Traffic Engineering

draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
      A Lexicography for the Interpretation of Generalized Multiprotocol
Label Switching (GMPLS) Terminology within The Context of the ITU-T's
Automatically Switched Optical Network (ASON) Architecture

Best regards,
Adrian Farrel and Kireeti Kompella
IETF CCAMP Working Group co-chairs






Envelope-to: [e-mail]
Delivery-date: Thu, 30 Jun 2005 19:17:16 +0000
Message-ID: <013601c57da8$66cac670$db849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Proposed liaison response to ITU-T SG15 on their work plan
Date: Thu, 30 Jun 2005 20:17:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

Please comment on this proposed liaison response.
I would like to send it on July 8th.

Thanks,
Adrian
========

To: ITU-T Study Group 15
From: IETF CCAMP Working Group
Subject: Response to your liaison on the SG15 OTNT Standardization Work
Plan
For: Information

The CCAMP working group would like to thank Study Group 15 for sharing
their current OTNT Standardization Work Plan. This has been made available
to the CCAMP participants.

We note that the work plan is kept updated for free download at
http://www.itu.int/itudoc/itu-t/com15/otn/index.html and thank the ITU-T
for this courtesy.

We would like to draw your attention to the following updates to your list
of RFCs and Internet-Drafts relevant to GMPLS and the ASON control plane.
We are sure that you will want to update your documentation accordingly.

Up-to-date information on CCAMP Internet-Drafts and RFCs can always be
found at http://www.ietf.org/html.charters/ccamp-charter.html with more
detail tracked at http://www.olddog.co.uk/ccamp-drafts.htm

Further drafts and RFCs will no doubt apply to the work you plan for the
MPLS transport network. We are sure you will want to contact the MPLS
working group for an up-to-date list.

draft-ietf-ccamp-gmpls-tc-mib-07.txt
    Definitions of Textual Conventions for Generalized Multiprotocol Label
Switching (GMPLS) Management

draft-ietf-ccamp-gmpls-lsr-mib-08.txt
    Generalized Multiprotocol Label Switching (GMPLS) Label Switching
Router (LSR) Management Information Base

draft-ietf-ccamp-gmpls-te-mib-09.txt
    Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management Information Base

draft-ietf-ccamp-crankback-05.txt
    Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE

draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
     Requirements for Generalized MPLS (GMPLS) Routing for Automatically
Switched Optical Network (ASON)

draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt
     Evaluation of existing Routing Protocols against ASON routing
requirements

draft-ietf-ccamp-gmpls-segment-recovery-02.txt
     GMPLS Based Segment Recovery

draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt
     Node ID based RSVP Hello: A Clarification Statement

draft-ietf-ccamp-loose-path-reopt-01.txt
     Reoptimization of Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) loosely routed Label Switch Path (LSP)

draft-ietf-ccamp-transport-lmp-02.txt
      A Transport Network View of the Link Management Protocol

draft-ietf-ccamp-rsvp-restart-ext-02.txt
      Extensions to GMPLS RSVP Graceful Restart

draft-ietf-ccamp-inter-domain-framework-03.txt
      A Framework for Inter-Domain MPLS Traffic Engineering

RFC 4054
     Impairments and Other Constraints on Optical Layer Routing

draft-ash-pce-architecture-01.txt
     Path Computation Element (PCE) Architecture

draft-ietf-mpls-lsp-hierarchy-08.txt
      LSP Hierarchy with Generalized MPLS TE

draft-ietf-mpls-bundle-06.txt
      Link Bundling in MPLS Traffic Engineering

draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
      A Lexicography for the Interpretation of Generalized Multiprotocol
Label Switching (GMPLS) Terminology within The Context of the ITU-T's
Automatically Switched Optical Network (ASON) Architecture

Best regards,
Adrian Farrel and Kireeti Kompella
IETF CCAMP Working Group co-chairs




Envelope-to: [e-mail]
Delivery-date: Wed, 29 Jun 2005 21:10:57 +0000
Message-ID: <04b001c57cef$142e6520$c9919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: WG Action: Layer 1 Virtual Private Networks (l1vpn)
Date: Wed, 29 Jun 2005 22:10:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

FYI
----- Original Message ----- 
From: "The IESG" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; "Hamid Ould-Brahim" <[e-mail]>; "Adrian
Farrel" <[e-mail]>; "Tomonori Takeda"
<[e-mail]>
Sent: Wednesday, June 29, 2005 8:38 PM
Subject: WG Action: Layer 1 Virtual Private Networks (l1vpn)


> A new IETF working group has been formed in the Routing Area. For
additional
> information, please contact the Area Directors or the WG Chairs.
>
> +++
>
> Layer 1 Virtual Private Networks (l1vpn)
> ========================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Hamid Ould-Brahim <[e-mail]>
> Adrian Farrel <[e-mail]>
> Tomonori Takeda <[e-mail]>
>
> Routing Area Director(s):
> Bill Fenner <[e-mail]>
> Alex Zinin <[e-mail]>
>
> Routing Area Advisor:
> Alex Zinin <[e-mail]>
>
> Mailing Lists:
> General Discussion: [e-mail]
> To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn
> Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html
>
> Description of Working Group:
> The L1VPN Working Group's task is to specify mechanisms necessary for
> providing layer-1 VPN services (establishment of layer-1 connections
> between CE devices) over a GMPLS-enabled transport service-provider
network.
>
> The following two service models will be addressed:
>
> 1. Basic mode: the CE-PE interface's functional repertoire is limited to
> path setup signalling only. Provider's network is not involved in
> distribution of customer network's routing information.
>
> 2. Enhanced mode: the CE-PE interface provides the signaling
> capabilities as in the Basic mode, plus permits limited exchange of
> information between the control planes of the provider and the customer
> to help such functions as discovery of reachability information in
> remote sites, or parameters of the part of the provider's network
> dedicated to the customer.
>
> The WG will work on the following items:
>
> 1. Framework document defining the reference network model, L1VPN
> service model, fundamental assumptions, and terminology.
>
> 2. Specification of the L1VPN signaling functionality between the
> customer and the provider network to support the basic mode.
>
> 3. Specification of the L1VPN signaling and routing functionality within
> the provider network to support the basic mode.
>
> 4. OAM features and MIB modules and/or extensions required for the basic
> mode.
>
> 5. Specification of the L1VPN signaling and routing functionality
> between the customer and the provider network to support the extended
mode.
>
> 6. Specification of the L1VPN signaling and routing functionality within
> the provider network to support the extended mode.
>
> 7. OAM features and MIB modules and/or extensions required for the
> extended mode.
>
> 8. Applicability guidelines to compare the basic and extended modes.
>
> At this point the WG will address the single-AS scenario only. The
> multi-AS/provider scenario may be considered in future.
>
> Protocol extensions required for L1VPN will be done in cooperation with
> MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary.
>
> L1VPN WG shall also cooperate with ITU-T SG13 through the established
> IETF process, and use documents Y.1312 and Y.1313 (describing L1VPN
> requirements and network architectures) as input to its design process.
> The documents will be available at the IETF liaison web-site.
>
> Goals and Milestones:
> Sep 05    Submit first Internet Draft of L1VPN framework
> Sep 05    Submit first Internet Drafts of basic mode specifications
> Dec 05    Submit first Internet Drafts of MIB modules for basic mode
> Apr 06    Submit basic mode specifications to IESG for publication as
Proposed
>           Standard
> Jun 06    Submit first Internet Drafts of enhanced mode specifications
> Aug 06    Submit MIB modules for basic mode to IESG for publication as
Proposed
>           Standard
> Dec 06    Submit enhanced mode specifications to IESG for publication as
>           Proposed Standard
> Dec 06    Submit L1VPN framework to IESG for publication as
Informational RFC
> Aug 07    Submit MIB modules for enhanced mode to IESG for publication
as
>           Proposed Standard
> Dec 07    Recharter or disband
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 28 Jun 2005 21:40:53 +0000
Message-ID: <030f01c57c2a$3deefbb0$c9919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Further short last call on draft-ietf-ccamp-inter-domain-framework-03.txt
Date: Tue, 28 Jun 2005 22:14:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

draft-ietf-ccamp-inter-domain-framework-03.txt has been updated after
CCAMP WG last call. The changes were purely editorial, but there were
quite a few changes made so we shall have another quick last call ending
on 6th July at noon GMT.

I want to bring this I-D to the attention of the MPLS WG since it covers
TE for MPLS and GMPLS. Please read, review and comment.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 28 Jun 2005 19:53:01 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-03.txt 
Message-Id: <[e-mail]>
Date: Tue, 28 Jun 2005 15:50: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		: A Framework for Inter-Domain MPLS Traffic Engineering
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-inter-domain-framework-03.txt
	Pages		: 20
	Date		: 2005-6-28
	
This document provides a framework for establishing and controlling
   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain
   networks.

   For the purposes of this document, a domain is considered to be any
   collection of network elements within a common sphere of address
   management or path computational responsibility. Examples of such
   domains include IGP areas and Autonomous Systems.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-03.txt

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

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

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Mon, 27 Jun 2005 19:28:56 +0000
Message-ID: <011801c57b4e$752bd6c0$c9919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Inter-domain framework
Date: Mon, 27 Jun 2005 20:28:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Folks,

We have updated the inter-domain framework after WG last call and
submitted it for publication. The changes, in addition to typos, are
listed below.

Since it is quite a long list of (purely editorial) changes, I will hold a
further, brief WG last call on this I-D once it has been published.
I will ping the MPLS WG as well since they should have an interest
in this I-D.

Thanks,
Adrian

++++

Abstract
Clarify that LSPs we are discussing are TE LSPs.

1. Introduction
Clarify that LSPs we are discussing are TE LSPs.
And that we are interested in all source-based and constraint-based routed
LSPs.

1. Introduction
Clarify the meaning of "wholly or partially overlapping domains".

1. Introduction
Add reference to [GMPLS-AS] for GMPLS-specific issues

1.1. Nested Domains
Remove reference to [MRN] as it is a distraction in this context.

2.1. LSP Nesting
Re-draft to (largely) replace references to FA LSPs with references to
hierarchical LSPs.

2.1. LSP Nesting
Clarify the role of policy in inheritance rules for dynamic LSPs.

2.1. LSP Nesting
Clarify the end-to-end consistency of objects that have end-to-end
significance

2.2 Contiguous LSP
Clarify the definition of contiguous LSPs.

2.3. LSP Stitching
Replace reference to FA with reference to TE link.

2.5. Control of Downstream Choice of Signaling Method
Clarify the dangers of allowing too many implementation options.

3.2.2 Partial Visibility Computation
Clarify that the example EROs are only examples.

3.4.2. Path Computation Use of PCE When Preserving Confidentiality
Clarify how the full path can be computed once, and supplied in pieces at
domain boundaries.

4. Distributing Reachability and TE Information
Final paragraph.
Clarify the conditions for inter-domain TE exchange. Specifically that
requirements and benefits must be established before doing protocol
work.

5.1. LSP Re-Optimization
Clarify the paragraph on end-to-end diversity to show that we are
applying any kind of diversity constraint to a set of end-to-end paths
that cross multiple domains.

5.4. Fast Reroute
Clarify that FRR applies to packet-based technologies only.

5.4. Fast Reroute
Point out that protecting border nodes when they are ingress of egress
of hierarchical LSPs or stitched segments may lead to different
protection behavior.

5.5. Comments on Path Diversity
2nd para
Clarify the "ease" of resolution of path diversity problems.

5.5. Comments on Path Diversity
Final para.
Clarify the scope of SRLG identifiers.

5.10. Applicability to Non-Packet Technologies
Add note that Segment Protection is also applicable to the packet-based
FRR problem.





Envelope-to: [e-mail]
Delivery-date: Thu, 23 Jun 2005 12:35:02 +0000
Message-ID: <0b5f01c577f0$410bb5b0$7f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Your opinion: Using the RDB to make TE decisions
Date: Thu, 23 Jun 2005 13:34:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

In my review of draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt (q.v.) I
found that the authors are proposing that when an ERO next hop cannot be
resolved using the TED, it MAY be resolved using the routing database.

That is, in the absence of known TE links all the way to the next hop, the
path computation component MAY determine some LSR to which it does have
TED connectivity and which it believes has IP reachability to the next
hop.

The proposed use for this is to resolve TE connectivity to out of domain
(e.g. out of AS) next hops. In particular to find the best ASBR to use to
get to the destination.

To be fair, the authors do not claim that their technique will produce the
most optimal route. Nor do they claim that it will always find a route
without using crankback.

1. I have asked them to tighten their language so that the use of
   the RDB is not allowed for TE route computation *within*
   a domain.
2. What does the WG think about this proposed use of the RDB
   for inter-domain route resolution within GMPLS networks.
   Note that the next hop is a TE address:
   a. Where this is a TE router ID the process may work fine.
   b. Where this is a TE link address and not present in the RDB
        no harm is done.
   c. The TE link addresses MIGHT re-use addresses from the
      IP control plane but identify different resources. This would
      be a mess.

Your opinion is needed.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 23 Jun 2005 12:15:59 +0000
Message-ID: <0b3401c577ed$399fdde0$7f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "'Jean Philippe Vasseur'" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Early chair review of draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Date: Thu, 23 Jun 2005 13:14:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Hi,

I have done an early review of this I-D because the authors indicated that
it was "fully stable".

I think there is a fair about of work to be done on the text. See the
comments below.

I have not caught all of the typos, I am sure. Also worried that the
number of changes needed may have obscured some technical issues, so we
will have to go around this at least once more.

Thanks,
Adrian

===========

## Please sort out the formatting so that paragraphs are indented


CCAMP Working Group                                 JP Vasseur (Editor)
## Should say "Network Working Group"
IETF Internet draft                                 Cisco Systems, Inc.
Proposed Status: Standard                       Arthi Ayyangar (Editor)
                                                Juniper Networks
                                                  Raymond Zhang
                                            Infonet Service Corporation

Expires: October 2005
                                                             April 2005


         draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt


## Would a more precise title be as follows?
## Also s/Path/Paths/
## A Per-domain path computation method for establishing Inter-domain
Traffic
##            Engineering (TE) Label Switched Paths (LSPs)



Status of this Memo

By submitting this Internet-Draft, I certify that any applicable patent
or IPR claims of which I am aware have been disclosed, and any of which
I become aware will be disclosed, in accordance with RFC 3668.

## Need new IPR boilerplate

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are
Working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups.  Note that other groups may also
distribute working documents as Internet-Drafts.

## Don't need old 2026 boilerplate.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document specifies a per-domain path computation method for
computing inter-domain Traffic Engineering (TE) Multiprotocol Label
## s/computing/establishing/
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched (LSP)
paths.
## "Label Switched Paths (LSPs)"
In this document a domain is referred to as a collection of
## s/is referred to as/refers to/
network elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous Systems.


 Vasseur, Ayyangar and Zhang                                   1



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005

## The next paragraph is a bit unclear. Why not it with...
## Per-domain computation applies where the full route to an
## inter-domain LSP cannot be or is not determined at the ingress
## point of the LSP, and is not signaled across domain boundaries.
## This is most likely to arrise owing to TE visibilty limitations.
## The signaling message indicates the destination and nodes up to
## the next domain boundary. It may also indicate further domain
## boundaries or domain identifiers. The route through each domain,
## possibly including the choice of exit point from the domain,
## must be determined within the domain.

The principle of per-domain path computation specified in this document
comprises of a GMPLS or MPLS node along an inter-domain LSP path,
computing a path up to the last reachable hop within its domain. It
covers cases where this last hop (domain exit point) may already be
specified in the signaling message as well the case where this last hop
may need to be determined by the GMPLS node.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

Table of content

1. Terminology ............................................. 3
2. Introduction ............................................ 4
3. General assumptions ..................................... 5
4. Per-Domain path computation algorithm ................... 8
4.1 Example with an inter-area TE LSP ...................... 9
4.1.1 Case 1: T1 is a contiguous TE LSP .................... 9
4.1.2 Case 2: T1 is a stitched or nested TE LSP ............ 10
4.2 Example with an inter-AS TE LSP ........................ 11
4.2.1  Case 1: T1 is a contiguous TE LSP ................... 12
4.2.2  Case 2: T1 is a stitched or nested TE LSP ........... 13
5 Path optimality/diversity ................................ 13
6  MPLS Traffic Engineering Fast Reroute for inter-domain
   TE LSPs ................................................. 13
6.1 Failure of an internal network element ................. 14
6.2 Failure of an inter-ASBR links (inter-AS TE) ........... 14
6.3 Failure of an ABR or an ASBR node ...................... 14
7. Reoptimization of an inter-domain TE LSP ................ 14
7.1 Contiguous TE LSPs ..................................... 14
7.2 Stitched or nested (non-contiguous) TE LSPs ............ 15
8. Security Considerations ................................. 16
9. Intellectual Property Considerations .................... 17
10 References .............................................. 17
10.1 Normative references .................................. 17
10.2 Informative references ................................ 18












 Vasseur, Ayyangar and Zhang                                   2



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005



1.     Terminology


ABR Routers: routers used to connect two IGP areas (areas in OSPF or
L1/L2 in IS-IS)
##replace "L1/L2" with "levels"

## Missing ASBR. Just point to Interconnect routers

Boundary LSR: a boundary LSR is either an ABR in the context of inter-
area MPLS TE or an ASBR in the context of inter-AS MPLS TE.

Bypass Tunnel: an LSP that is used to protect a set of LSPs passing
over a common facility.

CSPF: Constraint-based Shortest Path First.
## I searched for the uses of this acronym and I thought all of them
## should be less specific (that is allowing any path computation
## technique). In which case, you will not need this in the terminology
## section.

Fast Reroutable LSP: any LSP for which the "Local protection desired"
bit is set in the Flag field of the SESSION_ATTRIBUTE object of its
Path messages or signaled with a FAST-REROUTE object.
## This term is not used. It can be deleted.

Interconnect routers or ASBR routers: routers used to connect together
ASes of a different or the same Service Provider via one or more Inter-
AS links.

Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do
not reside within the same Autonomous System (AS), or whose head-end
LSR and tail-end LSR are both in the same AS but the TE  LSPÆs path
## Non-ASCII character. This would not happen if you ran idnits
## before submission. I have not flagged the *many* other non-ASCII
## characters. Please fix.
may be across different ASes. Note that this definition also applies to
TE LSP whose Head-end and Tail-end LSRs reside in different sub-ASes
(BGP confederations).
## So, to summarise this definition...
## A TE LSP that crosses an AS boundary.

Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end
LSR do not reside in the same area or both the head-end and tail end
LSR reside in the same area but the TE LSP transits one or more
different areas along the path.
## To summarise again...
## A TE LSP that crosses an area boundary.

LSR: Label Switch Router
## Aaaaagh!
## Label Switching Router (come back after class and write this out
## a hundred times!)

LSP: MPLS Label Switched Path

Local Repair: local protection techniques used to repair TE LSPs
quickly when a node or link along the LSPs path fails.
## Term not used in this I-D. Please delete.

MP: Merge Point. The LSR where bypass tunnels meet the protected LSP.
## Term not used in this I-D. Please delete.

NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel which
bypasses a single link of the protected LSP.
## Term not used in this I-D. Please delete.

NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel which
bypasses a single node of the protected LSP.
## Term not used in this I-D. Please delete.


 Vasseur, Ayyangar and Zhang                                   3



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


PCE: Path Computation Element. An LSR in charge of computing TE LSP
path for which it is not the Head-end. For instance, an ABR (inter-
area) or an ASBR (Inter-AS) can play the role of PCE.

PCC: Path Computation Client (any head-end LSR) requesting a path
computation from the Path Computation Element.
## Term not used in this I-D. Please delete or use.

Protected LSP: an LSP is said to be protected at a given hop if it has
one or multiple associated backup tunnels originating at that hop.
## Term not used in this I-D. Please delete.

PLR: Point of Local Repair. The head-end of a bypass tunnel.
## Term not used in this I-D. Please delete.

TED: MPLS Traffic Engineering Database

The notion of contiguous, stitched and nested TE LSPs is defined in
[INTER-DOMAIN-SIG] and [LSP-STITCHING] and will not be repeated here.
## May be better to refer to the framework I-D.

2.     Introduction

The requirements for inter-area and inter-AS MPLS Traffic Engineering
have been developed by the Traffic Engineering Working Group and have
been stated in [INTER-AREA-REQS] and [INTER-AS-REQS] respectively. The
## Throughout this document you must make the following changes
## s/[INTER-AREA-TE-REQS]/[INT-AREA-REQS]/
## s/[INTER-AREA-REQS]/[INT-AREA-REQS]/
## s/[INTER-AS-TE-REQS]/[INT-AS-REQS]/
## s/[INTER-AS-REQS]/[INT-AS-REQS]/
## s/[INTER-DOMAIN-FRAMEWORK]/[INT-DOMAIN-FRWK]/
framework for inter-domain MPLS Traffic Engineering has been provided
in [INTER-DOMAIN-FRAMEWORK].

The set of mechanisms to establish and maintain inter-domain TE LSPs
are specified in [INTER-DOMAIN-SIG] and [LSP-STITCHING].
## Not sure about "the set of". "Some of" would be better.
## For example, is the mechanism described here also described in those
## I-Ds?
## Maybe even delete this paragraph.

This document exclusively focuses on the path computation aspects and
defines a method for computing inter-domain TE LSP paths where each
node in charge of computing a section of an inter-domain TE LSP path is
always along the path of such LSP.

When the visibility of an end to end complete path spanning multiple
domains is not available at the head end node, one approach described
in the document consists of using a per-domain path computation scheme
## which document? this document?
used during LSP setup to determine the inter-domain LSP path as it
traverses multiple domains.

Note that the mechanisms proposed in this document could also be
applicable to MPLS TE domains other than areas and ASes.

According to the wide set of requirements defined in [INTER-AS-TE-REQS]
and [INTER-AREA-TE-REQS], coming up with a single solution covering all
the requirements is certainly possible but may not be desired: indeed,
as described in [INTER-AS-TE-REQS] the spectrum of deployment scenarios
is quite large and designing a solution addressing the super-set of all
the requirements would lead to providing a rich set of mechanisms not
required in several cases. Depending on the deployment scenarios of a
SP, certain requirements stated above may be strict while certain other
requirements may be relaxed.
## Useful information. Could benefit from rewording.
## Your message is what?
## The solution in this document does not attempt to address all the
## requirements specified in [INT-AREA-REQS] and [INT-AS-REQS]. This
## is acceptible according to [INT-AS-REQS] which indicates that a
## solution may be developed tuned to a particular deployment scenario
## and might, therefore, not meet all requirements for other deployment
## scenarios. The procedures described in this document apply to the
## specific deployment scenario just described.

 Vasseur, Ayyangar and Zhang                                   4



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


## The next paragpraph is true but irrelevant to this I-D.
There are different ways in which inter-domain TE LSP path computation
may be performed. For example, if the requirement is to get an end-to-
end constraint-based shortest path across multiple domains, then a
mechanism using one or more distributed PCEs could be used to compute
the shortest path across different domains. Alternatively, one could
also use some static or discovery mechanisms to determine the next
boundary LSR per domain as the inter-domain TE LSP is being signaled.
Other offline mechanisms for path computation are not precluded either.
Depending on the Service ProviderÆs requirements, one may adopt either
of these techniques for inter-domain path computation.

## First sentence is not needed.
## First half of second sentence has already been said.
## Move second half of second sentence to live with the first instance
## of the first half of the second sentence.
Note that the adequate path computation method may be chosen based upon
the TE LSP characteristics and requirements. This document specifies an
inter-domain path computation technique based on per-domain path
computation and could be used in place or in conjunction with other
techniques.

3.     General assumptions

In the rest of this document, we make the following set of assumptions:

## Shouldn't 1), 2) etc. be 3.1, 3.2 etc.?
1)  Common assumptions

- Each domain in all the examples below is assumed to be capable of
doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and RSVP-
TE). A domain may itself comprise multiple other domains. E.g. An AS
may itself be composed of several other sub-AS(es) (BGP confederations)
or areas/levels.

## The formatting in the next bullets could use some work.

- The inter-domain LSPs are signaled using RSVP-TE ([RSVP-TE]).

- The path (ERO) for the inter-domain TE LSP traversing multiple
areas/ASes may be signaled as a set of (loose and/or strict) hops. The
## delete "traversing multiple areas/ASes"
hops may identify:
      - The complete strict path end to end across different
      areas/ASes
      - The complete strict path in the source area/AS followed by
      boundary LSRs (and domain identifiers, e.g. AS numbers)
## s/and/or/ ?
      - The complete list of boundary LSRs along the path
      - The current boundary LSR and the LSP destination
## This reads a little as though the destination can only be
## present in the final case.

In this case, the set of (loose or strict) hops can either be
## In which case?
statically configured on the Head-end LSR or dynamically computed. In
the former case, the resulting path is statically configured on the
Head-end LSR. In the latter case (dynamic computation), a per-domain
path computation method is defined in this document with some Auto-
discovery mechanism based on BGP and/or IGP information yielding the
next-hop boundary node (domain exit point, say ABR/ASBR) along the path
as the LSP is being signaled, along with crankback mechanisms. Note

 Vasseur, Ayyangar and Zhang                                   5



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


that alternatively next-hop may be statically configured on the Head-
end LSR in which case next-hop auto-discovery would not be needed.

- Furthermore, the boundary LSRs are assumed to be capable of
performing local path computation for expansion of a loose next-hop in
the signaled ERO if the path is not signaled by the head-end LSR as a
set of strict hops or if the strict hop is an abstract node (e.g. an
AS). This can be done by performing a CSPF computation up to that next

## Why do you mention CSPF? The path computation algorithm in use is
## surely not relevant to this I-D.

loose hop as opposed to the TE LSP destination or by making use of some
PCEs. In any case, no topology or resource information needs to be
distributed between areas/ASes (as mandated per [INTER-AREA-REQS] and
[INTER-AS-REQS]), which is critical to preserve IGP/BGP scalability and
confidentiality in the case of TE LSPs spanning multiple routing
domains.

Note that PCE-based path computation may be mentioned in this document
for the sake of reference but such techniques are outside the scope of
this document.
## Then don't mention them.

- The paths for the intra-domain  FA-LSPs or LSP segments or for a
contiguous TE LSP within the area/AS, may be pre-configured or computed
dynamically based on the arriving inter-domain LSP setup request;
depending on the requirements of the transit area/AS. Note that this
capability is explicitly specified as a requirement in [INTER-AS-TE-
REQS]. When the paths for the FA-LSPs/LSP segments are pre-configured,
the constraints as well as other parameters like local protection
scheme for the intra-area/AS FA-LSP/LSP segment are also pre-
configured.

- While certain constraints like bandwidth can be used across different
areas/ASes, certain other TE constraints like resource affinity, color,
metric, etc. as listed in [RFC2702] could be translated at areas/ASes
boundaries. If required, it is assumed that, at the area/AS boundary
LSRs, there will exist some sort of local mapping based on offline
policy agreement, in order to translate such constraints across area/AS
boundaries. It is expected that such an assumption particularly applies
to inter-AS TE: for example, the local mapping would be similar to the
Inter-AS TE Agreement Enforcement Polices stated in [INTER-AS-TE-REQS].

2) Example of topology for the inter-area TE case

The following example will be used for the inter-area TE case in this
document.

## Formatting of figure is broken

<--area1--><---area0---><----area2----->
 ------ABR1------------ABRÆ1------- 
 |    /   |              |  \     |
R0--X1    |              |   X2---X3--R1
 |        |              |  /     |
 -------ABR2-----------ABRÆ2------ 
<=========== Inter-area TE LSP =======>

 Vasseur, Ayyangar and Zhang                                   6



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005



Assumptions

## Do you need to say that you also support the case where area2 is
## not a spearate area, but is part of area 1?
##
## Do you support routing across (i.e. into and out of) an area
## that is not area zero?

## The following is not a list of assumptions, it is part of the
## explanation of the example.
- ABR1, ABR2, ABRÆ1 and ABRÆ2 are ABRs,
- X1: an LSR in area 1,
- X2, X3: LSRs in area 2,
- An inter-area TE LSP T0 originated at R0 in area1 and terminating at
R1 in area2,

Notes:
- The terminology used in the example above corresponds to OSPF but the
path computation methods proposed in this document equally applies to
the case of an IS-IS multi-levels network.
## s/levels/level/
- Just a few routers in each area are depicted in the diagram above for
the sake of simplicity.

3) Example of topology for the inter-AS TE case:

We will consider the following general case, built on a superset of the
various scenarios defined in [INTER-AS-TE-REQS]:

## Formatting of figure is broken

     <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ---->

               <---BGP--->            <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4ù-R3---ASBR7-ù--ASBR9----R6
      |\     \ |       / |   / |   / |          |      |
      | \     ASBR2---/ ASBR5  | --  |          |      |
      |  \     |         |     |/    |          |      |
      R1-R2ù--ASBR3ù----ASBR6ù-R4---ASBR8ù---ASBR10ù--R7---CE2

      <======= Inter-AS TE LSP(LSR to LSR)===========>
or

<======== Inter-AS TE LSP (CE to ASBR =>

or

<================= Inter-AS TE LSP (CE to CE)===============>
Formatted:

The diagram above covers all the inter-AS TE deployment cases described
in [INTER-AS-TE-REQS].

## Be careful to separate the assumptions (which are good to have) from
## the explanation of the example.

Assumptions:

- Three interconnected ASes, respectively AS1, AS2, and AS3. Note that
AS3 might be AS1 in some scenarios described in [INTER-AS-TE-REQS],
## A beautifully phrased note :-)
## Please tell me, when AS3 is AS1, what is AS1?

- The various ASBRs are BGP peers, without any IGP running on the
single hop links interconnecting the ASBRs and also referred to as
inter-ASBR links,
## Whoah! I hope you will explain why you *need* to run BGP, and
## how you will manage non-TE distribution of reachability
## information when the destination of a TE-LSP is a TE address.
## Will you perhaps be mandating (stronger than recommending) that
## the destination of an inter-AS TE LSP is the TE Router ID of
## the egress in order to be sure that this address is one of the
## reachable addresses advertised by BGP?

 Vasseur, Ayyangar and Zhang                                   7



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005



- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE
extensions (see [OSPF-TE] and [IS-IS-TE]). In other words, the ASes are
## s/[IS-IS-TE]/[ISIS-TE]/
TE enabled,
## and/or GMPLS extensions, please (since we are in CCAMP)

- Each AS can be made of several IGP areas. The path computation
techniques described in this document applies to the case of a single
## s/applies/apply/
AS made of multiple IGP areas, multiples ASes made of a single IGP
## s/of a single/of single/
areas or any combination of the above. For the sake of simplicity, each
routing domain will be considered as single area in this document.
## A very nice simplification, but hardly real-world. So you need
## to explain how to handle multiple areas in an AS in the inter-AS
## case. I don't think this is hard to explain since you just
## recursively apply the techniques.

- An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6
in AS3.

4.     Per-domain path computation algorithm

Regardless of the nature of the inter-domain TE LSP (contiguous,
stitched or nested), a similar set of mechanisms for local TE LSP path
computation (next hop resolution) can be used.
## "A similar set can be used." Could you perhaps be more vague? :-)
## Do try to have some backbone.

When an ABR/ASBR receives a Path message with a loose next-hop or an
abstract node in the ERO, then it carries out the following actions:

## Mutter, mutter. All ERO hops are abstract nodes.
## You need "non-simple abstract node". I prefer "Widely-scoped
## abstract node" but this is not defined anywhere.

1) It checks if the loose next-hop is accessible via the TED. If the
## perhaps you can just drop the word "loose" because we have already
## established that the next-hop is either loose or non-simple.

loose next-hop is not present in the TED, then it checks if the next-
hop at least has IP reachability (via IGP or BGP). If the next-hop is
not reachable, then the path computation stops and the LSR sends back a
PathErr upstream. If the next-hop is reachable, then it finds an
ABR/ASBR to get to the next-hop. In the absence of an auto-discovery
mechanism, the ABR in the case of inter-area TE or the ASBR in the
next-hop AS in the case of inter-AS TE should be the loose next-hop in
the ERO and hence should be accessible via the TED, otherwise the path
computation for the inter-domain TE LSP will fail.
## I would like you to make it VERY clear what you are doing here.
## You are using the Routing Database to make TE routing decisions.
## This may (or may not) be OK in people's minds
## I will send separate mail to the CCAMP list because this is a BIG
## DEAL in GMPLS networks.
## In any case, can you please clarify that this process MUST NOT be
## used when the next-hop is within the same domain but does not
## appear in the TED, or does not have TE connectivity available.

## Presumably in the case above, presumably the boundary LSR is
## inserted into the ERO as a loose hop, and then we can tun on
## to the next item.

2) If the next-hop boundary LSR is present in the TED.

      a) Case of a contiguous TE LSP. The ABR/ASBR just performs an

## Which ABR/ASBR? The one in the TED or the one processing the ERO?

      ERO expansion (unless not allowed by policy) after having
      computed the path to the next loose hop (ABR/ASBR) that obeys
      the set of required constraints. If no path satisfying the set
      of constraints can be found, the path computation stops and a
      Path Error MUST be sent for the inter-domain TE LSP.

      b) Case of stitched or nested LSP

## You appear to say the same thing twice in this next point
## although the SHOULDs and MAYs get a bit garbled.
## I think that the SHOULD/MAY distinction is a mess anyway :-)
## If there is already an FA in place, the computing node will not
## know it as any different in the TED, and will compute to use
## it according to constraints and metrics. No option for "SHOULD"
## because it will just happen.
## The trigger for setting up a new FA is clearly local Policy and
## you should highlight this.
             i) if the ABR/ASBR (receiving the LSP setup request) is
             a candidate LSR for intra-area FA-LSP/LSP segment
             setup, and if there is no FA-LSP/LSP segment from this
             LSR to the next-hop boundary LSR (satisfying the
             constraints) it SHOULD signal a FA-LSP/LSP segment to
             the next-hop boundary LSR. If pre-configured FA-LSP(s)

 Vasseur, Ayyangar and Zhang                                   8



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


             or LSP segment(s) already exist, then it SHOULD try to
             select from among those intra-area/AS LSPs. Depending
             on local policy, it MAY signal a new FA-LSP/LSP segment
             if this selection fails. If the FA-LSP/LSP segment is
             successfully signaled or selected, it propagates the
             inter-domain Path message to the next-hop following the
             procedures described in [LSP-HIER]. If, for some reason
             the dynamic FA-LSP/LSP segment setup to the next-hop
             boundary LSR fails, the path computation stops and a
## Is it the path computation that stops?
## Is there no scope for retires or fall-back to ordinary routing?
             PathErr is sent upstream for the inter-domain LSP.
             Similarly, if selection of a preconfigured FA-LSP/LSP
             segment fails and local policy prevents dynamic FA-
             LSP/LSP segment setup, then the path computation stops
             and a PathErr is sent upstream for the inter-domain TE
             LSP.

             ii) If, however, the boundary LSR is not a FA-LSP/LSP
             segment candidate, then it SHOULD simply compute a CSPF

## Again, why is CSPF the important choice?

             path up to the next-hop boundary LSR carry out an ERO
             expansion to the next-hop boundary LSR) and propagate
             the Path message downstream. The outgoing ERO is
             modified after the ERO expansion to the loose next-hop.
## b) ii) seems to be identical to a).
## Is it possible that you need to tell us that the type of inter-
## domain LSP that is desired is part of the Path message?

             Note that in both cases, path computation may be
             stopped due to some local policy.


4.1.   Example with an inter-area TE LSP

4.1.1.  Case 1: T1 is a contiguous TE LSP

## I think your example should start at the ingress! It seems you
## cut back to that after the first paragraph.
## What does the user supply? What does the ingress compute?
## How is ABR1 selected? (I like ABR2: it is a nicer color. Why
## can't I have ABR2?)
## There is also some repeated text in this section.
## Also, why are you considering Example 1 since it is out of scope
## for you?
## Presumably, Example 3 only applies if areas 1 and 2 are actually
## part of the same area, so you should say so.

When the path message reaches ABR1, it first determines the egress LSR
from its area 0 along the LSP path (say ABRÆ1), either directly from
the ERO (if for example the next hop ABR is specified as a loose hop in
the ERO) or by using some constraint-aware auto-discovery mechanism. In
## Wow! "A constraint-aware auto-discovery mechanism." I borrowed
## one of those from Batman once, but I could never get it to work.
## What are you talking about?
## Yes, I see this in section 3, 1) and in section 4, 1) but it does
## not explain what you are suggesting may exist. I must say it sounds
## suspisciously like TE aggregation advertisement using BGP.
the former case, every inter-AS TE LSP path is defined as a set of
loose and strict hops but at least the ABRs traversed by the inter-area
TE LSP MUST be specified as loose hops on the head-End LSR.

- Example 1 (set of strict hops end to end): R0-X1-ABR1-ABRÆ1-X2-X3-R1
- Example 2 (set of loose hops): R0-ABR1(loose)-ABRÆ1(loose)-R1(loose)
- Example 3 (mix of strict and loose hops): R0-X1-ASBR1-ABRÆ1(loose)-
X2-X3-R1

At least, the set of ABRs from the TE LSP head-end to the tail-End MUST
be present in the ERO as a set of loose hops. Optionally, a set of
paths can be configured on the head-end LSR, ordered by priority. Each
priority path can be associated with a different set of constraints.

## I don't think this type of implementation detail is needed in the
## I-D. It is out of the scope of the protocol.

Typically, it might be desirable to systematically have a last resort
## "Typically, it might be desirable"? You sound unsure!
## Anyway, this whole paragrpah is also an implementation detail, and
## not part of a protocol spec. You are not expecting the ingress to
## make this decision on its own, so there is no need to cover it.
## (You can put it in the MIB if you like!)
option with no constraint to ensure that the inter-area TE LSP could
always be set up if at least a path exists between the inter-area TE
## "a path"? Perhaps "a TE path".

 Vasseur, Ayyangar and Zhang                                   9



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


LSP source and destination. Note that in case of set up failure or when
an RSVP Path Error is received indicating the TE LSP has suffered a
## Inconsistent "Path Error" and "PathErr"
failure, an implementation might support the possibility to retry a
particular path option a specific amount of time (optionally with
## amount of time or number of times?
dynamic intervals between each trial) before trying a lower priority
path option. Any path can be defined as a set of loose and strict hops.
In other words, in some cases, it might be desirable to rely on the
dynamic path computation in some area, and exert a strict control on
the path in other areas (defining strict hops).

Once it has computed the path up to the next ABR, ABR1 sends the Path
message for the inter-area TE LSP to ABRÆ1. ABRÆ1 then repeats the a
similar procedure and the Path message for the inter-area TE LSP will
reach the destination R1. If ABRÆ1 cannot find a path obeying the set
of constraints for the inter-area TE LSP, the path computation stops
## Again, is it the computation that stops? I think it has already
## stopped when you couldn't find a path. That is how you know you
## couldn't find a path.
and ABRÆ1 MUST send a PathErr message to ABR1. Then ABR1 can in turn
triggers a new computation by selecting another egress boundary LSR
## s/triggers/trigger/
(ABRÆ2 in the example above) if crankback is allowed for this inter-
area TE LSP (see [CRANBACK]). If crankback is not allowed for that
## s/CRANBACK/CRANKBACK/
inter-area TE LSP or if ABR1 has been configured not to perform
crankback, then ABR1 MUST stop any path computation for the TE LSP and
MUST forward a PathErr up to the head-end LSR (R0) without trying to
select another egress LSR.
## But R0 can possibly do crankback even if ABR1 doesn't.

4.1.2.  Case 2: T1 is a stitched or nested TE LSP

## Again, I would like you to start at the ingress.

When the path message reaches ABR1, ABR1 first determines the egress
LSR from its area 0 along the LSP path (say ABRÆ1), either directly
from the ERO or by using some constraint-aware auto-discovery
mechanism.

ABR1 will check if it has a FA-LSP or LSP segment to ABRÆ1 matching the
constraints carried in the inter-area TE LSP Path message. If not, ABR1
will compute the path for a FA-LSP or LSP segment from ABR1 to ABRÆ1
satisfying the constraint and will set it up accordingly. Note that the
FA-LSP or LSP segment could have also been pre-configured.

Once the ABR has selected the FA-LSP/LSP segment for the inter-area
LSP, using the signaling procedures described in [LSP-HIER], ABR1 sends
the Path message for inter-area TE LSP to ABRÆ1. Note that irrespective
of whether ABR1 does nesting or stitching, the Path message for the
inter-area TE LSP is always forwarded to ABRÆ1. ABRÆ1 then repeats the
exact same procedures and the Path message for the inter-area TE LSP
will reach the destination R1. If ABRÆ1 cannot find a path obeying the
set of constraints for the inter-area TE LSP, then ABRÆ1 MUST send a
PathErr message to ABR1. Then ABR1 can in turn either select another
FA-LSP/LSP segment to ABRÆ1 if such an LSP exists or select another
egress boundary LSR (ABRÆ2 in the example above) if crankback is
allowed for this inter-area TE LSP (see [CRANBACK]). If crankback is
## s/CRANBACK/CRANKBACK/
not allowed for that inter-area TE LSP or if ABR1 has been configured
not to perform crankback, then ABR1 MUST forward a PathErr up to the

 Vasseur, Ayyangar and Zhang                                  10



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


inter-area head-end LSR (R0) without trying to select another egress
LSR.

4.2.   Example with an inter-AS TE LSP

The procedures for establishing an inter-AS TE LSP are very similar to
those of an inter-area TE LSP described above. The main difference is
related to the presence of inter-ASBRs link(s).

The links interconnecting ASBRs are usually not TE enabled and no IGP
is running at the AS boundaries. An implementation supporting inter-AS
MPLS TE MUST obviously allow the set up of inter-AS TE LSP over the
## "MUST obviously" is not in RFC2119.
region interconnecting multiple ASBRs. In other words, an ASBR
compliant with this document MUST support the set up of TE LSP over
ASBR to ASBR links, performing all the usual operations related to MPLS
Traffic Engineering (call admission control, à) as defined in [RSVP-
TE].

In term of computation of an inter-AS TE LSP path, an interesting
## s/term/terms/
optimization consists of allowing the ASBRs to flood the TE information
related to the inter-ASBR link(s) although no IGP TE is enabled over
those links (and so there is no IGP adjacency over the inter-ASBR
links). This of course implies for the inter-ASBR links to be TE-
enabled although no IGP is running on those links. This allows a head-
end LSR to make a more appropriate route selection up to the first ASBR
in the next hop AS and will significantly reduce the number of
signaling steps in route computation. This also allows the entry ASBR
in an AS to make a more appropriate route selection up to the entry
ASBR in the next hop AS taking into account constraints associated with
the ASBR-ASBR links. Moreover, this reduces the risk of call set up
failure due to inter-ASBR links not satisfying the inter-AS TE LSP set
of constraints. Note that the TE information is only related to the
inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not only
the TE-enabled links contained in the AS but also the inter-ASBR links.

## Can you explain why the TE information pertaining to the inter-AS
## links *needs* to be flooded within the ASs? It is surely enough that
## the ASBRs have access to the TE information about their own TE links.
## After all, you have defined that the ASBRs in the *next* AS can do
## hop resolution and crankback. Why should the ASBRs in *this* AS also
## not perform that operation if necessary?
## You are reducing the chance of call setup failure at the expense of
## increasing the scope of the TE information flooded. But we know
## how that works!

Note that no summarized TE information is leaked between ASes which is
compliant with the requirements listed in [INTER-AREA-TE-REQS] and
[INTER-AS-TE-REQS].

Example:

               <---BGP--->            <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4ù-R3---ASBR7-ù--ASBR9---R6
      |\     \ |       / |   / |   / |          |     |
      | \     ASBR2---/ ASBR5  | --  |          |     |
      |  \     |         |     |/    |          |     |
      R1-R2ù--ASBR3ù----ASBR6ù-R4---ASBR8ù---ASBR10---R7---CE2

For instance, in the diagram depicted above, when ASBR1 floods its IGP
TE LSA (opaque LSA for OSPF)/LSP (TLV 22 for IS-IS) in its routing

 Vasseur, Ayyangar and Zhang                                  11



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


domain, it reflects the reservation states and TE properties of the
following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1-ASBR4.

Thanks to such an optimization, the inter-ASBRs TE link information
corresponding to the links originated by the ASBR is made available in
the TED of other LSRs in the same area/AS that the ASBR belongs to.
Consequently, the CSPF computation for an inter-AS TE LSP path can also

## CSPF again

take into account the inter-ASBR link(s). This will improve the chance
of successful path computation up to the next AS in case of a
bottleneck on some inter-ASBR links and it potentially reduces one
level of crankback. Note that no topology information is flooded and
these links are not used in IGP SPF computations. Only the TE
information for the links originated by the ASBR is advertised.

4.2.1.  Case 1: T1 is a contiguous TE LSP

The inter-AS TE path may be configured on the head-end LSR as a set of
strict hops, loose hops or a combination of both.

- Example 1 (set of strict hops end to end): R0-X1-ASBR1-ASBR4-ASBR5-
R3-ASBR7-ASBR9-R6
- Example 2 (set of loose hops): R0-ASBR4(loose)-ASBR9(loose)-R6(loose)
- Example 3 (mix of strict and loose hops): R0-R2-ASBR3-ASBR2-ASBR1-
ASBR4(loose)-ASBR10(loose)-ASBR9-R6

When a next hop is a loose hop, a dynamic path calculation (also called
ERO expansion) is required taking into account the topology and TE
information of its own AS and the set of TE LSP constraints. In the
example 1 above, the inter-AS TE LSP path is statically configured as a
set of strict hops; thus, in this case, no dynamic computation is
required. Conversely, in the example 2, a per-AS path computation is
performed, respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3.
Note that when an LSR has to perform an ERO expansion, the next hop
must either belong to the same AS, or must be the ASBR directly
connected to the next hops AS. In this later case, the ASBR
reachability MUST be announced in the IGP TE LSA/LSP originated by its
neighboring ASBR. Indeed, in the example 2 above, the TE LSP path is
defined as: R0-ASBR4(loose)-ASBR9(loose)-R6(loose). This implies that
R0 must compute the path from R0 to ASBR4, hence the need for R0 to get
the TE reservation state related to the ASBR1-ASBR4 link (flooded in
AS1 by ASBR1). In addition, ASBR1 MUST also announce the IP address of
ASBR4 specified in the T1 path configuration.

If an auto-discovery mechanism is available, every LSR receiving an
RSVP Path message, will have to determine automatically the next hop
ASBR, based on the IGP/BGP reachability of the TE LSP destination. With
such a scheme, the head-end LSR and every downstream ASBR loose hop
(except the last loose hop that computes the path to the final
destination) automatically computes the path up to the next ASBR, the
next loose hop based on the IGP/BGP reachability of the TE LSP
destination. If a particular destination is reachable via multiple

 Vasseur, Ayyangar and Zhang                                  12



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


loose hops (ASBRs), local heuristics may be implemented by the head-end
LSR/ASBRs to select the next hop an ASBR among a list of possible
choices (closest exit point, metric advertised for the IP destination
(ex: OSPF LSA External - Type 2), local policy,...). Once the next ASBR
has been determined, an ERO expansion is performed as in the previous
case.

Once it has computed the path up to the next ASBR, ASBR1 sends the Path
message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 is the
selected next hop ASBR). ASBR4 then repeats the exact same procedures
and the Path message for the inter-AS TE LSP will reach the destination
R1. If ASBR4 cannot find a path obeying the set of constraints for the
inter-AS TE LSP, then ASBR4 MUST send a PathErr message to ASBR1. Then
ASBR1 can in turn either select another ASBR (ASBR5 in the example
above) if crankback is allowed for this inter-AS TE LSP (see
[CRANBACK]). If crankback is not allowed for that inter-AS TE LSP or if
## s/CRANBACK/CRANKBACK/
ASBR1 has been configured not to perform crankback, then ABR1 MUST stop
the path computation and MUST forward a PathErr up to the head-end LSR
(R0) without trying to select another egress LSR. In this case, the
head-end LSR can in turn select another sequence of loose hops, if
configured. Alternatively, the head-end LSR may decide to retry the
same path; this can be useful in case of set up failure due an outdated
IGP TE database in some downstream AS. An alternative could also be for
the head-end LSR to retry to same sequence of loose hops after having
relaxed some constraint(s).

4.2.2.  Case 2: T1 is a stitched or nested TE LSP

The signaling procedures are very similar to the inter-area LSP setup
case described earlier. In this case, the FA-LSPs or LSP segments will
only be originated by the ASBRs at the entry to the AS.
## This is a really important point that you should bring out a bit!
## An FA cannot exist out of the IGP instance that contains its
## component TE links.
## What about non-FAs? Could I operate a stitched segment for just the
## link between ASBRs? I think so. Indeed, I might want to.
## Could I run a hierarchical LSP for just the link between ASBRs? Yes
## although I am not convinced it adds value, but maybe there is some
## administrative benefit when crossing a trust boundary (for example,
## all I have to do is count the packets with one label).

5.     Path optimality/diversity

Since the inter-domain path is computed on a per domain (area, AS)
basis, one cannot guarantee that the shortest inter-domain path can be
## Who cares about "shortest"? We want "optimal given the constraints."
found.
## Well, you have explicitly allowed the selection of domains to be
## made in the initial ERO. (Note you never really said how this
## selection might be made.) Presumably, this selection might be
## used to achieve the optimal.

Moreover, computing two diverse paths might not be possible in some
topologies (due to the well-known ôtrappingö problem).
## "Might not" is an understatement!
## You should note two things.
## The e2e protection technique offers a way to help achieve this
## however there is a direct conflict with the trust policies at
## domain boundaries that may mean that it is impossible to make
## any guarantees (or even to make an attempt) without new techniques
## probably related to crankback, but maybe requiring perpendicular
## communication between boundary LSRs.
## Domain-diverse paths provide an intersting solution and also
## offer interesting protection characteristics.

As already pointed out, the required path computation method can be
selected by the Operator on a per LSP basis.
## And so... ?
## I think you are saying that "If this technique does not give you
## the function you need, look elsewhere." This is a good thing to
## say.
## In fact, I would like you to add a new section titled
## "Applicability" to cover what you can and cannot do with this
## technique.

6.     MPLS Traffic Engineering Fast Reroute for inter-domain TE LSPs
## The following section is valuable in the context of the popularity
## of RFC 4090, but you cannot produce this I-D in CCAMP without also
## discussing the use of Segment Protection to achieve the same
## function in the data plane.

The signaling aspects of Fast Reroute and related constraints for each
TE LSP types in the case of inter-domain TE LSP has been covered in
## s/types/type/
## s/has/have/
[INTER-DOMAIN-SIG] and will not be repeated in this document.
## Does that mean that to operate FRR with the techniques described
## here you must apply something from [INTER-DOMAIN-SIG]? If so, you
## need to make that I-D noramtive.


 Vasseur, Ayyangar and Zhang                                  13



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


There are multiple failure scenarios to consider in the case of Fast
Reroute for inter-domain TE LSPs.

6.1.   Failure of an internal network element

The case of a failure of a network element within an area/AS such as a
link, SRLG or a node does not differ from Fast Reroute for intra-domain
TE LSP.
## You need to make it clear that you do not consider an ABR or ASBR to
## be within the area or AS. Most people will find this shocking.
## You need to be careful with "SRLG" because some SRLGs span domains
## although no-one is quite sure how that works (c:

6.2.   Failure of an inter-ASBR links (inter-AS TE)
## s/links/link/

In order to protect inter-domain TE LSPs from the failure of an inter-
ASBR link, this requires the computation of a backup tunnel path that
crosses an non IGP TE-enabled region (between two ASes).
## s/an non/a non/
If the inter-
ASBR TE related information is flooded in the IGPs, each ASBR is
capable of computing the path according to the backup tunnel
constraints. Otherwise, the backup tunnel path MUST be statically
configured.
## If the inter-ASBR TE link is flooded in the IGPs, doesn't that
## make it IGP TE-enabled?

6.3.   Failure of an ABR or an ASBR node

The constraints to be taken into account during the backup tunnel path
computation significantly differs upon the TE LSP type, network element
## s/differs/differ depending/
to protect (entry/exit boundary node) and the Fast Reroute method in
use (facility backup versus one-to-one). Those constraints have been
explored in detail in [INTER-DOMAIN-SIG] but since the backup tunnel is
itself an inter-domain TE LSP, its path computation can be performed
according to the two path computation methods described in this
document.

7.     Reoptimization of an inter-domain TE LSP

The ability to reoptimize an existing inter-domain TE LSP path is of
course a requirement. The reoptimization process significantly differs
based upon the nature of the TE LSP and the mechanism in use for the TE
LSP path computation.

The following mechanisms can be used for re-optimization, which are
## Please decide "reoptimize" or "re-optimize"
dependent on the nature of the inter-domain TE LSP.

7.1.   Contiguous TE LSPs

## Need to generalize this section for areas, etc.

After an inter-AS TE LSP has been set up, a more optimal route might
appear in the various traversed ASes. Then in this case, it is
desirable to get the ability to reroute an inter-AS TE LSP in a non-
disruptive fashion (making use of the so called Make Before Break
procedure) to follow this more optimal path. This is a known as a TE
LSP reoptimization procedure.

## Is there any requirement to redescribe the procedures of
## [LOOSE-PATH-REOPT]? Why not simply state that...
## [LOOSE-PATH-REOPT] describes a mechanism to control discovery
## or more optimal paths, and to signal new paths using make before
## break.

#### BEGIN DELETE
#
#

[LOOSE-REOPT] proposes a mechanisms allowing:
## s/[LOOSE-REOPT]/[LOOSE-PATH-REOPT]/ -- change throughout the doc
## s/proposes/defines/


 Vasseur, Ayyangar and Zhang                                  14



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


      - The head-end LSR to trigger on every LSR whose next hop is a
      loose hop the re evaluation of the current path in order to
## s/re evaluation/re-evaluation/
      detect a potentially more optimal path. This is done via
      explicit signaling request: the head-end LSR sets the ôERO
      Expansion requestö bit of the SESSION-ATTRIBUTE object carried
      in the RSVP Path message.

      - An LSR whose next hop is a loose-hop to signal to the head-
      end LSR that a better path exists. This is performed by sending
      an RSVP Path Error Notify message (ERROR-CODE = 25), sub-code 6
      (Better path exists).

      This indication may be sent either:

            - In response to a query sent by the head-end LSR,
             - Spontaneously by any LSR having detected a more
             optimal path

Such a mechanism allows for the reoptimization of a TE LSP if and only
if a better path is some downstream area/AS is detected.

The reoptimization event can either be timer or event-driven based (a
link UP event for instance).

Note that the reoptimization MUST always be performed in a non-
disruptive fashion.

Once the head-end LSR is informed of the existence of a more optimal
path either in its head-end area/AS or in another AS, the inter-AS TE
Path computation is triggered using the same set of mechanisms as when
the TE LSP is first set up. Then the inter-AS TE LSP is set up
following the more optimal path, making use of the make before break
procedure. In case of a contiguous LSP, the reoptimization process is
strictly controlled by the head-end LSR which triggers the make-before-
break procedure, regardless of the location where the more optimal path
is.

Note that in the case of loose hop reoptimization, the TE LSP may
follow a preferable path within one or more domain(s) whereas in the
case of PCE-based path computation techniques, the reoptimization
process may lead to following a completely different inter-domain path
(including a different set of ABRs/ASBRs) since end-to-end shortest
path is computed.

#
#
#### END DELETE

7.2.   Stitched or nested (non-contiguous) TE LSPs

## This section contains quite a lot of repetition.

In the case of a stitched or nested inter-domain TE LSP, the re-
optimization process is treated as a local matter to any Area/AS. The
main reason is that the inter-domain TE LSP is a different LSP (and
therefore different RSVP session) from the intra-domain LSP segment or

## Your causality is broken. Being a different LSP does not imply
## being a different session. However, the key point *is* that this
## is a different session (with different ingress and egress).

FA-LSP in an area or an AS. Therefore, reoptimization in an area/AS is

 Vasseur, Ayyangar and Zhang                                  15



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


done by locally reoptimizing the intra-domain FA LSP or LSP segment.
Since the inter-domain TE LSPs are transported using LSP segments or
FA-LSP across each domain, optimality of the inter-domain TE LSP in an
area/AS is dependent on the optimality of the corresponding LSP
segments or FA-LSPs. If, after an inter-domain LSP is setup, a more
optimal path is available within an area/AS, the corresponding LSP
segment(s) or FA-LSP will be re-optimized using "make-before-break"
techniques discussed in [RSVP-TE]. Reoptimization of the FA LSP or LSP
segment automatically reoptimizes the inter-domain TE LSPs that the LSP
segment transports. Reoptimization parameters like frequency of
reoptimization, criteria for reoptimization like metric or bandwidth
availability; etc can vary from one area/AS to another and can be
configured as required, per intra-area/AS TE LSP segment or FA-LSP if
it is preconfigured or based on some global policy within the area/AS.

Hence, in this scheme, since each area/AS takes care of reoptimizing
its own LSP segments or FA-LSPs, and therefore the corresponding inter-
domain TE LSPs, the make-before-break can happen locally and is not
triggered by the head-end LSR for the inter-domain LSP. So, no
additional RSVP signaling is required for LSP re-optimization and
reoptimization is transparent to the HE LSR of the inter-domain TE LSP.

If, however, an operator desires to manually trigger reoptimization at
the head-end LSR for the inter-domain TE LSP, then this solution does
not prevent that. A manual trigger for reoptimization at the head-end
LSR SHOULD force a reoptimization thereby signaling a "new" path for
the same LSP (along the optimal path) making use of the make-before-
break procedure. In response to this new setup request, the boundary
LSR may either initiate new LSP segment setup, in case the inter-domain
TE LSP is being stitched to the intra-area/AS LSP segment or it may
select an existing or new FA-LSP in case of nesting. When the LSP setup
along the current optimal path is complete, the head end should
switchover the traffic onto that path and the old path is eventually
torn down. Note that the head-end LSR does not know a priori whether a
more optimal path exists. Such a manual trigger from the head-end LSR
of the inter-domain TE LSP is, however, not considered to be a frequent
occurrence.

Note that stitching or nesting rely on local optimization: the
reoptimization process allows to locally reoptimize each TE LSP segment
or FA-LSP: hence, the reoptimization is not global and consequently the
end to end path may no longer to optimal, should it be optimal when set
up.

Procedures described in [LOOSE-REOPT] MUST be used if the operator does
## Oh, no. You cannot MUST the procedures of an Information document.
not desire local re-optimization of certain inter-domain LSPs. In this
case, any re-optimization event within the domain MUST be reported to
the head-end node. This SHOULD be a configurable policy.

## You need to comment that local repotimization (either of hierarchical
## LSPs and stiched segments, or reported to the ingress) does not handle
## the case where a better path would use different domains. Please
## think about that case.

8.     Security Considerations

## This section seems very lightweight given the importance of
## inter-AS trust boundaries.

 Vasseur, Ayyangar and Zhang                                  16



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


When signaling an inter-AS TE, an Operator may make use of the already
defined security features related to RSVP (authentication). This may
require some coordination between Service Providers to share the keys
(see RFC 2747 and RFC 3097).
## Should these be normative references?

9.     Intellectual Property Considerations

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights. Information
  on the procedures with respect to rights in RFC documents can be
  found in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this
  specification can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard. Please address the information to the IETF at ietf-
  [e-mail]..

  IPR Disclosure Acknowledgement

  By submitting this Internet-Draft, I certify that any applicable
  patent or other IPR claims of which I am aware have been disclosed,
  and any of which I become aware will be disclosed, in accordance with
  RFC 3668.
## You don't need to say this twice. It is already at the head of the
## I-D

10.    Acknowledgments

We would like to acknowledge input and helpful comments from Adrian
Farrel.

## Has no-one else reviewed this I-D? That is a problem!

11 References

10.1.  Normative References

[RFC] Bradner, S., "Key words for use in RFCs to indicate requirements
## s/[RFC]/[RFC2119]/
levels", RFC 2119, March 1997.

[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
## Out of date reference

 Vasseur, Ayyangar and Zhang                                  17



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005


[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
## Out of date reference

[RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) û Version
1, Functional Specificationö, RFC 2205, September 1997.

[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.

[REFRESH-REDUCTION] Berger et al, ôRSVP Refresh Overhead Reduction
Extensionsö, RFC2961, April 2001.
## Not sure why this is listed as normative, or even at all.

[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December
2003.
## Now an RFC
## Note, this RFC is not referenced. It probably should be.

[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", RFC 3630, September 2003.

[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering",
RFC 3784, June 2004.

10.2.  Informative references

[INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements
for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea-
mpls-te-req-03.txt, work in progress.

[INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic
Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req-09.txt,
work in progress.

[INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A Framework
for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter-
domain-framework-00.txt, work in progress.

[FACILITY-BACKUP] Le Roux, J.L., Vasseur, J.P. et al. "Framework for
PCE based MPLS Facility Backup Path Computation", draft-leroux-pce-
backup-comp-frwk-00.txt, work in progress
## A very interesting I-D, no doubt, but you have not referenced it, so
## why is it listed?

[INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. ôInter-domain MPLS
Traffic Engineering û RSVP extensionsö, draft-ietf-ccamp-inter-domain-
rsvp-te, work in progress.

[LSP-STITCHING] Ayyangar, A., Vasseur, JP. ôLabel Switched Path
Stitching with Generalized MPLS Traffic Engineeringö, draft-ietf-ccamp-
lsp-stitching-00, Work under progress.





 Vasseur, Ayyangar and Zhang                                  18



draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005



[LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes-04,(work
in progress).
## One of my favorite I-Ds. But why have you listed it without
## referencing it?
##
## In fact, all of the remaining I-Ds are very worthwhile, but except
## for [LSP-HIER] and [LOOSE-PATH-REOPT] you haven't referenced them.
##
## On the other hand, you do reference [RFC2702] and [CRANKBACK] so
## you should list them here.

[GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay
Model", (work in progress).

[EXCLUDE-ROUTE] Lee et all, Exclude Routes - Extension to RSVP-TE,
draft-ietf-ccamp-rsvp-te-exclude-route-00.txt, work in progress.

[LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G.,
Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS",
Internet Draft <draft-ietf-mpls-lsp-ping-02.txt>, October 2002. (Work
in Progress)

[MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS
Networks", RFC 3443 Updates RFC 3032) ", January 2003

[LOOSE-PATH-REOPT] Vasseur, Ikejiri and Zhang ôReoptimization of an
explicit loosely routed MPLS TE pathsö, draft-ietf-ccamp-loose-path-
reopt-01.txt, July 2004, Work in Progress.

[NODE-ID] Vasseur, Ali and Sivabalan, ôDefinition of an RRO node-id
subobjectö,  draft-ietf-mpls-nodeid-subobject-05.txt, work in progress.

[LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002.

[MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS
Networks", RFC 3443 (Updates RFC 3032) ", January 2003.




Envelope-to: [e-mail]
Delivery-date: Tue, 21 Jun 2005 23:43:23 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>
Cc: "Richard Rabbat" <[e-mail]>, "'NTT - Kohei Shiomoto'" <[e-mail]>, "'Rajiv Papneja'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt 
Date: Tue, 21 Jun 2005 16:41:50 -0700
Message-ID: <006e01c576ba$cc3b4c40$3a3ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,
The update has the major changes listed below, in addition to multiple
editorial fixes, typos and general wording. We also changed the title of =
the
draft to clarify it. I believe it has captured all IPv4/IPv6 issues. =
Thanks
for all the suggestions. Please send us more comments when you have time =
to
read through this.=20
In particular, can we get feedback on the new section 5.2.3?=20

Thanks.

   - Updated sections 5.2.1 and 5.2.2 based on consensus in the WG=20
   =20
   - Moved common addressing text to new section 4=20
   =20
   - Added text in section 5.2.2 to address FA LSP=20
   =20
   - Integrated sections 4.2.3 and 5.2.1 as 7.2=20
   =20
   - Added new section 5.2.3 on Extended Tunnel ID=20
   =20
   - Integrated draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00 in new =
section 9


> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of=20
> [e-mail]
> Sent: Tuesday, June 21, 2005 12:50 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt=20
>=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Common Control and=20
> Measurement Plane Working Group of the IETF.
>=20
> 	Title		: Use of Addresses in Generalized Multi-Protocol
>                           Label Switching (GMPLS) Networks
> 	Author(s)	: K. Shiomoto, et al.
> 	Filename	: draft-ietf-ccamp-gmpls-addressing-01.txt
> 	Pages		: 23
> 	Date		: 2005-6-21
> =09
> This document explains and clarifies the use of addresses in=20
>    Generalized Multi-Protocol Label Switching (GMPLS)=20
> networks.  The aim=20
>    of this document is to facilitate and ensure better=20
> interworking of=20
>    GMPLS-capable Label Switching Routers (LSRs) based on experience=20
>    gained in deployments and interoperability testing and proper=20
>    interpretation of published RFCs.=20
>    =20
>    The document recommends a proper approach for the=20
> interpretation and=20
>    choice of address and identifier fields within GMPLS protocols and=20
>    references specific control plane usage models.  It also examines=20
>    some common GMPLS Resource Reservation Protocol-Traffic=20
> Engineering=20
>    (RSVP-TE) signaling message processing issues and recommends=20
>    solutions.  It finally discusses how to handle IPv6 sources and=20
>    destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB=20
>    (Management Information Base) modules.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-add
ressing-01.txt

To remove yourself from the I-D Announcement list, send a message to=20
[e-mail] with the word unsubscribe in the body of =
the
message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
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-addressing-01.txt".

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-01.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.




Envelope-to: [e-mail]
Delivery-date: Tue, 21 Jun 2005 23:21:08 +0000
Message-ID: <06c601c576b8$0e920dc0$7f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-03.txt 
Date: Wed, 22 Jun 2005 00:22:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Just a quick note to explain the revisions in this I-D.

1. Restructure the main terminology section so that the GMPLS terms and
ASON terms are broken out into separate subsections.
2. Remodel the intro and wrap-up text to be more "positive".
3. Apply a few tweaks to GMPLS terms for clarity after discussion in the
ITU-T
4. Apply *most* of the changes to the ASON terms suggested in the liaison
from Study Group 15

The last point is limited to "most" because we had a couple of points
about which we weren't clear. We have sent mail to Ben Mack-Crane who is
acting as special envoy within SG15, and he will attempt to resolve the
questions for us. At the moment we are going to try to do this without
formal liaison, but the next revision (including any responses he sends)
will be sent back to SG15 formally.

As usual, we would really welcome the review of this document by GMPLS
experts and ASON experts. Comments may be sent provately to the authors or
on the CCAMP list.

Thanks,
Adrian





Envelope-to: [e-mail]
Delivery-date: Tue, 21 Jun 2005 19:52:27 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-03.txt 
Message-Id: <[e-mail]>
Date: Tue, 21 Jun 2005 15:50: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		: A Lexicography for the Interpretation of
                          Generalized Multiprotocol Label Switching
                         (GMPLS) Terminology within The Context of the
                         ITU-T's Automatically Switched Optical Network
                         (ASON) Architecture
	Author(s)	: I. Bryskin, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
	Pages		: 17
	Date		: 2005-6-21
	
Generalized Multiprotocol Label Switching (GMPLS) has been developed
   by the IETF to facilitate the establishment of Label Switched Paths
   (LSPs) in a variety of data plane technologies and across several
   architectural models. The ITU-T has specified an architecture for
   the control of Automatically Switched Optical Networks (ASON).

   This document provides a lexicography for the interpretation of GMPLS
   terminology within the context of the ASON architecture.

   It is important to note that GMPLS is applicable in a wider contexts
   than ASON. The definitions presented in this document do not provide
   exclusive or complete interpretations of GMPLS concepts. This
   document simply to allows the GMPLS terms to be applied within the
   ASON context.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-03.txt

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

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

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Tue, 21 Jun 2005 19:52:20 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt 
Message-Id: <[e-mail]>
Date: Tue, 21 Jun 2005 15:50: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		: Use of Addresses in Generalized Multi-Protocol
                          Label Switching (GMPLS) Networks
	Author(s)	: K. Shiomoto, et al.
	Filename	: draft-ietf-ccamp-gmpls-addressing-01.txt
	Pages		: 23
	Date		: 2005-6-21
	
This document explains and clarifies the use of addresses in 
   Generalized Multi-Protocol Label Switching (GMPLS) networks.  The aim 
   of this document is to facilitate and ensure better interworking of 
   GMPLS-capable Label Switching Routers (LSRs) based on experience 
   gained in deployments and interoperability testing and proper 
   interpretation of published RFCs. 
    
   The document recommends a proper approach for the interpretation and 
   choice of address and identifier fields within GMPLS protocols and 
   references specific control plane usage models.  It also examines 
   some common GMPLS Resource Reservation Protocol-Traffic Engineering 
   (RSVP-TE) signaling message processing issues and recommends 
   solutions.  It finally discusses how to handle IPv6 sources and 
   destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB 
   (Management Information Base) modules.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-01.txt

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

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

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Mon, 20 Jun 2005 13:28:36 +0000
Sensitivity: 
Subject: Re: LCAS and GMPLS
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 20 Jun 2005 15:28:37 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Adrian,
           again agreed.

Diego



"Adrian Farrel" <[e-mail]> on 20/06/2005 15.25.06

Please respond to "Adrian Farrel" <[e-mail]>

To:    "Wataru Imajuku <imajuku.wataru", "Diego Caviglia"
       <[e-mail]>
cc:    "ccamp  <ccamp"

Subject:    Re: LCAS and GMPLS

Hi Diego,

> If I've correctly understood the ASSOCIATION obj it should work in the
> same way as the Call_ID (operator spec) obj.

If you MUST make the comparison :-)

> Wataru if you're familiar with ITU I'll try to make a corrispondence
> between the two objects.
> The corrispondeces are the following:
> Call_ID (RCF 3473)    ASSOCIATION
(draft-ietf-ccamp-gmpls-recovery-e2e-signaling)
> Source LSR Address <--> IPv4 Association Source
> Type 1 = 4 bytes        Type 1 = 4 bytes
> Type 2 = 16 bytes       Type 2 = 16 bytes
> Type 3 = 30 bytes       na
> Type 4 = 6 bytes        na
>
> Local Identifier   <--> Association ID
> 8 bytes                 2 bytes
>
> So apart from the maximum number of associations/Calls that a source can
> originate seems to me that the two objects solve well the problem.
>
> IMHO Call_ID is better but I'm not going to stress this point, if the
> feeling of the group is to use ASSOCIATION obj for me it is fine.
So, something that might be useful would be if the requirements I-D made
some statement about the number of VCAT groups likely to be originated by a
single sender.

It is my *guess* that the number of such groups is likely to be smaller
than the number of LSPs associated by the same sender. Thus, the size of
the group ID does not need to be larger than the size of the LSP-ID.


If there is a need to overload the semanitc of the group ID for correlation
with LCAS or something, then we should discuss the point, but so far we
have only discussed it in the context of grouping together a set of LSPs.

Cheers,
Adrian











Envelope-to: [e-mail]
Delivery-date: Mon, 20 Jun 2005 13:26:42 +0000
Sensitivity: 
Subject: Re: LCAS and GMPLS
To: "Adrian Farrel" <[e-mail]>
Cc: ""ccamp" <ccamp" <[e-mail]>, ""Wataru Imajuku" <imajuku.wataru" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 20 Jun 2005 15:26:31 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Adrian,

> We need to write down how to use the Association ID for VCAT grouping.
> That is, we must explain that the Association ID value should be an
> arbitrary value unique within the scope of the Association Sourse address
> and common to all members of the group.

Yes this is also my view.  That is consistent with ITU-T Call_ID (sorry for
quoting again ITU-T here ;-))

Regards

Diego






Envelope-to: [e-mail]
Delivery-date: Mon, 20 Jun 2005 13:23:39 +0000
Message-ID: <03e601c5759b$9470ac80$7f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Wataru Imajuku <imajuku.wataru" <[e-mail]>, "Diego Caviglia" <[e-mail]>
Cc: "ccamp  <ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Mon, 20 Jun 2005 14:25:06 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E3_01C575A3.DB2C4DC0"

This is a multi-part message in MIME format.

------=_NextPart_000_03E3_01C575A3.DB2C4DC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Diego,

> If I've correctly understood the ASSOCIATION obj it should work in the
> same way as the Call_ID (operator spec) obj.

If you MUST make the comparison :-)

> Wataru if you're familiar with ITU I'll try to make a corrispondence
> between the two objects.
> The corrispondeces are the following:
> Call_ID (RCF 3473)    ASSOCIATION =
(draft-ietf-ccamp-gmpls-recovery-e2e-signaling)
> Source LSR Address <--> IPv4 Association Source
> Type 1 =3D 4 bytes        Type 1 =3D 4 bytes
> Type 2 =3D 16 bytes       Type 2 =3D 16 bytes
> Type 3 =3D 30 bytes       na
> Type 4 =3D 6 bytes        na
>=20
> Local Identifier   <--> Association ID
> 8 bytes                 2 bytes
>=20
> So apart from the maximum number of associations/Calls that a source =
can
> originate seems to me that the two objects solve well the problem.
>=20
> IMHO Call_ID is better but I'm not going to stress this point, if the
> feeling of the group is to use ASSOCIATION obj for me it is fine.

So, something that might be useful would be if the requirements I-D made =
some statement about the number of VCAT groups likely to be originated =
by a single sender.

It is my *guess* that the number of such groups is likely to be smaller =
than the number of LSPs associated by the same sender. Thus, the size of =
the group ID does not need to be larger than the size of the LSP-ID.


If there is a need to overload the semanitc of the group ID for =
correlation with LCAS or something, then we should discuss the point, =
but so far we have only discussed it in the context of grouping together =
a set of LSPs.

Cheers,
Adrian

------=_NextPart_000_03E3_01C575A3.DB2C4DC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Hi Diego,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; If I've correctly understood the =
ASSOCIATION=20
obj it should work in the<BR>&gt;&nbsp;same way as the Call_ID (operator =
spec)=20
obj.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>If you MUST make the comparison =
:-)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
<DIV>&gt; Wataru if you're familiar with ITU I'll try to make a=20
corrispondence<BR>&gt; between the two objects.<BR>&gt; The =
corrispondeces are=20
the following:<BR>&gt; Call_ID (RCF 3473)&nbsp;&nbsp;&nbsp; ASSOCIATION=20
(draft-ietf-ccamp-gmpls-recovery-e2e-signaling)<BR>&gt; Source LSR =
Address=20
&lt;--&gt; IPv4 Association Source<BR>&gt; Type 1 =3D 4=20
bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type 1 =3D 4 =
bytes<BR>&gt; Type 2=20
=3D 16 bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type 2 =3D 16 =
bytes<BR>&gt; Type 3=20
=3D 30 bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; na<BR>&gt; Type 4 =3D 6 =

bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; na<BR>&gt; <BR>&gt; =
Local=20
Identifier&nbsp;&nbsp; &lt;--&gt; Association ID<BR>&gt; 8=20
bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
2 bytes<BR>&gt; <BR>&gt; So apart from the maximum number of =
associations/Calls=20
that a source can<BR>&gt; originate seems to me that the two objects =
solve well=20
the problem.<BR>&gt; <BR>&gt; IMHO Call_ID is better but I'm not going =
to stress=20
this point, if the<BR>&gt; feeling of the group is to use ASSOCIATION =
obj for me=20
it is fine.<BR></DIV>
<DIV>So, something that might be useful would be if the requirements I-D =
made=20
some statement about the number of VCAT groups likely to be originated =
by a=20
single sender.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is my *guess* that the number of such groups is likely to be =
smaller=20
than the number of LSPs associated by the same sender. Thus, the size of =
the=20
group ID does not need to be larger than the size of the LSP-ID.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>If there is a need to overload the semanitc of the group ID for =
correlation=20
with LCAS or something, then we should discuss the point, but so far we =
have=20
only discussed it in the context of grouping together a set of =
LSPs.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Cheers,</DIV>
<DIV>Adrian</DIV>
<DIV>&nbsp;</DIV></FONT></BODY></HTML>

------=_NextPart_000_03E3_01C575A3.DB2C4DC0--




Envelope-to: [e-mail]
Delivery-date: Mon, 20 Jun 2005 13:21:27 +0000
Message-ID: <03e201c5759b$1bd5e330$7f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "ccamp" <[e-mail]>, "Wataru Imajuku" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Mon, 20 Jun 2005 14:19:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

> > >   Now, consider the LCAS.
> > >   Does the LCAS define or have primary connetion ?
> > >   I think all of conections in LCAS should be equivalent.
>
> >Why is primary conneciton valid? LCAS has nothing to do with
protection.
> >The Association object provides an *arbitrary* association ID that is
> >common across all LSPs in the same group, and unique within the context
of
> >the association source. There is no concept of a primary connection in
the
> >process of association.
>
>   But, my concern is the value of Association ID in VCAT.
>   Different from 1:n protection, generic VCAT group does not have
primary
>   connection.
>   In the case of 1:n protection, we define "primary" connection.

Wataru,

draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt introduces the
Association object and describes its use for protection. It is not
surprising that it does not include its use for VCAT. We need to define
that use now.

When draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt says to use an
LSP-ID in the Association ID field, it is describing how you associate
LSPs for protection.

We need to write down how to use the Association ID for VCAT grouping.
That is, we must explain that the Association ID value should be an
arbitrary value unique within the scope of the Association Sourse address
and common to all members of the group.

>   But, in the case of generic VCAT, the Association ID of second and
third
> connection should be first connection of LSP ID ?
>   My answer is no.

The only person to suggest doing this is you. Everyone agrees with you
that the answer is no.

>   The first connection in VCAT group can be torn down before the tear
down
>   of secondary or third connection.
>   If the second and third connection use LSP ID of first connection for
>   their Association ID, the second and third connection of the VCAT
group
>   use non-existing LSP ID for their Association ID in some state.
>   Do we accept this kind of state ?

No, we don't. And we do not suggest it.

Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 20 Jun 2005 08:18:43 +0000
Sensitivity: 
Subject: Re: LCAS and GMPLS
To: "Wataru Imajuku <imajuku.wataru" <[e-mail]>
Cc: ""Adrian Farrel" <adrian" <[e-mail]>, ""ccamp" <ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 20 Jun 2005 10:16:18 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

If I've correctly understood the ASSOCIATION obj it should work in the same
way as the Call_ID (operator spec) obj.

Wataru if you're familiar with ITU I'll try to make a corrispondence
between the two objects.
The corrispondeces are the following:
Call_ID (RCF 3473)                        ASSOCIATION (
draft-ietf-ccamp-gmpls-recovery-e2e-signaling)
Source LSR Address <--------------------> IPv4 Association Source
Type 1 = 4 bytes                          Type 1 = 4 bytes
Type 2 = 16 bytes                         Type 2 = 16 bytes
Type 3 = 30 bytes                         na
Type 4 = 6 bytes                          na

Local Identifier   <--------------------> Association ID
8 bytes                                   2 bytes

So a part from the maximum number of associations/Calls that a source can
originate seems to me that the two objects solve well the problem.

IMHO Call_ID is better but I'm not going to stress this point, if the
feeling of the group is to use ASSOCIATION obj for me it is fine.

Regards

Diego



Wataru Imajuku <[e-mail]>@ops.ietf.org on 20/06/2005
02.52.41

Sent by:    [e-mail]


To:    "Adrian Farrel" <[e-mail]>, "ccamp" <[e-mail]>
cc:

Subject:    Re: LCAS and GMPLS

Hi, Adrian

  Thank you for your comment.
  I should have explain my thought more in detail.


> > >see anything that forces this limitation. In fact, it would be hard to
> > >offer 1:n protection with such a scheme.
> >
> > In my understanding, the ASSOCIATION ID of ASSOCIATION Object only
> > relates protected LSP and protecting LSPs.
>
>Then I am sorry to say that your understanding is wrong.
>
>The Association object is used to associate LSPs.
>Clearly, in its use in a protection ID it describes the association for
>the purposes of protection. However, the text is carefully worded to
>ensure that the object is more widely applicable.
>To quote from section 16...
>    The ASSOCIATION object is used to associate LSPs with each other.

>You originally said...
> > > > Current ASSOCIATION objects relates only two connections.
>...but you now seem to accept that the Association object can relate more
>than one LSP since you say...
> > It's OK adoptation of ASSOCIATION Object and ID for 1:n protection.
>
>Thus, I presume that you accept that the Association object could handle
>VCAT groups with more than two LSPs.

  Yes.
  In the case of 1:n protection scheme, all of n back up paths set the
primary LSP ID
for their Association IDs.  It seems OK the use of association ID.

> >   Now, consider the LCAS.
> >   Does the LCAS define or have primary connetion ?
> >   I think all of conections in LCAS should be equivalent.

>Why is primary conneciton valid? LCAS has nothing to do with protection.
>The Association object provides an *arbitrary* association ID that is
>common across all LSPs in the same group, and unique within the context of
>the association source. There is no concept of a primary connection in the
>process of association.

  But, my concern is the value of Association ID in VCAT.
  Different from 1:n protection, generic VCAT group does not have primary
connection.
  In the case of 1:n protection, we define "primary" connection.

  But, in the case of generic VCAT, the Association ID of second and third
connection
should be first connection of LSP ID ?
  My answer is no.

  The first connection in VCAT group can be torn down before the tear down
of secondary or third connection.
  If the second and third connection use LSP ID of first connection for
their Association ID,
the second and third connection of the VCAT group use non-existing LSP ID
for their Association ID
in some state.
  Do we accept this kind of state ?

Thanks,
Wataru

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










Envelope-to: [e-mail]
Delivery-date: Mon, 20 Jun 2005 00:56:09 +0000
Message-Id: <[e-mail]>
Date: Mon, 20 Jun 2005 09:52:41 +0900
To: "Adrian Farrel" <[e-mail]>, "ccamp" <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: LCAS and GMPLS
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Adrian

  Thank you for your comment.
  I should have explain my thought more in detail.


> > >see anything that forces this limitation. In fact, it would be hard to
> > >offer 1:n protection with such a scheme.
> >
> > In my understanding, the ASSOCIATION ID of ASSOCIATION Object only
> > relates protected LSP and protecting LSPs.
>
>Then I am sorry to say that your understanding is wrong.
>
>The Association object is used to associate LSPs.
>Clearly, in its use in a protection ID it describes the association for
>the purposes of protection. However, the text is carefully worded to
>ensure that the object is more widely applicable.
>To quote from section 16...
>    The ASSOCIATION object is used to associate LSPs with each other.

>You originally said...
> > > > Current ASSOCIATION objects relates only two connections.
>...but you now seem to accept that the Association object can relate more
>than one LSP since you say...
> > It's OK adoptation of ASSOCIATION Object and ID for 1:n protection.
>
>Thus, I presume that you accept that the Association object could handle
>VCAT groups with more than two LSPs.

  Yes.
  In the case of 1:n protection scheme, all of n back up paths set the 
primary LSP ID
for their Association IDs.  It seems OK the use of association ID.

> >   Now, consider the LCAS.
> >   Does the LCAS define or have primary connetion ?
> >   I think all of conections in LCAS should be equivalent.

>Why is primary conneciton valid? LCAS has nothing to do with protection.
>The Association object provides an *arbitrary* association ID that is
>common across all LSPs in the same group, and unique within the context of
>the association source. There is no concept of a primary connection in the
>process of association.

  But, my concern is the value of Association ID in VCAT.
  Different from 1:n protection, generic VCAT group does not have primary 
connection.
  In the case of 1:n protection, we define "primary" connection.

  But, in the case of generic VCAT, the Association ID of second and third 
connection
should be first connection of LSP ID ?
  My answer is no.

  The first connection in VCAT group can be torn down before the tear down 
of secondary or third connection.
  If the second and third connection use LSP ID of first connection for 
their Association ID,
the second and third connection of the VCAT group use non-existing LSP ID 
for their Association ID
in some state.
  Do we accept this kind of state ?

Thanks,
Wataru

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




Envelope-to: [e-mail]
Delivery-date: Fri, 17 Jun 2005 14:32:34 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gp0adhOi0jCUvRdVvUl8RQLi5zaLyk0hPF5hzLocW3A4GSoh1laxEGAZN4bCkMowMO4WoTqm9jF3ImJ43YUrA8DEGHYc1VNdQjCvNvp9/ALzHHGID0t6yT14LuneeNTc4c5l+UyFuoLZztEWuqgYuoZYsAHf0FRWWoxUPF2/jtw=  ;
Message-ID: <[e-mail]>
Date: Fri, 17 Jun 2005 07:31:33 -0700 (PDT)
From: Igor Bryskin <[e-mail]>
Subject: Re: LCAS and GMPLS
To: [e-mail], Wataru Imajuku <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, ccamp <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1079727923-1119018693=:93349"
Content-Transfer-Encoding: 8bit

--0-1079727923-1119018693=:93349
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri, all

[e-mail] wrote:

hi

[snip]

>> Can you say why you think this is so?
>> Looking at draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt I do not
>> see anything that forces this limitation. In fact, it would be hard to
>> offer 1:n protection with such a scheme.

> In my understanding, the ASSOCIATION ID of ASSOCIATION Object only
> relates protected LSP and protecting LSPs.

this object includes a Association Type field (16 bits) that indicates the
type of association being identified, for recovery purposes the Type is 1;

so in the present case (i.e. base VC grouping) a new Type value would be
defined

IB>> Agree 100%

Igor



[snip]







__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-1079727923-1119018693=:93349
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Dimitri, all<BR><BR><B><I>[e-mail]</I></B> wrote:
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P><BR>hi<BR><BR>[snip]<BR><BR>&gt;&gt; Can you say why you think this is so?<BR>&gt;&gt; Looking at draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt I do not<BR>&gt;&gt; see anything that forces this limitation. In fact, it would be hard to<BR>&gt;&gt; offer 1:n protection with such a scheme.<BR><BR>&gt; In my understanding, the ASSOCIATION ID of ASSOCIATION Object only<BR>&gt; relates protected LSP and protecting LSPs.<BR><BR>this object includes a Association Type field (16 bits) that indicates the<BR>type of association being identified, for recovery purposes the Type is 1;<BR><BR>so in the present case (i.e. base VC grouping) a new Type value would be<BR>defined</P>
<P>IB&gt;&gt; Agree 100%</P>
<P>Igor</P>
<P><BR><BR>[snip]<BR><BR><BR><BR><BR></P></BLOCKQUOTE></DIV><p>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com 
--0-1079727923-1119018693=:93349--



Envelope-to: [e-mail]
Delivery-date: Fri, 17 Jun 2005 11:45:16 +0000
Message-ID: <022801c57332$14c23c80$7f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "ccamp" <[e-mail]>, "Wataru Imajuku" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Fri, 17 Jun 2005 11:34:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

Hi again Wataru,

> > > >IB>> This is an interesting requirement. Fortunately, it is
possible to
> > > >realize this requirement via GMPLS signaling by including several
> > > >ASSOCIATION objects of the same type into the same Path message.
For
> > > >instance, one of them will indicate that the signalled LSP belongs
to
> > > >the nested VCAT group, while another -to the nesting VCAT group.
> > >
> > > Current ASSOCIATION objects relates only two connections.
> >
> >Can you say why you think this is so?
> >Looking at draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt I do
not
> >see anything that forces this limitation. In fact, it would be hard to
> >offer 1:n protection with such a scheme.
>
> In my understanding, the ASSOCIATION ID of ASSOCIATION Object only
> relates protected LSP and protecting LSPs.

Then I am sorry to say that your understanding is wrong.

The Association object is used to associate LSPs.
Clearly, in its use in a protection ID it describes the association for
the purposes of protection. However, the text is carefully worded to
ensure that the object is more widely applicable.
To quote from section 16...
   The ASSOCIATION object is used to associate LSPs with each other.

You originally said...
> > > Current ASSOCIATION objects relates only two connections.
...but you now seem to accept that the Association object can relate more
than one LSP since you say...
> It's OK adoptation of ASSOCIATION Object and ID for 1:n protection.

Thus, I presume that you accept that the Association object could handle
VCAT groups with more than two LSPs.

>   Now, consider the LCAS.
>   Does the LCAS define or have primary connetion ?
>   I think all of conections in LCAS should be equivalent.

Why is primary conneciton valid? LCAS has nothing to do with protection.
The Association object provides an *arbitrary* association ID that is
common across all LSPs in the same group, and unique within the context of
the association source. There is no concept of a primary connection in the
process of association.

I hope this clarifies that the Association object is suitable for
identifying the LSPs in VCAT groups. (Pending the documentation of the
real requirements.)

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 17 Jun 2005 07:07:36 +0000
To: Wataru Imajuku <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "ccamp" <[e-mail]>
From: [e-mail]
Subject: Re: LCAS and GMPLS
MIME-Version: 1.0
Date: Fri, 17 Jun 2005 09:05:03 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

hi

[snip]

>> Can you say why you think this is so?
>> Looking at draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt I do not
>> see anything that forces this limitation. In fact, it would be hard to
>> offer 1:n protection with such a scheme.

> In my understanding, the ASSOCIATION ID of ASSOCIATION Object only
> relates protected LSP and protecting LSPs.

this object includes a Association Type field (16 bits) that indicates the
type of association being identified, for recovery purposes the Type is 1;

so in the present case (i.e. base VC grouping) a new Type value would be
defined

[snip]






Envelope-to: [e-mail]
Delivery-date: Fri, 17 Jun 2005 00:37:12 +0000
Message-Id: <[e-mail]>
Date: Fri, 17 Jun 2005 09:35:40 +0900
To: "Adrian Farrel" <[e-mail]>, "ccamp" <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: LCAS and GMPLS
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Adrian

>Hi Wataru,
>
> > > > Another requirement to consider is whether the associating the LSPs
> > > > needs to be recursive.  For example, consider an STS-3c-2v where one
>of
> > > > the STS-3c is a real contiguously >
> > > > concatenated LSP, and the other is actually an STS-1-3v (three STS-1
> > > > LSPs).  From a bearer plane point of view, this is possible.  Does
>the
> > > > service maintain the two STS-3c LSP > association and the three
>STS-1 LSP
> > > > association?
> > > > I suggest that there be a requirement for recursive association.
> > >
> > >IB>> This is an interesting requirement. Fortunately, it is possible to
> > >realize this requirement via GMPLS signaling by including several
> > >ASSOCIATION objects of the same type into the same Path message. For
> > >instance, one of them will indicate that the signalled LSP belongs to
>the
> > >nested VCAT group, while another -to the nesting VCAT group.
> >
> > Current ASSOCIATION objects relates only two connections.
>
>Can you say why you think this is so?
>Looking at draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt I do not
>see anything that forces this limitation. In fact, it would be hard to
>offer 1:n protection with such a scheme.

  In my understanding, the ASSOCIATION ID of ASSOCIATION Object only 
relates protected LSP and protecting LSPs.
  It's OK adoptation of ASSOCIATION Object and ID for 1:n protection.

  Now, consider the LCAS.
  Does the LCAS define or have primary connetion ?
  I think all of conections in LCAS should be equivalent.

Wataru

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




Envelope-to: [e-mail]
Delivery-date: Thu, 16 Jun 2005 19:12:16 +0000
Message-ID: <010f01c572a7$6a762640$7f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>, <[e-mail]>
Cc: "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Thu, 16 Jun 2005 20:12:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Greg,

Sorry, no. We don't have access to the Recommendations you list.
This is particularly hard for those of us who are independent or work for
small companies that are not ITU-T members.

Note that you can get three free downloads of Recommendations by following
the links on the ITU web pages, so this may help a little.

Great news that you have started the work.

Cheers,
Adrian
----- Original Message ----- 
From: "Greg Bernstein" <[e-mail]>
To: <[e-mail]>
Cc: "ccamp" <[e-mail]>
Sent: Thursday, June 16, 2005 5:03 PM
Subject: Re: LCAS and GMPLS


> Hi Maarten, thanks.  Adrian and ITU folks, I went to the additional
> CCAMP web page and looked at the liasons but didn't see
> G.806, G.783, G.783, G.798 nor G.7042 (LCAS itself) listed. Are these
> available to the CCAMP workgroup.  My archive of ITU-T
> documents is a bit out of date.
>
> Stephen, did Maarten's answer clear things up?  Think about VCAT as a
> physical layer (circuit based) inverse multiplexing technique, hence to
> keep the hardware reasonable the spec. (G.707) doesn't allow for mix and
> matching component types in a VCAT group.  Or did you mean something
> else with your recursive composition idea?
>
> Adrian, I've started on the I-D using the relatively new XML method
> (seems easier than the MS Word or pure text method).  Anyone who wants
> to help
> or review prior to submission let me know.  Note that my
> [e-mail] e-mail address is checked more frequently
> than my [e-mail] address.
>
> Greg B.
> [e-mail] wrote:
>
> >Greg,
> >
> >
> >
> >>E.g., what about renumbering?
> >>
> >>
> >The renumbering is a LCAS element (fully LCAS controlled), that NMS or
> >GMPLS should not be bothered about.
> >Only if you want to operate VCAT with LCAS disabled, NMS/ASON/GMPLS has
to
> >control the sequence numbers, but changes in the group size is not
hitless
> >without LCAS.
> >
> >Hereafter some information on the VCAT/LCAS associated parameters as
> >extracted from G.806 (02/04) and G.783 (02/04).
> >
> >10.1/G.806 includes a generic specification for the VCAT/LCAS
functions,
> >inlcuding a list of MI signals (MI: Management Information) which
> >management needs to control and gets reported. G.783 and G.798 specify
the
> >technology specific functions, using the specifications in G.806 as
basis.
> >
> >Input MI signals:
> >=================
> >P-Xv/P-X-L_A_So_MI_LCASEnable:
> >The MI_LCASEnable input controls whether the LCAS functionality is
enabled
> >for the source function (MI_LCASEnable = true) or disabled
(MI_LCASEnable
> >= false).
> >
> >P-Xv/P-X-L_A_So_MI_ProvM[1..XMT]:
> >The MI_ProvM[1..XMT] input controls whether a P[i]_AP at the P-Xv_AP is
> >provisioned to be a member of the VCG (MI_ProvM[i] = 1) or not
> >(MI_ProvM[i] = 0).
> >
> >==> With this input parameter NMS/GNPLS controls which access points
(and
> >thus VC-n trail termination functions) are part of the VCAT group.
Note -
> >LCAS determines if there will be traffic routed over it.
> >
> >P-Xv/P-X-L_A_So_MI_PLCTThr:
> >Partial loss of capacity transmit threshold associated with cPLCT fault
> >cause.
> >
> >----------
> >
> >P-Xv/P-X-L_A_Sk_MI_LCASEnable:
> >The MI_LCASEnable input controls whether the LCAS functionality is
enabled
> >for the sink function (MI_LCASEnable = true) or disabled (MI_LCASEnable
=
> >false). If LCAS is enabled, the function auto-detects which type of
source
> >it is interfacing to. The output MI_LCAS_So_Detected reports whether
the
> >present sink function detected an LCAS-enabled source function
> >(MI_LCAS_So_Detected=true) or a non-LCAS-enabled source
> >(MI_LCAS_So_Detected=false, see below for details). Only if both
> >MI_LCASEnable and MI_LCAS_So_Detected are true is the LCAS
functionality
> >active in the function.
> >
> >P-Xv/P-X-L_A_Sk_MI_ProvM[1..XMR]:
> >The MI_ProvM[1..XMR] input controls whether a particular one of the
> >available physical resources at the P-Xv_AP is provisioned to be a
member
> >of the VCG (MI_ProvM[i] = 1) or not (MI_ProvM[i] = 0).
> >
> >==> With this input parameter NMS/GMPLS controls which access points
(and
> >thus VC-n trail termination functions) are part of the VCAT group.
Note -
> >LCAS determines if there will be traffic routed over it.
> >
> >P-Xv/P-X-L_A_Sk_MI_PLCRThr:
> >Partial loss of capacity receive threshold associated with cPLCR fault
> >cause.
> >
> >P-Xv/P-X-L_A_Sk_MI_TSDEnable:
> >The MI_TSDEnable input controls whether the sink function uses
AI_TSD[i]
> >indications as contributors for signalling defective members back to
the
> >LCAS source function (MI_TSDEnable = true) or whether it ignores
AI_TSD[i]
> >indications altogether (MI_TSDEnable = false).
> >
> >P-Xv/P-X-L_A_Sk_MI_HOTime:
> >The MI_HOTime input controls whether the Hold-Off (HO) timer is enabled
or
> >disabled for the sink function and, if enabled, what the value of the
> >timer is. If MI_HOTime = 0, the HO timer shall be disabled, if
MI_HOTime 0
> >it shall be enabled.
> >
> >P-Xv/P-X-L_A_Sk_MI_WTRTime:
> >The MI_WTRTime input controls whether the Wait-To-Restore (WTR) timer
is
> >enabled or disabled for the sink function and, if enabled, what the
value
> >of the timer is. If MI_WTRTime = 0, the WTR timer shall be disabled, if
> >MI_WTRTime 0 it shall be enabled.
> >The range of values for the HO/WTR timers is as defined in ITU-T Rec.
> >G.808.1.
> >
> >P-X-L_TT_Sk_MI_SSF_Reported:
> >Controls if cSSF fault cause is reported. Typically owned by NMS.
> >
> >
> >Output MI signals:
> >==================
> >P-Xv/P-X-L_A_So_MI_XAT:
> >Current size of the transmitted payload.
> >
> >P-Xv/P-X-L_A_So_MI_XMT
> >Maximum size of the transmitted payload.
> >
> >P-Xv/P-X-L_A_So_MI_TxSQ[1..XMT]
> >Indication of which sequence number (_SQmap[i]) is being carried over a
> >particular P_AI (P_AI[i]) signal.
> >
> >P-Xv/P-X-L_A_Sk_MI_XMR
> >Maximum size of the received payload.
> >
> >P-Xv/P-X-L_A_Sk_MI_XAR
> >Current size of the received payload
> >
> >P-Xv/P-X-L_A_Sk_MI_DMFI[1..XMR]
> >The relative delay, in MFI units, between each provisioned member and
the
> >earliest-arriving member among those considered for the calculation
> >
> >P-Xv/P-X-L_A_Sk_MI_LCAS_So_Detected
> >Indication if remote node supports LCAS.
> >
> >P-Xv/P-X-L_A_Sk_MI_AcSQ[1..XMR]
> >Indication of which sequence number is being received over a particular
> >P_AI (P_AI[i]) signal.
> >
> >
> >Besides these VCAT/LCAS specific parameters, you need to control a
subset
> >of the individual trail termination (e.g. S4_TT) function and the
client
> >adaptation (e.g. S4-X/ETH_A) function parameters. E.g. for VC-4 and
VC-3
> >TT_Sk functions:
> >
> >Input MI parameters:
> >====================
> >Sn_TT_Sk_MI_TPmode
> >Termination Point mode to control alarm free path set up. Refer to
> >6.1/G.806 and 7.1.4/G.7710.
> >
> >Sn_TT_Sk_MI_ExTI
> >Expected Trace Identifier value must be configured by GMPLS when GMPLS
> >sets up VC-n network connection; action is to read MI_TxTI parameter in
> >TT_So and carry this value to remote end to configure MI_ExTI.
> >
> >Sn_TT_Sk_MI_TIMdis
> >Disables/Enables TIM defect detection. GMPLS should control this as
part
> >of VC-n connection setup.
> >
> >Sn_TT_Sk_MI_TIMAISdis
> >Disables/enables AIS insertion on TIM defect detection. GMPLS to
control
> >this as part of VC-n connection setup.
> >
> >Sn_TT_Sk_MI_RDI_Reported
> >Sn_TT_Sk_MI_SSF_Reported
> >Controls if cRDI and cSSF fault cause are reported. Typically owned by
> >NMS.
> >
> >Sn_TT_Sk_MI_DEGTHR
> >Sn_TT_Sk_MI_DEGM
> >Sn_TT_Sk_MI_EXC_X
> >Sn_TT_Sk_MI_DEG_X
> >Bit error defect detection process configuration parameters. Must be
> >configured as part of connection setup; values depend on SLA.
> >
> >
> >Output MI parameters:
> >=====================
> >Sn_TT_Sk_MI_AcTI
> >Accepted Trace Identifier value report.
> >
> >Parameters for one of the client adaptation functions (e.g. Sn/ETH_A,
> >G.8021) are typically outside the control of the GMPLS VC-n Group
> >connection setup; those parameters are under either NMS or client layer
> >GMPLS control.
> >
> >
> >I hope the above helps to get a feeling of what you need to control
during
> >VC-n Group connection set up.
> >Note that the VCAT group can be set up as a single VC-n Group, or as
> >multiple, diverse routed, (smaller) VC-n (sub)Groups. E.g. a 5 VC-4
VCAT
> >group may be set up as a 5 VC-4 network connection group, as a 3 VC-4
> >netowrk connection group (VCG A) and a 2 VC-4 network connection group
> >(VCG B), as five individual VC-4 network connections, ... The most
common
> >case when used to transport data will most likely be the second case:
two
> >VCGs supporting one VCAT/LCAS group. I assume that NMS and GMPLS VC-n
> >connection management would set up VCG A and a VCG B, with the
requirement
> >that both must be diverse routed.
> >
> >If the VCAT group at a later stage is to be extended to 6 VC-4 members,
> >then for the case of VCG A and VCG B, the VCG B could be extended from
2
> >to 3 VC-4 network connections. You would then issue a connection
> >modification request for VCG B and leave VCG A untouched.
> >
> >Regards,
> >Maarten
> >
> >
> >
> >
> >
> >
> >
> >
> >Greg Bernstein <[e-mail]>
> >Sent by: [e-mail]
> >15-06-2005 18:04
> >
> >        To:     Adrian Farrel <[e-mail]>, Diego Caviglia
> ><[e-mail]>
> >        cc:     yhwkim <[e-mail]>, ccamp <[e-mail]>
> >        Subject:        Re: LCAS and GMPLS
> >
> >
> >Okay Adrian I'll take a first stab at the I-D based on
> >the e-mails to date and some of my tutorial material
> >from short courses and papers.
> >
> >Thanks everyone for the info and particularly Maarten
> >for the in depth descriptions and information.  I may
> >send you some extra questions after I digest it.  I'm
> >particularly interested in places where we "enable
> >LCAS" or some entity tells LCAS to perform an "add" or
> >"delete" action. E.g., what about renumbering?
> >
> >Sounds like there are plenty of possible solutions, so
> >a focus on a clear understanding of the problem space
> >and capabilities (which are already automated, can be
> >automated, or need to be commanded) is important.
> >
> >Greg B.
> >
> >--- Adrian Farrel <[e-mail]> wrote:
> >--- Lots of snips
> >I would suggest that Greg and Diego start an I-D. Call
> >it something like "Applicability Statement for
> >Operating LCAS and VCAT with GMPLS LSPs".
> >Include:
> >- Simple overview of VCAT and LCAS (no more than a
> >page, please)
> >- Simple statement of how LSPs fit into the picture
> >(about half a page)
> >- Statement of the requirements on GMPLS signaling
> >(about a page)
> >- Mechanisms and procedures (two or three pages)
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Tired of spam?  Yahoo! Mail has the best spam protection around
> >http://mail.yahoo.com
> >
> >
> >
> >
> >
> >
> >
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 16 Jun 2005 16:05:18 +0000
Message-ID: <[e-mail]>
Date: Thu, 16 Jun 2005 09:03:35 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: [e-mail]
CC: ccamp <[e-mail]>
Subject: Re: LCAS and GMPLS
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Maarten, thanks.  Adrian and ITU folks, I went to the additional 
CCAMP web page and looked at the liasons but didn't see
G.806, G.783, G.783, G.798 nor G.7042 (LCAS itself) listed. Are these 
available to the CCAMP workgroup.  My archive of ITU-T
documents is a bit out of date.

Stephen, did Maarten's answer clear things up?  Think about VCAT as a 
physical layer (circuit based) inverse multiplexing technique, hence to
keep the hardware reasonable the spec. (G.707) doesn't allow for mix and 
matching component types in a VCAT group.  Or did you mean something
else with your recursive composition idea?

Adrian, I've started on the I-D using the relatively new XML method 
(seems easier than the MS Word or pure text method).  Anyone who wants 
to help
or review prior to submission let me know.  Note that my 
[e-mail] e-mail address is checked more frequently 
than my [e-mail] address.

Greg B.
[e-mail] wrote:

>Greg, 
>
>  
>
>>E.g., what about renumbering?
>>    
>>
>The renumbering is a LCAS element (fully LCAS controlled), that NMS or 
>GMPLS should not be bothered about.
>Only if you want to operate VCAT with LCAS disabled, NMS/ASON/GMPLS has to 
>control the sequence numbers, but changes in the group size is not hitless 
>without LCAS.
>
>Hereafter some information on the VCAT/LCAS associated parameters as 
>extracted from G.806 (02/04) and G.783 (02/04).
>
>10.1/G.806 includes a generic specification for the VCAT/LCAS functions, 
>inlcuding a list of MI signals (MI: Management Information) which 
>management needs to control and gets reported. G.783 and G.798 specify the 
>technology specific functions, using the specifications in G.806 as basis.
>
>Input MI signals:
>=================
>P-Xv/P-X-L_A_So_MI_LCASEnable:
>The MI_LCASEnable input controls whether the LCAS functionality is enabled 
>for the source function (MI_LCASEnable = true) or disabled (MI_LCASEnable 
>= false).
>
>P-Xv/P-X-L_A_So_MI_ProvM[1..XMT]:
>The MI_ProvM[1..XMT] input controls whether a P[i]_AP at the P-Xv_AP is 
>provisioned to be a member of the VCG (MI_ProvM[i] = 1) or not 
>(MI_ProvM[i] = 0). 
>
>==> With this input parameter NMS/GNPLS controls which access points (and 
>thus VC-n trail termination functions) are part of the VCAT group. Note - 
>LCAS determines if there will be traffic routed over it.
>
>P-Xv/P-X-L_A_So_MI_PLCTThr:
>Partial loss of capacity transmit threshold associated with cPLCT fault 
>cause.
>
>----------
>
>P-Xv/P-X-L_A_Sk_MI_LCASEnable:
>The MI_LCASEnable input controls whether the LCAS functionality is enabled 
>for the sink function (MI_LCASEnable = true) or disabled (MI_LCASEnable = 
>false). If LCAS is enabled, the function auto-detects which type of source 
>it is interfacing to. The output MI_LCAS_So_Detected reports whether the 
>present sink function detected an LCAS-enabled source function 
>(MI_LCAS_So_Detected=true) or a non-LCAS-enabled source 
>(MI_LCAS_So_Detected=false, see below for details). Only if both 
>MI_LCASEnable and MI_LCAS_So_Detected are true is the LCAS functionality 
>active in the function.
>
>P-Xv/P-X-L_A_Sk_MI_ProvM[1..XMR]:
>The MI_ProvM[1..XMR] input controls whether a particular one of the 
>available physical resources at the P-Xv_AP is provisioned to be a member 
>of the VCG (MI_ProvM[i] = 1) or not (MI_ProvM[i] = 0). 
>
>==> With this input parameter NMS/GMPLS controls which access points (and 
>thus VC-n trail termination functions) are part of the VCAT group. Note - 
>LCAS determines if there will be traffic routed over it.
>
>P-Xv/P-X-L_A_Sk_MI_PLCRThr:
>Partial loss of capacity receive threshold associated with cPLCR fault 
>cause.
>
>P-Xv/P-X-L_A_Sk_MI_TSDEnable:
>The MI_TSDEnable input controls whether the sink function uses AI_TSD[i] 
>indications as contributors for signalling defective members back to the 
>LCAS source function (MI_TSDEnable = true) or whether it ignores AI_TSD[i] 
>indications altogether (MI_TSDEnable = false).
>
>P-Xv/P-X-L_A_Sk_MI_HOTime:
>The MI_HOTime input controls whether the Hold-Off (HO) timer is enabled or 
>disabled for the sink function and, if enabled, what the value of the 
>timer is. If MI_HOTime = 0, the HO timer shall be disabled, if MI_HOTime 0 
>it shall be enabled. 
>
>P-Xv/P-X-L_A_Sk_MI_WTRTime:
>The MI_WTRTime input controls whether the Wait-To-Restore (WTR) timer is 
>enabled or disabled for the sink function and, if enabled, what the value 
>of the timer is. If MI_WTRTime = 0, the WTR timer shall be disabled, if 
>MI_WTRTime 0 it shall be enabled. 
>The range of values for the HO/WTR timers is as defined in ITU-T Rec. 
>G.808.1.
>
>P-X-L_TT_Sk_MI_SSF_Reported:
>Controls if cSSF fault cause is reported. Typically owned by NMS.
>
>
>Output MI signals:
>==================
>P-Xv/P-X-L_A_So_MI_XAT:
>Current size of the transmitted payload. 
>
>P-Xv/P-X-L_A_So_MI_XMT
>Maximum size of the transmitted payload.
>
>P-Xv/P-X-L_A_So_MI_TxSQ[1..XMT]
>Indication of which sequence number (_SQmap[i]) is being carried over a 
>particular P_AI (P_AI[i]) signal. 
>
>P-Xv/P-X-L_A_Sk_MI_XMR
>Maximum size of the received payload.
>
>P-Xv/P-X-L_A_Sk_MI_XAR
>Current size of the received payload
>
>P-Xv/P-X-L_A_Sk_MI_DMFI[1..XMR]
>The relative delay, in MFI units, between each provisioned member and the 
>earliest-arriving member among those considered for the calculation
>
>P-Xv/P-X-L_A_Sk_MI_LCAS_So_Detected
>Indication if remote node supports LCAS.
>
>P-Xv/P-X-L_A_Sk_MI_AcSQ[1..XMR]
>Indication of which sequence number is being received over a particular 
>P_AI (P_AI[i]) signal. 
>
>
>Besides these VCAT/LCAS specific parameters, you need to control a subset 
>of the individual trail termination (e.g. S4_TT) function and the client 
>adaptation (e.g. S4-X/ETH_A) function parameters. E.g. for VC-4 and VC-3 
>TT_Sk functions:
>
>Input MI parameters:
>====================
>Sn_TT_Sk_MI_TPmode
>Termination Point mode to control alarm free path set up. Refer to 
>6.1/G.806 and 7.1.4/G.7710.
>
>Sn_TT_Sk_MI_ExTI
>Expected Trace Identifier value must be configured by GMPLS when GMPLS 
>sets up VC-n network connection; action is to read MI_TxTI parameter in 
>TT_So and carry this value to remote end to configure MI_ExTI.
>
>Sn_TT_Sk_MI_TIMdis
>Disables/Enables TIM defect detection. GMPLS should control this as part 
>of VC-n connection setup.
>
>Sn_TT_Sk_MI_TIMAISdis
>Disables/enables AIS insertion on TIM defect detection. GMPLS to control 
>this as part of VC-n connection setup.
>
>Sn_TT_Sk_MI_RDI_Reported
>Sn_TT_Sk_MI_SSF_Reported
>Controls if cRDI and cSSF fault cause are reported. Typically owned by 
>NMS.
>
>Sn_TT_Sk_MI_DEGTHR
>Sn_TT_Sk_MI_DEGM
>Sn_TT_Sk_MI_EXC_X
>Sn_TT_Sk_MI_DEG_X
>Bit error defect detection process configuration parameters. Must be 
>configured as part of connection setup; values depend on SLA.
>
>
>Output MI parameters:
>=====================
>Sn_TT_Sk_MI_AcTI
>Accepted Trace Identifier value report.
>
>Parameters for one of the client adaptation functions (e.g. Sn/ETH_A, 
>G.8021) are typically outside the control of the GMPLS VC-n Group 
>connection setup; those parameters are under either NMS or client layer 
>GMPLS control.
>
>
>I hope the above helps to get a feeling of what you need to control during 
>VC-n Group connection set up.
>Note that the VCAT group can be set up as a single VC-n Group, or as 
>multiple, diverse routed, (smaller) VC-n (sub)Groups. E.g. a 5 VC-4 VCAT 
>group may be set up as a 5 VC-4 network connection group, as a 3 VC-4 
>netowrk connection group (VCG A) and a 2 VC-4 network connection group 
>(VCG B), as five individual VC-4 network connections, ... The most common 
>case when used to transport data will most likely be the second case: two 
>VCGs supporting one VCAT/LCAS group. I assume that NMS and GMPLS VC-n 
>connection management would set up VCG A and a VCG B, with the requirement 
>that both must be diverse routed.
>
>If the VCAT group at a later stage is to be extended to 6 VC-4 members, 
>then for the case of VCG A and VCG B, the VCG B could be extended from 2 
>to 3 VC-4 network connections. You would then issue a connection 
>modification request for VCG B and leave VCG A untouched.
>
>Regards,
>Maarten 
>
>
>
>
>
>
>
>
>Greg Bernstein <[e-mail]>
>Sent by: [e-mail]
>15-06-2005 18:04
> 
>        To:     Adrian Farrel <[e-mail]>, Diego Caviglia 
><[e-mail]>
>        cc:     yhwkim <[e-mail]>, ccamp <[e-mail]>
>        Subject:        Re: LCAS and GMPLS
>
>
>Okay Adrian I'll take a first stab at the I-D based on
>the e-mails to date and some of my tutorial material
>from short courses and papers. 
>
>Thanks everyone for the info and particularly Maarten
>for the in depth descriptions and information.  I may
>send you some extra questions after I digest it.  I'm
>particularly interested in places where we "enable
>LCAS" or some entity tells LCAS to perform an "add" or
>"delete" action. E.g., what about renumbering? 
>
>Sounds like there are plenty of possible solutions, so
>a focus on a clear understanding of the problem space
>and capabilities (which are already automated, can be
>automated, or need to be commanded) is important.
>
>Greg B.
>
>--- Adrian Farrel <[e-mail]> wrote:
>--- Lots of snips
>I would suggest that Greg and Diego start an I-D. Call
>it something like "Applicability Statement for
>Operating LCAS and VCAT with GMPLS LSPs".
>Include:
>- Simple overview of VCAT and LCAS (no more than a
>page, please)
>- Simple statement of how LSPs fit into the picture
>(about half a page)
>- Statement of the requirements on GMPLS signaling
>(about a page)
>- Mechanisms and procedures (two or three pages)
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>
>
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Thu, 16 Jun 2005 10:45:01 +0000
To: Greg Bernstein <[e-mail]>
Cc: ccamp <[e-mail]>
Subject: Re: LCAS and GMPLS
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 16 Jun 2005 12:43:15 +0200
Content-Type: text/plain; charset="US-ASCII"

Greg, 

> E.g., what about renumbering?
The renumbering is a LCAS element (fully LCAS controlled), that NMS or 
GMPLS should not be bothered about.
Only if you want to operate VCAT with LCAS disabled, NMS/ASON/GMPLS has to 
control the sequence numbers, but changes in the group size is not hitless 
without LCAS.

Hereafter some information on the VCAT/LCAS associated parameters as 
extracted from G.806 (02/04) and G.783 (02/04).

10.1/G.806 includes a generic specification for the VCAT/LCAS functions, 
inlcuding a list of MI signals (MI: Management Information) which 
management needs to control and gets reported. G.783 and G.798 specify the 
technology specific functions, using the specifications in G.806 as basis.

Input MI signals:
=================
P-Xv/P-X-L_A_So_MI_LCASEnable:
The MI_LCASEnable input controls whether the LCAS functionality is enabled 
for the source function (MI_LCASEnable = true) or disabled (MI_LCASEnable 
= false).

P-Xv/P-X-L_A_So_MI_ProvM[1..XMT]:
The MI_ProvM[1..XMT] input controls whether a P[i]_AP at the P-Xv_AP is 
provisioned to be a member of the VCG (MI_ProvM[i] = 1) or not 
(MI_ProvM[i] = 0). 

==> With this input parameter NMS/GNPLS controls which access points (and 
thus VC-n trail termination functions) are part of the VCAT group. Note - 
LCAS determines if there will be traffic routed over it.

P-Xv/P-X-L_A_So_MI_PLCTThr:
Partial loss of capacity transmit threshold associated with cPLCT fault 
cause.

----------

P-Xv/P-X-L_A_Sk_MI_LCASEnable:
The MI_LCASEnable input controls whether the LCAS functionality is enabled 
for the sink function (MI_LCASEnable = true) or disabled (MI_LCASEnable = 
false). If LCAS is enabled, the function auto-detects which type of source 
it is interfacing to. The output MI_LCAS_So_Detected reports whether the 
present sink function detected an LCAS-enabled source function 
(MI_LCAS_So_Detected=true) or a non-LCAS-enabled source 
(MI_LCAS_So_Detected=false, see below for details). Only if both 
MI_LCASEnable and MI_LCAS_So_Detected are true is the LCAS functionality 
active in the function.

P-Xv/P-X-L_A_Sk_MI_ProvM[1..XMR]:
The MI_ProvM[1..XMR] input controls whether a particular one of the 
available physical resources at the P-Xv_AP is provisioned to be a member 
of the VCG (MI_ProvM[i] = 1) or not (MI_ProvM[i] = 0). 

==> With this input parameter NMS/GMPLS controls which access points (and 
thus VC-n trail termination functions) are part of the VCAT group. Note - 
LCAS determines if there will be traffic routed over it.

P-Xv/P-X-L_A_Sk_MI_PLCRThr:
Partial loss of capacity receive threshold associated with cPLCR fault 
cause.

P-Xv/P-X-L_A_Sk_MI_TSDEnable:
The MI_TSDEnable input controls whether the sink function uses AI_TSD[i] 
indications as contributors for signalling defective members back to the 
LCAS source function (MI_TSDEnable = true) or whether it ignores AI_TSD[i] 
indications altogether (MI_TSDEnable = false).

P-Xv/P-X-L_A_Sk_MI_HOTime:
The MI_HOTime input controls whether the Hold-Off (HO) timer is enabled or 
disabled for the sink function and, if enabled, what the value of the 
timer is. If MI_HOTime = 0, the HO timer shall be disabled, if MI_HOTime 0 
it shall be enabled. 

P-Xv/P-X-L_A_Sk_MI_WTRTime:
The MI_WTRTime input controls whether the Wait-To-Restore (WTR) timer is 
enabled or disabled for the sink function and, if enabled, what the value 
of the timer is. If MI_WTRTime = 0, the WTR timer shall be disabled, if 
MI_WTRTime 0 it shall be enabled. 
The range of values for the HO/WTR timers is as defined in ITU-T Rec. 
G.808.1.

P-X-L_TT_Sk_MI_SSF_Reported:
Controls if cSSF fault cause is reported. Typically owned by NMS.


Output MI signals:
==================
P-Xv/P-X-L_A_So_MI_XAT:
Current size of the transmitted payload. 

P-Xv/P-X-L_A_So_MI_XMT
Maximum size of the transmitted payload.

P-Xv/P-X-L_A_So_MI_TxSQ[1..XMT]
Indication of which sequence number (_SQmap[i]) is being carried over a 
particular P_AI (P_AI[i]) signal. 

P-Xv/P-X-L_A_Sk_MI_XMR
Maximum size of the received payload.

P-Xv/P-X-L_A_Sk_MI_XAR
Current size of the received payload

P-Xv/P-X-L_A_Sk_MI_DMFI[1..XMR]
The relative delay, in MFI units, between each provisioned member and the 
earliest-arriving member among those considered for the calculation

P-Xv/P-X-L_A_Sk_MI_LCAS_So_Detected
Indication if remote node supports LCAS.

P-Xv/P-X-L_A_Sk_MI_AcSQ[1..XMR]
Indication of which sequence number is being received over a particular 
P_AI (P_AI[i]) signal. 


Besides these VCAT/LCAS specific parameters, you need to control a subset 
of the individual trail termination (e.g. S4_TT) function and the client 
adaptation (e.g. S4-X/ETH_A) function parameters. E.g. for VC-4 and VC-3 
TT_Sk functions:

Input MI parameters:
====================
Sn_TT_Sk_MI_TPmode
Termination Point mode to control alarm free path set up. Refer to 
6.1/G.806 and 7.1.4/G.7710.

Sn_TT_Sk_MI_ExTI
Expected Trace Identifier value must be configured by GMPLS when GMPLS 
sets up VC-n network connection; action is to read MI_TxTI parameter in 
TT_So and carry this value to remote end to configure MI_ExTI.

Sn_TT_Sk_MI_TIMdis
Disables/Enables TIM defect detection. GMPLS should control this as part 
of VC-n connection setup.

Sn_TT_Sk_MI_TIMAISdis
Disables/enables AIS insertion on TIM defect detection. GMPLS to control 
this as part of VC-n connection setup.

Sn_TT_Sk_MI_RDI_Reported
Sn_TT_Sk_MI_SSF_Reported
Controls if cRDI and cSSF fault cause are reported. Typically owned by 
NMS.

Sn_TT_Sk_MI_DEGTHR
Sn_TT_Sk_MI_DEGM
Sn_TT_Sk_MI_EXC_X
Sn_TT_Sk_MI_DEG_X
Bit error defect detection process configuration parameters. Must be 
configured as part of connection setup; values depend on SLA.


Output MI parameters:
=====================
Sn_TT_Sk_MI_AcTI
Accepted Trace Identifier value report.

Parameters for one of the client adaptation functions (e.g. Sn/ETH_A, 
G.8021) are typically outside the control of the GMPLS VC-n Group 
connection setup; those parameters are under either NMS or client layer 
GMPLS control.


I hope the above helps to get a feeling of what you need to control during 
VC-n Group connection set up.
Note that the VCAT group can be set up as a single VC-n Group, or as 
multiple, diverse routed, (smaller) VC-n (sub)Groups. E.g. a 5 VC-4 VCAT 
group may be set up as a 5 VC-4 network connection group, as a 3 VC-4 
netowrk connection group (VCG A) and a 2 VC-4 network connection group 
(VCG B), as five individual VC-4 network connections, ... The most common 
case when used to transport data will most likely be the second case: two 
VCGs supporting one VCAT/LCAS group. I assume that NMS and GMPLS VC-n 
connection management would set up VCG A and a VCG B, with the requirement 
that both must be diverse routed.

If the VCAT group at a later stage is to be extended to 6 VC-4 members, 
then for the case of VCG A and VCG B, the VCG B could be extended from 2 
to 3 VC-4 network connections. You would then issue a connection 
modification request for VCG B and leave VCG A untouched.

Regards,
Maarten 








Greg Bernstein <[e-mail]>
Sent by: [e-mail]
15-06-2005 18:04
 
        To:     Adrian Farrel <[e-mail]>, Diego Caviglia 
<[e-mail]>
        cc:     yhwkim <[e-mail]>, ccamp <[e-mail]>
        Subject:        Re: LCAS and GMPLS


Okay Adrian I'll take a first stab at the I-D based on
the e-mails to date and some of my tutorial material
from short courses and papers. 

Thanks everyone for the info and particularly Maarten
for the in depth descriptions and information.  I may
send you some extra questions after I digest it.  I'm
particularly interested in places where we "enable
LCAS" or some entity tells LCAS to perform an "add" or
"delete" action. E.g., what about renumbering? 

Sounds like there are plenty of possible solutions, so
a focus on a clear understanding of the problem space
and capabilities (which are already automated, can be
automated, or need to be commanded) is important.

Greg B.

--- Adrian Farrel <[e-mail]> wrote:
--- Lots of snips
I would suggest that Greg and Diego start an I-D. Call
it something like "Applicability Statement for
Operating LCAS and VCAT with GMPLS LSPs".
Include:
- Simple overview of VCAT and LCAS (no more than a
page, please)
- Simple statement of how LSPs fit into the picture
(about half a page)
- Statement of the requirements on GMPLS signaling
(about a page)
- Mechanisms and procedures (two or three pages)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 






Envelope-to: [e-mail]
Delivery-date: Thu, 16 Jun 2005 08:28:30 +0000
To: "Stephen Shew" <[e-mail]>
Cc: ccamp <[e-mail]>, [e-mail]
Subject: RE: LCAS and GMPLS
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 16 Jun 2005 10:25:26 +0200
Content-Type: text/plain; charset="US-ASCII"

Stephen,

A VCAT group is defined to contain only a single type of VC-n signals; 
e.g. all VC-n signals in the group are VC-4 (STS-3c), or all signals in 
the group or VC-3 (STS-1), or all signals in the group are VC-12 (VT-2) or 
all signals in the group are VC-11 (VT-1.5). 
A mixture of two or more VC-n types within one VCAT group is not defined. 
Note that a VC-3-3v (STS-1-3v) is not the same as a VC-4 (STS-3c). 
And a VC-4 (STS-3c) can not be carried over a VC-3-3v (STS-1-3v).

So the bearer plane doesn't support a VCAT group including one VC-4 
(STS-3c) and 3 VC-3s (STS-1s), and the contorl plane (ASON/GMPLS) doesn't 
need to take such undefined combinations into consideration.

Regards,
Maarten







"Stephen Shew" <[e-mail]>
Sent by: [e-mail]
15-06-2005 19:16
 
        To:     ccamp <[e-mail]>
        cc: 
        Subject:        RE: LCAS and GMPLS




> -----Original Message----- 
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Wednesday, June 15, 2005 08:22 
> To: Shew, Stephen [CAR:QT30:EXCH]; ccamp 
> Subject: Re: LCAS and GMPLS 
> 
> 
> Thanks Stephen, 
> 
> Helpful input. 
> 
> So if I read you right, GMPLS does not need to be aware of or 
> help with LCAS signaling. 
Correct.  What I mean precisely is that a GMPLS signaling application 
(something that knows to initiate/remove LSPs) would have understanding of 
LCAS and can trigger it.  However, GMPLS signaling is not the means to 
carry LCAS signaling.
> This means that we do not need to worry about mechanisms for 
> removing an LSP without disrupting the service, because LCAS 
> will be used to negotiate the correct behavior at the end 
> points before the LSP teardown is triggered. 
Correct. 
> We still have the question about deciding whether LCAS is in 
> use at all. But I assume that there are already mechanisms 
> for handling this in the absence of GMPLS signaling (for 
> example, in manually provisioned 
> connections) so that extensions to GMPLS are also not required. 
Yes.  Knowledge of whether LCAS capability is present or not only has to 
be known by something at the endpoint of an LSP.  There may be need to 
exchange LCAS endpoint capability via GMPLS signaling but that is arguably 
an application level exchange.  I'm not presuming that GMPLS signaling has 
to carry application level information.
> I *think* this means that the LCAS/VCAT requirements on GMPLS 
> collapse to a way of identifying that a set of LSPs apply to 
> a single VCAT group. 
I think so too.  As with LCAS knowledge, there may be other application 
level information that needs to be exchanged for VCAT, but again I'm not 
presuming that GMPLS signaling has to carry this.
> As you point out, grouping of LSPs are 
> needed for a variety of reasons when providing a service. 
> Nothing special about VCAT here as far as I can tell (but it 
> would be good to confirm that). 
I think VCAT is special in that it involves an adaptation (actually two if 
you include GFP), which requires constituent LSPs to all be at the same 
layer. Other services that use multiple LSPs (e.g., 1:1 restoration) don't 
have an adaptation that is applied to the collective group of LSPs.
> All that remains is to pick a way of associating the LSPs. 
> Will Session do, or do we need to use the Association object? 
I'm not sure if the requirements are complete enough for me to have an 
opinion on the mechanism.  A key point to decide is whether it needs to be 
known at a transit node that an LSP is part of an application that uses 
more than one LSP.  If so, then we'd want this information to survive 
crossing domains and cases where LSPs are concatentated/stitched.
Another requirement to consider is whether the associating the LSPs needs 
to be recursive.  For example, consider an STS-3c-2v where one of the 
STS-3c is a real contiguously concatenated LSP, and the other is actually 
an STS-1-3v (three STS-1 LSPs).  From a bearer plane point of view, this 
is possible.  Does the service maintain the two STS-3c LSP association and 
the three STS-1 LSP association?
I suggest that there be a requirement for recursive association. 
Stephen 




Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 22:34:58 +0000
Message-ID: <10c001c571fa$9f7dc670$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>, "Wataru Imajuku" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Wed, 15 Jun 2005 23:32:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

Hi Wataru,

> > > Another requirement to consider is whether the associating the LSPs
> > > needs to be recursive.  For example, consider an STS-3c-2v where one
of
> > > the STS-3c is a real contiguously >
> > > concatenated LSP, and the other is actually an STS-1-3v (three STS-1
> > > LSPs).  From a bearer plane point of view, this is possible.  Does
the
> > > service maintain the two STS-3c LSP > association and the three
STS-1 LSP
> > > association?
> > > I suggest that there be a requirement for recursive association.
> >
> >IB>> This is an interesting requirement. Fortunately, it is possible to
> >realize this requirement via GMPLS signaling by including several
> >ASSOCIATION objects of the same type into the same Path message. For
> >instance, one of them will indicate that the signalled LSP belongs to
the
> >nested VCAT group, while another -to the nesting VCAT group.
>
> Current ASSOCIATION objects relates only two connections.

Can you say why you think this is so?
Looking at draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt I do not
see anything that forces this limitation. In fact, it would be hard to
offer 1:n protection with such a scheme.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 21:20:47 +0000
Message-Id: <[e-mail]>
Date: Thu, 16 Jun 2005 06:18:22 +0900
To: "Igor Bryskin" <[e-mail]>, "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: LCAS and GMPLS
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Stephen

>Stephen,
>
>
> > Another requirement to consider is whether the associating the LSPs 
> needs to be recursive.  For example, consider an STS-3c-2v where one of 
> the STS-3c is a real contiguously >
> >  concatenated LSP, and the other is actually an STS-1-3v (three STS-1 
> LSPs).  From a bearer plane point of view, this is possible.  Does the 
> service maintain the two STS-3c LSP > association and the three STS-1 LSP 
> association?
> > I suggest that there be a requirement for recursive association.
>
>IB>> This is an interesting requirement. Fortunately, it is possible to 
>realize this requirement via GMPLS signaling by including several 
>ASSOCIATION objects of the same type into the same Path message. For 
>instance, one of them will indicate that the signalled LSP belongs to the 
>nested VCAT group, while another -to the nesting VCAT group.

  Current ASSOCIATION objects relates only two connections.
  I think that introducing the concept of virtual connection indicating 
the group of VCAT is good idea.
  Use of Call ID object $B!J(Bassigning VCAT Group) and Assosiation object
(indicating VCAT group in Call ID) may be one of solution.

Best Regards,
Wataru

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




Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 20:35:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C571E9.A017FAA3"
Subject: RE: LCAS and GMPLS
Date: Wed, 15 Jun 2005 15:34:26 -0500
Message-ID: <[e-mail]>
Thread-Topic: LCAS and GMPLS
Thread-Index: AcVxzk+WyyVZ/AwQSca2j3TeGBDJywACSA7g
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>

This is a multi-part message in MIME format.

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

Couple of comments:
- while the requirement for recursive association may/may not be
interesting, from a VCAT point of view it is not needed (by ITU
standards). All members of the VCAT group are defined as of one type
"X".
- VCAT and LCAS have been defined specifically so as not to require
transit node "awareness" or operational impacts.
- LCAS, itself, provides a mechanism for interworking LCAS-nonLCAS. And
it will depend on the service if LCAS is appropriate. VCAT does not
require LCAS.
- VCAT and LCAS can be used asymmetrically, VCAT can be unidirectional,
though LCAS does require one "return" member.
=20
Suggest first scoping to data plane requirements/terminology to avoid
confusion with control plane requirements and also to allow liaisoning
with ITU early in the development.=20
=20
Deborah
=20
=20
=20
=20

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Shew
Sent: Wednesday, June 15, 2005 1:17 PM
To: ccamp
Subject: RE: LCAS and GMPLS





> -----Original Message-----=20
> From: Adrian Farrel [mailto:[e-mail]]=20
> Sent: Wednesday, June 15, 2005 08:22=20
> To: Shew, Stephen [CAR:QT30:EXCH]; ccamp=20
> Subject: Re: LCAS and GMPLS=20
>=20
>=20
> Thanks Stephen,=20
>=20
> Helpful input.=20
>=20
> So if I read you right, GMPLS does not need to be aware of or=20
> help with LCAS signaling.=20

Correct.  What I mean precisely is that a GMPLS signaling application
(something that knows to initiate/remove LSPs) would have understanding
of LCAS and can trigger it.  However, GMPLS signaling is not the means
to carry LCAS signaling.

> This means that we do not need to worry about mechanisms for=20
> removing an LSP without disrupting the service, because LCAS=20
> will be used to negotiate the correct behavior at the end=20
> points before the LSP teardown is triggered.=20

Correct.=20

> We still have the question about deciding whether LCAS is in=20
> use at all. But I assume that there are already mechanisms=20
> for handling this in the absence of GMPLS signaling (for=20
> example, in manually provisioned=20
> connections) so that extensions to GMPLS are also not required.=20

Yes.  Knowledge of whether LCAS capability is present or not only has to
be known by something at the endpoint of an LSP.  There may be need to
exchange LCAS endpoint capability via GMPLS signaling but that is
arguably an application level exchange.  I'm not presuming that GMPLS
signaling has to carry application level information.

> I *think* this means that the LCAS/VCAT requirements on GMPLS=20
> collapse to a way of identifying that a set of LSPs apply to=20
> a single VCAT group.=20

I think so too.  As with LCAS knowledge, there may be other application
level information that needs to be exchanged for VCAT, but again I'm not
presuming that GMPLS signaling has to carry this.

> As you point out, grouping of LSPs are=20
> needed for a variety of reasons when providing a service.=20
> Nothing special about VCAT here as far as I can tell (but it=20
> would be good to confirm that).=20

I think VCAT is special in that it involves an adaptation (actually two
if you include GFP), which requires constituent LSPs to all be at the
same layer. Other services that use multiple LSPs (e.g., 1:1
restoration) don't have an adaptation that is applied to the collective
group of LSPs.

> All that remains is to pick a way of associating the LSPs.=20
> Will Session do, or do we need to use the Association object?=20

I'm not sure if the requirements are complete enough for me to have an
opinion on the mechanism.  A key point to decide is whether it needs to
be known at a transit node that an LSP is part of an application that
uses more than one LSP.  If so, then we'd want this information to
survive crossing domains and cases where LSPs are
concatentated/stitched.

Another requirement to consider is whether the associating the LSPs
needs to be recursive.  For example, consider an STS-3c-2v where one of
the STS-3c is a real contiguously concatenated LSP, and the other is
actually an STS-1-3v (three STS-1 LSPs).  From a bearer plane point of
view, this is possible.  Does the service maintain the two STS-3c LSP
association and the three STS-1 LSP association?

I suggest that there be a requirement for recursive association.=20

Stephen=20


------_=_NextPart_001_01C571E9.A017FAA3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: LCAS and GMPLS</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2627" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Couple of comments:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- while the requirement for recursive =
association may/may=20
not be interesting, from a VCAT point of view it is not&nbsp;needed (by =
ITU=20
standards). All members of the VCAT group are defined as of one type=20
"X".</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- VCAT and LCAS have been defined specifically =
so&nbsp;as=20
not to&nbsp;require transit node "awareness" or operational=20
impacts.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- LCAS, itself, provides a mechanism for =
interworking=20
LCAS-nonLCAS. And it will depend on the service if LCAS is appropriate. =
VCAT=20
does not require LCAS.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- VCAT and LCAS can be used asymmetrically, =
VCAT can be=20
unidirectional, though LCAS does require one "return"=20
member.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Suggest first scoping to data plane=20
requirements/terminology to avoid confusion with control plane=20
requirements&nbsp;and&nbsp;also to allow liaisoning with ITU early in =
the=20
development. </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D761152418-15062005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Stephen=20
Shew<BR><B>Sent:</B> Wednesday, June 15, 2005 1:17 PM<BR><B>To:</B>=20
ccamp<BR><B>Subject:</B> RE: LCAS and GMPLS<BR></FONT><BR></DIV>
<DIV></DIV><BR><BR>
<P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
From: Adrian Farrel [<A=20
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]=20
</FONT><BR><FONT size=3D2>&gt; Sent: Wednesday, June 15, 2005 =
08:22</FONT>=20
<BR><FONT size=3D2>&gt; To: Shew, Stephen [CAR:QT30:EXCH]; ccamp</FONT> =
<BR><FONT=20
size=3D2>&gt; Subject: Re: LCAS and GMPLS</FONT> <BR><FONT size=3D2>&gt; =

</FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Thanks =
Stephen,</FONT>=20
<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Helpful =
input.</FONT>=20
<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; So if I read you =
right, GMPLS=20
does not need to be aware of or </FONT><BR><FONT size=3D2>&gt; help with =
LCAS=20
signaling.</FONT> </P>
<P><FONT size=3D2>Correct.&nbsp; What I mean precisely is that a GMPLS =
signaling=20
application (something that knows to initiate/remove LSPs) would have=20
understanding of LCAS and can trigger it.&nbsp; However, GMPLS signaling =
is not=20
the means to carry LCAS signaling.</FONT></P>
<P><FONT size=3D2>&gt; This means that we do not need to worry about =
mechanisms=20
for </FONT><BR><FONT size=3D2>&gt; removing an LSP without disrupting =
the service,=20
because LCAS </FONT><BR><FONT size=3D2>&gt; will be used to negotiate =
the correct=20
behavior at the end </FONT><BR><FONT size=3D2>&gt; points before the LSP =
teardown=20
is triggered.</FONT> </P>
<P><FONT size=3D2>Correct.</FONT> </P>
<P><FONT size=3D2>&gt; We still have the question about deciding whether =
LCAS is=20
in </FONT><BR><FONT size=3D2>&gt; use at all. But I assume that there =
are already=20
mechanisms </FONT><BR><FONT size=3D2>&gt; for handling this in the =
absence of=20
GMPLS signaling (for </FONT><BR><FONT size=3D2>&gt; example, in manually =

provisioned</FONT> <BR><FONT size=3D2>&gt; connections) so that =
extensions to=20
GMPLS are also not required.</FONT> </P>
<P><FONT size=3D2>Yes.&nbsp; Knowledge of whether LCAS capability is =
present or=20
not only has to be known by something at the endpoint of an LSP.&nbsp; =
There may=20
be need to exchange LCAS endpoint capability via GMPLS signaling but =
that is=20
arguably an application level exchange.&nbsp; I'm not presuming that =
GMPLS=20
signaling has to carry application level information.</FONT></P>
<P><FONT size=3D2>&gt; I *think* this means that the LCAS/VCAT =
requirements on=20
GMPLS </FONT><BR><FONT size=3D2>&gt; collapse to a way of identifying =
that a set=20
of LSPs apply to </FONT><BR><FONT size=3D2>&gt; a single VCAT group. =
</FONT></P>
<P><FONT size=3D2>I think so too.&nbsp; As with LCAS knowledge, there =
may be other=20
application level information that needs to be exchanged for VCAT, but =
again I'm=20
not presuming that GMPLS signaling has to carry this.</FONT></P>
<P><FONT size=3D2>&gt; As you point out, grouping of LSPs are =
</FONT><BR><FONT=20
size=3D2>&gt; needed for a variety of reasons when providing a service.=20
</FONT><BR><FONT size=3D2>&gt; Nothing special about VCAT here as far as =
I can=20
tell (but it </FONT><BR><FONT size=3D2>&gt; would be good to confirm =
that).</FONT>=20
</P>
<P><FONT size=3D2>I think VCAT is special in that it involves an =
adaptation=20
(actually two if you include GFP), which requires constituent LSPs to =
all be at=20
the same layer. Other services that use multiple LSPs (e.g., 1:1 =
restoration)=20
don't have an adaptation that is applied to the collective group of=20
LSPs.</FONT></P>
<P><FONT size=3D2>&gt; All that remains is to pick a way of associating =
the LSPs.=20
</FONT><BR><FONT size=3D2>&gt; Will Session do, or do we need to use the =

Association object?</FONT> </P>
<P><FONT size=3D2>I'm not sure if the requirements are complete enough =
for me to=20
have an opinion on the mechanism.&nbsp; A key point to decide is whether =
it=20
needs to be known at a transit node that an LSP is part of an =
application that=20
uses more than one LSP.&nbsp; If so, then we'd want this information to =
survive=20
crossing domains and cases where LSPs are =
concatentated/stitched.</FONT></P>
<P><FONT size=3D2>Another requirement to consider is whether the =
associating the=20
LSPs needs to be recursive.&nbsp; For example, consider an STS-3c-2v =
where one=20
of the STS-3c is a real contiguously concatenated LSP, and the other is =
actually=20
an STS-1-3v (three STS-1 LSPs).&nbsp; From a bearer plane point of view, =
this is=20
possible.&nbsp; Does the service maintain the two STS-3c LSP association =
and the=20
three STS-1 LSP association?</FONT></P>
<P><FONT size=3D2>I suggest that there be a requirement for recursive=20
association.</FONT> </P>
<P><FONT size=3D2>Stephen</FONT> </P></BODY></HTML>

------_=_NextPart_001_01C571E9.A017FAA3--



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 17:37:24 +0000
Message-ID: <017501c571d0$d9ea14a0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Wed, 15 Jun 2005 13:37:07 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0172_01C571AF.52B227F0"

This is a multi-part message in MIME format.

------=_NextPart_000_0172_01C571AF.52B227F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: LCAS and GMPLSStephen,


> Another requirement to consider is whether the associating the LSPs =
needs to be recursive.  For example, consider an STS-3c-2v where one of =
the STS-3c is a real contiguously >
>  concatenated LSP, and the other is actually an STS-1-3v (three STS-1 =
LSPs).  From a bearer plane point of view, this is possible.  Does the =
service maintain the two STS-3c LSP > association and the three STS-1 =
LSP association?
  > I suggest that there be a requirement for recursive association.=20

  IB>> This is an interesting requirement. Fortunately, it is possible =
to realize this requirement via GMPLS signaling by including several =
ASSOCIATION objects of the same type into the same Path message. For =
instance, one of them will indicate that the signalled LSP belongs to =
the nested VCAT group, while another -to the nesting VCAT group.



  Cheers,

  Igor



  Stephen=20

------=_NextPart_000_0172_01C571AF.52B227F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: LCAS and GMPLS</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Stephen,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&gt; Another requirement to consider is whether the=20
associating the LSPs needs to be recursive.&nbsp; For example, consider =
an=20
STS-3c-2v where one of the STS-3c is a real contiguously =
&gt;</FONT></DIV>
<DIV><FONT size=3D2>&gt; &nbsp;concatenated LSP, and the other is =
actually an=20
STS-1-3v (three STS-1 LSPs).&nbsp; From a bearer plane point of view, =
this is=20
possible.&nbsp; Does the service maintain the two STS-3c LSP &gt; =
association=20
and the three STS-1 LSP association?</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>&gt; I suggest that there be a requirement for =
recursive=20
  association.</FONT> </P>
  <P><FONT size=3D2>IB&gt;&gt; This is an interesting requirement. =
Fortunately, it=20
  is possible to realize this requirement via GMPLS signaling by =
including=20
  several&nbsp;ASSOCIATION objects of the same type into the same Path =
message.=20
  For instance,&nbsp;one of them will indicate that the signalled LSP =
belongs=20
  to&nbsp;the nested VCAT group, while another -to the nesting VCAT=20
  group.</FONT></P>
  <P><FONT size=3D2></FONT>&nbsp;</P>
  <P><FONT size=3D2>Cheers,</FONT></P>
  <P><FONT size=3D2>Igor</FONT></P>
  <P><FONT size=3D2></FONT>&nbsp;</P>
  <P><FONT size=3D2>Stephen</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0172_01C571AF.52B227F0--




Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 17:18:37 +0000
Message-ID: <[e-mail]>
From: "Stephen Shew" <[e-mail]>
To: ccamp <[e-mail]>
Subject: RE: LCAS and GMPLS
Date: Wed, 15 Jun 2005 13:16:59 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C571CE.09AF769C"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C571CE.09AF769C
Content-Type: text/plain



> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Wednesday, June 15, 2005 08:22
> To: Shew, Stephen [CAR:QT30:EXCH]; ccamp
> Subject: Re: LCAS and GMPLS
> 
> 
> Thanks Stephen,
> 
> Helpful input.
> 
> So if I read you right, GMPLS does not need to be aware of or 
> help with LCAS signaling.

Correct.  What I mean precisely is that a GMPLS signaling application
(something that knows to initiate/remove LSPs) would have understanding of
LCAS and can trigger it.  However, GMPLS signaling is not the means to carry
LCAS signaling.

> This means that we do not need to worry about mechanisms for 
> removing an LSP without disrupting the service, because LCAS 
> will be used to negotiate the correct behavior at the end 
> points before the LSP teardown is triggered.

Correct.

> We still have the question about deciding whether LCAS is in 
> use at all. But I assume that there are already mechanisms 
> for handling this in the absence of GMPLS signaling (for 
> example, in manually provisioned
> connections) so that extensions to GMPLS are also not required.

Yes.  Knowledge of whether LCAS capability is present or not only has to be
known by something at the endpoint of an LSP.  There may be need to exchange
LCAS endpoint capability via GMPLS signaling but that is arguably an
application level exchange.  I'm not presuming that GMPLS signaling has to
carry application level information.

> I *think* this means that the LCAS/VCAT requirements on GMPLS 
> collapse to a way of identifying that a set of LSPs apply to 
> a single VCAT group. 

I think so too.  As with LCAS knowledge, there may be other application
level information that needs to be exchanged for VCAT, but again I'm not
presuming that GMPLS signaling has to carry this.

> As you point out, grouping of LSPs are 
> needed for a variety of reasons when providing a service. 
> Nothing special about VCAT here as far as I can tell (but it 
> would be good to confirm that).

I think VCAT is special in that it involves an adaptation (actually two if
you include GFP), which requires constituent LSPs to all be at the same
layer. Other services that use multiple LSPs (e.g., 1:1 restoration) don't
have an adaptation that is applied to the collective group of LSPs.

> All that remains is to pick a way of associating the LSPs. 
> Will Session do, or do we need to use the Association object?

I'm not sure if the requirements are complete enough for me to have an
opinion on the mechanism.  A key point to decide is whether it needs to be
known at a transit node that an LSP is part of an application that uses more
than one LSP.  If so, then we'd want this information to survive crossing
domains and cases where LSPs are concatentated/stitched.

Another requirement to consider is whether the associating the LSPs needs to
be recursive.  For example, consider an STS-3c-2v where one of the STS-3c is
a real contiguously concatenated LSP, and the other is actually an STS-1-3v
(three STS-1 LSPs).  From a bearer plane point of view, this is possible.
Does the service maintain the two STS-3c LSP association and the three STS-1
LSP association?

I suggest that there be a requirement for recursive association.

Stephen


------_=_NextPart_001_01C571CE.09AF769C
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: LCAS and GMPLS</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Adrian Farrel [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, June 15, 2005 08:22</FONT>
<BR><FONT SIZE=3D2>&gt; To: Shew, Stephen [CAR:QT30:EXCH]; ccamp</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: LCAS and GMPLS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks Stephen,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Helpful input.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So if I read you right, GMPLS does not need to =
be aware of or </FONT>
<BR><FONT SIZE=3D2>&gt; help with LCAS signaling.</FONT>
</P>

<P><FONT SIZE=3D2>Correct.&nbsp; What I mean precisely is that a GMPLS =
signaling application (something that knows to initiate/remove LSPs) =
would have understanding of LCAS and can trigger it.&nbsp; However, =
GMPLS signaling is not the means to carry LCAS signaling.</FONT></P>

<P><FONT SIZE=3D2>&gt; This means that we do not need to worry about =
mechanisms for </FONT>
<BR><FONT SIZE=3D2>&gt; removing an LSP without disrupting the service, =
because LCAS </FONT>
<BR><FONT SIZE=3D2>&gt; will be used to negotiate the correct behavior =
at the end </FONT>
<BR><FONT SIZE=3D2>&gt; points before the LSP teardown is =
triggered.</FONT>
</P>

<P><FONT SIZE=3D2>Correct.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; We still have the question about deciding =
whether LCAS is in </FONT>
<BR><FONT SIZE=3D2>&gt; use at all. But I assume that there are already =
mechanisms </FONT>
<BR><FONT SIZE=3D2>&gt; for handling this in the absence of GMPLS =
signaling (for </FONT>
<BR><FONT SIZE=3D2>&gt; example, in manually provisioned</FONT>
<BR><FONT SIZE=3D2>&gt; connections) so that extensions to GMPLS are =
also not required.</FONT>
</P>

<P><FONT SIZE=3D2>Yes.&nbsp; Knowledge of whether LCAS capability is =
present or not only has to be known by something at the endpoint of an =
LSP.&nbsp; There may be need to exchange LCAS endpoint capability via =
GMPLS signaling but that is arguably an application level =
exchange.&nbsp; I'm not presuming that GMPLS signaling has to carry =
application level information.</FONT></P>

<P><FONT SIZE=3D2>&gt; I *think* this means that the LCAS/VCAT =
requirements on GMPLS </FONT>
<BR><FONT SIZE=3D2>&gt; collapse to a way of identifying that a set of =
LSPs apply to </FONT>
<BR><FONT SIZE=3D2>&gt; a single VCAT group. </FONT>
</P>

<P><FONT SIZE=3D2>I think so too.&nbsp; As with LCAS knowledge, there =
may be other application level information that needs to be exchanged =
for VCAT, but again I'm not presuming that GMPLS signaling has to carry =
this.</FONT></P>

<P><FONT SIZE=3D2>&gt; As you point out, grouping of LSPs are </FONT>
<BR><FONT SIZE=3D2>&gt; needed for a variety of reasons when providing =
a service. </FONT>
<BR><FONT SIZE=3D2>&gt; Nothing special about VCAT here as far as I can =
tell (but it </FONT>
<BR><FONT SIZE=3D2>&gt; would be good to confirm that).</FONT>
</P>

<P><FONT SIZE=3D2>I think VCAT is special in that it involves an =
adaptation (actually two if you include GFP), which requires =
constituent LSPs to all be at the same layer. Other services that use =
multiple LSPs (e.g., 1:1 restoration) don't have an adaptation that is =
applied to the collective group of LSPs.</FONT></P>

<P><FONT SIZE=3D2>&gt; All that remains is to pick a way of associating =
the LSPs. </FONT>
<BR><FONT SIZE=3D2>&gt; Will Session do, or do we need to use the =
Association object?</FONT>
</P>

<P><FONT SIZE=3D2>I'm not sure if the requirements are complete enough =
for me to have an opinion on the mechanism.&nbsp; A key point to decide =
is whether it needs to be known at a transit node that an LSP is part =
of an application that uses more than one LSP.&nbsp; If so, then we'd =
want this information to survive crossing domains and cases where LSPs =
are concatentated/stitched.</FONT></P>

<P><FONT SIZE=3D2>Another requirement to consider is whether the =
associating the LSPs needs to be recursive.&nbsp; For example, consider =
an STS-3c-2v where one of the STS-3c is a real contiguously =
concatenated LSP, and the other is actually an STS-1-3v (three STS-1 =
LSPs).&nbsp; From a bearer plane point of view, this is possible.&nbsp; =
Does the service maintain the two STS-3c LSP association and the three =
STS-1 LSP association?</FONT></P>

<P><FONT SIZE=3D2>I suggest that there be a requirement for recursive =
association.</FONT>
</P>

<P><FONT SIZE=3D2>Stephen</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C571CE.09AF769C--



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 16:07:25 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TORwFwkjLlZWQN/i6b+v3E+8BZV0Fl2T9vlYSOpkPP3GNTyFOxzCMj7ltKjdAIWHEJU5BCSqoGFZVmQx5m0Z4DR7aCixb8Izbf/q9+jKmxXWdrQNahp81JL3cCf9T59RwL/SbcAGAoeq0an15OQyzrCW0qd9g64iWTFXDr6RzQc=  ;
Message-ID: <[e-mail]>
Date: Wed, 15 Jun 2005 09:04:27 -0700 (PDT)
From: Greg Bernstein <[e-mail]>
Subject: Re: LCAS and GMPLS
To: Adrian Farrel <[e-mail]>, Diego Caviglia <[e-mail]>
Cc: yhwkim <[e-mail]>, ccamp <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Okay Adrian I'll take a first stab at the I-D based on
the e-mails to date and some of my tutorial material
from short courses and papers.  

Thanks everyone for the info and particularly Maarten
for the in depth descriptions and information.  I may
send you some extra questions after I digest it.  I'm
particularly interested in places where we "enable
LCAS" or some entity tells LCAS to perform an "add" or
"delete" action. E.g., what about renumbering? 

Sounds like there are plenty of possible solutions, so
a focus on a clear understanding of the problem space
and capabilities (which are already automated, can be
automated, or need to be commanded) is important.

Greg B.

--- Adrian Farrel <[e-mail]> wrote:
--- Lots of snips
I would suggest that Greg and Diego start an I-D. Call
it something like "Applicability Statement for
Operating LCAS and VCAT with GMPLS LSPs".
Include:
- Simple overview of VCAT and LCAS (no more than a
page, please)
- Simple statement of how LSPs fit into the picture
(about half a page)
- Statement of the requirements on GMPLS signaling
(about a page)
- Mechanisms and procedures (two or three pages)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 14:48:45 +0000
Message-ID: <012401c571b8$e74ea7e0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Wed, 15 Jun 2005 10:45:41 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I'd like to put my 50c into this discussion.

1. I don't think that just using the same Session object for all VCAT
component LSPs will work. Why ? If you signal them with the SE reservation
style they will share resources on common links and you don't want this to
happen. If you signal them with the FF reservation style you will not be
able to do make-before-break.

2. Association object seems to be a good solution. Today we have the
Association object of two types:

a) Protection: allows to associate protecting and protected LSPs;
b) Resource sharing: allows to associate groups of LSPs with different
Session IDs, so that one can perform make-before-break procedures for entire
group.

You can put any number of Association objects into the same Path message.

I think for the purpose of VCAT we need to introduce an Association object
of the third type (let's call it VCAT Association object): generally
speaking, it will allow associating LSPs with different Sessions IDs that
are used as a single unit from the user perspective. My understanding is
that this object will be useful only on the egress of all of the
LPS-components: ingress node knows the association anyway, transit nodes do
not care (am I right ?). All LSP-components will have distinct Session IDs,
will be signaled with SE reservation style and include this new (identical)
Association object. This would allow managing each component individually
(including individual make-before-break operations). It will be also
possible to perform "global" make-before-break for entire VCAT group. This
could be easily achieved by signaling in each of new components an
Association object of Resource sharing type (in addition to Association
object of VCAT type) which will be a copy of Association object of VCAT type
of the existing group.

I guess I've lost everybody by now :=)

Igor

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Stephen Shew" <[e-mail]>; "ccamp" <[e-mail]>
Sent: Wednesday, June 15, 2005 8:22 AM
Subject: Re: LCAS and GMPLS


> Thanks Stephen,
>
> Helpful input.
>
> So if I read you right, GMPLS does not need to be aware of or help with
> LCAS signaling.
>
> This means that we do not need to worry about mechanisms for removing an
> LSP without disrupting the service, because LCAS will be used to negotiate
> the correct behavior at the end points before the LSP teardown is
> triggered.
>
> We still have the question about deciding whether LCAS is in use at all.
> But I assume that there are already mechanisms for handling this in the
> absence of GMPLS signaling (for example, in manually provisioned
> connections) so that extensions to GMPLS are also not required.
>
> I *think* this means that the LCAS/VCAT requirements on GMPLS collapse to
> a way of identifying that a set of LSPs apply to a single VCAT group. As
> you point out, grouping of LSPs are needed for a variety of reasons when
> providing a service. Nothing special about VCAT here as far as I can tell
> (but it would be good to confirm that).
>
> All that remains is to pick a way of associating the LSPs. Will Session
> do, or do we need to use the Association object?
>
> Cheers,
> Adrian
>
>
> ----- Original Message ----- 
> From: "Stephen Shew" <[e-mail]>
> To: "ccamp" <[e-mail]>
> Sent: Tuesday, June 14, 2005 10:10 PM
> Subject: RE: LCAS and GMPLS
>
>
> > In considering the use of LCAS, it is important to note that there are
> > separate requirements here:
> > 1. Having multiple LSPs participate in a single service.   This is not
> just
> > limited to virtual concatenation but is also useful for 1:1 and other
> > restoration mechanisms.
> >
> > 2. If LSPs can be added/removed from a common service after they have
> been
> > set up.
> >
> > 3. What effects LSP addition/removal are allowed to have on the common
> > service.
> >
> > Putting these together, one could envision a requirement to offer a
> service
> > whose bandwidth requirements are met with a service in a transport
> network
> > that uses multiple LSPs for bandwidth efficiency.  Further this service
> > allows changes to be signalled and the bandwidth change is to be
> > non-disruptive.
> >
> > Mechanisms to accomplish such a service could consist of VCAT and LCAS.
> > Note that LCAS has its own "in-band" signalling.  I think that the
> service
> > associated with the VCAT adaptation is the one that should be LCAS
> aware,
> > not the individual LSPs.
> >
> > Stephen
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > > Sent: Tuesday, June 14, 2005 14:48
> > > To: Greg Bernstein <gregbern; Diego Caviglia
> > > Cc: yhwkim; ccamp
> > > Subject: Re: LCAS and GMPLS
> > >
> > <snip>
> >
> > > Nevertheless, before completing on the solutions discussion,
> > > we still have to sort out the issues above. I am most
> > > concerned about the "layering" issue. That is:
> > > a) Is the LCAS component on the egress started by management,
> > >    by a trigger in some communication between LCAS components,
> > >    or by a trigger in GMPLS signaling?
> > > b) Do the LCAS components converse through GMPLS signaling
> > >    or by other (existing?) means?
> > >
> > > > [dc] My initial idea was to use Call_ID to identify the LSP that are
> > > part of the
> > > > same VCAT/LCAS set and a bit in the profile filed to inform
> > > the other
> > > and
> > > > that LCAS protcol has bo enabled.
> > >
> > > Understood. I think we have moved on a little from that
> > > suggestion. Presumably you will not be unhappy with any
> > > solution that is functional and not over-complex.
> > >
> > > I would suggest that Greg and Diego start an I-D. Call it
> > > something like "Applicability Statement for Operating LCAS
> > > and VCAT with GMPLS LSPs".
> > > Include:
> > > - Simple overview of VCAT and LCAS (no more than a page, please)
> > > - Simple statement of how LSPs fit into the picture (about
> > > half a page)
> > > - Statement of the requirements on GMPLS signaling (about a page)
> > > - Mechanisms and procedures (two or three pages)
> > >
> > > It may be that we need to define a new bit somewhere in which
> > > case we will drop "Applicability Statement for" from the name
> > > of the I-D.
> > >
> > > I would be very happy to discuss the solutions component with
> > > you before publication so that we avoid thrashing.
> > >
> > >
> > > Anyone who is interested in this topic should contact Diego
> > > and Greg to offer help.
> >
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 12:44:13 +0000
MIME-Version: 1.0
Sensitivity: 
To: "Adrian Farrel" <[e-mail]>
Cc: ""Stephen Shew" <sdshew" <[e-mail]>, ""ccamp" <ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 15 Jun 2005 14:42:12 +0200
Content-Type: multipart/alternative; boundary="=_alternative 0045DFE2C1257021_="

This is a multipart message in MIME format.
--=_alternative 0045DFE2C1257021_=
Content-Type: text/plain; charset="us-ascii"

Adrian,
              some comments in line.

Regards

Diego


Please respond to "Adrian Farrel" <[e-mail]>
Sent by:        [e-mail]
To:     "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>
cc: 

Subject:        Re: LCAS and GMPLS

[CUT]
We still have the question about deciding whether LCAS is in use at all.
But I assume that there are already mechanisms for handling this in the
absence of GMPLS signaling (for example, in manually provisioned
connections) so that extensions to GMPLS are also not required.
[dc] This sound strange to be because almost everything of what you can do 
with GMPLS can be done via NMS. 
Circuit provisioning can be done via ENS so I'm sure I've got your point 
here.

I *think* this means that the LCAS/VCAT requirements on GMPLS collapse to
a way of identifying that a set of LSPs apply to a single VCAT group. As
you point out, grouping of LSPs are needed for a variety of reasons when
providing a service. Nothing special about VCAT here as far as I can tell
(but it would be good to confirm that).

All that remains is to pick a way of associating the LSPs. Will Session
do, or do we need to use the Association object?

Cheers,
Adrian


----- Original Message ----- 
From: "Stephen Shew" <[e-mail]>
To: "ccamp" <[e-mail]>
Sent: Tuesday, June 14, 2005 10:10 PM
Subject: RE: LCAS and GMPLS


> In considering the use of LCAS, it is important to note that there are
> separate requirements here:
> 1. Having multiple LSPs participate in a single service.   This is not
just
> limited to virtual concatenation but is also useful for 1:1 and other
> restoration mechanisms.
>
> 2. If LSPs can be added/removed from a common service after they have
been
> set up.
>
> 3. What effects LSP addition/removal are allowed to have on the common
> service.
>
> Putting these together, one could envision a requirement to offer a
service
> whose bandwidth requirements are met with a service in a transport
network
> that uses multiple LSPs for bandwidth efficiency.  Further this service
> allows changes to be signalled and the bandwidth change is to be
> non-disruptive.
>
> Mechanisms to accomplish such a service could consist of VCAT and LCAS.
> Note that LCAS has its own "in-band" signalling.  I think that the
service
> associated with the VCAT adaptation is the one that should be LCAS
aware,
> not the individual LSPs.
>
> Stephen
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > Sent: Tuesday, June 14, 2005 14:48
> > To: Greg Bernstein <gregbern; Diego Caviglia
> > Cc: yhwkim; ccamp
> > Subject: Re: LCAS and GMPLS
> >
> <snip>
>
> > Nevertheless, before completing on the solutions discussion,
> > we still have to sort out the issues above. I am most
> > concerned about the "layering" issue. That is:
> > a) Is the LCAS component on the egress started by management,
> >    by a trigger in some communication between LCAS components,
> >    or by a trigger in GMPLS signaling?
> > b) Do the LCAS components converse through GMPLS signaling
> >    or by other (existing?) means?
> >
> > > [dc] My initial idea was to use Call_ID to identify the LSP that are
> > part of the
> > > same VCAT/LCAS set and a bit in the profile filed to inform
> > the other
> > and
> > > that LCAS protcol has bo enabled.
> >
> > Understood. I think we have moved on a little from that
> > suggestion. Presumably you will not be unhappy with any
> > solution that is functional and not over-complex.
> >
> > I would suggest that Greg and Diego start an I-D. Call it
> > something like "Applicability Statement for Operating LCAS
> > and VCAT with GMPLS LSPs".
> > Include:
> > - Simple overview of VCAT and LCAS (no more than a page, please)
> > - Simple statement of how LSPs fit into the picture (about
> > half a page)
> > - Statement of the requirements on GMPLS signaling (about a page)
> > - Mechanisms and procedures (two or three pages)
> >
> > It may be that we need to define a new bit somewhere in which
> > case we will drop "Applicability Statement for" from the name
> > of the I-D.
> >
> > I would be very happy to discuss the solutions component with
> > you before publication so that we avoid thrashing.
> >
> >
> > Anyone who is interested in this topic should contact Diego
> > and Greg to offer help.
>





--=_alternative 0045DFE2C1257021_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 color=blue face="Times New Roman">Adrian,</font>
<br><font size=3 color=blue face="Times New Roman">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; some comments in line.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">Regards</font>
<br>
<br><font size=3 color=blue face="Times New Roman">Diego</font>
<br>
<br>
<p><font size=1 color=#800080 face="sans-serif">Please respond to &quot;Adrian Farrel&quot; &lt;[e-mail]&gt;</font>
<p><font size=1 color=#800080 face="sans-serif">Sent by: &nbsp; &nbsp; &nbsp; &nbsp;[e-mail]</font>
<p><font size=1 color=#800080 face="sans-serif">To: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">&quot;Stephen Shew&quot; &lt;[e-mail]&gt;, &quot;ccamp&quot; &lt;[e-mail]&gt;</font>
<br><font size=1 color=#800080 face="sans-serif">cc: &nbsp; &nbsp; &nbsp; &nbsp; </font>
<br>
<br><font size=1 color=#800080 face="sans-serif">Subject: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">Re: LCAS and GMPLS</font>
<br>
<br><font size=3 color=blue face="Times New Roman">[CUT]</font><font size=2 face="Courier New"><br>
We still have the question about deciding whether LCAS is in use at all.<br>
But I assume that there are already mechanisms for handling this in the<br>
absence of GMPLS signaling (for example, in manually provisioned<br>
connections) so that extensions to GMPLS are also not required.<br>
</font><font size=3 color=blue face="Times New Roman">[dc] This sound strange to be because almost everything of what you can do with GMPLS can be done via NMS. &nbsp;</font>
<br><font size=3 color=blue face="Times New Roman">Circuit provisioning can be done via ENS so I'm sure I've got your point here.</font>
<br><font size=2 face="Courier New"><br>
I *think* this means that the LCAS/VCAT requirements on GMPLS collapse to<br>
a way of identifying that a set of LSPs apply to a single VCAT group. As<br>
you point out, grouping of LSPs are needed for a variety of reasons when<br>
providing a service. Nothing special about VCAT here as far as I can tell<br>
(but it would be good to confirm that).<br>
<br>
All that remains is to pick a way of associating the LSPs. Will Session<br>
do, or do we need to use the Association object?<br>
<br>
Cheers,<br>
Adrian<br>
<br>
<br>
----- Original Message ----- <br>
From: &quot;Stephen Shew&quot; &lt;[e-mail]&gt;<br>
To: &quot;ccamp&quot; &lt;[e-mail]&gt;<br>
Sent: Tuesday, June 14, 2005 10:10 PM<br>
Subject: RE: LCAS and GMPLS<br>
<br>
<br>
&gt; In considering the use of LCAS, it is important to note that there are<br>
&gt; separate requirements here:<br>
&gt; 1. Having multiple LSPs participate in a single service. &nbsp; This is not<br>
just<br>
&gt; limited to virtual concatenation but is also useful for 1:1 and other<br>
&gt; restoration mechanisms.<br>
&gt;<br>
&gt; 2. If LSPs can be added/removed from a common service after they have<br>
been<br>
&gt; set up.<br>
&gt;<br>
&gt; 3. What effects LSP addition/removal are allowed to have on the common<br>
&gt; service.<br>
&gt;<br>
&gt; Putting these together, one could envision a requirement to offer a<br>
service<br>
&gt; whose bandwidth requirements are met with a service in a transport<br>
network<br>
&gt; that uses multiple LSPs for bandwidth efficiency. &nbsp;Further this service<br>
&gt; allows changes to be signalled and the bandwidth change is to be<br>
&gt; non-disruptive.<br>
&gt;<br>
&gt; Mechanisms to accomplish such a service could consist of VCAT and LCAS.<br>
&gt; Note that LCAS has its own &quot;in-band&quot; signalling. &nbsp;I think that the<br>
service<br>
&gt; associated with the VCAT adaptation is the one that should be LCAS<br>
aware,<br>
&gt; not the individual LSPs.<br>
&gt;<br>
&gt; Stephen<br>
&gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: [e-mail]<br>
&gt; &gt; [mailto:[e-mail]] On Behalf Of Adrian Farrel<br>
&gt; &gt; Sent: Tuesday, June 14, 2005 14:48<br>
&gt; &gt; To: Greg Bernstein &lt;gregbern; Diego Caviglia<br>
&gt; &gt; Cc: yhwkim; ccamp<br>
&gt; &gt; Subject: Re: LCAS and GMPLS<br>
&gt; &gt;<br>
&gt; &lt;snip&gt;<br>
&gt;<br>
&gt; &gt; Nevertheless, before completing on the solutions discussion,<br>
&gt; &gt; we still have to sort out the issues above. I am most<br>
&gt; &gt; concerned about the &quot;layering&quot; issue. That is:<br>
&gt; &gt; a) Is the LCAS component on the egress started by management,<br>
&gt; &gt; &nbsp; &nbsp;by a trigger in some communication between LCAS components,<br>
&gt; &gt; &nbsp; &nbsp;or by a trigger in GMPLS signaling?<br>
&gt; &gt; b) Do the LCAS components converse through GMPLS signaling<br>
&gt; &gt; &nbsp; &nbsp;or by other (existing?) means?<br>
&gt; &gt;<br>
&gt; &gt; &gt; [dc] My initial idea was to use Call_ID to identify the LSP that are<br>
&gt; &gt; part of the<br>
&gt; &gt; &gt; same VCAT/LCAS set and a bit in the profile filed to inform<br>
&gt; &gt; the other<br>
&gt; &gt; and<br>
&gt; &gt; &gt; that LCAS protcol has bo enabled.<br>
&gt; &gt;<br>
&gt; &gt; Understood. I think we have moved on a little from that<br>
&gt; &gt; suggestion. Presumably you will not be unhappy with any<br>
&gt; &gt; solution that is functional and not over-complex.<br>
&gt; &gt;<br>
&gt; &gt; I would suggest that Greg and Diego start an I-D. Call it<br>
&gt; &gt; something like &quot;Applicability Statement for Operating LCAS<br>
&gt; &gt; and VCAT with GMPLS LSPs&quot;.<br>
&gt; &gt; Include:<br>
&gt; &gt; - Simple overview of VCAT and LCAS (no more than a page, please)<br>
&gt; &gt; - Simple statement of how LSPs fit into the picture (about<br>
&gt; &gt; half a page)<br>
&gt; &gt; - Statement of the requirements on GMPLS signaling (about a page)<br>
&gt; &gt; - Mechanisms and procedures (two or three pages)<br>
&gt; &gt;<br>
&gt; &gt; It may be that we need to define a new bit somewhere in which<br>
&gt; &gt; case we will drop &quot;Applicability Statement for&quot; from the name<br>
&gt; &gt; of the I-D.<br>
&gt; &gt;<br>
&gt; &gt; I would be very happy to discuss the solutions component with</font>
<br><font size=2 face="Courier New">&gt; &gt; you before publication so that we avoid thrashing.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Anyone who is interested in this topic should contact Diego<br>
&gt; &gt; and Greg to offer help.<br>
&gt;<br>
<br>
<br>
</font>
<br>
<br>
--=_alternative 0045DFE2C1257021_=--



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 12:40:55 +0000
Message-ID: <0f3d01c571a7$c4d3d020$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Wed, 15 Jun 2005 13:42:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

Agreed.

A potential issue with the use of the Session object is that the
destination might be different. I don't know enough about VCAT to know if
this is possible. (Note, this is not simply a difference in incoming
interface/port on the egress node, but would be a difference in egress
node itself.)

This is why I would really like to get the requirements written down (in
an I-D) so that we can select a solution and move on.

Cheers,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: "Stephen Shew" <[e-mail]>; "ccamp" <[e-mail]>
Sent: Wednesday, June 15, 2005 1:33 PM
Subject: Re: LCAS and GMPLS


> adrian -
>
> independently of LCAS or not LCAS, the question of grouping VCs (that
can be diversely routed) and that belong to a given a VCG (VC group) is an
open point since now more than four years -
>
> from this the key question is indeed whether the Session object is
enough or not however the question should not be answered as "can it do
the job" because potentially it can (example among other using the
Extended Tunnel ID) but positioning this as follows is there 1)
requirement that would not be met and interference 2) implementation
and/or usage practices of the Session object sub-fields if such approach
would be used and 3) what would be required from this object in order to
deliver this functionality and evolution (it would be really harmful to
select that solution and mandate at some point in time modification of the
Session object processing to continue supporting functional needs)
>
> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 06/15/2005 13:22
> Please respond to "Adrian Farrel"
>
> To: "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>
> cc:
> bcc:
> Subject: Re: LCAS and GMPLS
>
>
>
>
> Thanks Stephen,
>
> Helpful input.
>
> So if I read you right, GMPLS does not need to be aware of or help with
> LCAS signaling.
>
> This means that we do not need to worry about mechanisms for removing an
> LSP without disrupting the service, because LCAS will be used to
negotiate
> the correct behavior at the end points before the LSP teardown is
> triggered.
>
> We still have the question about deciding whether LCAS is in use at all.
> But I assume that there are already mechanisms for handling this in the
> absence of GMPLS signaling (for example, in manually provisioned
> connections) so that extensions to GMPLS are also not required.
>
> I *think* this means that the LCAS/VCAT requirements on GMPLS collapse
to
> a way of identifying that a set of LSPs apply to a single VCAT group. As
> you point out, grouping of LSPs are needed for a variety of reasons when
> providing a service. Nothing special about VCAT here as far as I can
tell
> (but it would be good to confirm that).
>
> All that remains is to pick a way of associating the LSPs. Will Session
> do, or do we need to use the Association object?
>
> Cheers,
> Adrian
>
>
> ----- Original Message -----
> From: "Stephen Shew" <[e-mail]>
> To: "ccamp" <[e-mail]>
> Sent: Tuesday, June 14, 2005 10:10 PM
> Subject: RE: LCAS and GMPLS
>
>
> > In considering the use of LCAS, it is important to note that there are
> > separate requirements here:
> > 1. Having multiple LSPs participate in a single service.   This is not
> just
> > limited to virtual concatenation but is also useful for 1:1 and other
> > restoration mechanisms.
> >
> > 2. If LSPs can be added/removed from a common service after they have
> been
> > set up.
> >
> > 3. What effects LSP addition/removal are allowed to have on the common
> > service.
> >
> > Putting these together, one could envision a requirement to offer a
> service
> > whose bandwidth requirements are met with a service in a transport
> network
> > that uses multiple LSPs for bandwidth efficiency.  Further this
service
> > allows changes to be signalled and the bandwidth change is to be
> > non-disruptive.
> >
> > Mechanisms to accomplish such a service could consist of VCAT and
LCAS.
> > Note that LCAS has its own "in-band" signalling.  I think that the
> service
> > associated with the VCAT adaptation is the one that should be LCAS
> aware,
> > not the individual LSPs.
> >
> > Stephen
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > > Sent: Tuesday, June 14, 2005 14:48
> > > To: Greg Bernstein <gregbern; Diego Caviglia
> > > Cc: yhwkim; ccamp
> > > Subject: Re: LCAS and GMPLS
> > >
> > <snip>
> >
> > > Nevertheless, before completing on the solutions discussion,
> > > we still have to sort out the issues above. I am most
> > > concerned about the "layering" issue. That is:
> > > a) Is the LCAS component on the egress started by management,
> > >    by a trigger in some communication between LCAS components,
> > >    or by a trigger in GMPLS signaling?
> > > b) Do the LCAS components converse through GMPLS signaling
> > >    or by other (existing?) means?
> > >
> > > > [dc] My initial idea was to use Call_ID to identify the LSP that
are
> > > part of the
> > > > same VCAT/LCAS set and a bit in the profile filed to inform
> > > the other
> > > and
> > > > that LCAS protcol has bo enabled.
> > >
> > > Understood. I think we have moved on a little from that
> > > suggestion. Presumably you will not be unhappy with any
> > > solution that is functional and not over-complex.
> > >
> > > I would suggest that Greg and Diego start an I-D. Call it
> > > something like "Applicability Statement for Operating LCAS
> > > and VCAT with GMPLS LSPs".
> > > Include:
> > > - Simple overview of VCAT and LCAS (no more than a page, please)
> > > - Simple statement of how LSPs fit into the picture (about
> > > half a page)
> > > - Statement of the requirements on GMPLS signaling (about a page)
> > > - Mechanisms and procedures (two or three pages)
> > >
> > > It may be that we need to define a new bit somewhere in which
> > > case we will drop "Applicability Statement for" from the name
> > > of the I-D.
> > >
> > > I would be very happy to discuss the solutions component with
> > > you before publication so that we avoid thrashing.
> > >
> > >
> > > Anyone who is interested in this topic should contact Diego
> > > and Greg to offer help.
> >
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 12:35:24 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: LCAS and GMPLS
Date: Wed, 15 Jun 2005 14:33:13 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmFkcmlhbiAtIDwvRk9OVD48L1A+PFA+
PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmluZGVwZW5kZW50bHkgb2YgTENBUyBvciBu
b3QgTENBUywgdGhlIHF1ZXN0aW9uIG9mIGdyb3VwaW5nIFZDcyAodGhhdCBjYW4gYmUgZGl2ZXJz
ZWx5IHJvdXRlZCkgYW5kIHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gYSBWQ0cgKFZDIGdyb3VwKSBp
cyBhbiBvcGVuIHBvaW50IHNpbmNlIG5vdyBtb3JlIHRoYW4gZm91ciB5ZWFycyAtIDwvRk9OVD48
L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmZyb20gdGhpcyB0aGUga2V5IHF1
ZXN0aW9uIGlzIGluZGVlZCB3aGV0aGVyIHRoZSBTZXNzaW9uIG9iamVjdCBpcyBlbm91Z2ggb3Ig
bm90IGhvd2V2ZXIgdGhlIHF1ZXN0aW9uIHNob3VsZCBub3QgYmUgYW5zd2VyZWQgYXMgJnF1b3Q7
Y2FuIGl0IGRvIHRoZSBqb2ImcXVvdDsgYmVjYXVzZSBwb3RlbnRpYWxseSBpdCBjYW4gKGV4YW1w
bGUgYW1vbmcgb3RoZXIgdXNpbmcgdGhlIEV4dGVuZGVkIFR1bm5lbCBJRCkgYnV0IHBvc2l0aW9u
aW5nIHRoaXMgYXMgZm9sbG93cyBpcyB0aGVyZSAxKSByZXF1aXJlbWVudCB0aGF0IHdvdWxkIG5v
dCBiZSBtZXQgYW5kIGludGVyZmVyZW5jZSAyKSBpbXBsZW1lbnRhdGlvbiBhbmQvb3IgdXNhZ2Ug
cHJhY3RpY2VzIG9mIHRoZSBTZXNzaW9uIG9iamVjdCBzdWItZmllbGRzIGlmIHN1Y2ggYXBwcm9h
Y2ggd291bGQgYmUgdXNlZCBhbmQgMykgd2hhdCB3b3VsZCBiZSByZXF1aXJlZCBmcm9tIHRoaXMg
b2JqZWN0IGluIG9yZGVyIHRvIGRlbGl2ZXIgdGhpcyBmdW5jdGlvbmFsaXR5IGFuZCBldm9sdXRp
b24gKGl0IHdvdWxkIGJlIHJlYWxseSBoYXJtZnVsIHRvIHNlbGVjdCB0aGF0IHNvbHV0aW9uIGFu
ZCBtYW5kYXRlIGF0IHNvbWUgcG9pbnQgaW4gdGltZSBtb2RpZmljYXRpb24gb2YgdGhlIFNlc3Np
b24gb2JqZWN0IHByb2Nlc3NpbmcgdG8gY29udGludWUgc3VwcG9ydGluZyBmdW5jdGlvbmFsIG5l
ZWRzKTxCUj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj48Qj4mcXVvdDtBZHJpYW4gRmFycmVsJnF1
b3Q7ICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
Mj4wNi8xNS8yMDA1IDEzOjIyPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQg
dG8gJnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90OzwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+
VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+JnF1b3Q7U3RlcGhlbiBTaGV3JnF1b3Q7ICZsdDtzZHNo
ZXdAbm9ydGVsLmNvbSZndDssICZxdW90O2NjYW1wJnF1b3Q7ICZsdDtjY2FtcEBvcHMuaWV0Zi5v
cmcmZ3Q7PC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpF
PTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJ
WkU9Mj5SZTogTENBUyBhbmQgR01QTFM8L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48Rk9OVCBG
QUNFPSJNb25vc3BhY2UsQ291cmllciI+VGhhbmtzIFN0ZXBoZW4sPEJSPjwvRk9OVD48QlI+PEZP
TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkhlbHBmdWwgaW5wdXQuPEJSPjwvRk9OVD48QlI+
PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlNvIGlmIEkgcmVhZCB5b3UgcmlnaHQsIEdN
UExTIGRvZXMgbm90IG5lZWQgdG8gYmUgYXdhcmUgb2Ygb3IgaGVscCB3aXRoPEJSPkxDQVMgc2ln
bmFsaW5nLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UaGlz
IG1lYW5zIHRoYXQgd2UgZG8gbm90IG5lZWQgdG8gd29ycnkgYWJvdXQgbWVjaGFuaXNtcyBmb3Ig
cmVtb3ZpbmcgYW48QlI+TFNQIHdpdGhvdXQgZGlzcnVwdGluZyB0aGUgc2VydmljZSwgYmVjYXVz
ZSBMQ0FTIHdpbGwgYmUgdXNlZCB0byBuZWdvdGlhdGU8QlI+dGhlIGNvcnJlY3QgYmVoYXZpb3Ig
YXQgdGhlIGVuZCBwb2ludHMgYmVmb3JlIHRoZSBMU1AgdGVhcmRvd24gaXM8QlI+dHJpZ2dlcmVk
LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5XZSBzdGlsbCBo
YXZlIHRoZSBxdWVzdGlvbiBhYm91dCBkZWNpZGluZyB3aGV0aGVyIExDQVMgaXMgaW4gdXNlIGF0
IGFsbC48QlI+QnV0IEkgYXNzdW1lIHRoYXQgdGhlcmUgYXJlIGFscmVhZHkgbWVjaGFuaXNtcyBm
b3IgaGFuZGxpbmcgdGhpcyBpbiB0aGU8QlI+YWJzZW5jZSBvZiBHTVBMUyBzaWduYWxpbmcgKGZv
ciBleGFtcGxlLCBpbiBtYW51YWxseSBwcm92aXNpb25lZDxCUj5jb25uZWN0aW9ucykgc28gdGhh
dCBleHRlbnNpb25zIHRvIEdNUExTIGFyZSBhbHNvIG5vdCByZXF1aXJlZC48QlI+PC9GT05UPjxC
Uj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SSAqdGhpbmsqIHRoaXMgbWVhbnMgdGhh
dCB0aGUgTENBUy9WQ0FUIHJlcXVpcmVtZW50cyBvbiBHTVBMUyBjb2xsYXBzZSB0bzxCUj5hIHdh
eSBvZiBpZGVudGlmeWluZyB0aGF0IGEgc2V0IG9mIExTUHMgYXBwbHkgdG8gYSBzaW5nbGUgVkNB
VCBncm91cC4gQXM8QlI+eW91IHBvaW50IG91dCwgZ3JvdXBpbmcgb2YgTFNQcyBhcmUgbmVlZGVk
IGZvciBhIHZhcmlldHkgb2YgcmVhc29ucyB3aGVuPEJSPnByb3ZpZGluZyBhIHNlcnZpY2UuIE5v
dGhpbmcgc3BlY2lhbCBhYm91dCBWQ0FUIGhlcmUgYXMgZmFyIGFzIEkgY2FuIHRlbGw8QlI+KGJ1
dCBpdCB3b3VsZCBiZSBnb29kIHRvIGNvbmZpcm0gdGhhdCkuPEJSPjwvRk9OVD48QlI+PEZPTlQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkFsbCB0aGF0IHJlbWFpbnMgaXMgdG8gcGljayBhIHdh
eSBvZiBhc3NvY2lhdGluZyB0aGUgTFNQcy4gV2lsbCBTZXNzaW9uPEJSPmRvLCBvciBkbyB3ZSBu
ZWVkIHRvIHVzZSB0aGUgQXNzb2NpYXRpb24gb2JqZWN0PzxCUj48L0ZPTlQ+PEJSPjxGT05UIEZB
Q0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5DaGVlcnMsPEJSPkFkcmlhbjxCUj48L0ZPTlQ+PEJSPjxC
Uj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt
LS0tLTxCUj5Gcm9tOiAmcXVvdDtTdGVwaGVuIFNoZXcmcXVvdDsgJmx0O3Nkc2hld0Bub3J0ZWwu
Y29tJmd0OzxCUj5UbzogJnF1b3Q7Y2NhbXAmcXVvdDsgJmx0O2NjYW1wQG9wcy5pZXRmLm9yZyZn
dDs8QlI+U2VudDogVHVlc2RheSwgSnVuZSAxNCwgMjAwNSAxMDoxMCBQTTxCUj5TdWJqZWN0OiBS
RTogTENBUyBhbmQgR01QTFM8QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPiZndDsgSW4gY29uc2lkZXJpbmcgdGhlIHVzZSBvZiBMQ0FTLCBpdCBpcyBpbXBv
cnRhbnQgdG8gbm90ZSB0aGF0IHRoZXJlIGFyZTxCUj4mZ3Q7IHNlcGFyYXRlIHJlcXVpcmVtZW50
cyBoZXJlOjxCUj4mZ3Q7IDEuIEhhdmluZyBtdWx0aXBsZSBMU1BzIHBhcnRpY2lwYXRlIGluIGEg
c2luZ2xlIHNlcnZpY2UuICZuYnNwOyBUaGlzIGlzIG5vdDxCUj5qdXN0PEJSPiZndDsgbGltaXRl
ZCB0byB2aXJ0dWFsIGNvbmNhdGVuYXRpb24gYnV0IGlzIGFsc28gdXNlZnVsIGZvciAxOjEgYW5k
IG90aGVyPEJSPiZndDsgcmVzdG9yYXRpb24gbWVjaGFuaXNtcy48QlI+Jmd0OzxCUj4mZ3Q7IDIu
IElmIExTUHMgY2FuIGJlIGFkZGVkL3JlbW92ZWQgZnJvbSBhIGNvbW1vbiBzZXJ2aWNlIGFmdGVy
IHRoZXkgaGF2ZTxCUj5iZWVuPEJSPiZndDsgc2V0IHVwLjxCUj4mZ3Q7PEJSPiZndDsgMy4gV2hh
dCBlZmZlY3RzIExTUCBhZGRpdGlvbi9yZW1vdmFsIGFyZSBhbGxvd2VkIHRvIGhhdmUgb24gdGhl
IGNvbW1vbjxCUj4mZ3Q7IHNlcnZpY2UuPEJSPiZndDs8QlI+Jmd0OyBQdXR0aW5nIHRoZXNlIHRv
Z2V0aGVyLCBvbmUgY291bGQgZW52aXNpb24gYSByZXF1aXJlbWVudCB0byBvZmZlciBhPEJSPnNl
cnZpY2U8QlI+Jmd0OyB3aG9zZSBiYW5kd2lkdGggcmVxdWlyZW1lbnRzIGFyZSBtZXQgd2l0aCBh
IHNlcnZpY2UgaW4gYSB0cmFuc3BvcnQ8QlI+bmV0d29yazxCUj4mZ3Q7IHRoYXQgdXNlcyBtdWx0
aXBsZSBMU1BzIGZvciBiYW5kd2lkdGggZWZmaWNpZW5jeS4gJm5ic3A7RnVydGhlciB0aGlzIHNl
cnZpY2U8QlI+Jmd0OyBhbGxvd3MgY2hhbmdlcyB0byBiZSBzaWduYWxsZWQgYW5kIHRoZSBiYW5k
d2lkdGggY2hhbmdlIGlzIHRvIGJlPEJSPiZndDsgbm9uLWRpc3J1cHRpdmUuPEJSPiZndDs8QlI+
Jmd0OyBNZWNoYW5pc21zIHRvIGFjY29tcGxpc2ggc3VjaCBhIHNlcnZpY2UgY291bGQgY29uc2lz
dCBvZiBWQ0FUIGFuZCBMQ0FTLjxCUj4mZ3Q7IE5vdGUgdGhhdCBMQ0FTIGhhcyBpdHMgb3duICZx
dW90O2luLWJhbmQmcXVvdDsgc2lnbmFsbGluZy4gJm5ic3A7SSB0aGluayB0aGF0IHRoZTxCUj5z
ZXJ2aWNlPEJSPiZndDsgYXNzb2NpYXRlZCB3aXRoIHRoZSBWQ0FUIGFkYXB0YXRpb24gaXMgdGhl
IG9uZSB0aGF0IHNob3VsZCBiZSBMQ0FTPEJSPmF3YXJlLDxCUj4mZ3Q7IG5vdCB0aGUgaW5kaXZp
ZHVhbCBMU1BzLjxCUj4mZ3Q7PEJSPiZndDsgU3RlcGhlbjxCUj4mZ3Q7PEJSPiZndDsgJmd0OyAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgRnJvbTogb3duZXItY2NhbXBA
b3BzLmlldGYub3JnPEJSPiZndDsgJmd0OyBbbWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9y
Z10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWw8QlI+Jmd0OyAmZ3Q7IFNlbnQ6IFR1ZXNkYXks
IEp1bmUgMTQsIDIwMDUgMTQ6NDg8QlI+Jmd0OyAmZ3Q7IFRvOiBHcmVnIEJlcm5zdGVpbiAmbHQ7
Z3JlZ2Jlcm47IERpZWdvIENhdmlnbGlhPEJSPiZndDsgJmd0OyBDYzogeWh3a2ltOyBjY2FtcDxC
Uj4mZ3Q7ICZndDsgU3ViamVjdDogUmU6IExDQVMgYW5kIEdNUExTPEJSPiZndDsgJmd0OzxCUj4m
Z3Q7ICZsdDtzbmlwJmd0OzxCUj4mZ3Q7PEJSPiZndDsgJmd0OyBOZXZlcnRoZWxlc3MsIGJlZm9y
ZSBjb21wbGV0aW5nIG9uIHRoZSBzb2x1dGlvbnMgZGlzY3Vzc2lvbiw8QlI+Jmd0OyAmZ3Q7IHdl
IHN0aWxsIGhhdmUgdG8gc29ydCBvdXQgdGhlIGlzc3VlcyBhYm92ZS4gSSBhbSBtb3N0PEJSPiZn
dDsgJmd0OyBjb25jZXJuZWQgYWJvdXQgdGhlICZxdW90O2xheWVyaW5nJnF1b3Q7IGlzc3VlLiBU
aGF0IGlzOjxCUj4mZ3Q7ICZndDsgYSkgSXMgdGhlIExDQVMgY29tcG9uZW50IG9uIHRoZSBlZ3Jl
c3Mgc3RhcnRlZCBieSBtYW5hZ2VtZW50LDxCUj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2J5IGEg
dHJpZ2dlciBpbiBzb21lIGNvbW11bmljYXRpb24gYmV0d2VlbiBMQ0FTIGNvbXBvbmVudHMsPEJS
PiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7b3IgYnkgYSB0cmlnZ2VyIGluIEdNUExTIHNpZ25hbGlu
Zz88QlI+Jmd0OyAmZ3Q7IGIpIERvIHRoZSBMQ0FTIGNvbXBvbmVudHMgY29udmVyc2UgdGhyb3Vn
aCBHTVBMUyBzaWduYWxpbmc8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtvciBieSBvdGhlciAo
ZXhpc3Rpbmc/KSBtZWFucz88QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IFtkY10gTXkg
aW5pdGlhbCBpZGVhIHdhcyB0byB1c2UgQ2FsbF9JRCB0byBpZGVudGlmeSB0aGUgTFNQIHRoYXQg
YXJlPEJSPiZndDsgJmd0OyBwYXJ0IG9mIHRoZTxCUj4mZ3Q7ICZndDsgJmd0OyBzYW1lIFZDQVQv
TENBUyBzZXQgYW5kIGEgYml0IGluIHRoZSBwcm9maWxlIGZpbGVkIHRvIGluZm9ybTxCUj4mZ3Q7
ICZndDsgdGhlIG90aGVyPEJSPiZndDsgJmd0OyBhbmQ8QlI+Jmd0OyAmZ3Q7ICZndDsgdGhhdCBM
Q0FTIHByb3Rjb2wgaGFzIGJvIGVuYWJsZWQuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgVW5k
ZXJzdG9vZC4gSSB0aGluayB3ZSBoYXZlIG1vdmVkIG9uIGEgbGl0dGxlIGZyb20gdGhhdDxCUj4m
Z3Q7ICZndDsgc3VnZ2VzdGlvbi4gUHJlc3VtYWJseSB5b3Ugd2lsbCBub3QgYmUgdW5oYXBweSB3
aXRoIGFueTxCUj4mZ3Q7ICZndDsgc29sdXRpb24gdGhhdCBpcyBmdW5jdGlvbmFsIGFuZCBub3Qg
b3Zlci1jb21wbGV4LjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IEkgd291bGQgc3VnZ2VzdCB0
aGF0IEdyZWcgYW5kIERpZWdvIHN0YXJ0IGFuIEktRC4gQ2FsbCBpdDxCUj4mZ3Q7ICZndDsgc29t
ZXRoaW5nIGxpa2UgJnF1b3Q7QXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQgZm9yIE9wZXJhdGluZyBM
Q0FTPEJSPiZndDsgJmd0OyBhbmQgVkNBVCB3aXRoIEdNUExTIExTUHMmcXVvdDsuPEJSPiZndDsg
Jmd0OyBJbmNsdWRlOjxCUj4mZ3Q7ICZndDsgLSBTaW1wbGUgb3ZlcnZpZXcgb2YgVkNBVCBhbmQg
TENBUyAobm8gbW9yZSB0aGFuIGEgcGFnZSwgcGxlYXNlKTxCUj4mZ3Q7ICZndDsgLSBTaW1wbGUg
c3RhdGVtZW50IG9mIGhvdyBMU1BzIGZpdCBpbnRvIHRoZSBwaWN0dXJlIChhYm91dDxCUj4mZ3Q7
ICZndDsgaGFsZiBhIHBhZ2UpPEJSPiZndDsgJmd0OyAtIFN0YXRlbWVudCBvZiB0aGUgcmVxdWly
ZW1lbnRzIG9uIEdNUExTIHNpZ25hbGluZyAoYWJvdXQgYSBwYWdlKTxCUj4mZ3Q7ICZndDsgLSBN
ZWNoYW5pc21zIGFuZCBwcm9jZWR1cmVzICh0d28gb3IgdGhyZWUgcGFnZXMpPEJSPiZndDsgJmd0
OzxCUj4mZ3Q7ICZndDsgSXQgbWF5IGJlIHRoYXQgd2UgbmVlZCB0byBkZWZpbmUgYSBuZXcgYml0
IHNvbWV3aGVyZSBpbiB3aGljaDxCUj4mZ3Q7ICZndDsgY2FzZSB3ZSB3aWxsIGRyb3AgJnF1b3Q7
QXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQgZm9yJnF1b3Q7IGZyb20gdGhlIG5hbWU8QlI+Jmd0OyAm
Z3Q7IG9mIHRoZSBJLUQuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSSB3b3VsZCBiZSB2ZXJ5
IGhhcHB5IHRvIGRpc2N1c3MgdGhlIHNvbHV0aW9ucyBjb21wb25lbnQgd2l0aDxCUj4mZ3Q7ICZn
dDsgeW91IGJlZm9yZSBwdWJsaWNhdGlvbiBzbyB0aGF0IHdlIGF2b2lkIHRocmFzaGluZy48QlI+
Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgQW55b25lIHdobyBpcyBpbnRlcmVz
dGVkIGluIHRoaXMgdG9waWMgc2hvdWxkIGNvbnRhY3QgRGllZ288QlI+Jmd0OyAmZ3Q7IGFuZCBH
cmVnIHRvIG9mZmVyIGhlbHAuPEJSPiZndDs8QlI+PC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 12:20:31 +0000
Message-ID: <0ef401c571a4$e722cd00$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Stephen Shew" <[e-mail]>, "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Wed, 15 Jun 2005 13:22:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks Stephen,

Helpful input.

So if I read you right, GMPLS does not need to be aware of or help with
LCAS signaling.

This means that we do not need to worry about mechanisms for removing an
LSP without disrupting the service, because LCAS will be used to negotiate
the correct behavior at the end points before the LSP teardown is
triggered.

We still have the question about deciding whether LCAS is in use at all.
But I assume that there are already mechanisms for handling this in the
absence of GMPLS signaling (for example, in manually provisioned
connections) so that extensions to GMPLS are also not required.

I *think* this means that the LCAS/VCAT requirements on GMPLS collapse to
a way of identifying that a set of LSPs apply to a single VCAT group. As
you point out, grouping of LSPs are needed for a variety of reasons when
providing a service. Nothing special about VCAT here as far as I can tell
(but it would be good to confirm that).

All that remains is to pick a way of associating the LSPs. Will Session
do, or do we need to use the Association object?

Cheers,
Adrian


----- Original Message ----- 
From: "Stephen Shew" <[e-mail]>
To: "ccamp" <[e-mail]>
Sent: Tuesday, June 14, 2005 10:10 PM
Subject: RE: LCAS and GMPLS


> In considering the use of LCAS, it is important to note that there are
> separate requirements here:
> 1. Having multiple LSPs participate in a single service.   This is not
just
> limited to virtual concatenation but is also useful for 1:1 and other
> restoration mechanisms.
>
> 2. If LSPs can be added/removed from a common service after they have
been
> set up.
>
> 3. What effects LSP addition/removal are allowed to have on the common
> service.
>
> Putting these together, one could envision a requirement to offer a
service
> whose bandwidth requirements are met with a service in a transport
network
> that uses multiple LSPs for bandwidth efficiency.  Further this service
> allows changes to be signalled and the bandwidth change is to be
> non-disruptive.
>
> Mechanisms to accomplish such a service could consist of VCAT and LCAS.
> Note that LCAS has its own "in-band" signalling.  I think that the
service
> associated with the VCAT adaptation is the one that should be LCAS
aware,
> not the individual LSPs.
>
> Stephen
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > Sent: Tuesday, June 14, 2005 14:48
> > To: Greg Bernstein <gregbern; Diego Caviglia
> > Cc: yhwkim; ccamp
> > Subject: Re: LCAS and GMPLS
> >
> <snip>
>
> > Nevertheless, before completing on the solutions discussion,
> > we still have to sort out the issues above. I am most
> > concerned about the "layering" issue. That is:
> > a) Is the LCAS component on the egress started by management,
> >    by a trigger in some communication between LCAS components,
> >    or by a trigger in GMPLS signaling?
> > b) Do the LCAS components converse through GMPLS signaling
> >    or by other (existing?) means?
> >
> > > [dc] My initial idea was to use Call_ID to identify the LSP that are
> > part of the
> > > same VCAT/LCAS set and a bit in the profile filed to inform
> > the other
> > and
> > > that LCAS protcol has bo enabled.
> >
> > Understood. I think we have moved on a little from that
> > suggestion. Presumably you will not be unhappy with any
> > solution that is functional and not over-complex.
> >
> > I would suggest that Greg and Diego start an I-D. Call it
> > something like "Applicability Statement for Operating LCAS
> > and VCAT with GMPLS LSPs".
> > Include:
> > - Simple overview of VCAT and LCAS (no more than a page, please)
> > - Simple statement of how LSPs fit into the picture (about
> > half a page)
> > - Statement of the requirements on GMPLS signaling (about a page)
> > - Mechanisms and procedures (two or three pages)
> >
> > It may be that we need to define a new bit somewhere in which
> > case we will drop "Applicability Statement for" from the name
> > of the I-D.
> >
> > I would be very happy to discuss the solutions component with
> > you before publication so that we avoid thrashing.
> >
> >
> > Anyone who is interested in this topic should contact Diego
> > and Greg to offer help.
>




Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 12:15:29 +0000
Message-Id: <[e-mail]>
From: [e-mail]
Date: Wed, 15 Jun 2005 12:13:44 +0000

by psg.com with esmtp (Exim 4.50 (FreeBSD))
id 1DiHhJ-0006va-RM
for [e-mail]; Tue, 14 Jun 2005 20:07:46 +0000
Received: from vissersm.demon.nl ([83.160.252.43]:1597 helo=Maarten01)
by post-22.mail.nl.demon.net with esmtp (Exim 4.43)
id 1DiHB2-0007LY-LT; Tue, 14 Jun 2005 19:34:25 +0000
From: "Maarten Vissers" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>
Cc: <[e-mail]>,
"'Varma, Eve L \(Eve\)'" <[e-mail]>
Subject: Re: LCAS and GMPLS
Sender: [e-mail]
Precedence: bulk

Adrian,

> So it seems to me that you have decided that LCAS is a GMPLS
application.
> That is, LCAS is an end-to-end protocol that triggers the establishment
of
> LSPs by making requests to GMPLS.

LCAS doesn't trigger any establishment of SDH VC-n or OTN ODUk. The
decision to create a VCAT group or to extend a VCAT group is made by a
client  layer's Topology Manager (TM), e.g. an Ethernet layer network TM
or IP layer network TM, which needs an extra (ETH, IP) topological link to
be established between two of its switching nodes. Two cases now to
consider:  1) ETH [IP] switching nodes have GFP/VCAT ports on the nodes 2)
ETH [IP] swithcing nodes have Ethernet ports on the nodes, which are
connected to EoS ports on the next SDH/SONET/OTN equipment.

Case 2 is perhaps today the most common case, so let's focus on this case
and assume that two IP routers need an IP link between them. The steps
that follow the IP TM's decision are (using G.8080 terminology):

1) IP TM requests its ETH CCC to issue an ETH Virtual Connection (EVC)
call
request to the ETH NCC (in the local network).

2) The ETH NCC forwards the request as an EVC connection request to the
local ETH CC.

3) This ETH CC notices that it can't complete the connection request in
absence of sufficient ETH topology.

4) ETH CC recognises that it can forward the connection request as an EVC
call request to a third party network (transport network).

5) So ETH CCC will issue an EVC call request to the network, where this
request is received by the transport netowrk's ETH NCC.

6) The ETH NCC is aware that the EVC connection point at the edges of the
transport network are connected to (SDH, OTN) VCAT ports.

7) The EVC call request is converted into an VCAT call request send to the
VC-n [ODUk] NCC, indicating the number of VC-n [ODUk] members it should
have, the number of diverse routes to be supported (e.g. 2 diverse routes,
each route having half the number of VC-n [ODUk] members) and that LCAS is
required.

8) The VC-n [ODUk] NCC receiving the request converts this into two VC-n
[ODUk] group connection request and configures the two VCAT endpoints with
the appropriate bandwidth to support (i.e. the value of X in the VC-n-Xv
or ODUk-Xv) and enables LCAS.

9) The VC-n [ODUk] CC receives two connection requests to set up two
groups (X1, X2) of VC-n [ODUk] network connections, the two groups must be
diverse routed. As part of the connection setup, the VC-n [ODUk]
termination functions must be configured (e.g. trace identifier values).
The connection setup may arbitrarily pick any subset of the VC-n [ODUk]
Termination Connection Points within the VCAT endpoint (much like
selecting one or more link connections in a link) to be the endpoint of
the X1 and X2 VC-n [ODUk] network connections. The two ends may select
different subsets (LCAS will deal with this).

10) As soon as one of the VC-n [ODUk] path termination functions indicate
that the Trail Signal Fail (TSF) condition is cleared, LCAS will try to
add this VC-n [ODUk] trail to the active group (initially zero active
members are present). This part is outside the NMS/ASON/GMPLS connection
management control.

11) successfull connection set up is reported back to the call request
originator (i.e. the IP TM), so that this new IP link can be taken into
service.

 Assume that at a later stage the IP TM decides to increase the IP link
bandwidth, then it will issue a call modification...

12) ETH CCC in local (i.e. IP) network will issue a call modification
request (bandwdith from B1 to B2)

13) via local ETH NCC, ETH CC and ETH CCC this call modification request
is forwarded to the transport network's ETH NCC.

14) ETH NCC converts this EVC call modification request into a VCAT call
modification request (e.g. X+1 VC-n [ODUk] VCAT group)

15) VC-n [ODUk] NCC receives this VCAT call modification request and
decides which of the two groups (X1, X2) to modify; e.g. X2 :=3D X2+1.

16) VC-n [ODUk] NCC modifies the two VCAT endpoint configurations
(X:=3DX+1)

17) VC-n [ODUk] CC receives a VC-n [ODUk] group conneciton modification
request for X2 group (X2+1). It sets up the additional VC-n [ODUk].

18) As soon as the additional VC-n [ODUk] path termination function
indicates TSF condition cleared, LCAS will try to add this VC-n ODUk]  to
the active VCAT group.

19) successfull connection modification is reported back to the call
request originator.

I hope the above clarifies who originates the request and the steps to
support the request.

Regards,
Maarten


More info on LCAS can be found in:
Next Generation SDH/SONET: Evolution or Revolution?
Huub van Helvoort
ISBN: 0-470-09120-7
http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470091207,descCd-tableOfContents.html




Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 09:08:54 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], "Diego Caviglia" <[e-mail]>, "Greg Bernstein" <[e-mail]>, [e-mail]
Subject: Re: LCAS and GMPLS
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 15 Jun 2005 11:08:08 +0200
Content-Type: text/plain; charset="US-ASCII"

Adrian,

> So it seems to me that you have decided that LCAS is a GMPLS 
> application. That is, LCAS is an end-to-end protocol that triggers the 
> establishment of LSPs by making requests to GMPLS.

LCAS doesn't trigger any establishment of SDH VC-n or OTN ODUk. The 
decision
to create a VCAT group or to extend a VCAT group is made by a client 
layer's
Topology Manager (TM), e.g. an Ethernet layer network TM or IP layer 
network
TM, which needs an extra (ETH, IP) topological link to be established
between two of its switching nodes. Two cases now to consider:
1) ETH [IP] switching nodes have GFP/VCAT ports on the nodes
2) ETH [IP] swithcing nodes have Ethernet ports on the nodes, which are
connected to EoS ports on the next SDH/SONET/OTN equipment.

Case 2 is perhaps today the most common case, so let's focus on this case
and assume that two IP routers need an IP link between them. The steps 
that
follow the IP TM's decision are (using G.8080 terminology):

1) IP TM requests its ETH CCC to issue an ETH Virtual Connection (EVC) 
call
   request to the ETH NCC (in the local network). 
2) The ETH NCC forwards the request as an EVC connection request to the
   local ETH CC. 
3) This ETH CC notices that it can't complete the connection request in
   absence of sufficient ETH topology. 
4) ETH CC recognises that it can forward the connection request as an EVC
   call request to a third party network (transport network). 
5) So ETH CCC will issue an EVC call request to the network, where this
   request is received by the transport netowrk's ETH NCC. 
6) The ETH NCC is aware that the EVC connection point at the edges of the
   transport network are connected to (SDH, OTN) VCAT ports.
7) The EVC call request is converted into an VCAT call request send to the
   VC-n [ODUk] NCC, indicating the number of VC-n [ODUk] members it should
   have, the number of diverse routes to be supported (e.g. 2 diverse 
   routes, each route having half the number of VC-n [ODUk] members) and
   that LCAS is required.
8) The VC-n [ODUk] NCC receiving the request converts this into two VC-n
   [ODUk] group connection request and configures the two VCAT endpoints
   with the appropriate bandwidth to support (i.e. the value of X in the
   VC-n-Xv or ODUk-Xv) and enables LCAS.
9) The VC-n [ODUk] CC receives two connection requests to set up two 
groups
   (X1, X2) of VC-n [ODUk] network connections, the two groups must be
   diverse routed. As part of the connection setup, the VC-n [ODUk]
   termination functions must be configured (e.g. trace identifier 
values).
   The connection setup may arbitrarily pick any subset of the VC-n [ODUk]
   Termination Connection Points within the VCAT endpoint (much like
   selecting one or more link connections in a link) to be the endpoint
   of the X1 and X2 VC-n [ODUk] network connections. The two ends may 
   select different subsets (LCAS will deal with this).
10) As soon as one of the VC-n [ODUk] path termination functions indicate
   that the Trail Signal Fail (TSF) condition is cleared, LCAS will try to
   add this VC-n [ODUk] trail to the active group (initially zero active
   members are present). This part is outside the NMS/ASON/GMPLS 
   connection management control.
11) successfull connection set up is reported back to the call request
   originator (i.e. the IP TM), so that this new IP link can be taken
   into service.

Assume that at a later stage the IP TM decides to increase the IP link
bandwidth, then it will issue a call modification...
12) ETH CCC in local (i.e. IP) network will issue a call modification
    request (bandwdith from B1 to B2)
13) via local ETH NCC, ETH CC and ETH CCC this call modification request 
is
    forwarded to the transport network's ETH NCC.
14) ETH NCC converts this EVC call modification request into a VCAT call
    modification request (e.g. X+1 VC-n [ODUk] VCAT group)
15) VC-n [ODUk] NCC receives this VCAT call modification request and 
decides
    which of the two groups (X1, X2) to modify; e.g. X2 := X2+1.
16) VC-n [ODUk] NCC modifies the two VCAT endpoint configurations (X:=X+1)
17) VC-n [ODUk] CC receives a VC-n [ODUk] group conneciton modification
    request for X2 group (X2+1). It sets up the additional VC-n [ODUk].
18) As soon as the additional VC-n [ODUk] path termination function
    indicates TSF condition cleared, LCAS will try to add this VC-n [ODUk] 
to
    the active VCAT group.
19) successfull connection modification is reported back to the call 
request
    originator.

I hope the above clarifies who originates the request and the steps to
support the request.

Regards,
Maarten


More info on LCAS can be found in:
Next Generation SDH/SONET: Evolution or Revolution?
Huub van Helvoort
ISBN: 0-470-09120-7
http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470091207,descCd-tableOfContents.html 




---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
VoIP: [phone]
Mobile: [phone]
Email:[e-mail]



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 08:38:01 +0000
MIME-Version: 1.0
Sensitivity: 
To: [e-mail]
Cc: "ccamp <ccamp" <[e-mail]>
Subject: RE: LCAS and GMPLS
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 15 Jun 2005 10:36:50 +0200
Content-Type: multipart/alternative; boundary="=_alternative 002F68BDC1257021_="

This is a multipart message in MIME format.
--=_alternative 002F68BDC1257021_=
Content-Type: text/plain; charset="us-ascii"

Hi Stephen,
                    good to hear you on this.

I agree on all of your points.

Regards

Diego


Sent by:        [e-mail]
To:     ccamp <[e-mail]>
cc: 

Subject:        RE: LCAS and GMPLS

In considering the use of LCAS, it is important to note that there are 
separate requirements here: 
1. Having multiple LSPs participate in a single service.   This is not 
just limited to virtual concatenation but is also useful for 1:1 and other 
restoration mechanisms.
2. If LSPs can be added/removed from a common service after they have been 
set up. 
3. What effects LSP addition/removal are allowed to have on the common 
service. 
Putting these together, one could envision a requirement to offer a 
service whose bandwidth requirements are met with a service in a transport 
network that uses multiple LSPs for bandwidth efficiency.  Further this 
service allows changes to be signalled and the bandwidth change is to be 
non-disruptive.
Mechanisms to accomplish such a service could consist of VCAT and LCAS. 
Note that LCAS has its own "in-band" signalling.  I think that the service 
associated with the VCAT adaptation is the one that should be LCAS aware, 
not the individual LSPs.
Stephen 
> -----Original Message----- 
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel 
> Sent: Tuesday, June 14, 2005 14:48 
> To: Greg Bernstein <gregbern; Diego Caviglia 
> Cc: yhwkim; ccamp 
> Subject: Re: LCAS and GMPLS 
> 
<snip> 
> Nevertheless, before completing on the solutions discussion, 
> we still have to sort out the issues above. I am most 
> concerned about the "layering" issue. That is: 
> a) Is the LCAS component on the egress started by management, 
>    by a trigger in some communication between LCAS components, 
>    or by a trigger in GMPLS signaling? 
> b) Do the LCAS components converse through GMPLS signaling 
>    or by other (existing?) means? 
> 
> > [dc] My initial idea was to use Call_ID to identify the LSP that are 
> part of the 
> > same VCAT/LCAS set and a bit in the profile filed to inform 
> the other 
> and 
> > that LCAS protcol has bo enabled. 
> 
> Understood. I think we have moved on a little from that 
> suggestion. Presumably you will not be unhappy with any 
> solution that is functional and not over-complex. 
> 
> I would suggest that Greg and Diego start an I-D. Call it 
> something like "Applicability Statement for Operating LCAS 
> and VCAT with GMPLS LSPs". 
> Include: 
> - Simple overview of VCAT and LCAS (no more than a page, please) 
> - Simple statement of how LSPs fit into the picture (about 
> half a page) 
> - Statement of the requirements on GMPLS signaling (about a page) 
> - Mechanisms and procedures (two or three pages) 
> 
> It may be that we need to define a new bit somewhere in which 
> case we will drop "Applicability Statement for" from the name 
> of the I-D. 
> 
> I would be very happy to discuss the solutions component with 
> you before publication so that we avoid thrashing. 
> 
> 
> Anyone who is interested in this topic should contact Diego 
> and Greg to offer help. 


--=_alternative 002F68BDC1257021_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 color=blue face="Times New Roman">Hi Stephen,</font>
<br><font size=3 color=blue face="Times New Roman">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; good to hear you on this.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">I agree on all of your points.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">Regards</font>
<br><font size=3 color=blue face="Times New Roman"><br>
Diego</font>
<br>
<br>
<p><font size=1 color=#800080 face="sans-serif">Sent by: &nbsp; &nbsp; &nbsp; &nbsp;[e-mail]</font>
<p><font size=1 color=#800080 face="sans-serif">To: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">ccamp &lt;[e-mail]&gt;</font>
<br><font size=1 color=#800080 face="sans-serif">cc: &nbsp; &nbsp; &nbsp; &nbsp; </font>
<br>
<br><font size=1 color=#800080 face="sans-serif">Subject: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">RE: LCAS and GMPLS</font>
<br>
<br><font size=2 face="Times New Roman">In considering the use of LCAS, it is important to note that there are separate requirements here:</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
1. Having multiple LSPs participate in a single service. &nbsp; This is not just limited to virtual concatenation but is also useful for 1:1 and other restoration mechanisms.</font>
<p><font size=2 face="Times New Roman">2. If LSPs can be added/removed from a common service after they have been set up.</font><font size=3 face="Times New Roman"> </font>
<p><font size=2 face="Times New Roman">3. What effects LSP addition/removal are allowed to have on the common service.</font><font size=3 face="Times New Roman"> </font>
<p><font size=2 face="Times New Roman">Putting these together, one could envision a requirement to offer a service whose bandwidth requirements are met with a service in a transport network that uses multiple LSPs for bandwidth efficiency. &nbsp;Further this service allows changes to be signalled and the bandwidth change is to be non-disruptive.</font>
<p><font size=2 face="Times New Roman">Mechanisms to accomplish such a service could consist of VCAT and LCAS. &nbsp;Note that LCAS has its own &quot;in-band&quot; signalling. &nbsp;I think that the service associated with the VCAT adaptation is the one that should be LCAS aware, not the individual LSPs.</font>
<p><font size=2 face="Times New Roman">Stephen</font><font size=3 face="Times New Roman"> </font>
<p><font size=2 face="Times New Roman">&gt; -----Original Message-----</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; From: [e-mail] <br>
&gt; [</font><a href="mailto:[e-mail]"><font size=2 color=blue face="Times New Roman"><u>mailto:[e-mail]</u></font></a><font size=2 face="Times New Roman">] On Behalf Of Adrian Farrel</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; Sent: Tuesday, June 14, 2005 14:48</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; To: Greg Bernstein &lt;gregbern; Diego Caviglia</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; Cc: yhwkim; ccamp</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; Subject: Re: LCAS and GMPLS</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; <br>
&lt;snip&gt;</font><font size=3 face="Times New Roman"> </font>
<p><font size=2 face="Times New Roman">&gt; Nevertheless, before completing on the solutions discussion, <br>
&gt; we still have to sort out the issues above. I am most <br>
&gt; concerned about the &quot;layering&quot; issue. That is:</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; a) Is the LCAS component on the egress started by management,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; &nbsp; &nbsp;by a trigger in some communication between LCAS components,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; &nbsp; &nbsp;or by a trigger in GMPLS signaling?</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; b) Do the LCAS components converse through GMPLS signaling</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; &nbsp; &nbsp;or by other (existing?) means?</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; <br>
&gt; &gt; [dc] My initial idea was to use Call_ID to identify the LSP that are</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; part of the</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; &gt; same VCAT/LCAS set and a bit in the profile filed to inform <br>
&gt; the other</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; and</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; &gt; that LCAS protcol has bo enabled.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; <br>
&gt; Understood. I think we have moved on a little from that <br>
&gt; suggestion. Presumably you will not be unhappy with any <br>
&gt; solution that is functional and not over-complex.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; <br>
&gt; I would suggest that Greg and Diego start an I-D. Call it <br>
&gt; something like &quot;Applicability Statement for Operating LCAS <br>
&gt; and VCAT with GMPLS LSPs&quot;.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; Include:</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; - Simple overview of VCAT and LCAS (no more than a page, please)</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; - Simple statement of how LSPs fit into the picture (about <br>
&gt; half a page)</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; - Statement of the requirements on GMPLS signaling (about a page)</font><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Times New Roman">&gt; - Mechanisms and procedures (two or three pages)</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; <br>
&gt; It may be that we need to define a new bit somewhere in which <br>
&gt; case we will drop &quot;Applicability Statement for&quot; from the name <br>
&gt; of the I-D.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; <br>
&gt; I would be very happy to discuss the solutions component with <br>
&gt; you before publication so that we avoid thrashing.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
&gt; <br>
&gt; <br>
&gt; Anyone who is interested in this topic should contact Diego <br>
&gt; and Greg to offer help.</font><font size=3 face="Times New Roman"> </font>
<br>
<br>
--=_alternative 002F68BDC1257021_=--



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 08:26:33 +0000
MIME-Version: 1.0
Sensitivity: 
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], ""yhwkim" <yhwkim" <[e-mail]>, ""ccamp" <ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 15 Jun 2005 10:23:53 +0200
Content-Type: multipart/alternative; boundary="=_alternative 002E3910C1257021_="

This is a multipart message in MIME format.
--=_alternative 002E3910C1257021_=
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,
                  please find my comments in line.

I cut the agreed part.

Regards

Diego


Please respond to "Adrian Farrel" <[e-mail]>
Sent by:        [e-mail]
To:     "Greg Bernstein <gregbern", "Diego Caviglia" <[e-mail]>
cc:     "yhwkim" <[e-mail]>, "ccamp" <[e-mail]> 

Subject:        Re: LCAS and GMPLS

Hi Diego, Greg,
[CUT]
>  Why?  (a) To more be able to full "extract
> bandwidth from a mesh" via inverse multiplexing. (b)
> To provide for graceful degradation in the case of
> failure, e.g., one of the disjointly routed components
> fails.
> [dc] Agreed

> --> I hear now that Call_ID isn't appropriate (thanks
> Jonathan and Hi!),
> [dc] This is not clear to me, so what is supposed to be the purpose of
the
> Call_ID? Can someone clarify this better?

I, too, think that the Call_ID object (RFC3474) is not appropriate for
this task.

RFC3474 is informational. It documents code point assignments for the
protocol documented by the ITU-T in Recommendation G.7713.2 for use at the
UNI and E-NNI reference points.

If you wanted to use that code point for coordinating VCAT LSPs then you
could, but you would need to have this conversation in the context of the
ITU-T (probably Study Group 15) and not here. A consequence of the use of
the Call_ID object would be that you would:
a) possibly need to implement the ITU-T's UNI before you could exercise
this function
[dc] Actually you can use Call_Id also for SPC circuits, usage of Call_Id 
is not restricted to to UNI.

b) need to disambiguate the Call function in G.7713.2 from the new VCAT
function.
[dc] My view of the Call concept is something that bundle a set of 
connections (LSPs) into a service. This seems to fit to the VCAT/LCAS 
scenario.

On the other hand, a distinct mechanism would allow more easy
interpretation and applicaiton in a GMPLS context.
[dc] Ok I see your point, and even if for me the Call_ID is a good choice 
for this job, I don't want to start an holy war for this.


> but that there is an Association object (thanks Adrian) of
> some sort that might be appropriate.
> [dc] hmmm I need some time to read the RFC 2746 at a first glance seems
> that the RFC address different problems.

Whoah Diego, I don't mean the Session_Association object of RFC 2746. That
mechanism is applicable to RSVP over tunnels and is, I think, not relevant
here.
[dc] ah ah ah ah this is very funny I've looked to the IANA and I've find 
that object. 

I am refering to the Association object in section 16 of
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt
[dc] Ok this sounds more in the scope of the discussion ;-)

In order to solve the problem at hand (which seems quite simply to be that
we wish to be able to associate two or more LSPs that have the same
ingress and egress) we need first to answer the question: why is it not
enough to rely on the fact that the LSPs all come from the same Session?

In draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt there is a
requirement to associate a subset of the LSPs that support a service by
coming from the same Session. This is so that a service may be supported
by more than one working LSP, and each working LSP may be protected by one
or more backup LSPs. The association is between a working LSP and its
backups.

But, for your requirement, it may be enough simply to use the Session to
identify all of the LSPs in the same VCAT group. if it is not enough, then
the Association object gives you the function you need.

> (2) LCAS can be used to add disjointly routed
> components to a group in a hitless fashion after it
> has been set up via GMPLS.  Initiation of the LCAS
> "add" procedure requires some type of management
> command.
> --> I'm not sure if I have a requirement here since I
> could default my end system behavior to automatically
> issue the "add" LCAS commands from both ends after the
> GMPLS procedure completes.  Diego or Jonathan, are
> their other situations where this wouldn't be
> appropriate?
> [dc] Yes but how you know that you have to enable LCAS?
> The LSP could be part of a 'simple' VCAT.

I'm also not sure that there is a GMPLS requirement here.
How do you know to use LCAS in management-established LSPs? Or any other
type of connection? Seems like this is a generic LCAS propblem.

So, there MIGHT [RFC2119] be a requirement to signal in GMPLS that the
egress should enable LCAS.
[dc] Yes that was what I meant.

This is relatively easy to perform if we have to.
I would suggest using draft-ietf-mpls-rsvpte-attributes-05.txt.

[CUT]

Nevertheless, before completing on the solutions discussion, we still have
to sort out the issues above. I am most concerned about the "layering"
issue. That is:
a) Is the LCAS component on the egress started by management,
   by a trigger in some communication between LCAS components,
   or by a trigger in GMPLS signaling?
[dc] I would like to triger it via GMPLS signalling.

b) Do the LCAS components converse through GMPLS signaling
   or by other (existing?) means?
[dc] Hmmm not sure that LCAS needs to be aware of the GMPLS.

> [dc] My initial idea was to use Call_ID to identify the LSP that are
part of the
> same VCAT/LCAS set and a bit in the profile filed to inform the other
and
> that LCAS protcol has bo enabled.

Understood. I think we have moved on a little from that suggestion.
Presumably you will not be unhappy with any solution that is functional
and not over-complex.
[dc] Yes you are right.


I would suggest that Greg and Diego start an I-D. Call it something like
"Applicability Statement for Operating LCAS and VCAT with GMPLS LSPs".
Include:
- Simple overview of VCAT and LCAS (no more than a page, please)
- Simple statement of how LSPs fit into the picture (about half a page)
- Statement of the requirements on GMPLS signaling (about a page)
- Mechanisms and procedures (two or three pages)

It may be that we need to define a new bit somewhere in which case we will
drop "Applicability Statement for" from the name of the I-D.
[dc] Ok no problem for me.  May I ask to Greg to be the editor of this? 
For sure his english is better than mine.  I promise that next time we 
have to write a doc in Italian I'll be the editor ;-)

I would be very happy to discuss the solutions component with you before
publication so that we avoid thrashing.
[dc] Of course will be a pleasure, as usual, to discuss this with you.

Anyone who is interested in this topic should contact Diego and Greg to
offer help.

Thanks,
Adrian


> --- Adrian Farrel <[e-mail]> wrote:
>
> > Hi Greg,
> >
> > Let me come in a bit heavy here, please.
> >
> >
> > > Hi all, thanks for the update Diego and Adrian.
> > Where
> > > we stand seems to be:
> > > (1) We've got an agreed method using the Call_ID
> > to
> > > identify (VC-3/VC-4) component belonging to a VCAT
> > > group. In particular, the Call_ID along with
> > source
> > > and destination addresses uniquely identifies the
> > VCAT
> > > group in the network?
> >
> > No. We do not have agreement on this.
> > We have a vague statement of requirements that a
> > group of LSPs need to be
> > associated. Until we see the requirements fleshed
> > out and written up it
> > would be wrong to pick one solution. For example, we
> > have an Association
> > object that is part of mainstream GMPLS that could
> > be used for this
> > purpose.
> >
> > So, let's see the requirements written up, please.
> >
> > > (2) I can use GMPLS to setup/tear down one or more
> > > VCAT group components at a time. (we've had this
> > for a
> > > while).
> > > (3) Once we set up via GMPLS a new component
> > > (VC-3/VC-4) of a VCAT group we want LCAS to
> > hitlessly
> > > add the new component to the group.
> > > (4) To remove (hitlessly) the component from the
> > VCAT
> > > group we need  LCAS to remove it before we
> > actually
> > > tear down the component connection via GMPLS.
> >
> > So it seems to me that you have decided that LCAS is
> > a GMPLS application.
> > That is, LCAS is an end-to-end protocol that
> > triggers the establishment of
> > LSPs by making requests to GMPLS.
> >
> > This sounds reasonable, but please write it up.
> >
> > > Now the thing that seems a bit tricky to me about
> > (3)
> > > and (4) is that LCAS does things unidirectionally,
> > in
> > > the sense of adding/removing components, (not in
> > the
> > > sense of a protocol which has a handshake
> > mechanism).
> > > All add or remove commands come from the source
> > end
> > > and since we generally setup/teardown
> > bi-directional
> > > connections that would leave us with a bit of
> > > coordination.  Is this what you are thinking
> > Diego?
> > > LCAS experts chime in too :-)
> >
> > Nothing to stop you having unidirectional LSPs if
> > you need to support a
> > service that controls LSPs in a unidirectional way.
> >
> > Cheers,
> > Adrian
> >
> >
>
>
>
>
> __________________________________
> Discover Yahoo!
> Get on-the-go sports scores, stock quotes, news and more. Check it out!
> http://discover.yahoo.com/mobile.html
>
>
>
>
>
>
>
>
>





--=_alternative 002E3910C1257021_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 color=blue face="Times New Roman">Hi Adrian,</font>
<br><font size=3 color=blue face="Times New Roman">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; please find my comments in line.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">I cut the agreed part.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">Regards</font>
<br><font size=3 color=blue face="Times New Roman"><br>
Diego</font>
<br>
<br>
<p><font size=1 color=#800080 face="sans-serif">Please respond to &quot;Adrian Farrel&quot; &lt;[e-mail]&gt;</font>
<p><font size=1 color=#800080 face="sans-serif">Sent by: &nbsp; &nbsp; &nbsp; &nbsp;[e-mail]</font>
<p><font size=1 color=#800080 face="sans-serif">To: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">&quot;Greg Bernstein &lt;gregbern&quot;, &quot;Diego Caviglia&quot; &lt;[e-mail]&gt;</font>
<br><font size=1 color=#800080 face="sans-serif">cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">&quot;yhwkim&quot; &lt;[e-mail]&gt;, &quot;ccamp&quot; &lt;[e-mail]&gt;</font><font size=1 color=#800080 face="sans-serif"> </font>
<br>
<br><font size=1 color=#800080 face="sans-serif">Subject: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">Re: LCAS and GMPLS</font>
<br>
<br><font size=2 face="Courier New">Hi Diego, Greg,<br>
</font><font size=3 color=blue face="Times New Roman">[CUT]</font><font size=2 face="Courier New"><br>
&gt; &nbsp;Why? &nbsp;(a) To more be able to full &quot;extract<br>
&gt; bandwidth from a mesh&quot; via inverse multiplexing. (b)<br>
&gt; To provide for graceful degradation in the case of<br>
&gt; failure, e.g., one of the disjointly routed components<br>
&gt; fails.<br>
&gt; [dc] Agreed<br>
<br>
&gt; --&gt; I hear now that Call_ID isn't appropriate (thanks<br>
&gt; Jonathan and Hi!),<br>
&gt; [dc] This is not clear to me, so what is supposed to be the purpose of<br>
the<br>
&gt; Call_ID? Can someone clarify this better?<br>
<br>
I, too, think that the Call_ID object (RFC3474) is not appropriate for<br>
this task.<br>
<br>
RFC3474 is informational. It documents code point assignments for the<br>
protocol documented by the ITU-T in Recommendation G.7713.2 for use at the<br>
UNI and E-NNI reference points.<br>
<br>
If you wanted to use that code point for coordinating VCAT LSPs then you<br>
could, but you would need to have this conversation in the context of the<br>
ITU-T (probably Study Group 15) and not here. A consequence of the use of<br>
the Call_ID object would be that you would:<br>
a) possibly need to implement the ITU-T's UNI before you could exercise<br>
this function</font>
<br><font size=3 color=blue face="Times New Roman">[dc] Actually you can use Call_Id also for SPC circuits, usage of Call_Id is not restricted to to UNI.</font>
<br><font size=2 face="Courier New"><br>
b) need to disambiguate the Call function in G.7713.2 from the new VCAT<br>
function.<br>
</font><font size=3 color=blue face="Times New Roman">[dc] My view of the Call concept is something that bundle a set of connections (LSPs) into a service. This seems to fit to the VCAT/LCAS scenario.</font>
<br><font size=2 face="Courier New"><br>
On the other hand, a distinct mechanism would allow more easy<br>
interpretation and applicaiton in a GMPLS context.<br>
</font><font size=3 color=blue face="Times New Roman">[dc] Ok I see your point, and even if for me the Call_ID is a good choice for this job, I don't want to start an holy war for this.</font>
<br>
<br><font size=2 face="Courier New"><br>
&gt; but that there is an Association object (thanks Adrian) of<br>
&gt; some sort that might be appropriate.<br>
&gt; [dc] hmmm I need some time to read the RFC 2746 at a first glance seems<br>
&gt; that the RFC address different problems.<br>
<br>
Whoah Diego, I don't mean the Session_Association object of RFC 2746. That<br>
mechanism is applicable to RSVP over tunnels and is, I think, not relevant<br>
here.<br>
</font><font size=3 color=blue face="Times New Roman">[dc] ah ah ah ah this is very funny I've looked to the IANA and I've find that object. &nbsp;</font>
<br><font size=2 face="Courier New"><br>
I am refering to the Association object in section 16 of<br>
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt<br>
</font><font size=3 color=blue face="Times New Roman">[dc] Ok this sounds more in the scope of the discussion ;-)</font>
<br><font size=2 face="Courier New"><br>
In order to solve the problem at hand (which seems quite simply to be that<br>
we wish to be able to associate two or more LSPs that have the same<br>
ingress and egress) we need first to answer the question: why is it not<br>
enough to rely on the fact that the LSPs all come from the same Session?<br>
<br>
In draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt there is a<br>
requirement to associate a subset of the LSPs that support a service by<br>
coming from the same Session. This is so that a service may be supported<br>
by more than one working LSP, and each working LSP may be protected by one<br>
or more backup LSPs. The association is between a working LSP and its<br>
backups.<br>
<br>
But, for your requirement, it may be enough simply to use the Session to<br>
identify all of the LSPs in the same VCAT group. if it is not enough, then<br>
the Association object gives you the function you need.<br>
<br>
&gt; (2) LCAS can be used to add disjointly routed<br>
&gt; components to a group in a hitless fashion after it<br>
&gt; has been set up via GMPLS. &nbsp;Initiation of the LCAS<br>
&gt; &quot;add&quot; procedure requires some type of management<br>
&gt; command.<br>
&gt; --&gt; I'm not sure if I have a requirement here since I<br>
&gt; could default my end system behavior to automatically<br>
&gt; issue the &quot;add&quot; LCAS commands from both ends after the<br>
&gt; GMPLS procedure completes. &nbsp;Diego or Jonathan, are<br>
&gt; their other situations where this wouldn't be<br>
&gt; appropriate?<br>
&gt; [dc] Yes but how you know that you have to enable LCAS?<br>
&gt; The LSP could be part of a 'simple' VCAT.<br>
<br>
I'm also not sure that there is a GMPLS requirement here.<br>
How do you know to use LCAS in management-established LSPs? Or any other<br>
type of connection? Seems like this is a generic LCAS propblem.<br>
<br>
So, there MIGHT [RFC2119] be a requirement to signal in GMPLS that the<br>
egress should enable LCAS.</font>
<br><font size=3 color=blue face="Times New Roman">[dc] Yes that was what I meant.</font>
<br>
<br><font size=2 face="Courier New">This is relatively easy to perform if we have</font><font size=3 color=blue face="Times New Roman"> </font><font size=2 face="Courier New">to.</font>
<br><font size=2 face="Courier New">I would suggest using draft-ietf-mpls-rsvpte-attributes-05.txt.<br>
</font>
<br><font size=3 color=blue face="Times New Roman">[CUT]</font>
<br><font size=2 face="Courier New"><br>
Nevertheless, before completing on the solutions discussion, we still have<br>
to sort out the issues above. I am most concerned about the &quot;layering&quot;<br>
issue. That is:<br>
a) Is the LCAS component on the egress started by management,<br>
 &nbsp; by a trigger in some communication between LCAS components,<br>
 &nbsp; or by a trigger in GMPLS signaling?</font>
<br><font size=3 color=blue face="Times New Roman">[dc] I would like to triger it via GMPLS signalling.</font>
<br><font size=2 face="Courier New"><br>
b) Do the LCAS components converse through GMPLS signaling<br>
 &nbsp; or by other (existing?) means?</font>
<br><font size=3 color=blue face="Times New Roman">[dc] Hmmm not sure that LCAS needs to be aware of the GMPLS.</font><font size=2 face="Courier New"><br>
<br>
&gt; [dc] My initial idea was to use Call_ID to identify the LSP that are<br>
part of the<br>
&gt; same VCAT/LCAS set and a bit in the profile filed to inform the other<br>
and<br>
&gt; that LCAS protcol has bo enabled.<br>
<br>
Understood. I think we have moved on a little from that suggestion.<br>
Presumably you will not be unhappy with any solution that is functional<br>
and not over-complex.<br>
</font><font size=3 color=blue face="Times New Roman">[dc] Yes you are right.</font>
<br>
<br><font size=2 face="Courier New"><br>
I would suggest that Greg and Diego start an I-D. Call it something like<br>
&quot;Applicability Statement for Operating LCAS and VCAT with GMPLS LSPs&quot;.<br>
Include:<br>
- Simple overview of VCAT and LCAS (no more than a page, please)<br>
- Simple statement of how LSPs fit into the picture (about half a page)<br>
- Statement of the requirements on GMPLS signaling (about a page)<br>
- Mechanisms and procedures (two or three pages)<br>
<br>
It may be that we need to define a new bit somewhere in which case we will<br>
drop &quot;Applicability Statement for&quot; from the name of the I-D.<br>
</font><font size=3 color=blue face="Times New Roman">[dc] Ok no problem for me. &nbsp;May I ask to Greg to be the editor of this? &nbsp;For sure his english is better than mine. &nbsp;I promise that next time we have to write a doc in Italian I'll be the editor ;-)</font>
<br><font size=2 face="Courier New"><br>
I would be very happy to discuss the solutions component with you before<br>
publication so that we avoid thrashing.<br>
</font><font size=3 color=blue face="Times New Roman">[dc] Of course will be a pleasure, as usual, to discuss this with you.</font><font size=2 face="Courier New"><br>
<br>
Anyone who is interested in this topic should contact Diego and Greg to<br>
offer help.<br>
<br>
Thanks,<br>
Adrian<br>
<br>
<br>
&gt; --- Adrian Farrel &lt;[e-mail]&gt; wrote:<br>
&gt;<br>
&gt; &gt; Hi Greg,<br>
&gt; &gt;<br>
&gt; &gt; Let me come in a bit heavy here, please.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; Hi all, thanks for the update Diego and Adrian.<br>
&gt; &gt; Where<br>
&gt; &gt; &gt; we stand seems to be:<br>
&gt; &gt; &gt; (1) We've got an agreed method using the Call_ID<br>
&gt; &gt; to<br>
&gt; &gt; &gt; identify (VC-3/VC-4) component belonging to a VCAT<br>
&gt; &gt; &gt; group. In particular, the Call_ID along with<br>
&gt; &gt; source<br>
&gt; &gt; &gt; and destination addresses uniquely identifies the<br>
&gt; &gt; VCAT<br>
&gt; &gt; &gt; group in the network?<br>
&gt; &gt;<br>
&gt; &gt; No. We do not have agreement on this.<br>
&gt; &gt; We have a vague statement of requirements that a<br>
&gt; &gt; group of LSPs need to be<br>
&gt; &gt; associated. Until we see the requirements fleshed<br>
&gt; &gt; out and written up it<br>
&gt; &gt; would be wrong to pick one solution. For example, we<br>
&gt; &gt; have an Association<br>
&gt; &gt; object that is part of mainstream GMPLS that could<br>
&gt; &gt; be used for this<br>
&gt; &gt; purpose.<br>
&gt; &gt;<br>
&gt; &gt; So, let's see the requirements written up, please.<br>
&gt; &gt;<br>
&gt; &gt; &gt; (2) I can use GMPLS to setup/tear down one or more<br>
&gt; &gt; &gt; VCAT group components at a time. (we've had this<br>
&gt; &gt; for a<br>
&gt; &gt; &gt; while).<br>
&gt; &gt; &gt; (3) Once we set up via GMPLS a new component<br>
&gt; &gt; &gt; (VC-3/VC-4) of a VCAT group we want LCAS to<br>
&gt; &gt; hitlessly</font>
<br><font size=2 face="Courier New">&gt; &gt; &gt; add the new component to the group.<br>
&gt; &gt; &gt; (4) To remove (hitlessly) the component from the<br>
&gt; &gt; VCAT<br>
&gt; &gt; &gt; group we need &nbsp;LCAS to remove it before we<br>
&gt; &gt; actually<br>
&gt; &gt; &gt; tear down the component connection via GMPLS.<br>
&gt; &gt;<br>
&gt; &gt; So it seems to me that you have decided that LCAS is<br>
&gt; &gt; a GMPLS application.<br>
&gt; &gt; That is, LCAS is an end-to-end protocol that<br>
&gt; &gt; triggers the establishment of<br>
&gt; &gt; LSPs by making requests to GMPLS.<br>
&gt; &gt;<br>
&gt; &gt; This sounds reasonable, but please write it up.<br>
&gt; &gt;<br>
&gt; &gt; &gt; Now the thing that seems a bit tricky to me about<br>
&gt; &gt; (3)<br>
&gt; &gt; &gt; and (4) is that LCAS does things unidirectionally,<br>
&gt; &gt; in<br>
&gt; &gt; &gt; the sense of adding/removing components, (not in<br>
&gt; &gt; the<br>
&gt; &gt; &gt; sense of a protocol which has a handshake<br>
&gt; &gt; mechanism).<br>
&gt; &gt; &gt; All add or remove commands come from the source<br>
&gt; &gt; end<br>
&gt; &gt; &gt; and since we generally setup/teardown<br>
&gt; &gt; bi-directional<br>
&gt; &gt; &gt; connections that would leave us with a bit of<br>
&gt; &gt; &gt; coordination. &nbsp;Is this what you are thinking<br>
&gt; &gt; Diego?<br>
&gt; &gt; &gt; LCAS experts chime in too :-)<br>
&gt; &gt;<br>
&gt; &gt; Nothing to stop you having unidirectional LSPs if<br>
&gt; &gt; you need to support a<br>
&gt; &gt; service that controls LSPs in a unidirectional way.<br>
&gt; &gt;<br>
&gt; &gt; Cheers,<br>
&gt; &gt; Adrian<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; __________________________________<br>
&gt; Discover Yahoo!<br>
&gt; Get on-the-go sports scores, stock quotes, news and more. Check it out!<br>
&gt; http://discover.yahoo.com/mobile.html<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
<br>
</font>
<br>
<br>
--=_alternative 002E3910C1257021_=--



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 03:51:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: LCAS and GMPLS
Date: Tue, 14 Jun 2005 23:50:05 -0400
Message-ID: <[e-mail]>
Thread-Topic: LCAS and GMPLS
Thread-Index: AcVxE7oPJSCEq8mTTYmwlmW1maVVmAASFthQ
From: "Ong, Lyndon" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Greg Bernstein <gregbern" <[e-mail]>, "Diego Caviglia" <[e-mail]>
Cc: "yhwkim" <[e-mail]>, "ccamp" <[e-mail]>

Hi Adrian,

Just a couple of comments:

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

If you wanted to use that code point for coordinating VCAT LSPs then you
could, but you would need to have this conversation in the context of
the ITU-T (probably Study Group 15) and not here. A consequence of the
use of the Call_ID object would be that you would:
a) possibly need to implement the ITU-T's UNI before you could exercise
this function

[LYO] This is not necessary, IMHO, the Call_ID is really part of
G.7713.2,=20
which could be used as UNI or E-NNI.

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

So, there MIGHT [RFC2119] be a requirement to signal in GMPLS that the
egress should enable LCAS. This is relatively easy to perform if we have
to. I would suggest using draft-ietf-mpls-rsvpte-attributes-05.txt.

[LYO] This seems like a useful addition, also information such as the
initial
size of the LCAS group, as this is not immediately obvious unless you
can
guarantee that setup of the group members is always done in correct
sequence.

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

But as with the previous question, I wonder whether you really want to
use GMPLS signaling to carry LCAS commands, or whether you want to run
LCAS between the end points and have them trigger GMPLS. I suspect that
Neil would say that this is a layering question!

[LYO] I don't think you actually need to use GMPLS to carry LCAS
commands,
since these will already be carried in the overhead.  =20

Cheers,

Lyndon



Envelope-to: [e-mail]
Delivery-date: Wed, 15 Jun 2005 00:30:13 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ypF3+qHn3J0li9MNqtKxU0cSILqaT9gBnaRI8UG46eKBK3ijbCP+kQW1Eo+g3F41BRE1zLsjoMPjoEJY5/8VuKqsq+cfAlOBCYuuz7ZbKL2JWSr6I9rWJZFfIh6mOujbKT19bofsY64mlgHDuTHYDPZuLJUoeZIe8TuU6P5DOgo=  ;
Message-ID: <[e-mail]>
Date: Tue, 14 Jun 2005 08:27:22 -0700 (PDT)
From: Greg Bernstein <[e-mail]>
Subject: Re: LCAS and GMPLS
To: Adrian Farrel <[e-mail]>, Diego Caviglia <[e-mail]>
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi Adrian, not heavy at all. This helps me see what's
up. Let me recast as informal requirements with
justification and of course a bit of solution
pondering.

(1) I (as an individual) really want to be able to use
GMPLS to set up disjointly routed components of a VCAT
group.  Why?  (a) To more be able to full "extract
bandwidth from a mesh" via inverse multiplexing. (b)
To provide for graceful degradation in the case of
failure, e.g., one of the disjointly routed components
fails.
--> I hear now that Call_ID isn't appropriate (thanks
Jonathan and Hi!), but that there is an Association
object (thanks Adrian) of some sort that might be
appropriate.

(2) LCAS can be used to add disjointly routed
components to a group in a hitless fashion after it
has been set up via GMPLS.  Initiation of the LCAS
"add" procedure requires some type of management
command. 
--> I'm not sure if I have a requirement here since I
could default my end system behavior to automatically
issue the "add" LCAS commands from both ends after the
GMPLS procedure completes.  Diego or Jonathan, are
their other situations where this wouldn't be
appropriate?

(3) LCAS can be used to delete disjointly routed
components in a hitless fashion prior to removal of
the component connection via GMPLS. Initiation of the
LCAS "delete" procedure requires some type of
management command. My requirement here would be to
have a way to communicate via the end systems that I'm
going to take down the connection and to have LCAS
first do its hitless deletion.  
--> Now at the end that initiating the removal of the
component alerting LCAS to "delete" shouldn't be a
problem. Its the far end we'd want to communicated
something to...  Now didn't we (way back) add
something to RSVP GMPLS extensions to kind of anounce
the release of the connection prior to tear down so
that we could turn off SONET/SDH alarms (and couldn't
we use that to trigger the "reverse LCAS delete").

So Adrian, it seems like LCAS isn't so much as a GMPLS
application but a helper application enabling the
hitless addition and deletion of VCAT components. 
Also we may be very close to having all the facilities
we need to automatically enable its "co-use" with
GMPLS. Hence we could be talking about an "Application
Note" rather than extension.  I need to review some of
the ITU VCAT management models to make sure I haven't
glossed over things too much.

Greg B.

--- Adrian Farrel <[e-mail]> wrote:

> Hi Greg,
> 
> Let me come in a bit heavy here, please.
> 
> 
> > Hi all, thanks for the update Diego and Adrian.
> Where
> > we stand seems to be:
> > (1) We've got an agreed method using the Call_ID
> to
> > identify (VC-3/VC-4) component belonging to a VCAT
> > group. In particular, the Call_ID along with
> source
> > and destination addresses uniquely identifies the
> VCAT
> > group in the network?
> 
> No. We do not have agreement on this.
> We have a vague statement of requirements that a
> group of LSPs need to be
> associated. Until we see the requirements fleshed
> out and written up it
> would be wrong to pick one solution. For example, we
> have an Association
> object that is part of mainstream GMPLS that could
> be used for this
> purpose.
> 
> So, let's see the requirements written up, please.
> 
> > (2) I can use GMPLS to setup/tear down one or more
> > VCAT group components at a time. (we've had this
> for a
> > while).
> > (3) Once we set up via GMPLS a new component
> > (VC-3/VC-4) of a VCAT group we want LCAS to
> hitlessly
> > add the new component to the group.
> > (4) To remove (hitlessly) the component from the
> VCAT
> > group we need  LCAS to remove it before we
> actually
> > tear down the component connection via GMPLS.
> 
> So it seems to me that you have decided that LCAS is
> a GMPLS application.
> That is, LCAS is an end-to-end protocol that
> triggers the establishment of
> LSPs by making requests to GMPLS.
> 
> This sounds reasonable, but please write it up.
> 
> > Now the thing that seems a bit tricky to me about
> (3)
> > and (4) is that LCAS does things unidirectionally,
> in
> > the sense of adding/removing components, (not in
> the
> > sense of a protocol which has a handshake
> mechanism).
> > All add or remove commands come from the source
> end
> > and since we generally setup/teardown
> bi-directional
> > connections that would leave us with a bit of
> > coordination.  Is this what you are thinking
> Diego?
> > LCAS experts chime in too :-)
> 
> Nothing to stop you having unidirectional LSPs if
> you need to support a
> service that controls LSPs in a unidirectional way.
> 
> Cheers,
> Adrian
> 
> 



		
__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html



Envelope-to: [e-mail]
Delivery-date: Tue, 14 Jun 2005 21:11:52 +0000
Message-ID: <[e-mail]>
From: "Stephen Shew" <[e-mail]>
To: ccamp <[e-mail]>
Subject: RE: LCAS and GMPLS
Date: Tue, 14 Jun 2005 17:10:09 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57125.728D7EA2"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C57125.728D7EA2
Content-Type: text/plain

In considering the use of LCAS, it is important to note that there are
separate requirements here:
1. Having multiple LSPs participate in a single service.   This is not just
limited to virtual concatenation but is also useful for 1:1 and other
restoration mechanisms.

2. If LSPs can be added/removed from a common service after they have been
set up.

3. What effects LSP addition/removal are allowed to have on the common
service.

Putting these together, one could envision a requirement to offer a service
whose bandwidth requirements are met with a service in a transport network
that uses multiple LSPs for bandwidth efficiency.  Further this service
allows changes to be signalled and the bandwidth change is to be
non-disruptive.

Mechanisms to accomplish such a service could consist of VCAT and LCAS.
Note that LCAS has its own "in-band" signalling.  I think that the service
associated with the VCAT adaptation is the one that should be LCAS aware,
not the individual LSPs.

Stephen

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, June 14, 2005 14:48
> To: Greg Bernstein <gregbern; Diego Caviglia
> Cc: yhwkim; ccamp
> Subject: Re: LCAS and GMPLS
> 
<snip>

> Nevertheless, before completing on the solutions discussion, 
> we still have to sort out the issues above. I am most 
> concerned about the "layering" issue. That is:
> a) Is the LCAS component on the egress started by management,
>    by a trigger in some communication between LCAS components,
>    or by a trigger in GMPLS signaling?
> b) Do the LCAS components converse through GMPLS signaling
>    or by other (existing?) means?
> 
> > [dc] My initial idea was to use Call_ID to identify the LSP that are
> part of the
> > same VCAT/LCAS set and a bit in the profile filed to inform 
> the other
> and
> > that LCAS protcol has bo enabled.
> 
> Understood. I think we have moved on a little from that 
> suggestion. Presumably you will not be unhappy with any 
> solution that is functional and not over-complex.
> 
> I would suggest that Greg and Diego start an I-D. Call it 
> something like "Applicability Statement for Operating LCAS 
> and VCAT with GMPLS LSPs".
> Include:
> - Simple overview of VCAT and LCAS (no more than a page, please)
> - Simple statement of how LSPs fit into the picture (about 
> half a page)
> - Statement of the requirements on GMPLS signaling (about a page)
> - Mechanisms and procedures (two or three pages)
> 
> It may be that we need to define a new bit somewhere in which 
> case we will drop "Applicability Statement for" from the name 
> of the I-D.
> 
> I would be very happy to discuss the solutions component with 
> you before publication so that we avoid thrashing.
> 
> 
> Anyone who is interested in this topic should contact Diego 
> and Greg to offer help.

------_=_NextPart_001_01C57125.728D7EA2
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: LCAS and GMPLS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>In considering the use of LCAS, it is important to =
note that there are separate requirements here:</FONT>
<BR><FONT SIZE=3D2>1. Having multiple LSPs participate in a single =
service.&nbsp;&nbsp; This is not just limited to virtual concatenation =
but is also useful for 1:1 and other restoration mechanisms.</FONT></P>

<P><FONT SIZE=3D2>2. If LSPs can be added/removed from a common service =
after they have been set up.</FONT>
</P>

<P><FONT SIZE=3D2>3. What effects LSP addition/removal are allowed to =
have on the common service.</FONT>
</P>

<P><FONT SIZE=3D2>Putting these together, one could envision a =
requirement to offer a service whose bandwidth requirements are met =
with a service in a transport network that uses multiple LSPs for =
bandwidth efficiency.&nbsp; Further this service allows changes to be =
signalled and the bandwidth change is to be non-disruptive.</FONT></P>

<P><FONT SIZE=3D2>Mechanisms to accomplish such a service could consist =
of VCAT and LCAS.&nbsp; Note that LCAS has its own &quot;in-band&quot; =
signalling.&nbsp; I think that the service associated with the VCAT =
adaptation is the one that should be LCAS aware, not the individual =
LSPs.</FONT></P>

<P><FONT SIZE=3D2>Stephen</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [e-mail] </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>] On Behalf Of Adrian Farrel</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, June 14, 2005 14:48</FONT>
<BR><FONT SIZE=3D2>&gt; To: Greg Bernstein &lt;gregbern; Diego =
Caviglia</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: yhwkim; ccamp</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: LCAS and GMPLS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Nevertheless, before completing on the solutions =
discussion, </FONT>
<BR><FONT SIZE=3D2>&gt; we still have to sort out the issues above. I =
am most </FONT>
<BR><FONT SIZE=3D2>&gt; concerned about the &quot;layering&quot; issue. =
That is:</FONT>
<BR><FONT SIZE=3D2>&gt; a) Is the LCAS component on the egress started =
by management,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; by a trigger in some =
communication between LCAS components,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; or by a trigger in GMPLS =
signaling?</FONT>
<BR><FONT SIZE=3D2>&gt; b) Do the LCAS components converse through =
GMPLS signaling</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; or by other (existing?) =
means?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [dc] My initial idea was to use Call_ID to =
identify the LSP that are</FONT>
<BR><FONT SIZE=3D2>&gt; part of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; same VCAT/LCAS set and a bit in the =
profile filed to inform </FONT>
<BR><FONT SIZE=3D2>&gt; the other</FONT>
<BR><FONT SIZE=3D2>&gt; and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that LCAS protcol has bo enabled.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Understood. I think we have moved on a little =
from that </FONT>
<BR><FONT SIZE=3D2>&gt; suggestion. Presumably you will not be unhappy =
with any </FONT>
<BR><FONT SIZE=3D2>&gt; solution that is functional and not =
over-complex.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would suggest that Greg and Diego start an =
I-D. Call it </FONT>
<BR><FONT SIZE=3D2>&gt; something like &quot;Applicability Statement =
for Operating LCAS </FONT>
<BR><FONT SIZE=3D2>&gt; and VCAT with GMPLS LSPs&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; Include:</FONT>
<BR><FONT SIZE=3D2>&gt; - Simple overview of VCAT and LCAS (no more =
than a page, please)</FONT>
<BR><FONT SIZE=3D2>&gt; - Simple statement of how LSPs fit into the =
picture (about </FONT>
<BR><FONT SIZE=3D2>&gt; half a page)</FONT>
<BR><FONT SIZE=3D2>&gt; - Statement of the requirements on GMPLS =
signaling (about a page)</FONT>
<BR><FONT SIZE=3D2>&gt; - Mechanisms and procedures (two or three =
pages)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It may be that we need to define a new bit =
somewhere in which </FONT>
<BR><FONT SIZE=3D2>&gt; case we will drop &quot;Applicability Statement =
for&quot; from the name </FONT>
<BR><FONT SIZE=3D2>&gt; of the I-D.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would be very happy to discuss the solutions =
component with </FONT>
<BR><FONT SIZE=3D2>&gt; you before publication so that we avoid =
thrashing.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Anyone who is interested in this topic should =
contact Diego </FONT>
<BR><FONT SIZE=3D2>&gt; and Greg to offer help.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C57125.728D7EA2--



Envelope-to: [e-mail]
Delivery-date: Tue, 14 Jun 2005 18:59:22 +0000
Message-ID: <0e0501c57113$4d95d6f0$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Greg Bernstein <gregbern" <[e-mail]>, "Diego Caviglia" <[e-mail]>
Cc: "yhwkim" <[e-mail]>, "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Tue, 14 Jun 2005 19:48:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Diego, Greg,
> Hi Adrian, not heavy at all. This helps me see what's
> up. Let me recast as informal requirements with
> justification and of course a bit of solution
> pondering.
>
> (1) I (as an individual) really want to be able to use
> GMPLS to set up disjointly routed components of a VCAT
> group.

Good. That is really clear.
This maps, I believe, into the need to be able to group together multiple
LSPs that support the same service.

>  Why?  (a) To more be able to full "extract
> bandwidth from a mesh" via inverse multiplexing. (b)
> To provide for graceful degradation in the case of
> failure, e.g., one of the disjointly routed components
> fails.
> [dc] Agreed

> --> I hear now that Call_ID isn't appropriate (thanks
> Jonathan and Hi!),
> [dc] This is not clear to me, so what is supposed to be the purpose of
the
> Call_ID? Can someone clarify this better?

I, too, think that the Call_ID object (RFC3474) is not appropriate for
this task.

RFC3474 is informational. It documents code point assignments for the
protocol documented by the ITU-T in Recommendation G.7713.2 for use at the
UNI and E-NNI reference points.

If you wanted to use that code point for coordinating VCAT LSPs then you
could, but you would need to have this conversation in the context of the
ITU-T (probably Study Group 15) and not here. A consequence of the use of
the Call_ID object would be that you would:
a) possibly need to implement the ITU-T's UNI before you could exercise
this function
b) need to disambiguate the Call function in G.7713.2 from the new VCAT
function.

On the other hand, a distinct mechanism would allow more easy
interpretation and applicaiton in a GMPLS context.

> but that there is an Association object (thanks Adrian) of
> some sort that might be appropriate.
> [dc] hmmm I need some time to read the RFC 2746 at a first glance seems
> that the RFC address different problems.

Whoah Diego, I don't mean the Session_Association object of RFC 2746. That
mechanism is applicable to RSVP over tunnels and is, I think, not relevant
here.

I am refering to the Association object in section 16 of
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt

In order to solve the problem at hand (which seems quite simply to be that
we wish to be able to associate two or more LSPs that have the same
ingress and egress) we need first to answer the question: why is it not
enough to rely on the fact that the LSPs all come from the same Session?

In draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt there is a
requirement to associate a subset of the LSPs that support a service by
coming from the same Session. This is so that a service may be supported
by more than one working LSP, and each working LSP may be protected by one
or more backup LSPs. The association is between a working LSP and its
backups.

But, for your requirement, it may be enough simply to use the Session to
identify all of the LSPs in the same VCAT group. if it is not enough, then
the Association object gives you the function you need.

> (2) LCAS can be used to add disjointly routed
> components to a group in a hitless fashion after it
> has been set up via GMPLS.  Initiation of the LCAS
> "add" procedure requires some type of management
> command.
> --> I'm not sure if I have a requirement here since I
> could default my end system behavior to automatically
> issue the "add" LCAS commands from both ends after the
> GMPLS procedure completes.  Diego or Jonathan, are
> their other situations where this wouldn't be
> appropriate?
> [dc] Yes but how you know that you have to enable LCAS?
> The LSP could be part of a 'simple' VCAT.

I'm also not sure that there is a GMPLS requirement here.
How do you know to use LCAS in management-established LSPs? Or any other
type of connection? Seems like this is a generic LCAS propblem.

So, there MIGHT [RFC2119] be a requirement to signal in GMPLS that the
egress should enable LCAS. This is relatively easy to perform if we have
to. I would suggest using draft-ietf-mpls-rsvpte-attributes-05.txt.

> (3) LCAS can be used to delete disjointly routed
> components in a hitless fashion prior to removal of
> the component connection via GMPLS. Initiation of the
> LCAS "delete" procedure requires some type of
> management command. My requirement here would be to
> have a way to communicate via the end systems that I'm
> going to take down the connection and to have LCAS
> first do its hitless deletion.
> --> Now at the end that initiating the removal of the
> component alerting LCAS to "delete" shouldn't be a
> problem. Its the far end we'd want to communicated
> something to...  Now didn't we (way back) add
> something to RSVP GMPLS extensions to kind of anounce
> the release of the connection prior to tear down so
> that we could turn off SONET/SDH alarms (and couldn't
> we use that to trigger the "reverse LCAS delete").

Yes, indeed. We have "alarm free teardown" using the Administrative Status
object [RFC 3473]. And this could be used to trigger actions.

But as with the previous question, I wonder whether you really want to use
GMPLS signaling to carry LCAS commands, or whether you want to run LCAS
between the end points and have them trigger GMPLS. I suspect that Neil
would say that this is a layering question!

> So Adrian, it seems like LCAS isn't so much as a GMPLS
> application but a helper application enabling the
> hitless addition and deletion of VCAT components.
> Also we may be very close to having all the facilities
> we need to automatically enable its "co-use" with
> GMPLS. Hence we could be talking about an "Application
> Note" rather than extension.  I need to review some of
> the ITU VCAT management models to make sure I haven't
> glossed over things too much.
> [dc] I agree that LCAS is an helper and we almost have all we
> need to use it via GMPLS.  We need to agree on how.

Yes. We seem to be in violent agreement that we need to end up with an
Applicability Statement.

We are making good progress on drilling down to the requirements (don't
throw away these emails, you will need them for you I-D!).

Nevertheless, before completing on the solutions discussion, we still have
to sort out the issues above. I am most concerned about the "layering"
issue. That is:
a) Is the LCAS component on the egress started by management,
   by a trigger in some communication between LCAS components,
   or by a trigger in GMPLS signaling?
b) Do the LCAS components converse through GMPLS signaling
   or by other (existing?) means?

> [dc] My initial idea was to use Call_ID to identify the LSP that are
part of the
> same VCAT/LCAS set and a bit in the profile filed to inform the other
and
> that LCAS protcol has bo enabled.

Understood. I think we have moved on a little from that suggestion.
Presumably you will not be unhappy with any solution that is functional
and not over-complex.

I would suggest that Greg and Diego start an I-D. Call it something like
"Applicability Statement for Operating LCAS and VCAT with GMPLS LSPs".
Include:
- Simple overview of VCAT and LCAS (no more than a page, please)
- Simple statement of how LSPs fit into the picture (about half a page)
- Statement of the requirements on GMPLS signaling (about a page)
- Mechanisms and procedures (two or three pages)

It may be that we need to define a new bit somewhere in which case we will
drop "Applicability Statement for" from the name of the I-D.

I would be very happy to discuss the solutions component with you before
publication so that we avoid thrashing.


Anyone who is interested in this topic should contact Diego and Greg to
offer help.

Thanks,
Adrian


> --- Adrian Farrel <[e-mail]> wrote:
>
> > Hi Greg,
> >
> > Let me come in a bit heavy here, please.
> >
> >
> > > Hi all, thanks for the update Diego and Adrian.
> > Where
> > > we stand seems to be:
> > > (1) We've got an agreed method using the Call_ID
> > to
> > > identify (VC-3/VC-4) component belonging to a VCAT
> > > group. In particular, the Call_ID along with
> > source
> > > and destination addresses uniquely identifies the
> > VCAT
> > > group in the network?
> >
> > No. We do not have agreement on this.
> > We have a vague statement of requirements that a
> > group of LSPs need to be
> > associated. Until we see the requirements fleshed
> > out and written up it
> > would be wrong to pick one solution. For example, we
> > have an Association
> > object that is part of mainstream GMPLS that could
> > be used for this
> > purpose.
> >
> > So, let's see the requirements written up, please.
> >
> > > (2) I can use GMPLS to setup/tear down one or more
> > > VCAT group components at a time. (we've had this
> > for a
> > > while).
> > > (3) Once we set up via GMPLS a new component
> > > (VC-3/VC-4) of a VCAT group we want LCAS to
> > hitlessly
> > > add the new component to the group.
> > > (4) To remove (hitlessly) the component from the
> > VCAT
> > > group we need  LCAS to remove it before we
> > actually
> > > tear down the component connection via GMPLS.
> >
> > So it seems to me that you have decided that LCAS is
> > a GMPLS application.
> > That is, LCAS is an end-to-end protocol that
> > triggers the establishment of
> > LSPs by making requests to GMPLS.
> >
> > This sounds reasonable, but please write it up.
> >
> > > Now the thing that seems a bit tricky to me about
> > (3)
> > > and (4) is that LCAS does things unidirectionally,
> > in
> > > the sense of adding/removing components, (not in
> > the
> > > sense of a protocol which has a handshake
> > mechanism).
> > > All add or remove commands come from the source
> > end
> > > and since we generally setup/teardown
> > bi-directional
> > > connections that would leave us with a bit of
> > > coordination.  Is this what you are thinking
> > Diego?
> > > LCAS experts chime in too :-)
> >
> > Nothing to stop you having unidirectional LSPs if
> > you need to support a
> > service that controls LSPs in a unidirectional way.
> >
> > Cheers,
> > Adrian
> >
> >
>
>
>
>
> __________________________________
> Discover Yahoo!
> Get on-the-go sports scores, stock quotes, news and more. Check it out!
> http://discover.yahoo.com/mobile.html
>
>
>
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 14 Jun 2005 16:25:52 +0000
Sensitivity: 
Subject: Re: LCAS and GMPLS
To: "Greg Bernstein <gregbern" <[e-mail]>
Cc: "Adrian Farrel <adrian" <[e-mail]>, "yhwkim" <[e-mail]>, "ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Tue, 14 Jun 2005 18:23:50 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Greg,
               some further comments in line.

Regards

Diego



Greg Bernstein <[e-mail]> on 14/06/2005 17.27.22

To:    Adrian Farrel <[e-mail]>, Diego Caviglia
       <[e-mail]>
cc:    [e-mail], [e-mail]

Subject:    Re: LCAS and GMPLS

Hi Adrian, not heavy at all. This helps me see what's
up. Let me recast as informal requirements with
justification and of course a bit of solution
pondering.

(1) I (as an individual) really want to be able to use
GMPLS to set up disjointly routed components of a VCAT
group.  Why?  (a) To more be able to full "extract
bandwidth from a mesh" via inverse multiplexing. (b)
To provide for graceful degradation in the case of
failure, e.g., one of the disjointly routed components
fails.
[dc] Agreed
--> I hear now that Call_ID isn't appropriate (thanks
Jonathan and Hi!),
[dc] This is not clear to me, so what is supposed to be the purpose of the
Call_ID? Can someone clarify this better?

but that there is an Association
object (thanks Adrian) of some sort that might be
appropriate.
[dc] hmmm I need some time to read the RFC 2746 at a first glance seems
that the RFC address different problems.

(2) LCAS can be used to add disjointly routed
components to a group in a hitless fashion after it
has been set up via GMPLS.  Initiation of the LCAS
"add" procedure requires some type of management
command.
--> I'm not sure if I have a requirement here since I
could default my end system behavior to automatically
issue the "add" LCAS commands from both ends after the
GMPLS procedure completes.  Diego or Jonathan, are
their other situations where this wouldn't be
appropriate?
[dc] Yes but how you know that you have to enable LCAS?  The LSP could be
part of a 'simple' VCAT.


(3) LCAS can be used to delete disjointly routed
components in a hitless fashion prior to removal of
the component connection via GMPLS. Initiation of the
LCAS "delete" procedure requires some type of
management command. My requirement here would be to
have a way to communicate via the end systems that I'm
going to take down the connection and to have LCAS
first do its hitless deletion.
--> Now at the end that initiating the removal of the
component alerting LCAS to "delete" shouldn't be a
problem. Its the far end we'd want to communicated
something to...  Now didn't we (way back) add
something to RSVP GMPLS extensions to kind of anounce
the release of the connection prior to tear down so
that we could turn off SONET/SDH alarms (and couldn't
we use that to trigger the "reverse LCAS delete").

So Adrian, it seems like LCAS isn't so much as a GMPLS
application but a helper application enabling the
hitless addition and deletion of VCAT components.
Also we may be very close to having all the facilities
we need to automatically enable its "co-use" with
GMPLS. Hence we could be talking about an "Application
Note" rather than extension.  I need to review some of
the ITU VCAT management models to make sure I haven't
glossed over things too much.
[dc] I agree that LCAS is an helper and we almost have all we need to use
it via GMPLS.  We need to agree on how.
My initial idea was to use Call_ID to identify the LSP that are part of the
same VCAT/LCAS set and a bit in the profile filed to inform the other and
that LCAS protcol has bo enabled.


Greg B.

--- Adrian Farrel <[e-mail]> wrote:

> Hi Greg,
>
> Let me come in a bit heavy here, please.
>
>
> > Hi all, thanks for the update Diego and Adrian.
> Where
> > we stand seems to be:
> > (1) We've got an agreed method using the Call_ID
> to
> > identify (VC-3/VC-4) component belonging to a VCAT
> > group. In particular, the Call_ID along with
> source
> > and destination addresses uniquely identifies the
> VCAT
> > group in the network?
>
> No. We do not have agreement on this.
> We have a vague statement of requirements that a
> group of LSPs need to be
> associated. Until we see the requirements fleshed
> out and written up it
> would be wrong to pick one solution. For example, we
> have an Association
> object that is part of mainstream GMPLS that could
> be used for this
> purpose.
>
> So, let's see the requirements written up, please.
>
> > (2) I can use GMPLS to setup/tear down one or more
> > VCAT group components at a time. (we've had this
> for a
> > while).
> > (3) Once we set up via GMPLS a new component
> > (VC-3/VC-4) of a VCAT group we want LCAS to
> hitlessly
> > add the new component to the group.
> > (4) To remove (hitlessly) the component from the
> VCAT
> > group we need  LCAS to remove it before we
> actually
> > tear down the component connection via GMPLS.
>
> So it seems to me that you have decided that LCAS is
> a GMPLS application.
> That is, LCAS is an end-to-end protocol that
> triggers the establishment of
> LSPs by making requests to GMPLS.
>
> This sounds reasonable, but please write it up.
>
> > Now the thing that seems a bit tricky to me about
> (3)
> > and (4) is that LCAS does things unidirectionally,
> in
> > the sense of adding/removing components, (not in
> the
> > sense of a protocol which has a handshake
> mechanism).
> > All add or remove commands come from the source
> end
> > and since we generally setup/teardown
> bi-directional
> > connections that would leave us with a bit of
> > coordination.  Is this what you are thinking
> Diego?
> > LCAS experts chime in too :-)
>
> Nothing to stop you having unidirectional LSPs if
> you need to support a
> service that controls LSPs in a unidirectional way.
>
> Cheers,
> Adrian
>
>




__________________________________
Discover Yahoo!
Get on-the-go sports scores, stock quotes, news and more. Check it out!
http://discover.yahoo.com/mobile.html









Envelope-to: [e-mail]
Delivery-date: Tue, 14 Jun 2005 13:25:55 +0000
Message-ID: <0d3e01c570e4$a29a4200$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>, "Diego Caviglia" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Tue, 14 Jun 2005 14:22:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Greg,

Let me come in a bit heavy here, please.


> Hi all, thanks for the update Diego and Adrian. Where
> we stand seems to be:
> (1) We've got an agreed method using the Call_ID to
> identify (VC-3/VC-4) component belonging to a VCAT
> group. In particular, the Call_ID along with source
> and destination addresses uniquely identifies the VCAT
> group in the network?

No. We do not have agreement on this.
We have a vague statement of requirements that a group of LSPs need to be
associated. Until we see the requirements fleshed out and written up it
would be wrong to pick one solution. For example, we have an Association
object that is part of mainstream GMPLS that could be used for this
purpose.

So, let's see the requirements written up, please.

> (2) I can use GMPLS to setup/tear down one or more
> VCAT group components at a time. (we've had this for a
> while).
> (3) Once we set up via GMPLS a new component
> (VC-3/VC-4) of a VCAT group we want LCAS to hitlessly
> add the new component to the group.
> (4) To remove (hitlessly) the component from the VCAT
> group we need  LCAS to remove it before we actually
> tear down the component connection via GMPLS.

So it seems to me that you have decided that LCAS is a GMPLS application.
That is, LCAS is an end-to-end protocol that triggers the establishment of
LSPs by making requests to GMPLS.

This sounds reasonable, but please write it up.

> Now the thing that seems a bit tricky to me about (3)
> and (4) is that LCAS does things unidirectionally, in
> the sense of adding/removing components, (not in the
> sense of a protocol which has a handshake mechanism).
> All add or remove commands come from the source end
> and since we generally setup/teardown bi-directional
> connections that would leave us with a bit of
> coordination.  Is this what you are thinking Diego?
> LCAS experts chime in too :-)

Nothing to stop you having unidirectional LSPs if you need to support a
service that controls LSPs in a unidirectional way.

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 13 Jun 2005 22:57:13 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IvAWRCpIBPtp9CecYICvrclkuSmBJmwbRQOVLtqJMVmIhtMNzu2ug5e9rWga8BiEycVix1MKQYu3aHegXUFwEgw5pBrkbSJ4yBydH47fPRBvwgx/3NdfjAW6MiJyFMIRnYDc3sl4OFmpwKMBtFNkSbLBIB4vEfv9J3D0kFl4uc0=  ;
Message-ID: <[e-mail]>
Date: Mon, 13 Jun 2005 15:54:24 -0700 (PDT)
From: Greg Bernstein <[e-mail]>
Subject: Re: LCAS and GMPLS
To: Diego Caviglia <[e-mail]>, Adrian Farrel <[e-mail]>
Cc: "<yhwkim" <[e-mail]>, "ccamp <ccamp" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi all, thanks for the update Diego and Adrian. Where
we stand seems to be:
(1) We've got an agreed method using the Call_ID to
identify (VC-3/VC-4) component belonging to a VCAT
group. In particular, the Call_ID along with source
and destination addresses uniquely identifies the VCAT
group in the network?
(2) I can use GMPLS to setup/tear down one or more
VCAT group components at a time. (we've had this for a
while).
(3) Once we set up via GMPLS a new component
(VC-3/VC-4) of a VCAT group we want LCAS to hitlessly
add the new component to the group.
(4) To remove (hitlessly) the component from the VCAT
group we need  LCAS to remove it before we actually
tear down the component connection via GMPLS.

Now the thing that seems a bit tricky to me about (3)
and (4) is that LCAS does things unidirectionally, in
the sense of adding/removing components, (not in the
sense of a protocol which has a handshake mechanism). 
All add or remove commands come from the source end
and since we generally setup/teardown bi-directional
connections that would leave us with a bit of
coordination.  Is this what you are thinking Diego?
LCAS experts chime in too :-)

Greg B.

--- Diego Caviglia <[e-mail]> wrote:

> Hi Adrian,
>                   IMHO the requirement are two
> 1       identify a set of LSPs as part of the same
> service 
> 2       transport end2end the information that the
> LCAS protocol has to be 
> enabled on tail end node 
> 
> Requirement 1 can be accomplished with Call_ID wile
> LCAS information can 
> be encoded in the Profile field of the SENDER_TSPEC.
> 
> That is my view.
> 
> BR
> 
> Diego
> 
> 
> Please respond to "Adrian Farrel"
> <[e-mail]>
> To:     "Greg Bernstein <gregbern", "Diego Caviglia"
> <[e-mail]>
> cc:     <[e-mail]>, "ccamp"
> <[e-mail]> 
> 
> Subject:        Re: LCAS and GMPLS
> 
> Hi,
> 
> In answer to Greg, I think this didn't go further
> because we are waiting
> for a clarification of the requirements.
> 
> It sounds to me (from the proposed solutions!!!)
> that the requirements
> placed on signaling may be quite light. But I would
> prefer to see a
> statement of what these are before thinking too much
> about what the
> solution might be.
> 
> Are LSPs modified through LCAS, or are LSPs added
> and deleted to support
> modifications in the required service?
> 
> Thanks,
> Adrian
> 
> ----- Original Message ----- 
> From: "Diego Caviglia" <[e-mail]>
> To: "Greg Bernstein <gregbern" <[e-mail]>
> Cc: <[e-mail]>; "ccamp"
> <[e-mail]>
> Sent: Monday, June 13, 2005 5:20 AM
> Subject: Re: LCAS and GMPLS
> 
> 
> >
> > Hi Greg,
> >                the idea I've in mind in order to
> identify the various
> VCAT
> > LSPs that are part of the same VCAT group is usage
> of CALL_ID (class-num
> > 230) object.  That is the Call_Id identifies the
> 'service' provided to
> the
> > customer that is in this case is a VCAT set of
> LSPs with LCAS.  Every
> > member of the set id identified as usual.
> >
> > Call_Id is an ITU-T (G.7713.2) object that has
> been 'accepted' by IETF
> with
> > RFC 3474.
> >
> > BR
> >
> > Diego
> >
> >
> >
> > Greg Bernstein <[e-mail]> on 10/06/2005
> 17.37.00
> >
> > To:    Diego Caviglia
> <[e-mail]>, [e-mail]
> > cc:
> >
> > Subject:    Re: LCAS and GMPLS
> >
> > Hi Diego et. al. agree that this is part of the
> > important topic on control of VCAT groups but I
> can't
> > remember why this didn't go further.  Is the
> > identification of separately routed VCAT
> components
> > resolved? I.e., those belonging to the same group
> but
> > disjointly routed. (We needed an identifier for
> the
> > VCAT group somewhere in the signaling message).
> >
> > Adrian or Lyndon do you recall?
> >
> > Greg B.
> > --- Diego Caviglia <[e-mail]>
> wrote:
> >
> > > Hi all,
> > >         I'd like to ask what is the statuts of
> the
> > > interworking between
> > > LCAS and GMPLS.  Surfing the net I've found a
> couple
> > > of ID about that
> > > subject
> (draft-kim-ccamp-intercaction-grsvpte-lcas
> > > and
> > > draft-mannie-ccamp-gmpls-tdm-lbm) but both of
> them
> > > seems to be expired,
> > > I've also found some interesting discussion on
> this
> > > matter on the ccamp
> > > mail archive.
> > >
> > > Is interwoking between LCAS and GMPLS outside
> the
> > > scope of CCAMP?
> > >
> > > IMHO that is not and should be addressed.
> > >
> > > What is the feeling of the rest of the group?
> > >
> > > Best regards
> > >
> > > Diego
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > __________________________________
> > Discover Yahoo!
> > Have fun online with music videos, cool games, IM
> and more. Check it
> out!
> > http://discover.yahoo.com/online.html
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 



		
__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html



Envelope-to: [e-mail]
Delivery-date: Mon, 13 Jun 2005 18:15:02 +0000
MIME-Version: 1.0
Sensitivity: 
To: "Adrian Farrel" <[e-mail]>
Cc: "<yhwkim" <[e-mail]>, ""ccamp" <ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 13 Jun 2005 20:13:36 +0200
Content-Type: multipart/alternative; boundary="=_alternative 00643619C125701F_="

This is a multipart message in MIME format.
--=_alternative 00643619C125701F_=
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,
                  IMHO the requirement are two
1       identify a set of LSPs as part of the same service 
2       transport end2end the information that the LCAS protocol has to be 
enabled on tail end node 

Requirement 1 can be accomplished with Call_ID wile LCAS information can 
be encoded in the Profile field of the SENDER_TSPEC.

That is my view.

BR

Diego


Please respond to "Adrian Farrel" <[e-mail]>
To:     "Greg Bernstein <gregbern", "Diego Caviglia" <[e-mail]>
cc:     <[e-mail]>, "ccamp" <[e-mail]> 

Subject:        Re: LCAS and GMPLS

Hi,

In answer to Greg, I think this didn't go further because we are waiting
for a clarification of the requirements.

It sounds to me (from the proposed solutions!!!) that the requirements
placed on signaling may be quite light. But I would prefer to see a
statement of what these are before thinking too much about what the
solution might be.

Are LSPs modified through LCAS, or are LSPs added and deleted to support
modifications in the required service?

Thanks,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: "Greg Bernstein <gregbern" <[e-mail]>
Cc: <[e-mail]>; "ccamp" <[e-mail]>
Sent: Monday, June 13, 2005 5:20 AM
Subject: Re: LCAS and GMPLS


>
> Hi Greg,
>                the idea I've in mind in order to identify the various
VCAT
> LSPs that are part of the same VCAT group is usage of CALL_ID (class-num
> 230) object.  That is the Call_Id identifies the 'service' provided to
the
> customer that is in this case is a VCAT set of LSPs with LCAS.  Every
> member of the set id identified as usual.
>
> Call_Id is an ITU-T (G.7713.2) object that has been 'accepted' by IETF
with
> RFC 3474.
>
> BR
>
> Diego
>
>
>
> Greg Bernstein <[e-mail]> on 10/06/2005 17.37.00
>
> To:    Diego Caviglia <[e-mail]>, [e-mail]
> cc:
>
> Subject:    Re: LCAS and GMPLS
>
> Hi Diego et. al. agree that this is part of the
> important topic on control of VCAT groups but I can't
> remember why this didn't go further.  Is the
> identification of separately routed VCAT components
> resolved? I.e., those belonging to the same group but
> disjointly routed. (We needed an identifier for the
> VCAT group somewhere in the signaling message).
>
> Adrian or Lyndon do you recall?
>
> Greg B.
> --- Diego Caviglia <[e-mail]> wrote:
>
> > Hi all,
> >         I'd like to ask what is the statuts of the
> > interworking between
> > LCAS and GMPLS.  Surfing the net I've found a couple
> > of ID about that
> > subject (draft-kim-ccamp-intercaction-grsvpte-lcas
> > and
> > draft-mannie-ccamp-gmpls-tdm-lbm) but both of them
> > seems to be expired,
> > I've also found some interesting discussion on this
> > matter on the ccamp
> > mail archive.
> >
> > Is interwoking between LCAS and GMPLS outside the
> > scope of CCAMP?
> >
> > IMHO that is not and should be addressed.
> >
> > What is the feeling of the rest of the group?
> >
> > Best regards
> >
> > Diego
> >
> >
> >
> >
>
>
>
>
> __________________________________
> Discover Yahoo!
> Have fun online with music videos, cool games, IM and more. Check it
out!
> http://discover.yahoo.com/online.html
>
>
>
>
>
>
>
>
>





--=_alternative 00643619C125701F_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 color=blue face="Times New Roman">Hi Adrian,</font>
<br><font size=3 color=blue face="Times New Roman">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; IMHO the requirement are two</font>
<br><font size=3 color=blue face="Times New Roman">1 &nbsp; &nbsp; &nbsp; &nbsp;identify a set of LSPs as part of the same service </font>
<br><font size=3 color=blue face="Times New Roman">2 &nbsp; &nbsp; &nbsp; &nbsp;transport end2end the information that the LCAS protocol has to be enabled on tail end node </font>
<br>
<br><font size=3 color=blue face="Times New Roman">Requirement 1 can be accomplished with Call_ID wile LCAS information can be encoded in the Profile field of the SENDER_TSPEC.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">That is my view.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">BR</font>
<br>
<br><font size=3 color=blue face="Times New Roman">Diego</font>
<br>
<br>
<p><font size=1 color=#800080 face="sans-serif">Please respond to &quot;Adrian Farrel&quot; &lt;[e-mail]&gt;</font>
<p><font size=1 color=#800080 face="sans-serif">To: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">&quot;Greg Bernstein &lt;gregbern&quot;, &quot;Diego Caviglia&quot; &lt;[e-mail]&gt;</font>
<br><font size=1 color=#800080 face="sans-serif">cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">&lt;[e-mail]&gt;, &quot;ccamp&quot; &lt;[e-mail]&gt;</font><font size=1 color=#800080 face="sans-serif"> </font>
<br>
<br><font size=1 color=#800080 face="sans-serif">Subject: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">Re: LCAS and GMPLS</font>
<br>
<br><font size=2 face="Courier New">Hi,<br>
<br>
In answer to Greg, I think this didn't go further because we are waiting<br>
for a clarification of the requirements.<br>
<br>
It sounds to me (from the proposed solutions!!!) that the requirements<br>
placed on signaling may be quite light. But I would prefer to see a<br>
statement of what these are before thinking too much about what the<br>
solution might be.<br>
<br>
Are LSPs modified through LCAS, or are LSPs added and deleted to support<br>
modifications in the required service?<br>
<br>
Thanks,<br>
Adrian<br>
<br>
----- Original Message ----- <br>
From: &quot;Diego Caviglia&quot; &lt;[e-mail]&gt;<br>
To: &quot;Greg Bernstein &lt;gregbern&quot; &lt;[e-mail]&gt;<br>
Cc: &lt;[e-mail]&gt;; &quot;ccamp&quot; &lt;[e-mail]&gt;<br>
Sent: Monday, June 13, 2005 5:20 AM<br>
Subject: Re: LCAS and GMPLS<br>
<br>
<br>
&gt;<br>
&gt; Hi Greg,<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the idea I've in mind in order to identify the various<br>
VCAT<br>
&gt; LSPs that are part of the same VCAT group is usage of CALL_ID (class-num<br>
&gt; 230) object. &nbsp;That is the Call_Id identifies the 'service' provided to<br>
the<br>
&gt; customer that is in this case is a VCAT set of LSPs with LCAS. &nbsp;Every<br>
&gt; member of the set id identified as usual.<br>
&gt;<br>
&gt; Call_Id is an ITU-T (G.7713.2) object that has been 'accepted' by IETF<br>
with<br>
&gt; RFC 3474.<br>
&gt;<br>
&gt; BR<br>
&gt;<br>
&gt; Diego<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Greg Bernstein &lt;[e-mail]&gt; on 10/06/2005 17.37.00<br>
&gt;<br>
&gt; To: &nbsp; &nbsp;Diego Caviglia &lt;[e-mail]&gt;, [e-mail]<br>
&gt; cc:<br>
&gt;<br>
&gt; Subject: &nbsp; &nbsp;Re: LCAS and GMPLS<br>
&gt;<br>
&gt; Hi Diego et. al. agree that this is part of the<br>
&gt; important topic on control of VCAT groups but I can't<br>
&gt; remember why this didn't go further. &nbsp;Is the<br>
&gt; identification of separately routed VCAT components<br>
&gt; resolved? I.e., those belonging to the same group but<br>
&gt; disjointly routed. (We needed an identifier for the<br>
&gt; VCAT group somewhere in the signaling message).<br>
&gt;<br>
&gt; Adrian or Lyndon do you recall?<br>
&gt;<br>
&gt; Greg B.<br>
&gt; --- Diego Caviglia &lt;[e-mail]&gt; wrote:<br>
&gt;<br>
&gt; &gt; Hi all,<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; I'd like to ask what is the statuts of the<br>
&gt; &gt; interworking between<br>
&gt; &gt; LCAS and GMPLS. &nbsp;Surfing the net I've found a couple<br>
&gt; &gt; of ID about that<br>
&gt; &gt; subject (draft-kim-ccamp-intercaction-grsvpte-lcas<br>
&gt; &gt; and<br>
&gt; &gt; draft-mannie-ccamp-gmpls-tdm-lbm) but both of them<br>
&gt; &gt; seems to be expired,<br>
&gt; &gt; I've also found some interesting discussion on this<br>
&gt; &gt; matter on the ccamp<br>
&gt; &gt; mail archive.<br>
&gt; &gt;<br>
&gt; &gt; Is interwoking between LCAS and GMPLS outside the<br>
&gt; &gt; scope of CCAMP?<br>
&gt; &gt;<br>
&gt; &gt; IMHO that is not and should be addressed.<br>
&gt; &gt;<br>
&gt; &gt; What is the feeling of the rest of the group?<br>
&gt; &gt;<br>
&gt; &gt; Best regards<br>
&gt; &gt;<br>
&gt; &gt; Diego<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; __________________________________<br>
&gt; Discover Yahoo!<br>
&gt; Have fun online with music videos, cool games, IM and more. Check it<br>
out!<br>
&gt; http://discover.yahoo.com/online.html<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
</font>
<br>
<p>
<p>
--=_alternative 00643619C125701F_=--



Envelope-to: [e-mail]
Delivery-date: Mon, 13 Jun 2005 17:50:51 +0000
Message-ID: <0ca801c57040$83275ce0$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Greg Bernstein <gregbern" <[e-mail]>, "Diego Caviglia" <[e-mail]>
Cc: <[e-mail]>, "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Mon, 13 Jun 2005 18:44:36 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

In answer to Greg, I think this didn't go further because we are waiting
for a clarification of the requirements.

It sounds to me (from the proposed solutions!!!) that the requirements
placed on signaling may be quite light. But I would prefer to see a
statement of what these are before thinking too much about what the
solution might be.

Are LSPs modified through LCAS, or are LSPs added and deleted to support
modifications in the required service?

Thanks,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: "Greg Bernstein <gregbern" <[e-mail]>
Cc: <[e-mail]>; "ccamp" <[e-mail]>
Sent: Monday, June 13, 2005 5:20 AM
Subject: Re: LCAS and GMPLS


>
> Hi Greg,
>                the idea I've in mind in order to identify the various
VCAT
> LSPs that are part of the same VCAT group is usage of CALL_ID (class-num
> 230) object.  That is the Call_Id identifies the 'service' provided to
the
> customer that is in this case is a VCAT set of LSPs with LCAS.  Every
> member of the set id identified as usual.
>
> Call_Id is an ITU-T (G.7713.2) object that has been 'accepted' by IETF
with
> RFC 3474.
>
> BR
>
> Diego
>
>
>
> Greg Bernstein <[e-mail]> on 10/06/2005 17.37.00
>
> To:    Diego Caviglia <[e-mail]>, [e-mail]
> cc:
>
> Subject:    Re: LCAS and GMPLS
>
> Hi Diego et. al. agree that this is part of the
> important topic on control of VCAT groups but I can't
> remember why this didn't go further.  Is the
> identification of separately routed VCAT components
> resolved? I.e., those belonging to the same group but
> disjointly routed. (We needed an identifier for the
> VCAT group somewhere in the signaling message).
>
> Adrian or Lyndon do you recall?
>
> Greg B.
> --- Diego Caviglia <[e-mail]> wrote:
>
> > Hi all,
> >         I'd like to ask what is the statuts of the
> > interworking between
> > LCAS and GMPLS.  Surfing the net I've found a couple
> > of ID about that
> > subject (draft-kim-ccamp-intercaction-grsvpte-lcas
> > and
> > draft-mannie-ccamp-gmpls-tdm-lbm) but both of them
> > seems to be expired,
> > I've also found some interesting discussion on this
> > matter on the ccamp
> > mail archive.
> >
> > Is interwoking between LCAS and GMPLS outside the
> > scope of CCAMP?
> >
> > IMHO that is not and should be addressed.
> >
> > What is the feeling of the rest of the group?
> >
> > Best regards
> >
> > Diego
> >
> >
> >
> >
>
>
>
>
> __________________________________
> Discover Yahoo!
> Have fun online with music videos, cool games, IM and more. Check it
out!
> http://discover.yahoo.com/online.html
>
>
>
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Mon, 13 Jun 2005 08:05:00 +0000
Sensitivity: 
Subject: Re: LCAS and GMPLS
To: "Greg Bernstein <gregbern" <[e-mail]>
Cc: [e-mail], "ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 13 Jun 2005 06:20:12 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Greg,
               the idea I've in mind in order to identify the various VCAT
LSPs that are part of the same VCAT group is usage of CALL_ID (class-num
230) object.  That is the Call_Id identifies the 'service' provided to the
customer that is in this case is a VCAT set of LSPs with LCAS.  Every
member of the set id identified as usual.

Call_Id is an ITU-T (G.7713.2) object that has been 'accepted' by IETF with
RFC 3474.

BR

Diego



Greg Bernstein <[e-mail]> on 10/06/2005 17.37.00

To:    Diego Caviglia <[e-mail]>, [e-mail]
cc:

Subject:    Re: LCAS and GMPLS

Hi Diego et. al. agree that this is part of the
important topic on control of VCAT groups but I can't
remember why this didn't go further.  Is the
identification of separately routed VCAT components
resolved? I.e., those belonging to the same group but
disjointly routed. (We needed an identifier for the
VCAT group somewhere in the signaling message).

Adrian or Lyndon do you recall?

Greg B.
--- Diego Caviglia <[e-mail]> wrote:

> Hi all,
>         I'd like to ask what is the statuts of the
> interworking between
> LCAS and GMPLS.  Surfing the net I've found a couple
> of ID about that
> subject (draft-kim-ccamp-intercaction-grsvpte-lcas
> and
> draft-mannie-ccamp-gmpls-tdm-lbm) but both of them
> seems to be expired,
> I've also found some interesting discussion on this
> matter on the ccamp
> mail archive.
>
> Is interwoking between LCAS and GMPLS outside the
> scope of CCAMP?
>
> IMHO that is not and should be addressed.
>
> What is the feeling of the rest of the group?
>
> Best regards
>
> Diego
>
>
>
>




__________________________________
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/online.html









Envelope-to: [e-mail]
Delivery-date: Fri, 10 Jun 2005 15:38:35 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lR7z3QiWUEsmCmZZKsQ4rQqeqGCfb9DGdNW5fN3ECEn3Nkj8/HGk6vvFHUWrTydoYQ8yD1QwPuKo25XWYFcMmPHoZZRwkjS/eIXDuZf2dUEEfTn6SRXkmSQ2d9q5kiSZG8ggfbvyZbGCUKLmThXCHyJ4Lt6ZgwDslFSWXJZ+/3I=  ;
Message-ID: <[e-mail]>
Date: Fri, 10 Jun 2005 08:37:00 -0700 (PDT)
From: Greg Bernstein <[e-mail]>
Subject: Re: LCAS and GMPLS
To: Diego Caviglia <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi Diego et. al. agree that this is part of the
important topic on control of VCAT groups but I can't
remember why this didn't go further.  Is the
identification of separately routed VCAT components
resolved? I.e., those belonging to the same group but
disjointly routed. (We needed an identifier for the
VCAT group somewhere in the signaling message).

Adrian or Lyndon do you recall?

Greg B.
--- Diego Caviglia <[e-mail]> wrote:

> Hi all,
>         I'd like to ask what is the statuts of the
> interworking between
> LCAS and GMPLS.  Surfing the net I've found a couple
> of ID about that
> subject (draft-kim-ccamp-intercaction-grsvpte-lcas
> and
> draft-mannie-ccamp-gmpls-tdm-lbm) but both of them
> seems to be expired,
> I've also found some interesting discussion on this
> matter on the ccamp
> mail archive.
> 
> Is interwoking between LCAS and GMPLS outside the
> scope of CCAMP?
> 
> IMHO that is not and should be addressed.
> 
> What is the feeling of the rest of the group?
> 
> Best regards
> 
> Diego
> 
> 
> 
> 



		
__________________________________ 
Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html



Envelope-to: [e-mail]
Delivery-date: Fri, 10 Jun 2005 11:34:35 +0000
Message-ID: <060501c56db0$545fe6d0$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France 
Date: Fri, 10 Jun 2005 12:22:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

For your information
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Friday, June 10, 2005 5:00 AM
Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting
in Paris, France


>
> There are two (2) Internet-Draft cutoff dates for the 63rd
> IETF Meeting in Paris, France:
>
> July 11th: Cutoff Date for Initial (i.e., version -00)
> Internet-Draft Submissions
>
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> July 11th at 9:00 AM ET. As always, all initial submissions with a
> filename beginning with "draft-ietf" must be approved by the
> appropriate WG Chair before they can be processed or announced.  The
> Secretariat would appreciate receiving WG Chair approval by Tuesday,
> July 5th at 9:00 AM ET.
>
> July 18th: Cutoff Date for Revised (i.e., version -01 and higher)
> Internet-Draft Submissions
>
> All revised Internet-Drafts (version -01 and higher) must be submitted
> by Monday, July 18th at 9:00 AM ET.
>
> Initial and revised Internet-Drafts received after their respective
> cutoff dates will not be made available in the Internet-Drafts
> directory or announced until on or after Monday, August 1st at 9:00
> AM ET, when Internet-Draft posting resumes.  Please do not wait until
> the last minute to submit.
>
> PLEASE NOTE THE CHANGE OF PROCEDURE:  If you submit an initial or
> revised Internet-Draft after their respective cutoff deadlines, then
> your document will be retained and posted when Internet-Draft
> processing resumes.  You will no longer be required to resubmit the
> document.
>
> Thank you for your understanding and cooperation. If you have any
> questions or concerns, then please send a message to
> [e-mail].
>
> The IETF Secretariat
>
> FYI: The Internet-Draft cutoff dates as well as other significant dates
> for the 63rd IETF Meeting can be found at
http://www.ietf.org/meetings/cutoff_dates_63.html.
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Jun 2005 17:12:44 +0000
Sensitivity: 
Subject: Re: A Design Team for Layer Two Switching
To: "Adrian Farrel" <[e-mail]>
Cc: "<ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Tue, 7 Jun 2005 19:11:55 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Adrian,
        I'd like to see stressed expecially the following point of your
list

- state that MPLS over Ethernet is not the same thing

May be could be useful to explain why a Network Operator should prefer
GMPLS control for L2 instead MPLS.

Hope this helps

Diego



"Adrian Farrel" <[e-mail]>@ops.ietf.org on 07/06/2005 13.40.08

Please respond to "Adrian Farrel" <[e-mail]>

Sent by:    [e-mail]


To:    <[e-mail]>
cc:

Subject:    A Design Team for Layer Two Switching


Hi,

In Minneapolis there was some discussion about solutions for layer two
switching and in particular for GMPLS control of Ethernet devices.

After much discussion backwards and forwards I am setting up a team to
develop a framework and the basic requirements. Their charter (which
limits their scope quite tightly) is found below. Please help them and
look forward to reviewing their output in Paris.

Thanks,
Adrian

========
Charter for the CCAMP Layer 2 Ethernet Design Team

    GMPLS signaling and routing is applicable to Layer 2.
    However, up to now, very little attention has been given to the
    control of Ethernet switches using GMPLS protocols.

    This Design Team is chartered to start the work of applying
    GMPLS to Ethernet devices by developing a framework draft that
    covers possible deployment scenarios, identifies the consequent
    requirements, and highlights possible interactions with other
    SDOs.

    The sole objective of the Design Team is to produce this
    framework draft which should be around 10 pages in length.
    Solutions work is out of scope at this time.

    The draft will be ready for discussion at the Paris IETF.

    The Design Team members are as follows...

    - Dimitri Papadimitriou (Team Lead and Editor)
      [e-mail]
    - Jaihyung Cho (Co-Editor)
      [e-mail]
    - Loa Andersson
      [e-mail]
    - Arthi Ayyangar
      [e-mail]
    - Anders Gavler
      [e-mail]
    - Martin Vigoureux
      [e-mail]
    - Deborah Brungard
      [e-mail]
    - Simon Delord
      [e-mail]
    - Avri Doria
      [e-mail]
    - Tomohiro Otani
      [e-mail]
    - Jean-Louis Le Roux
      [e-mail]

Standard design team disclaimer: this design team has no special
status in the CCAMP WG. Any document produced is subject to the usual WG
procedures. Individuals are encouraged to interact with the design team,
to offer suggestions and, if they feel so inclined, to submit their own
drafts.

===

Suggested contents of framework I-D (fully open for revision)
- half page introduction
   - what does GMPLS currently do
   - L2 switching is in scope
   - Ethernet not previously examined
   - state that MPLS over Ethernet is not the same thing
- half page overview of the objectives
- four pages of figures and deployment scenarios
- two pages of requirements (just brief statements)
   - which nodes participate in signaling and routing?
   - what needs to be labeled?
       - don't get sucked into *how* to label anything
   - any scoping requirements for labels
   - is link discovery needed?
   - what needs to be advertised in routing?
   - etc.
   Each requirement should note which scenarios do/don't
   depend on the requirement
- half page to reference other SDOs (I think IEEE and ITU-T SG15)
- half page on security implications of control of Ethernet

===









Envelope-to: [e-mail]
Delivery-date: Tue, 07 Jun 2005 16:54:30 +0000
Message-ID: <017701c56b81$b7b98870$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Follow-up on L2SC design team
Date: Tue, 7 Jun 2005 17:51:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

In an unusual turn of events, everyone in CCAMP appears to be interested
in contributing to some work!

I have had a variety of emails from people offering to contribute to the
efforts of the Design Team and also asking detailed questions about
exactly what the functions at issue are. This is a generic response.

1. Design Team Membership

While I welcome everyone's involvement in this debate, I think that the
current design team is already too big. The team is chartered to produce a
10 page I-D. Given considerations of boilerplate etc., that means that
each DT member is responsible for only one page of text.

What I would prefer is that the team produces a draft that we can all
discuss on the mailing list and face-to-face in Paris. The objective of
the DT is not to arrive at a perfect and complete draft before they
discuss it with anyone else.

Thus, I'd like to thank you all for wanting to help out, and encourage you
to contact the DT direct if you believe you have something specific to
offer, but I would suggest that the main time for your input is:
- when the DT publishes a draft
- when solutions work is needed.

2. What's It All About?

This is a very good question. The CCAMP chairs felt that even with the
existence of Dimitri's I-D and his slides from Minneapolis, there was not
enough of a clear statement of what was being attempted. The main reason
why the DT exists is to try to write down and reach agreement on exactly
this point.

It is quite possible that once the DT has produced a draft there will be a
hot debate (on the CCAMP list) about what they have suggested and whether
it is correct, reasonable, realistic, and so forth.

Unfortunately, until then, I can't give you any answers.


Hope that helps.
Adrian





Envelope-to: [e-mail]
Delivery-date: Tue, 07 Jun 2005 14:04:42 +0000
Sensitivity: 
Subject: Re: Review of draft-caviglia-mp2cpcp2mp-01.txt
To: "Adrian Farrel" <[e-mail]>
Cc: "<ccamp" <[e-mail]>, "<dino.bramanti" <[e-mail]>, "<n.ciulli" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Tue, 7 Jun 2005 16:02:53 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Adrian,
           thank you for your valuable comments.

We'll take them in consideration reviewing the ID, hopefully we'll be able
to present it to Paris if there room for that.

Best Regards

Diego
         
         
         





"Adrian Farrel" <[e-mail]> on 04/06/2005 14.28.37

Please respond to "Adrian Farrel" <[e-mail]>

To:    "Diego Caviglia" <[e-mail]>
cc:    <[e-mail]>, <[e-mail]>,
       <[e-mail]>

Subject:    Review of draft-caviglia-mp2cpcp2mp-01.txt


Hi Diego,

I have had a look through your I-D and have a few comments attached.

This could be a nice and useful little function requiring only a very
short document and just one bit on the wire. Excellent!

Wrt your proposed solution, I think it is nearly there, but needs a few
tweaks and there are still a couple of areas to complete.

You also really need to do some work on the English. I known this is hard
(you write better English than I write Italian!), but in order that the
document can be properly reviewed (and hopefully implemented one day) we
have to improve the use of language. What I suggest is that you make the
revisions necessary for the next version and then you get someone to
review the document just to polish the language. I'm sure there would be
volunteers to work with you on this.

Regards,
Adrian

===========

Network Working Group                                     Diego Caviglia
IETF Internet Draft                                              Marconi
Proposed Status: Informational

## Why do you propose this as Informational? Do you not want it to be
## standardized?
## you may even want to flag it as "Updates RFC 3473"

Expires: August 2005                                       Dino Bramanti
                                                                 Marconi

                                                           Nicola Ciulli
                                                               Nextworks

                                                           February 2005

        GRSVP-TE signaling extension for LSP ownership handover from
             Management Plane to Control Plane and vice versa.

## I would prefer the title to be...
## GMPLS Signaling Extensions for the Transfer of Ownership of Label
## Switched Paths Between the Management and Control Planes

                     draft-caviglia-mp2cpcp2mp-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667. By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.
## You'll need to fix this boilerplate before you republish.
## Don't forget to run the idnis script found at
## http://ietf.levkowetz.com/tools/idnits/

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2005). All Rights Reserved.

Abstract

   This memo introduces a new flag in the Administrative Status object,
   namely the "Handover" flag, and defines its use within GRSVP-TE
   signaling.  This flag SHOULD be used in order to allow LSPs,
   originally created and controlled by the Management Plane (MP), to be
   transferred to Control Plane (CP) domain and vice-versa. The result

Caviglia et al.           Expires - August 2005               [Page 1]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   of the Handover flag use in GRSVP-TE is that, at the end of the
   setup signaling flow, an LSP that was created thru Management Plane
   operations is moved under Control Plane domain and control.
   Conversely, at the end of a deletion procedure, the LSP that was
   under the Control Plane domain is moved back to the Management Plane
   domain.
   Both the above procedure are not traffic affecting and can be
   performed with "in service traffic".

## It is normal for the Abstract to talk about the problem and the desired
## function rather than solutions.
##
## So you should rephrase this along the lines of...
##
## During migration scenarios it may be desirable to transfer the
## ownership of a Label Switched Path (LSP) from the Management Plane
## to the Control Plane, or vice versa. If the LSP is carrying traffic
## this change needs to be made "in service," that is, without affecting
## traffic.
##
## This memo provides minor extensions to the Generalized Multiprotocol
## label Switching (GMPLS) signaling protocol to enable this transfer of
## ownership, and descirbes the necessary procedures.


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].


Table of Contents

   1. Introduction.....................................................2
   2. LSP Adoption/Release.............................................4
      2.1 Overview.....................................................4
      2.2 LSP Adoption phase: association of GMPLS information to a MP
          born LSP - LSP SetUp.........................................4
        2.2.1 Association Procedure....................................5
        2.2.2 Association Failure Handling.............................6
      2.3 LSP Release phase- disassociation of GMPLS information to a
          MP born, CP adopted LSP - LSP Tear Down......................7
   3. RSVP Message Formats.............................................7
      3.1 Object Modification..........................................7
        3.1.1 Administrative Status Object.............................7
   4. Security Considerations..........................................8
   5. IANA Considerations..............................................8
   6. Normative References.............................................8
   7. Informational References.........................................9
   8. Acknowledgements.................................................9
   9. Author's Addresses...............................................9
   10. Intellectual Property Rights Notices............................9
   11. Full Copyright Statement.......................................10


1. Introduction

## I think that before you start you need to explain to the reader that
## when you say "LSP" you mean the data plane forwarding path and data
## plane state. There are many people who have come to use the term
## "LSP" to mean the control plane state necessary to establish and
## maintain the data plane state - of course, you do not mean this.

## You need to expand all of the acronyms the first time they are used

   The use of a GMPLS control plane over networks that are already in
   service can't be considered of course as a green field application.
   This means that in a transport network control scenario LSPs created
   and owned by Management Plane and LSPs signaled and owned by means of
   GMPLS Control Plane have to coexist. In such a situation it is
   possible that a network operator wants to move to Control Plane an
   LSP created by and belonging to Management Plane. In a similar
   fashion, the opposite operation is also needed. In this memo let's

Caviglia et al.           Expires - August 2005               [Page 2]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   call "LSP adoption" the procedure that is aimed at moving an LSP born
   in Management Plane to Control Plane. Let's call "LSP release" the
   opposite procedure aimed at moving back the LSP from Control Plane to
   Management Plane.
## In fact, it isn't a question of where the LSP was "born" or of
## "moving back". The question is, which plane 'owns' the LSP before and
## after the operation. After all, the LSP could be moved back and
## forwards many times.
##
## I would suggest that "release" is a term already applied to LSP
## teardown, so you should choose another term.

   At present there is no way for a Carrier Operator that wants to
   associate/disassociate GMPLS information to an already existent LSP.
   In particular there is no way to inject LSP information and
   visibility from Management Plane to Control Plane (and the other way
   back) by means of standard G.RSVP-TE signaling flow.
## Please don't say G.RSVP-TE. It isn't an ITU-T G-series Recommendation
:-)

## You should explain why this does not work for the transfers in both
## directions. For example:
## If you try to signal an LSP to use resources already established and
## under the control of the Management Plane you will either be rejected
## by the network devices because the resources are already in use, or
## you will establish a second, parallel LSP.
## If you try to release an LSP established by the Control Plane by
## sending teardown signaling messages, the LSP will be lost before the
## Management Plane can take over.
##
## You should also explain why make-before-break is not an acceptable
## way to handle this situation. For example, one could have two LSPs
## (one set up by the Management Plane, and one set up by the Control
## Plane) and switch data between them (in the manner of 1+1 protection)
## with no significant hit on the traffic.

   A new flag in the Administrative Status Object (RFC 3471[3] and RFC
   3473 [4]), named Handover flag, is proposed in this memo as a mean to
   make possible necessary information exchange between GMPLS enabled
   nodes, in order to implement and support the functionality introduced
   above.

   Handover flag SHOULD be used during a signaling set-up (tear down,
   when performing opposite operation) and allows the association of
   LSP-related GMPLS information (at Control Plane level) to a circuit
   originated by Management Plane actions and formerly not visible and
   "known" to Control Plane itself. Data plane flow related to such LSP
   is unaware of this transfer of control from MP to CP (and back). It
   is worth taking into account that affected LSP may already be
   carrying traffic, which hasn't to be perturbed neither during MP to
   CP LSP handover, nor during dual CP to MP control transfer.

   The procedure here described is based (in case of MP to CP LSP
   handover, for instance) on the collection of information owned by
   Management Plane and related to a LSP originated in MP. This detailed
   information about route and resources used by the LSP is passed to
   Control Plane, which gets it to signal the LSP. When signaling the CP
   adopted LSP, Handover flag is set in order to make recognizable that
   signal flow and instruct GMPLS nodes about it.
   GMPLS nodes have to handle that LSP in such a way that, at the end of
   signaling, it is a full effect Control Plane owned LSP.
   Conversely, CP to MP migration is signaled over CP by relevant
   G.RSVP-TE tear down messages with Handover flag set.
   This is in some way similar to the Restart Procedure, (Section 4.3
   RFC 3473 [4]), in the sense that the cross connection in the Data
## "cross-connection" throughout the I-D
## The connection has nothing to be cross about :-)
   Plane are already present and it is only needed relevant GMPLS
   information to be associated to it.

   The modification proposed in this document refers only to
   Administrative Status object, that is, the message flow is left
   unmodified for both set-up and deletion.

## Most of your description discusses only cross-connections. But of
## course there is more going on in terms of resource reservation and
## resource activation (e.g. turning on lasers). You need to make sure
## that your language cover this.




Caviglia et al.           Expires - August 2005               [Page 3]

draft-caviglia-mp2cpcp2mp-02                            February 2005

2. LSP Adoption/Release

2.1 Overview

   In LSP association/release procedure here introduced, GRSVP-TE
   signaling messages and flow is used as normal and the processing of
   the messages is exactly the same as usual, except for the fact that
   no operation has to be performed over Data Plane. This means that the
   cross connection, which is assumed to be physically already in place
   in Data Plane, hasn't to be actually created (set-up phase)_ nor
   deleted (deletion phase) during signaling flow used to move LSP
   control from MP to CP (or CP to MP) .
## This is a major piece of problem statement (that the data plane
## must be unchanged, and that the resources are assumed to be
## already in place). You should move it to section 1.

   Such signaling messages are
   marked and recognizable for this purpose by Handover flag setting.
   When the LSP is adopted either by CP or MP, i.e. at the end of
   signaling with Handover flag set, normal CP procedures or MP
   procedures have to take their place as usual when needed. This means
   that a LSP originated in MP, signaled in CP with Handover flag on and
   hence passed to CP, can be deleted by usual and relevant Control
   Plane signaling flows (i.e. with Handover flag not set). The same
   applies when a LSP belongs to Management Plane. In other words, after
   those LSP handover procedures have taken place, the LSP is not
   different from the other LSP owned by handover destination entity,
   and it has to be treated with usual rules of that entity.

2.2 LSP Adoption phase: association of GMPLS information to a MP born
    LSP - LSP SetUp

   In order to support the adoption of a LSP, the ERO object in the Path
   message MUST be filled with all the LSP relevant information, that
   is, down to the Label level.  That can be done by means of the object
   and procedures defined in [5].
## You need to reference RFC3209 and RFC3473 here as well.
## But I think that component link identification has become clearer
## since the rework of the bundling I-D and you may be able to reference
## that instead of [5]. Talk to Zafar Ali about that issue.

   The filling of the ERO down to the Label Level, including Component
   Link identifier when necessary, is possible as we are assuming the
   LSP already exists in the Network and the MP has all the associated
   information. Management Plane is the entity holding LSP information
   and passing it over to CP during adoption.

   Signaling set-up related to the LSP adoption contains the Handover
   flag of the Administrative State Object set.
   Upon reception of GRSVP-TE Path with Handover flagged Admin Status
   object, i.e. during signaling set-up, a node SHOULD associate LSP
   info at CP level to the existing cross connection.

   The information about the fact that a LSP adoption procedure is
   ongoing on the LSP should be maintained by the TNE until Resv Confirm
   message is received at the node. That information is needed in case
   of failures during the association set-up.



Caviglia et al.           Expires - August 2005               [Page 4]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   Resv and Resv Confirm messages following Path (all with Handover flag
   set) are processed as usual and, after Resv Confirm processing, the
   LSP is completely under the CP domain.  This means that any memory
   about the fact that previously was under the MP is lost.

## Hmmm. You are assuming the use of the ResvConf message and I am not
## sure that that is a good idea. Why don't you continue to retain this
## information until the Handover flag is cleared?
##
## I think this would work well because, in any case, you need to
## discuss if and when the Handover flag is cleared. Note that
## Admin Status flags are not one-off triggers, but persistent state
## controllers.
##
## Clearing the Handover flag is important because until you have
## doen this, the LSP remains in 'handover state' (that is, it might
## appear to be in the process of being sent back to the MP as
## described in section 2.3) and so the CP will never have full control.
##
## This makes the rules for processing on an LSR very clear:
## When the handover bit is set in the Path state for an LSP, neither
## the CP nor the MP may make changes to the DP state or the associated
## resources. (You would probably want to allow an MP over-ride on this,
## but that is identical to the over-ride that the MP has on a CP-owned
## LSP in normal circumstances.)

   Failures during the Adoption of an LSP are managed as usual, except
   that TNEs receiving error messages, with Path State Removed set, do
   not delete the cross connection in the data plane but only their
   GMPLS associated information.
## Well, this ruling applies to all error cases and scenarios.
## That is, while the adoption process is under way (until the ResvConf,
## or clearing of the Handover bit) an LSR MUST NOT release any Data
## Plane state associated with the LSP even if it releases Control
## Plane state.

2.2.1 Association Procedure

## Can you please use RFC2119 terminology in the definition of
## procedures. This will help to remove any ambiguities.

   This Section covers the procedure needed to manage a LSP Adoption
   procedure, that is, a GRSVP-TE signaling set-up where Path message
   contain an Administrative Status object with the Handover flag set.

   In the following the adoption of a bidirectional LSP is taken into
   consideration. The case of unidirectional LSP can be easily derived
   from that.

   A node receiving a Path message containing an Administrative Status
   object with the Handover flag set is informed about the fact that a
   LSP adoption procedure is ongoing. The node assumes that a Data Plane
   connection related to the info carried in Path Message is already in
   place. The node SHOULD check however if there is an actual Data Plane
   cross connection between the resources indicated by the message:

   - If yes then a GRSVP-TE state is associated with the cross
      connection and relevant CP data structures of LSP are created.

   - If no, that is the resources are used in a way that is different
     from the one indicated by the Path message then:

     o a PathErr with Path State Removed flag set should be generated

     o GMPLS state information is deleted but actual cross-connection in
## Don't say "GMPLS state information." Say "GMPLS Control Plane state
## information."
       the data plane are not.

   In order to be able to cope with a failure during described
   procedure, the information about the fact that the ongoing signaling
   flow is concerning an LSP adoption is maintained by the TNE until the
   receipt of the Resv Confirm. In such a way Management Plane holds LSP
   related info until Handover flagged signaling session has
   successfully ended.

## The previous paragraph highlights that you need to describe (a little
## earlier in the document) how the handover procedure is coordinated
## between the MP and CP. Although the precise mechanisms are out of
## scope, we can assume that:
## - it is under operator or management applicaiton control
## - control requests are sent to the ingress LSR by the MP
## - the MP has some way of knowing when the CP has completed its task
##   or has failed.

   The following example illustrates the possible Adoption cases either
   successful or failed.




Caviglia et al.           Expires - August 2005               [Page 5]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   The cross connection to be moved under the control plane involves
   Timeslot A and B. This means that Handover flagged signaling refers
## You say "Timeslot." Does this only apply to TDM?
   to A-B xconnection over Data Plane. The symbol <----> means that the
   two Timeslots are actually cross connected over Data Plane.


          | Data Plane| Control Plane| Management Plane| Notes
   ---------------------------------------------------------------------
   Case 1 | A<---->B  | No info yet  | LSP info present| OK for MP to CP
          |           |              |                 | LSP handover
   ---------------------------------------------------------------------
   Case 2 | A<---->C  | No info yet  | LSP info present| NOK for MP to
                                                       | CP LSP handover
   ---------------------------------------------------------------------

## Perhaps instead of "LSP info present" for the MP, you should say
## "MP expects A-B".

   Case 1:
   - LSP info in Management Plane is present and describes A-B
     connection.
   - LSP is not visible yet over Control Plane.
   - A-B connection is actually present over Data Plane.
   - GRSVP-TE state (related to involved LSP) is associated to the
     cross connection after Handover flagged signaling flow
     (Path/Resv/resvConfirm with Handover flag set).
   - No actions are taken in the Data Plane.
   - At the end LSP is completely under CP control.


   Case 2:
   - LSP info in Management Plane is present and describes A-B
     connection.
   - LSP is not visible yet over Control Plane.
   - A-B connection is not actually present over Data Plane and relevant
     resources are used within other context (A is x-connected to C).
   - GRSVP-TE state (related to involved LSP) is not associated to the
     cross connection after Handover flagged signaling flow.
   - A PathErr with Path State Removed flag set should be sent Upstream.
   - No actions are taken in the Data Plane.
   - At the end LSP stays completely under MP control as before.

2.2.2 Association Failure Handling

   When a node receives a PathErr with Path State Removed checks if the
   LSP it refers to is involved in an Adoption procedure, whose track is
   kept until successful end of signaling flow has been carried on as
   stated above. If yes, then no actions are performed over the data
   plane, while GMPLS status information about involved LSP over Control
   Plane is deleted and the cross connection ownership is moved back
   under the NMS controls.



Caviglia et al.           Expires - August 2005               [Page 6]

draft-caviglia-mp2cpcp2mp-02                           February 2005

   The same applies for PathTear message.
## Ah. Very important!
## In fact, rather than limiting to the PathErr with PSR flag, and
## PathTear, why don't you say that "While the Handover flag is set in
## the Administrative Status object of the associated Path message, an
## LSR MUST NOT make changes to the data plane state (resource
## reservations, cross-connects, etc.) as the result of either Control
## Plane or Management Plane actions.

2.3 LSP Release phase- disassociation of GMPLS information to a MP born,
    CP adopted LSP - LSP Tear Down

   This Section covers the procedure needed to manage a LSP Release
   procedure (as a dual, opposite procedure respect to Adoption
   described above).

   Such a procedure is performed at a signaling level as described in
   Section 7.2.1 of the RFC 3473 [4]. LSP tear down flow is carried on
   as usual, except that Handover flag is set in Administrative Status
   Object like it was during set-up (adoption) case.
## Although this reference is correct, I think you could usefully give
## some hints. That is, explain that the procedures are the same as for
## alarm-free teardown using the Adminastrative Status object as
## described in...

   Nodes receiving G.RSVP-TE tear down messages with Handover flag set,
## No, no, no, no!
## There is no Admin Status object on a PathTear. Go back and read the
## reference you cited! What you have to do is:
##
## 1. Turn on Handover and Refelect bits in Admin Status on a Path
## 2. Wait until the Handover bit is received back in the Resv
## 3. Send PathTear to release the CP state.
## 4. Apply the same rule as above. That is:
##    While the Handover flag is set in
##    the Administrative Status object of the associated Path message,
##    an LSR MUST NOT make changes to the data plane state (resource
##    reservations, cross-connects, etc.) as the result of either
##    Control Plane or Management Plane actions.

   have to process such messages as usual, but they have to behave in a
   special way respect to Data Plane. As a perfect dual situation of the
   Adoption described before, no actions at all have to be performed
   over the data plane. This means that the node has to carry on tear
   down signaling procedure but it SHOULD NOT clear x-connection related
   to affected LSP. As a consequence of the Release only GMPLS state
   information have to be deleted.

   At the end of the Disassociation procedure the GMPLS associated
   information is deleted and the LPS is moved under the NMS control.

## You need to add sections to describe:
## - Control Plane failure and recovery during handover
## - Non-support of the handover process by transit or egress LSRs

3. RSVP Message Formats

   This memo does not introduce any modification in RSVP messages.

3.1 Object Modification

   This memo introduces a new flag into the Administrative Status
   object.

3.1.1 Administrative Status Object

## Say...
## The Admin_Status Object is defined in RFC 3473 [4].
##
## This document uses the H-bit of the Admin_Status object. The bit
## is bit number (TBD by IANA).

##### START DELETE
#  The use of the Admin_Status Object is optional.  It uses Class-Number
#  196 (of form 11bbbbbb).
#
#     The format of the Admin_Status Object is:
#
#      0                   1                   2                   3
#      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
#     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#     |            Length             | Class-Num(196)|   C-Type (1)  |
#     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#     |R|                        Reserved               |H|L|I|C|T|A|D|
#     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#
#
#Caviglia et al.           Expires - August 2005               [Page 7]
#
#draft-caviglia-mp2cpcp2mp-02                            February 2005
#
#        Reflect (R): 1 bit
#
#        When set, indicates that the edge node SHOULD reflect the
#        object/TLV back in the appropriate message.  This bit MUST NOT
#        be set in state change request, i.e., Notify, messages.
#
#        Reserved: 28 bits
#
#        This field is reserved.  It MUST be set to zero on transmission
#        and MUST be ignored on receipt.  These bits SHOULD be pass
#        through unmodified by transit nodes.
####### END DELETE

         Handover signaling (H): 1 bit

         When set, indicates that an Association/Disassociation
         procedure is ongoing.
## Why not call this the ahndover procedure?


####### START DELETE
#  The other flag are defined in the following documents:
#        R-bit   [RFC3471]
#        L-bit   [E2E]
#        I-bit   [ALARM]
#        C-bit   [ASON]
#        T-bit   [RFC3471]
#        A-bit   [RFC3471]
#        D-bit   [RFC3471]
#
#
#  Where:
#   [RFC3471]     RFC3471
#   [E2E]         draft-ietf-ccamp-gmpls-recovery-e2e-signaling
#   [ALARM]       draft-ietf-ccamp-gmpls-alarm-spec
#   [ASON]        draft-ietf-ccamp-gmpls-rsvp-te-ason
####### END DELETE

4. Security Considerations

   This document does not introduce any additional Security issues.  For
   GRSVP-TE Security please refer to [3].

## I think that the removal of an LSP from one sphere of control to
## another is a serious security issue. You need to explain this risk
## and state why it is or is not a problem.


5. IANA Consideration

   This memo introduces a new GRSVP-TE object type and a new Error Code
   Error Value couple.
##
## Hmmm? What new object type? What new error code/value?
##
## Say the following...
## 6.1 Administrative Status Bit Allocation
##
## IANA has been asked to manage the bit allocations for the
## Administrative Status object [6].
##
## This document requires the allocation of the Handover bit: the H-bit.
## IANA is requested to allocate a bit for this purpose. See section
## 3.1.1.

6. Normative References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

Caviglia et al.           Expires - August 2005               [Page 8]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   3  Berger, L., " Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Functional Description", RFC 3471, January 2003

   4  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Resource ReserVation Protocol-Traffic Engineering
      (RSVP-TE) Extensions", RFC 3473, January 2003.

7. Informational References

   5  Zamfir, A., " Component Link Recording and Resource Control for
      GMPLS Link Bundles",
      draft-zamfir-explicit-resource-control-bundle-03, February 2004.
## state "work in progress"

## 6  L. Berger (Ed.) "GMPLS - Communication of Alarm Information",
      draft-ietf-ccamp-gmpls-alarm-spec-02.txt, November 2004, work in
      progress.



8. Acknowledgements

   Adrian Farrel provided editorial assistance to prepare this draft
   for publication.


9. Author's Addresses

   Diego Caviglia
   Marconi
   Via A. Negrone 1/A
   Phone: [phone]
   Email: [e-mail]

   Dino Bramanti
   Marconi
   Via Moruzzi 1
   C/O Area Ricerca CNR, Pisa
   Email: [e-mail]

   Nicola Ciulli
   Nextworks
   Corso Italia n. 116,
   56125 Pisa (Italy)
   Email: [e-mail]

10. Intellectual Property Rights Notices

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


Caviglia et al.           Expires - August 2005               [Page 9]

draft-caviglia-mp2cpcp2mp-02                         February 2005

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   [e-mail].

11. Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and

   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

























Caviglia et al.           Expires - August 2005              [Page 10]












Envelope-to: [e-mail]
Delivery-date: Tue, 07 Jun 2005 11:54:13 +0000
Message-ID: <011d01c56b57$9dd25060$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: comments on draft-ietf-ccamp-inter-domain-framework-02.txt
Date: Tue, 7 Jun 2005 12:52:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks,

I think we are closed down on nearly all of the points.

Adrian

> >>2. introduction
> >>    "However, domains of computational responsibility may also exist
as
> >>    sub-domains of areas or ASs. Wholly or partially overlapping
domains
> >>    are not within the scope of this document."
> >>
> >>how the second sentence should be interpreted wrt to the previous one
?
>
> i would say
>
> "Wholly or partially overlapping domains (e.g. path computation
> sub-domains of areas or ASs) are not within the scope of this document."

OK

> >>6. section 2.2
> >>
> >>this notion of contiguous LSP is unclear, if i correctly understand
the
> >>definition i can not establish a contiguous packet LSP using PSC links
> >>that are themselves TDM LSPs - why this restriction ?
> >
> > The notion we are trying to convey is that there is a single LSP
> > established from ingress to egress that does not require the use of FA
> > LSPs or stitching.
>  >
> > It is true that you could use hierarchical layered LSPs as you
describe,
> > but if you were to expose this fact, you would be using nested domains
> > (which are out of scope). On the other hand, if you hide this fact (by
> > presenting the TDM LSPs as TE links in the PSC domain) then these are
just
> > TE links and there is nothing special going on.
> >
> > So...
> > We struggled with the words for section 2.2. Every time we visited the
> > text, we deleted more words.
> >
> > Any suggestions?
>
> i was mainly referring to the following sentence "Signaling occurs
> between adjacent neighbors only (no tunneling), and hop-by-hop signaling
> is used."
>
> i think the notion of contiguous LSP is to be defined as 1) LSP for
> which TE links are not represented as FA links and 2) there is no
> incoming signaling flow interruption to trigger an FA link or an LSP
segment

The main point we wanted to make was continuous use of the same
Session/LSP ID along the whole path (i.e. at every LSR) of the LSP. The
points you make are valid, but they don't quite capture what we were
trying to say.

> >>11. section 3.2.2
> >>
> >>i guess the proposed formats are not meant to be exchaustive (would be
> >>worth indicating this)
> >
> > Hmmm. I can certainly make the text more ambiguous, but these were the
> > only two formats (apart from the mixed format as indicated) that we
could
> > come up with. Do you see any further formats for this mode of
visibility?
>
> i asked this because mixing does only refers to partial visibility while
> we can assume learning systems or possibility for having full visibility
> for some domains but not for others in this case "intermediate hops" (in
> the broad sense) would not necessarily represent "domains"

OK. Understood.

> >>16. section 4
> >>
> >>would it be possible to expand on "end-point" reachability information
> >>exchanges - which is at the end the only mandatory information needed
> >>the following "Where any cross-domain reachability and TE information
> >>needs to be advertised, consideration must be given to TE extensions
to
> >>BGP, and how these may be fed to the IGPs. ..." is again focusing on
TE
> >>info processing
> >
> > I'm not sure I get your point.
>
> the sentence under discussion here is
>
> "Where any cross-domain reachability and TE information needs to be
>   advertised, consideration must be given to TE extensions to BGP, and
>   how these may be fed to the IGPs."
>
> it is important to understand what the transposition of inter-domain
> reachability provides as real information before stating we need TE
> extensions to BGP

Indeed. The text does *not* say that we need extensions to BGP. It says
that consideration must be given. That is, if there is a need to advertise
cross-domain reachability and TE information then no new mechanism should
be developed without first considering existing protocols.

Obviously (ah, but maybe it is not so obvious? - so I will add an explicit
statement) the real need for inter-domain reachability and TE informaiton
must be established before doing any work on how to distribute that
information.

> >>18. section 5.1
> >>
> >>" Note also that where multiple diverse paths are applied end-to-end
> >>    (i.e. not simply within protection domains - see section 5.5) the
> >>    point of calculation for re-optimization (whether it is PCE,
> >> ingress, or domain entry point) needs to know all such paths before
> >> attempting re-optimization of any one path."
> >>
> >>the notion of diversity is unclear in this sentence i.e. diverse from
?
> >
> > mutually-diverse
>
> ok - so you mean mutually "resource disjoint" LSP

Then we have to define "resource" :-)

I think we understand each other. I will find some words that makes the
I-D clearer.

> >>20. section 5.5
> >>
> >>would be interesting to know what is meant by "easier" in the
following
> >>sentence "The problem is generally considered to be easier and more
> >>efficient when the diverse paths can be computed 'simultaneously' on
the
> >>fullest set of information."
> >
> > Replaced with "less complex".
>
> i would simply say "The problem can be resolved more efficiently (e.g.
> avoid so called "trap problem") when mutually resource disjoint paths
> can be computed 'simultaneously' on the fullest set of information."

Thanks.

> >> it would also be interesting to know what is meant by "Domain ID" in
> >> the context of the following sentence "The former might be identified
using
> >>a combination of domain ID and an SRLG ID that is administered by the
> >>domain." in particular if SRLGs are confined within a domain adding a
> >>domain id to the SRLG ID would only be useful if SRLG id values are
not
> >>unique across domains but the latter would then be expected to share
> >>that information - is that the intention ?
> >
> > As you note, this case is intended to apply where the constituents of
the
> > SRLG are confined within a domain, but the SRLG is identified with
wider
> > scope than the domain. Thus, either we need administration of SRLG IDs
> > across domains (to make the SRLG ID unique across domains) or we need
the
> > domain ID to form part of the SRLG identification.
>
> agreed & i suggest to formalize this as part of the text even if the
> former alternative is probably difficult to achieve

OK

> >>21. Section 5.8
> >>
> >>the major issue is whether end-points are supportive of the
capability -
> >>this should be highlighted in this section
> >
> > OK
> >
> >>editorial: this document refers to TE LSP and sometimes to LSP is
there
> >>any specific different or just a contraction ? i am asking this
because
> >>in the context of a document that speaks about Traffic Engineering
this
> >>is not necessarily clear
> >
> > Right.
> > I think it is just sloppy editing.
> >
> > The intention is to indicate that we are in the realm of RSVP-TE and
not
> > LDP, so all of the LSPs are really TE LSPs.
>
> the realm of this document is source/constrain-based routing which by
> definition implies the use of a protocol that support these notions

Understood.





Envelope-to: [e-mail]
Delivery-date: Tue, 07 Jun 2005 11:54:05 +0000
Message-ID: <011c01c56b57$9cb60af0$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: A Design Team for Layer Two Switching
Date: Tue, 7 Jun 2005 12:40:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

In Minneapolis there was some discussion about solutions for layer two
switching and in particular for GMPLS control of Ethernet devices.

After much discussion backwards and forwards I am setting up a team to
develop a framework and the basic requirements. Their charter (which
limits their scope quite tightly) is found below. Please help them and
look forward to reviewing their output in Paris.

Thanks,
Adrian

========
Charter for the CCAMP Layer 2 Ethernet Design Team

    GMPLS signaling and routing is applicable to Layer 2.
    However, up to now, very little attention has been given to the
    control of Ethernet switches using GMPLS protocols.

    This Design Team is chartered to start the work of applying
    GMPLS to Ethernet devices by developing a framework draft that
    covers possible deployment scenarios, identifies the consequent
    requirements, and highlights possible interactions with other
    SDOs.

    The sole objective of the Design Team is to produce this
    framework draft which should be around 10 pages in length.
    Solutions work is out of scope at this time.

    The draft will be ready for discussion at the Paris IETF.

    The Design Team members are as follows...

    - Dimitri Papadimitriou (Team Lead and Editor)
      [e-mail]
    - Jaihyung Cho (Co-Editor)
      [e-mail]
    - Loa Andersson
      [e-mail]
    - Arthi Ayyangar
      [e-mail]
    - Anders Gavler
      [e-mail]
    - Martin Vigoureux
      [e-mail]
    - Deborah Brungard
      [e-mail]
    - Simon Delord
      [e-mail]
    - Avri Doria
      [e-mail]
    - Tomohiro Otani
      [e-mail]
    - Jean-Louis Le Roux
      [e-mail]

Standard design team disclaimer: this design team has no special
status in the CCAMP WG. Any document produced is subject to the usual WG
procedures. Individuals are encouraged to interact with the design team,
to offer suggestions and, if they feel so inclined, to submit their own
drafts.

===

Suggested contents of framework I-D (fully open for revision)
- half page introduction
   - what does GMPLS currently do
   - L2 switching is in scope
   - Ethernet not previously examined
   - state that MPLS over Ethernet is not the same thing
- half page overview of the objectives
- four pages of figures and deployment scenarios
- two pages of requirements (just brief statements)
   - which nodes participate in signaling and routing?
   - what needs to be labeled?
       - don't get sucked into *how* to label anything
   - any scoping requirements for labels
   - is link discovery needed?
   - what needs to be advertised in routing?
   - etc.
   Each requirement should note which scenarios do/don't
   depend on the requirement
- half page to reference other SDOs (I think IEEE and ITU-T SG15)
- half page on security implications of control of Ethernet

===




Envelope-to: [e-mail]
Delivery-date: Sun, 05 Jun 2005 11:29:18 +0000
Message-ID: <[e-mail]>
Date: Sun, 05 Jun 2005 13:28:06 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail],  [e-mail]
Subject: Re: comments on draft-ietf-ccamp-inter-domain-framework-02.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Adrian - some hints inside to complete this discussion

> Thanks Dimitri,
> 
> 
>>some comments on this document:
>>
>>1. introduction refers to a separate document - but without much
> 
> precision -
> 
> Hmmm. There is some difficulty in providing a list which will necessarily
> be assumed to be complete.
> 
> For the "techniques" (para 3) I propose to add a note to say that
> references to these documents are given from the sections that discuss the
> techniques.
> 
> For the case of GMPLS TE (para 4) I will add a pointer to...
>    [GMPLS-AS]    Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS
>                  Traffic Engineering Requirements",
>                  draft-otani-ccamp-interas-GMPLS-TE, work in progress.

ok

>>2. introduction
>>    "However, domains of computational responsibility may also exist as
>>    sub-domains of areas or ASs. Wholly or partially overlapping domains
>>    are not within the scope of this document."
>>
>>how the second sentence should be interpreted wrt to the previous one ?
> 
> OK, this could be clearer.
 >
> The intention is is to give examples of domains and also not constrain
> their use. But, we do want to restrict the discussion to non-nested
> domains at this point.
> 
> So, computational domains might exist within a single area. The reasons
> for such domains might be as simple as limited computation power, or
> limited computation necessity (for example on a subtended ring).
> 
> Maybe it is OK simply to delete the sentence "However, domains of ...." as
> this does not add much value.

i would say

"Wholly or partially overlapping domains (e.g. path computation 
sub-domains of areas or ASs) are not within the scope of this document."

>>3. section 2 refers to
>>
>>"Three distinct options for signaling TE LSPs across multiple domains
>>    are identified. The choice of which options to use may be influenced
>>    by the path computation technique used (see section 3), although
>> some path computation techniques may apply to multiple TE LSP types."
>>
>>what are these LSP types ? i think this document is the right place to
>>disambiguate the signaling methodology from
> 
> That final "multiple TE LSP types" should read "multiple signaling
> options"

ok

>>4. section 2.1
>>
>>"Furthermore, the mapping (inheritance rules)
>>    between attributes of the nested and FA LSPs (including bandwidth)
>>    may be statically pre-configured or, for on-demand FA LSPs, may be
>>    dynamic according to the properties of the nested LSPs."
>>
>>worth indicating here that even in the dynamic case inheritance from the
>>properties of the nested LSP(s) can be complemented by local or
>>domain-wide policy rules
>  
> OK
> 
>>5. section 2.1
>>
>>"During the operation of establishing a nested LSP that uses a
>>hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain
>>unchanged along the entire length of the nested LSP." the same applies
>>for the FILTER_SPEC object and any other object that has an end-to-end
>>significance
> 
> OK. The point we wanted to make is that the Session remains constant. This
> seems to be the most important end-to-end property. But I will extend the
> text to say "and all other objects that have end-to-end significance".
> 
>>6. section 2.2
>>
>>this notion of contiguous LSP is unclear, if i correctly understand the
>>definition i can not establish a contiguous packet LSP using PSC links
>>that are themselves TDM LSPs - why this restriction ?
> 
> The notion we are trying to convey is that there is a single LSP
> established from ingress to egress that does not require the use of FA
> LSPs or stitching.
 >
> It is true that you could use hierarchical layered LSPs as you describe,
> but if you were to expose this fact, you would be using nested domains
> (which are out of scope). On the other hand, if you hide this fact (by
> presenting the TDM LSPs as TE links in the PSC domain) then these are just
> TE links and there is nothing special going on.
> 
> So...
> We struggled with the words for section 2.2. Every time we visited the
> text, we deleted more words.
> 
> Any suggestions?

i was mainly referring to the following sentence "Signaling occurs 
between adjacent neighbors only (no tunneling), and hop-by-hop signaling 
is used."

i think the notion of contiguous LSP is to be defined as 1) LSP for 
which TE links are not represented as FA links and 2) there is no 
incoming signaling flow interruption to trigger an FA link or an LSP segment

>>7. section 2.4
>>
>>could be interesting to have better insight on RRO methods to select
>>signaling method "It may be desirable in this case for the choice of the
>>various methods to be indicated along the path perhaps through the RRO."
> 
> The intention was not to use the RRO to select the method, but to report
> the choice that was made. I have cahnged the text to read...
>    It may be desirable in this case for the choice of the
>    various methods to be reported along the path, perhaps through the
>    RRO.

ok

>>8. section 2.5
>>
>>refers to interoperability but in which sense ? object support or
>>functionality
> 
> There are two concers as you identify. It is necessary to be backwards
> compatible. But a greater concern (for me) exists with the creation of too
> many options: that is, if it is acceptable for LSRs to select which
> functional components they support, then there is a high risk of
> "stnadard" implementations not interoperating. I have clarified this in
> the text.

ok

>>9. section 3.2
>>
>>indeed the destination must be provided but i suggest to indicate the
>>corr. object(s) i.e. Session, ERO subobjects, etc.
> 
> Ni, I don't think so. The operator does not use Session, ERO or any other
> objects. The operator simply fills in information in his GUI, CLI or
> whatever.

i understand - if you refer here to the information that must be 
supplied by an external "entity" such as to construct the request then 
the source should be part of this set

>>10. section 3.2.1
>>
>>having full visibility provides the capacity to achieve optimality - at
>>least for a given period of time - in brief, it is not a sufficient
>>condition
> 
> OK.
> "is best" was the wrong choice of words.
> Changed it to "can be better".

ok

>>11. section 3.2.2
>>
>>i guess the proposed formats are not meant to be exchaustive (would be
>>worth indicating this)
> 
> Hmmm. I can certainly make the text more ambiguous, but these were the
> only two formats (apart from the mixed format as indicated) that we could
> come up with. Do you see any further formats for this mode of visibility?

i asked this because mixing does only refers to partial visibility while 
we can assume learning systems or possibility for having full visibility 
for some domains but not for others in this case "intermediate hops" (in 
the broad sense) would not necessarily represent "domains"

>>12. section 3.3
>>
>>3rd paragraph is indeed expressing ERO construction per 3209, but then
>>how to interpreet second bullet of the alternative presented in section
>>3.2.2.
> 
> Don't you just love the ERO processing rules in 3209? :-)
> 
> Suppose you have an ERO that says, {strict AS A, strict AS B, loose Bn}
> where Bn is the egress.

ok - i understand better now whatt you meant with "strict hops giving 
abstract nodes representing each domain"

> When we reach A1 in AS A we may *replace* the hop {strict AS A} with the
> sequence of hops {A2, A3, ...., An}. This is allowed because these hops
> are all within the abstract node {AS A}. In this sense we are not
> inserting hops before {strict AS B}.
> 
> However, when we arrive at An (the border node) the ERO looks like {An,
> strict AS B, loose Bn}. At this point the abstract node {An} is not open
> for expansion, and we are not allowed to insert hops before the next hop
> which is strict, so we must now move on to B1.
 >
>>13. section 3.4
>>
>>"The selection of PCE(s) may be driven by static configuration or the
>>dynamic discovery by means of IGP or BGP extensions." would it be
>>possible to detail in which context BGP PCE discovery would be
>>appropriate and the corresponding mechanism applicable
>  
> I have views on this, but I think the politically correct thing to do here
> is change the text to read...
>    The selection of PCE(s) may be driven by static configuration or the
>    dynamic discovery.

ok

>>14. section 3.4.2
>>
>>paragraph 2 discusses (again) optimality issues but in the context of a
>>section that speaks about confidentiality - not sure this is the best
>>place in the document to do so -
> 
> I guess you are refering to the word "best"?
> 
> I will delete it as it is superfluous.

it is probably more specific here - i mean there is indeed a trade-off 
and as far as my reading goes there is something that must be formalized 
  there is either an explicit mechanism or an implicit mechanism, in the 
former case confidentiality is also involved in the second optimality 
(as far as this notion can indeed be provided in a multi-domain environment)

>>15. section 3.5
>>
>>what is the real purpose of this section ? lot of things is said about
>>conditions prevailing in multi-domain environments but very few is said
>>about what could be a baseline on "optimal multi-domain path" - may be
>>worth considering the last paragraph only -
> 
> The intention is to point out that optimality by most definitioins is
> likely to be degraded by the existence of more than one domain (or at
> least the need to traverse more than one domain). The intention is then to
> dodge the issue of defining optimality in any generic way.
> 
> Thus, as you note, there is no baseline for an optimal multi-domain path.
> 
> We can wordsmith the first paragrpah a bit, I think.

ok

>>16. section 4
>>
>>would it be possible to expand on "end-point" reachability information
>>exchanges - which is at the end the only mandatory information needed
>>the following "Where any cross-domain reachability and TE information
>>needs to be advertised, consideration must be given to TE extensions to
>>BGP, and how these may be fed to the IGPs. ..." is again focusing on TE
>>info processing
> 
> I'm not sure I get your point.

the sentence under discussion here is

"Where any cross-domain reachability and TE information needs to be
  advertised, consideration must be given to TE extensions to BGP, and
  how these may be fed to the IGPs."

it is important to understand what the transposition of inter-domain 
reachability provides as real information before stating we need TE 
extensions to BGP

>>17. section 5.1
>>
>>if this section is dedicated to re-optmization - and considered as an
>>advanced mechanism - details included as part of section 3.4.2 should be
>>moved in this section
> 
> Why?
> 3.4.2 is talking about normal LSP establishment.
> I think the confusion comes from the text in 3.4.2 that says...
>    In this way an end-to-end path may be computed using the full network
>    capabilities, but confidentiality between domains may be preserved.
>    Optionally, the PCE(s) may compute the entire path at the first
>    request and hold it in storage for subsequent requests, or it may
>    recompute the path on each request or at regular intervals.
> This should really read as follows...
>    In this way an end-to-end path may be computed using the full network
>    capabilities, but confidentiality between domains may be preserved.
>    Optionally, the PCE(s) may compute the entire path at the first
>    request and hold it in storage for subsequent requests, or it may
>    recompute each leg of the path on each request or at regular
>    intervals until requested by the LSRs establishing the LSP.

ok

>>18. section 5.1
>>
>>" Note also that where multiple diverse paths are applied end-to-end
>>    (i.e. not simply within protection domains - see section 5.5) the
>>    point of calculation for re-optimization (whether it is PCE,
>> ingress, or domain entry point) needs to know all such paths before
>> attempting re-optimization of any one path."
>>
>>the notion of diversity is unclear in this sentence i.e. diverse from ?
> 
> mutually-diverse

ok - so you mean mutually "resource disjoint" LSP

>>19. section 5.4
>>
>>would it be possible to detail the following sentence, in particular,
>>when FRR is used in combination with LSP stitching
>>
>>"The techniques that must be employed to use Fast Reroute for the
>>    different methods of signaling LSPs identified in section 2 differ
>>    considerably."
> 
> Hmmm.
> Our aim here was just to flag that FRR does not simply transport itself to
> work with hierarchical or stitched LSPs. We wanted to punt on this and
> make it the responsibility of the applicability I-D or the signaling
> extensions I-D.
> 
> I will, however, add a note that...
> "In particular, there may be issues protecting the ingress and egress LSRs
> of hierarchical LSPs or stitched segments."

ok

>>20. section 5.5
>>
>>would be interesting to know what is meant by "easier" in the following
>>sentence "The problem is generally considered to be easier and more
>>efficient when the diverse paths can be computed 'simultaneously' on the
>>fullest set of information."
> 
> Replaced with "less complex".

i would simply say "The problem can be resolved more efficiently (e.g. 
avoid so called "trap problem") when mutually resource disjoint paths 
can be computed 'simultaneously' on the fullest set of information."

>> it would also be interesting to know what is meant by "Domain ID" in
>> the context of the following sentence "The former might be identified using
>>a combination of domain ID and an SRLG ID that is administered by the
>>domain." in particular if SRLGs are confined within a domain adding a
>>domain id to the SRLG ID would only be useful if SRLG id values are not
>>unique across domains but the latter would then be expected to share
>>that information - is that the intention ?
> 
> As you note, this case is intended to apply where the constituents of the
> SRLG are confined within a domain, but the SRLG is identified with wider
> scope than the domain. Thus, either we need administration of SRLG IDs
> across domains (to make the SRLG ID unique across domains) or we need the
> domain ID to form part of the SRLG identification.

agreed & i suggest to formalize this as part of the text even if the 
former alternative is probably difficult to achieve

>>21. Section 5.8
>>
>>the major issue is whether end-points are supportive of the capability -
>>this should be highlighted in this section
> 
> OK
>
>>editorial: this document refers to TE LSP and sometimes to LSP is there
>>any specific different or just a contraction ? i am asking this because
>>in the context of a document that speaks about Traffic Engineering this
>>is not necessarily clear
> 
> Right.
> I think it is just sloppy editing.
> 
> The intention is to indicate that we are in the realm of RSVP-TE and not
> LDP, so all of the LSPs are really TE LSPs.

the realm of this document is source/constrain-based routing which by 
definition implies the use of a protocol that support these notions

> Are there any specific instances of "LSP" which you feel confuse matters?

i would say that "MPLS TE" does implicitly means the above

> Thanks,
> Adrian
> 
> 
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sun, 05 Jun 2005 08:48:44 +0000
Message-ID: <[e-mail]>
Date: Sun, 05 Jun 2005 10:46:40 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail],  [e-mail]
Subject: Re: Liaison from ITU-T on CCAMP ASON Routing Evaluation I-D
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian

the rsdt will take the below points into account during document's next 
revision

thanks,
- dimitri.

Adrian Farrel wrote:
> Hi,
> 
> We have received the following liaison from Study Group 15 of the ITU-T.
> 
> This is informational so no action is required, but obviously the ASON
> Routing Solutions design team will take these items on board in their next
> revision.
> 
> As with all incoming liaisons, this is posted at
> http://www.olddog.co.uk/incoming.htm and will be placed on the IETF's
> liaison Web site.
> 
> You can find the attachments there as well.
> 
> Adrian
> 
> =========
> Title: Reply to Evaluation of IETF Routing Protocols in the Context of
> ASON
>>From : ITU-T SG15, Q14/15
> Contact: Hing-Kam Lam ([e-mail])
> For: Information
> 
> Thank you for informing Q14/15 of the progress of the design team
> operating under the umbrella of the CCAMP working group within the IETF.
> As requested, Q14/15 reviewed the document
> draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt and have provided some
> detailed comments directly in the document as marked up text. The marked
> up document is attached below.
> 
> As further context to comments provided in the document:
> -  In "4. Requirements - Overview". It is not required for UNI Transport
> resource names
>    to be included as reachability information in any routing protocol.
> They are
>    resolved to SNPP addresses and SNPP addresses are reachable.
> -  In "5.1 Terminology and Identification".  Text of SP16 from G.8080 is
> attached as it
>    is relevant to the RC ID format.
> -  Q14 would like to see items that are under evaluation to be resolved
> (e.g., cases
>    where Li is given a value different from TE Router ID. Our
> understanding is that the
>    TE Router ID is the address of a point in an IP-layer topology,
> possibly an SCN
>    address. Such separation is permitted by the ASON routing architecture'
> s name space
>    separation concepts).
> -  In "5.3.1 Link Attributes".  Representation of layer resources and
> utilization is
>    required.
> -  In "6. Evaluation Scenarios".  Add cases where multiple Ri announce on
> behalf of an
>    Li or multiple Li.
> -  We suggest that the lexicography draft be added as informative and that
> ASON routing
>    requirements draft be added as normative.
> 
> Q14/15 appreciates the work undertaken to enable protocols that realize
> the ASON routing architecture, as well as the opportunity to review that
> work as it progresses.
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 04 Jun 2005 12:31:44 +0000
Message-ID: <023b01c56901$4e924620$34919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Review of draft-caviglia-mp2cpcp2mp-01.txt
Date: Sat, 4 Jun 2005 13:28:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Hi Diego,

I have had a look through your I-D and have a few comments attached.

This could be a nice and useful little function requiring only a very
short document and just one bit on the wire. Excellent!

Wrt your proposed solution, I think it is nearly there, but needs a few
tweaks and there are still a couple of areas to complete.

You also really need to do some work on the English. I known this is hard
(you write better English than I write Italian!), but in order that the
document can be properly reviewed (and hopefully implemented one day) we
have to improve the use of language. What I suggest is that you make the
revisions necessary for the next version and then you get someone to
review the document just to polish the language. I'm sure there would be
volunteers to work with you on this.

Regards,
Adrian

===========

Network Working Group                                     Diego Caviglia
IETF Internet Draft                                              Marconi
Proposed Status: Informational

## Why do you propose this as Informational? Do you not want it to be
## standardized?
## you may even want to flag it as "Updates RFC 3473"

Expires: August 2005                                       Dino Bramanti
                                                                 Marconi

                                                           Nicola Ciulli
                                                               Nextworks

                                                           February 2005

        GRSVP-TE signaling extension for LSP ownership handover from
             Management Plane to Control Plane and vice versa.

## I would prefer the title to be...
## GMPLS Signaling Extensions for the Transfer of Ownership of Label
## Switched Paths Between the Management and Control Planes

                     draft-caviglia-mp2cpcp2mp-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667. By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.
## You'll need to fix this boilerplate before you republish.
## Don't forget to run the idnis script found at
## http://ietf.levkowetz.com/tools/idnits/

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2005). All Rights Reserved.

Abstract

   This memo introduces a new flag in the Administrative Status object,
   namely the "Handover" flag, and defines its use within GRSVP-TE
   signaling.  This flag SHOULD be used in order to allow LSPs,
   originally created and controlled by the Management Plane (MP), to be
   transferred to Control Plane (CP) domain and vice-versa. The result

Caviglia et al.           Expires - August 2005               [Page 1]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   of the Handover flag use in GRSVP-TE is that, at the end of the
   setup signaling flow, an LSP that was created thru Management Plane
   operations is moved under Control Plane domain and control.
   Conversely, at the end of a deletion procedure, the LSP that was
   under the Control Plane domain is moved back to the Management Plane
   domain.
   Both the above procedure are not traffic affecting and can be
   performed with "in service traffic".

## It is normal for the Abstract to talk about the problem and the desired
## function rather than solutions.
##
## So you should rephrase this along the lines of...
##
## During migration scenarios it may be desirable to transfer the
## ownership of a Label Switched Path (LSP) from the Management Plane
## to the Control Plane, or vice versa. If the LSP is carrying traffic
## this change needs to be made "in service," that is, without affecting
## traffic.
##
## This memo provides minor extensions to the Generalized Multiprotocol
## label Switching (GMPLS) signaling protocol to enable this transfer of
## ownership, and descirbes the necessary procedures.


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].


Table of Contents

   1. Introduction.....................................................2
   2. LSP Adoption/Release.............................................4
      2.1 Overview.....................................................4
      2.2 LSP Adoption phase: association of GMPLS information to a MP
          born LSP - LSP SetUp.........................................4
        2.2.1 Association Procedure....................................5
        2.2.2 Association Failure Handling.............................6
      2.3 LSP Release phase- disassociation of GMPLS information to a
          MP born, CP adopted LSP - LSP Tear Down......................7
   3. RSVP Message Formats.............................................7
      3.1 Object Modification..........................................7
        3.1.1 Administrative Status Object.............................7
   4. Security Considerations..........................................8
   5. IANA Considerations..............................................8
   6. Normative References.............................................8
   7. Informational References.........................................9
   8. Acknowledgements.................................................9
   9. Author's Addresses...............................................9
   10. Intellectual Property Rights Notices............................9
   11. Full Copyright Statement.......................................10


1. Introduction

## I think that before you start you need to explain to the reader that
## when you say "LSP" you mean the data plane forwarding path and data
## plane state. There are many people who have come to use the term
## "LSP" to mean the control plane state necessary to establish and
## maintain the data plane state - of course, you do not mean this.

## You need to expand all of the acronyms the first time they are used

   The use of a GMPLS control plane over networks that are already in
   service can't be considered of course as a green field application.
   This means that in a transport network control scenario LSPs created
   and owned by Management Plane and LSPs signaled and owned by means of
   GMPLS Control Plane have to coexist. In such a situation it is
   possible that a network operator wants to move to Control Plane an
   LSP created by and belonging to Management Plane. In a similar
   fashion, the opposite operation is also needed. In this memo let's

Caviglia et al.           Expires - August 2005               [Page 2]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   call "LSP adoption" the procedure that is aimed at moving an LSP born
   in Management Plane to Control Plane. Let's call "LSP release" the
   opposite procedure aimed at moving back the LSP from Control Plane to
   Management Plane.
## In fact, it isn't a question of where the LSP was "born" or of
## "moving back". The question is, which plane 'owns' the LSP before and
## after the operation. After all, the LSP could be moved back and
## forwards many times.
##
## I would suggest that "release" is a term already applied to LSP
## teardown, so you should choose another term.

   At present there is no way for a Carrier Operator that wants to
   associate/disassociate GMPLS information to an already existent LSP.
   In particular there is no way to inject LSP information and
   visibility from Management Plane to Control Plane (and the other way
   back) by means of standard G.RSVP-TE signaling flow.
## Please don't say G.RSVP-TE. It isn't an ITU-T G-series Recommendation
:-)

## You should explain why this does not work for the transfers in both
## directions. For example:
## If you try to signal an LSP to use resources already established and
## under the control of the Management Plane you will either be rejected
## by the network devices because the resources are already in use, or
## you will establish a second, parallel LSP.
## If you try to release an LSP established by the Control Plane by
## sending teardown signaling messages, the LSP will be lost before the
## Management Plane can take over.
##
## You should also explain why make-before-break is not an acceptable
## way to handle this situation. For example, one could have two LSPs
## (one set up by the Management Plane, and one set up by the Control
## Plane) and switch data between them (in the manner of 1+1 protection)
## with no significant hit on the traffic.

   A new flag in the Administrative Status Object (RFC 3471[3] and RFC
   3473 [4]), named Handover flag, is proposed in this memo as a mean to
   make possible necessary information exchange between GMPLS enabled
   nodes, in order to implement and support the functionality introduced
   above.

   Handover flag SHOULD be used during a signaling set-up (tear down,
   when performing opposite operation) and allows the association of
   LSP-related GMPLS information (at Control Plane level) to a circuit
   originated by Management Plane actions and formerly not visible and
   "known" to Control Plane itself. Data plane flow related to such LSP
   is unaware of this transfer of control from MP to CP (and back). It
   is worth taking into account that affected LSP may already be
   carrying traffic, which hasn't to be perturbed neither during MP to
   CP LSP handover, nor during dual CP to MP control transfer.

   The procedure here described is based (in case of MP to CP LSP
   handover, for instance) on the collection of information owned by
   Management Plane and related to a LSP originated in MP. This detailed
   information about route and resources used by the LSP is passed to
   Control Plane, which gets it to signal the LSP. When signaling the CP
   adopted LSP, Handover flag is set in order to make recognizable that
   signal flow and instruct GMPLS nodes about it.
   GMPLS nodes have to handle that LSP in such a way that, at the end of
   signaling, it is a full effect Control Plane owned LSP.
   Conversely, CP to MP migration is signaled over CP by relevant
   G.RSVP-TE tear down messages with Handover flag set.
   This is in some way similar to the Restart Procedure, (Section 4.3
   RFC 3473 [4]), in the sense that the cross connection in the Data
## "cross-connection" throughout the I-D
## The connection has nothing to be cross about :-)
   Plane are already present and it is only needed relevant GMPLS
   information to be associated to it.

   The modification proposed in this document refers only to
   Administrative Status object, that is, the message flow is left
   unmodified for both set-up and deletion.

## Most of your description discusses only cross-connections. But of
## course there is more going on in terms of resource reservation and
## resource activation (e.g. turning on lasers). You need to make sure
## that your language cover this.




Caviglia et al.           Expires - August 2005               [Page 3]

draft-caviglia-mp2cpcp2mp-02                            February 2005

2. LSP Adoption/Release

2.1 Overview

   In LSP association/release procedure here introduced, GRSVP-TE
   signaling messages and flow is used as normal and the processing of
   the messages is exactly the same as usual, except for the fact that
   no operation has to be performed over Data Plane. This means that the
   cross connection, which is assumed to be physically already in place
   in Data Plane, hasn't to be actually created (set-up phase)_ nor
   deleted (deletion phase) during signaling flow used to move LSP
   control from MP to CP (or CP to MP) .
## This is a major piece of problem statement (that the data plane
## must be unchanged, and that the resources are assumed to be
## already in place). You should move it to section 1.

   Such signaling messages are
   marked and recognizable for this purpose by Handover flag setting.
   When the LSP is adopted either by CP or MP, i.e. at the end of
   signaling with Handover flag set, normal CP procedures or MP
   procedures have to take their place as usual when needed. This means
   that a LSP originated in MP, signaled in CP with Handover flag on and
   hence passed to CP, can be deleted by usual and relevant Control
   Plane signaling flows (i.e. with Handover flag not set). The same
   applies when a LSP belongs to Management Plane. In other words, after
   those LSP handover procedures have taken place, the LSP is not
   different from the other LSP owned by handover destination entity,
   and it has to be treated with usual rules of that entity.

2.2 LSP Adoption phase: association of GMPLS information to a MP born
    LSP - LSP SetUp

   In order to support the adoption of a LSP, the ERO object in the Path
   message MUST be filled with all the LSP relevant information, that
   is, down to the Label level.  That can be done by means of the object
   and procedures defined in [5].
## You need to reference RFC3209 and RFC3473 here as well.
## But I think that component link identification has become clearer
## since the rework of the bundling I-D and you may be able to reference
## that instead of [5]. Talk to Zafar Ali about that issue.

   The filling of the ERO down to the Label Level, including Component
   Link identifier when necessary, is possible as we are assuming the
   LSP already exists in the Network and the MP has all the associated
   information. Management Plane is the entity holding LSP information
   and passing it over to CP during adoption.

   Signaling set-up related to the LSP adoption contains the Handover
   flag of the Administrative State Object set.
   Upon reception of GRSVP-TE Path with Handover flagged Admin Status
   object, i.e. during signaling set-up, a node SHOULD associate LSP
   info at CP level to the existing cross connection.

   The information about the fact that a LSP adoption procedure is
   ongoing on the LSP should be maintained by the TNE until Resv Confirm
   message is received at the node. That information is needed in case
   of failures during the association set-up.



Caviglia et al.           Expires - August 2005               [Page 4]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   Resv and Resv Confirm messages following Path (all with Handover flag
   set) are processed as usual and, after Resv Confirm processing, the
   LSP is completely under the CP domain.  This means that any memory
   about the fact that previously was under the MP is lost.

## Hmmm. You are assuming the use of the ResvConf message and I am not
## sure that that is a good idea. Why don't you continue to retain this
## information until the Handover flag is cleared?
##
## I think this would work well because, in any case, you need to
## discuss if and when the Handover flag is cleared. Note that
## Admin Status flags are not one-off triggers, but persistent state
## controllers.
##
## Clearing the Handover flag is important because until you have
## doen this, the LSP remains in 'handover state' (that is, it might
## appear to be in the process of being sent back to the MP as
## described in section 2.3) and so the CP will never have full control.
##
## This makes the rules for processing on an LSR very clear:
## When the handover bit is set in the Path state for an LSP, neither
## the CP nor the MP may make changes to the DP state or the associated
## resources. (You would probably want to allow an MP over-ride on this,
## but that is identical to the over-ride that the MP has on a CP-owned
## LSP in normal circumstances.)

   Failures during the Adoption of an LSP are managed as usual, except
   that TNEs receiving error messages, with Path State Removed set, do
   not delete the cross connection in the data plane but only their
   GMPLS associated information.
## Well, this ruling applies to all error cases and scenarios.
## That is, while the adoption process is under way (until the ResvConf,
## or clearing of the Handover bit) an LSR MUST NOT release any Data
## Plane state associated with the LSP even if it releases Control
## Plane state.

2.2.1 Association Procedure

## Can you please use RFC2119 terminology in the definition of
## procedures. This will help to remove any ambiguities.

   This Section covers the procedure needed to manage a LSP Adoption
   procedure, that is, a GRSVP-TE signaling set-up where Path message
   contain an Administrative Status object with the Handover flag set.

   In the following the adoption of a bidirectional LSP is taken into
   consideration. The case of unidirectional LSP can be easily derived
   from that.

   A node receiving a Path message containing an Administrative Status
   object with the Handover flag set is informed about the fact that a
   LSP adoption procedure is ongoing. The node assumes that a Data Plane
   connection related to the info carried in Path Message is already in
   place. The node SHOULD check however if there is an actual Data Plane
   cross connection between the resources indicated by the message:

   - If yes then a GRSVP-TE state is associated with the cross
      connection and relevant CP data structures of LSP are created.

   - If no, that is the resources are used in a way that is different
     from the one indicated by the Path message then:

     o a PathErr with Path State Removed flag set should be generated

     o GMPLS state information is deleted but actual cross-connection in
## Don't say "GMPLS state information." Say "GMPLS Control Plane state
## information."
       the data plane are not.

   In order to be able to cope with a failure during described
   procedure, the information about the fact that the ongoing signaling
   flow is concerning an LSP adoption is maintained by the TNE until the
   receipt of the Resv Confirm. In such a way Management Plane holds LSP
   related info until Handover flagged signaling session has
   successfully ended.

## The previous paragraph highlights that you need to describe (a little
## earlier in the document) how the handover procedure is coordinated
## between the MP and CP. Although the precise mechanisms are out of
## scope, we can assume that:
## - it is under operator or management applicaiton control
## - control requests are sent to the ingress LSR by the MP
## - the MP has some way of knowing when the CP has completed its task
##   or has failed.

   The following example illustrates the possible Adoption cases either
   successful or failed.




Caviglia et al.           Expires - August 2005               [Page 5]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   The cross connection to be moved under the control plane involves
   Timeslot A and B. This means that Handover flagged signaling refers
## You say "Timeslot." Does this only apply to TDM?
   to A-B xconnection over Data Plane. The symbol <----> means that the
   two Timeslots are actually cross connected over Data Plane.


          | Data Plane| Control Plane| Management Plane| Notes
   ---------------------------------------------------------------------
   Case 1 | A<---->B  | No info yet  | LSP info present| OK for MP to CP
          |           |              |                 | LSP handover
   ---------------------------------------------------------------------
   Case 2 | A<---->C  | No info yet  | LSP info present| NOK for MP to
                                                       | CP LSP handover
   ---------------------------------------------------------------------

## Perhaps instead of "LSP info present" for the MP, you should say
## "MP expects A-B".

   Case 1:
   - LSP info in Management Plane is present and describes A-B
     connection.
   - LSP is not visible yet over Control Plane.
   - A-B connection is actually present over Data Plane.
   - GRSVP-TE state (related to involved LSP) is associated to the
     cross connection after Handover flagged signaling flow
     (Path/Resv/resvConfirm with Handover flag set).
   - No actions are taken in the Data Plane.
   - At the end LSP is completely under CP control.


   Case 2:
   - LSP info in Management Plane is present and describes A-B
     connection.
   - LSP is not visible yet over Control Plane.
   - A-B connection is not actually present over Data Plane and relevant
     resources are used within other context (A is x-connected to C).
   - GRSVP-TE state (related to involved LSP) is not associated to the
     cross connection after Handover flagged signaling flow.
   - A PathErr with Path State Removed flag set should be sent Upstream.
   - No actions are taken in the Data Plane.
   - At the end LSP stays completely under MP control as before.

2.2.2 Association Failure Handling

   When a node receives a PathErr with Path State Removed checks if the
   LSP it refers to is involved in an Adoption procedure, whose track is
   kept until successful end of signaling flow has been carried on as
   stated above. If yes, then no actions are performed over the data
   plane, while GMPLS status information about involved LSP over Control
   Plane is deleted and the cross connection ownership is moved back
   under the NMS controls.



Caviglia et al.           Expires - August 2005               [Page 6]

draft-caviglia-mp2cpcp2mp-02                           February 2005

   The same applies for PathTear message.
## Ah. Very important!
## In fact, rather than limiting to the PathErr with PSR flag, and
## PathTear, why don't you say that "While the Handover flag is set in
## the Administrative Status object of the associated Path message, an
## LSR MUST NOT make changes to the data plane state (resource
## reservations, cross-connects, etc.) as the result of either Control
## Plane or Management Plane actions.

2.3 LSP Release phase- disassociation of GMPLS information to a MP born,
    CP adopted LSP - LSP Tear Down

   This Section covers the procedure needed to manage a LSP Release
   procedure (as a dual, opposite procedure respect to Adoption
   described above).

   Such a procedure is performed at a signaling level as described in
   Section 7.2.1 of the RFC 3473 [4]. LSP tear down flow is carried on
   as usual, except that Handover flag is set in Administrative Status
   Object like it was during set-up (adoption) case.
## Although this reference is correct, I think you could usefully give
## some hints. That is, explain that the procedures are the same as for
## alarm-free teardown using the Adminastrative Status object as
## described in...

   Nodes receiving G.RSVP-TE tear down messages with Handover flag set,
## No, no, no, no!
## There is no Admin Status object on a PathTear. Go back and read the
## reference you cited! What you have to do is:
##
## 1. Turn on Handover and Refelect bits in Admin Status on a Path
## 2. Wait until the Handover bit is received back in the Resv
## 3. Send PathTear to release the CP state.
## 4. Apply the same rule as above. That is:
##    While the Handover flag is set in
##    the Administrative Status object of the associated Path message,
##    an LSR MUST NOT make changes to the data plane state (resource
##    reservations, cross-connects, etc.) as the result of either
##    Control Plane or Management Plane actions.

   have to process such messages as usual, but they have to behave in a
   special way respect to Data Plane. As a perfect dual situation of the
   Adoption described before, no actions at all have to be performed
   over the data plane. This means that the node has to carry on tear
   down signaling procedure but it SHOULD NOT clear x-connection related
   to affected LSP. As a consequence of the Release only GMPLS state
   information have to be deleted.

   At the end of the Disassociation procedure the GMPLS associated
   information is deleted and the LPS is moved under the NMS control.

## You need to add sections to describe:
## - Control Plane failure and recovery during handover
## - Non-support of the handover process by transit or egress LSRs

3. RSVP Message Formats

   This memo does not introduce any modification in RSVP messages.

3.1 Object Modification

   This memo introduces a new flag into the Administrative Status
   object.

3.1.1 Administrative Status Object

## Say...
## The Admin_Status Object is defined in RFC 3473 [4].
##
## This document uses the H-bit of the Admin_Status object. The bit
## is bit number (TBD by IANA).

##### START DELETE
#  The use of the Admin_Status Object is optional.  It uses Class-Number
#  196 (of form 11bbbbbb).
#
#     The format of the Admin_Status Object is:
#
#      0                   1                   2                   3
#      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
#     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#     |            Length             | Class-Num(196)|   C-Type (1)  |
#     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#     |R|                        Reserved               |H|L|I|C|T|A|D|
#     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#
#
#Caviglia et al.           Expires - August 2005               [Page 7]
#
#draft-caviglia-mp2cpcp2mp-02                            February 2005
#
#        Reflect (R): 1 bit
#
#        When set, indicates that the edge node SHOULD reflect the
#        object/TLV back in the appropriate message.  This bit MUST NOT
#        be set in state change request, i.e., Notify, messages.
#
#        Reserved: 28 bits
#
#        This field is reserved.  It MUST be set to zero on transmission
#        and MUST be ignored on receipt.  These bits SHOULD be pass
#        through unmodified by transit nodes.
####### END DELETE

         Handover signaling (H): 1 bit

         When set, indicates that an Association/Disassociation
         procedure is ongoing.
## Why not call this the ahndover procedure?


####### START DELETE
#  The other flag are defined in the following documents:
#        R-bit   [RFC3471]
#        L-bit   [E2E]
#        I-bit   [ALARM]
#        C-bit   [ASON]
#        T-bit   [RFC3471]
#        A-bit   [RFC3471]
#        D-bit   [RFC3471]
#
#
#  Where:
#   [RFC3471]     RFC3471
#   [E2E]         draft-ietf-ccamp-gmpls-recovery-e2e-signaling
#   [ALARM]       draft-ietf-ccamp-gmpls-alarm-spec
#   [ASON]        draft-ietf-ccamp-gmpls-rsvp-te-ason
####### END DELETE

4. Security Considerations

   This document does not introduce any additional Security issues.  For
   GRSVP-TE Security please refer to [3].

## I think that the removal of an LSP from one sphere of control to
## another is a serious security issue. You need to explain this risk
## and state why it is or is not a problem.


5. IANA Consideration

   This memo introduces a new GRSVP-TE object type and a new Error Code
   Error Value couple.
##
## Hmmm? What new object type? What new error code/value?
##
## Say the following...
## 6.1 Administrative Status Bit Allocation
##
## IANA has been asked to manage the bit allocations for the
## Administrative Status object [6].
##
## This document requires the allocation of the Handover bit: the H-bit.
## IANA is requested to allocate a bit for this purpose. See section
## 3.1.1.

6. Normative References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

Caviglia et al.           Expires - August 2005               [Page 8]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   3  Berger, L., " Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Functional Description", RFC 3471, January 2003

   4  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Resource ReserVation Protocol-Traffic Engineering
      (RSVP-TE) Extensions", RFC 3473, January 2003.

7. Informational References

   5  Zamfir, A., " Component Link Recording and Resource Control for
      GMPLS Link Bundles",
      draft-zamfir-explicit-resource-control-bundle-03, February 2004.
## state "work in progress"

## 6  L. Berger (Ed.) "GMPLS - Communication of Alarm Information",
      draft-ietf-ccamp-gmpls-alarm-spec-02.txt, November 2004, work in
      progress.



8. Acknowledgements

   Adrian Farrel provided editorial assistance to prepare this draft
   for publication.


9. Author's Addresses

   Diego Caviglia
   Marconi
   Via A. Negrone 1/A
   Phone: [phone]
   Email: [e-mail]

   Dino Bramanti
   Marconi
   Via Moruzzi 1
   C/O Area Ricerca CNR, Pisa
   Email: [e-mail]

   Nicola Ciulli
   Nextworks
   Corso Italia n. 116,
   56125 Pisa (Italy)
   Email: [e-mail]

10. Intellectual Property Rights Notices

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


Caviglia et al.           Expires - August 2005               [Page 9]

draft-caviglia-mp2cpcp2mp-02                         February 2005

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   [e-mail].

11. Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

























Caviglia et al.           Expires - August 2005              [Page 10]





Envelope-to: [e-mail]
Delivery-date: Fri, 03 Jun 2005 16:07:45 +0000
Message-ID: <014301c56856$a6702250$34919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Liaison to ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON Lexicography"
Date: Fri, 3 Jun 2005 17:09:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Title: Liaison to ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON
Lexicography"
To: ITU-T Study Group 15 Question 3
From: IETF CCAMP Working Group
For: Action
Deadline: August 1, 2005

CCAMP would like to thank Q3/15 for their liaison and the useful
explanatory information it contains.

The liaison is marked "For: Action" with a deadline of August 31,2005.
However, there are no obvious requests for action within the liaison.

Can you please clarify whether there was an intent to request specific
action.

Thank you.

Adrian Farrel and Kireeti Kompella
CCAMP Working Group Co-Chairs




Envelope-to: [e-mail]
Delivery-date: Fri, 03 Jun 2005 16:06:40 +0000
Message-ID: <014201c56856$877253a0$34919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Liaison from ITU-T on Optical Transport Work Plan
Date: Fri, 3 Jun 2005 17:08:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received the following liaison from Study Group 15 of the ITU-T on
their plans for work on the Optical Transport Network and Technologies.

The liaison is for comment so we must respond. However, it is possible
that we will have nothing to say.

You are encouraged to read the Work Plan and send any comments to the
CCAMP mailing list. Of particular interest are areas of potential
cooperation between the IETF and the ITU-T.

There is a very long lead time to the deadline for this response, but I
would like to ask you to make your comments by June 30th

As with all incoming liaisons, this is posted at
http://www.olddog.co.uk/incoming.htm and will be placed on the IETF's
liaison Web site.

You can find the attachment there as well.

Adrian

=========
Title: Reply to liaison on GMPLS/ASON Lexicography
>From : ITU-T SG15, Q3/15
Contacts: Hiroshi Ohta ([e-mail])
For: Comment
Deadline: 31 December 2005

Attached is the updated version resulted from this SG15 meeting (Geneva,
16-27 May 2005).  We appreciate your comments.  In addition, please note
that we decided to remove detailed contact information of Chairmen and
other key people of related standard bodies and indicate the URLs of their
web sites instead since contact information changes regularly.








Envelope-to: [e-mail]
Delivery-date: Fri, 03 Jun 2005 16:06:23 +0000
Message-ID: <014101c56856$6381bc10$34919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Further liaison from ITU-T on ASON Lexicography
Date: Fri, 3 Jun 2005 17:07:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received a second liaison from Study Group 15 of the ITU-T on the
ASON lexicography.

The liaison is marked for Action, but no specific action is requested.

I will send a response liaison to query this.

If anyone wishes to review the two appendixes on IETF terms in the
referenced Recommendation, then I am sure that SG15 would welcome the
feedback.

As with all incoming liaisons, this is posted at
http://www.olddog.co.uk/incoming.htm and will be placed on the IETF's
liaison Web site.

Adrian

=========
Title: Reply on GMPLS/ASON Lexicography
>From : ITU-T SG15, Q3/15
Contacts: Hiroshi Ohta ([e-mail])
For: Action
Deadline: August 31, 2005

Thank you for your information on your Internet-Draft on GMPLS/ASON
Lexicography.  We would like to explain the status within ITU-T SG15
concerning the GMPLS/ASON development.

To facilitate readers in using ASON terminology, ITU-T has developed
Recommendation G.8081/Y.1353, which is intended to be a single normative
source for terms in ASON area. G.8081/Y.1353 included two Appendices,
which are named:

- Definitions found in documents from other organizations related, and
- Abbreviations and Acronyms found in documents from other organizations
related.

Among terms listed in these two appendices, most are from IETF. Of course,
due to the availability of documents and progress of the work related the
coverage of these appendixes is not complete, and updates to them are
needed. To avoid misleading, the two appendices cited exactly what the
original documents stated for particular term as a definition listed
explicitly with no extra words.

All terms and Abbreviations are listed in Alphabetical order in
G.8081/Y.1353 including those in its appendices as this would be
convenient for readers to look up.

We appreciate the continuous exchange of information between us for
consistent development.




Envelope-to: [e-mail]
Delivery-date: Fri, 03 Jun 2005 16:06:15 +0000
Message-ID: <013f01c56856$334d0950$34919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Liaison from ITU-T on CCAMP ASON Routing Evaluation I-D
Date: Fri, 3 Jun 2005 17:06:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received the following liaison from Study Group 15 of the ITU-T.

This is informational so no action is required, but obviously the ASON
Routing Solutions design team will take these items on board in their next
revision.

As with all incoming liaisons, this is posted at
http://www.olddog.co.uk/incoming.htm and will be placed on the IETF's
liaison Web site.

You can find the attachments there as well.

Adrian

=========
Title: Reply to Evaluation of IETF Routing Protocols in the Context of
ASON
>From : ITU-T SG15, Q14/15
Contact: Hing-Kam Lam ([e-mail])
For: Information

Thank you for informing Q14/15 of the progress of the design team
operating under the umbrella of the CCAMP working group within the IETF.
As requested, Q14/15 reviewed the document
draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt and have provided some
detailed comments directly in the document as marked up text. The marked
up document is attached below.

As further context to comments provided in the document:
-  In "4. Requirements - Overview". It is not required for UNI Transport
resource names
   to be included as reachability information in any routing protocol.
They are
   resolved to SNPP addresses and SNPP addresses are reachable.
-  In "5.1 Terminology and Identification".  Text of SP16 from G.8080 is
attached as it
   is relevant to the RC ID format.
-  Q14 would like to see items that are under evaluation to be resolved
(e.g., cases
   where Li is given a value different from TE Router ID. Our
understanding is that the
   TE Router ID is the address of a point in an IP-layer topology,
possibly an SCN
   address. Such separation is permitted by the ASON routing architecture'
s name space
   separation concepts).
-  In "5.3.1 Link Attributes".  Representation of layer resources and
utilization is
   required.
-  In "6. Evaluation Scenarios".  Add cases where multiple Ri announce on
behalf of an
   Li or multiple Li.
-  We suggest that the lexicography draft be added as informative and that
ASON routing
   requirements draft be added as normative.

Q14/15 appreciates the work undertaken to enable protocols that realize
the ASON routing architecture, as well as the opportunity to review that
work as it progresses.




Envelope-to: [e-mail]
Delivery-date: Fri, 03 Jun 2005 16:06:07 +0000
Message-ID: <014001c56856$62c12b30$34919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>, "Ben Mack-Crane" <[e-mail]>
Subject: Liaison from ITU-T on ASON Lexicography
Date: Fri, 3 Jun 2005 17:06:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received the following liaison from Study Group 15 of the ITU-T.

The liaison is for comment so we must respond. We will obviously want to
take the review comments on board when we revise the I-D.

As with all incoming liaisons, this is posted at
http://www.olddog.co.uk/incoming.htm and will be placed on the IETF's
liaison Web site.

You can find the attachment there as well.

Adrian

=========
Title: Reply to liaison on GMPLS/ASON Lexicography
>From : ITU-T SG15, Q12/15 and Q14/15
Contacts: Malcolm Betts ([e-mail])
          Hing-Kam Lam ([e-mail])
For: Comment

Q12/15 thanks the CCAMP working group for the liaison of the
Internet-Draft written to capture and progress the output of the
terminology discussions held under our auspices in Holmdel earlier this
year (draft-ietf-ccamp-gmpls-ason-lexicography-02.txt).  The draft is a
very useful step toward developing a common understanding of GMPLS terms
in order to apply GMPLS in an ASON context.

Q12/15 has partially reviewed and discussed the draft.  There was not
sufficient time in this meeting to complete this review and discussion;
however, the results achieved have been recorded in the attached revised
draft which Q12/15 submits for CCAMP consideration. The proposed revisions
have been made with the following understanding:

- The purpose of the document is to enable those familiar with ASON to
understand
  GMPLS terminology in an ASON context
- GMPLS terms are described informally in the document in a way that is
generally
  consistent with GMPLS (existing RFCs and work in progress)
- Based on these descriptions, interpretations of these GMPLS terms in
ASON
  terminology are provided
- CCAMP has primarily responsibility for the descriptions of GMPLS terms
- Q12/15 has responsibility to provide input to the GMPLS-ASON
interpretations
  (based on the descriptions in this draft)

Q12/15 looks forward to continued exchange on this topic.  The work will
be progressed via correspondence on the Q12/15 mailing list and liaison if
required.  Q12/15 would appreciate future liaison of this draft and will
provide further review and comment as a response.

To assist in this joint effort, Mr. Ben Mack-Crane will act as SG15
representative to IETF CCAMP WG on the GMPLS-ASON lexicography draft.




Envelope-to: [e-mail]
Delivery-date: Fri, 03 Jun 2005 16:05:59 +0000
Message-ID: <013e01c56856$3298ad70$34919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Liaison from ITU-T on ASON Discovery
Date: Fri, 3 Jun 2005 17:05:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received the following liaison from Study Group 15 of the ITU-T.

No action is required, but some folks might want to look at this to
examine how or if LMP is applicable to the new requirements.

As with all incoming liaisons, this is posted at
http://www.olddog.co.uk/incoming.htm and will be placed on the IETF's
liaison Web site.

You can find the attachment there as well.

Adrian

=========
Title: Draft G.7714 Revision
>From : ITU-T SG15, Q14/15
Contact: Hing-Kam Lam ([e-mail])
For: Information

At the 16 - 27 May 2005 meeting, SG15 has consented on the Revision of
G.7714. Attached for your information is the consented text of G.7714
Revision. We look forward to continued cooperation between the two
organizations.




Envelope-to: [e-mail]
Delivery-date: Fri, 03 Jun 2005 16:05:51 +0000
Message-ID: <013d01c56856$31d81c90$34919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Liaison from ITU-T on Crankback
Date: Fri, 3 Jun 2005 17:05:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received the following response liaison from Study Group 15 of the
ITU-T.
No action is required.

As with all incoming liaisons, this is posted at
http://www.olddog.co.uk/incoming.htm and will be placed on the IETF's
liaison Web site.

Adrian

=========
Title: Liaison Statement to CCAMP on Crankback
>From : ITU-T SG15, Q14/15
Contact: Hing-Kam Lam ([e-mail])
For: Information

As requested in your liaison about crankback in Recommendation G.7713,
Q14/15 would be pleased to have CCAMP review any text in draft G.7713 and
G.7713.2 revisions prior to consent.  Text will be available after our
interim meetings planned for July and November 2005. Our current plan is
to consent G.7713 Revision in the February 2006 SG15 meeting.

An electronic copy of this liaison statement can also be found at
ftp://sg15opticalt:[e-mail]/tsg15opticaltransport/COMMUNICATIONS/index.html




Envelope-to: [e-mail]
Delivery-date: Fri, 03 Jun 2005 11:09:10 +0000
Message-ID: <009601c5682c$c6923ed0$34919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: P2MP Signaling Requirements in Working Group Last Call
Date: Fri, 3 Jun 2005 12:03:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

draft-ietf-mpls-p2mp-sig-requirement-02.txt is in last call in the MPLS
Working Group.

The I-D is entitled "Signaling Requirements for Point to Multipoint
Traffic Engineered MPLS LSPs" and applies to GMPLS as well as MPLS TE
LSPs.

We forgot to draw this to the attention of CCAMP, so Loa has kindly agreed
to extend the last call until June 10th to give CCAMP a chance to comment.

Please send you comments to any of (but preferably not all of)
- the MPLS mailing list
- the MPLS chairs
- the authors
- the CCAMP mailing list
- the CCAMP chairs

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 02 Jun 2005 22:25:24 +0000
Message-ID: <085d01c567c2$2755fbf0$23849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: GMPLS MIBs updated
Date: Thu, 2 Jun 2005 23:26:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have updated the GMPLS MIBs to take account of comments made in (and
just before) working group last call.

The biggest change is in the TE MIB where we have moved various
enumerations out of the main MIB and into textual conventions in an IANA
MIB.

The next step is to talk with the MIB doctors.

Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 02 Jun 2005 20:07:07 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-09.txt
Date: Thu, 02 Jun 2005 16:06:18 -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		: Generalized Multiprotocol Label Switching (GMPLS) 
		   	  Traffic Engineering Management Information Base
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-te-mib-09.txt
	Pages		: 54
	Date		: 2005-6-2
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for Generalized
   Multiprotocol Label Switching (GMPLS) based traffic engineering.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-09.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Thu, 02 Jun 2005 20:06:59 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-08.txt
Date: Thu, 02 Jun 2005 16:05:40 -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		: Generalized Multiprotocol Label Switching (GMPLS) 
			  Label Switching Router (LSR) Management Information Base
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-08.txt
	Pages		: 40
	Date		: 2005-6-2
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects to configure and/or
   monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
   Switching Router (LSR).

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-08.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Thu, 02 Jun 2005 20:06:52 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-07.txt
Date: Thu, 02 Jun 2005 16:05:06 -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		: Definitions of Textual Conventions for Generalized 
			  Multiprotocol Label Switching (GMPLS) Management
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-tc-mib-07.txt
	Pages		: 8
	Date		: 2005-6-2
	
This document defines a Management Information Base (MIB) module
   which contains Textual Conventions to represent commonly used
   Generalized Multiprotocol Label Switching (GMPLS) management
   information. The intent is that these TEXTUAL CONVENTIONS (TCs) will
   be imported and used in GMPLS related MIB modules that would
   otherwise define their own representations.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-07.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Thu, 02 Jun 2005 14:15:08 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Jun 2005 10:12:46 -0400
From: [e-mail]
To: [e-mail]
Subject: Deadline reminder: MPLS 2005 (Oct 16-19, Washington DC)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0)

=====================================
MPLS 2005 International Conference
http://www.mpls2005.com
October 16-19, 2005
Washington, DC
======================================

A reminder that the deadline for submissions to the CFP for MPLS 2005 is
approaching.

The Program Committee of MPLS2005 (<http://www.mpls2005.com>) is soliciting
presentation proposals for this conference. If you wish to suggest a particular
topic or a contribution, please send a one page long proposal (including
speaker's contact details) to the attention of the Technical Program Committee
at [e-mail] by June 10, 2005.

This year's conference will include, but not be limited to, topics such as:

 - MPLS in multi-area and multi-AS networks
 - Point-to-multipoint MPLS and applications
 - Supporting multicast in MPLS VPNs and for VPLS
 - Single and Multi-hop Pseudowire placement, setup and management
 - Providing QoS in MPLS networks
 - MPLS network management
 - OAM for MPLS networks
 - MPLS in the Next Generation Network
 - Voice over IP/MPLS
 - Triple-play applications on MPLS
 - MPLS-enabled Advanced services and converged networks
 - Interworking and migration for MPLS and GMPLS
 - Multi-layer networks and integration with non-packet technologies
 - Deploying, interworking and operating L2 and L3 MPLS VPNs
 - MPLS deployment experience: scaling, performance and security
 - Testing the technology: MPLS test tools and experience
 - Protection, restoration and reliability
 - Network processors for MPLS and GMPLS
 - MPLS/GMPLS control plane resilience, scaling and robustness
 - MPLS TE applications of the Path Computation Element (PCE)
 - Motivations and requirements for extending MPLS into the access network

The program committee is looking for original and unpublished work to continue
the tradition initiated by this conference in 1998 of covering cutting-edge
topics. Presentations from the vendor, service provider, research and user
community are solicited on new technologies and operational experience.

REGISTRATION is also now open, with extremely lucrative early-bird discounts -
visit <http://www.mpls2005.com/registration.htm> for details.

Thank you for your continued support.

Regards,
Kavita



Envelope-to: [e-mail]
Delivery-date: Wed, 01 Jun 2005 16:25:37 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Addressing doc
Date: Wed, 1 Jun 2005 09:22:39 -0700
Message-ID: <000b01c566c6$214d77d0$3b3ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks, 
Richard.

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Wednesday, June 01, 2005 8:47 AM
> To: Diego Caviglia; [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Re: Addressing doc
> 
> 
> Hi,
> 
> > would it be possible that you refine the notion of "address 
> translation"
> in the context of the
> > present LMP discussion as i am not necessarily sure 
> something specific
> needs to considered
> > beside what the LMP transport document already provides 
> (Section 4.3 for
> inst.)
> 
> If there is additional function required, it won't be in the 
> addressing
> draft.
> If there is guidance to operators or implementors it can be in the
> addressing draft (even if it is only a restatement of what is found in
> another draft or RFC).
> 
> Cheers,
> Adrian
> 
> 
> >
> > thanks,
> >
> > - dimitri.
> >
> >
> >
> > "Diego Caviglia" <[e-mail]>
> > Sent by: [e-mail]
> > 06/01/2005 15:09 ZE2
> >
> > To: [e-mail]
> > cc: [e-mail], [e-mail],
> [e-mail]
> > bcc:
> > Subject: RE: Addressing doc
> >
> >
> >
> >
> > Hi Richard,
> > I think that some text that explain how LMP can be
> > used to translate between TE links and control plane 
> addresses should be
> > very valuable.
> >
> > BTW if you think that the explanation is out of the scope 
> of the ID may
> be
> > some text that highlights that  LMP is one of the protocols 
> that could
> be
> > used to do address translation between  TE links and control plane
> > addresses can be enough.
> >
> > Diego
> >
> >
> >
> >
> >
> > "Richard Rabbat" <[e-mail]>@ops.ietf.org on
> 01/06/2005
> > 02.38.08
> >
> > Sent by:    [e-mail]
> >
> >
> > To:    "'Diego Caviglia'" <[e-mail]>, 
> "'\"\"'ccamp'\"
> > <ccamp\"'"
> > cc:    <[e-mail]>, "'\"\"'Kohei Shiomoto'\"
> > <shiomoto.kohei\"'", "'\"\"'Rajiv Papneja'\" <rpapneja\"'"
> >
> > Subject:    RE: Addressing doc
> >
> >
> >
> > Hi  Diego,
> >
> > We're  currently working on an update to
> > draft-ietf-ccamp-gmpls-addressing-00.txt. I  was wondering 
> if you have
> any
> > ideas w/r to your request below? Are you looking  for an 
> explanation of
> how
> > LMP could be used or simple text that highlights that  LMP 
> is one of the
> > protocols that could be used to do address translation 
> between  TE links
> > and control plane addresses?
> >
> > Richard.
> >
> > -----Original Message-----
> > From: Diego Caviglia  [mailto:[e-mail]]
> > Sent: Wednesday, April 27, 2005  8:42 AM
> > To: [e-mail]
> > Cc: ""'ccamp'"  <ccamp" ""'Kohei Shiomoto'" 
> <shiomoto.kohei" ""'Rajiv
> > Papneja'"  <rpapneja"
> > Subject: RE: Addressing  doc
> >
> >
> >
> > Richiard,
> > IMHO also a section (or sub-section)  dedicated to
> > LMP usage could be very useful in order to clarify how LMP 
> can  help in
> > addressing resolution.
> >
> > BR
> >
> > D
> >
> > Sent by:         [e-mail]
> >
> > To:         "'ccamp'"  <[e-mail]>
> > cc:        "'Kohei Shiomoto'" 
> <[e-mail]>, "'Richard
> > Rabbat'" <[e-mail]>, "'Rajiv Papneja'"
> > <[e-mail]>
> >
> > Subject:         RE: Addressing  doc
> >
> >
> >
> > Hi all,
> >
> > The editors have been having various discussions  with people  about
> some
> > oftheir issues  with this draft. In order to clarify a  some  points
> here
> > are some of thechanges that  we plan tomake to the  next 
> version  of the
> > draft. We hope thiswill help  to clarify  the draft.
> >
> > 1. In section 4.2.1,  previous text:
> > Alternatively, the tunnel end  point  address MAY also be set to
> > the destination data plane address  if the  ingress knows 
> that address
> or
> > the TE Router ID.
> > New  text:
> > Alternatively, the tunnel end point address MAY  also  be set to
> > thedestination data plane  address if the ingress knows 
> that  address.
> >
> > 2. In section 4.2.2 previous text:
> > Alternatively,  the tunnel  sender address MAY also be set 
> to thesender
> > data plane address or the TE  Router ID.
> > New  text:
> > Alternatively, the tunnel sender  address MAY also  be set 
> to thesender
> > data plane  address.
> >
> > 3. at the end of the introduction, we will add  wording  to the last
> line
> > to that effect:
> > Various more complex deployment scenarios can be  
> constructed but  these
> > are currently out of scope as the only GMPLS implementations
> encountered
> > ininteroperability testing or in deployment have  applied  this
> > relationship. Whennew  implementations that include any other
> relationship
> > between controlplane and data plane entities are encountered,   this
> > document would beenhanced as  necessary.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 




Envelope-to: [e-mail]
Delivery-date: Wed, 01 Jun 2005 16:24:22 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: "Diego Caviglia" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Addressing doc
Date: Wed, 1 Jun 2005 18:23:47 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+YWRyaWFuIC0gb2sgLSBpIHRoaW5rIHdlIGFyZSBpbiBzeW5jLiA8QlI+PEJSPjxGT05UIFNJ
WkU9Mj48Qj4mcXVvdDtBZHJpYW4gRmFycmVsJnF1b3Q7ICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVr
Jmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wNi8wMS8yMDA1IDE2OjQ2PC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQgdG8gJnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90
OzwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+JnF1
b3Q7RGllZ28gQ2F2aWdsaWEmcXVvdDsgJmx0O0RpZWdvLkNhdmlnbGlhQG1hcmNvbmkuY29tJmd0
OywgRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTDwvRk9OVD48QlI+IDxG
T05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj4mbHQ7cmljaGFyZC5yYWJiYXRAdXMu
ZnVqaXRzdS5jb20mZ3Q7LCAmbHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OywgJmx0O3NoaW9tb3Rv
LmtvaGVpQGxhYi5udHQuY28uanAmZ3Q7LCAmbHQ7cnBhcG5lamFAaXNvY29yZS5jb20mZ3Q7PC9G
T05UPjxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1Ympl
Y3Q6PC9GT05UPiA8Rk9OVCBTSVpFPTI+UmU6IEFkZHJlc3NpbmcgZG9jPC9GT05UPjxCUj4gPEJS
PjxCUj48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkhpLDxCUj48L0ZPTlQ+
PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7IHdvdWxkIGl0IGJlIHBvc3Np
YmxlIHRoYXQgeW91IHJlZmluZSB0aGUgbm90aW9uIG9mICZxdW90O2FkZHJlc3MgdHJhbnNsYXRp
b24mcXVvdDs8QlI+aW4gdGhlIGNvbnRleHQgb2YgdGhlPEJSPiZndDsgcHJlc2VudCBMTVAgZGlz
Y3Vzc2lvbiBhcyBpIGFtIG5vdCBuZWNlc3NhcmlseSBzdXJlIHNvbWV0aGluZyBzcGVjaWZpYzxC
Uj5uZWVkcyB0byBjb25zaWRlcmVkPEJSPiZndDsgYmVzaWRlIHdoYXQgdGhlIExNUCB0cmFuc3Bv
cnQgZG9jdW1lbnQgYWxyZWFkeSBwcm92aWRlcyAoU2VjdGlvbiA0LjMgZm9yPEJSPmluc3QuKTxC
Uj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5JZiB0aGVyZSBpcyBh
ZGRpdGlvbmFsIGZ1bmN0aW9uIHJlcXVpcmVkLCBpdCB3b24ndCBiZSBpbiB0aGUgYWRkcmVzc2lu
ZzxCUj5kcmFmdC48QlI+SWYgdGhlcmUgaXMgZ3VpZGFuY2UgdG8gb3BlcmF0b3JzIG9yIGltcGxl
bWVudG9ycyBpdCBjYW4gYmUgaW4gdGhlPEJSPmFkZHJlc3NpbmcgZHJhZnQgKGV2ZW4gaWYgaXQg
aXMgb25seSBhIHJlc3RhdGVtZW50IG9mIHdoYXQgaXMgZm91bmQgaW48QlI+YW5vdGhlciBkcmFm
dCBvciBSRkMpLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5D
aGVlcnMsPEJSPkFkcmlhbjxCUj48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2Us
Q291cmllciI+Jmd0OzxCUj4mZ3Q7IHRoYW5rcyw8QlI+Jmd0OzxCUj4mZ3Q7IC0gZGltaXRyaS48
QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyAmcXVvdDtEaWVnbyBDYXZpZ2xpYSZxdW90
OyAmbHQ7RGllZ28uQ2F2aWdsaWFAbWFyY29uaS5jb20mZ3Q7PEJSPiZndDsgU2VudCBieTogb3du
ZXItY2NhbXBAb3BzLmlldGYub3JnPEJSPiZndDsgMDYvMDEvMjAwNSAxNTowOSBaRTI8QlI+Jmd0
OzxCUj4mZ3Q7IFRvOiByaWNoYXJkLnJhYmJhdEB1cy5mdWppdHN1LmNvbTxCUj4mZ3Q7IGNjOiBj
Y2FtcEBvcHMuaWV0Zi5vcmcsIHNoaW9tb3RvLmtvaGVpQGxhYi5udHQuY28uanAsPEJSPnJwYXBu
ZWphQGlzb2NvcmUuY29tPEJSPiZndDsgYmNjOjxCUj4mZ3Q7IFN1YmplY3Q6IFJFOiBBZGRyZXNz
aW5nIGRvYzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgSGkgUmljaGFy
ZCw8QlI+Jmd0OyBJIHRoaW5rIHRoYXQgc29tZSB0ZXh0IHRoYXQgZXhwbGFpbiBob3cgTE1QIGNh
biBiZTxCUj4mZ3Q7IHVzZWQgdG8gdHJhbnNsYXRlIGJldHdlZW4gVEUgbGlua3MgYW5kIGNvbnRy
b2wgcGxhbmUgYWRkcmVzc2VzIHNob3VsZCBiZTxCUj4mZ3Q7IHZlcnkgdmFsdWFibGUuPEJSPiZn
dDs8QlI+Jmd0OyBCVFcgaWYgeW91IHRoaW5rIHRoYXQgdGhlIGV4cGxhbmF0aW9uIGlzIG91dCBv
ZiB0aGUgc2NvcGUgb2YgdGhlIElEIG1heTxCUj5iZTxCUj4mZ3Q7IHNvbWUgdGV4dCB0aGF0IGhp
Z2hsaWdodHMgdGhhdCAmbmJzcDtMTVAgaXMgb25lIG9mIHRoZSBwcm90b2NvbHMgdGhhdCBjb3Vs
ZDxCUj5iZTxCUj4mZ3Q7IHVzZWQgdG8gZG8gYWRkcmVzcyB0cmFuc2xhdGlvbiBiZXR3ZWVuICZu
YnNwO1RFIGxpbmtzIGFuZCBjb250cm9sIHBsYW5lPEJSPiZndDsgYWRkcmVzc2VzIGNhbiBiZSBl
bm91Z2guPEJSPiZndDs8QlI+Jmd0OyBEaWVnbzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4m
Z3Q7PEJSPiZndDs8QlI+Jmd0OyAmcXVvdDtSaWNoYXJkIFJhYmJhdCZxdW90OyAmbHQ7cmljaGFy
ZC5yYWJiYXRAdXMuZnVqaXRzdS5jb20mZ3Q7QG9wcy5pZXRmLm9yZyBvbjxCUj4wMS8wNi8yMDA1
PEJSPiZndDsgMDIuMzguMDg8QlI+Jmd0OzxCUj4mZ3Q7IFNlbnQgYnk6ICZuYnNwOyAmbmJzcDtv
d25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgVG86ICZuYnNw
OyAmbmJzcDsmcXVvdDsnRGllZ28gQ2F2aWdsaWEnJnF1b3Q7ICZsdDtEaWVnby5DYXZpZ2xpYUBt
YXJjb25pLmNvbSZndDssICZxdW90OydcJnF1b3Q7XCZxdW90OydjY2FtcCdcJnF1b3Q7PEJSPiZn
dDsgJmx0O2NjYW1wXCZxdW90OycmcXVvdDs8QlI+Jmd0OyBjYzogJm5ic3A7ICZuYnNwOyZsdDty
aWNoYXJkLnJhYmJhdEB1cy5mdWppdHN1LmNvbSZndDssICZxdW90OydcJnF1b3Q7XCZxdW90OydL
b2hlaSBTaGlvbW90bydcJnF1b3Q7PEJSPiZndDsgJmx0O3NoaW9tb3RvLmtvaGVpXCZxdW90Oycm
cXVvdDssICZxdW90OydcJnF1b3Q7XCZxdW90OydSYWppdiBQYXBuZWphJ1wmcXVvdDsgJmx0O3Jw
YXBuZWphXCZxdW90OycmcXVvdDs8QlI+Jmd0OzxCUj4mZ3Q7IFN1YmplY3Q6ICZuYnNwOyAmbmJz
cDtSRTogQWRkcmVzc2luZyBkb2M8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBIaSAm
bmJzcDtEaWVnbyw8QlI+Jmd0OzxCUj4mZ3Q7IFdlJ3JlICZuYnNwO2N1cnJlbnRseSB3b3JraW5n
IG9uIGFuIHVwZGF0ZSB0bzxCUj4mZ3Q7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYWRkcmVzc2lu
Zy0wMC50eHQuIEkgJm5ic3A7d2FzIHdvbmRlcmluZyBpZiB5b3UgaGF2ZTxCUj5hbnk8QlI+Jmd0
OyBpZGVhcyB3L3IgdG8geW91ciByZXF1ZXN0IGJlbG93PyBBcmUgeW91IGxvb2tpbmcgJm5ic3A7
Zm9yIGFuIGV4cGxhbmF0aW9uIG9mPEJSPmhvdzxCUj4mZ3Q7IExNUCBjb3VsZCBiZSB1c2VkIG9y
IHNpbXBsZSB0ZXh0IHRoYXQgaGlnaGxpZ2h0cyB0aGF0ICZuYnNwO0xNUCBpcyBvbmUgb2YgdGhl
PEJSPiZndDsgcHJvdG9jb2xzIHRoYXQgY291bGQgYmUgdXNlZCB0byBkbyBhZGRyZXNzIHRyYW5z
bGF0aW9uIGJldHdlZW4gJm5ic3A7VEUgbGlua3M8QlI+Jmd0OyBhbmQgY29udHJvbCBwbGFuZSBh
ZGRyZXNzZXM/PEJSPiZndDs8QlI+Jmd0OyBSaWNoYXJkLjxCUj4mZ3Q7PEJSPiZndDsgLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyBGcm9tOiBEaWVnbyBDYXZpZ2xpYSAmbmJzcDtb
bWFpbHRvOkRpZWdvLkNhdmlnbGlhQG1hcmNvbmkuY29tXTxCUj4mZ3Q7IFNlbnQ6IFdlZG5lc2Rh
eSwgQXByaWwgMjcsIDIwMDUgJm5ic3A7ODo0MiBBTTxCUj4mZ3Q7IFRvOiByaWNoYXJkLnJhYmJh
dEB1cy5mdWppdHN1LmNvbTxCUj4mZ3Q7IENjOiAmcXVvdDsmcXVvdDsnY2NhbXAnJnF1b3Q7ICZu
YnNwOyZsdDtjY2FtcCZxdW90OyAmcXVvdDsmcXVvdDsnS29oZWkgU2hpb21vdG8nJnF1b3Q7ICZs
dDtzaGlvbW90by5rb2hlaSZxdW90OyAmcXVvdDsmcXVvdDsnUmFqaXY8QlI+Jmd0OyBQYXBuZWph
JyZxdW90OyAmbmJzcDsmbHQ7cnBhcG5lamEmcXVvdDs8QlI+Jmd0OyBTdWJqZWN0OiBSRTogQWRk
cmVzc2luZyAmbmJzcDtkb2M8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBSaWNoaWFy
ZCw8QlI+Jmd0OyBJTUhPIGFsc28gYSBzZWN0aW9uIChvciBzdWItc2VjdGlvbikgJm5ic3A7ZGVk
aWNhdGVkIHRvPEJSPiZndDsgTE1QIHVzYWdlIGNvdWxkIGJlIHZlcnkgdXNlZnVsIGluIG9yZGVy
IHRvIGNsYXJpZnkgaG93IExNUCBjYW4gJm5ic3A7aGVscCBpbjxCUj4mZ3Q7IGFkZHJlc3Npbmcg
cmVzb2x1dGlvbi48QlI+Jmd0OzxCUj4mZ3Q7IEJSPEJSPiZndDs8QlI+Jmd0OyBEPEJSPiZndDs8
QlI+Jmd0OyBTZW50IGJ5OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgb3duZXItY2NhbXBA
b3BzLmlldGYub3JnPEJSPiZndDs8QlI+Jmd0OyBUbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZxdW90OydjY2FtcCcmcXVvdDsgJm5ic3A7Jmx0O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8
QlI+Jmd0OyBjYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7J0tvaGVpIFNoaW9t
b3RvJyZxdW90OyAmbHQ7c2hpb21vdG8ua29oZWlAbGFiLm50dC5jby5qcCZndDssICZxdW90OydS
aWNoYXJkPEJSPiZndDsgUmFiYmF0JyZxdW90OyAmbHQ7cmljaGFyZC5yYWJiYXRAdXMuZnVqaXRz
dS5jb20mZ3Q7LCAmcXVvdDsnUmFqaXYgUGFwbmVqYScmcXVvdDs8QlI+Jmd0OyAmbHQ7cnBhcG5l
amFAaXNvY29yZS5jb20mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBTdWJqZWN0OiAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgUkU6IEFkZHJlc3NpbmcgJm5ic3A7ZG9jPEJSPiZndDs8QlI+Jmd0OzxC
Uj4mZ3Q7PEJSPiZndDsgSGkgYWxsLDxCUj4mZ3Q7PEJSPiZndDsgVGhlIGVkaXRvcnMgaGF2ZSBi
ZWVuIGhhdmluZyB2YXJpb3VzIGRpc2N1c3Npb25zICZuYnNwO3dpdGggcGVvcGxlICZuYnNwO2Fi
b3V0PEJSPnNvbWU8QlI+Jmd0OyBvZnRoZWlyIGlzc3VlcyAmbmJzcDt3aXRoIHRoaXMgZHJhZnQu
IEluIG9yZGVyIHRvIGNsYXJpZnkgYSAmbmJzcDtzb21lICZuYnNwO3BvaW50czxCUj5oZXJlPEJS
PiZndDsgYXJlIHNvbWUgb2YgdGhlY2hhbmdlcyB0aGF0ICZuYnNwO3dlIHBsYW4gdG9tYWtlIHRv
IHRoZSAmbmJzcDtuZXh0IHZlcnNpb24gJm5ic3A7b2YgdGhlPEJSPiZndDsgZHJhZnQuIFdlIGhv
cGUgdGhpc3dpbGwgaGVscCAmbmJzcDt0byBjbGFyaWZ5ICZuYnNwO3RoZSBkcmFmdC48QlI+Jmd0
OzxCUj4mZ3Q7IDEuIEluIHNlY3Rpb24gNC4yLjEsICZuYnNwO3ByZXZpb3VzIHRleHQ6PEJSPiZn
dDsgQWx0ZXJuYXRpdmVseSwgdGhlIHR1bm5lbCBlbmQgJm5ic3A7cG9pbnQgJm5ic3A7YWRkcmVz
cyBNQVkgYWxzbyBiZSBzZXQgdG88QlI+Jmd0OyB0aGUgZGVzdGluYXRpb24gZGF0YSBwbGFuZSBh
ZGRyZXNzICZuYnNwO2lmIHRoZSAmbmJzcDtpbmdyZXNzIGtub3dzIHRoYXQgYWRkcmVzczxCUj5v
cjxCUj4mZ3Q7IHRoZSBURSBSb3V0ZXIgSUQuPEJSPiZndDsgTmV3ICZuYnNwO3RleHQ6PEJSPiZn
dDsgQWx0ZXJuYXRpdmVseSwgdGhlIHR1bm5lbCBlbmQgcG9pbnQgYWRkcmVzcyBNQVkgJm5ic3A7
YWxzbyAmbmJzcDtiZSBzZXQgdG88QlI+Jmd0OyB0aGVkZXN0aW5hdGlvbiBkYXRhIHBsYW5lICZu
YnNwO2FkZHJlc3MgaWYgdGhlIGluZ3Jlc3Mga25vd3MgdGhhdCAmbmJzcDthZGRyZXNzLjxCUj4m
Z3Q7PEJSPiZndDsgMi4gSW4gc2VjdGlvbiA0LjIuMiBwcmV2aW91cyB0ZXh0OjxCUj4mZ3Q7IEFs
dGVybmF0aXZlbHksICZuYnNwO3RoZSB0dW5uZWwgJm5ic3A7c2VuZGVyIGFkZHJlc3MgTUFZIGFs
c28gYmUgc2V0IHRvIHRoZXNlbmRlcjxCUj4mZ3Q7IGRhdGEgcGxhbmUgYWRkcmVzcyBvciB0aGUg
VEUgJm5ic3A7Um91dGVyIElELjxCUj4mZ3Q7IE5ldyAmbmJzcDt0ZXh0OjxCUj4mZ3Q7IEFsdGVy
bmF0aXZlbHksIHRoZSB0dW5uZWwgc2VuZGVyICZuYnNwO2FkZHJlc3MgTUFZIGFsc28gJm5ic3A7
YmUgc2V0IHRvIHRoZXNlbmRlcjxCUj4mZ3Q7IGRhdGEgcGxhbmUgJm5ic3A7YWRkcmVzcy48QlI+
Jmd0OzxCUj4mZ3Q7IDMuIGF0IHRoZSBlbmQgb2YgdGhlIGludHJvZHVjdGlvbiwgd2Ugd2lsbCBh
ZGQgJm5ic3A7d29yZGluZyAmbmJzcDt0byB0aGUgbGFzdDxCUj5saW5lPEJSPiZndDsgdG8gdGhh
dCBlZmZlY3Q6PEJSPiZndDsgVmFyaW91cyBtb3JlIGNvbXBsZXggZGVwbG95bWVudCBzY2VuYXJp
b3MgY2FuIGJlICZuYnNwO2NvbnN0cnVjdGVkIGJ1dCAmbmJzcDt0aGVzZTxCUj4mZ3Q7IGFyZSBj
dXJyZW50bHkgb3V0IG9mIHNjb3BlIGFzIHRoZSBvbmx5IEdNUExTIGltcGxlbWVudGF0aW9uczxC
Uj5lbmNvdW50ZXJlZDxCUj4mZ3Q7IGluaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIG9yIGluIGRl
cGxveW1lbnQgaGF2ZSAmbmJzcDthcHBsaWVkICZuYnNwO3RoaXM8QlI+Jmd0OyByZWxhdGlvbnNo
aXAuIFdoZW5uZXcgJm5ic3A7aW1wbGVtZW50YXRpb25zIHRoYXQgaW5jbHVkZSBhbnkgb3RoZXI8
QlI+cmVsYXRpb25zaGlwPEJSPiZndDsgYmV0d2VlbiBjb250cm9scGxhbmUgYW5kIGRhdGEgcGxh
bmUgZW50aXRpZXMgYXJlIGVuY291bnRlcmVkLCAmbmJzcDsgdGhpczxCUj4mZ3Q7IGRvY3VtZW50
IHdvdWxkIGJlZW5oYW5jZWQgYXMgJm5ic3A7bmVjZXNzYXJ5LjxCUj4mZ3Q7PEJSPiZndDs8QlI+
Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzwvRk9O
VD48L1A+



Envelope-to: [e-mail]
Delivery-date: Wed, 01 Jun 2005 16:19:52 +0000
Message-ID: <05b101c566c5$dc0d0b40$23849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Addressing doc
Date: Wed, 1 Jun 2005 16:46:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

> would it be possible that you refine the notion of "address translation"
in the context of the
> present LMP discussion as i am not necessarily sure something specific
needs to considered
> beside what the LMP transport document already provides (Section 4.3 for
inst.)

If there is additional function required, it won't be in the addressing
draft.
If there is guidance to operators or implementors it can be in the
addressing draft (even if it is only a restatement of what is found in
another draft or RFC).

Cheers,
Adrian


>
> thanks,
>
> - dimitri.
>
>
>
> "Diego Caviglia" <[e-mail]>
> Sent by: [e-mail]
> 06/01/2005 15:09 ZE2
>
> To: [e-mail]
> cc: [e-mail], [e-mail],
[e-mail]
> bcc:
> Subject: RE: Addressing doc
>
>
>
>
> Hi Richard,
> I think that some text that explain how LMP can be
> used to translate between TE links and control plane addresses should be
> very valuable.
>
> BTW if you think that the explanation is out of the scope of the ID may
be
> some text that highlights that  LMP is one of the protocols that could
be
> used to do address translation between  TE links and control plane
> addresses can be enough.
>
> Diego
>
>
>
>
>
> "Richard Rabbat" <[e-mail]>@ops.ietf.org on
01/06/2005
> 02.38.08
>
> Sent by:    [e-mail]
>
>
> To:    "'Diego Caviglia'" <[e-mail]>, "'\"\"'ccamp'\"
> <ccamp\"'"
> cc:    <[e-mail]>, "'\"\"'Kohei Shiomoto'\"
> <shiomoto.kohei\"'", "'\"\"'Rajiv Papneja'\" <rpapneja\"'"
>
> Subject:    RE: Addressing doc
>
>
>
> Hi  Diego,
>
> We're  currently working on an update to
> draft-ietf-ccamp-gmpls-addressing-00.txt. I  was wondering if you have
any
> ideas w/r to your request below? Are you looking  for an explanation of
how
> LMP could be used or simple text that highlights that  LMP is one of the
> protocols that could be used to do address translation between  TE links
> and control plane addresses?
>
> Richard.
>
> -----Original Message-----
> From: Diego Caviglia  [mailto:[e-mail]]
> Sent: Wednesday, April 27, 2005  8:42 AM
> To: [e-mail]
> Cc: ""'ccamp'"  <ccamp" ""'Kohei Shiomoto'" <shiomoto.kohei" ""'Rajiv
> Papneja'"  <rpapneja"
> Subject: RE: Addressing  doc
>
>
>
> Richiard,
> IMHO also a section (or sub-section)  dedicated to
> LMP usage could be very useful in order to clarify how LMP can  help in
> addressing resolution.
>
> BR
>
> D
>
> Sent by:         [e-mail]
>
> To:         "'ccamp'"  <[e-mail]>
> cc:        "'Kohei Shiomoto'" <[e-mail]>, "'Richard
> Rabbat'" <[e-mail]>, "'Rajiv Papneja'"
> <[e-mail]>
>
> Subject:         RE: Addressing  doc
>
>
>
> Hi all,
>
> The editors have been having various discussions  with people  about
some
> oftheir issues  with this draft. In order to clarify a  some  points
here
> are some of thechanges that  we plan tomake to the  next version  of the
> draft. We hope thiswill help  to clarify  the draft.
>
> 1. In section 4.2.1,  previous text:
> Alternatively, the tunnel end  point  address MAY also be set to
> the destination data plane address  if the  ingress knows that address
or
> the TE Router ID.
> New  text:
> Alternatively, the tunnel end point address MAY  also  be set to
> thedestination data plane  address if the ingress knows that  address.
>
> 2. In section 4.2.2 previous text:
> Alternatively,  the tunnel  sender address MAY also be set to thesender
> data plane address or the TE  Router ID.
> New  text:
> Alternatively, the tunnel sender  address MAY also  be set to thesender
> data plane  address.
>
> 3. at the end of the introduction, we will add  wording  to the last
line
> to that effect:
> Various more complex deployment scenarios can be  constructed but  these
> are currently out of scope as the only GMPLS implementations
encountered
> ininteroperability testing or in deployment have  applied  this
> relationship. Whennew  implementations that include any other
relationship
> between controlplane and data plane entities are encountered,   this
> document would beenhanced as  necessary.
>
>
>
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 01 Jun 2005 14:50:19 +0000
Message-ID: <01fd01c566b9$14adbb00$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)
Date: Wed, 1 Jun 2005 10:49:14 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian,

Thanks for taking my comments into consideration.

The text WRT domain boundary path computation I will provide shortly.

Igor

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>; "Dimitri Papadimitriou"
<[e-mail]>; "Dimitri Papadimitriou"
<[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>; <[e-mail]>
Sent: Wednesday, June 01, 2005 7:20 AM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)


> Hi,
>
> Some proposed resolutions...
>
> > > > > Section 1.1 Nested domains:
> > > > >
> > > > > For further consideration of nested domains see [MRN]
> > > > >
> > > > > MRN does not cover nested domains, ITU hierarchical routing does.
> > > > > This is a hole in (G)MPLS TE
>
> The citation is perceived as too definitive. That is, while MRN may cover
> some cases of nested domains, it does not cover all cases.
>
> This will be clarified in the revised I-D.
>
> > > > > Section 2.1 LSP Nesting
> > > > >
> > > > > FA and FA-LSP are not accurate terms for describing LSP nesting,
> > > > > which is using an LSP created in one network layer as a data link
> > > > > in other layer(s).
>
> We have established two points.
> 1. Discussion of layering is not material
> 2. The terms FA and FA-LSP are too limiting and should be replaced with
> "TE link" and "hierarchical LSP".
>
> > > > > Section 2.3 LSP stitching
> > > > >
> > > > > Again, a stitching segment created in one domain and advertised as
> > > > > a TE link into a different domain is not an FA, it is just a
> > > > > "regular" TE link not distinguishable from a TE link supported by
> > > > > static data link(s)
>
> As with nesting, the term "FA" needs to be replaced with "TE link".
>
> > > > > Section 3.3 Domain Boundary Computation
> > > > >
> > > > > I'd like to see a clause here stating about necessity of avoiding
> > > > > loops with the LSP head segment during domain boundary path
> > > > > computation and describing some mechanisms how this could be
> achieved.
>
> Igor will supply some text that highlights the danger of loops in domain
> boundary computation, and notes that such dangers only exist in non-linear
> (i.e. mesh) domain topologies, and even then, only when the domain
> sequence (expressed as the sequence of domain boundaries) has not been
> supplied in the ERO.
>
> Although sorely tempted, he will not include discussion of solutions!
>
> > > > > Section 5.10 Applicability to Non-Packet Technologies
> > > > >
> > > > > I'd like to see in this section a statement saying that earlier
> > > > > described FRR does not work well in non-packet environments and
> > > > > other techniques should be considered for inter-domain service
> > > > > recovery. One of such techniques is the segment recovery, which
> > > > > IMHO works equally well in packet and non-packet environments
>
> Resolved by text suggetsed in previous emails.
>
> Thanks,
> Adrian
>




Envelope-to: [e-mail]
Delivery-date: Wed, 01 Jun 2005 14:10:04 +0000
To: "Diego Caviglia" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Addressing doc
Date: Wed, 1 Jun 2005 16:08:06 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmRpZWdvLCByaWNoYXJkPC9GT05UPjwv
UD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+d291bGQgaXQgYmUgcG9zc2libGUg
dGhhdCB5b3UgcmVmaW5lIHRoZSBub3Rpb24gb2YgJnF1b3Q7YWRkcmVzcyB0cmFuc2xhdGlvbiZx
dW90OyBpbiB0aGUgY29udGV4dCBvZiB0aGUgcHJlc2VudCBMTVAgZGlzY3Vzc2lvbiBhcyBpIGFt
IG5vdCBuZWNlc3NhcmlseSBzdXJlIHNvbWV0aGluZyBzcGVjaWZpYyBuZWVkcyB0byBjb25zaWRl
cmVkIGJlc2lkZSB3aGF0IHRoZSBMTVAgdHJhbnNwb3J0IGRvY3VtZW50IGFscmVhZHkgcHJvdmlk
ZXMgKFNlY3Rpb24gNC4zIGZvciBpbnN0Lik8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj50aGFua3MsPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2Us
Q291cmllciI+LSBkaW1pdHJpLjwvRk9OVD48L1A+PFA+Jm5ic3A7PEJSPjxCUj48Rk9OVCBTSVpF
PTI+PEI+JnF1b3Q7RGllZ28gQ2F2aWdsaWEmcXVvdDsgJmx0O0RpZWdvLkNhdmlnbGlhQG1hcmNv
bmkuY29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2Ft
cEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wNi8wMS8yMDA1IDE1OjA5IFpF
MjwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+cmlj
aGFyZC5yYWJiYXRAdXMuZnVqaXRzdS5jb208L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9G
T05UPiA8Rk9OVCBTSVpFPTI+Y2NhbXBAb3BzLmlldGYub3JnLCBzaGlvbW90by5rb2hlaUBsYWIu
bnR0LmNvLmpwLCBycGFwbmVqYUBpc29jb3JlLmNvbTwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5i
Y2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0y
PlJFOiBBZGRyZXNzaW5nIGRvYzwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIEZBQ0U9
Ik1vbm9zcGFjZSxDb3VyaWVyIj5IaSBSaWNoYXJkLDxCUj5JIHRoaW5rIHRoYXQgc29tZSB0ZXh0
IHRoYXQgZXhwbGFpbiBob3cgTE1QIGNhbiBiZTwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3Nw
YWNlLENvdXJpZXIiPnVzZWQgdG8gdHJhbnNsYXRlIGJldHdlZW4gVEUgbGlua3MgYW5kIGNvbnRy
b2wgcGxhbmUgYWRkcmVzc2VzIHNob3VsZCBiZTxCUj52ZXJ5IHZhbHVhYmxlLjxCUj48L0ZPTlQ+
PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5CVFcgaWYgeW91IHRoaW5rIHRoYXQg
dGhlIGV4cGxhbmF0aW9uIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhlIElEIG1heSBiZTxCUj5z
b21lIHRleHQgdGhhdCBoaWdobGlnaHRzIHRoYXQgJm5ic3A7TE1QIGlzIG9uZSBvZiB0aGUgcHJv
dG9jb2xzIHRoYXQgY291bGQgYmU8QlI+dXNlZCB0byBkbyBhZGRyZXNzIHRyYW5zbGF0aW9uIGJl
dHdlZW4gJm5ic3A7VEUgbGlua3MgYW5kIGNvbnRyb2wgcGxhbmU8QlI+YWRkcmVzc2VzIGNhbiBi
ZSBlbm91Z2guPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkRp
ZWdvPEJSPjwvRk9OVD48QlI+PEJSPjxCUj48QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD
b3VyaWVyIj4mcXVvdDtSaWNoYXJkIFJhYmJhdCZxdW90OyAmbHQ7cmljaGFyZC5yYWJiYXRAdXMu
ZnVqaXRzdS5jb20mZ3Q7QG9wcy5pZXRmLm9yZyBvbiAwMS8wNi8yMDA1PEJSPjAyLjM4LjA4PEJS
PjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlNlbnQgYnk6ICZuYnNw
OyAmbmJzcDtvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8QlI+PC9GT05UPjxCUj48QlI+PEZPTlQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlRvOiAmbmJzcDsgJm5ic3A7JnF1b3Q7J0RpZWdvIENh
dmlnbGlhJyZxdW90OyAmbHQ7RGllZ28uQ2F2aWdsaWFAbWFyY29uaS5jb20mZ3Q7LCAmcXVvdDsn
XCZxdW90O1wmcXVvdDsnY2NhbXAnXCZxdW90OzxCUj4mbHQ7Y2NhbXBcJnF1b3Q7JyZxdW90Ozwv
Rk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmNjOiAmbmJzcDsgJm5ic3A7
Jmx0O3JpY2hhcmQucmFiYmF0QHVzLmZ1aml0c3UuY29tJmd0OywgJnF1b3Q7J1wmcXVvdDtcJnF1
b3Q7J0tvaGVpIFNoaW9tb3RvJ1wmcXVvdDs8QlI+Jmx0O3NoaW9tb3RvLmtvaGVpXCZxdW90Oycm
cXVvdDssICZxdW90OydcJnF1b3Q7XCZxdW90OydSYWppdiBQYXBuZWphJ1wmcXVvdDsgJmx0O3Jw
YXBuZWphXCZxdW90OycmcXVvdDs8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2Us
Q291cmllciI+U3ViamVjdDogJm5ic3A7ICZuYnNwO1JFOiBBZGRyZXNzaW5nIGRvYzxCUj48L0ZP
TlQ+PEJSPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkhpICZuYnNwO0Rp
ZWdvLDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5XZSdyZSAm
bmJzcDtjdXJyZW50bHkgd29ya2luZyBvbiBhbiB1cGRhdGUgdG88QlI+ZHJhZnQtaWV0Zi1jY2Ft
cC1nbXBscy1hZGRyZXNzaW5nLTAwLnR4dC4gSSAmbmJzcDt3YXMgd29uZGVyaW5nIGlmIHlvdSBo
YXZlIGFueTxCUj5pZGVhcyB3L3IgdG8geW91ciByZXF1ZXN0IGJlbG93PyBBcmUgeW91IGxvb2tp
bmcgJm5ic3A7Zm9yIGFuIGV4cGxhbmF0aW9uIG9mIGhvdzxCUj5MTVAgY291bGQgYmUgdXNlZCBv
ciBzaW1wbGUgdGV4dCB0aGF0IGhpZ2hsaWdodHMgdGhhdCAmbmJzcDtMTVAgaXMgb25lIG9mIHRo
ZTxCUj5wcm90b2NvbHMgdGhhdCBjb3VsZCBiZSB1c2VkIHRvIGRvIGFkZHJlc3MgdHJhbnNsYXRp
b24gYmV0d2VlbiAmbmJzcDtURSBsaW5rczxCUj5hbmQgY29udHJvbCBwbGFuZSBhZGRyZXNzZXM/
PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlJpY2hhcmQuPEJS
PjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tPEJSPkZyb206IERpZWdvIENhdmlnbGlhICZuYnNwO1ttYWlsdG86RGllZ28u
Q2F2aWdsaWFAbWFyY29uaS5jb21dPEJSPlNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjcsIDIwMDUg
Jm5ic3A7ODo0MiBBTTxCUj5UbzogcmljaGFyZC5yYWJiYXRAdXMuZnVqaXRzdS5jb208QlI+Q2M6
ICZxdW90OyZxdW90OydjY2FtcCcmcXVvdDsgJm5ic3A7Jmx0O2NjYW1wJnF1b3Q7ICZxdW90OyZx
dW90OydLb2hlaSBTaGlvbW90bycmcXVvdDsgJmx0O3NoaW9tb3RvLmtvaGVpJnF1b3Q7ICZxdW90
OyZxdW90OydSYWppdjxCUj5QYXBuZWphJyZxdW90OyAmbmJzcDsmbHQ7cnBhcG5lamEmcXVvdDs8
QlI+U3ViamVjdDogUkU6IEFkZHJlc3NpbmcgJm5ic3A7ZG9jPEJSPjwvRk9OVD48QlI+PEJSPjxC
Uj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+UmljaGlhcmQsPEJSPklNSE8gYWxzbyBh
IHNlY3Rpb24gKG9yIHN1Yi1zZWN0aW9uKSAmbmJzcDtkZWRpY2F0ZWQgdG88L0ZPTlQ+PEJSPjxG
T05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5MTVAgdXNhZ2UgY291bGQgYmUgdmVyeSB1c2Vm
dWwgaW4gb3JkZXIgdG8gY2xhcmlmeSBob3cgTE1QIGNhbiAmbmJzcDtoZWxwIGluPEJSPmFkZHJl
c3NpbmcgcmVzb2x1dGlvbi48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291
cmllciI+QlI8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+RDxC
Uj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5TZW50IGJ5OiAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8QlI+
PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VG86ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90OydjY2FtcCcmcXVvdDsgJm5ic3A7Jmx0O2NjYW1w
QG9wcy5pZXRmLm9yZyZndDs8QlI+Y2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90
OydLb2hlaSBTaGlvbW90bycmcXVvdDsgJmx0O3NoaW9tb3RvLmtvaGVpQGxhYi5udHQuY28uanAm
Z3Q7LCAmcXVvdDsnUmljaGFyZDxCUj5SYWJiYXQnJnF1b3Q7ICZsdDtyaWNoYXJkLnJhYmJhdEB1
cy5mdWppdHN1LmNvbSZndDssICZxdW90OydSYWppdiBQYXBuZWphJyZxdW90OzxCUj4mbHQ7cnBh
cG5lamFAaXNvY29yZS5jb20mZ3Q7PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPlN1YmplY3Q6ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwO1JFOiBB
ZGRyZXNzaW5nICZuYnNwO2RvYzxCUj48L0ZPTlQ+PEJSPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9u
b3NwYWNlLENvdXJpZXIiPkhpJm5ic3A7YWxsLDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1v
bm9zcGFjZSxDb3VyaWVyIj5UaGUgZWRpdG9ycyBoYXZlIGJlZW4gaGF2aW5nIHZhcmlvdXMgZGlz
Y3Vzc2lvbnMgJm5ic3A7d2l0aCBwZW9wbGUgJm5ic3A7YWJvdXQgc29tZTxCUj5vZnRoZWlyIGlz
c3VlcyAmbmJzcDt3aXRoIHRoaXMgZHJhZnQuJm5ic3A7SW4gb3JkZXIgdG8gY2xhcmlmeSBhICZu
YnNwO3NvbWUgJm5ic3A7cG9pbnRzIGhlcmU8QlI+YXJlIHNvbWUgb2YgdGhlY2hhbmdlcyB0aGF0
ICZuYnNwO3dlIHBsYW4gdG9tYWtlIHRvIHRoZSAmbmJzcDtuZXh0IHZlcnNpb24gJm5ic3A7b2Yg
dGhlPEJSPmRyYWZ0LiBXZSBob3BlIHRoaXN3aWxsIGhlbHAgJm5ic3A7dG8mbmJzcDtjbGFyaWZ5
ICZuYnNwO3RoZSBkcmFmdC48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291
cmllciI+MS4gSW4gc2VjdGlvbiA0LjIuMSwgJm5ic3A7cHJldmlvdXMgdGV4dDo8QlI+QWx0ZXJu
YXRpdmVseSwgdGhlIHR1bm5lbCBlbmQgJm5ic3A7cG9pbnQgJm5ic3A7YWRkcmVzcyBNQVkgYWxz
byBiZSBzZXQgdG88L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj50aGUm
bmJzcDtkZXN0aW5hdGlvbiBkYXRhIHBsYW5lIGFkZHJlc3MgJm5ic3A7aWYgdGhlICZuYnNwO2lu
Z3Jlc3Mga25vd3MgdGhhdCBhZGRyZXNzIG9yPEJSPnRoZSBURSBSb3V0ZXIgSUQuPEJSPk5ldyAm
bmJzcDt0ZXh0OjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkFsdGVy
bmF0aXZlbHksIHRoZSB0dW5uZWwgZW5kIHBvaW50IGFkZHJlc3MgTUFZICZuYnNwO2Fsc28gJm5i
c3A7YmUgc2V0IHRvPEJSPnRoZWRlc3RpbmF0aW9uIGRhdGEgcGxhbmUgJm5ic3A7YWRkcmVzcyBp
ZiB0aGUgaW5ncmVzcyBrbm93cyB0aGF0ICZuYnNwO2FkZHJlc3MuPEJSPjwvRk9OVD48QlI+PEZP
TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjIuIEluIHNlY3Rpb24gNC4yLjImbmJzcDtwcmV2
aW91cyB0ZXh0OjxCUj5BbHRlcm5hdGl2ZWx5LCAmbmJzcDt0aGUgdHVubmVsICZuYnNwO3NlbmRl
ciBhZGRyZXNzIE1BWSBhbHNvIGJlIHNldCB0byB0aGVzZW5kZXI8L0ZPTlQ+PEJSPjxGT05UIEZB
Q0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5kYXRhIHBsYW5lIGFkZHJlc3Mgb3IgdGhlIFRFICZuYnNw
O1JvdXRlciBJRC48QlI+TmV3ICZuYnNwO3RleHQ6PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25v
c3BhY2UsQ291cmllciI+QWx0ZXJuYXRpdmVseSwgdGhlIHR1bm5lbCBzZW5kZXIgJm5ic3A7YWRk
cmVzcyBNQVkgYWxzbyAmbmJzcDtiZSBzZXQgdG8gdGhlc2VuZGVyPEJSPmRhdGEgcGxhbmUgJm5i
c3A7YWRkcmVzcy48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+
My4mbmJzcDthdCB0aGUgZW5kIG9mIHRoZSBpbnRyb2R1Y3Rpb24sJm5ic3A7d2Ugd2lsbCBhZGQg
Jm5ic3A7d29yZGluZyAmbmJzcDt0byB0aGUgbGFzdCBsaW5lPEJSPnRvIHRoYXQgZWZmZWN0OjxC
Uj5WYXJpb3VzIG1vcmUgY29tcGxleCBkZXBsb3ltZW50IHNjZW5hcmlvcyBjYW4gYmUgJm5ic3A7
Y29uc3RydWN0ZWQgYnV0ICZuYnNwO3RoZXNlPEJSPmFyZSBjdXJyZW50bHkgb3V0IG9mIHNjb3Bl
Jm5ic3A7YXMgdGhlIG9ubHkmbmJzcDtHTVBMUyBpbXBsZW1lbnRhdGlvbnMgJm5ic3A7ZW5jb3Vu
dGVyZWQ8QlI+aW5pbnRlcm9wZXJhYmlsaXR5IHRlc3Rpbmcgb3IgaW4gZGVwbG95bWVudCBoYXZl
ICZuYnNwO2FwcGxpZWQgJm5ic3A7dGhpczxCUj5yZWxhdGlvbnNoaXAuJm5ic3A7V2hlbm5ldyAm
bmJzcDtpbXBsZW1lbnRhdGlvbnMgdGhhdCBpbmNsdWRlIGFueSBvdGhlciAmbmJzcDtyZWxhdGlv
bnNoaXA8QlI+YmV0d2VlbiBjb250cm9scGxhbmUgYW5kIGRhdGEgcGxhbmUgZW50aXRpZXMgYXJl
IGVuY291bnRlcmVkLCAmbmJzcDsmbmJzcDt0aGlzPEJSPmRvY3VtZW50Jm5ic3A7d291bGQgYmVl
bmhhbmNlZCBhcyAmbmJzcDtuZWNlc3NhcnkuPEJSPjwvRk9OVD48QlI+PEJSPjxCUj48QlI+PEJS
PjxCUj48QlI+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Wed, 01 Jun 2005 13:10:36 +0000
Sensitivity: 
Subject: RE: Addressing doc
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 1 Jun 2005 15:09:14 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

Hi Richard,
                        I think that some text that explain how LMP can=
 be
used to translate between TE links and control plane addresses should b=
e
very valuable.

BTW if you think that the explanation is out of the scope of the ID may=
 be
some text that highlights that  LMP is one of the protocols that could =
be
used to do address translation between  TE links and control plane
addresses can be enough.

Diego





"Richard Rabbat" <[e-mail]>@ops.ietf.org on 01/06/=
2005
02.38.08

Sent by:    [e-mail]


To:    "'Diego Caviglia'" <[e-mail]>, "'\"\"'ccamp'\"=

       <ccamp\"'"
cc:    <[e-mail]>, "'\"\"'Kohei Shiomoto'\"
       <shiomoto.kohei\"'", "'\"\"'Rajiv Papneja'\" <rpapneja\"'"

Subject:    RE: Addressing doc



Hi  Diego,

We're  currently working on an update to
draft-ietf-ccamp-gmpls-addressing-00.txt. I  was wondering if you have =
any
ideas w/r to your request below? Are you looking  for an explanation of=
 how
LMP could be used or simple text that highlights that  LMP is one of th=
e
protocols that could be used to do address translation between  TE link=
s
and control plane addresses?

Richard.

-----Original Message-----
From: Diego Caviglia  [mailto:[e-mail]]
Sent: Wednesday, April 27, 2005  8:42 AM
To: [e-mail]
Cc: ""'ccamp'"  <ccamp"; ""'Kohei Shiomoto'" <shiomoto.kohei"; ""'Rajiv=

Papneja'"  <rpapneja"
Subject: RE: Addressing  doc



Richiard,
=A0 =A0 =A0 =A0 =A0 =A0  =A0 =A0 =A0 =A0 =A0IMHO also a section (or sub=
-section)  dedicated to
LMP usage could be very useful in order to clarify how LMP can  help in=

addressing resolution.

BR

D

Sent by: =A0 =A0 =A0  =[e-mail]

To: =A0 =A0 =A0  =A0"'ccamp'"  <[e-mail]>
cc: =A0 =A0 =A0 =A0"'Kohei Shiomoto'" <[e-mail]>, "=
'Richard
Rabbat'" <[e-mail]>, "'Rajiv Papneja'"
<[e-mail]>

Subject: =A0  =A0 =A0 =A0RE: Addressing  doc



Hi=A0all,

The editors have been having various discussions =A0with people  about =
some
oftheir issues =A0with this draft.=A0In order to clarify a  some =A0poi=
nts here
are some of thechanges that =A0we plan tomake to the  next version =A0o=
f the
draft. We hope thiswill help =A0to=A0clarify  the draft.

1. In section 4.2.1, =A0previous text:
=A0=A0 Alternatively, the tunnel end  point =A0address MAY also be set =
to
the=A0destination data plane address  if the =A0ingress knows that addr=
ess or
the TE Router ID.
New =A0text:
=A0=A0 Alternatively, the tunnel end point address MAY =A0also  be set =
to
thedestination data plane =A0address if the ingress knows that  address=
.

2. In section 4.2.2=A0previous text:
=A0=A0 Alternatively, =A0the tunnel  sender address MAY also be set to =
thesender
data plane address or the TE  Router ID.
New =A0text:
=A0=A0 Alternatively, the tunnel sender  address MAY also =A0be set to =
thesender
data plane =A0address.

3.=A0at the end of the introduction,=A0we will add =A0wording  to the l=
ast line
to that effect:
Various more complex deployment scenarios can be =A0constructed but  th=
ese
are currently out of scope=A0as the only=A0GMPLS implementations  encou=
ntered
ininteroperability testing or in deployment have =A0applied  this
relationship.=A0Whennew =A0implementations that include any other  rela=
tionship
between controlplane and data plane entities are encountered,  =A0this
document=A0would beenhanced as =A0necessary.






=





Envelope-to: [e-mail]
Delivery-date: Wed, 01 Jun 2005 11:23:49 +0000
Message-ID: <054901c5669c$749c2a50$23849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd)
Date: Wed, 1 Jun 2005 12:20:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Some proposed resolutions...

> > > > Section 1.1 Nested domains:
> > > >
> > > > For further consideration of nested domains see [MRN]
> > > >
> > > > MRN does not cover nested domains, ITU hierarchical routing does.
> > > > This is a hole in (G)MPLS TE

The citation is perceived as too definitive. That is, while MRN may cover
some cases of nested domains, it does not cover all cases.

This will be clarified in the revised I-D.

> > > > Section 2.1 LSP Nesting
> > > >
> > > > FA and FA-LSP are not accurate terms for describing LSP nesting,
> > > > which is using an LSP created in one network layer as a data link
> > > > in other layer(s).

We have established two points.
1. Discussion of layering is not material
2. The terms FA and FA-LSP are too limiting and should be replaced with
"TE link" and "hierarchical LSP".

> > > > Section 2.3 LSP stitching
> > > >
> > > > Again, a stitching segment created in one domain and advertised as
> > > > a TE link into a different domain is not an FA, it is just a
> > > > "regular" TE link not distinguishable from a TE link supported by
> > > > static data link(s)

As with nesting, the term "FA" needs to be replaced with "TE link".

> > > > Section 3.3 Domain Boundary Computation
> > > >
> > > > I'd like to see a clause here stating about necessity of avoiding
> > > > loops with the LSP head segment during domain boundary path
> > > > computation and describing some mechanisms how this could be
achieved.

Igor will supply some text that highlights the danger of loops in domain
boundary computation, and notes that such dangers only exist in non-linear
(i.e. mesh) domain topologies, and even then, only when the domain
sequence (expressed as the sequence of domain boundaries) has not been
supplied in the ERO.

Although sorely tempted, he will not include discussion of solutions!

> > > > Section 5.10 Applicability to Non-Packet Technologies
> > > >
> > > > I'd like to see in this section a statement saying that earlier
> > > > described FRR does not work well in non-packet environments and
> > > > other techniques should be considered for inter-domain service
> > > > recovery. One of such techniques is the segment recovery, which
> > > > IMHO works equally well in packet and non-packet environments

Resolved by text suggetsed in previous emails.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 01 Jun 2005 00:41:18 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Diego Caviglia'" <[e-mail]>, "'\"\"'ccamp'\" <ccamp\"'" <[e-mail]>
Cc: <[e-mail]>, "'\"\"'Kohei Shiomoto'\" <shiomoto.kohei\"'" <[e-mail]>, "'\"\"'Rajiv Papneja'\" <rpapneja\"'" <[e-mail]>
Subject: RE: Addressing doc
Date: Tue, 31 May 2005 17:38:08 -0700
Message-ID: <00e301c56642$3282ba30$3e3ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E4_01C56607.8623E230"

This is a multi-part message in MIME format.

------=_NextPart_000_00E4_01C56607.8623E230
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Diego,
=20
We're currently working on an update to
draft-ietf-ccamp-gmpls-addressing-00.txt. I was wondering if you have =
any
ideas w/r to your request below? Are you looking for an explanation of =
how
LMP could be used or simple text that highlights that LMP is one of the
protocols that could be used to do address translation between TE links =
and
control plane addresses?
=20
Richard.
=20

-----Original Message-----
From: Diego Caviglia [mailto:[e-mail]]=20
Sent: Wednesday, April 27, 2005 8:42 AM
To: [e-mail]
Cc: ""'ccamp'" <ccamp"; ""'Kohei Shiomoto'" <shiomoto.kohei"; ""'Rajiv
Papneja'" <rpapneja"
Subject: RE: Addressing doc



Richiard,=20
                     IMHO also a section (or sub-section) dedicated to =
LMP
usage could be very useful in order to clarify how LMP can help in
addressing resolution.=20

BR=20

D=20



Sent by:        [e-mail]=20


To:        "'ccamp'" <[e-mail]>=20
cc:        "'Kohei Shiomoto'" <[e-mail]>, "'Richard
Rabbat'" <[e-mail]>, "'Rajiv Papneja'"
<[e-mail]>=20

Subject:        RE: Addressing doc=20



Hi all,=20
 =20
The editors have been having various discussions  with people about some
oftheir issues  with this draft. In order to clarify a some  points here =
are
some of thechanges that  we plan tomake to the next version  of the =
draft.
We hope thiswill help  to clarify the draft.=20
 =20
1. In section 4.2.1,  previous text:=20
   Alternatively, the tunnel end point  address MAY also be set to the
destination data plane address if the  ingress knows that address or the =
TE
Router ID.=20
New  text:=20
   Alternatively, the tunnel end point address MAY  also be set to
thedestination data plane  address if the ingress knows that address.=20
 =20
2. In section 4.2.2 previous text:=20
   Alternatively,  the tunnel sender address MAY also be set to =
thesender
data plane address or the TE Router ID.=20
New  text:=20
   Alternatively, the tunnel sender address MAY also  be set to =
thesender
data plane  address.=20
 =20
3. at the end of the introduction, we will add  wording to the last line =
to
that effect:=20
Various more complex deployment scenarios can be  constructed but these =
are
currently out of scope as the only GMPLS implementations encountered
ininteroperability testing or in deployment have  applied this =
relationship.
Whennew  implementations that include any other relationship between
controlplane and data plane entities are encountered,  this document =
would
beenhanced as  necessary.=20






------=_NextPart_000_00E4_01C56607.8623E230
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2627" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D749123000-01062005><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Diego,</FONT></SPAN></DIV>
<DIV><SPAN class=3D749123000-01062005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D749123000-01062005><FONT face=3DArial color=3D#0000ff =
size=3D2>We're=20
currently working on an update to =
draft-ietf-ccamp-gmpls-addressing-00.txt. I=20
was wondering if you have any ideas w/r to your request below? Are you =
looking=20
for an explanation of how LMP could be used or simple text that =
highlights that=20
LMP is one of the protocols that could be used to do address translation =
between=20
TE links and control plane addresses?</FONT></SPAN></DIV>
<DIV><SPAN class=3D749123000-01062005></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D749123000-01062005><FONT face=3DArial color=3D#0000ff =

size=3D2>Richard.</FONT></SPAN></DIV>
<DIV><SPAN class=3D749123000-01062005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Diego Caviglia=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Wednesday, April =
27, 2005=20
  8:42 AM<BR><B>To:</B> [e-mail]<BR><B>Cc:</B> =
""'ccamp'"=20
  &lt;ccamp"; ""'Kohei Shiomoto'" &lt;shiomoto.kohei"; ""'Rajiv =
Papneja'"=20
  &lt;rpapneja"<BR><B>Subject:</B> RE: Addressing=20
  doc<BR><BR></FONT></DIV><BR><FONT face=3Dsans-serif =
size=3D2>Richiard,</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D2>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;IMHO also a section (or sub-section) =

  dedicated to LMP usage could be very useful in order to clarify how =
LMP can=20
  help in addressing resolution.</FONT> <BR><BR><FONT face=3Dsans-serif=20
  size=3D2>BR</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>D</FONT> =
<BR><BR>
  <P><FONT face=3Dsans-serif color=3D#800080 size=3D1>Sent by: &nbsp; =
&nbsp; &nbsp;=20
  &nbsp;[e-mail]</FONT>=20
  <P><FONT face=3Dsans-serif color=3D#800080 size=3D1>To: &nbsp; &nbsp; =
&nbsp;=20
  &nbsp;</FONT><FONT face=3Dsans-serif size=3D1>"'ccamp'"=20
  &lt;[e-mail]&gt;</FONT> <BR><FONT face=3Dsans-serif =
color=3D#800080=20
  size=3D1>cc: &nbsp; &nbsp; &nbsp; &nbsp;</FONT><FONT face=3Dsans-serif =

  size=3D1>"'Kohei Shiomoto'" &lt;[e-mail]&gt;, =
"'Richard=20
  Rabbat'" &lt;[e-mail]&gt;, "'Rajiv Papneja'"=20
  &lt;[e-mail]&gt;</FONT><FONT face=3Dsans-serif =
color=3D#800080 size=3D1>=20
  </FONT><BR><BR><FONT face=3Dsans-serif color=3D#800080 =
size=3D1>Subject: &nbsp;=20
  &nbsp; &nbsp; &nbsp;</FONT><FONT face=3Dsans-serif size=3D1>RE: =
Addressing=20
  doc</FONT> <BR><BR><BR><BR><FONT face=3Dsans-serif =
size=3D2>Hi&nbsp;all,</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D3>&nbsp;</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>The editors have been having various discussions &nbsp;with =
people=20
  about some oftheir issues &nbsp;with this draft.&nbsp;In order to =
clarify a=20
  some &nbsp;points here are some of thechanges that &nbsp;we plan =
tomake to the=20
  next version &nbsp;of the draft. We hope thiswill help =
&nbsp;to&nbsp;clarify=20
  the draft.</FONT> <BR><FONT face=3Dsans-serif size=3D3>&nbsp;</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D2>1. In section 4.2.1, &nbsp;previous =
text:</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D2>&nbsp;&nbsp; Alternatively, the =
tunnel end=20
  point &nbsp;address MAY also be set to the&nbsp;destination data plane =
address=20
  if the &nbsp;ingress knows that address or the TE Router ID.</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D2>New &nbsp;text:</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>&nbsp;&nbsp; Alternatively, the tunnel end point address MAY =
&nbsp;also=20
  be set to thedestination data plane &nbsp;address if the ingress knows =
that=20
  address.</FONT> <BR><FONT face=3Dsans-serif size=3D3>&nbsp;</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D2>2. In section 4.2.2&nbsp;previous =
text:</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D2>&nbsp;&nbsp; Alternatively, =
&nbsp;the tunnel=20
  sender address MAY also be set to thesender data plane address or the =
TE=20
  Router ID.</FONT> <BR><FONT face=3Dsans-serif size=3D2>New =
&nbsp;text:</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D2>&nbsp;&nbsp; Alternatively, the =
tunnel sender=20
  address MAY also &nbsp;be set to thesender data plane =
&nbsp;address.</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D3>&nbsp;</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>3.&nbsp;at the end of the introduction,&nbsp;we will add =
&nbsp;wording=20
  to the last line to that effect:</FONT> <BR><FONT face=3Dsans-serif=20
  size=3D2>Various more complex deployment scenarios can be =
&nbsp;constructed but=20
  these are currently out of scope&nbsp;as the only&nbsp;GMPLS =
implementations=20
  encountered ininteroperability testing or in deployment have =
&nbsp;applied=20
  this relationship.&nbsp;Whennew &nbsp;implementations that include any =
other=20
  relationship between controlplane and data plane entities are =
encountered,=20
  &nbsp;this document&nbsp;would beenhanced as &nbsp;necessary.</FONT>=20
  <BR><BR><BR><BR></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00E4_01C56607.8623E230--




Envelope-to: [e-mail]
Delivery-date: Wed, 01 Jun 2005 00:39:55 +0000
Thread-Topic: LCAS and GMPLS
thread-index: AcVmQlGUDvsOcF20R+SUeRiCduCt6Q==
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
Content-Transfer-Encoding: 7bit
To: "Diego Caviglia" <[e-mail]>
Cc: <[e-mail]>
Bcc: 
Subject: RE: LCAS and GMPLS
Date: Wed, 1 Jun 2005 09:39:07 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBPQU2x4rz6xsAsILTjtOc=?=
Message-ID: <854601c56642$519681e0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_8541_01C5668D.C17BB8E0"
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_8541_01C5668D.C17BB8E0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64


------=_NextPart_000_8541_01C5668D.C17BB8E0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy
Ij4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkhpLDwvRElWPg0KPERJVj5UaGFuayB5b3UgdGhh
dCB5b3UgcmVtaW5kIG1lIHRoZSBjb250cmlidXRpb24uPC9ESVY+DQo8RElWPk1heWJlIEkgdGhp
bmsgdGhhdCB0aGUgY29udHJpYnV0aW9uIHdhcyBzdWJtaXR0ZWQgdG8gdGhlIFNlb3VsIG1lZXRp
bmcuPC9ESVY+DQo8RElWPk15IGNvbnRyaWJ1dGlvbiAoZHJhZnQta2ltLWNjYW1wLWludGVyY2Fj
dGlvbi1ncnN2cHRlLWxjYXMpJm5ic3A7ZGlkbid0IGdldCBhIGNoYW5jZSB0byBwcmVzZW50IGF0
IHRoYXQgdGltZS48L0RJVj4NCjxESVY+SXQgaXMgY29tcGxldGVseSBzYWlkIHRoYXQgTENBUyBp
cyBjb250cm9sZWQgYnkgRU1TLiBCdXQsIG15IGNvbnRyaWJ1dGlvbiB3YXMgd3JpdHRlbiBkb3du
IHRvIHJlZHVjZSB0aGUgRU1TIG92ZXJoZWFkLjwvRElWPg0KPERJVj5Db3VsZCB5b3UmbmJzcDto
YXBwZW4gdG8gdGVsbCBtZSB5b3VyIGludGVyZXN0aW5nIHBvaW50cyBhYm91dCZuYnNwO215IGNv
bnRyaWJ1dGlvbiZuYnNwOz88L0RJVj4NCjxESVY+QVNBUCwgSSdkIGxpa2UgdG8gbW9kaWZ5IGFu
ZCByZS1zdWJtaXQgdGhlIGNvbnRyaWJ1dGlvbiBhZnRlciBhZGRpbmcgeW91ciBjb21tZW50cy48
L0RJVj4NCjxESVY+PEJSPi0tLS0tv/i6uyC43r3DwfYtLS0tLTxCUj48Qj66uLO9ILvntvc6PC9C
PiAiRGllZ28gQ2F2aWdsaWEiICZsdDtEaWVnby5DYXZpZ2xpYUBNYXJjb25pLmNvbSZndDs8QlI+
PEI+urizvSCzr8KlOjwvQj4gMjAwNS0wNS0zMSC/wMjEIDEwOjQ1OjExPEJSPjxCPrnetMIgu+e2
9zo8L0I+ICJjY2FtcEBvcHMuaWV0Zi5vcmciICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PEJS
PjxCPsL8wbY6PC9CPiA8QlI+PEI+waa48To8L0I+IExDQVMgYW5kIEdNUExTPEJSPjxCUj48L0RJ
Vj4NCjxESVY+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT48QlI+DQo8
UD48Rk9OVCBzaXplPTI+SGkgYWxsLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgSSdkIGxpa2UgdG8gYXNrIHdoYXQgaXMgdGhlIHN0YXR1dHMgb2YgdGhlIGlu
dGVyd29ya2luZyBiZXR3ZWVuPEJSPkxDQVMgYW5kIEdNUExTLiZuYnNwOyBTdXJmaW5nIHRoZSBu
ZXQgSSd2ZSBmb3VuZCBhIGNvdXBsZSBvZiBJRCBhYm91dCB0aGF0PEJSPnN1YmplY3QgKGRyYWZ0
LWtpbS1jY2FtcC1pbnRlcmNhY3Rpb24tZ3JzdnB0ZS1sY2FzIGFuZDxCUj5kcmFmdC1tYW5uaWUt
Y2NhbXAtZ21wbHMtdGRtLWxibSkgYnV0IGJvdGggb2YgdGhlbSBzZWVtcyB0byBiZSBleHBpcmVk
LDxCUj5JJ3ZlIGFsc28gZm91bmQgc29tZSBpbnRlcmVzdGluZyBkaXNjdXNzaW9uIG9uIHRoaXMg
bWF0dGVyIG9uIHRoZSBjY2FtcDxCUj5tYWlsIGFyY2hpdmUuPEJSPjxCUj5JcyBpbnRlcndva2lu
ZyBiZXR3ZWVuIExDQVMgYW5kIEdNUExTIG91dHNpZGUgdGhlIHNjb3BlIG9mIENDQU1QPzxCUj48
QlI+SU1ITyB0aGF0IGlzIG5vdCBhbmQgc2hvdWxkIGJlIGFkZHJlc3NlZC48QlI+PEJSPldoYXQg
aXMgdGhlIGZlZWxpbmcgb2YgdGhlIHJlc3Qgb2YgdGhlIGdyb3VwPzxCUj48QlI+QmVzdCByZWdh
cmRzPEJSPjxCUj5EaWVnbzxCUj48QlI+PEJSPjxCUj48L0ZPTlQ+PC9QPjwvRElWPjwvRElWPjxp
bWcgc3R5bGU9ImRpc3BsYXk6bm9uZSIgd2lkdGg9MCBoZWlnaHQ9MCBzcmM9Imh0dHA6Ly91bWFp
bC5ldHJpLnJlLmtyL0V4dGVybmFsX1JlYWRDaGVjay5hc3B4P2VtYWlsPWNjYW1wQG9wcy5pZXRm
Lm9yZyZuYW1lPWNjYW1wJTQwb3BzLmlldGYub3JnJmZyb21lbWFpbD15aHdraW1AZXRyaS5yZS5r
ciZtZXNzYWdlaWQ9JTNDMzQ5ZDRiYWYtMjhjNC00NzVkLTkyNWEtZDNhOGVjZmI4ZmRiQGV0cmku
cmUua3IlM0UiPg==

------=_NextPart_000_8541_01C5668D.C17BB8E0--