Re: WG last calls

[Zhang Renhai <[e-mail]>]

Hi,Adrian 
 From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the number of crankback
rerouting is limited, so there will be a result: there is another LSP,but for the reason
of limiting, the path may be not found.
I think sometimes it is unacceptable.The LSP may be prefered to enhancing performance.

Regards,
Zhang

----- Original Message ----- 
From: "Kireeti Kompella" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 31, 2005 11:37 PM
Subject: WG last calls


> Hi,
> 
> This is to initiate CCAMP WG last calls on:
> 
> draft-ietf-ccamp-crankback-04.txt
> 
> and
> 
> draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
> 
> Please send your comments to the list (preferably) or to the authors
> by April 14, 23:59 GMT (which is when the last calls end).
> 
> Thanks,
> Kireeti.
> -------
> 




Envelope-to: [e-mail]
Delivery-date: Thu, 31 Mar 2005 18:46:09 +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: Please review: Draft liaison to ITU-T Q14/15 on crankback
Date: Thu, 31 Mar 2005 12:44:51 -0600
Message-ID: <[e-mail]>
Thread-Topic: Please review: Draft liaison to ITU-T Q14/15 on crankback
Thread-Index: AcU2IAlUlNvuVecuRp+fJMkCPzm0tgAAYlvA
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Kireeti Kompella" <[e-mail]>, <[e-mail]>, "Scott Bradner" <[e-mail]>

> Please review and comment.

Looks good Adrian.



Envelope-to: [e-mail]
Delivery-date: Thu, 31 Mar 2005 18:36:23 +0000
Message-ID: <148601c5361e$77d62990$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Considering draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt as a WG draft
Date: Thu, 31 Mar 2005 18:06:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

This draft is the product of a DT set up by the WG so it is appropriate
that the draft become a WG draft.

Please speak up now if you feel strongly against this.

Thanks,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, March 23, 2005 10:10 PM
Subject: I-D ACTION:draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Evaluation of existing Routing Protocols against
>   ASON routing requirements
> Author(s) : J. Drake, et al.
> Filename : draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt
> Pages : 0
> Date : 2005-3-23
>
> The Generalized MPLS (GMPLS) suite of protocols has been defined to
>    control different switching technologies as well as different
>    applications. These include support for requesting TDM connections
>    including SONET/SDH and Optical Transport Networks (OTNs).
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-ason-routing-eval-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-dimitri-ccamp-gmpls-ason-routing-eval-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-dimitri-ccamp-gmpls-ason-routing-eval-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.
>


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


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>




Envelope-to: [e-mail]
Delivery-date: Thu, 31 Mar 2005 18:36:15 +0000
Message-ID: <148501c5361e$76d9ef40$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Jean Philippe Vasseur'" <[e-mail]>
Subject: draft-vasseur-ccamp-inter-domain-pd-path-comp
Date: Thu, 31 Mar 2005 18:02:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Not exactly overwhelmed by positive response, but not negative comments
received, so since this draft is one of the set of inter-domain drafts we
will take it into the fold.

JP, please republish as draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
with only the following changes:
- dates, name etc.
- inclusion of the agreed additional sentence for clarification
- any changes to pass the idnits script

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 31 Mar 2005 18:31:20 +0000
Message-ID: <148201c5361e$72138d90$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Please review: Draft liaison to ITU-T Q14/15 on crankback
Date: Thu, 31 Mar 2005 15:30:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Based on the comments at Minneapolis and on the list, here is a draft
liaison to go to ITU-T Q14/15.
Please review and comment.
Thanks,
Adrian
=======
To: Mr. Kam Lam, Rapporteur ITU-T Q14/15
From: Adrian Farrel and Kireeti Kompella
         Co-chairs of IETF CCAMP Working Group
Subject: Inclusion of Crankback in G.7713
For: Action
Deadline: May 1st 2005

Dear Mr. Lam,

Thank you for your recent response liaison on Crankback. The CCAMP working
group is pleased to hear that our work on crankback is of use to your
Question and looks forward to seeing inclusion of crankback within G.7713,
and to the specific inclusion of protocol elements in G.7713.2.

In order to increase the convergence between the work of our two
organizations, the CCAMP working group would welcome the opportunity to
review and comment on these inclusions before they are presented for
consent.

Thank you.

Adrian Farrel and Kireeti Kompella




Envelope-to: [e-mail]
Delivery-date: Thu, 31 Mar 2005 15:38:23 +0000
Date: Thu, 31 Mar 2005 07:37:23 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: WG last calls
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

This is to initiate CCAMP WG last calls on:

draft-ietf-ccamp-crankback-04.txt

and

draft-ietf-ccamp-rsvp-te-exclude-route-03.txt

Please send your comments to the list (preferably) or to the authors
by April 14, 23:59 GMT (which is when the last calls end).

Thanks,
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Thu, 31 Mar 2005 11:41:00 +0000
Message-ID: <13f501c535e5$b40d2370$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Liaison received from ITU-T Q3/15
Date: Thu, 31 Mar 2005 12:34:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received a liaison statement from ITU-T Study Group 15 Question 3.

This liaison is for our information and contains a copy of Recommendation
G.8081 "Terms and definitions for Automatically Switched Optical
Networks".

The authors of the GMPLS/ASON lexicography will need to examine this
Recommendation to ensure alignment with ASON terminology.

The text of the liaison is found below. A copy of the liaison and the
Recommendation can be found at http://www.olddog.co.uk/incoming.htm

(Beware that the ITU-T FTP site is quite slow.)

Thanks,
Adrian

===

From: Hiroshi Ohta, Rapporteur, Q.3/15
To: IETF ccamp WG
For: Information
Subject: G.8081: Terms and definitions for ASON

We are pleased to send you the ITU-T Recommendation G.8081, "Terms and
definitions for Automatically Switched Optical Networks".  We believe this
Recommendation is useful to develop consistent standards related to GMPLS
and ASON.  We hope to collaborate further for future development.  As
usual a pdf version of ITU-T Recommendation G.8081 can be downloaded from
the link below:
ftp://sg15opticalt:[e-mail]/tsg15opticaltransport/COMMUNICATIONS/index.html





Envelope-to: [e-mail]
Delivery-date: Wed, 30 Mar 2005 23:31:15 +0000
Message-Id: <6.1.2.0.2.20050330180027.04a175b8@mo-ex1>
Date: Wed, 30 Mar 2005 18:29:57 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Comments on draft-ietf-ccamp-gmpls-segment-recovery-01.txt
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Adrian,
         Thanks for the comments.  The editorial comments will be 
integrated into the next rev.  Will cover the 1 technical comment (on 
section 6.1) in a separate e-mail.

Lou

At 07:35 AM 3/29/2005, Adrian Farrel wrote:
>Hi,
>
>Working group last call has ended for this draft. As a co-author I held 
>off making comments during WG last call, but as WG chair I wanted to raise 
>a couple of points.
>
>Thanks,
>Adrian
>
>===
>Need to run idnits and fix all errors and warnings
>===
>Opening boilerplate.
>Replace first paragraph with...
>    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.
>===
>Abstract
>Expand "LSP"
>===
>Abstract
>OLD
>    intended to be compliment and be consistent with the Extensions for
>NEW
>    intended to compliment and be consistent with the Extensions for
>===
>Abstract
>Don't use square brace citations in the abstract.
>===
>Section 1
>OLD
>    The extensions defined in this document allow for support of the full
>    set of recovery types supported by [E2E-RECOVERY] on a segment, or
>    portion of the LSP, basis.
>NEW
>    The extensions defined in this document allow for support of the full
>    set of recovery types supported by [E2E-RECOVERY], but applied to any
>    segment, or to any portion of the LSP.
>===
>Section 2
>OLD
>    failure, or failure over a particularly portion of a network used by
>NEW
>    failure, or failure over a particular portion of a network used by
>                                         ^
>===
>Section 2.1
>OLD
>    Three approaches of end-to-end protection are defined in [E2E-
>NEW
>    Three approaches for end-to-end protection are defined in [E2E-
>===
>Section 2.1
>OLD
>    counterparts.  Each behaves just like there end-to-end counterparts,
>NEW
>    counterparts.  Each behaves just like its end-to-end counterpart,
>                                          ^^^                       ^
>===
>Section 2.1 and section 2.2
>Cross-references are all (presumably) to [E2E-RECOVERY]. This is not clear.
>===
>Section 3
>OLD
>    [E2E-RECOVERY].  In this document we define a new type to support
>NEW
>    [E2E-RECOVERY].  In this document we define a new value for the 
> Association Type field to support
>===
>Section 4
>OLD
>    When upstream control of branch and merge nodes are not desired,
>NEW
>    When upstream control of branch and merge nodes is not desired,
>===
>Section 4.1.1
>The definition of the Type value for the Protection sub-object should not 
>be here. It should be in the IANA section and under IANA control.
>===
>Section 4.1.1
>Need to include a definition of the Length field. This can point to RFC3209.
>===
>Section 4.1.1
>Need to state the rules for the Reserved bits.
>===
>Section 4.2.4.2
>    Once the ingress receives all expected Resv messages MUST follow the
>    tear down procedure described in the Section 4.2.4.
>Assume this means 4.2.4.1?
>===
>Section 5.1
>    The protection subobject defined in [E2E-RECOVERY] can also be used
>    in SECONDARY_RECORD_ROUTE objects.
>No. It is defined in section 4.1.1 of this document.
>===
>Section 6.1
>OLD
>    LSP Segment Recovery Flags are carried in the Protection object C-
>    Type defined in [E2E-RECOVERY].  The format of the flags are:
>NEW
>    LSP Segment Recovery Flags are carried in the Protection object of the 
> same C-
>    Type defined in [E2E-RECOVERY].  The format of the flags are:
>===
>Section 6.1
>***
>Same question as for E2E-RECOVERY. Why do we need to use a new C-Type 
>(compared with the old definition of the Protection object)?
>It is possible to carry all of the additional information within the old 
>Protection object format.
>***
>===
>Section 6.1
>       (LSP) Segment (Recovery) Flags: 6 bits
>Not _entirely_ clear which fields in the figure are referred to by this text.
>===
>Section 8
>Is it true that there are _no_ additional security considerations?
>Suppose that I am able to doctor a Path message by adding an SERO. This 
>would cause the data to be duplicated to my chosen destination without 
>impacting the real destination (i.e. without raising an alarm).
>Doesn't segment protection actually improve the security of the network by 
>making data delivery more robust?
>===
>Section 9 first para.
>It is not clear what action (if any) IANA is expected to take for this 
>information. If action is required, it would be helpful to point to the 
>relevant text within the draft.
>===
>Section 9 second para.
>There are some TBAs embedded in the text (section 4, section 5) that 
>relate to this paragraph). Need either to include "IANA" with the TBA, or 
>put a back pointer in this paragraph (or both).
>===
>Section 10
>Obsoleted by section 14
>===
>Section 11.1
>Does [FRR] need to be a normative reference?




Envelope-to: [e-mail]
Delivery-date: Wed, 30 Mar 2005 20:35:42 +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-recovery-functional-04.txt
Date: Wed, 30 Mar 2005 15:33:27 -0500

--NextPart

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

	Title		: Generalized Multi-Protocol Label Switching (GMPLS) 
			  Recovery Functional Specification
	Author(s)	: J. Lang, et al.
	Filename	: draft-ietf-ccamp-gmpls-recovery-functional-04.txt
	Pages		: 20
	Date		: 2005-3-30
	
This document presents a functional description of the protocol 
   extensions needed to support Generalized Multi-Protocol Label 
   Switching (GMPLS)-based recovery (i.e. protection and restoration). 
   Protocol specific formats and mechanisms will be described in 
   companion documents.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-04.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Wed, 30 Mar 2005 20:35:34 +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-recovery-terminology-06.txt
Date: Wed, 30 Mar 2005 15:33:58 -0500

--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		: Recovery (Protection and Restoration) Terminology for 
			  Generalized Multi-Protocol Label Switching (GMPLS)
	Author(s)	: E. Mannie, D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-recovery-terminology-06.txt
	Pages		: 20
	Date		: 2005-3-30
	
This document defines a common terminology for Generalized Multi-
   Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
   protection and restoration). The terminology is independent of the
   underlying transport technologies covered by GMPLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.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-recovery-terminology-06.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-recovery-terminology-06.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-recovery-terminology-06.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Wed, 30 Mar 2005 20:35:26 +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-recovery-analysis-05.txt
Date: Wed, 30 Mar 2005 15:32:35 -0500

--NextPart

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

	Title		: Analysis of Generalized Multi-Protocol Label Switching 
			  (GMPLS)-based Recovery Mechanisms (including Protection 
			  and Restoration)
	Author(s)	: D. Papadimitriou, E. Mannie
	Filename	: draft-ietf-ccamp-gmpls-recovery-analysis-05.txt
	Pages		: 42
	Date		: 2005-3-30
	
This document provides an analysis grid to evaluate, compare and
contrast the Generalized Multi-Protocol Label Switching (GMPLS)
protocol suite capabilities with respect to the recovery mechanisms
currently proposed at the IETF CCAMP Working Group. A detailed
analysis of each of the recovery phases is provided using the
terminology defined in a companion document. This document focuses
on transport plane survivability and recovery issues and not on
control plane resilience and related aspects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-05.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-recovery-analysis-05.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-recovery-analysis-05.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-recovery-analysis-05.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Wed, 30 Mar 2005 11:54:59 +0000
Message-ID: <134001c5351e$6dc9a630$dccb2bd4@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-01.txt
Date: Wed, 30 Mar 2005 12:26:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Igor and I have submitted a new copy of this draft and we now have our
asbestos suits on. Please comment.

This revision includes the outcome of quite a few discussions with the
ASON cognoscenti, but we are pretty convinced that we do not have
everything right yet.

You review thoughts would be most appreciated if they were accompanied by
suggested text revisions.

Thanks,
Adrian



----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, March 29, 2005 4:56 PM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-01.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.
>
> Title : 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-01.txt
> Pages : 15
> Date : 2005-3-28
>
> Generalized Multiprotocol Label Switching (GMPLS) has been developed
>    by the IETF to facilitate the establishment of Label Switched Paths
>    (LSPs) in a variety of physical technologies and across several
>    architectural models. The ITU-T has specified an architecture for
>    the management of Automatically Switched Optical Networks (ASON).
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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-ason-lexicography-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-ason-lexicography-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.
>


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


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>




Envelope-to: [e-mail]
Delivery-date: Tue, 29 Mar 2005 15:57:26 +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-ason-lexicography-01.txt
Date: Tue, 29 Mar 2005 10:56:28 -0500

--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-01.txt
	Pages		: 15
	Date		: 2005-3-28
	
Generalized Multiprotocol Label Switching (GMPLS) has been developed
   by the IETF to facilitate the establishment of Label Switched Paths
   (LSPs) in a variety of physical technologies and across several
   architectural models. The ITU-T has specified an architecture for
   the management of Automatically Switched Optical Networks (ASON).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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-ason-lexicography-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-ason-lexicography-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-ason-lexicography-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-lexicography-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: Tue, 29 Mar 2005 13:29:25 +0000
Message-ID: <127e01c53462$2a7f1ca0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: I-D ACTION:draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt
Date: Tue, 29 Mar 2005 14:17:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Not sure why this was not copied to the CCAMP list.

Anyway...

Alan raised an interesting question about how to handle IPv6 sources and
destinations in the TE MIBs for MPLS and GMPLS.

This draft is an attempt to define a process for managing the existing
MPLS TE MIB so that it can handle this case. Since the GMPLS MIBs are
built on the MPLS MIBs, this is equally applicable to the GMPLS TE MIB.

In the long term it will become clearer whether IPv6 and MPLS/GMPLS need
to become more closely integrated, but this is probably a few years away.
At that time the MPLS MIBs are quite likely to be ready for a rework, and
so IPv6 sources and destinations can be included at that time.

We would appreciate a quick turn-around from you in commenting on this
draft so that we can:
- make it a CCAMP draft if appropriate
- last call it at the same time as the GMPLS MIB drafts.

Thanks,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Monday, March 28, 2005 5:03 PM
Subject: I-D ACTION:draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Handling IPv6 Sources and Destinations in the MPLS
>   and GMPLS TE MIB Modules
> Author(s) : A. Davey, et al.
> Filename : draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt
> Pages : 7
> Date : 2005-3-25
>
> This document describes how to configure or monitor a Multiprotocol
>    Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineered
>    (TE) Label Switched Path (LSP) using the MPLS and GMPLS TE MIB module
>    where the ingress and/or egress routers are identified using IPv6
>    addresses.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.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-davey-ccamp-gmpls-te-mib-ipv6-addr-00.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-davey-ccamp-gmpls-te-mib-ipv6-addr-00.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.
>


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


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>




Envelope-to: [e-mail]
Delivery-date: Tue, 29 Mar 2005 13:07:22 +0000
Message-ID: <123501c5345f$b7c537a0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: WG last call complete on Recovery Signaling drafts
Date: Tue, 29 Mar 2005 13:38:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Authors/editors,

Please pick up all of the comments from the mailing list and either
demonstrate that no changes are needed or respin your drafts.

Let me know when you are done.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 29 Mar 2005 13:07:18 +0000
Message-ID: <123401c5345f$b3d18f40$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Comments on draft-ietf-ccamp-gmpls-segment-recovery-01.txt
Date: Tue, 29 Mar 2005 13:35:03 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_11EF_01C53464.1CEB8C20"

This is a multi-part message in MIME format.

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

Hi,

Working group last call has ended for this draft. As a co-author I held =
off making comments during WG last call, but as WG chair I wanted to =
raise a couple of points.

Thanks,
Adrian

=3D=3D=3D
Need to run idnits and fix all errors and warnings
=3D=3D=3D
Opening boilerplate.
Replace first paragraph with...
   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.
=3D=3D=3D
Abstract
Expand "LSP"
=3D=3D=3D
Abstract
OLD
   intended to be compliment and be consistent with the Extensions for
NEW
   intended to compliment and be consistent with the Extensions for
=3D=3D=3D
Abstract
Don't use square brace citations in the abstract.
=3D=3D=3D
Section 1
OLD
   The extensions defined in this document allow for support of the full
   set of recovery types supported by [E2E-RECOVERY] on a segment, or
   portion of the LSP, basis.=20
NEW
   The extensions defined in this document allow for support of the full
   set of recovery types supported by [E2E-RECOVERY], but applied to any =

   segment, or to any portion of the LSP.
=3D=3D=3D
Section 2
OLD
   failure, or failure over a particularly portion of a network used by
NEW
   failure, or failure over a particular portion of a network used by
                                        ^=20
=3D=3D=3D
Section 2.1
OLD
   Three approaches of end-to-end protection are defined in [E2E-
NEW
   Three approaches for end-to-end protection are defined in [E2E-
=3D=3D=3D
Section 2.1
OLD
   counterparts.  Each behaves just like there end-to-end counterparts,
NEW
   counterparts.  Each behaves just like its end-to-end counterpart,
                                         ^^^                       ^
=3D=3D=3D
Section 2.1 and section 2.2
Cross-references are all (presumably) to [E2E-RECOVERY]. This is not =
clear.
=3D=3D=3D
Section 3
OLD
   [E2E-RECOVERY].  In this document we define a new type to support
NEW
   [E2E-RECOVERY].  In this document we define a new value for the =
Association Type field to support
=3D=3D=3D
Section 4
OLD
   When upstream control of branch and merge nodes are not desired,
NEW
   When upstream control of branch and merge nodes is not desired,
=3D=3D=3D
Section 4.1.1
The definition of the Type value for the Protection sub-object should =
not be here. It should be in the IANA section and under IANA control.
=3D=3D=3D
Section 4.1.1
Need to include a definition of the Length field. This can point to =
RFC3209.
=3D=3D=3D
Section 4.1.1
Need to state the rules for the Reserved bits.
=3D=3D=3D
Section 4.2.4.2
   Once the ingress receives all expected Resv messages MUST follow the
   tear down procedure described in the Section 4.2.4.
Assume this means 4.2.4.1?
=3D=3D=3D
Section 5.1
   The protection subobject defined in [E2E-RECOVERY] can also be used
   in SECONDARY_RECORD_ROUTE objects.
No. It is defined in section 4.1.1 of this document.
=3D=3D=3D
Section 6.1
OLD
   LSP Segment Recovery Flags are carried in the Protection object C-
   Type defined in [E2E-RECOVERY].  The format of the flags are:
NEW
   LSP Segment Recovery Flags are carried in the Protection object of =
the same C-
   Type defined in [E2E-RECOVERY].  The format of the flags are:
=3D=3D=3D
Section 6.1
***
Same question as for E2E-RECOVERY. Why do we need to use a new C-Type =
(compared with the old definition of the Protection object)?
It is possible to carry all of the additional information within the old =
Protection object format.
***
=3D=3D=3D
Section 6.1
      (LSP) Segment (Recovery) Flags: 6 bits
Not _entirely_ clear which fields in the figure are referred to by this =
text.
=3D=3D=3D
Section 8
Is it true that there are _no_ additional security considerations?
Suppose that I am able to doctor a Path message by adding an SERO. This =
would cause the data to be duplicated to my chosen destination without =
impacting the real destination (i.e. without raising an alarm).
Doesn't segment protection actually improve the security of the network =
by making data delivery more robust?
=3D=3D=3D
Section 9 first para.
It is not clear what action (if any) IANA is expected to take for this =
information. If action is required, it would be helpful to point to the =
relevant text within the draft.
=3D=3D=3D
Section 9 second para.
There are some TBAs embedded in the text (section 4, section 5) that =
relate to this paragraph). Need either to include "IANA" with the TBA, =
or put a back pointer in this paragraph (or both).
=3D=3D=3D
Section 10
Obsoleted by section 14
=3D=3D=3D
Section 11.1
Does [FRR] need to be a normative reference?

------=_NextPart_000_11EF_01C53464.1CEB8C20
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,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Working group last call has ended for =
this draft.=20
As a co-author I held off making comments during WG last call, but =
as&nbsp;WG=20
chair I wanted to raise a couple of points.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Need to run idnits and fix all errors =
and=20
warnings</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Opening boilerplate.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Replace first paragraph =
with...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This document is an =
Internet-Draft=20
and is subject to all provisions<BR>&nbsp;&nbsp; of Section 3 of RFC =
3667.&nbsp;=20
By submitting this Internet-Draft, each<BR>&nbsp;&nbsp; author =
represents that=20
any applicable patent or other IPR claims of<BR>&nbsp;&nbsp; which he or =
she is=20
aware have been or will be disclosed, and any of<BR>&nbsp;&nbsp; which =
he or she=20
become aware will be disclosed, in accordance with<BR>&nbsp;&nbsp; RFC=20
3668.<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Abstract</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Expand "LSP"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Abstract</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; intended to be =
compliment and be=20
consistent with the Extensions for<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; intended =
to&nbsp;compliment and be=20
consistent with the Extensions for</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Abstract</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Don't use square brace citations in =
the=20
abstract.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The extensions defined =
in this=20
document allow for support of the full<BR>&nbsp;&nbsp; set of recovery =
types=20
supported by [E2E-RECOVERY] on a segment, or<BR>&nbsp;&nbsp; portion of =
the LSP,=20
basis.&nbsp;<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The extensions defined =
in this=20
document allow for support of the full<BR>&nbsp;&nbsp; set of recovery =
types=20
supported by [E2E-RECOVERY], but applied to any </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; segment, or to =
any&nbsp;portion of=20
the LSP.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; failure, or failure over =
a=20
particularly portion of a network used by<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; failure, or failure over =
a=20
particular portion of a network used by</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;^=20
<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Three approaches of =
end-to-end=20
protection are defined in [E2E-<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Three =
approaches&nbsp;for end-to-end=20
protection are defined in [E2E-<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD<BR>&nbsp;&nbsp; =
counterparts.&nbsp; Each=20
behaves just like there end-to-end counterparts,<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; counterparts.&nbsp; Each =
behaves=20
just like&nbsp;its end-to-end counterpart,</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;^^^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
^</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>Section 2.1 and section =
2.2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Cross-references are all (presumably) =
to=20
[E2E-RECOVERY]. This is not clear.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; [E2E-RECOVERY].&nbsp; In =
this=20
document we define a new type to support<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; [E2E-RECOVERY].&nbsp; In =
this=20
document we define a new value for the Association&nbsp;Type field to=20
support<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; When upstream control of =
branch and=20
merge nodes are not desired,<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; When upstream control of =
branch and=20
merge nodes is not desired,<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>The definition of the Type value for =
the=20
Protection sub-object should not be here. It should be in the IANA =
section and=20
under IANA control.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Need to include a definition of the =
Length field.=20
This can point to RFC3209.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Need to state the rules for the =
Reserved=20
bits.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.2.4.2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Once the ingress =
receives all=20
expected Resv messages MUST follow the<BR>&nbsp;&nbsp; tear down =
procedure=20
described in the Section 4.2.4.<BR>Assume this means =
4.2.4.1?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>Section 5.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The protection subobject =
defined in=20
[E2E-RECOVERY] can also be used<BR>&nbsp;&nbsp; in =
SECONDARY_RECORD_ROUTE=20
objects.<BR>No. It is defined in section 4.1.1 of this =
document.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 6.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; LSP Segment Recovery =
Flags are=20
carried in the Protection object C-<BR>&nbsp;&nbsp; Type defined in=20
[E2E-RECOVERY].&nbsp; The format of the flags are:<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; LSP Segment Recovery =
Flags are=20
carried in the Protection object of the same&nbsp;</FONT><FONT =
face=3DCourier=20
size=3D2>C-</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Type defined in=20
[E2E-RECOVERY].&nbsp; The format of the flags =
are:<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 6.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>***</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Same question as for E2E-RECOVERY. =
Why do we need=20
to use a new C-Type (compared with the old definition of the Protection=20
object)?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>It is possible to carry all of the =
additional=20
information within the old Protection object format.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>***</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 6.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (LSP) =
Segment=20
(Recovery) Flags: 6 bits</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Not _entirely_ clear which fields in =
the figure=20
are referred to by this text.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT><FONT face=3DCourier =
size=3D2></DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>Section 8</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Is it true that there are _no_ =
additional=20
security considerations?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Suppose that I am able to doctor a =
Path message=20
by adding an SERO. This would cause the data to be duplicated to my =
chosen=20
destination without impacting the real destination (i.e. without raising =
an=20
alarm).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Doesn't segment protection actually =
improve the=20
security of the network by making data delivery more =
robust?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 9 first para.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>It is not clear what action (if any) =
IANA is=20
expected to take for this information. If action is required, it would =
be=20
helpful to point to the relevant text within the draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 9 second para.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>There are some TBAs embedded in the =
text (section=20
4, section 5) that relate to this paragraph). Need either to include =
"IANA" with=20
the TBA, or put a back pointer in this paragraph (or both).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 10</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Obsoleted by =
section&nbsp;14</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 11.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Does [FRR] need to be a normative=20
reference?<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_11EF_01C53464.1CEB8C20--




Envelope-to: [e-mail]
Delivery-date: Mon, 28 Mar 2005 12:29:22 +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: WG drafts - My correction
Date: Mon, 28 Mar 2005 06:25:32 -0600
Message-ID: <[e-mail]>
Thread-Topic: WG drafts - My correction
Thread-Index: AcUvPpgKC5q1cD9uQm+wyVzO7ctyiAEUk1ZA
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>

> 3. The name of the third draft is
> draft-vasseur-ccamp-inter-domain-pd-path-comp.
> This is the draft that we need to consider.
> ...
> are we content to accept this draft as a WG draft?

Yes.

Thanks,
Jerry



Envelope-to: [e-mail]
Delivery-date: Fri, 25 Mar 2005 21:31:41 +0000
Sensitivity: 
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
To: "Amit 70405 <AmitG" <[e-mail]>
Cc: "Adrian Farrel <adrian" <[e-mail]>, "Igor Bryskin <i_bryskin" <[e-mail]>, "ccamp" <[e-mail]>, "Sasha" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Fri, 25 Mar 2005 22:30:10 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Amit,
                it seems to me that we are mixing different issues here (a
part from the fact that may be we need to change the subject of the
thread).

First point I think that link protection and path protection leads to
different problem.

In case of link protection it is quite simple to solve the issue; data
plane protecting link is hidden to the control plane and a hold-off timer
is used in order to separate data plane protection mechanism from control
plane restoration.

In case of path protection thing are different and I think are not solved,
or at least not solved in CCAMP/ITU-T.

The main issue I see in this field is the interworking between MS-SPRing
protection and control plane restoration.

It is a matter of fact that MS-SPRing is one of the most used inherent
protection scheme in SDH network but up to now we don't have a 'standard'
way to let MS-SPRing to interwork with control plane restoration scheme
(e.g. timeslot interchange and squelching problem)

I've again to mention the WG chair here and ask him if this kind issues are
in the scope of the CCAMP.

Regards

Diego





Amit 70405 <[e-mail]> on 25/03/2005 02.41.04

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

Subject:    Re: Failure definition w.r.t. SONET/SDH and
       Protection/Restoration


Hi Adrian & Igor,
   But there is one issue with this multilayer protection.
   Say in the case if the link gets broken, and the lower layer protection
has succeeded.
   In this case, should the control plane(higher layer) be notified by the
lower layer of link??

   If yes than it has following consequences:
   - As control plane is unaware of any failure, control plane will
continue to setup new connections on the failed.
   - This may not be a good thing to do.
   - Some means may be needed to avoid this link in Path computation.

   If no than following are the consequences:
   - Control plane too will go ahead with its protection mechanism.

   Let me know your view.
Regards,
Amit.


----- Original Message -----
From: Adrian Farrel <[e-mail]>
Date: Thursday, March 24, 2005 7:40 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> Hi Amit,
>
> >    Do you mean to say that Data plane & Control plane protection
> shouldbe independant of each other??
>
> No, I mean that they MAY be independent.
> In particular, if you are using the control plane *and* the data
> plane to
> manage protection on the same set of resources you are bound to
> get in a
> horrible mess.
>
> Seems more reasonable that you would apply data plane protection
> first and
> then apply control plane protection at a higher level.
>
> >    If so, in case of MSP protection in SDH,
> >     Control plane should not have any control over the resource pool
> >      used for MSP switch.
> >    This may lead to lot of unused resource in the network.
>
> It is certain that each layer of protection that you install MAY
> result in
> unused resources. Building multiple layers of protection will,
> therefore,potentially build up more and more unused resources. It
> is the job of
> CCAMP to produce the tools that allow operators to build the
> protectionschemes that they want. It's not really our business to
> tell them which
> schemes to build and when.
>
> Cheers,
> Adrian
>
>









Envelope-to: [e-mail]
Delivery-date: Fri, 25 Mar 2005 15:52:33 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=5Vsmz/y0dZPHcAnEKdwD2O2B5G9jV45cj84cpVvKpM24qkJz63y1NXm18Kn+cpchGBdR1Ww5iJb6GAQAlD4L/f1QEfJWsyZC5BFDioa7QSztx6I4U10GqxXoEeK2Yp6iokgD0aWhskGr+FGe41uDT6gJsHwpXugK+rCAzg5lsrc=  ;
Message-ID: <[e-mail]>
Date: Fri, 25 Mar 2005 07:51:12 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
To: Amit 70405 <[e-mail]>, Adrian Farrel <[e-mail]>
Cc: Diego Caviglia <[e-mail]>, [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1031285146-1111765872=:74671"

--0-1031285146-1111765872=:74671
Content-Type: text/plain; charset=us-ascii


Please, ee in-line.

Amit 70405 <[e-mail]> wrote: 

Hi Adrian & Igor,
But there is one issue with this multilayer protection.
Say in the case if the link gets broken, and the lower layer protection has succeeded.
In this case, should the control plane(higher layer) be notified by the lower layer of link??

IIB>> Control plane needs to verify with the data plane if the fault condition still exists after the hold-off time and start recovery procedures only if necessary.


Igor

If yes than it has following consequences:
- As control plane is unaware of any failure, control plane will continue to setup new connections on the failed.
- This may not be a good thing to do.
- Some means may be needed to avoid this link in Path computation.

If no than following are the consequences:
- Control plane too will go ahead with its protection mechanism.

Let me know your view.
Regards,
Amit.


----- Original Message -----
From: Adrian Farrel 
Date: Thursday, March 24, 2005 7:40 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> Hi Amit,
> 
> > Do you mean to say that Data plane & Control plane protection 
> shouldbe independant of each other??
> 
> No, I mean that they MAY be independent.
> In particular, if you are using the control plane *and* the data 
> plane to
> manage protection on the same set of resources you are bound to 
> get in a
> horrible mess.
> 
> Seems more reasonable that you would apply data plane protection 
> first and
> then apply control plane protection at a higher level.
> 
> > If so, in case of MSP protection in SDH,
> > Control plane should not have any control over the resource pool
> > used for MSP switch.
> > This may lead to lot of unused resource in the network.
> 
> It is certain that each layer of protection that you install MAY 
> result in
> unused resources. Building multiple layers of protection will, 
> therefore,potentially build up more and more unused resources. It 
> is the job of
> CCAMP to produce the tools that allow operators to build the 
> protectionschemes that they want. It's not really our business to 
> tell them which
> schemes to build and when.
> 
> Cheers,
> Adrian
> 
> 




 

		
---------------------------------
Do you Yahoo!?
 Yahoo! Small Business - Try our new resources site! 
--0-1031285146-1111765872=:74671
Content-Type: text/html; charset=us-ascii

<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Please, ee in-line.<BR><BR><B><I>Amit 70405 &lt;[e-mail]&gt;</I></B> wrote: </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Arial Unicode MS'"><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 3pt; PADDING-BOTTOM: 0in; BORDER-LEFT: #1010ff 1pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<P style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN-LEFT: 2.5pt; BORDER-LEFT: medium none; MARGIN-RIGHT: 0.5in; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi Adrian &amp; Igor,<BR>But there is one issue with this multilayer protection.<BR>Say in the case if the link gets broken, and the lower layer protection has succeeded.<BR>In this case, should the control plane(higher layer) be notified by the lower layer of link??<o:p></o:p></SPAN></P>
<P style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; MARGIN-BOTTOM: 12pt; PADDING-BOTTOM: 0in; MARGIN-LEFT: 2.5pt; BORDER-LEFT: medium none; MARGIN-RIGHT: 0.5in; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">IIB&gt;&gt; Control plane needs to verify with the data plane if the fault condition still exists after the hold-off time and start recovery procedures only if necessary.<o:p></o:p></SPAN></P></DIV>
<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 3pt; PADDING-BOTTOM: 0in; BORDER-LEFT: #1010ff 1pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<P style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; MARGIN-BOTTOM: 12pt; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; MARGIN-RIGHT: 0.5in; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Igor<BR><BR>If yes than it has following consequences:<BR>- As control plane is unaware of any failure, control plane will continue to setup new connections on the failed.<BR>- This may not be a good thing to do.<BR>- Some means may be needed to avoid this link in Path computation.<BR><BR>If no than following are the consequences:<BR>- Control plane too will go ahead with its protection mechanism.<BR><BR>Let me know your view.<BR>Regards,<BR>Amit.<BR><BR><BR>----- Original Message -----<BR>From: Adrian Farrel <[e-mail]><BR>Date: Thursday, March 24, 2005 7:40 pm<BR>Subject: Re: Failure definition w.r.t. SONET/SDH and
 Protection/Restoration<BR><BR>&gt; Hi Amit,<BR>&gt; <BR>&gt; &gt; Do you mean to say that Data plane &amp; Control plane protection <BR>&gt; shouldbe independant of each other??<BR>&gt; <BR>&gt; No, I mean that they MAY be independent.<BR>&gt; In particular, if you are using the control plane *and* the data <BR>&gt; plane to<BR>&gt; manage protection on the same set of resources you are bound to <BR>&gt; get in a<BR>&gt; horrible mess.<BR>&gt; <BR>&gt; Seems more reasonable that you would apply data plane protection <BR>&gt; first and<BR>&gt; then apply control plane protection at a higher level.<BR>&gt; <BR>&gt; &gt; If so, in case of MSP protection in SDH,<BR>&gt; &gt; Control plane should not have any control over the resource pool<BR>&gt; &gt; used for MSP switch.<BR>&gt; &gt; This may lead to lot of unused resource in the network.<BR>&gt; <BR>&gt; It is certain that each layer of protection that you install MAY <BR>&gt; result in<BR>&gt; unused resources. Building multiple
 layers of protection will, <BR>&gt; therefore,potentially build up more and more unused resources. It <BR>&gt; is the job of<BR>&gt; CCAMP to produce the tools that allow operators to build the <BR>&gt; protectionschemes that they want. It's not really our business to <BR>&gt; tell them which<BR>&gt; schemes to build and when.<BR>&gt; <BR>&gt; Cheers,<BR>&gt; Adrian<BR>&gt; <BR>&gt; <BR style="mso-special-character: line-break"><BR style="mso-special-character: line-break"><o:p></o:p></SPAN></P></DIV>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT size=3><FONT face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></P><p>
		<hr size=1>Do you Yahoo!?<br> 
Yahoo! Small Business - <a href="http://us.rd.yahoo.com/evt=31637/*http://smallbusiness.yahoo.com/resources/">Try our new resources site!</a> 
--0-1031285146-1111765872=:74671--



Envelope-to: [e-mail]
Delivery-date: Fri, 25 Mar 2005 12:05:20 +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: Failure definition w.r.t. SONET/SDH and Protection/Restoration
Date: Fri, 25 Mar 2005 12:03:54 -0000
Message-ID: <[e-mail]>
Thread-Topic: Failure definition w.r.t. SONET/SDH and Protection/Restoration
Thread-Index: AcUxE+cYWcvvMc0ISg6FWV8FowB2kQAHNVYg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

You are quite correct Amit.  What you need is proper client/server
functional decoupling between the layer networks involved.  The ideas of
a 'common' control-plane (esp routing) from IP to Optics is rather a
nonsence in our view.....not just technically either, you need this to
provide the key 'network builder service' capability in commercial
relationships between operators.

Historically things have worked OK in practice because there has been a
common-sense approach about how the 3 networking modes of co-cs, co-ps
and cl-ps have been nested (there are 9 possible client/server
relationships here are there are no formal rules governing how many
up/down transitions are allowed in some end-end reference
architecture...and remember, a client layer network will inherit the
performance of its server layer network, and this is recursive to the
duct).  PWE3 stuff is turning this on its head wrt XoverY relationships
(not that these even ensure the key requirement of client/server
independence/transparency anyway)....hopefully most operator folks
should have the common sense to see the problems and avoid the pitfalls.

In the 2 co modes the defect handling MUST be done in the data-plane and
it MUST be unidirectional.  There is an OAM requirement to send a signal
called FDI (Forward Defect Indication...sometimes know as AIS in co-cs
technologies) which is intended to suppress alarm storms (which would
otherwise occur in all higher client co mode networks).  Has to be like
this, esp in the co-cs mode as the control/management-plane is forced to
run OOB and it must work the *same* for all methods of trail
set-up....be this by signalling protocols X, Y or Z of via management
provisioning.

regards, neil

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Amit 70405
> Sent: 25 March 2005 08:23
> To: Diego Caviglia
> Cc: Adrian Farrel <adrian; Igor Bryskin <i_bryskin; ccamp; Sasha
> Subject: Re: Failure definition w.r.t. SONET/SDH and=20
> Protection/Restoration
>=20
>=20
> Hi Diego,
>    Its not only the case with MSP protection.
>    For that matter any Multilayer protection will have the=20
> interworking issues.
>    According to me lower layer restoration should be=20
> mandatorily independant of higher layer restoration.
>    And let the Network operator be aware of the=20
> consequences(mainly some unutilised resources).
>   =20
>    This is the point which I feel that CCAMP should clarify.
>=20
> Regards,
> Amit.
>=20
>=20
>=20
> ----- Original Message -----
> From: Diego Caviglia <[e-mail]>
> Date: Friday, March 25, 2005 3:25 pm
> Subject: Re: Failure definition w.r.t. SONET/SDH and=20
> Protection/Restoration
>=20
> > Hi Amit,
> >               actally for link/span protection I don't see any
> > problem=20
> > with control plane restoration and data plane protection=20
> interworking.
> >=20
> > It is sufficient to hide protection resourse to control plane.
> >=20
> > I see a lot of problems (there are SPs opened in the ITU-T
> > documents about=20
> > that) when you want an MS-SPRing protected ring to interwork with=20
> > GMPLS=20
> > restoration.
> >=20
> > Actually I'm not sure if that topic is in the charter of the CCAMP
> > (Adrian=20
> > what is your feeling about this?) but in any case it is a problem.
> >=20
> > Regards
> >=20
> > Diego
> >=20
> >=20
> > To:     Adrian Farrel <[e-mail]>, Igor Bryskin=20
> > <[e-mail]>cc:     Diego Caviglia=20
> > <[e-mail]>, [e-mail],
> > [e-mail]=20
> >=20
> > Subject:        Re: Failure definition w.r.t. SONET/SDH and=20
> > Protection/Restoration
> >=20
> > Hi Adrian & Igor,
> >   But there is one issue with this multilayer protection.
> >   Say in the case if the link gets broken, and the lower layer
> > protection=20
> > has succeeded.
> >   In this case, should the control plane(higher layer) be=20
> > notified by the=20
> > lower layer of link??
> >=20
> >   If yes than it has following consequences:
> >   - As control plane is unaware of any failure, control plane
> > will=20
> > continue to setup new connections on the failed.
> >   - This may not be a good thing to do.
> >   - Some means may be needed to avoid this link in Path computation.
> >=20
> >   If no than following are the consequences:
> >   - Control plane too will go ahead with its protection mechanism.
> >=20
> >   Let me know your view.
> > Regards,
> > Amit.
> >=20
> >=20
> > ----- Original Message -----
> > From: Adrian Farrel <[e-mail]>
> > Date: Thursday, March 24, 2005 7:40 pm
> > Subject: Re: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoration
> >=20
> > > Hi Amit,
> > >
> > > >    Do you mean to say that Data plane & Control plane protection
> > > shouldbe independant of each other??
> > >
> > > No, I mean that they MAY be independent.
> > > In particular, if you are using the control plane *and* the data=20
> > > plane to manage protection on the same set of resources you are=20
> > > bound to get in a
> > > horrible mess.
> > >
> > > Seems more reasonable that you would apply data plane protection=20
> > > first and then apply control plane protection at a higher level.
> > >
> > > >    If so, in case of MSP protection in SDH,
> > > >     Control plane should not have any control over the
> > resource pool
> > > >      used for MSP switch.
> > > >    This may lead to lot of unused resource in the network.
> > >
> > > It is certain that each layer of protection that you install MAY=20
> > > result in unused resources. Building multiple layers of=20
> protection=20
> > > will, therefore,potentially build up more and more unused=20
> resources.=20
> > > It is the job of
> > > CCAMP to produce the tools that allow operators to build the
> > > protectionschemes that they want. It's not really our business to
> > > tell them which
> > > schemes to build and when.
> > >
> > > Cheers,
> > > Adrian
> > >
> > >
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 25 Mar 2005 08:23:05 +0000
Date: Fri, 25 Mar 2005 16:22:49 +0800
From: Amit 70405 <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
To: Diego Caviglia <[e-mail]>
Cc: "Adrian Farrel <adrian" <[e-mail]>, "Igor Bryskin <i_bryskin" <[e-mail]>, ccamp <[e-mail]>, Sasha <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi Diego,
   Its not only the case with MSP protection.
   For that matter any Multilayer protection will have the interworking issues.
   According to me lower layer restoration should be mandatorily independant of higher layer restoration.
   And let the Network operator be aware of the consequences(mainly some unutilised resources).
   
   This is the point which I feel that CCAMP should clarify.

Regards,
Amit.



----- Original Message -----
From: Diego Caviglia <[e-mail]>
Date: Friday, March 25, 2005 3:25 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> Hi Amit,
>               actally for link/span protection I don't see any 
> problem 
> with control plane restoration and data plane protection interworking.
> 
> It is sufficient to hide protection resourse to control plane.
> 
> I see a lot of problems (there are SPs opened in the ITU-T 
> documents about 
> that) when you want an MS-SPRing protected ring to interwork with 
> GMPLS 
> restoration.
> 
> Actually I'm not sure if that topic is in the charter of the CCAMP 
> (Adrian 
> what is your feeling about this?) but in any case it is a problem.
> 
> Regards
> 
> Diego
> 
> 
> To:     Adrian Farrel <[e-mail]>, Igor Bryskin 
> <[e-mail]>cc:     Diego Caviglia 
> <[e-mail]>, [e-mail], 
> [e-mail] 
> 
> Subject:        Re: Failure definition w.r.t. SONET/SDH and 
> Protection/Restoration
> 
> Hi Adrian & Igor,
>   But there is one issue with this multilayer protection.
>   Say in the case if the link gets broken, and the lower layer 
> protection 
> has succeeded.
>   In this case, should the control plane(higher layer) be 
> notified by the 
> lower layer of link??
> 
>   If yes than it has following consequences:
>   - As control plane is unaware of any failure, control plane 
> will 
> continue to setup new connections on the failed.
>   - This may not be a good thing to do.
>   - Some means may be needed to avoid this link in Path computation.
> 
>   If no than following are the consequences:
>   - Control plane too will go ahead with its protection mechanism.
> 
>   Let me know your view.
> Regards,
> Amit.
> 
> 
> ----- Original Message -----
> From: Adrian Farrel <[e-mail]>
> Date: Thursday, March 24, 2005 7:40 pm
> Subject: Re: Failure definition w.r.t. SONET/SDH and 
> Protection/Restoration
> 
> > Hi Amit,
> >
> > >    Do you mean to say that Data plane & Control plane protection
> > shouldbe independant of each other??
> >
> > No, I mean that they MAY be independent.
> > In particular, if you are using the control plane *and* the data
> > plane to
> > manage protection on the same set of resources you are bound to
> > get in a
> > horrible mess.
> >
> > Seems more reasonable that you would apply data plane protection
> > first and
> > then apply control plane protection at a higher level.
> >
> > >    If so, in case of MSP protection in SDH,
> > >     Control plane should not have any control over the 
> resource pool
> > >      used for MSP switch.
> > >    This may lead to lot of unused resource in the network.
> >
> > It is certain that each layer of protection that you install MAY
> > result in
> > unused resources. Building multiple layers of protection will,
> > therefore,potentially build up more and more unused resources. It
> > is the job of
> > CCAMP to produce the tools that allow operators to build the
> > protectionschemes that they want. It's not really our business to
> > tell them which
> > schemes to build and when.
> >
> > Cheers,
> > Adrian
> >
> >
> 
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Fri, 25 Mar 2005 07:32:37 +0000
MIME-Version: 1.0
Sensitivity: 
To: "Adrian Farrel" <[e-mail]>
Cc: "<ccamp" <[e-mail]>, "<Sasha" <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Fri, 25 Mar 2005 08:32:28 +0100
Content-Type: multipart/alternative; boundary="=_alternative 00296FB3C1256FCF_="

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

Hi Adrian,
                  I see your points (that doesn't mean I agree ;-)).

Given that seems that I'm the only one to ask such kind of statement I 
think the discussion could stop here.

Regards and thanks

Diego


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

Subject:        Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration



Hi Diego,
 
>> - The GMPLS control plane does not  necessarily want to define data
>>   plane failures. Rather, it  wants to signal (report) errors and allow
>>   the control plane  state (and data plane state) to remain in place.
> [dc] Agreed and that  was my initial point.  Which kind of data plane 
(e.g.
> SDG)  defects have to advertised to control plane to trigger 
restoration?  
> Given that control plane is concerned in  restore the data plane it 
should 
> also define what is a failure.  It is a  fiber break or we have also to 
> consider other defects? Of course we  have.  What happens if one
> restoration TNE consider as failure  only Loss Of Light (LOS) while the
> other starts restoration even if there  is a e.g. Loss Of Pointer?  Is 
> that acceptable?
 
Let's look at two things.
 
First, the trigger for protection switchover. If  you look at section 6.2 
of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt  (currently in 
working group last call, so please comment now!) you will  see...
 
   To co-ordinate the switchover  between end-points, an end-to-end 
   switchover request is needed  since a failure affecting one the LSPs 
   results in both  end-points switching to the other LSP (resulting in 
   receiving  traffic from the other LSP) in their respective 
   directions.  This is done using the Notify message with a new Error 
   Code  indicating "Working LSP Failure (Switchover Request)".

This clearly indicates that the objective is not  to report a failure, but 
to request a switchover.
 
Which takes us to your second point: which data  plane errors should be 
reported to the control plane to trigger switchover  signaling, and would 
it matter if different transport nodes applied different  policies?
 
My contention is that this is entirely an  implementation issue. I think 
it would be a wise implementation that included  some degree of 
configurability to this function, but that is not in CCAMP's  scope. If 
two "TNEs" have different trigger thresholds I do not see that any  harm 
will be done, it might even be desirable.
 
>> - Decisions that trigger control plane  protection actions are
>>   fundamentally implementation  choices.
> [dc] Here we are.  This is the point.  IMHO CCAMP  should provide some
> guidance on this.
> 
>>   Maybe  we should make a statement that this type
>>   of thing SHOULD be  configurable so that there is some sort of
>>   consistency within  a network.
> [dc] Something like "..control plane restoration mechanism  SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section  12.1.1.1).
 
But why?
 
It is not enough to know that this is a difficult  question for an 
implementaiton to answer.
 
Why is it not enough to say that the Data Plane  should trigger control 
plane recovery action when the data plane deems that  there is a fault 
from which it determines that recovery is required and from  which it is 
unable or unwilling to recover on its own?
 
If you can show that there is a need to make a more definitive statement 
then we can consider it.

Cheers,
Adrian



--=_alternative 00296FB3C1256FCF_=
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; I see your points (that doesn't mean I agree ;-)).</font>
<br>
<br><font size=3 color=blue face="Times New Roman">Given that seems that I'm the only one to ask such kind of statement I think the discussion could stop here.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">Regards and thanks</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;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;, &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: Failure definition w.r.t. SONET/SDH and Protection/Restoration</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Hi Diego,</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">&gt;&gt; - The GMPLS control plane does not &nbsp;necessarily want to define data</font>
<br><font size=2 face="sans-serif">&gt;&gt; &nbsp; plane failures. Rather, it &nbsp;wants to signal (report) errors and allow</font>
<br><font size=2 face="sans-serif">&gt;&gt; &nbsp; the control plane &nbsp;state (and data plane state) to remain in place.</font>
<br><font size=2 face="sans-serif">&gt; [dc] Agreed and that &nbsp;was my initial point.&nbsp; Which kind of data plane (e.g.</font>
<br><font size=2 face="sans-serif">&gt; SDG) &nbsp;defects&nbsp;have to advertised to control plane to trigger restoration?&nbsp; &nbsp;</font>
<br><font size=2 face="sans-serif">&gt; Given that control plane is concerned in &nbsp;restore the data plane it should </font>
<br><font size=2 face="sans-serif">&gt; also define what is a failure.&nbsp; It is a &nbsp;fiber break or we have also to </font>
<br><font size=2 face="sans-serif">&gt; consider other defects? Of course we &nbsp;have.&nbsp; What happens if one</font>
<br><font size=2 face="sans-serif">&gt;&nbsp;restoration TNE consider as failure &nbsp;only Loss Of Light (LOS) while the</font>
<br><font size=2 face="sans-serif">&gt;&nbsp;other starts restoration even if there &nbsp;is a e.g. Loss Of Pointer?&nbsp; Is </font>
<br><font size=2 face="sans-serif">&gt; that acceptable?</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">Let's look at two things.</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">First, the trigger for protection switchover. If &nbsp;you look at section 6.2 of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt &nbsp;(currently in working group last call, so please comment now!) you will &nbsp;see...</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; To co-ordinate the switchover &nbsp;between end-points, an end-to-end </font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; switchover request is needed &nbsp;since a failure affecting one the LSPs </font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; results in both &nbsp;end-points switching to the other LSP (resulting in </font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; receiving &nbsp;traffic from the other LSP) in their respective </font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; directions. &nbsp;This is done using the Notify message with a new Error </font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; Code &nbsp;indicating &quot;Working LSP Failure (Switchover Request)&quot;.</font>
<br>
<br><font size=2 face="sans-serif">This clearly indicates that the objective is not &nbsp;to report a failure, but to request a switchover.</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">Which takes us to your second point: which data &nbsp;plane errors should be reported to the control plane to trigger switchover &nbsp;signaling, and would it matter if different transport nodes applied different &nbsp;policies?</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">My contention is that this is entirely an &nbsp;implementation issue. I think it would be a wise implementation that included &nbsp;some degree of configurability to this function, but that is not in CCAMP's &nbsp;scope. If two &quot;TNEs&quot; have different trigger thresholds I do not see that any &nbsp;harm will be done, it might even be desirable.</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">&gt;&gt; - Decisions that trigger control plane &nbsp;protection actions are</font>
<br><font size=2 face="sans-serif">&gt;&gt; &nbsp; fundamentally implementation &nbsp;choices.</font>
<br><font size=2 face="sans-serif">&gt; [dc] Here we are.&nbsp; This is the point.&nbsp; IMHO CCAMP &nbsp;should provide some</font>
<br><font size=2 face="sans-serif">&gt; guidance on this.</font>
<br><font size=2 face="sans-serif">&gt; </font>
<br><font size=2 face="sans-serif">&gt;&gt; &nbsp; Maybe &nbsp;we should make a statement that this type</font>
<br><font size=2 face="sans-serif">&gt;&gt; &nbsp; of thing SHOULD be &nbsp;configurable so that there is some sort of</font>
<br><font size=2 face="sans-serif">&gt;&gt; &nbsp; consistency within &nbsp;a network.</font>
<br><font size=2 face="sans-serif">&gt; [dc] Something like &quot;..control plane restoration mechanism &nbsp;SHOULD be</font>
<br><font size=2 face="sans-serif">&gt; triggered as the SNC/I defined in ITU-T G.783 (section &nbsp;12.1.1.1).</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">But why?</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">It is not enough to know that this is a difficult &nbsp;question for an implementaiton to answer.</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">Why is it not enough to say that the Data Plane &nbsp;should trigger control plane recovery action when the data plane deems that &nbsp;there is a fault from which it determines that recovery is required and from &nbsp;which it is unable or unwilling to recover on its own?</font>
<br><font size=2 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">If you can show that there is a need to make a more definitive statement &nbsp;then we can consider it.</font>
<br>
<br><font size=2 face="sans-serif">Cheers,</font>
<br><font size=2 face="sans-serif">Adrian</font>
<br>
<p>
<p>
--=_alternative 00296FB3C1256FCF_=--



Envelope-to: [e-mail]
Delivery-date: Fri, 25 Mar 2005 07:26:41 +0000
Sensitivity: 
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
To: "Amit 70405 <AmitG" <[e-mail]>
Cc: "Adrian Farrel <adrian" <[e-mail]>, "Igor Bryskin <i_bryskin" <[e-mail]>, "ccamp" <[e-mail]>, "Sasha" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Fri, 25 Mar 2005 08:25:22 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Amit,
               actally for link/span protection I don't see any problem
with control plane restoration and data plane protection interworking.

It is sufficient to hide protection resourse to control plane.

I see a lot of problems (there are SPs opened in the ITU-T documents about
that) when you want an MS-SPRing protected ring to interwork with GMPLS
restoration.

Actually I'm not sure if that topic is in the charter of the CCAMP (Adrian
what is your feeling about this?) but in any case it is a problem.

Regards

Diego



Amit 70405 <[e-mail]> on 25/03/2005 02.41.04

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

Subject:    Re: Failure definition w.r.t. SONET/SDH and
       Protection/Restoration


Hi Adrian & Igor,
   But there is one issue with this multilayer protection.
   Say in the case if the link gets broken, and the lower layer protection
has succeeded.
   In this case, should the control plane(higher layer) be notified by the
lower layer of link??

   If yes than it has following consequences:
   - As control plane is unaware of any failure, control plane will
continue to setup new connections on the failed.
   - This may not be a good thing to do.
   - Some means may be needed to avoid this link in Path computation.

   If no than following are the consequences:
   - Control plane too will go ahead with its protection mechanism.

   Let me know your view.
Regards,
Amit.


----- Original Message -----
From: Adrian Farrel <[e-mail]>
Date: Thursday, March 24, 2005 7:40 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> Hi Amit,
>
> >    Do you mean to say that Data plane & Control plane protection
> shouldbe independant of each other??
>
> No, I mean that they MAY be independent.
> In particular, if you are using the control plane *and* the data
> plane to
> manage protection on the same set of resources you are bound to
> get in a
> horrible mess.
>
> Seems more reasonable that you would apply data plane protection
> first and
> then apply control plane protection at a higher level.
>
> >    If so, in case of MSP protection in SDH,
> >     Control plane should not have any control over the resource pool
> >      used for MSP switch.
> >    This may lead to lot of unused resource in the network.
>
> It is certain that each layer of protection that you install MAY
> result in
> unused resources. Building multiple layers of protection will,
> therefore,potentially build up more and more unused resources. It
> is the job of
> CCAMP to produce the tools that allow operators to build the
> protectionschemes that they want. It's not really our business to
> tell them which
> schemes to build and when.
>
> Cheers,
> Adrian
>
>









Envelope-to: [e-mail]
Delivery-date: Fri, 25 Mar 2005 01:43:50 +0000
Date: Fri, 25 Mar 2005 09:41:04 +0800
From: Amit 70405 <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
To: Adrian Farrel <[e-mail]>, Igor Bryskin <[e-mail]>
Cc: Diego Caviglia <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi Adrian & Igor,
   But there is one issue with this multilayer protection.
   Say in the case if the link gets broken, and the lower layer protection has succeeded.
   In this case, should the control plane(higher layer) be notified by the lower layer of link??

   If yes than it has following consequences:
   - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed.
   - This may not be a good thing to do.
   - Some means may be needed to avoid this link in Path computation.

   If no than following are the consequences:
   - Control plane too will go ahead with its protection mechanism.
  
   Let me know your view.
Regards,
Amit.


----- Original Message -----
From: Adrian Farrel <[e-mail]>
Date: Thursday, March 24, 2005 7:40 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> Hi Amit,
> 
> >    Do you mean to say that Data plane & Control plane protection 
> shouldbe independant of each other??
> 
> No, I mean that they MAY be independent.
> In particular, if you are using the control plane *and* the data 
> plane to
> manage protection on the same set of resources you are bound to 
> get in a
> horrible mess.
> 
> Seems more reasonable that you would apply data plane protection 
> first and
> then apply control plane protection at a higher level.
> 
> >    If so, in case of MSP protection in SDH,
> >     Control plane should not have any control over the resource pool
> >      used for MSP switch.
> >    This may lead to lot of unused resource in the network.
> 
> It is certain that each layer of protection that you install MAY 
> result in
> unused resources. Building multiple layers of protection will, 
> therefore,potentially build up more and more unused resources. It 
> is the job of
> CCAMP to produce the tools that allow operators to build the 
> protectionschemes that they want. It's not really our business to 
> tell them which
> schemes to build and when.
> 
> Cheers,
> Adrian
> 
> 




Envelope-to: [e-mail]
Delivery-date: Thu, 24 Mar 2005 19:26:39 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=V7lvIqRw/FDpfP5FaYLKCXfWElLRQ0sbOet4HzqpJI+t6g33BGl3o3EMg8fGsbmbc+5WYVhgUKbXgeGMCf7EJUK0kj5nWMTyLcXj9MdFybzO/BjC0rQmxuENs0jo5dhekjmot/mtX4IasdYJtxv84qYEjLh6saYMnVy+z8ea2Jo=  ;
Message-ID: <[e-mail]>
Date: Thu, 24 Mar 2005 11:25:23 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
To: Amit 70405 <[e-mail]>, Adrian Farrel <[e-mail]>, Diego Caviglia <[e-mail]>
Cc: "<Sasha" <[e-mail]>, "<ccamp" <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2077387970-1111692323=:48357"

--0-2077387970-1111692323=:48357
Content-Type: text/plain; charset=us-ascii


Hi,

 

I agree that recovery supervised by data and control plane should be correlated in a sense that control plane shouldn’t not trigger any recovery activities before giving a chance to the data plane (of course, capable of doing so) to provide the recovery. In fact, the similar strategy could be applied as in case of a multi-layer recovery, when, say, a higher layer does not start recovery procedures immediately on the fault detection, rather, waits for some time to let the lower layer(s) do the job, and starts recovery  only if the fault situation still exists after the hold off time.

 

Igor

Amit 70405 <[e-mail]> wrote: 

Hi Adrian,
Do you mean to say that Data plane & Control plane protection should be independant of each other??
If so, in case of MSP protection in SDH, 
Control plane should not have any control over the resource pool 
used for MSP switch.
This may lead to lot of unused resource in the network.
Regards,
Amit.


----- Original Message -----
From: Diego Caviglia 
Date: Thursday, March 24, 2005 4:03 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> 
> Hi Adrian,
> thanks for taking part to this discussion.
> 
> Please find my comments in line.
> 
> Regards
> 
> Diego
> 
> 
> 
> "Adrian Farrel" on 23/03/2005 15.58.42
> 
> Please respond to "Adrian Farrel" 
> 
> To: "Diego Caviglia" , 
> cc: 
> 
> Subject: Re: Failure definition w.r.t. SONET/SDH and
> Protection/Restoration
> 
> 
> Hi,
> 
> My initial reaction is that this is way out of scope for CCAMP for 
> a bunch
> of reasons. In particular order:
> 
> - The GMPLS control plane does not necessarily want to define data
> plane failures. Rather, it wants to signal (report) errors and allow
> the control plane state (and data plane state) to remain in place.
> [dc] Agreed and that was my initial point. Which kind of data 
> plane (e.g.
> SDG) defects
> have to advertised to control plane to trigger restoration? Given 
> thatcontrol plane is concerned in restore the data plane it should 
> also define
> what is a failure. It is a fiber break or we have also to 
> consider other
> defects? Of course we have. What happens if one restoration TNE 
> consideras failure only Loss Of Light (LOS) while the other starts 
> restoration even
> if there is a e.g. Loss Of Pointer? Is that acceptable?
> 
> - Control plane and data plane protection actions need to be carefully
> separated.
> [dc] Agreed.
> 
> - Decisions that trigger control plane protection actions are
> fundamentally implementation choices.
> [dc] Here we are. This is the point. IMHO CCAMP should provide some
> guidance on this.
> 
> Maybe we should make a statement that this type
> of thing SHOULD be configurable so that there is some sort of
> consistency within a network.
> [dc] Something like "..control plane restoration mechanism SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1).
> 
> - Existing alarm procedures should not be impacted by the use of 
> GMPLS.[dc] Absolutely agreed
> 
> - Data plane technology is not what we do.
> [dc] Absolutely agreed
> 
> But I'm open to discussion.
> 
> Finally, to follow on Sasha's comments, such a draft would 
> probably be
> informational.
> [dc] Ok for me no problem on that.
> 
> Cheers,
> Adrian
> 
> ----- Original Message -----
> From: "Diego Caviglia" 
> To: "Sasha Vainshtein 
> Cc: "ccamp 
> Sent: Wednesday, March 23, 2005 2:01 PM
> Subject: RE: Failure definition w.r.t. SONET/SDH and 
> Protection/Restoration
> 
> 
> >
> > May be Adrian can put come light on the question you raised.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> > Sasha Vainshtein on 23/03/2005 14.44.23
> >
> > To: "'Diego Caviglia'" 
> > cc: ccamp 
> >
> > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoratio n
> >
> >
> > Diego,
> > I do not see any technical problems with placing such
> > a definition in an Internet-Draft.
> >
> > But there may be problems associated with the IETF process:
> >
> > 1. Do you want to pursue this activity in the CCAMP WG?
> > I am not sure this is really in the scope as defined
> > by the CCAMP Charter
> >
> > 2. For interoperability the IETF document should be
> > a Standards Track RFC. On the other hand, CCAMP is in
> > the Routing Area meaning that you need an implementation
> > to publish a Standards Track RFC - but what could be
> > considered as an implementation in this case?
> >
> > Regards,
> > Sasha Vainshtein
> > email: [e-mail]
> 
> > phone: [phone] (office)
> > fax: [phone]
> > mobile: [phone]
> >
> >
> > > -----Original Message-----
> > > From: Diego Caviglia [[e-mail]]
> > > Sent: Wednesday, March 23, 2005 3:37 PM
> > > To: Sasha Vainshtein
> > > Cc: ccamp
> > > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoratio n
> > >
> > >
> > >
> > > Hi Sasha,
> > > I agree with you but in any case for
> > > interop issues
> > > and for sake of clarity I'd like to have that written in some IETF
> > > document.
> > >
> > > Regards
> > >
> > > Diego
> > >
> > >
> > >
> > >
> > >
> > > Sasha Vainshtein on 23/03/2005 12.23.12
> > >
> > > To: "'Diego Caviglia'" 
> > > cc: [e-mail]
> > >
> > > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoratio n
> > >
> > >
> > > Diego and all,
> > > IMHO it is reasonable to assume that a failure is
> > > a defect that results in sending downstream AIS
> > > (and upstream RDI) as consequent action(s).
> > >
> > > For SDH consecutive actions for each defect
> > > are specified in ITU-T G.783.
> > >
> > > Note also that for some defects the consecutive action
> > > can be disabled by configuration. Hence I'd say that
> > > the same defect can be a failure in one case and
> > > not a failure in another case. The typical example
> > > is Trail Identifier Mismatch (TIM).
> > >
> > > Hopefully this note will help.
> > >
> > > Regards,
> > > Sasha Vainshtein
> > > email: [e-mail]
> > > 
> > > phone: [phone] (office)
> > > fax: [phone]
> > > mobile: [phone]
> > >
> > >
> > > > -----Original Message-----
> > > > From: Diego Caviglia [[e-mail]]
> > > > Sent: Wednesday, March 23, 2005 1:06 PM
> > > > To: [e-mail]
> > > > Subject: Failure definition w.r.t. SONET/SDH and
> > > > Protection/Restoration
> > > >
> > > >
> > > > Hi all,
> > > > is it defined somewhere, with respect to
> > > > SDH/SONET, which
> > > > defect has to be consider as a failure?
> > > >
> > > > It seems to me that for interoperability could be useful to
> > > > have a list of
> > > > defect that must be considered as failure, the same applies
> > > > for defect that
> > > > optionally can be considered as defect.
> > > >
> > > > May be also a communication between restoration TNEs in order
> > > > to agree on
> > > > the list could be useful.
> > > >
> > > > Does anyone agree on that?
> > > >
> > > > Regards
> > > >
> > > > Diego
> > > >
> > > > PS I apologise if the list is defined somewhere but I wasn't
> > > > able to find
> > > > it.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 




 

		
---------------------------------
Do you Yahoo!?
 Yahoo! Small Business - Try our new resources site! 
--0-2077387970-1111692323=:48357
Content-Type: text/html; charset=us-ascii

<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">I agree that recovery supervised by data and control plane should be correlated in a sense that control plane shouldn’t not trigger any recovery activities before giving a chance to the data plane (of course, capable of doing so) to provide the recovery. In fact, the similar strategy could be applied as in case of a multi-layer recovery, when, say, a higher layer does not start recovery procedures immediately on the fault detection, rather, waits for some time to let the lower layer(s) do the job, and starts recovery<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>only if the fault situation still exists after the hold off time.<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Igor<BR><BR><B><I>Amit 70405 &lt;[e-mail]&gt;</I></B> wrote: </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Arial Unicode MS'"><o:p></o:p></SPAN></P>
<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 3pt; PADDING-BOTTOM: 0in; BORDER-LEFT: #1010ff 1pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<P class=MsoNormal style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN: 0in 0.5in 12pt 2.5pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-margin-top-alt: auto; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi Adrian,<BR>Do you mean to say that Data plane &amp; Control plane protection should be independant of each other??<BR>If so, in case of MSP protection in SDH, <BR>Control plane should not have any control over the resource pool <BR>used for MSP switch.<BR>This may lead to lot of unused resource in the network.<BR>Regards,<BR>Amit.<BR><BR><BR>----- Original Message -----<BR>From: Diego Caviglia <BR>Date: Thursday, March 24, 2005 4:03 pm<BR>Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration<BR><BR>&gt; <BR>&gt; Hi Adrian,<BR>&gt; thanks for taking part to this
 discussion.<BR>&gt; <BR>&gt; Please find my comments in line.<BR>&gt; <BR>&gt; Regards<BR>&gt; <BR>&gt; Diego<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; "Adrian Farrel" on 23/03/2005 15.58.42<BR>&gt; <BR>&gt; Please respond to "Adrian Farrel" <BR>&gt; <BR>&gt; To: "Diego Caviglia" , <BR>&gt; cc: <BR>&gt; <BR>&gt; Subject: Re: Failure definition w.r.t. SONET/SDH and<BR>&gt; Protection/Restoration<BR>&gt; <BR>&gt; <BR>&gt; Hi,<BR>&gt; <BR>&gt; My initial reaction is that this is way out of scope for CCAMP for <BR>&gt; a bunch<BR>&gt; of reasons. In particular order:<BR>&gt; <BR>&gt; - The GMPLS control plane does not necessarily want to define data<BR>&gt; plane failures. Rather, it wants to signal (report) errors and allow<BR>&gt; the control plane state (and data plane state) to remain in place.<BR>&gt; [dc] Agreed and that was my initial point. Which kind of data <BR>&gt; plane (e.g.<BR>&gt; SDG) defects<BR>&gt; have to advertised to control plane to trigger restoration? Given <BR>&gt;
 thatcontrol plane is concerned in restore the data plane it should <BR>&gt; also define<BR>&gt; what is a failure. It is a fiber break or we have also to <BR>&gt; consider other<BR>&gt; defects? Of course we have. What happens if one restoration TNE <BR>&gt; consideras failure only Loss Of Light (LOS) while the other starts <BR>&gt; restoration even<BR>&gt; if there is a e.g. Loss Of Pointer? Is that acceptable?<BR>&gt; <BR>&gt; - Control plane and data plane protection actions need to be carefully<BR>&gt; separated.<BR>&gt; [dc] Agreed.<BR>&gt; <BR>&gt; - Decisions that trigger control plane protection actions are<BR>&gt; fundamentally implementation choices.<BR>&gt; [dc] Here we are. This is the point. IMHO CCAMP should provide some<BR>&gt; guidance on this.<BR>&gt; <BR>&gt; Maybe we should make a statement that this type<BR>&gt; of thing SHOULD be configurable so that there is some sort of<BR>&gt; consistency within a network.<BR>&gt; [dc] Something like "..control plane
 restoration mechanism SHOULD be<BR>&gt; triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1).<BR>&gt; <BR>&gt; - Existing alarm procedures should not be impacted by the use of <BR>&gt; GMPLS.[dc] Absolutely agreed<BR>&gt; <BR>&gt; - Data plane technology is not what we do.<BR>&gt; [dc] Absolutely agreed<BR>&gt; <BR>&gt; But I'm open to discussion.<BR>&gt; <BR>&gt; Finally, to follow on Sasha's comments, such a draft would <BR>&gt; probably be<BR>&gt; informational.<BR>&gt; [dc] Ok for me no problem on that.<BR>&gt; <BR>&gt; Cheers,<BR>&gt; Adrian<BR>&gt; <BR>&gt; ----- Original Message -----<BR>&gt; From: "Diego Caviglia" <BR>&gt; To: "Sasha Vainshtein <BR>&gt; Cc: "ccamp <BR>&gt; Sent: Wednesday, March 23, 2005 2:01 PM<BR>&gt; Subject: RE: Failure definition w.r.t. SONET/SDH and <BR>&gt; Protection/Restoration<BR>&gt; <BR>&gt; <BR>&gt; &gt;<BR>&gt; &gt; May be Adrian can put come light on the question you raised.<BR>&gt; &gt;<BR>&gt; &gt; Regards<BR>&gt; &gt;<BR>&gt;
 &gt; Diego<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; Sasha Vainshtein on 23/03/2005 14.44.23<BR>&gt; &gt;<BR>&gt; &gt; To: "'Diego Caviglia'" <BR>&gt; &gt; cc: ccamp <BR>&gt; &gt;<BR>&gt; &gt; Subject: RE: Failure definition w.r.t. SONET/SDH and<BR>&gt; &gt; Protection/Restoratio n<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; Diego,<BR>&gt; &gt; I do not see any technical problems with placing such<BR>&gt; &gt; a definition in an Internet-Draft.<BR>&gt; &gt;<BR>&gt; &gt; But there may be problems associated with the IETF process:<BR>&gt; &gt;<BR>&gt; &gt; 1. Do you want to pursue this activity in the CCAMP WG?<BR>&gt; &gt; I am not sure this is really in the scope as defined<BR>&gt; &gt; by the CCAMP Charter<BR>&gt; &gt;<BR>&gt; &gt; 2. For interoperability the IETF document should be<BR>&gt; &gt; a Standards Track RFC. On the other hand, CCAMP is in<BR>&gt; &gt; the Routing Area meaning that you need an implementation<BR>&gt; &gt; to publish a Standards Track RFC - but what
 could be<BR>&gt; &gt; considered as an implementation in this case?<BR>&gt; &gt;<BR>&gt; &gt; Regards,<BR>&gt; &gt; Sasha Vainshtein<BR>&gt; &gt; email: [e-mail]<BR>&gt; <BR>&gt; &gt; phone: [phone] (office)<BR>&gt; &gt; fax: [phone]<BR>&gt; &gt; mobile: [phone]<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; &gt; -----Original Message-----<BR>&gt; &gt; &gt; From: Diego Caviglia [[e-mail]]<BR>&gt; &gt; &gt; Sent: Wednesday, March 23, 2005 3:37 PM<BR>&gt; &gt; &gt; To: Sasha Vainshtein<BR>&gt; &gt; &gt; Cc: ccamp<BR>&gt; &gt; &gt; Subject: RE: Failure definition w.r.t. SONET/SDH and<BR>&gt; &gt; &gt; Protection/Restoratio n<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Hi Sasha,<BR>&gt; &gt; &gt; I agree with you but in any case for<BR>&gt; &gt; &gt; interop issues<BR>&gt; &gt; &gt; and for sake of clarity I'd like to have that written in some IETF<BR>&gt; &gt; &gt; document.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;
 Regards<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Diego<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Sasha Vainshtein on 23/03/2005 12.23.12<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; To: "'Diego Caviglia'" <BR>&gt; &gt; &gt; cc: [e-mail]<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Subject: RE: Failure definition w.r.t. SONET/SDH and<BR>&gt; &gt; &gt; Protection/Restoratio n<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Diego and all,<BR>&gt; &gt; &gt; IMHO it is reasonable to assume that a failure is<BR>&gt; &gt; &gt; a defect that results in sending downstream AIS<BR>&gt; &gt; &gt; (and upstream RDI) as consequent action(s).<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; For SDH consecutive actions for each defect<BR>&gt; &gt; &gt; are specified in ITU-T G.783.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Note also that for some defects the consecutive action<BR>&gt; &gt; &gt; can be disabled by configuration. Hence I'd say that<BR>&gt; &gt;
 &gt; the same defect can be a failure in one case and<BR>&gt; &gt; &gt; not a failure in another case. The typical example<BR>&gt; &gt; &gt; is Trail Identifier Mismatch (TIM).<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Hopefully this note will help.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Regards,<BR>&gt; &gt; &gt; Sasha Vainshtein<BR>&gt; &gt; &gt; email: [e-mail]<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; phone: [phone] (office)<BR>&gt; &gt; &gt; fax: [phone]<BR>&gt; &gt; &gt; mobile: [phone]<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; -----Original Message-----<BR>&gt; &gt; &gt; &gt; From: Diego Caviglia [[e-mail]]<BR>&gt; &gt; &gt; &gt; Sent: Wednesday, March 23, 2005 1:06 PM<BR>&gt; &gt; &gt; &gt; To: [e-mail]<BR>&gt; &gt; &gt; &gt; Subject: Failure definition w.r.t. SONET/SDH and<BR>&gt; &gt; &gt; &gt; Protection/Restoration<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Hi all,<BR>&gt; &gt; &gt;
 &gt; is it defined somewhere, with respect to<BR>&gt; &gt; &gt; &gt; SDH/SONET, which<BR>&gt; &gt; &gt; &gt; defect has to be consider as a failure?<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; It seems to me that for interoperability could be useful to<BR>&gt; &gt; &gt; &gt; have a list of<BR>&gt; &gt; &gt; &gt; defect that must be considered as failure, the same applies<BR>&gt; &gt; &gt; &gt; for defect that<BR>&gt; &gt; &gt; &gt; optionally can be considered as defect.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; May be also a communication between restoration TNEs in order<BR>&gt; &gt; &gt; &gt; to agree on<BR>&gt; &gt; &gt; &gt; the list could be useful.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Does anyone agree on that?<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Regards<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Diego<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; PS I apologise if the list is defined somewhere but I wasn't<BR>&gt; &gt; &gt; &gt; able to
 find<BR>&gt; &gt; &gt; &gt; it.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR style="mso-special-character: line-break"><BR style="mso-special-character: line-break"><o:p></o:p></SPAN></P></DIV>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT size=3><FONT face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></P><p>
		<hr size=1>Do you Yahoo!?<br> 
Yahoo! Small Business - <a href="http://us.rd.yahoo.com/evt=31637/*http://smallbusiness.yahoo.com/resources/">Try our new resources site!</a> 
--0-2077387970-1111692323=:48357--



Envelope-to: [e-mail]
Delivery-date: Thu, 24 Mar 2005 13:17:23 +0000
Message-ID: <0e7901c53070$cc1696b0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Amit 70405" <[e-mail]>, "Diego Caviglia" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
Date: Thu, 24 Mar 2005 11:40:01 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Amit,

>    Do you mean to say that Data plane & Control plane protection should
be independant of each other??

No, I mean that they MAY be independent.
In particular, if you are using the control plane *and* the data plane to
manage protection on the same set of resources you are bound to get in a
horrible mess.

Seems more reasonable that you would apply data plane protection first and
then apply control plane protection at a higher level.

>    If so, in case of MSP protection in SDH,
>     Control plane should not have any control over the resource pool
>      used for MSP switch.
>    This may lead to lot of unused resource in the network.

It is certain that each layer of protection that you install MAY result in
unused resources. Building multiple layers of protection will, therefore,
potentially build up more and more unused resources. It is the job of
CCAMP to produce the tools that allow operators to build the protection
schemes that they want. It's not really our business to tell them which
schemes to build and when.

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 24 Mar 2005 12:56:08 +0000
Message-ID: <0e7a01c53070$cdb4b650$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
Date: Thu, 24 Mar 2005 11:53:32 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E0E_01C53068.1A6EFAE0"

This is a multi-part message in MIME format.

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

Hi Diego,

>> - The GMPLS control plane does not necessarily want to define data
>>   plane failures. Rather, it wants to signal (report) errors and =
allow
>>   the control plane state (and data plane state) to remain in place.
> [dc] Agreed and that was my initial point.  Which kind of data plane =
(e.g.
> SDG) defects have to advertised to control plane to trigger =
restoration? =20
> Given that control plane is concerned in restore the data plane it =
should=20
> also define what is a failure.  It is a fiber break or we have also to =

> consider other defects? Of course we have.  What happens if one
> restoration TNE consider as failure only Loss Of Light (LOS) while the
> other starts restoration even if there is a e.g. Loss Of Pointer?  Is=20
> that acceptable?

Let's look at two things.

First, the trigger for protection switchover. If you look at section 6.2 =
of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt (currently in =
working group last call, so please comment now!) you will see...

   To co-ordinate the switchover between end-points, an end-to-end=20
   switchover request is needed since a failure affecting one the LSPs=20
   results in both end-points switching to the other LSP (resulting in=20
   receiving traffic from the other LSP) in their respective=20
   directions. This is done using the Notify message with a new Error=20
   Code indicating "Working LSP Failure (Switchover Request)".

This clearly indicates that the objective is not to report a failure, =
but to request a switchover.

Which takes us to your second point: which data plane errors should be =
reported to the control plane to trigger switchover signaling, and would =
it matter if different transport nodes applied different policies?

My contention is that this is entirely an implementation issue. I think =
it would be a wise implementation that included some degree of =
configurability to this function, but that is not in CCAMP's scope. If =
two "TNEs" have different trigger thresholds I do not see that any harm =
will be done, it might even be desirable.

>> - Decisions that trigger control plane protection actions are
>>   fundamentally implementation choices.
> [dc] Here we are.  This is the point.  IMHO CCAMP should provide some
> guidance on this.
>=20
>>   Maybe we should make a statement that this type
>>   of thing SHOULD be configurable so that there is some sort of
>>   consistency within a network.
> [dc] Something like "..control plane restoration mechanism SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1).

But why?

It is not enough to know that this is a difficult question for an =
implementaiton to answer.

Why is it not enough to say that the Data Plane should trigger control =
plane recovery action when the data plane deems that there is a fault =
from which it determines that recovery is required and from which it is =
unable or unwilling to recover on its own?

If you can show that there is a need to make a more definitive statement =
then we can consider it.

Cheers,
Adrian
------=_NextPart_000_0E0E_01C53068.1A6EFAE0
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;&gt; - The GMPLS control plane =
does not=20
necessarily want to define data<BR>&gt;&gt; &nbsp; plane failures. =
Rather, it=20
wants to signal (report) errors and allow<BR>&gt;&gt; &nbsp; the control =
plane=20
state (and data plane state) to remain in place.<BR>&gt; [dc] Agreed and =
that=20
was my initial point.&nbsp; Which kind of data plane (e.g.<BR>&gt; SDG)=20
defects&nbsp;have to advertised to control plane to trigger =
restoration?&nbsp;=20
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; Given that control plane is =
concerned in=20
restore the data plane it should </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; also define what is a =
failure.&nbsp; It is a=20
fiber break or we have also to </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; consider other defects? Of =
course we=20
have.&nbsp; What happens if one</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;restoration TNE consider as =
failure=20
only Loss Of Light (LOS) while the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;other starts restoration =
even if there=20
is a e.g. Loss Of Pointer?&nbsp; Is </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; that acceptable?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Let's look at two =
things.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>First, the trigger for protection =
switchover. If=20
you look at section 6.2 of =
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt=20
(currently in working group last call, so please comment now!) you will=20
see...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; To co-ordinate the =
switchover=20
between end-points, an end-to-end <BR>&nbsp;&nbsp; switchover request is =
needed=20
since a failure affecting one the LSPs <BR>&nbsp;&nbsp; results in both=20
end-points switching to the other LSP (resulting in <BR>&nbsp;&nbsp; =
receiving=20
traffic from the other LSP) in their respective <BR>&nbsp;&nbsp; =
directions.=20
This is done using the Notify message with a new Error <BR>&nbsp;&nbsp; =
Code=20
indicating "Working LSP Failure (Switchover Request)".<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This clearly indicates that the =
objective is not=20
to report a failure, but to request a switchover.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Which takes us to your second point: =
which data=20
plane errors should be reported to the control plane to trigger =
switchover=20
signaling, and would it matter if different transport nodes applied =
different=20
policies?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>My contention is that this is =
entirely an=20
implementation issue. I think it would be a wise implementation that =
included=20
some degree of configurability to this function, but that is not in =
CCAMP's=20
scope. If two "TNEs" have different trigger thresholds I do not see that =
any=20
harm will be done, it might even be desirable.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; - Decisions that trigger =
control plane=20
protection actions are<BR>&gt;&gt; &nbsp; fundamentally implementation=20
choices.<BR>&gt; [dc] Here we are.&nbsp; This is the point.&nbsp; IMHO =
CCAMP=20
should provide some<BR>&gt; guidance on this.<BR>&gt; <BR>&gt;&gt; =
&nbsp; Maybe=20
we should make a statement that this type<BR>&gt;&gt; &nbsp; of thing =
SHOULD be=20
configurable so that there is some sort of<BR>&gt;&gt; &nbsp; =
consistency within=20
a network.<BR>&gt; [dc] Something like "..control plane restoration =
mechanism=20
SHOULD be<BR>&gt; triggered as the SNC/I defined in ITU-T G.783 (section =

12.1.1.1).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>But why?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It is not enough to know that this is =
a difficult=20
question for an implementaiton to answer.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Why is it not enough to say that the =
Data Plane=20
should trigger control plane recovery action when the data plane deems =
that=20
there is a fault from which it determines that recovery is required and =
from=20
which it is unable or unwilling to recover on its own?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
<DIV>If you can show that there is a need to make a more definitive =
statement=20
then we can consider it.</DIV>
<DIV><BR>Cheers,</DIV>
<DIV>Adrian</FONT></DIV></BODY></HTML>

------=_NextPart_000_0E0E_01C53068.1A6EFAE0--




Envelope-to: [e-mail]
Delivery-date: Thu, 24 Mar 2005 10:13:35 +0000
Date: Thu, 24 Mar 2005 18:01:48 +0800
From: Amit 70405 <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
To: Adrian Farrel <[e-mail]>, Diego Caviglia <[e-mail]>
Cc: "<Sasha" <[e-mail]>, "<ccamp" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi Adrian,
   Do you mean to say that Data plane & Control plane protection should be independant of each other??
   If so, in case of MSP protection in SDH, 
    Control plane should not have any control over the resource pool 
     used for MSP switch.
   This may lead to lot of unused resource in the network.
Regards,
Amit.


----- Original Message -----
From: Diego Caviglia <[e-mail]>
Date: Thursday, March 24, 2005 4:03 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> 
> Hi Adrian,
>           thanks for taking part to this discussion.
> 
> Please find my comments in line.
> 
> Regards
> 
> Diego
> 
> 
> 
> "Adrian Farrel" <[e-mail]> on 23/03/2005 15.58.42
> 
> Please respond to "Adrian Farrel" <[e-mail]>
> 
> To:    "Diego Caviglia" <[e-mail]>, 
> <[e-mail]>cc:    <[e-mail]>
> 
> Subject:    Re: Failure definition w.r.t. SONET/SDH and
>       Protection/Restoration
> 
> 
> Hi,
> 
> My initial reaction is that this is way out of scope for CCAMP for 
> a bunch
> of reasons. In particular order:
> 
> - The GMPLS control plane does not necessarily want to define data
>  plane failures. Rather, it wants to signal (report) errors and allow
>  the control plane state (and data plane state) to remain in place.
> [dc] Agreed and that was my initial point.  Which kind of data 
> plane (e.g.
> SDG) defects
> have to advertised to control plane to trigger restoration?  Given 
> thatcontrol plane is concerned in restore the data plane it should 
> also define
> what is a failure.  It is a fiber break or we have also to 
> consider other
> defects? Of course we have.  What happens if one restoration TNE 
> consideras failure only Loss Of Light (LOS) while the other starts 
> restoration even
> if there is a e.g. Loss Of Pointer?  Is that acceptable?
> 
> - Control plane and data plane protection actions need to be carefully
>  separated.
> [dc] Agreed.
> 
> - Decisions that trigger control plane protection actions are
>  fundamentally implementation choices.
> [dc] Here we are.  This is the point.  IMHO CCAMP should provide some
> guidance on this.
> 
>  Maybe we should make a statement that this type
>  of thing SHOULD be configurable so that there is some sort of
>  consistency within a network.
> [dc] Something like "..control plane restoration mechanism SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1).
> 
> - Existing alarm procedures should not be impacted by the use of 
> GMPLS.[dc] Absolutely agreed
> 
> - Data plane technology is not what we do.
> [dc] Absolutely agreed
> 
> But I'm open to discussion.
> 
> Finally, to follow on Sasha's comments, such a draft would 
> probably be
> informational.
> [dc] Ok for me no problem on that.
> 
> Cheers,
> Adrian
> 
> ----- Original Message -----
> From: "Diego Caviglia" <[e-mail]>
> To: "Sasha Vainshtein <Sasha" <[e-mail]>
> Cc: "ccamp <ccamp" <[e-mail]>
> Sent: Wednesday, March 23, 2005 2:01 PM
> Subject: RE: Failure definition w.r.t. SONET/SDH and 
> Protection/Restoration
> 
> 
> >
> > May be Adrian can put come light on the question you raised.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> > Sasha Vainshtein <[e-mail]> on 23/03/2005 14.44.23
> >
> > To:    "'Diego Caviglia'" <[e-mail]>
> > cc:    ccamp <[e-mail]>
> >
> > Subject:    RE: Failure definition w.r.t. SONET/SDH and
> >        Protection/Restoratio        n
> >
> >
> > Diego,
> > I do not see any technical problems with placing such
> > a definition in an Internet-Draft.
> >
> > But there may be problems associated with the IETF process:
> >
> > 1. Do you want to pursue this activity in the CCAMP WG?
> >    I am not sure this is really in the scope as defined
> >    by the CCAMP Charter
> >
> > 2. For interoperability the IETF document should be
> >    a Standards Track RFC. On the other hand, CCAMP is in
> >    the Routing Area meaning that you need an implementation
> >    to publish a Standards Track RFC - but what could be
> >    considered as an implementation in this case?
> >
> > Regards,
> >                                   Sasha Vainshtein
> > email:                         [e-mail]
> <[e-mail]>
> > phone:                       [phone] (office)
> > fax:                            [phone]
> > mobile:                      [phone]
> >
> >
> > > -----Original Message-----
> > > From: Diego Caviglia [[e-mail]]
> > > Sent: Wednesday, March 23, 2005 3:37 PM
> > > To: Sasha Vainshtein
> > > Cc: ccamp
> > > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoratio n
> > >
> > >
> > >
> > > Hi Sasha,
> > >                        I agree with you but in any case for
> > > interop issues
> > > and for sake of clarity I'd like to have that written in some IETF
> > > document.
> > >
> > > Regards
> > >
> > > Diego
> > >
> > >
> > >
> > >
> > >
> > > Sasha Vainshtein <[e-mail]> on 23/03/2005 12.23.12
> > >
> > > To:    "'Diego Caviglia'" <[e-mail]>
> > > cc:    [e-mail]
> > >
> > > Subject:    RE: Failure definition w.r.t. SONET/SDH and
> > >        Protection/Restoratio  n
> > >
> > >
> > > Diego and all,
> > > IMHO it is reasonable to assume that a failure is
> > > a defect that results in sending downstream AIS
> > > (and upstream RDI) as consequent action(s).
> > >
> > > For SDH consecutive actions for each defect
> > > are specified in ITU-T G.783.
> > >
> > > Note also that for some defects the consecutive action
> > > can be disabled by configuration. Hence I'd say that
> > > the same defect can be a failure in one case and
> > > not a failure in another case. The typical example
> > > is Trail Identifier Mismatch (TIM).
> > >
> > > Hopefully this note will help.
> > >
> > > Regards,
> > >                                   Sasha Vainshtein
> > > email:                         [e-mail]
> > > <[e-mail]>
> > > phone:                       [phone] (office)
> > > fax:                            [phone]
> > > mobile:                      [phone]
> > >
> > >
> > > > -----Original Message-----
> > > > From: Diego Caviglia [[e-mail]]
> > > > Sent: Wednesday, March 23, 2005 1:06 PM
> > > > To: [e-mail]
> > > > Subject: Failure definition w.r.t. SONET/SDH and
> > > > Protection/Restoration
> > > >
> > > >
> > > > Hi all,
> > > >               is it defined somewhere, with respect to
> > > > SDH/SONET, which
> > > > defect has to be consider as a failure?
> > > >
> > > > It seems to me that for interoperability could be useful to
> > > > have a list of
> > > > defect that must be considered as failure, the same applies
> > > > for defect that
> > > > optionally can be considered as defect.
> > > >
> > > > May be also a communication between restoration TNEs in order
> > > > to agree on
> > > > the list could be useful.
> > > >
> > > > Does anyone agree on that?
> > > >
> > > > Regards
> > > >
> > > > Diego
> > > >
> > > > PS I apologise if the list is defined somewhere but I wasn't
> > > > able to find
> > > > it.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Thu, 24 Mar 2005 08:05:23 +0000
Sensitivity: 
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
To: "Adrian Farrel" <[e-mail]>
Cc: "<Sasha" <[e-mail]>, "<ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Thu, 24 Mar 2005 09:03:52 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Adrian,
           thanks for taking part to this discussion.

Please find my comments in line.

Regards

Diego



"Adrian Farrel" <[e-mail]> on 23/03/2005 15.58.42

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

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

Subject:    Re: Failure definition w.r.t. SONET/SDH and
       Protection/Restoration


Hi,

My initial reaction is that this is way out of scope for CCAMP for a bunch
of reasons. In particular order:

- The GMPLS control plane does not necessarily want to define data
  plane failures. Rather, it wants to signal (report) errors and allow
  the control plane state (and data plane state) to remain in place.
[dc] Agreed and that was my initial point.  Which kind of data plane (e.g.
SDG) defects
have to advertised to control plane to trigger restoration?  Given that
control plane is concerned in restore the data plane it should also define
what is a failure.  It is a fiber break or we have also to consider other
defects? Of course we have.  What happens if one restoration TNE consider
as failure only Loss Of Light (LOS) while the other starts restoration even
if there is a e.g. Loss Of Pointer?  Is that acceptable?

- Control plane and data plane protection actions need to be carefully
  separated.
[dc] Agreed.

- Decisions that trigger control plane protection actions are
  fundamentally implementation choices.
[dc] Here we are.  This is the point.  IMHO CCAMP should provide some
guidance on this.

  Maybe we should make a statement that this type
  of thing SHOULD be configurable so that there is some sort of
  consistency within a network.
[dc] Something like "..control plane restoration mechanism SHOULD be
triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1).

- Existing alarm procedures should not be impacted by the use of GMPLS.
[dc] Absolutely agreed

- Data plane technology is not what we do.
[dc] Absolutely agreed

But I'm open to discussion.

Finally, to follow on Sasha's comments, such a draft would probably be
informational.
[dc] Ok for me no problem on that.

Cheers,
Adrian

----- Original Message -----
From: "Diego Caviglia" <[e-mail]>
To: "Sasha Vainshtein <Sasha" <[e-mail]>
Cc: "ccamp <ccamp" <[e-mail]>
Sent: Wednesday, March 23, 2005 2:01 PM
Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio
n


>
> May be Adrian can put come light on the question you raised.
>
> Regards
>
> Diego
>
>
>
> Sasha Vainshtein <[e-mail]> on 23/03/2005 14.44.23
>
> To:    "'Diego Caviglia'" <[e-mail]>
> cc:    ccamp <[e-mail]>
>
> Subject:    RE: Failure definition w.r.t. SONET/SDH and
>        Protection/Restoratio        n
>
>
> Diego,
> I do not see any technical problems with placing such
> a definition in an Internet-Draft.
>
> But there may be problems associated with the IETF process:
>
> 1. Do you want to pursue this activity in the CCAMP WG?
>    I am not sure this is really in the scope as defined
>    by the CCAMP Charter
>
> 2. For interoperability the IETF document should be
>    a Standards Track RFC. On the other hand, CCAMP is in
>    the Routing Area meaning that you need an implementation
>    to publish a Standards Track RFC - but what could be
>    considered as an implementation in this case?
>
> Regards,
>                                   Sasha Vainshtein
> email:                         [e-mail]
<mailto:[e-mail]>
> phone:                       [phone] (office)
> fax:                            [phone]
> mobile:                      [phone]
>
>
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[e-mail]]
> > Sent: Wednesday, March 23, 2005 3:37 PM
> > To: Sasha Vainshtein
> > Cc: ccamp
> > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoratio n
> >
> >
> >
> > Hi Sasha,
> >                        I agree with you but in any case for
> > interop issues
> > and for sake of clarity I'd like to have that written in some IETF
> > document.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >
> > Sasha Vainshtein <[e-mail]> on 23/03/2005 12.23.12
> >
> > To:    "'Diego Caviglia'" <[e-mail]>
> > cc:    [e-mail]
> >
> > Subject:    RE: Failure definition w.r.t. SONET/SDH and
> >        Protection/Restoratio  n
> >
> >
> > Diego and all,
> > IMHO it is reasonable to assume that a failure is
> > a defect that results in sending downstream AIS
> > (and upstream RDI) as consequent action(s).
> >
> > For SDH consecutive actions for each defect
> > are specified in ITU-T G.783.
> >
> > Note also that for some defects the consecutive action
> > can be disabled by configuration. Hence I'd say that
> > the same defect can be a failure in one case and
> > not a failure in another case. The typical example
> > is Trail Identifier Mismatch (TIM).
> >
> > Hopefully this note will help.
> >
> > Regards,
> >                                   Sasha Vainshtein
> > email:                         [e-mail]
> > <mailto:[e-mail]>
> > phone:                       [phone] (office)
> > fax:                            [phone]
> > mobile:                      [phone]
> >
> >
> > > -----Original Message-----
> > > From: Diego Caviglia [mailto:[e-mail]]
> > > Sent: Wednesday, March 23, 2005 1:06 PM
> > > To: [e-mail]
> > > Subject: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoration
> > >
> > >
> > > Hi all,
> > >               is it defined somewhere, with respect to
> > > SDH/SONET, which
> > > defect has to be consider as a failure?
> > >
> > > It seems to me that for interoperability could be useful to
> > > have a list of
> > > defect that must be considered as failure, the same applies
> > > for defect that
> > > optionally can be considered as defect.
> > >
> > > May be also a communication between restoration TNEs in order
> > > to agree on
> > > the list could be useful.
> > >
> > > Does anyone agree on that?
> > >
> > > Regards
> > >
> > > Diego
> > >
> > > PS I apologise if the list is defined somewhere but I wasn't
> > > able to find
> > > it.
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>











Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 22:08:57 +0000
Date: Wed, 23 Mar 2005 14:08:13 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: [e-mail]
cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: WG drafts - My correction
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dimitri,

> 2. I have seen consensus for draft-ayyangar-ccamp-lsp-stitching to be
> published as a WG draft and the authors will submit it as
> draft-ietf-ccamp-lsp-stitching soon
>
> -> agreed - note: would you tell us (or authors) when comments made on
> this list would then be incorporated ?
-------> I think the plan was to first republish as WG draft with *no*
changes. Following that, we could submit another version shortly incorporating
the comments made on the list.

thanks,
-arthi

>
> 3. The name of the third draft is
> draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the draft that we
> need to consider.
>
> As JP says, he plans to add the sentence "In the context of this draft,
> the node in charge of any ERO expansion within its domain is always along
> the inter-domain TE LSP path" to this draft.
>
> -> reading through the document and taking section 4 as the core, i
> wonder why examples of the same section are prescriptive ? is there by no
> means a way to re-write this document in prescriptive mode (since afaik
> this is intended to become a proposed standard and not an informational
> document) and only give examples in appendix and not use examples to
> describe its core content -
>
>
> Question: With the addition of this sentence, are we content to accept
> this draft as a WG draft?
>
> Thanks,
> Adrian
>
>
>



Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 22:05:00 +0000
Message-ID: <0da201c52ff4$77bb5aa0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration
Date: Wed, 23 Mar 2005 14:58:42 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

My initial reaction is that this is way out of scope for CCAMP for a bunch
of reasons. In particular order:

- The GMPLS control plane does not necessarily want to define data
  plane failures. Rather, it wants to signal (report) errors and allow
  the control plane state (and data plane state) to remain in place.
- Control plane and data plane protection actions need to be carefully
  separated.
- Decisions that trigger control plane protection actions are
fundamentally
  implementation choices. Maybe we should make a statement that this type
  of thing SHOULD be configurable so that there is some sort of
  consistency within a network.
- Existing alarm procedures should not be impacted by the use of GMPLS.
- Data plane technology is not what we do.

But I'm open to discussion.

Finally, to follow on Sasha's comments, such a draft would probably be
informational.

Cheers,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: "Sasha Vainshtein <Sasha" <[e-mail]>
Cc: "ccamp <ccamp" <[e-mail]>
Sent: Wednesday, March 23, 2005 2:01 PM
Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio
n


>
> May be Adrian can put come light on the question you raised.
>
> Regards
>
> Diego
>
>
>
> Sasha Vainshtein <[e-mail]> on 23/03/2005 14.44.23
>
> To:    "'Diego Caviglia'" <[e-mail]>
> cc:    ccamp <[e-mail]>
>
> Subject:    RE: Failure definition w.r.t. SONET/SDH and
>        Protection/Restoratio        n
>
>
> Diego,
> I do not see any technical problems with placing such
> a definition in an Internet-Draft.
>
> But there may be problems associated with the IETF process:
>
> 1. Do you want to pursue this activity in the CCAMP WG?
>    I am not sure this is really in the scope as defined
>    by the CCAMP Charter
>
> 2. For interoperability the IETF document should be
>    a Standards Track RFC. On the other hand, CCAMP is in
>    the Routing Area meaning that you need an implementation
>    to publish a Standards Track RFC - but what could be
>    considered as an implementation in this case?
>
> Regards,
>                                   Sasha Vainshtein
> email:                         [e-mail]
<mailto:[e-mail]>
> phone:                       [phone] (office)
> fax:                            [phone]
> mobile:                      [phone]
>
>
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[e-mail]]
> > Sent: Wednesday, March 23, 2005 3:37 PM
> > To: Sasha Vainshtein
> > Cc: ccamp
> > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoratio n
> >
> >
> >
> > Hi Sasha,
> >                        I agree with you but in any case for
> > interop issues
> > and for sake of clarity I'd like to have that written in some IETF
> > document.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >
> > Sasha Vainshtein <[e-mail]> on 23/03/2005 12.23.12
> >
> > To:    "'Diego Caviglia'" <[e-mail]>
> > cc:    [e-mail]
> >
> > Subject:    RE: Failure definition w.r.t. SONET/SDH and
> >        Protection/Restoratio  n
> >
> >
> > Diego and all,
> > IMHO it is reasonable to assume that a failure is
> > a defect that results in sending downstream AIS
> > (and upstream RDI) as consequent action(s).
> >
> > For SDH consecutive actions for each defect
> > are specified in ITU-T G.783.
> >
> > Note also that for some defects the consecutive action
> > can be disabled by configuration. Hence I'd say that
> > the same defect can be a failure in one case and
> > not a failure in another case. The typical example
> > is Trail Identifier Mismatch (TIM).
> >
> > Hopefully this note will help.
> >
> > Regards,
> >                                   Sasha Vainshtein
> > email:                         [e-mail]
> > <mailto:[e-mail]>
> > phone:                       [phone] (office)
> > fax:                            [phone]
> > mobile:                      [phone]
> >
> >
> > > -----Original Message-----
> > > From: Diego Caviglia [mailto:[e-mail]]
> > > Sent: Wednesday, March 23, 2005 1:06 PM
> > > To: [e-mail]
> > > Subject: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoration
> > >
> > >
> > > Hi all,
> > >               is it defined somewhere, with respect to
> > > SDH/SONET, which
> > > defect has to be consider as a failure?
> > >
> > > It seems to me that for interoperability could be useful to
> > > have a list of
> > > defect that must be considered as failure, the same applies
> > > for defect that
> > > optionally can be considered as defect.
> > >
> > > May be also a communication between restoration TNEs in order
> > > to agree on
> > > the list could be useful.
> > >
> > > Does anyone agree on that?
> > >
> > > Regards
> > >
> > > Diego
> > >
> > > PS I apologise if the list is defined somewhere but I wasn't
> > > able to find
> > > it.
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 21:07:25 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>,  ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>, ccamp chair <[e-mail]>
Subject: Protocol Action: 'Generalize Multiprotocol Label  Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation  Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model'  to Proposed Standard 
Message-Id: <[e-mail]>
Date: Wed, 23 Mar 2005 16:07:16 -0500

The IESG has approved the following document:

- 'Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface 
   (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support 
   for the Overlay Model '
   <draft-ietf-ccamp-gmpls-overlay-05.txt> as a Proposed Standard

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

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
   Generalized Multiprotocol Label Switching (GMPLS) defines both
   routing and signaling protocols for the creation of Label Switched
   Paths (LSPs) in various switching technologies. These protocols can
   be used to support a number of deployment scenarios. This memo
   addresses the application of GMPLS to the overlay model.
 
Working Group Summary
 
   The WG had a consensus on advancing this document.
 
Protocol Quality
 
   Dimitri Papadimitriou reviewed this document for the RTG-DIR, and
   Alex Zinin reviewed this document for the IESG.

RFC Editor Note:

Section 8. Security Considerations

OLD:
   This draft imposes no new security risks over [RFC3473]. In fact it
   represents a lower trust model between the core and edge-nodes as the
   core is permitted to hide its topology from the edge-nodes. The core
   is also permitted to restrict the actions of edge-nodes by filtering
   out specific RSVP objects.

NEW:
   The trust model between the core and edge-nodes is different
   than the one described in [RFC3473], as the core is permitted to
   hide its topology from the edge-nodes, and the core is permitted
   to restrict the actions of edge-nodes by filtering out specific
   RSVP objects.


IANA Note:

 This document requires no IANA action.




Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 21:06:53 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>,  ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>, ccamp chair <[e-mail]>
Subject: Protocol Action: 'Generalized MPLS (GMPLS) Signaling  Extensions for G.709 Optical Transport Networks Control' to Proposed  Standard 
Message-Id: <[e-mail]>
Date: Wed, 23 Mar 2005 16:05:55 -0500

The IESG has approved the following document:

- 'Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport 
   Networks Control '
   <draft-ietf-ccamp-gmpls-g709-09.txt> as a Proposed Standard

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

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
   This document is a companion to the Generalized MPLS (GMPLS) 
   signaling documents. It describes the technology specific 
   information needed to extend GMPLS signaling to control Optical 
   Transport Networks (OTN); it also includes the so-called pre-OTN 
   developments.  
 
Working Group Summary
 
   The WG had a consensus on advancing this document.
 
Protocol Quality
 
  Alex Zinin reviewed this document for the IESG.
  There is at least one implementation of the described mechanisms.




Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 19:49:41 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>,  ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>, ccamp chair <[e-mail]>
Subject: Document Action: 'Requirements for Generalized MPLS (GMPLS)  Routing for Automatically Switched Optical Network (ASON)' to  Informational RFC 
Message-Id: <[e-mail]>
Date: Wed, 23 Mar 2005 14:47:50 -0500

The IESG has approved the following document:

- 'Requirements for Generalized MPLS (GMPLS) Routing for Automatically 
   Switched Optical Network (ASON) '
   <draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt> as an Informational RFC

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

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
   The Generalized Multi-Protocol Label Switching (GMPLS) suite of 
   protocols has been defined to control different switching 
   technologies as well as different applications. These include support 
   for requesting Time Division Multiplexing (TDM) connections including 
   Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy 
   (SDH) and Optical Transport Networks (OTNs). 
   This document concentrates on the routing requirements on the GMPLS 
   suite of protocols to support the capabilities and functionalities 
   for an Automatically Switched Optical Network (ASON) as defined by 
   ITU-T.  
 
Working Group Summary
 
 This document is the product of a design team that included IETF and ITU
 members. The goal of the document was to represent routing-related 
 requirements for ASON networks received from ITU in a liaison statement 
 in the form understandable for a usual IETF participant.
 
Protocol Quality

 This document has been reviewed for IESG by Alex Zinin. Adrian Farrel
 followed up with the WG on the provided comments.

IANA Note
 
 This document required no specific IANA action.




Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 16:11:30 +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: Failure definition w.r.t. SONET/SDH and Protection/Restoratio 	n
Date: Wed, 23 Mar 2005 10:10:25 -0600
Message-ID: <[e-mail]>
Thread-Topic: Failure definition w.r.t. SONET/SDH and Protection/Restoratio 	n
Thread-Index: AcUvvSyGOamZm8+CQ9enJZOhhSTyBgAAgq5w
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Stephen J Trowbridge" <[e-mail]>, "Sasha Vainshtein" <[e-mail]>
Cc: "Diego Caviglia" <[e-mail]>, "ccamp" <[e-mail]>

Not sure the context of your question Diego? ITU provides the
definitions allowing interop. And CCAMP does have documents referencing
- CCAMP's recovery documents (terminology, analysis, functional,
signaling). CCAMP's documents were based on the approach as Steve
described - terminology alignment with ITU/T1X1 (e.g. defect, failure,
SF, SD) and references to the T1X1/ITU documents (T1.105, G.806, G.783,
G.841/842, G.808.1). These ITU documents also include differences
between SONET and SDH. If you have questions on specific
defects/failures (eg TIM), suggest sending mail on the ITU's SG15 q9
exploder.

Deborah=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen J Trowbridge
Sent: Wednesday, March 23, 2005 10:27 AM
To: Sasha Vainshtein
Cc: 'Diego Caviglia'; ccamp
Subject: Re: Failure definition w.r.t. SONET/SDH and
Protection/Restoratio n

Sasha and Diego,
IMHO, it is a very bad idea to have two "normative" places where
something is
standardized.
You already have the SDH standards in ITU-T documents (G.707, G.783,
etc.) and
the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the
T1.105
series). There is no reason that standards track RFCs cannot make
normative
references to these documents where needed. It would be inappropriate
for IETF
to attempt to replicate these documents as RFCs.
Regards,
Steve

On 3/23/2005 6:44 AM, Sasha Vainshtein wrote:
> Diego,
> I do not see any technical problems with placing such
> a definition in an Internet-Draft.
>=20
> But there may be problems associated with the IETF process:
>=20
> 1. Do you want to pursue this activity in the CCAMP WG?=20
>    I am not sure this is really in the scope as defined
>    by the CCAMP Charter
>=20
> 2. For interoperability the IETF document should be
>    a Standards Track RFC. On the other hand, CCAMP is in
>    the Routing Area meaning that you need an implementation
>    to publish a Standards Track RFC - but what could be
>    considered as an implementation in this case?
>=20
> Regards,
>                                   Sasha Vainshtein
> email:                         [e-mail]
<mailto:[e-mail]>=20
> phone:                       [phone] (office)
> fax:                            [phone]
> mobile:                      [phone]=20
>=20
>=20
>=20
>>-----Original Message-----
>>From: Diego Caviglia [mailto:[e-mail]]
>>Sent: Wednesday, March 23, 2005 3:37 PM
>>To: Sasha Vainshtein
>>Cc: ccamp
>>Subject: RE: Failure definition w.r.t. SONET/SDH and=20
>>Protection/Restoratio n
>>
>>
>>
>>Hi Sasha,
>>                       I agree with you but in any case for=20
>>interop issues
>>and for sake of clarity I'd like to have that written in some IETF
>>document.
>>
>>Regards
>>
>>Diego
>>
>>
>>
>>
>>
>>Sasha Vainshtein <[e-mail]> on 23/03/2005 12.23.12
>>
>>To:    "'Diego Caviglia'" <[e-mail]>
>>cc:    [e-mail]
>>
>>Subject:    RE: Failure definition w.r.t. SONET/SDH and
>>       Protection/Restoratio  n
>>
>>
>>Diego and all,
>>IMHO it is reasonable to assume that a failure is
>>a defect that results in sending downstream AIS
>>(and upstream RDI) as consequent action(s).
>>
>>For SDH consecutive actions for each defect
>>are specified in ITU-T G.783.
>>
>>Note also that for some defects the consecutive action
>>can be disabled by configuration. Hence I'd say that
>>the same defect can be a failure in one case and
>>not a failure in another case. The typical example
>>is Trail Identifier Mismatch (TIM).
>>
>>Hopefully this note will help.
>>
>>Regards,
>>                                  Sasha Vainshtein
>>email:                         [e-mail]=20
>><mailto:[e-mail]>
>>phone:                       [phone] (office)
>>fax:                            [phone]
>>mobile:                      [phone]
>>
>>
>>
>>>-----Original Message-----
>>>From: Diego Caviglia [mailto:[e-mail]]
>>>Sent: Wednesday, March 23, 2005 1:06 PM
>>>To: [e-mail]
>>>Subject: Failure definition w.r.t. SONET/SDH and
>>>Protection/Restoration
>>>
>>>
>>>Hi all,
>>>              is it defined somewhere, with respect to
>>>SDH/SONET, which
>>>defect has to be consider as a failure?
>>>
>>>It seems to me that for interoperability could be useful to
>>>have a list of
>>>defect that must be considered as failure, the same applies
>>>for defect that
>>>optionally can be considered as defect.
>>>
>>>May be also a communication between restoration TNEs in order
>>>to agree on
>>>the list could be useful.
>>>
>>>Does anyone agree on that?
>>>
>>>Regards
>>>
>>>Diego
>>>
>>>PS I apologise if the list is defined somewhere but I wasn't
>>>able to find
>>>it.
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>=20








Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 15:42:13 +0000
Sensitivity: 
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio 	n
To: "Stephen J Trowbridge <sjtrowbridge" <[e-mail]>
Cc: "Sasha Vainshtein <Sasha" <[e-mail]>, "ccamp <ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 23 Mar 2005 16:41:47 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Stephen,
                    for me is ok to have a reference to the ITU-T doc in a
IETF doc.

The point is that seems there is no reference to that in any IETF ID/RFC.

So if your proposal is to add a reference to ITU-T in some already existing
IETF draft that is ok for me.

Regards

Diego



Stephen J Trowbridge <[e-mail]> on 23/03/2005 16.26.47

To:    Sasha Vainshtein <[e-mail]>
cc:    "'Diego Caviglia'" <[e-mail]>, ccamp
       <[e-mail]>

Subject:    Re: Failure definition w.r.t. SONET/SDH and
       Protection/Restoratio  n


Sasha and Diego,
IMHO, it is a very bad idea to have two "normative" places where something
is
standardized.
You already have the SDH standards in ITU-T documents (G.707, G.783, etc.)
and
the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the
T1.105
series). There is no reason that standards track RFCs cannot make normative
references to these documents where needed. It would be inappropriate for
IETF
to attempt to replicate these documents as RFCs.
Regards,
Steve

On 3/23/2005 6:44 AM, Sasha Vainshtein wrote:
> Diego,
> I do not see any technical problems with placing such
> a definition in an Internet-Draft.
>
> But there may be problems associated with the IETF process:
>
> 1. Do you want to pursue this activity in the CCAMP WG?
>    I am not sure this is really in the scope as defined
>    by the CCAMP Charter
>
> 2. For interoperability the IETF document should be
>    a Standards Track RFC. On the other hand, CCAMP is in
>    the Routing Area meaning that you need an implementation
>    to publish a Standards Track RFC - but what could be
>    considered as an implementation in this case?
>
> Regards,
>                                   Sasha Vainshtein
> email:                         [e-mail] <mailto:[e-mail]>
> phone:                       [phone] (office)
> fax:                            [phone]
> mobile:                      [phone]
>
>
>
>>-----Original Message-----
>>From: Diego Caviglia [mailto:[e-mail]]
>>Sent: Wednesday, March 23, 2005 3:37 PM
>>To: Sasha Vainshtein
>>Cc: ccamp
>>Subject: RE: Failure definition w.r.t. SONET/SDH and
>>Protection/Restoratio n
>>
>>
>>
>>Hi Sasha,
>>                       I agree with you but in any case for
>>interop issues
>>and for sake of clarity I'd like to have that written in some IETF
>>document.
>>
>>Regards
>>
>>Diego
>>
>>
>>
>>
>>
>>Sasha Vainshtein <[e-mail]> on 23/03/2005 12.23.12
>>
>>To:    "'Diego Caviglia'" <[e-mail]>
>>cc:    [e-mail]
>>
>>Subject:    RE: Failure definition w.r.t. SONET/SDH and
>>       Protection/Restoratio  n
>>
>>
>>Diego and all,
>>IMHO it is reasonable to assume that a failure is
>>a defect that results in sending downstream AIS
>>(and upstream RDI) as consequent action(s).
>>
>>For SDH consecutive actions for each defect
>>are specified in ITU-T G.783.
>>
>>Note also that for some defects the consecutive action
>>can be disabled by configuration. Hence I'd say that
>>the same defect can be a failure in one case and
>>not a failure in another case. The typical example
>>is Trail Identifier Mismatch (TIM).
>>
>>Hopefully this note will help.
>>
>>Regards,
>>                                  Sasha Vainshtein
>>email:                         [e-mail]
>><mailto:[e-mail]>
>>phone:                       [phone] (office)
>>fax:                            [phone]
>>mobile:                      [phone]
>>
>>
>>
>>>-----Original Message-----
>>>From: Diego Caviglia [mailto:[e-mail]]
>>>Sent: Wednesday, March 23, 2005 1:06 PM
>>>To: [e-mail]
>>>Subject: Failure definition w.r.t. SONET/SDH and
>>>Protection/Restoration
>>>
>>>
>>>Hi all,
>>>              is it defined somewhere, with respect to
>>>SDH/SONET, which
>>>defect has to be consider as a failure?
>>>
>>>It seems to me that for interoperability could be useful to
>>>have a list of
>>>defect that must be considered as failure, the same applies
>>>for defect that
>>>optionally can be considered as defect.
>>>
>>>May be also a communication between restoration TNEs in order
>>>to agree on
>>>the list could be useful.
>>>
>>>Does anyone agree on that?
>>>
>>>Regards
>>>
>>>Diego
>>>
>>>PS I apologise if the list is defined somewhere but I wasn't
>>>able to find
>>>it.
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>










Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 15:38:17 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: WG drafts - My correction
Date: Wed, 23 Mar 2005 16:37:37 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+aGkgYWRyaWFuIC0gdHdvIHBvaW50cyBoZXJlIGJlbG93IDxCUj48QlI+PEZPTlQgU0laRT0y
PjxCPiZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7
PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRm
Lm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjAzLzIzLzIwMDUgMDA6MTYgR01UPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQgdG8gJnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90
OzwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+Jmx0
O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05U
PiA8QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0
OjwvRk9OVD4gPEZPTlQgU0laRT0yPldHIGRyYWZ0cyAtIE15IGNvcnJlY3Rpb248L0ZPTlQ+PEJS
PiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGhhbmtzIHRv
IHRob3NlIG9mIHlvdSB3aG8gcG9pbnRlZCBvdXQgbXkgbWlzdGFrZSBvbiBhbmQgb2ZmIHRoZSBs
aXN0LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UbyBzZXQg
dGhpbmdzIHN0cmFpZ2h0Li4uPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv
dXJpZXIiPjEuIFdlIGhhdmUgYWxyZWFkeSBhY2NlcHRlZCBkcmFmdC1heXlhbmdhci1jY2FtcC1p
bnRlci1kb21haW4tcnN2cC10ZSBhcyBhPEJSPldHIGRyYWZ0IGFuZCBpdCBoYXMgYmVlbiBwdWJs
aXNoZWQgYXM8QlI+ZHJhZnQtaWV0Zi1jY2FtcC1pbnRlci1kb21haW4tcnN2cC10ZTxCUj48L0ZP
TlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4yLiBJIGhhdmUgc2VlbiBjb25z
ZW5zdXMgZm9yIGRyYWZ0LWF5eWFuZ2FyLWNjYW1wLWxzcC1zdGl0Y2hpbmcgdG8gYmU8QlI+cHVi
bGlzaGVkIGFzIGEgV0cgZHJhZnQgYW5kIHRoZSBhdXRob3JzIHdpbGwgc3VibWl0IGl0IGFzPEJS
PmRyYWZ0LWlldGYtY2NhbXAtbHNwLXN0aXRjaGluZyBzb29uPEJSPjwvRk9OVD48L1A+PFA+PEZP
TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0mZ3Q7IGFncmVlZCAtIG5vdGU6IHdvdWxkIHlv
dSB0ZWxsIHVzIChvciBhdXRob3JzKSB3aGVuIGNvbW1lbnRzIG1hZGUgb24gdGhpcyBsaXN0IHdv
dWxkIHRoZW4gYmUgaW5jb3Jwb3JhdGVkID88L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj48QlI+My4gVGhlIG5hbWUgb2YgdGhlIHRoaXJkIGRyYWZ0IGlzPEJSPmRy
YWZ0LXZhc3NldXItY2NhbXAtaW50ZXItZG9tYWluLXBkLXBhdGgtY29tcC4gVGhpcyBpcyB0aGUg
ZHJhZnQgdGhhdCB3ZTxCUj5uZWVkIHRvIGNvbnNpZGVyLjxCUj48QlI+QXMgSlAgc2F5cywgaGUg
cGxhbnMgdG8gYWRkIHRoZSBzZW50ZW5jZSAmcXVvdDtJbiB0aGUgY29udGV4dCBvZiB0aGlzIGRy
YWZ0LDxCUj50aGUgbm9kZSBpbiBjaGFyZ2Ugb2YgYW55IEVSTyBleHBhbnNpb24gd2l0aGluIGl0
cyBkb21haW4gaXMgYWx3YXlzIGFsb25nPEJSPnRoZSBpbnRlci1kb21haW4gVEUgTFNQIHBhdGgm
cXVvdDsgdG8gdGhpcyBkcmFmdC48QlI+PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3Bh
Y2UsQ291cmllciI+LSZndDsgcmVhZGluZyB0aHJvdWdoIHRoZSBkb2N1bWVudCBhbmQgdGFraW5n
IHNlY3Rpb24gNCBhcyB0aGUgY29yZSwgaSB3b25kZXIgd2h5IGV4YW1wbGVzIG9mIHRoZSBzYW1l
IHNlY3Rpb24gYXJlIHByZXNjcmlwdGl2ZSA/IGlzIHRoZXJlIGJ5IG5vIG1lYW5zIGEgd2F5IHRv
IHJlLXdyaXRlIHRoaXMgZG9jdW1lbnQgaW4gcHJlc2NyaXB0aXZlIG1vZGUgKHNpbmNlIGFmYWlr
IHRoaXMgaXMgaW50ZW5kZWQgdG8gYmVjb21lIGEgcHJvcG9zZWQgc3RhbmRhcmQgYW5kIG5vdCBh
biBpbmZvcm1hdGlvbmFsIGRvY3VtZW50KSBhbmQgb25seSBnaXZlIGV4YW1wbGVzIGluIGFwcGVu
ZGl4IGFuZCBub3QgdXNlIGV4YW1wbGVzIHRvIGRlc2NyaWJlIGl0cyBjb3JlIGNvbnRlbnQgLSA8
L0ZPTlQ+PC9QPjxQPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+UXVlc3Rpb246
IFdpdGggdGhlIGFkZGl0aW9uIG9mIHRoaXMgc2VudGVuY2UsIGFyZSB3ZSBjb250ZW50IHRvIGFj
Y2VwdDxCUj50aGlzIGRyYWZ0IGFzIGEgV0cgZHJhZnQ/PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPlRoYW5rcyw8QlI+QWRyaWFuPEJSPjwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 15:29:02 +0000
Message-ID: <[e-mail]>
Date: Wed, 23 Mar 2005 08:26:47 -0700
From: Stephen J Trowbridge <[e-mail]>
Organization: Lucent Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES)
MIME-Version: 1.0
To: Sasha Vainshtein <[e-mail]>
CC: "'Diego Caviglia'" <[e-mail]>, ccamp <[e-mail]>
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n
Content-Type: text/plain; charset=ISO-8859-8
Content-Transfer-Encoding: 7bit

Sasha and Diego,
IMHO, it is a very bad idea to have two "normative" places where something is
standardized.
You already have the SDH standards in ITU-T documents (G.707, G.783, etc.) and
the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the T1.105
series). There is no reason that standards track RFCs cannot make normative
references to these documents where needed. It would be inappropriate for IETF
to attempt to replicate these documents as RFCs.
Regards,
Steve

On 3/23/2005 6:44 AM, Sasha Vainshtein wrote:
> Diego,
> I do not see any technical problems with placing such
> a definition in an Internet-Draft.
> 
> But there may be problems associated with the IETF process:
> 
> 1. Do you want to pursue this activity in the CCAMP WG? 
>    I am not sure this is really in the scope as defined
>    by the CCAMP Charter
> 
> 2. For interoperability the IETF document should be
>    a Standards Track RFC. On the other hand, CCAMP is in
>    the Routing Area meaning that you need an implementation
>    to publish a Standards Track RFC - but what could be
>    considered as an implementation in this case?
> 
> Regards,
>                                   Sasha Vainshtein
> email:                         [e-mail] <mailto:[e-mail]> 
> phone:                       [phone] (office)
> fax:                            [phone]
> mobile:                      [phone] 
> 
> 
> 
>>-----Original Message-----
>>From: Diego Caviglia [mailto:[e-mail]]
>>Sent: Wednesday, March 23, 2005 3:37 PM
>>To: Sasha Vainshtein
>>Cc: ccamp
>>Subject: RE: Failure definition w.r.t. SONET/SDH and 
>>Protection/Restoratio n
>>
>>
>>
>>Hi Sasha,
>>                       I agree with you but in any case for 
>>interop issues
>>and for sake of clarity I'd like to have that written in some IETF
>>document.
>>
>>Regards
>>
>>Diego
>>
>>
>>
>>
>>
>>Sasha Vainshtein <[e-mail]> on 23/03/2005 12.23.12
>>
>>To:    "'Diego Caviglia'" <[e-mail]>
>>cc:    [e-mail]
>>
>>Subject:    RE: Failure definition w.r.t. SONET/SDH and
>>       Protection/Restoratio  n
>>
>>
>>Diego and all,
>>IMHO it is reasonable to assume that a failure is
>>a defect that results in sending downstream AIS
>>(and upstream RDI) as consequent action(s).
>>
>>For SDH consecutive actions for each defect
>>are specified in ITU-T G.783.
>>
>>Note also that for some defects the consecutive action
>>can be disabled by configuration. Hence I'd say that
>>the same defect can be a failure in one case and
>>not a failure in another case. The typical example
>>is Trail Identifier Mismatch (TIM).
>>
>>Hopefully this note will help.
>>
>>Regards,
>>                                  Sasha Vainshtein
>>email:                         [e-mail] 
>><mailto:[e-mail]>
>>phone:                       [phone] (office)
>>fax:                            [phone]
>>mobile:                      [phone]
>>
>>
>>
>>>-----Original Message-----
>>>From: Diego Caviglia [mailto:[e-mail]]
>>>Sent: Wednesday, March 23, 2005 1:06 PM
>>>To: [e-mail]
>>>Subject: Failure definition w.r.t. SONET/SDH and
>>>Protection/Restoration
>>>
>>>
>>>Hi all,
>>>              is it defined somewhere, with respect to
>>>SDH/SONET, which
>>>defect has to be consider as a failure?
>>>
>>>It seems to me that for interoperability could be useful to
>>>have a list of
>>>defect that must be considered as failure, the same applies
>>>for defect that
>>>optionally can be considered as defect.
>>>
>>>May be also a communication between restoration TNEs in order
>>>to agree on
>>>the list could be useful.
>>>
>>>Does anyone agree on that?
>>>
>>>Regards
>>>
>>>Diego
>>>
>>>PS I apologise if the list is defined somewhere but I wasn't
>>>able to find
>>>it.
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 14:01:55 +0000
Sensitivity: 
Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio		n
To: "Sasha Vainshtein <Sasha" <[e-mail]>
Cc: "ccamp <ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 23 Mar 2005 15:01:48 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

May be Adrian can put come light on the question you raised.

Regards

Diego



Sasha Vainshtein <[e-mail]> on 23/03/2005 14.44.23

To:    "'Diego Caviglia'" <[e-mail]>
cc:    ccamp <[e-mail]>

Subject:    RE: Failure definition w.r.t. SONET/SDH and
       Protection/Restoratio        n


Diego,
I do not see any technical problems with placing such
a definition in an Internet-Draft.

But there may be problems associated with the IETF process:

1. Do you want to pursue this activity in the CCAMP WG?
   I am not sure this is really in the scope as defined
   by the CCAMP Charter

2. For interoperability the IETF document should be
   a Standards Track RFC. On the other hand, CCAMP is in
   the Routing Area meaning that you need an implementation
   to publish a Standards Track RFC - but what could be
   considered as an implementation in this case?

Regards,
                                  Sasha Vainshtein
email:                         [e-mail] <mailto:[e-mail]>
phone:                       [phone] (office)
fax:                            [phone]
mobile:                      [phone]


> -----Original Message-----
> From: Diego Caviglia [mailto:[e-mail]]
> Sent: Wednesday, March 23, 2005 3:37 PM
> To: Sasha Vainshtein
> Cc: ccamp
> Subject: RE: Failure definition w.r.t. SONET/SDH and
> Protection/Restoratio n
>
>
>
> Hi Sasha,
>                        I agree with you but in any case for
> interop issues
> and for sake of clarity I'd like to have that written in some IETF
> document.
>
> Regards
>
> Diego
>
>
>
>
>
> Sasha Vainshtein <[e-mail]> on 23/03/2005 12.23.12
>
> To:    "'Diego Caviglia'" <[e-mail]>
> cc:    [e-mail]
>
> Subject:    RE: Failure definition w.r.t. SONET/SDH and
>        Protection/Restoratio  n
>
>
> Diego and all,
> IMHO it is reasonable to assume that a failure is
> a defect that results in sending downstream AIS
> (and upstream RDI) as consequent action(s).
>
> For SDH consecutive actions for each defect
> are specified in ITU-T G.783.
>
> Note also that for some defects the consecutive action
> can be disabled by configuration. Hence I'd say that
> the same defect can be a failure in one case and
> not a failure in another case. The typical example
> is Trail Identifier Mismatch (TIM).
>
> Hopefully this note will help.
>
> Regards,
>                                   Sasha Vainshtein
> email:                         [e-mail]
> <mailto:[e-mail]>
> phone:                       [phone] (office)
> fax:                            [phone]
> mobile:                      [phone]
>
>
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[e-mail]]
> > Sent: Wednesday, March 23, 2005 1:06 PM
> > To: [e-mail]
> > Subject: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoration
> >
> >
> > Hi all,
> >               is it defined somewhere, with respect to
> > SDH/SONET, which
> > defect has to be consider as a failure?
> >
> > It seems to me that for interoperability could be useful to
> > have a list of
> > defect that must be considered as failure, the same applies
> > for defect that
> > optionally can be considered as defect.
> >
> > May be also a communication between restoration TNEs in order
> > to agree on
> > the list could be useful.
> >
> > Does anyone agree on that?
> >
> > Regards
> >
> > Diego
> >
> > PS I apologise if the list is defined somewhere but I wasn't
> > able to find
> > it.
> >
> >
> >
> >
>
>
>
>
>
>








Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 13:52:12 +0000
Message-ID: <AF5018AC03D1D411ABB70002A5091326015E1CC9@TLV1>
From: Sasha Vainshtein <[e-mail]>
To: "'Diego Caviglia'" <[e-mail]>
Cc: ccamp <[e-mail]>
Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n
Date: Wed, 23 Mar 2005 15:44:23 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-8"

Diego,
I do not see any technical problems with placing such
a definition in an Internet-Draft.

But there may be problems associated with the IETF process:

1. Do you want to pursue this activity in the CCAMP WG? 
   I am not sure this is really in the scope as defined
   by the CCAMP Charter

2. For interoperability the IETF document should be
   a Standards Track RFC. On the other hand, CCAMP is in
   the Routing Area meaning that you need an implementation
   to publish a Standards Track RFC - but what could be
   considered as an implementation in this case?

Regards,
                                  Sasha Vainshtein
email:                         [e-mail] <mailto:[e-mail]> 
phone:                       [phone] (office)
fax:                            [phone]
mobile:                      [phone] 


> -----Original Message-----
> From: Diego Caviglia [mailto:[e-mail]]
> Sent: Wednesday, March 23, 2005 3:37 PM
> To: Sasha Vainshtein
> Cc: ccamp
> Subject: RE: Failure definition w.r.t. SONET/SDH and 
> Protection/Restoratio n
> 
> 
> 
> Hi Sasha,
>                        I agree with you but in any case for 
> interop issues
> and for sake of clarity I'd like to have that written in some IETF
> document.
> 
> Regards
> 
> Diego
> 
> 
> 
> 
> 
> Sasha Vainshtein <[e-mail]> on 23/03/2005 12.23.12
> 
> To:    "'Diego Caviglia'" <[e-mail]>
> cc:    [e-mail]
> 
> Subject:    RE: Failure definition w.r.t. SONET/SDH and
>        Protection/Restoratio  n
> 
> 
> Diego and all,
> IMHO it is reasonable to assume that a failure is
> a defect that results in sending downstream AIS
> (and upstream RDI) as consequent action(s).
> 
> For SDH consecutive actions for each defect
> are specified in ITU-T G.783.
> 
> Note also that for some defects the consecutive action
> can be disabled by configuration. Hence I'd say that
> the same defect can be a failure in one case and
> not a failure in another case. The typical example
> is Trail Identifier Mismatch (TIM).
> 
> Hopefully this note will help.
> 
> Regards,
>                                   Sasha Vainshtein
> email:                         [e-mail] 
> <mailto:[e-mail]>
> phone:                       [phone] (office)
> fax:                            [phone]
> mobile:                      [phone]
> 
> 
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[e-mail]]
> > Sent: Wednesday, March 23, 2005 1:06 PM
> > To: [e-mail]
> > Subject: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoration
> >
> >
> > Hi all,
> >               is it defined somewhere, with respect to
> > SDH/SONET, which
> > defect has to be consider as a failure?
> >
> > It seems to me that for interoperability could be useful to
> > have a list of
> > defect that must be considered as failure, the same applies
> > for defect that
> > optionally can be considered as defect.
> >
> > May be also a communication between restoration TNEs in order
> > to agree on
> > the list could be useful.
> >
> > Does anyone agree on that?
> >
> > Regards
> >
> > Diego
> >
> > PS I apologise if the list is defined somewhere but I wasn't
> > able to find
> > it.
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 13:38:43 +0000
Sensitivity: 
Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio	n
To: "Sasha Vainshtein <Sasha" <[e-mail]>
Cc: "ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 23 Mar 2005 14:36:59 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Sasha,
                       I agree with you but in any case for interop issues
and for sake of clarity I'd like to have that written in some IETF
document.

Regards

Diego





Sasha Vainshtein <[e-mail]> on 23/03/2005 12.23.12

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

Subject:    RE: Failure definition w.r.t. SONET/SDH and
       Protection/Restoratio  n


Diego and all,
IMHO it is reasonable to assume that a failure is
a defect that results in sending downstream AIS
(and upstream RDI) as consequent action(s).

For SDH consecutive actions for each defect
are specified in ITU-T G.783.

Note also that for some defects the consecutive action
can be disabled by configuration. Hence I'd say that
the same defect can be a failure in one case and
not a failure in another case. The typical example
is Trail Identifier Mismatch (TIM).

Hopefully this note will help.

Regards,
                                  Sasha Vainshtein
email:                         [e-mail] <mailto:[e-mail]>
phone:                       [phone] (office)
fax:                            [phone]
mobile:                      [phone]


> -----Original Message-----
> From: Diego Caviglia [mailto:[e-mail]]
> Sent: Wednesday, March 23, 2005 1:06 PM
> To: [e-mail]
> Subject: Failure definition w.r.t. SONET/SDH and
> Protection/Restoration
>
>
> Hi all,
>               is it defined somewhere, with respect to
> SDH/SONET, which
> defect has to be consider as a failure?
>
> It seems to me that for interoperability could be useful to
> have a list of
> defect that must be considered as failure, the same applies
> for defect that
> optionally can be considered as defect.
>
> May be also a communication between restoration TNEs in order
> to agree on
> the list could be useful.
>
> Does anyone agree on that?
>
> Regards
>
> Diego
>
> PS I apologise if the list is defined somewhere but I wasn't
> able to find
> it.
>
>
>
>








Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 11:30:41 +0000
Message-ID: <AF5018AC03D1D411ABB70002A5091326015E1CC6@TLV1>
From: Sasha Vainshtein <[e-mail]>
To: "'Diego Caviglia'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n
Date: Wed, 23 Mar 2005 13:23:12 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-8"

Diego and all,
IMHO it is reasonable to assume that a failure is
a defect that results in sending downstream AIS
(and upstream RDI) as consequent action(s).

For SDH consecutive actions for each defect
are specified in ITU-T G.783.

Note also that for some defects the consecutive action
can be disabled by configuration. Hence I'd say that
the same defect can be a failure in one case and 
not a failure in another case. The typical example
is Trail Identifier Mismatch (TIM).

Hopefully this note will help.

Regards,
                                  Sasha Vainshtein
email:                         [e-mail] <mailto:[e-mail]> 
phone:                       [phone] (office)
fax:                            [phone]
mobile:                      [phone] 


> -----Original Message-----
> From: Diego Caviglia [mailto:[e-mail]]
> Sent: Wednesday, March 23, 2005 1:06 PM
> To: [e-mail]
> Subject: Failure definition w.r.t. SONET/SDH and 
> Protection/Restoration
> 
> 
> Hi all,
>               is it defined somewhere, with respect to 
> SDH/SONET, which
> defect has to be consider as a failure?
> 
> It seems to me that for interoperability could be useful to 
> have a list of
> defect that must be considered as failure, the same applies 
> for defect that
> optionally can be considered as defect.
> 
> May be also a communication between restoration TNEs in order 
> to agree on
> the list could be useful.
> 
> Does anyone agree on that?
> 
> Regards
> 
> Diego
> 
> PS I apologise if the list is defined somewhere but I wasn't 
> able to find
> it.
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 11:06:55 +0000
Sensitivity: 
Subject: Failure definition w.r.t. SONET/SDH and Protection/Restoration
To: [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 23 Mar 2005 12:05:49 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi all,
              is it defined somewhere, with respect to SDH/SONET, which
defect has to be consider as a failure?

It seems to me that for interoperability could be useful to have a list of
defect that must be considered as failure, the same applies for defect that
optionally can be considered as defect.

May be also a communication between restoration TNEs in order to agree on
the list could be useful.

Does anyone agree on that?

Regards

Diego

PS I apologise if the list is defined somewhere but I wasn't able to find
it.





Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 09:55:05 +0000
Message-ID: <0cd001c52f8e$8c5465d0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: IETF-62 Proceedings Submission
Date: Wed, 23 Mar 2005 09:55:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Common Control and Measurement Plane WG (ccamp)

Tuesday, March 8, 2005 at 0900-1130
Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen

Working group status - chairs
- No changes to the agenda made.
- Adrian reviewed status of drafts, reviewed charter milestones.
  We are holding off on new charter until finish last call of 8
  drafts, expect 1-2 months.
- Bill summarized ADs view, should wait for re-chartering until
  finish last call considering expectation will be very soon for
  last calls.
* Dimitri asked about IPR assertion on re-optimization draft
  - Adrian said it did not give the same terms that have been seen
    in some recent IPR claims. The WG has to decide what to do.
  - Scott Bradner said we need to be very careful.  Advised there
    may be anti-trust issues. Best to have no IETF interaction
    other than to ask for clarity.
    Scott offered to review emails on the subject.
  - JP said we can take that as a way to go forward and continue
    technical work.

ASON considerations

ITU liaison - Lyndon Ong presented Wesam's slides
- Thanks to the IETF for liaisons and participation of Adrian and
  Igor at last meetings
- Crankback and the comparison of LMP and ASON discovery will be
  incorporated in SG15 Q14's work.
- There are two liaisons from ITU to CCAMP on the way.
- Routing - ITU not planning any routing exts work, looking to
  IETF's work.
- Continuing work on ASON management.
- An FTP site is available for liaison statements.
* Adrian asked if ITU plans to liaise G.7713 on new text for
  crankback before consent?
  - Lyndon said a meeting is upcoming and will ask for it to be
    considered.
* Kireeti asked if there is any problem in that the crankback draft
  is not an RFC yet?
  - Adrian - RFC is desirable, not required?
  - Scott Bradner - it is required to have an RFC number for final
    balloting. The IESG can request expedited publication.
* Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU
  terminology, and may want to consider including it.
  - Adrian - can that be liaised to us?
  - Steve Trowbridge - Yes, we can do that.

ASON Routing Evaluation
* Adrian - The design team on routing has members from both ITU and
  IETF, although we did not do the correct process, so ITU reps are
  individuals, not ITU representatives.
  - Adrian will work with Steve to formalize the process.
* Adrian - Would like to make the draft from the team on evaluation
  of routing protocols into a working group draft
  - we will take to the list to see if any objection.
* Dimitri - asked if we can use formal liaison process to send this
  draft to ITU, does it need to be WG draft? And encourages comments
  now, before it goes to last call.
  - Adrian - we can liaise the draft and our intention to consider it
    as a WG draft

Lexicography draft (Adrian)
- Q14 indicates meeting went well, authors summarized comments and
  incorporated in this release.
* Adrian asked if should be WG draft
  - Kireeti said we could do that, need to ask the list, also need to
    compare with G.8081
* Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC
  or drafts, are there definitions?
  - Adrian thinks there are good terms, though in multiple
    RFCs/drafts.
  - Ben - if someone is new to the IETF, they have difficulty on
    where to go for definitions.
  - Adrian - if people want to do a draft to collect definitions of all
    GMPLS terms (more general than just ASON as in lexi draft), then
    they are welcome to do it.

Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi)
LSP Stitching (Arthi)
- Need feedback on several items.
* Adrian - it would be inappropriate to move extensions to be a WG
  draft without first stitching draft becoming a wg draft. If no one
  objects, see no reason why not to be WG draft.
* Dimitri - Question: the draft was to originally do signaling exts,
  do we need to do more on routing aspects?
  - Arthi - agree, however this comment would have applied to the
    previous merged draft. The whole point of splitting the ID was
    because the scope was wider and generic. In that case, it becomes
    necessary to include the routing aspects as well.
* Dimitri - if allow stitching of end-to-end LSP with LSP segment
  through different switching caps, then this changes the LSP switching
  type along the path and thus this becomes a FA
  - Arthi - but end-to-end does not change.
* Zafar - we need to be careful what advertising because of scalability
  concerns, need further consideration.
  - Kireeti - As Arthi said the LSP segment does not *have to* be
    advertised but *can be* if desired.
  - Arthi - You, of course, need to be careful about advertising
    anything as TE-links dictated by correct policies. And as far as
    scaling is concerned, Igor is standing right behind you and will
    probably say (and I agree) that LSP segments can also be bundled
    in which case you are no longer advertising each LSP segment as a
    TE-link. We are simply having the same discussion again that was on
    the mailing list.
* Igor - thought stitching maybe more appropriate for LSP hierarchy
  draft, but as this already in editor's queue, will add here.
* Lou - sw cap can change hop by hop just needs to match end to end of
  hop.
  - Arthi - agree, we were thinking the same.
* Discussion sent to mailing list

Per-domain path computation method for computing inter-domain traffic
engineering (TE) LSP. (JP)
Draft-vasseur-ccamp-inter-domain-path-comp-00.txt:
routing and path computation aspects.
* Zafar asked clarification on ccamp-pce relationship
  - Kireeti - this draft discusses ASBR on the path, if not then it's
    PCE, suggest add this to draft to clarify that this is for when
    computation is done by elements on the path.
  - JP - ok
* Adrian and Kireeti asked if this should be a WG draft? Good consensus
  in the room to be WG draft, will take it to the list.

Automesh (JP)
- Agreement to rehash work a bit to put these together.
- Now 2 drafts
- Not a new ID, no changes.
- Deployed networks using that.
- No major changes planned
* Igor - asked how to reflect constraints in a node for switching?
  - JP - we are discussing auto mesh, not node switching.
  - Igor - but how do we reflect node capabilities?
  - JP - this draft is not about node capability discovery (for this,
    see draft-vasseur-ccamp-te-node-cap)
  - Igor - how to reflect for computation any internal constraints,
    could do via node caps advertisement.
  - JP agrees, though here just doing a discovery, doesn't think
    related as discovering members of mesh.
  - Adrian - two drafts, this is not node capability that is next one
    by JP, cut discussion said to take it to list.

Routing extensions for discovery of TE node capabilities (JL Le Roux)
* Adrian - on process, authors did a group job of splitting draft
  and sending to OSPF and ISIS groups, chairs will follow up with
  those groups.
* Dimitri - should for terminology call TE router?
  - JL - yes.
  - Dimitri - should the TLV be exclusive to this function?
  - JL - yes.
* Igor - how to distinguish node capabilities?
  - Adrian - do by TLVs, need to do a draft to propose, this draft
    gives you the TLVs, then can follow-up with other drafts to
    describe function want to use it for, take discussion to list.
* JL asked that this be adopted as a WG document.
  - Adrian - Take it to the list

Extensions to GMPLS RSVP graceful restart (Lou Berger)
* Adrian - do editorial respin, let us know, and we will take to
  last call
* Any implementations?
  - Yes - two!

MRN
Requirements (Kohei Shiomoto)
Evaluation draft (JL Le Roux)
Protocol extensions (Dimitri)
* Arthi - what does virtual FA have to do with MRN,
  isn't it general?
  - Dimitri - should we have a specific doc on virtual FA for
    wider scope?
  - Arthi - did you want to scope only to MRN context?
  - Dimitri - no, just not sure if soln doc should be split.
  - Arthi - could be general - so prefer a separate doc on virtual FA.
* Zafar - we need to give a priority capability for TE.
  - Dimitri - new TLV may be needed to describe relationships of
    multiple interfaces
* Zafar - how relates to hierarchy draft?
  - Dimitri - maybe should be as applicability statement,
  - Kireeti - should do on mailing list
* Kireeti - requests to continue work, when re-charter will consider
  for WG drafts.

Routing considerations and CSPF for inter-as (Tomohiro Otani)
* JP - very useful draft. Concerned about the advertisement of DYNAMIC
  summarized TE resource information across domains (static
  capabilities are perfectly fine). Too much of aggregation renders
  the solution inefficient and not enough of aggregation seriously
  compromises the routing scalability. Furthermore, there are other
  confidentiality issues to sort out in the context of inter-provider.
  - Otani - ok, we need more on summarizing capability.
* Kireeti - thinks good and hopes to be a WG draft, though for now
  would request for this draft to continue work, though lets finish
  what ccamp has now and then when re-charter will make this as a
  WG doc.
* Otani - how to handle inter-as cspf constraints?
  - Kireeti - as noted before (continue work).

L2LSP (Dimitri)
* Adrian asked clarification, is this "single hop"?
  - Dimitri - multiple hops each is a LSR, will clarify this in draft
* Kireeti - ADs request a framework doc and include how it relates to
  other SDOs, max 10 pages
  - Dimitri - ok

GMPLS addressing (Richard Rabbat)
* Adrian - as this is first version, recommend continue discussion,
  re-spin draft, and then review again.
* Adrian asked for feedback on the topics, not the technical content
  initially.
* Loa - BCP is a specific type of RFC, describes what we have
  experience with not necessarily what should be (as in this draft)
* Kireeti - warns for everyone with implementations to review the
  draft to ensure direction taken by this draft is right one.
* Lou - should we wait for re-spin or now?
  - Kireeti - wait for re-spin.

L1VPN (Tomonori Takeda)
Framework draft
Applicability draft
* Alex - by next IETF will decide if it should be included in ccamp or
  as separate WG.

Control plane saturation (JL Le Roux)
* Arthi - Do you think the LSRs would really want to advertise such
  control plane limitations ? Secondly, what implication does this have
  in case of inter-domain, especially inter-provider LSPs ?
* Kireeti - because of time, lets do on list.

Graceful shutdown (Zafar Ali)
* Kireeti - will consider for wg doc after re-charter
* JP - is this part of current charter
  - Kireeti - doesn't matter, we just can not include anymore as WG
    doc until re-charter.

Deployment-augmented (Zafar Ali)
* Arthi - This is good work. My only concern is the use of terminology.
  Do you actually expect to use LSP-Hierarchy extensions (say Hop3)
  while signaling an MPLS LSP over that FA in the MPLS domain ?
  - Zafar - no just TE link

GMPLS interworking (Kenji)
* Dimitri - why need to adv priority of LSP?
  - Adrian - need to ask on list.

GMPLS interworking (Kohei Shiomoto)
* Adrian - WG doc will be decided after re-charter
  - Welcome that will merge with other draft on augmented,
  - Suggest also look at Kenji's interworking draft to merge.

Cho - ARP signal
* Kireeti - request work with Dimitri on framework draft,
  - When decide direction and interactions with other SDO, may
    decide to form a design team to work on L2,
  - First we need a framework.



Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 09:36:46 +0000
Date: Wed, 23 Mar 2005 18:36:21 +0900
From: Kenji Kumaki <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Subject: Re: WG drafts - My correction
Cc: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

> 
> Question: With the addition of this sentence, are we content to accept
> this draft as a WG draft?
> 

Yes.

Thanks,
Kenji

> Thanks,
> Adrian
> 

-- 
Kenji Kumaki <[e-mail]>





Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 09:28:11 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : WG drafts - My correction
Date: Wed, 23 Mar 2005 10:26:10 +0100
Message-ID: <[e-mail]>
Thread-Topic: WG drafts - My correction
Thread-Index: AcUvPvt+pKkACTm3QGmj+hNaAyrvMAASzGDQ
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>

>Question: With the addition of this sentence, are we content=20
>to accept this draft as a WG draft?

yes

JL

>-----Message d'origine-----
>De : [e-mail]=20
>[mailto:[e-mail]] De la part de Adrian Farrel
>Envoy=E9 : mercredi 23 mars 2005 01:17
>=C0 : [e-mail]
>Objet : WG drafts - My correction
>
>
>Thanks to those of you who pointed out my mistake on and off the list.
>
>To set things straight...
>
>1. We have already accepted=20
>draft-ayyangar-ccamp-inter-domain-rsvp-te as a WG draft and it=20
>has been published as draft-ietf-ccamp-inter-domain-rsvp-te
>
>2. I have seen consensus for=20
>draft-ayyangar-ccamp-lsp-stitching to be published as a WG=20
>draft and the authors will submit it as=20
>draft-ietf-ccamp-lsp-stitching soon
>
>3. The name of the third draft is=20
>draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the=20
>draft that we need to consider.
>
>As JP says, he plans to add the sentence "In the context of=20
>this draft, the node in charge of any ERO expansion within its=20
>domain is always along the inter-domain TE LSP path" to this draft.
>
>Question: With the addition of this sentence, are we content=20
>to accept this draft as a WG draft?
>
>Thanks,
>Adrian
>
>
>



Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 00:37:15 +0000
Message-Id: <[e-mail]>
From: "Zafar Ali" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: WG drafts - My correction
Date: Tue, 22 Mar 2005 19:36:50 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcUvPqHcj/FQyz7MQ8OO/bjV2G6CUQAAawkQ

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, March 22, 2005 7:17 PM
> To: [e-mail]
> Subject: WG drafts - My correction
> 
> Thanks to those of you who pointed out my mistake on and off the list.
> 
> To set things straight...
> 
> 1. We have already accepted 
> draft-ayyangar-ccamp-inter-domain-rsvp-te as a WG draft and 
> it has been published as draft-ietf-ccamp-inter-domain-rsvp-te
> 
> 2. I have seen consensus for 
> draft-ayyangar-ccamp-lsp-stitching to be published as a WG 
> draft and the authors will submit it as 
> draft-ietf-ccamp-lsp-stitching soon
> 
> 3. The name of the third draft is
> draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the 
> draft that we need to consider.
> 
> As JP says, he plans to add the sentence "In the context of 
> this draft, the node in charge of any ERO expansion within 
> its domain is always along the inter-domain TE LSP path" to 
> this draft.
> 
> Question: With the addition of this sentence, are we content 
> to accept this draft as a WG draft?

Yes, 

Thanks

Regards... Zafar 

> 
> Thanks,
> Adrian
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 23 Mar 2005 00:23:22 +0000
Message-ID: <0c8a01c52f3e$7f9de820$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: WG drafts - My correction
Date: Wed, 23 Mar 2005 00:16:55 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks to those of you who pointed out my mistake on and off the list.

To set things straight...

1. We have already accepted draft-ayyangar-ccamp-inter-domain-rsvp-te as a
WG draft and it has been published as
draft-ietf-ccamp-inter-domain-rsvp-te

2. I have seen consensus for draft-ayyangar-ccamp-lsp-stitching to be
published as a WG draft and the authors will submit it as
draft-ietf-ccamp-lsp-stitching soon

3. The name of the third draft is
draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the draft that we
need to consider.

As JP says, he plans to add the sentence "In the context of this draft,
the node in charge of any ERO expansion within its domain is always along
the inter-domain TE LSP path" to this draft.

Question: With the addition of this sentence, are we content to accept
this draft as a WG draft?

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 22 Mar 2005 18:26:44 +0000
Date: Tue, 22 Mar 2005 10:26:13 -0800 (PST)
From: Rahul Aggarwal <[e-mail]>
To: mohanss <[e-mail]>
cc: [e-mail]
Subject: Re: Doubts on draft-ietf-mpls-rsvp-te-p2mp-01
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Mohan,

On Tue, 22 Mar 2005, mohanss wrote:

> Hi all,
>
> I have few doubts regarding the following drafts.
>
> Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt
> 1) In this draft what is the role of sub-group ID. What will be the
> value of this? I mean IP address or some other number? If it is IP
> address which one?
>

The sub-group ID is intended to distinguish different Path Messages tha
are signaling sub-LSPs for the same P2MP LSP. Its value is chosen by the
originator of the PathMessage and doesn't have to be an IP address.

> 2) Any vendor is already supporting this feature?
> Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors?
>

I will respond offline to this.

rahul

> 3) Which one of the following is best suitable for CSPF in P2MP?
> Core Based Trees, Reverse Path Forwarding and Spanning trees?
>


> If available, please send the links for the same.
>
> Thanks and Regards,
> -Mohan
>
>
>
>
>
>
>
>



Envelope-to: [e-mail]
Delivery-date: Tue, 22 Mar 2005 18:23:54 +0000
Message-ID: <09b201c52f0c$3d1d4a90$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Doubts on draft-ietf-mpls-rsvp-te-p2mp-01
Date: Tue, 22 Mar 2005 18:23:16 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Mohan,

The correct place for your question is really the MPLS mailing list (see
http://www.ietf.org/html.charters/mpls-charter.html)

Brief answers to your questions below.

> Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt

> 1) In this draft what is the role of sub-group ID. What will be the
> value of this? I mean IP address or some other number? If it is IP
> address which one?

The sub-group ID allows you to distinguish different sub-trees of the same
P2MP tree. this allows the signaling state to be separated and managed
distinctly (for example, using separate Path messages). The ability to
provide such a distinction is important when more than one Path message
for the same P2MP LSP might be received by the same LSR.

For more details, see the section 3.3 of the draft.

Sub-Group Originator ID should be set to the TE Router ID of the transit
LSR.
Sub-Group ID should be chosen as unique within the context of the
Sub-Group Originator ID.

> 2) Any vendor is already supporting this feature?
> Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors?

I am aware of three vendors with "early" implementations of this draft. I
must let them come forward and announce their own names.

> 3) Which one of the following is best suitable for CSPF in P2MP?
> Core Based Trees, Reverse Path Forwarding and Spanning trees?

There are many choices.
Since this is traffic engineering, all algorithms are acceptable, and
vendors might expect to make significant marketing through their
implementation of path computation.

Regards,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 22 Mar 2005 07:06:24 +0000
Date: Tue, 22 Mar 2005 12:29:43 +0530
From: mohanss <[e-mail]>
Subject: Doubts on draft-ietf-mpls-rsvp-te-p2mp-01
To: [e-mail]
Reply-to: [e-mail]
Message-id: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAKpqEfWbFb02tkV1Hmkg2asKAAAAQAAAAB0ACFPtIWkGhm6bCb/[e-mail]>
Organization: huawei technlogies
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ)"

This is a multi-part message in MIME format.

--Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

Hi all, 

I have few doubts regarding the following drafts.

Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt
1) In this draft what is the role of sub-group ID. What will be the
value of this? I mean IP address or some other number? If it is IP
address which one?

2) Any vendor is already supporting this feature? 
Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors?

3) Which one of the following is best suitable for CSPF in P2MP?
Core Based Trees, Reverse Path Forwarding and Spanning trees?

If available, please send the links for the same.

Thanks and Regards, 
-Mohan








--Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.4630.0">
<TITLE>Doubts on draft-ietf-mpls-rsvp-te-p2mp-01</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=2 FACE="Verdana">Hi all, </FONT>
</P>

<P><FONT SIZE=2 FACE="Verdana">I have few doubts regarding the following drafts.</FONT>
</P>

<P><FONT SIZE=2 FACE="Verdana">Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt</FONT>

<BR><FONT SIZE=2 FACE="Verdana">1) In this draft what is the role of sub-group ID. What will be the value of this? I mean IP address or some other number? If it is IP address which one?</FONT></P>

<P><FONT SIZE=2 FACE="Verdana">2) Any vendor is already supporting this feature? </FONT>

<BR><FONT SIZE=2 FACE="Verdana">Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors?</FONT>
</P>

<P><FONT SIZE=2 FACE="Verdana">3) Which one of the following is best suitable for CSPF in P2MP?</FONT>

<BR><FONT SIZE=2 FACE="Verdana">Core Based Trees, Reverse Path Forwarding and Spanning trees?</FONT>
</P>

<P><FONT SIZE=2 FACE="Verdana">If available, please send the links for the same.</FONT>
</P>

<P><FONT SIZE=2 FACE="Verdana">Thanks and Regards, </FONT>

<BR><FONT SIZE=2 FACE="Verdana">-Mohan</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>

--Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ)--



Envelope-to: [e-mail]
Delivery-date: Mon, 21 Mar 2005 23:01:05 +0000
Message-ID: <08f801c52e69$c9cd0eb0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt
Date: Mon, 21 Mar 2005 21:32:27 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_088E_01C52E5D.7A7129C0"

This is a multi-part message in MIME format.

------=_NextPart_000_088E_01C52E5D.7A7129C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Richard and Michelle,
=20
Thank you for submitting your Patent Disclosure=20
(http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reop=
t-00.txt)=20
with respect to IETF Internet Draft =
draft-ietf-ccamp-loose-path-reopt-00.txt.
=20
 I would be grateful if you could clarify two points to help me =
understand this discolsure further.

1. The disclosure states that:
     Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus and
     method of maintaining timely topology data within a link state =
routing
     network" may contain claims that may be necessary for practicing a
     resulting IETF Standard based on this Internet Draft.
  Could you provide more detail about what aspects of
  draft-ietf-ccamp-loose-path-reopt-00.txt you believe may be impacted =
by
  this disclosure?
=20
 2. Can you clarify whether the "fair, reasonable, reciprocal, and
   non-discriminatory terms" referenced in the disclosure include the
   intention, in the event that the referenced draft becomes an Internet
   Standard, not to assert the patent except that some party asserts a =
patent
   patent it owns or controls against Nortel?
   By way of an example of wording that covers this intention, can I =
draw
   your attention to a completely unrelated IPR disclosure at
   http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt
=20
Thank you for any clarification you are able to offer.

Please note that I am copying this email to Kireeti Kompella who =
co-chairs the IETF's CCAMP working group with me. The CCAMP working =
group developed the Internet-Draft in question =
(draft-ietf-ccamp-loose-path-reopt-00.txt) and so I am also copying this =
email to the CCAMP mailing list.

Best regards,
Adrian Farrel
--
Adrian Farrel
Old Dog Consulting
Phone: [phone]
Fax: [phone]
[e-mail]


------=_NextPart_000_088E_01C52E5D.7A7129C0
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>Dear Richard and =
Michelle,<BR>&nbsp;<BR>Thank you=20
for submitting your Patent Disclosure </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>(</FONT><A=20
href=3D"http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-pa=
th-reopt-00.txt"><FONT=20
face=3DCourier=20
size=3D2>http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-p=
ath-reopt-00.txt</FONT></A><FONT=20
face=3DCourier size=3D2>) </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>with respect to IETF Internet Draft=20
draft-ietf-ccamp-loose-path-reopt-00.txt.<BR>&nbsp;<BR> I would be =
grateful if=20
you could clarify two points to help me understand&nbsp;this discolsure=20
further.<BR><BR>1. The disclosure states =
that:<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus=20
and<BR></FONT><FONT face=3DCourier size=3D2>&nbsp;&nbsp; =
&nbsp;&nbsp;method of=20
maintaining timely topology data within a link state=20
routing<BR>&nbsp;&nbsp;&nbsp; &nbsp;network" may contain claims that may =
be=20
necessary for practicing a<BR>&nbsp;&nbsp;&nbsp;&nbsp; resulting IETF =
Standard=20
based on this Internet Draft.<BR>&nbsp; Could you provide more detail =
about what=20
aspects of<BR>&nbsp; draft-ietf-ccamp-loose-path-reopt-00.txt you =
believe may be=20
impacted by<BR>&nbsp;&nbsp;this disclosure?<BR>&nbsp;<BR> 2. Can you =
clarify=20
whether the "fair, reasonable, reciprocal, and<BR>&nbsp;=20
&nbsp;non-discriminatory terms" referenced in the disclosure include=20
the<BR>&nbsp;&nbsp; intention, in the event that the referenced draft =
becomes an=20
Internet<BR>&nbsp; &nbsp;Standard, not to assert the patent except that =
some=20
party asserts a patent<BR>&nbsp;&nbsp; patent it owns or controls =
against=20
Nortel?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;By way of an =
example=20
of&nbsp;wording that covers this intention, can I draw</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; your attention to a =
completely=20
unrelated IPR disclosure at<BR>&nbsp;&nbsp;&nbsp;</FONT><A=20
href=3D"http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.=
txt"><FONT=20
face=3DCourier=20
size=3D2>http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure=
.txt</FONT></A><BR><FONT=20
face=3DCourier size=3D2>&nbsp;<BR>Thank you for any clarification you =
are able to=20
offer.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Please note that I am copying this =
email to=20
Kireeti Kompella who co-chairs the IETF's CCAMP working group with me. =
The CCAMP=20
working group developed the Internet-Draft in question=20
(draft-ietf-ccamp-loose-path-reopt-00.txt) and so I am also copying this =
email=20
to the CCAMP mailing list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Best regards,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian Farrel</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>--<BR>Adrian Farrel<BR>Old Dog=20
Consulting<BR>Phone: [phone]<BR>Fax: +44 (0) =
870-130-5411<BR><A=20
href=3D"mailto:[e-mail]">[e-mail]</A></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_088E_01C52E5D.7A7129C0--




Envelope-to: [e-mail]
Delivery-date: Mon, 21 Mar 2005 20:31:22 +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-rsvp-restart-ext-02.txt
Date: Mon, 21 Mar 2005 15:29:50 -0500

--NextPart

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

	Title		: Extensions to GMPLS RSVP Graceful Restart
	Author(s)	: A. Satyanarayana, R. Rahman
	Filename	: draft-ietf-ccamp-rsvp-restart-ext-02.txt
	Pages		: 20
	Date		: 2005-3-21
	
This document describes extensions to the RSVP Graceful Restart
   mechanisms defined in [RFC3473].  The extensions enable the recovery
   of RSVP signaling state based on the Path message last sent by the
   node being restarted.  Previously defined Graceful Restart
   mechanisms, also called recovery from nodal faults, permit recovery
   of signaling state from adjacent nodes when the data plane has
   retained the associated forwarding state across a restart.  These
   mechanisms do not fully support signaling state recovery on ingress
   nodes or recovery of all RSVP objects.  The presented extensions use
   the RSVP Hello extensions defined in [RFC3209], and extensions for
   state recovery on nodal faults defined in [RFC3473].  With the
   presented extensions the restarting node can recover all previously
   transmitted Path state including the ERO and the downstream
   (outgoing) interface identifiers.  The extensions can also be used to
   recover signaling state after the restart of an ingress node.  The
   extensions optionally support the use of Summary Refresh, defined in
   [RFC2961], to reduce the number of messages exchanged during the
   Recovery Phase when the restarting node has recovered signaling state
   locally for one or more LSP's.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-02.txt

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-02.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Mon, 21 Mar 2005 13:10:54 +0000
Mime-Version: 1.0 (Apple Message framework v619.2)
To: [e-mail]
Message-Id: <[e-mail]>
Content-Type: multipart/alternative; boundary=Apple-Mail-25--40678782
From: JP Vasseur <[e-mail]>
Subject: Fwd: Opinion on two new WG drafts (CORRECTION)
Date: Mon, 21 Mar 2005 08:08:27 -0500

--Apple-Mail-25--40678782
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

I just had a brief discussion with Adrian. As requested per Kireeti I 
will add the following sentence to 
draft-vasseur-ccamp-inter-domain-pd-path-comp: "In the context of this 
draft, the node in charge of any ERO expansion within its domain is 
always along the inter-domain TE LSP path". Then the question for the 
WG should read:

Is the WG in favor of adopting 
draft-vasseur-ccamp-inter-domain-pd-path-comp as a WG document (yes/no) 
?

thanks.

JP.

Begin forwarded message:

> From: "Adrian Farrel" <[e-mail]>
> Date: March 18, 2005 3:04:51 PM EST
> To: <[e-mail]>
> Subject: Opinion on two new WG drafts
> Reply-To: "Adrian Farrel" <[e-mail]>
>
> Our charter encourages us to work on inter-domain solutions.
> There are two drafts which we should consider as working group drafts:
> - draft-vasseur-ccamp-inter-domain-path-comp-00.txt
> - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt
>
> In Minneapolis the room seemed to be in favor with two caveats:
> - draft-vasseur-ccamp-inter-domain-path-comp must include a
>   statement clarifying that in the context of this draft, the node in
>   charge of any ERO expansion within its domain is always along
>   the inter-domain TE LSP path
> - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait
>    for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a
>    CCAMP draft
>
> Assuming these requirements to be fulfilled, please say whether you
> support these drafts becoming CCAMP drafts. A simple yes/no is enough, 
> but
> reasons against are useful.
>
> Thanks,
> Adrian
>

--Apple-Mail-25--40678782
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

I just had a brief discussion with Adrian. As requested per Kireeti I
will add the following sentence to
draft-vasseur-ccamp-inter-domain-pd-path-comp: "In the context of this
draft, the node in charge of any ERO expansion within its domain is
always along the inter-domain TE LSP path". Then the question for the
WG should read:


Is the WG in favor of adopting
draft-vasseur-ccamp-inter-domain-pd-path-comp as a WG document
(yes/no) ?


thanks.


JP.


Begin forwarded message:


<excerpt><bold><fontfamily><param>Helvetica</param><color><param>0000,0000,0000</param>From:
</color></fontfamily></bold><fontfamily><param>Helvetica</param>"Adrian
Farrel" <<[e-mail]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>March
18, 2005 3:04:51 PM EST

<bold><color><param>0000,0000,0000</param>To:
</color></bold><<[e-mail]>

<bold><color><param>0000,0000,0000</param>Subject: </color>Opinion on
two new WG drafts

<color><param>0000,0000,0000</param>Reply-To: </color></bold>"Adrian
Farrel" <<[e-mail]>

</fontfamily>

Our charter encourages us to work on inter-domain solutions.

There are two drafts which we should consider as working group drafts:

- draft-vasseur-ccamp-inter-domain-path-comp-00.txt

- draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt


In Minneapolis the room seemed to be in favor with two caveats:

- draft-vasseur-ccamp-inter-domain-path-comp must include a

  statement clarifying that in the context of this draft, the node in

  charge of any ERO expansion within its domain is always along

  the inter-domain TE LSP path

- draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait

   for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a

   CCAMP draft


Assuming these requirements to be fulfilled, please say whether you

support these drafts becoming CCAMP drafts. A simple yes/no is enough,
but

reasons against are useful.


Thanks,

Adrian


</excerpt>
--Apple-Mail-25--40678782--



Envelope-to: [e-mail]
Delivery-date: Sat, 19 Mar 2005 16:38:59 +0000
Message-ID: <[e-mail]>
Date: Sat, 19 Mar 2005 17:36:54 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: Opinion on two new WG drafts
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

adrian, just to be sure the first reference is not available, so be sure 
that we are discussing the correct document do you refer to

<http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-inter-domain-pd-path-comp-00.txt>

now the second document appears to me to be already a working group 
document - so would you clarify the below question ?

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-00.txt>

i have already send a bunch of comment on this document (from its non-WG 
version so expect to see some discussion on the next version), an 
additional remark would be that the sentence "There are three ways in 
which an RSVP-TE LSP could be signaled across multiple domains:" is not 
precise enough to translate the fact there are two ways (and not three) 
one that does use a unique end-to-end RSVP session (contiguous) and 
another that allows usage of intermediate RSVP session(s) used to 
establish the end-to-end session; currently there are three (and not 
two) methods that can be used for the second way: stitching (the 
head-end intermediate node performs selection of the segment), splicing 
(the LSP head-end node performs selection of the segment, using explicit 
label control), and nesting

note: the second method is detailed in RFC 3471, section 6,

thanks,
- dimitri.

Adrian Farrel wrote:

> Our charter encourages us to work on inter-domain solutions.
> There are two drafts which we should consider as working group drafts:
> - draft-vasseur-ccamp-inter-domain-path-comp-00.txt
> - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt
> 
> In Minneapolis the room seemed to be in favor with two caveats:
> - draft-vasseur-ccamp-inter-domain-path-comp must include a
>   statement clarifying that in the context of this draft, the node in
>   charge of any ERO expansion within its domain is always along
>   the inter-domain TE LSP path
> - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait
>    for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a
>    CCAMP draft
> 
> Assuming these requirements to be fulfilled, please say whether you
> support these drafts becoming CCAMP drafts. A simple yes/no is enough, but
> reasons against are useful.
> 
> Thanks,
> Adrian
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 20:35:20 +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-ason-lexicography-00.txt
Date: Fri, 18 Mar 2005 15:34:21 -0500

--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-00.txt
	Pages		: 12
	Date		: 2005-3-18
	
Generalized Multiprotocol Label Switching (GMPLS) has been developed
   by the IETF to facilitate the establishment of Label Switched Paths
   (LSPs) in a variety of physical technologies and across several
   architectural models. The ITU-T has specified an architecture for
   the management of Automatically Switched Optical Networks (ASON).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-00.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-00.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-00.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-00.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 20:26:08 +0000
Message-ID: <065701c52bf8$31885830$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Opinion on two new WG drafts
Date: Fri, 18 Mar 2005 20:04:51 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Our charter encourages us to work on inter-domain solutions.
There are two drafts which we should consider as working group drafts:
- draft-vasseur-ccamp-inter-domain-path-comp-00.txt
- draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt

In Minneapolis the room seemed to be in favor with two caveats:
- draft-vasseur-ccamp-inter-domain-path-comp must include a
  statement clarifying that in the context of this draft, the node in
  charge of any ERO expansion within its domain is always along
  the inter-domain TE LSP path
- draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait
   for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a
   CCAMP draft

Assuming these requirements to be fulfilled, please say whether you
support these drafts becoming CCAMP drafts. A simple yes/no is enough, but
reasons against are useful.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 20:26:00 +0000
Message-ID: <065401c52bf8$2cbd3b90$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Arthi Ayyangar" <[e-mail]>
Subject: Stitching draft to WG status
Date: Fri, 18 Mar 2005 19:56:36 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We discussed making  draft-ayyangar-ccamp-lsp-stitching-00.txt a CCAMP
draft before Minneapolis.
I judge that the consensus was that this should now be a WG draft.

Arthi, please republish as draft-ietf-ccamp-lsp-stitching-00.txt with no
other changes (except boilerplate as needed).

We can then discuss the draft within the WG and move it forward rapidly.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 19:43:50 +0000
Message-ID: <017601c52be9$eef2efc0$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: Yet more on drraft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Fri, 18 Mar 2005 19:38:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Digging deeper (sorry, I should done this before sending any e-mail:-(

RFC 3471 says in IANA considerations
"This document defines the following namespaces:

      o LSP Encoding Type: 8 bits
      o Switching Type: 8 bits
      o Generalized PID (G-PID): 16 bits

   All future assignments should be allocated through IETF Consensus
   action or documented in a Specification.

  LSP Encoding Type - valid value range is 1-255.  This document
   defines values 1-11.

   Switching Type - valid value range is 1-255.  This document defines
   values 1-4, 100, 150 and 200.

   Generalized PID (G-PID) - valid value range is 0-1500.  This document
   defines values 0-46."

fine no problem

Switching type

draft-ietf-ccamp-ospf-gmpls-extensions-12.txt adds
         51    Layer-2 Switch Capable  (L2SC)
 but makes no mention of that in IANA considerations; should it?

The MIB text cites as reference draft-ietf-ccamp-gmpls-routing-09.txt which has
no IANA considerations and I cannot see adding a value; should this be
OSPF-gmpls-extensions?

And draft-ietf-ccamp-gmpls-g709-09.txt says

 "Switching Type:
        Assigned by IANA via IETF Standards Track RFC  Action. "

ie this is now more restrictive than RFC 3471; is this really intended?


LSP encoding type

The MIB cites
draft-ietf-ccamp-gmpls-g709-06.txt,
This should be -09 which says

   - LSP Encoding Type:
        12              defined in Section 3.1.1
        13              defined in Section 3.1.1
     Allocation Policy:
        [0..239]        Assigned by IANA via IETF Standards Track RFC Action.

ie this is now more restrictive than RFC3471; was this intended?


Generalized PID

Same story, MIB cites draft-ietf-ccamp-gmpls-g709-06.txt, which should be -09,
does add values but again is more restrictive about how the values can be
updated.

Standing back, there are these three enumerations, they will be added to over
the years, what is the right policy for updating them? Standards track, expert
review, IETF consensus?

How best to keep the MIBS in line with the I-Ds at least at initial publication,
which is the authoritative document?(define it all in the MIB:-)

Are there any more in other documents, perhaps for which no MIB yet exists? (RFC
3471 does list five sets of numbers - I have only looked at these three - and
there an awfully large number of GMPLS documents most of which I have not looked
at)





Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 17:54:54 +0000
Message-ID: <05b001c52be1$8ebd3e10$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>
Subject: Discussion about IPR claim in draft-ietf-ccamp-loose-path-reopt
Date: Fri, 18 Mar 2005 17:18:29 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

As mentioned in Minneapolis, draft-ietf-ccamp-loose-path-reopt is the
subject of an IPR disclosure
http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reopt-00.txt

The working group must decide whether we wish to pursue this I-D in the
face of this IPR disclosure. Clearly it is a significant step to create an
RFC that might require implementers to license technology.

I would welcome opinions on this subject.

In the mean time I will work with Scott Bradner to see if we can get any
additional information or clarification about this disclosure.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 17:54:46 +0000
Message-ID: <05b401c52be1$93bf4930$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Tom Petch" <[e-mail]>, <[e-mail]>
Subject: Re: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Fri, 18 Mar 2005 17:38:13 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Tom,

Good advice.

We'll look at how to do this.

Adrian
----- Original Message ----- 
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Friday, March 18, 2005 8:29 AM
Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt


> This MIB contains several 'enumerations' except they are not
enumerations but
> text in
> DESCRIPTION clauses  -  gmplsTunnelGPid gmplsTunnelSwitchingType
> gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference.  So
these are
> not defined anywhere in SMI; and as this points out, these values will
be added
> to in future RFC.
>
> I think these should be in a MIB under IANA control and there is already
a way
> to do just that, namely to put them in an IANA MIB (as opposed to a
standards
> track MIB) with the RFC specifying under what conditions the IANA MIB
can be
> updated (standards track, IESG, expert etc).
>
> This procedure is described in
draft-ietf-ops-mib-review-guidelines-04.txt which
> also points to previous examples of this.  And this issue has already
surfaced,
> albeit obliquely, on this list once before in the context of
> IANAItuProbableCause which uses this procedure and is now published as
part of
> the Alarm MIB (RFC 3877).
>
> Not to do this now creates extra work in the future; when an implementor
has to
> create their own SMI and whenever these values need to be updated.
>
> Tom Petch
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 14:21:55 +0000
Message-ID: <[e-mail]>
Date: Fri, 18 Mar 2005 15:21:30 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: Updated minutes
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian

a brief comment to clarify

< "* Dimitri - if allow different switching caps, then this changes the
<  type, and this a FA"

 > * Dimitri - if allow stitching of end-to-end LSP with LSP segment
 > through different switching caps, then this changes the LSP switching
 > type along the path and thus this becomes a FA

thanks,
- dimitri.

Adrian Farrel wrote:
> Here with updates from Jean-Louis, JP and Arthi.
> 
> Short call for further comments before I submit.
> 
> Thanks,
> Adrian
> 
> ===
> 
> Common Control and Measurement Plane WG (ccamp)
> 
> Tuesday, March 8, 2005 at 0900-1130
> Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen
> 
> Working group status - chairs
> - No changes to the agenda made.
> - Adrian reviewed status of drafts, reviewed charter milestones.
>   We are holding off on new charter until finish last call of 8
>   drafts, expect 1-2 months.
> - Bill summarized ADs view, should wait for re-chartering until
>   finish last call considering expectation will be very soon for
>   last calls.
> * Dimitri asked about IPR assertion on re-optimization draft
>   - Adrian said it did not give the same terms that have been seen
>     in some recent IPR claims. The WG has to desice what to do.
>   - Scott Bradner said we need to be very careful.  Advised there
>     may be anti-trust issues. Best to have no IETF interaction
>     other than to ask for clarity.
>     Scott offered to review emails on the subject.
>   - JP said we can take that as a way to go forward and continue
>     technical work.
> 
> ASON considerations
> 
> ITU liaison - Lyndon Ong presented Wesam's slides
> - Thanks to the IETF for liaisons and participation of Adrian and
>   Igor at last meetings
> - Crankback and the comparison of LMP and ASON discovery will be
>   incorporated in SG15 Q14's work.
> - There are two liaisons from ITU to CCAMP on the way.
> - Routing - ITU not planning any routing exts work, looking to
>   IETF's work.
> - Continuing work on ASON management.
> - An FTP site is available for liaison statements.
> * Adrian asked if ITU plans to liaise G.7713 on new text for
>   crankback before consent?
>   - Lyndon said a meeting is upcoming and will ask for it to be
>     considered.
> * Kireeti asked if there is any problem in that the crankback draft
>   is not an RFC yet?
>   - Adrian - RFC is desirable, not required?
>   - Scott Bradner - it is required to have an RFC number for final
>     balloting. The IESG can request expedited publication.
> * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU
>   terminology, and may want to consider including it.
>   - Adrian - can that be liaisoned to us?
>   - Steve Trowbridge - Yes, we can do that.
> 
> ASON Routing Evaluation
> * Adrian - The design team on routing has members from both ITU and
>   IETF, although we did not do the correct process, so ITU reps are
>   individuals, not ITU representatives.
>   - Adrian will work with Steve to formalize the process.
> * Adrian - Would like to make the draft from the team on evaluation
>   of routing protocols into a working group draft
>   - we will take to the list to see if any objection.
> * Dimitri - asked if we can use formal liaison process to send this
>   draft to ITU, does it need to be WG draft? And encourages comments
>   now, before it goes to last call.
>   - Adrian - we can liaise the draft and our intention to consider it
>     as a WG draft
> 
> Lexicography draft (Adrian)
> - Q14 indicates meeting went well, authors summarized comments and
>   incorporated in this release.
> * Adrian asked if should be WG draft
>   - Kireeti said we could do that, need to ask the list, also need to
>     compare with G.8081
> * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC
>   or drafts, are there definitions?
>   - Adrian thinks there are good terms, though in multiple
>     RFCs/drafts.
>   - Ben - if someone is new to the IETF, they have difficulty on
>     where to go for definitions.
>   - Adrian - if people want to do a draft to collect defintions of all
>     GMPLS terms (more general than just ASON as in lexi draft), then
>     they are welcome to do it.
> 
> Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi)
> LSP Stitching (Arthi)
> - Need feedback on several items.
> * Adrian - it would be inappropriate to move extensions to be a WG
>   draft without first stitching draft becoming a wg draft. If no one
>   objects, see no reason why not to be WG draft.
> * Dimitri - Question: the draft was to originally do signaling exts,
>   do we need to do more on routing aspects?
>   - Arthi - agree, however this comment would have applied to the
>     previous merged draft. The whole point of splitting the ID was
>     because the scope was wider and generic. In that case, it becomes
>     necessary to include the routing aspects as well.
> * Dimitri - if allow different switching caps, then this changes the
>   type, and this a FA
>   - Arthi - but end-to-end does not change.
> * Zafar - we need to be careful what advertising because of scalability
>   concerns, need further consideration.
>   - Kireeti - As Arthi said the LSP segment does not *have to* be
>     advertised but *can be* if desired.
>   - Arthi - You, of course, need to be careful about advertising
>     anything as TE-links dictated by correct policies. And as far as
>     scaling is concerned, Igor is standing right behind you and will
>     probably say (and I agree) that LSP segments can also be bundled
>     in which case you are no longer advertising each LSP segment as a
>     TE-link. We are simply having the same discussion again that was on
>     the mailing list.
> * Igor - thought stitching maybe more appropriate for LSP hierarchy
>   draft, but as this already in editor's queue, will add here.
> * Lou - sw cap can change hop by hop just needs to match end to end of
>   hop.
>   - Arthi - agree, we were thinking the same.
> * Discussion sent to mailing list
> 
> Per-domain path computation method for computing inter-domain traffic
> engineering (TE) LSP. (JP)
> Draft-vasseur-ccamp-inter-domain-path-comp-00.txt:
> routing and path computation aspects.
> * Zafar asked clarification on ccamp-pce relationship
>   - Kireeti - this draft discusses ASBR on the path, if not then it's
>     PCE, suggest add this to draft to clarify that this is for when
>     computation is done by elements on the path.
>   - JP - ok
> * Adrian and Kireeti asked if this should be a WG draft? Good consensus
>   in the room to be WG draft, will take it to the list.
> 
> Automesh (JP)
> - Agreement to rehash work a bit to put these together.
> - Now 2 drafts
> - Not a new ID, no changes.
> - Deployed networks using that.
> - No major changes planned
> * Igor - asked how to reflect constraints in a node for switching?
>   - JP - we are discussing auto mesh, not node switching.
>   - Igor - but how do we reflect node capabilities?
>   - JP - this draft is not about node capability discovery (for this,
>     see draft-vasseur-ccamp-te-node-cap)
>   - Igor - how to reflect for computation any internal constraints,
>     could do via node caps advertisement.
>   - JP agrees, though here just doing a discovery, doesn't think
>     related as discovering members of mesh.
>   - Adrian - two drafts, this is not node capability that is next one
>     by JP, cut discussion said to take it to list.
> 
> Routing extensions for discovery of TE node capabilities (JL Le Roux)
> * Adrian - on process, authors did a group job of splitting draft
>   and sending to OSPF and ISIS groups, chairs will follow up with
>   those groups.
> * Dimitri - should for terminology call TE router?
>   - JL - yes.
>   - Dimitri - should the TLV be exclusive to this function?
>   - JL - yes.
> * Igor - how to distinguish node capabilities?
>   - Adrian - do by TLVs, need to do a draft to propose, this draft
>     gives you the TLVs, then can follow-up with other drafts to
>     describe function want to use it for, take discussion to list.
> * JL asked that this be adopted as a WG document.
>   - Adrian - Take it to the list
> 
> Extensions to GMPLS RSVP graceful restart (Lou Berger)
> * Adrian - do editorial respin, let us know, and we will take to
>   last call
> * Any implementations?
>   - Yes - two!
> 
> MRN
> Requirements (Kohei Shiomoto)
> Evaluation draft (JL Le Roux)
> Protocol extensions (Dimitri)
> * Arthi - what does virtual FA have to do with MRN,
>   isn't it general?
>   - Dimitri - should we have a specific doc on virtual FA for
>     wider scope?
>   - Arthi - did you want to scope only to MRN context?
>   - Dimitri - no, just not sure if soln doc should be split.
>   - Arthi - could be general - so prefer a separate doc on virtual FA.
> * Zafar - we need to give a priority capability for TE.
>   - Dimitri - new TLV may be needed to describe relationships of
>     multiple interfaces
> * Zafar - how relates to hierarchy draft?
>   - Dimitri - maybe should be as applicability statement,
>   - Kireeti - should do on mailing list
> * Kireeti - requests to continue work, when re-charter will consider
>   for WG drafts.
> 
> Routing considerations and CSPF for inter-as (Tomohiro Otani)
> * JP - very useful draft. Concerned about the advertisement of DYNAMIC
>   summarized TE resource information across domains (static
>   capabilities are perfectly fine). Too much of aggregation renders
>   the solution inefficient and not enough of aggregation seriously
>   compromises the routing scalability. Furthermore, there are other
>   confidentiality issues to sort out in the context of inter-provider.
>   - Otani - ok, we need more on summarizing capability.
> * Kireeti - thinks good and hopes to be a WG draft, though for now
>   would request for this draft to continue work, though lets finish
>   what ccamp has now and then when re-charter will make this as a
>   WG doc.
> * Otani - how to handle inter-as cspf constraints?
>   - Kireeti - as noted before (continue work).
> 
> L2LSP (Dimitri)
> * Adrian asked clarification, is this "single hop"?
>   - Dimitri - multiple hops each is a LSR, will clarify this in draft
> * Kireeti - ADs request a framework doc and include how it relates to
>   other SDOs, max 10 pages
>   - Dimitri - ok
> 
> GMPLS addressing (Richard Rabbat)
> * Adrian - as this is first version, recommend continue discussion,
>   re-spin draft, and then review again.
> * Adrian asked for feedback on the topics, not the technical content
>   initially.
> * Loa - BCP is a specific type of RFC, describes what we have
>   experience with not necessarily what should be (as in this draft)
> * Kireeti - warns for everyone with implementations to review the
>   draft to ensure direction taken by this draft is right one.
> * Lou - should we wait for re-spin or now?
>   - Kireeti - wait for re-spin.
> 
> L1VPN (Tomonori Takeda)
> Framework draft
> Applicability draft
> * Alex - by next IETF will decide if it should be included in ccamp or
>   as separate WG.
> 
> Control plane saturation (JL Le Roux)
> * Arthi - Do you think the LSRs would really want to advertise such
>   control plane limitations ? Secondly, what implication does this have
>   in case of inter-domain, especially inter-provider LSPs ?
> * Kireeti - because of time, lets do on list.
> 
> Graceful shutdown (Zafar Ali)
> * Kireeti - will consider for wg doc after re-charter
> * JP - is this part of current charter
>   - Kireeti - doesn't matter, we just can not include anymore as WG
>     doc until re-charter.
> 
> Deployment-augumented (Zafar Ali)
> * Arthi - This is good work. My only concern is the use of terminology.
>   Do you actually expect to use LSP-Hierarchy extensions (say Hop3)
>   while signaling an MPLS LSP over that FA in the MPLS domain ?
>   - Zafar - no just TE link
> 
> GMPLS interworking (Kenji)
> * Dimitri - why need to adv priority of LSP?
>   - Adrian - need to ask on list.
> 
> GMPLS interworking (Kohei Shiomoto)
> * Adrian - WG doc will be decided after re-charter
>   - Welcome that will merge with other draft on augumented,
>   - Suggest also look at Kenji's interworking draft to merge.
> 
> Cho - ARP signal
> * Kireeti - request work with Dimitri on framework draft,
>   - When decide direction and interactions with other SDO, may
>     decide to form a design team to work on L2,
>   - First we need a framework.
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 13:28:14 +0000
Message-ID: <04cc01c52bbd$1dec83e0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Updated minutes
Date: Fri, 18 Mar 2005 12:34:37 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Here with updates from Jean-Louis, JP and Arthi.

Short call for further comments before I submit.

Thanks,
Adrian

===

Common Control and Measurement Plane WG (ccamp)

Tuesday, March 8, 2005 at 0900-1130
Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen

Working group status - chairs
- No changes to the agenda made.
- Adrian reviewed status of drafts, reviewed charter milestones.
  We are holding off on new charter until finish last call of 8
  drafts, expect 1-2 months.
- Bill summarized ADs view, should wait for re-chartering until
  finish last call considering expectation will be very soon for
  last calls.
* Dimitri asked about IPR assertion on re-optimization draft
  - Adrian said it did not give the same terms that have been seen
    in some recent IPR claims. The WG has to desice what to do.
  - Scott Bradner said we need to be very careful.  Advised there
    may be anti-trust issues. Best to have no IETF interaction
    other than to ask for clarity.
    Scott offered to review emails on the subject.
  - JP said we can take that as a way to go forward and continue
    technical work.

ASON considerations

ITU liaison - Lyndon Ong presented Wesam's slides
- Thanks to the IETF for liaisons and participation of Adrian and
  Igor at last meetings
- Crankback and the comparison of LMP and ASON discovery will be
  incorporated in SG15 Q14's work.
- There are two liaisons from ITU to CCAMP on the way.
- Routing - ITU not planning any routing exts work, looking to
  IETF's work.
- Continuing work on ASON management.
- An FTP site is available for liaison statements.
* Adrian asked if ITU plans to liaise G.7713 on new text for
  crankback before consent?
  - Lyndon said a meeting is upcoming and will ask for it to be
    considered.
* Kireeti asked if there is any problem in that the crankback draft
  is not an RFC yet?
  - Adrian - RFC is desirable, not required?
  - Scott Bradner - it is required to have an RFC number for final
    balloting. The IESG can request expedited publication.
* Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU
  terminology, and may want to consider including it.
  - Adrian - can that be liaisoned to us?
  - Steve Trowbridge - Yes, we can do that.

ASON Routing Evaluation
* Adrian - The design team on routing has members from both ITU and
  IETF, although we did not do the correct process, so ITU reps are
  individuals, not ITU representatives.
  - Adrian will work with Steve to formalize the process.
* Adrian - Would like to make the draft from the team on evaluation
  of routing protocols into a working group draft
  - we will take to the list to see if any objection.
* Dimitri - asked if we can use formal liaison process to send this
  draft to ITU, does it need to be WG draft? And encourages comments
  now, before it goes to last call.
  - Adrian - we can liaise the draft and our intention to consider it
    as a WG draft

Lexicography draft (Adrian)
- Q14 indicates meeting went well, authors summarized comments and
  incorporated in this release.
* Adrian asked if should be WG draft
  - Kireeti said we could do that, need to ask the list, also need to
    compare with G.8081
* Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC
  or drafts, are there definitions?
  - Adrian thinks there are good terms, though in multiple
    RFCs/drafts.
  - Ben - if someone is new to the IETF, they have difficulty on
    where to go for definitions.
  - Adrian - if people want to do a draft to collect defintions of all
    GMPLS terms (more general than just ASON as in lexi draft), then
    they are welcome to do it.

Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi)
LSP Stitching (Arthi)
- Need feedback on several items.
* Adrian - it would be inappropriate to move extensions to be a WG
  draft without first stitching draft becoming a wg draft. If no one
  objects, see no reason why not to be WG draft.
* Dimitri - Question: the draft was to originally do signaling exts,
  do we need to do more on routing aspects?
  - Arthi - agree, however this comment would have applied to the
    previous merged draft. The whole point of splitting the ID was
    because the scope was wider and generic. In that case, it becomes
    necessary to include the routing aspects as well.
* Dimitri - if allow different switching caps, then this changes the
  type, and this a FA
  - Arthi - but end-to-end does not change.
* Zafar - we need to be careful what advertising because of scalability
  concerns, need further consideration.
  - Kireeti - As Arthi said the LSP segment does not *have to* be
    advertised but *can be* if desired.
  - Arthi - You, of course, need to be careful about advertising
    anything as TE-links dictated by correct policies. And as far as
    scaling is concerned, Igor is standing right behind you and will
    probably say (and I agree) that LSP segments can also be bundled
    in which case you are no longer advertising each LSP segment as a
    TE-link. We are simply having the same discussion again that was on
    the mailing list.
* Igor - thought stitching maybe more appropriate for LSP hierarchy
  draft, but as this already in editor's queue, will add here.
* Lou - sw cap can change hop by hop just needs to match end to end of
  hop.
  - Arthi - agree, we were thinking the same.
* Discussion sent to mailing list

Per-domain path computation method for computing inter-domain traffic
engineering (TE) LSP. (JP)
Draft-vasseur-ccamp-inter-domain-path-comp-00.txt:
routing and path computation aspects.
* Zafar asked clarification on ccamp-pce relationship
  - Kireeti - this draft discusses ASBR on the path, if not then it's
    PCE, suggest add this to draft to clarify that this is for when
    computation is done by elements on the path.
  - JP - ok
* Adrian and Kireeti asked if this should be a WG draft? Good consensus
  in the room to be WG draft, will take it to the list.

Automesh (JP)
- Agreement to rehash work a bit to put these together.
- Now 2 drafts
- Not a new ID, no changes.
- Deployed networks using that.
- No major changes planned
* Igor - asked how to reflect constraints in a node for switching?
  - JP - we are discussing auto mesh, not node switching.
  - Igor - but how do we reflect node capabilities?
  - JP - this draft is not about node capability discovery (for this,
    see draft-vasseur-ccamp-te-node-cap)
  - Igor - how to reflect for computation any internal constraints,
    could do via node caps advertisement.
  - JP agrees, though here just doing a discovery, doesn't think
    related as discovering members of mesh.
  - Adrian - two drafts, this is not node capability that is next one
    by JP, cut discussion said to take it to list.

Routing extensions for discovery of TE node capabilities (JL Le Roux)
* Adrian - on process, authors did a group job of splitting draft
  and sending to OSPF and ISIS groups, chairs will follow up with
  those groups.
* Dimitri - should for terminology call TE router?
  - JL - yes.
  - Dimitri - should the TLV be exclusive to this function?
  - JL - yes.
* Igor - how to distinguish node capabilities?
  - Adrian - do by TLVs, need to do a draft to propose, this draft
    gives you the TLVs, then can follow-up with other drafts to
    describe function want to use it for, take discussion to list.
* JL asked that this be adopted as a WG document.
  - Adrian - Take it to the list

Extensions to GMPLS RSVP graceful restart (Lou Berger)
* Adrian - do editorial respin, let us know, and we will take to
  last call
* Any implementations?
  - Yes - two!

MRN
Requirements (Kohei Shiomoto)
Evaluation draft (JL Le Roux)
Protocol extensions (Dimitri)
* Arthi - what does virtual FA have to do with MRN,
  isn't it general?
  - Dimitri - should we have a specific doc on virtual FA for
    wider scope?
  - Arthi - did you want to scope only to MRN context?
  - Dimitri - no, just not sure if soln doc should be split.
  - Arthi - could be general - so prefer a separate doc on virtual FA.
* Zafar - we need to give a priority capability for TE.
  - Dimitri - new TLV may be needed to describe relationships of
    multiple interfaces
* Zafar - how relates to hierarchy draft?
  - Dimitri - maybe should be as applicability statement,
  - Kireeti - should do on mailing list
* Kireeti - requests to continue work, when re-charter will consider
  for WG drafts.

Routing considerations and CSPF for inter-as (Tomohiro Otani)
* JP - very useful draft. Concerned about the advertisement of DYNAMIC
  summarized TE resource information across domains (static
  capabilities are perfectly fine). Too much of aggregation renders
  the solution inefficient and not enough of aggregation seriously
  compromises the routing scalability. Furthermore, there are other
  confidentiality issues to sort out in the context of inter-provider.
  - Otani - ok, we need more on summarizing capability.
* Kireeti - thinks good and hopes to be a WG draft, though for now
  would request for this draft to continue work, though lets finish
  what ccamp has now and then when re-charter will make this as a
  WG doc.
* Otani - how to handle inter-as cspf constraints?
  - Kireeti - as noted before (continue work).

L2LSP (Dimitri)
* Adrian asked clarification, is this "single hop"?
  - Dimitri - multiple hops each is a LSR, will clarify this in draft
* Kireeti - ADs request a framework doc and include how it relates to
  other SDOs, max 10 pages
  - Dimitri - ok

GMPLS addressing (Richard Rabbat)
* Adrian - as this is first version, recommend continue discussion,
  re-spin draft, and then review again.
* Adrian asked for feedback on the topics, not the technical content
  initially.
* Loa - BCP is a specific type of RFC, describes what we have
  experience with not necessarily what should be (as in this draft)
* Kireeti - warns for everyone with implementations to review the
  draft to ensure direction taken by this draft is right one.
* Lou - should we wait for re-spin or now?
  - Kireeti - wait for re-spin.

L1VPN (Tomonori Takeda)
Framework draft
Applicability draft
* Alex - by next IETF will decide if it should be included in ccamp or
  as separate WG.

Control plane saturation (JL Le Roux)
* Arthi - Do you think the LSRs would really want to advertise such
  control plane limitations ? Secondly, what implication does this have
  in case of inter-domain, especially inter-provider LSPs ?
* Kireeti - because of time, lets do on list.

Graceful shutdown (Zafar Ali)
* Kireeti - will consider for wg doc after re-charter
* JP - is this part of current charter
  - Kireeti - doesn't matter, we just can not include anymore as WG
    doc until re-charter.

Deployment-augumented (Zafar Ali)
* Arthi - This is good work. My only concern is the use of terminology.
  Do you actually expect to use LSP-Hierarchy extensions (say Hop3)
  while signaling an MPLS LSP over that FA in the MPLS domain ?
  - Zafar - no just TE link

GMPLS interworking (Kenji)
* Dimitri - why need to adv priority of LSP?
  - Adrian - need to ask on list.

GMPLS interworking (Kohei Shiomoto)
* Adrian - WG doc will be decided after re-charter
  - Welcome that will merge with other draft on augumented,
  - Suggest also look at Kenji's interworking draft to merge.

Cho - ARP signal
* Kireeti - request work with Dimitri on framework draft,
  - When decide direction and interactions with other SDO, may
    decide to form a design team to work on L2,
  - First we need a framework.




Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 13:28:06 +0000
Message-ID: <04c801c52bbd$13a39c70$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: ASON Lexicography
Date: Fri, 18 Mar 2005 12:31:13 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Sounds like no-one against, but recognition that this is work in progress.

We will submit as a WG draft.
The authors are busy with a new revision.

Thanks,
Adrian

> > Dear CCAMP,
> >
> > In our meeting this week we heard about
> > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
> >
> > There is some more discussion to be done on the content of
> > this draft but the chairs and the meeting thought that the
> > work is a very important part of CCAMP's job.
> >
> > Please indicate your opinion on whether this draft should be
> > made a working draft document by March 20, 2005.
> >
> > Thanks,
> > Kireeti.




Envelope-to: [e-mail]
Delivery-date: Fri, 18 Mar 2005 09:36:32 +0000
Message-ID: <000e01c52b94$e310a440$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Fri, 18 Mar 2005 09:29:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This MIB contains several 'enumerations' except they are not enumerations but
text in
DESCRIPTION clauses  -  gmplsTunnelGPid gmplsTunnelSwitchingType
gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference.  So these are
not defined anywhere in SMI; and as this points out, these values will be added
to in future RFC.

I think these should be in a MIB under IANA control and there is already a way
to do just that, namely to put them in an IANA MIB (as opposed to a standards
track MIB) with the RFC specifying under what conditions the IANA MIB can be
updated (standards track, IESG, expert etc).

This procedure is described in draft-ietf-ops-mib-review-guidelines-04.txt which
also points to previous examples of this.  And this issue has already surfaced,
albeit obliquely, on this list once before in the context of
IANAItuProbableCause which uses this procedure and is now published as part of
the Alarm MIB (RFC 3877).

Not to do this now creates extra work in the future; when an implementor has to
create their own SMI and whenever these values need to be updated.

Tom Petch




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Mar 2005 18:00:51 +0000
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Draft minutes
Date: Thu, 17 Mar 2005 12:59:03 -0500
To: "Adrian Farrel" <[e-mail]>

Hi Adrian,

Few comments,

On Mar 16, 2005, at 5:44 PM, Adrian Farrel wrote:

> Hi,
>
> Please comment on the draft minutes.
>
> Thanks to Richard, Zafar and Tove for putting these together.
>
> Adrian
>
> ========
>
> Common Control and Measurement Plane WG (ccamp)
>
> Tuesday, March 8, 2005 at 0900-1130
> Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen
>
> Working group status - chairs
> - No changes to the agenda made.
> - Adrian reviewed status of drafts, reviewed charter milestones.
>   We are holding off on new charter until finish last call of 8
>   drafts, expect 1-2 months.
> - Bill summarized ADs view, should wait for re-chartering until
>   finish last call considering expectation will be very soon for
>   last calls.
> * Dimitri asked about IPR assertion on re-optimization draft
>   - Adrian said it did not give the same terms that have been seen
>     in some recent IPR claims. The WG has to decide what to do.
>   - Scott Bradner said we need to be very careful.  Advised there
>     may be anti-trust issues. Best to have no IETF interaction
>     other than to ask for clarity.
>     Scott offered to review emails on the subject.
>   - JP said we can take that as a way to go forward and continue
>     technical work.
>
> ASON considerations
>
> ITU liaison - Lyndon Ong presented Wesam's slides
> - Thanks to the IETF for liaisons and participation of Adrian and
>   Igor at last meetings
> - Crankback and the comparison of LMP and ASON discovery will be
>   incorporated in SG15 Q14's work.
> - There are two liaisons from ITU to CCAMP on the way.
> - Routing - ITU not planning any routing exts work, looking to
>   IETF's work.
> - Continuing work on ASON management.
> - An FTP site is available for liaison statements.
> * Adrian asked if ITU plans to liaise G.7713 on new text for
>   crankback before consent?
>   - Lyndon said a meeting is upcoming and will ask for it to be
>     considered.
> * Kireeti asked if there is any problem in that the crankback draft
>   is not an RFC yet?
>   - Adrian - RFC is desirable, not required?
>   - Scott Bradner - it is required to have an RFC number for final
>     balloting. The IESG can request expedited publication.
> * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU
>   terminology, and may want to consider including it.
>   - Adrian - can that be liaised to us?
>   - Steve Trowbridge - Yes, we can do that.
>
> ASON Routing Evaluation
> * Adrian - The design team on routing has members from both ITU and
>   IETF, although we did not do the correct process, so ITU reps are
>   individuals, not ITU representatives.
>   - Adrian will work with Steve to formalize the process.
> * Adrian - Would like to make the draft from the team on evaluation
>   of routing protocols into a working group draft
>   - we will take to the list to see if any objection.
> * Dimitri - asked if we can use formal liaison process to send this
>   draft to ITU, does it need to be WG draft? And encourages comments
>   now, before it goes to last call.
>   - Adrian - we can liaise the draft and our intention to consider it
>     as a WG draft
>
> Lexicography draft (Adrian)
> - Q14 indicates meeting went well, authors summarized comments and
>   incorporated in this release.
> * Adrian asked if should be WG draft
>   - Kireeti said we could do that, need to ask the list, also need to
>     compare with G.8081
> * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC
>   or drafts, are there definitions?
>   - Adrian thinks there are good terms, though in multiple
>     RFCs/drafts.
>   - Ben - if someone is new to the IETF, they have difficulty on
>     where to go for definitions.
>   - Adrian - if people want to do a draft to collect definitions of all
>     GMPLS terms (more general than just ASON as in lexi draft), then
>     they are welcome to do it.
>
> Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi)
> LSP Stitching (Arthi)
> - Need feedback on several items.
> * Adrian - it would be inappropriate to move extensions to be a WG
>   draft without first stitching draft becoming a wg draft. If no one
>   objects, see no reason why not to be WG draft.
> * Dimitri - Question: the draft was to originally do signaling exts,
>   do we need to do more on routing aspects?
>   - Arthi - agree, if we do now as separate doc from exts draft, then
>     should include routing aspects.
> * Dimitri - if allow different switching caps, then this changes the
>   type, and this a FA
>   - Arthi - but end-to-end does not change.
> * Zafar - we need to be careful what advertising because of scalability
>   concerns, need further consideration.
>   - Arthi - yes need more discussion.
> * Igor - thought stitching maybe more appropriate for LSP hierarchy
>   draft, but as this already in editor's queue, will add here.
> * Lou - sw cap can change hop by hop just needs to match end to end of
>   hop.
>   - Arthi - agree, we were thinking the same.
> * Discussion sent to mailing list
>
> Per-domain path computation method for computing inter-domain traffic
> engineering (TE) LSP. (JP)
> Draft-vasseur-ccamp-inter-domain-path-comp-00.txt:
> routing and path computation aspects.
> * Zafar asked clarification on ccamp-pce relationship
>   - Kireeti - this draft discusses ASBR on the path, if not then it's
>     PCE, suggest add this to draft to clarify that this is for when
>     computation is done by elements on the path.
>   - JP - ok
> * Adrian and Kireeti asked if this should be a WG draft? Good consensus
>   in the room to be WG draft, will take it to the list.
>
> Automesh (JP)
> - Agreement to rehash work a bit to put these together.
> - Now 2 drafts
> - Not a new ID, no changes.
> - Deployed networks using that.
> - No major changes planned
> * Igor - asked how to reflect constraints in a node for switching?
>   - JP - we are discussing auto mesh, not node switching.
>   - Igor - but how do we reflect node capabilities?
>   - JP - this we do, we carry in OSPF a TLV to describe.

Please replace by:
JP - this draft is not about node capability discovery (for this, see 
draft-vasseur-ccamp-te-node-cap)

>   - Igor - how to reflect for computation any internal constraints,
>     could do via node caps advertisement.
>   - JP agrees, though here just doing a discovery, doesn't think
>     related as discovering members of mesh.
>   - Adrian - two drafts, this is not node capability that is next one
>     by JP, cut discussion said to take it to list.
>
> JP - Routing extensions for discovery of TE node capabilities
> * Adrian - on process, authors did a group job of splitting draft
>   and sending to OSPF and ISIS groups, chairs will follow up with
>   those groups.
> * Dimitri - should for terminology call TE router?
>   - JP - yes.
>   - Dimitri - shouldn't be exclusive the TLV?

not sure of what the question was ...

>   - JP - yes.
> * Igor - how to distinguish node capabilities?
>   - Adrian - do by TLVs, need to do a draft to propose, this draft
>     gives you the TLVs, then can follow-up with other drafts to
>     describe function want to use it for, take discussion to list.
> * JP asked that this be adopted as a WG document.
>   - Adrian - Take it to the list
>
> Extensions to GMPLS RSVP graceful restart (Lou Berger)
> * Adrian - do editorial respin, let us know, and we will take to
>   last call
> * Any implementations?
>   - Yes - two!
>
> MRN
> Requirements (Kohei Shiomoto)
> Evaluation draft (JL Le Roux)
> Protocol extensions (Dimitri)
> * Arthi - what does virtual FA have to do with MRN,
>   isn't it general?
>   - Dimitri - should we have a specific doc on virtual FA for
>     wider scope?
>   - Arthi - did you want to scope only to MRN context?
>   - Dimitri - no, just not sure if soln doc should be split.
>   - Arthi - could be general - so prefer a separate doc on virtual FA.
> * Zafar - we need to give a priority capability for TE.
>   - Dimitri - new TLV may be needed to describe relationships of
>     multiple interfaces
> * Zafar - how relates to hierarchy draft?
>   - Dimitri - maybe should be as applicability statement,
>   - Kireeti - should do on mailing list
> * Kireeti - requests to continue work, when re-charter will consider
>   for WG drafts.
>
> Routing considerations and CSPF for inter-as (Tomohiro Otani)
> * JP - very useful draft, not sure (and concerned) on capability and
>   scalability as depends on constraint trying to summarize.

Please replace by:

JP - very useful draft, concerned about the advertisement of DYNAMIC 
summarized TE resource information across domains (static capabilities 
are perfectly fine). Too much of aggregation renders the solution 
inefficient and not enough of aggregation seriously compromises the 
routing scalability. Furthermore, there are other confidentiality 
issues to sort out in the context of inter-provider.

>   - Otani - ok, we need more on summarizing capability.
> * Kireeti - thinks good and hopes to be a WG draft, though for now
>   would request for this draft to continue work, though lets finish
>   what ccamp has now and then when re-charter will make this as a
>   WG doc.
> * Otani - how to handle inter-as cspf constraints?
>   - Kireeti - as noted before (continue work).
>
> L2LSP (Dimitri)
> * Adrian asked clarification, is this "single hop"?
>   - Dimitri - multiple hops each is a LSR, will clarify this in draft
> * Kireeti - ADs request a framework doc and include how it relates to
>   other SDOs, max 10 pages
>   - Dimitri - ok
>
> GMPLS addressing (Richard Rabbat)
> * Adrian - as this is first version, recommend continue discussion,
>   re-spin draft, and then review again.
> * Adrian asked for feedback on the topics, not the technical content
>   initially.
> * Loa - BCP is a specific type of RFC, describes what we have
>   experience with not necessarily what should be (as in this draft)
> * Kireeti - warns for everyone with implementations to review the
>   draft to ensure direction taken by this draft is right one.
> * Lou - should we wait for re-spin or now?
>   - Kireeti - wait for re-spin.
>
> L1VPN (Tomonori Takeda)
> Framework draft
> Applicability draft
> * Alex - by next IETF will decide if it should be included in ccamp or
>   as separate WG.
>
> Control plane saturation (JL Le Roux)
> * Arthi - do we really want to advertise limitations and implications?
> * Kireeti - because of time, lets do on list.
>
> Graceful shutdown (Zafar Ali)
> * Kireeti - will consider for wg doc after re-charter
> * JP - is this part of current charter
>   - Kireeti - doesn't matter, we just can not include anymore as WG
>     doc until re-charter.
>
> Deployment-augmented (Zafar Ali)
> * Arthi- comment is this a FA for router to optical domain
>   - Zafar - no just TE link
>
> GMPLS interworking (Kenji)
> * Dimitri - why need to adv priority of LSP?
>   - Adrian - need to ask on list.
>
> GMPLS interworking (Kohei Shiomoto)
> * Adrian - WG doc will be decided after re-charter
>   - Welcome that will merge with other draft on augmented,
>   - Suggest also look at Kenji's interworking draft to merge.
>
> Cho - ARP signal
> * Kireeti - request work with Dimitri on framework draft,
>   - When decide direction and interactions with other SDO, may
>     decide to form a design team to work on L2,
>   - First we need a framework.
>

Thanks.

JP.



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Mar 2005 17:30:41 +0000
Message-ID: <03ef01c52b16$e8513c40$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt
Date: Thu, 17 Mar 2005 17:26:46 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Dimitri,

> > Abstract:
> >    This document describes protocol specific procedures and extensions
> >    for Generalized Multi-Protocol Label Switching (GMPLS) Resource
> >    ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to
> >    support end-to-end Label Switched Path (LSP) recovery that denotes
> >    protection and restoration.
> > Not sure what is meant by "denotes" in this context.
> > Perhaps "is used to provide" ?
>
> -> was meant to say "that means..." - so any better wording ?

OK...
"...to support end-to-end Label Switched Path (LSP) recovery, that is
protection and restoration of end-to-end LSPs."

> > ===
> > Section 3
> > Although the second paragraph defines "end-to-end protection" I would
like to see this pulled out into its own paragraph for emphasis, and also
a little more clarity added to the definition. For example, it would
appear that your four types of e2e protection are all have the protecting
and protected LSPs disjoint in some way - this makes it appear that this
is a property of e2e protection in general and you should state this if it
is true.
>
> -> so you would like to see as part of the introduction a statement
> about end-to-end protection concept - i don't think there is any
> specific issue in adding this

OK. Thanks. I don't need a whole essay; just a short paragraph.

> > ===
> > Section 3
> >    Note that in both
> >    cases, any lower priority LSP that would use the pre-reserved
> >    resources for the protecting LSP(s) MUST be preempted during the
> >    activation of the protecting LSP.
> > This sentence comes out of the blue. The whole of the paragraph up to
then has not even mentioned extra traffic.
>
> -> don't understand your comment as it is mentioned at the beginning of
> the paragraph

OK. It's a long paragraph with a page throw in the middle. I guess I fell
asleep by the time I got to the end of the paragraph!

> > ===
> > Section 4.2.1
> >    - S (Secondary) bit: enables distinction between primary and
> >      secondary LSPs. A primary LSP is a fully established LSP for
> >      which the resource allocation has been committed at the data
plane
> >      (i.e. full cross-connection has been performed). Both working and
> >      protecting LSPs can be primary LSPs. A secondary LSP is an LSP
> > I am uneasy about this definition of "primary". In [TERM] the only
mention of "primary" is in section 2...
> >    Recovery typically involves the activation of a recovery (or
> >    alternate) LSP when a failure is encountered in the working (or
> >    primary) LSP.
>
> -> this definition needs to be updated as - by removing primary in the
> second parenthesis - it comes from a initial phase where no solution
> where yet started

OK. So please make sure that this happens during RFC Ed or authors 48
hours on [TERM].

> > This implies that "primary" is a synonym for "working".
> > Further, RFC3471 has a subtly different meaning for "secondary" in
section 7.
> >    Protection Information also indicates if the LSP is a primary or
> >    secondary LSP.  A secondary LSP is a backup to a primary LSP.  The
> >    resources of a secondary LSP are not used until the primary LSP
> >    fails.  The resources allocated for a secondary LSP MAY be used by
> >    other LSPs until the primary LSP fails over to the secondary LSP.
At
> >    that point, any LSP that is using the resources for the secondary
LSP
> >    MUST be preempted.
> > Can we please not modify the interpretation of the S-bit.
>
> -> this is what the draft does as also explained in
>
> "   In this document, the PROTECTION object uses as a basis the
>     PROTECTION object defined in [RFC3471] and [RFC3473] and defines
>     additional fields within it. The fields defined in [RFC3471] and
>     [RFC3473] are unchanged by this memo. "
>
> > If you need to flag a new piece of information (to distinguish between
resource allocated and not) then please introduce a new flag.
> > Note that the P-bit appears to be slightly orthogonal because the text
seems to describe the *current* role of the LSP. (The S-bit in RFC3471
describes the role at the time the LSP is set up, I think).
>
> -> note this has already been explained to you - where we came to the
> conclusion for clarity to add the above mentioned paragraph

Well, then I guess I find RFC3471 poorly drafted.

> > ===
> > Section 5
> >    When a failure occurs (say at node B) and is detected at end-node
D,
> >    the receiver at D selects the normal traffic from the other LSP.
> >    From this perspective, 1+1 unidirectional protection can be seen as
> >    an uncoordinated protection switching mechanism acting
independently
> >    at both end-points. Also, for the protected LSP under failure
> >    condition, the Path_State_Removed Flag of the ERROR_SPEC object
(see
> >    [RFC3473]) SHOULD NOT be set upon PathErr message generation.
> > So, what you are saying is that in 1+1 protection the network may
*never* know that the error is so bad that the LSP is dead, but MUST leave
that choice to the ingress. While this is the operational practice in many
transport networks, I don't see why you make this as strong as a SHOULD
NOT.
>
> -> what i mean is that this LSP in a 1+1 mode should not be released
> after failure (which is the common usage of such a scheme)

Agree about comon usage.
Think SHOULD NOT is too strong.
Would accept RECOMMENDED.

> > ===
> > Section 5.1
> >    A new PROTECTION object is included in the Path message. This
object
> >    carries the desired end-to-end LSP Protection Type (in this case,
> >    "1+1 Unidirectional"). This LSP Protection Type value is applicable
> >    to both uni- and bi-directional LSPs.
> > This is unclear. In section 14.1 you have
> >                 0x08    1+1 Unidirectional Protection
> >                 0x10    1+1 Bi-directional Protection
>
> -> in 5.1 "This LSP Protection Type value is applicable
>     to both uni- and bi-directional LSPs. "
>
> -> in 6.1 "This LSP Protection Type
>     value is only applicable to bi-directional LSPs.

Ah!

Very sorry. I wonder if my stupidity is also present in others.
That is (of course), the protection type uni/bi is not the same as the LSP
direction uni/bi.
And that bi protection is meaningless for a uni LSP.

Any hope of a couple of lines to avoid this confusion?

> > ===
> > Section 6.2
> >    directions. This is done using the Notify message with a new Error
> >    Code indicating "Working LSP Failure (Switchover Request)". The
> > I don't see this in the IANA section, and I wonder if you also mean
Error Value?
>
> -> it corresponds to the entry "Notify Error/LSP Failure"
> (suggested value = 6)" error value is thus appropriate

Ah. OK, then just update the text in section 6.2.

> > ===
> > Section 7.2
> >    This operation may be done using a Notify message exchange with a
> >    new Error Code indicating "(Working) LSP Failure (Switchover
> >    Request)". The Notify Ack message MUST be sent to confirm the
> >    reception of the Notify message.
> > All of the same comments as for section 6.2.
> > Also:
> > - Why do you say "may be done"?
>
> -> "initiated" or "performed"

It is the "may be" that I question. It implies there is a choice of ways
to do it.
Section 6.2 uses "this is done".

> > ===
> > Section 13 (D and E)
> >    This, unless a fault condition exists on
> > ? "This is allowed"? "This is possible"? "This is successful"?
>
> -> would you clarify what you mean here

I am suggesting meaning (and therefore replacement text) for the phrase
"This, unless a fault condition exists"

> > ===
> > Section 14.1
> > I believe we have had this discussion before.
> > We don't introduce reserved fields for future extensibility. We only
do it for padding.
> > If you are certain that we need to extend in the future then please
use sub-objects or TLVs.
> > This means that you can:
> > a. Remove the last four bytes of the Protection object.
> > b. Retain the C-Type from RFC3473
>
> -> will add a reference to segment recovery (that does not make use of
> TLVs) - see section 6.1 of SEG-REC

Suppose this is OK.
But, notwithstanding the fact that I am an author of SEG-REC, it appears
that the additional info that is defined in SEG-REC would fit within the
existing 64 bit structure. (Appologies for not reviewing that draft
first.)

> > ===
> > Section 15
> > In the case where my protecting LSP protects only one working LSP and
where the full path of the protecting LSP is known by the ingress (strict
and explicit) and there is no resource sharing between the protected and
protecting LSP, I can't see why I must include a PPRO.
> > In other words, PPRO is an enabler of function (as stated in section
15.4 "The PPRO enables of sharing recovery resources between a given
secondary protecting LSP and one or more secondary protecting LSPs if
their corresponding primary working LSPs have mutually
(link/node/SRLG)disjoint paths."), but that does not make its presence
mandatory.

No comment?

> > ===
> > Section 15.1
> >    The contents of a PRIMARY_PATH_ROUTE object are a series of
> >    variable-length data items called subobjects. The subobjects are
> >    identical to those that can constitute an EXPLICIT/RECORD ROUTE
> >    object as defined in [RFC3209], [RFC3473] and [RFC3477].
> > This seems in contradiction with section 15.3
>
> -> identical in terms of content definition

15.3 says
   The following subobjects are currently defined for the PRIMARY PATH
   ROUTE object:
   - Sub-Type 1: IPv4 Address (see [RFC3209])
   - Sub-Type 2: IPv6 Address (see [RFC3209])
   - Sub-Type 3: Label (see [RFC3473])
   - Sub-Type 4: Unnumbered Interface (see [RFC3477])
but RFC3209 defines
    32   Autonomous system number

Hence a contradiction. If you are prepared to accept type 32 in the PPRO I
suggest that you remove the list of accepted values and simply state that
anything that can go in an ERO *or* an RRO is acceptable in a PPRO.

> > ===
> > Section 17
> > Isn't Notify modified as well?
> > And I thought Resv was, but I may have been sleeping.
>
> -> Resv needs to be added (Notify is not modified)

   This section describes the extensions to the PROTECTION object to
   broaden its applicability to end-to-end LSP recovery. In addition to
   modifications to the format of the PROTECTION object, we extend its
   use so that the object can be included in the Notify message to act
   a switchover request for 1+1 bi-directional and 1:1 protection.

Looks like a modification to me.

> > ===
> > Section 19
> > The IANA section needs some gardening to make it really easy for IANA
to implement.
> > - Only have suggested values in one place in the document
>
> -> ok (do think put the proposed value as part of the text and the IANA
> section ease reading)

Don't feel strongly.
Have seen too many drafts go to RFC with mixed values or TBD still in
place.

> > ===
> > Section 19
> > Should the IANA section also cover the bits in the ADMIN STATUS
object?
>
> -> we did not register these bits since if you think we need to register
> them as part of this section just let me know

Asking your opinion, really.
Question is, what is the risk of losing track of Admin Status bits?
Note, I keep an informal registry on the alternate CCAMP pages.

Thanks for the hard work.
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Mar 2005 14:38:34 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Mar 2005 15:35:34 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian

thanks for commenting - in-line responses to your question

Adrian Farrel wrote:

> Hi,
> I've got a couple of comments in what seems like quite a long draft.
> Adrian
> 
> Abstract:
>    This document describes protocol specific procedures and extensions 
>    for Generalized Multi-Protocol Label Switching (GMPLS) Resource 
>    ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to 
>    support end-to-end Label Switched Path (LSP) recovery that denotes 
>    protection and restoration.
> Not sure what is meant by "denotes" in this context.
> Perhaps "is used to provide" ?

-> was meant to say "that means..." - so any better wording ?

> ===
> Section 2
> OLD
>    In addition, the reader is assumed to be familiar with the 
>    terminology used in [RFC3945], [RFC3471], [RFC3473] and referenced 
>    as well as [TERM] and [FUNCT]. 
> NEW
>    In addition, the reader is assumed to be familiar with the 
>    terminology used in [RFC3945], [RFC3471], [RFC3473],
>    as well as in [TERM] and [FUNCT]. 

-> ok

> ===
> Section 2
>    Checklog List from revision v01.txt:  
> Please either remove this text or mark it so that the RFC editor will remove it.

-> ok

> ===
> Section 3
> Although the second paragraph defines "end-to-end protection" I would like to see this pulled out into its own paragraph for emphasis, and also a little more clarity added to the definition. For example, it would appear that your four types of e2e protection are all have the protecting and protected LSPs disjoint in some way - this makes it appear that this is a property of e2e protection in general and you should state this if it is true.

-> so you would like to see as part of the introduction a statement 
about end-to-end protection concept - i don't think there is any 
specific issue in adding this

> ===
> Section 3 para 5
>    In 1:N (N =< 1) protection with extra-traffic,
> Hopefully you mean N >= 1  

-> yes

> ===
> Section 3 para 5
> I note that you do not distinguish between 1:N and 1:N-with-extra-traffic.
> If there is a reason for this perhaps you could add a note to the text.

-> indeed

> ===
> Section 3
> OLD
>    working one. Here, the recovery resources for the protecting LSP are 
>    pre-reserved and explicit action is required to activate (i.e. 
> NEW
>    working one. Here, the recovery resources for the protecting LSP are 
>    pre-reserved but explicit action is required to activate (i.e. 
>                 ^^^

-> ok

> ===
> Section 3
> OLD
>    requirements by allowing multiple protecting LSPs to share common 
>    link and node resources. The recovery resources are pre-reserved and 
> NEW
>    requirements by allowing multiple protecting LSPs to share common 
>    link and node resources. The recovery resources are pre-reserved but
>                                                                     ^^^ 

-> ok

> ===
> Section 3
>    Note that in both 
>    cases, any lower priority LSP that would use the pre-reserved 
>    resources for the protecting LSP(s) MUST be preempted during the 
>    activation of the protecting LSP. 
> This sentence comes out of the blue. The whole of the paragraph up to then has not even mentioned extra traffic. 

-> don't understand your comment as it is mentioned at the beginning of 
the paragraph

> I suggest you insert a paragraph break and a sentence explaining how the pre-reserved resources may be used to support an extra-traffic LSP...
> Also, delete "would".

-> ok - this could indeed ease reading

> ===
> Section 3
>    Full LSP re-routing (or restoration) switches normal traffic to an 
>    alternate LSP that is fully established only after working LSP 
>    failure occurs.
> This text does not read well in English. In fact, the same is true of pre-planned. What you mean is, I think, as follows...
>    Full LSP re-routing (or restoration) switches normal traffic to an 
>    alternate LSP that is not even partially established until after 
>    the working LSP failure occurs. 

-> indeed as none pre-provisioning actions are performed for the alternate

> ===
> Section 3
>    Note that crankback signaling (see [CRANK]) and LSP segment recovery 
>    are further detailed in dedicated companion documents. Also, there 
> Need to add a citation for LSP segment recovery.

-> ok

> ===
> Section 4.2
> OLD
>    The recovery attributes includes all the parameters that determine 
> NEW
>    The recovery attributes include all the parameters that determine 

-> ok

> ===
> Section 4.2.1
>    - S (Secondary) bit: enables distinction between primary and  
>      secondary LSPs. A primary LSP is a fully established LSP for  
>      which the resource allocation has been committed at the data plane  
>      (i.e. full cross-connection has been performed). Both working and  
>      protecting LSPs can be primary LSPs. A secondary LSP is an LSP  
> I am uneasy about this definition of "primary". In [TERM] the only mention of "primary" is in section 2...
>    Recovery typically involves the activation of a recovery (or
>    alternate) LSP when a failure is encountered in the working (or
>    primary) LSP.

-> this definition needs to be updated as - by removing primary in the 
second parenthesis - it comes from a initial phase where no solution 
where yet started

> This implies that "primary" is a synonym for "working".
> Further, RFC3471 has a subtly different meaning for "secondary" in section 7.
>    Protection Information also indicates if the LSP is a primary or
>    secondary LSP.  A secondary LSP is a backup to a primary LSP.  The
>    resources of a secondary LSP are not used until the primary LSP
>    fails.  The resources allocated for a secondary LSP MAY be used by
>    other LSPs until the primary LSP fails over to the secondary LSP.  At
>    that point, any LSP that is using the resources for the secondary LSP
>    MUST be preempted.
> Can we please not modify the interpretation of the S-bit.

-> this is what the draft does as also explained in

"   In this document, the PROTECTION object uses as a basis the
    PROTECTION object defined in [RFC3471] and [RFC3473] and defines
    additional fields within it. The fields defined in [RFC3471] and
    [RFC3473] are unchanged by this memo. "

> If you need to flag a new piece of information (to distinguish between resource allocated and not) then please introduce a new flag.
> Note that the P-bit appears to be slightly orthogonal because the text seems to describe the *current* role of the LSP. (The S-bit in RFC3471 describes the role at the time the LSP is set up, I think).

-> note this has already been explained to you - where we came to the 
conclusion for clarity to add the above mentioned paragraph

> ===
> Section 4.3
> OLD
>    When used for the working LSP signaling, the Association ID of the 
> NEW
>    When used for signaling the working LSP, the Association ID of the 

-> ok

> ===
> Section 4.3
> OLD
>    When used for the protecting LSP signaling, this field identifies 
> NEW
>    When used for signaling the protecting LSP, this field identifies 

-> ok

> ===
> Section 5
>    When a failure occurs (say at node B) and is detected at end-node D, 
>    the receiver at D selects the normal traffic from the other LSP. 
>    From this perspective, 1+1 unidirectional protection can be seen as 
>    an uncoordinated protection switching mechanism acting independently 
>    at both end-points. Also, for the protected LSP under failure 
>    condition, the Path_State_Removed Flag of the ERROR_SPEC object (see 
>    [RFC3473]) SHOULD NOT be set upon PathErr message generation. 
> So, what you are saying is that in 1+1 protection the network may *never* know that the error is so bad that the LSP is dead, but MUST leave that choice to the ingress. While this is the operational practice in many transport networks, I don't see why you make this as strong as a SHOULD NOT.

-> what i mean is that this LSP in a 1+1 mode should not be released 
after failure (which is the common usage of such a scheme)

> ===
> Section 5
>    Note: one should assume that both paths are SRLG disjoint otherwise, 
>    a failure would impact both working and protecting LSPs. 
> What is this supposed to tell the reader? That he should make the assumption or that he should ensure SRLG diversity? ;-)
> Actually, I think you want to say that the quality of 1+1 protection may vary. Allowing link diverse, node diverse or SRLG diverse 1+1 protection.
> (ditto section 6 and 7)

-> indeed i can phrase this in a more prescriptive way (rather than the 
descriptive currently proposed)

> ===
> Section 5.1
>    Since both LSPs belong to the same session, the SESSION object MUST 
>    be the same for both LSPs. 
> An undisputable conclusion drawn from an unproven premise.
> Why must both LSPs belong to the same session? A one line explanation would start the section off nicely.

-> ok

> ===
> Section 5.1
>    A new PROTECTION object is included in the Path message. This object 
> What is the implication of "new"? I guess you mean the new type defined in this draft.

-> yes

> ===
> Section 5.1
>    A new PROTECTION object is included in the Path message. This object 
>    carries the desired end-to-end LSP Protection Type (in this case, 
>    "1+1 Unidirectional"). This LSP Protection Type value is applicable 
>    to both uni- and bi-directional LSPs. 
> This is unclear. In section 14.1 you have 
>                 0x08    1+1 Unidirectional Protection  
>                 0x10    1+1 Bi-directional Protection 

-> in 5.1 "This LSP Protection Type value is applicable
    to both uni- and bi-directional LSPs. "

-> in 6.1 "This LSP Protection Type
    value is only applicable to bi-directional LSPs.

> ===
> Section 5.1
> Your description of the use of the P-bit for 1+1 protection isn't clear. You mean to say that the P-bit indicates which LSP the ingress would *prefer* to be the protecting LSP if all other things are equal, but your text (and the description of the P-bit in sections 4.2.1 and 14) don't make this clear.

-> ok instead of stating it is desirable i will provide a more 
deterministic statement

> ===
> Section 6.2
>    directions. This is done using the Notify message with a new Error 
>    Code indicating "Working LSP Failure (Switchover Request)". The 
> I don't see this in the IANA section, and I wonder if you also mean Error Value?

-> it corresponds to the entry "Notify Error/LSP Failure" 
(suggested value = 6)" error value is thus appropriate

> ===
> Section 6.2
>    directions. This is done using the Notify message with a new Error 
>    Code indicating "Working LSP Failure (Switchover Request)". The 
>    Notify Ack message MUST be sent to confirm the reception of the 
>    Notify message (see [RFC3473], Section 4.3).    
> I see no definition of a "Notify Ack message" in RFC3473 (in any section).
> I am worried that you are confusing the Ack message with a new procedure requiring a handshake of Notify messages.

-> ok i will rephrase that one

> ===
> Section 6.2
>         1. If an end-node (A or D) detects the failure of the working  
>            LSP (or a degradation of signal quality over the working  
>            LSP) or receives a Notify message including its SESSION  
>            object within the <upstream/downstream session list> (see  
>            [RFC3473]), it MUST begin receiving on the protecting LSP  
> Note that the sender descriptor or flow descriptor is also present in the Notify and this will considerably help resolve ambiguities and race conditions since it identifies the LSP.

-> ok i will add a statement along these lines

> ===
> Section 6.2
>         1. If an end-node (A or D) detects the failure of the working  
>            LSP (or a degradation of signal quality over the working  
>            LSP) or receives a Notify message including its SESSION  
>            object within the <upstream/downstream session list> (see  
>            [RFC3473]), it MUST begin receiving on the protecting LSP  
> I don't think the receipt of a Notify message is sufficient, per se. I think the error code and value need to indicate a problem with the LSP.

-> this is explained in the next paragraph, but i will add a statement 
with respect to this error code/value processing

"           Note: in this case, the IF_ID ERROR_SPEC replaces the
            ERROR_SPEC in the Notify message, otherwise the
            corresponding (data plane) information SHOULD be received
            in the PathErr/ResvErr message. "

> ===
> Section 6.2
>         1. If an end-node (A or D) detects the failure of the working  
>            LSP (or a degradation of signal quality over the working  
>            LSP) or receives a Notify message including its SESSION  
>            object within the <upstream/downstream session list> (see  
>            [RFC3473]), it MUST begin receiving on the protecting LSP  
>            and send a Notify message reliably to the other end-node (D  
>            or A, respectively).
> "...send a Notify message reliably" will certainly be misunderstood.
> You presumably mean "...send a Notify message including the Message_ID object".

-> yes

> ===
> Section 6.2
>         2. Upon receipt of the switchover message, the end-node  
>            (D or A, respectively) MUST begin receiving from the  
>            protection LSP and send a (Notify) Ack message to the other  
>            end-node (A or D, respectively) using reliable message  
>            delivery (see [RFC2961]). 
> While this clarifies the use of Ack rather than Notify Ack (not sure why you need to include "(Notify)") it is now confused about the delivery of the Ack message. How do we achieve reliable delivery of an Ack message?!

-> needs to be rephrased as the only to achieve reliable bi-directional 
exchange is by ensuring three way handshake (Notify ->, Notify + Ack <-, 
Ack ->)

> ===
> Section 7
>    Although the resources for the protecting LSP are pre-allocated, 
>    preemptable traffic may be carried end-to-end using this LSP (i.e. 
>    the protecting LSP is capable of carrying extra-traffic) with the 
>    caveat that this traffic will be preempted if the working LSP fails. 
> Do you mean that the extra traffic is carried "using this LSP" or "using some or all of the resources assigned to this LSP"?

-> the first "using this LSP"

> ===
> Section 7
>    Also, if extra-traffic is carried over the protecting LSP, the 
>    corresponding end-nodes may be notified of the failure in order to 
>    complete the switchover.  
> I think this is "end-nodes may need to be notified"

-> ok

> ===
> Section 7.2
>    To co-ordinate the switchover between end-points, an end-to-end 
>    switchover request is needed such that the affected LSP(s) are moved 
>    to the protecting LSP.
> In what way may there be more than one affected LSP moved to a single protecting LSP?

-> if someone uses the multiplier field of the SONET/SDH TSPEC, but 
there is a typo in the last LSP (missed a "s")

> ===
> Section 7.2
>    This operation may be done using a Notify message exchange with a 
>    new Error Code indicating "(Working) LSP Failure (Switchover 
>    Request)". The Notify Ack message MUST be sent to confirm the 
>    reception of the Notify message.  
> All of the same comments as for section 6.2.
> Also:
> - Why do you say "may be done"?

-> "initiated" or "performed"

> - Is this the same error code as in 6.2? (the text is slightly different)

-> i will adapt error value per IANA section - the same for the error 
codes as part of section 6.2

> === 
> Section 7.3
> OLD
>    provisioned protecting LSP is resource-disjoint LSP from the N 
> NEW
>    provisioned protecting LSP is resource-disjoint from the N 

-> ok

> ===
> Section 7.3
> Can you highlight that the N working LSPs are all between the same pair of end points.

-> ok

> ===
> Section 8
> OLD
>    this does not mean that the corresponding resources can not used by 
> NEW
>    this does not mean that the corresponding resources can not be used by 

-> ok

> ===
> Section 8
>    To make bandwidth pre-reserved for a protecting (but not activated) 
>    LSP, available for extra traffic this bandwidth could be included in 
>    the advertised Unreserved Bandwidth at priority lower (means 
>    numerically higher) than the Setup Priority of the protecting LSP. 
> This feels like it should be the Holding Priority. That is, the Setup Priority was only important for how it could displace pre-existing LSPs.

-> ok (it will clarify) - but there was an implicit statement here that 
both are actually equal

> ===
> Section 8.3
> OLD
>    From [GMPLS-ARCH], the secondary LSP is setup with resource pre-
> NEW
>    From [RFC3945], the secondary LSP is setup with resource pre-

-> ok

> ===
> Section 9
> OLD
>    plane) a specific protecting LSP instantiated during the (pre-
>    )provisioning phase. This requires restoration signaling along the 
> NEW
>    plane) a specific protecting LSP instantiated during the (pre-)
>    provisioning phase. This requires restoration signaling along the 

-> ok

> ===
> Section 9
>    resource sharing), the LSPs must have the same Session Ids, but the 
>    Session Id includes the target (egress) IP address. These addresses 
> 2xs/Id/ID/
> Suggest a search for "id"

-> will use "ID"

> ===
> Section 9.3
> OLD
>    From [GMPLS-ARCH], the secondary LSP is setup with resource pre-
> NEW
>    From [RFC3945], the secondary LSP is setup with resource pre-

-> ok

> ===
> Section 10
> OLD
>    activated. Additional condition raises from mis-connection avoidance 
> NEW
>    activated. An additional condition arises from mis-connection avoidance 

-> ok

> ===
> Section 10
> OLD
>    Note that step 1 may cause alarms to be raised for the pre-empted 
>    LSP. If alarm suppression is desired the pre-empting node MAY expand 
>    before applying step 1 act as follows. 
> NEW
>    Note that step 1 may cause alarms to be raised for the pre-empted 
>    LSP. If alarm suppression is desired the pre-empting node MAY insert
>    the following steps before step 1. 

-> ok

> ===
> Section 10
>    At the downstream node (with respect to the pre-empting LSP) the 
>    processing is RECOMMENDED to be as follows: 
>     
>    1. Receive PathTear (and/or PathErr) message for the pre-empted  
>       LSP(s). 
>     
>    2a.Release the resources associated with the LSP on the interface 
>       to the pre-empting LSP, remove any cross-connection and release  
>       all other resources associated with the pre-empted LSP. 
>    2b.Forward the PathTear (and/or PathErr) message per [RFC 3473]. 
>     
>    C. Receive the Path message for the pre-empting LSP and process as  
>       normal, forwarding it to the downstream node. 
>     
>    D. Receive the Resv for the pre-empting LSP and process as normal, 
>       forwarding it to the upstream node. 
> Cool numbering scheme :-)
> Any chance of settling on something more conventional?

-> ok - will use 1, 2a, 2b, 3, 4

> ===
> Section 11.2
>    Note: when the end-to-end LSP Protection Type is set to 
>    "Unprotected", both S and P bit MUST be set to 0 and the LSP SHOULD 
>    NOT be re-routed at the head-end node after failure occurrence. The 
>    Association_ID value MUST be set to the LSP_ID value of the signaled 
>    LSP. 
> Please explain the difference between an attempt to "re-route" and an attempt to "re-establish". presumably it could involve:
> - a time difference
> - the use of make-before-break for failed LSPs.
> - the use of the ASSOCIATION object.
> I would like to make sure that you are not applying "SHOULD NOT" to LSP re-establishment.

-> it means do not apply re-routing as specified in this document, i 
will add a paragraph around these lines

> ===
> Section 12
> OLD
>    allocated to the LSP that was originally routed over it even after a 
> NEW
>    allocated to the LSP that was originally routed over them even after a 

-> ok

> ===
> Section 12
>    - then, apply the reverse 1-phase APS switchover request/response  
>      (or 2-phase APS) described in Section 6.2 (or Section 7.2,  
> This is the first mention of APS

-> see section 7.2 in this section 12 i will use the term "protection 
switching signaling" instead

> ===
> Section 13
> I think this section is going to give us grief during IESG review :-(
> Why do we need to tie this so closely with NMS etc. And why describe it as external?
> Can't we simply describe the function by:
> - dropping the first para
> - in C, D and E drop "externally"
> - in D and E replace "manual" with "requested"

-> ok

> ===
> Section 13 TWICE
> OLD
>    Recovery signaling operation is initiated externally that switches 
> NEW
>    Recovery signaling is initiated externally that switches 

-> ok
> ===
> Section 13 (A and B)
>    is set to either 0x04, or 0x08 or 0x10. 
> I would prefer you to use the meanings rather than the values.

-> ok will add the description

> ===
> Section 13 (D and E)
>    This, unless a fault condition exists on 
> ? "This is allowed"? "This is possible"? "This is successful"?

-> would you clarify what you mean here

> ===
> Section 14
> OLD
>    use so that the object can be included in the Notify message to act 
>    a switchover request for 1+1 bi-directional and 1:1 protection.  
> NEW
>    use so that the object can be included in the Notify message to act 
>    as a switchover request for 1+1 bi-directional and 1:1 protection.  

-> ok

> ===
> Section 14.1
> I believe we have had this discussion before.
> We don't introduce reserved fields for future extensibility. We only do it for padding.
> If you are certain that we need to extend in the future then please use sub-objects or TLVs.
> This means that you can:
> a. Remove the last four bytes of the Protection object.
> b. Retain the C-Type from RFC3473

-> will add a reference to segment recovery (that does not make use of 
TLVs) - see section 6.1 of SEG-REC

> ===
> Section 15
>    This object MUST be 
>    present in the Path message (for the pre-provisioning of the 
>    secondary protecting LSP) if and only if the LSP Protection Type 
>    value is set to "0x02".
> "MUST if and only if" is not really in RFC2119.
> Can we two statements. One with "MUST" and one with "MUST NOT".

-> ok (but i don't understand why this logical statement is not allowed)

> ===
> Section 15
> In the case where my protecting LSP protects only one working LSP and where the full path of the protecting LSP is known by the ingress (strict and explicit) and there is no resource sharing between the protected and protecting LSP, I can't see why I must include a PPRO.
> In other words, PPRO is an enabler of function (as stated in section 15.4 "The PPRO enables of sharing recovery resources between a given secondary protecting LSP and one or more secondary protecting LSPs if their corresponding primary working LSPs have mutually (link/node/SRLG)disjoint paths."), but that does not make its presence mandatory.
> ===
> Section 15.1
>    The contents of a PRIMARY_PATH_ROUTE object are a series of 
>    variable-length data items called subobjects. The subobjects are 
>    identical to those that can constitute an EXPLICIT/RECORD ROUTE 
>    object as defined in [RFC3209], [RFC3473] and [RFC3477]. 
> This seems in contradiction with section 15.3

-> identical in terms of content definition

> ===
> Section 15.4
> OLD
>    The PPRO enables of sharing recovery resources between a given 
> NEW
>    The PPRO enables sharing of recovery resources between a given 

-> ok

> ===
> Section 16
>    The ASSOCIATION object is used to associate LSPs with each other. In 
>    the context of end-to-end LSP recovery, the association MUST only 
>    identify LSPs that support the same Tunnel ID.
> Hmmm. presumably same source and destination is relatively important too.

-> ok i will add a statement here even if it is already part of the next 
sentence

> ===
> Section 16
>    The ASSOCIATION object is used to associate LSPs with each other.   
> You already said this.

-> i will remove it

> ===
> Section 16.1
>       Association ID: 16 bits 
>     
>         A value that when combined with Association Type and  
>         Association Source uniquely identifies an association.  
> It would be helpful to state who assigns this value.

-> it is the sender (i will add this)

> ===
> Section 16.1
>       Association Source: 4 or 16 bytes 
>     
>         The IP address of the node that originated the association. 
> "The IP address"?
> Question. Are two associations with the same Association ID equivalent if the Association Source addresses are different but identify the same node?
> Answer (it transpires) is "no". 
> You need to make this much clearer here.

-> ok i will add a statement along these lines, note this statement will 
be added such that relationship between values is clearer

> ===
> Section 17
> Isn't Notify modified as well?
> And I thought Resv was, but I may have been sleeping.

-> Resv needs to be added (Notify is not modified)

> ===
> Section 18
> This is a bit poor.
> If you don't modify the "external commands" section, you'll certainly have to discuss security for them. After all, a forced failover can be pretty disruptive.
> But I think you need to discuss misconnection here. In particular when there is mesh protection going on.

-> i will include specifics inlight with the text provided in the 
functional specification

> ===
> Section 19
> The IANA section needs some gardening to make it really easy for IANA to implement.
> - Break it up into clearer subsections.
> - Make sure you have included all of the information needed in the registry
> - Point back at the defining sections of the draft
> - Only have suggested values in one place in the document
> - Be consistend in using TBD or TBA in the document

-> ok (do think put the proposed value as part of the text and the IANA 
section ease reading)

> ===
> Section 19
> Should the IANA section also cover the bits in the ADMIN STATUS object?

-> we did not register these bits since if you think we need to register 
them as part of this section just let me know

> ===
> Section 21
> Missing references [CRANK], [RFC2205]. Suspect you need to check them all.
> Will need to add a reference for LSP segment recovery.

-> ok

> ===
> Section 21.1
> This seems a very long list of normative references. I hope you can split this so that most of the references are informational.

-> ok
> ===
> Section 22
> You might change this to "Editors' Addresses"

-> ok



Envelope-to: [e-mail]
Delivery-date: Wed, 16 Mar 2005 22:56:15 +0000
Message-ID: <037901c52a7a$d8d96630$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Tom Petch" <[e-mail]>, <[e-mail]>
Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Wed, 16 Mar 2005 22:51:45 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks for the references.
This fits with what I thought.

Viz. Augments means that an entry in the augmenting table is created
whenever an entry in the base table is created.
Extends means that an entry in the extending table is created only when
required.

The indexing in the two cases is the same.

Cheers,
Adrian


----- Original Message ----- 
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Wednesday, March 16, 2005 9:09 PM
Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt


> To quote from RFC2578
> " Instances of subordinate columnar
>    objects of a conceptual row augmentation are identified according to
>    the INDEX clause of the base conceptual row corresponding to the
>    object named in the AUGMENTS clause.  Further, instances of
>    subordinate columnar objects of a conceptual row augmentation exist
>    according to the same semantics as instances of subordinate columnar
>    objects of the base conceptual row being augmented.  As such, note
>    that creation of a base conceptual row implies the correspondent
>    creation of any conceptual row augmentations"
>
> exactly; or
>
> - AUGMENTS is an alternative to INDEX in SMIv2
> - there is a one to one correspondence between rows in the base table
and rows
> in the AUGMENTS table(s - can be more than one), same index columns,
same index
> values
> - the column objects in the AUGMENTS table(s) are created when the row
in the
> base table is created; assuming that the agent implements those columns
in the
> AUGMENTS table(s) - that is a matter of conformance clauses etc.
>
> Reading the text, I thought these conditions were met - but I was not
sure;
> seeing the INDEX clauses makes me think I am not understanding the text,
I am
> missing something:-)
>
> Tom Petch
>
> ----- Original Message -----
> From: "Adrian Farrel" <[e-mail]>
> To: "Tom Petch" <[e-mail]>; <[e-mail]>
> Sent: Wednesday, March 16, 2005 5:34 PM
> Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt
>
>
> > Hi Tom,
> >
> > > A minor comment; this document has
> > >  false (0),
> > > in several places; following RFC 2579, I think this should be
> > >  false (2)
> >
> > Good catch. This is in the example which is why we didn't catch it by
> > compiling.
> >
> > > A larger question,; this mib augments tables in the mpls mib
(RFC3812);
> > is there
> > > a reason why the AUGMENTS construct was not used?
> >
> > This is not my area of expertise!
> > I think that there are two strict augmentations and in these cases
> > AUGMENTS was used.
> >
> > The other cases are, I believe, extensions.
> >
> > I *think* the difference is that an AUGMENT is always present and an
> > extension is only present if used.
> > (Feels like I'm on shaky ground!)
> >
> > Cheers,
> > Adrian
> >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 16 Mar 2005 22:56:08 +0000
Message-ID: <036b01c52a7a$5dea9ac0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Draft minutes
Date: Wed, 16 Mar 2005 22:44:36 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Please comment on the draft minutes.

Thanks to Richard, Zafar and Tove for putting these together.

Adrian

========

Common Control and Measurement Plane WG (ccamp)

Tuesday, March 8, 2005 at 0900-1130
Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen

Working group status - chairs
- No changes to the agenda made.
- Adrian reviewed status of drafts, reviewed charter milestones.
  We are holding off on new charter until finish last call of 8
  drafts, expect 1-2 months.
- Bill summarized ADs view, should wait for re-chartering until
  finish last call considering expectation will be very soon for
  last calls.
* Dimitri asked about IPR assertion on re-optimization draft
  - Adrian said it did not give the same terms that have been seen
    in some recent IPR claims. The WG has to decide what to do.
  - Scott Bradner said we need to be very careful.  Advised there
    may be anti-trust issues. Best to have no IETF interaction
    other than to ask for clarity.
    Scott offered to review emails on the subject.
  - JP said we can take that as a way to go forward and continue
    technical work.

ASON considerations

ITU liaison - Lyndon Ong presented Wesam's slides
- Thanks to the IETF for liaisons and participation of Adrian and
  Igor at last meetings
- Crankback and the comparison of LMP and ASON discovery will be
  incorporated in SG15 Q14's work.
- There are two liaisons from ITU to CCAMP on the way.
- Routing - ITU not planning any routing exts work, looking to
  IETF's work.
- Continuing work on ASON management.
- An FTP site is available for liaison statements.
* Adrian asked if ITU plans to liaise G.7713 on new text for
  crankback before consent?
  - Lyndon said a meeting is upcoming and will ask for it to be
    considered.
* Kireeti asked if there is any problem in that the crankback draft
  is not an RFC yet?
  - Adrian - RFC is desirable, not required?
  - Scott Bradner - it is required to have an RFC number for final
    balloting. The IESG can request expedited publication.
* Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU
  terminology, and may want to consider including it.
  - Adrian - can that be liaised to us?
  - Steve Trowbridge - Yes, we can do that.

ASON Routing Evaluation
* Adrian - The design team on routing has members from both ITU and
  IETF, although we did not do the correct process, so ITU reps are
  individuals, not ITU representatives.
  - Adrian will work with Steve to formalize the process.
* Adrian - Would like to make the draft from the team on evaluation
  of routing protocols into a working group draft
  - we will take to the list to see if any objection.
* Dimitri - asked if we can use formal liaison process to send this
  draft to ITU, does it need to be WG draft? And encourages comments
  now, before it goes to last call.
  - Adrian - we can liaise the draft and our intention to consider it
    as a WG draft

Lexicography draft (Adrian)
- Q14 indicates meeting went well, authors summarized comments and
  incorporated in this release.
* Adrian asked if should be WG draft
  - Kireeti said we could do that, need to ask the list, also need to
    compare with G.8081
* Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC
  or drafts, are there definitions?
  - Adrian thinks there are good terms, though in multiple
    RFCs/drafts.
  - Ben - if someone is new to the IETF, they have difficulty on
    where to go for definitions.
  - Adrian - if people want to do a draft to collect definitions of all
    GMPLS terms (more general than just ASON as in lexi draft), then
    they are welcome to do it.

Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi)
LSP Stitching (Arthi)
- Need feedback on several items.
* Adrian - it would be inappropriate to move extensions to be a WG
  draft without first stitching draft becoming a wg draft. If no one
  objects, see no reason why not to be WG draft.
* Dimitri - Question: the draft was to originally do signaling exts,
  do we need to do more on routing aspects?
  - Arthi - agree, if we do now as separate doc from exts draft, then
    should include routing aspects.
* Dimitri - if allow different switching caps, then this changes the
  type, and this a FA
  - Arthi - but end-to-end does not change.
* Zafar - we need to be careful what advertising because of scalability
  concerns, need further consideration.
  - Arthi - yes need more discussion.
* Igor - thought stitching maybe more appropriate for LSP hierarchy
  draft, but as this already in editor's queue, will add here.
* Lou - sw cap can change hop by hop just needs to match end to end of
  hop.
  - Arthi - agree, we were thinking the same.
* Discussion sent to mailing list

Per-domain path computation method for computing inter-domain traffic
engineering (TE) LSP. (JP)
Draft-vasseur-ccamp-inter-domain-path-comp-00.txt:
routing and path computation aspects.
* Zafar asked clarification on ccamp-pce relationship
  - Kireeti - this draft discusses ASBR on the path, if not then it's
    PCE, suggest add this to draft to clarify that this is for when
    computation is done by elements on the path.
  - JP - ok
* Adrian and Kireeti asked if this should be a WG draft? Good consensus
  in the room to be WG draft, will take it to the list.

Automesh (JP)
- Agreement to rehash work a bit to put these together.
- Now 2 drafts
- Not a new ID, no changes.
- Deployed networks using that.
- No major changes planned
* Igor - asked how to reflect constraints in a node for switching?
  - JP - we are discussing auto mesh, not node switching.
  - Igor - but how do we reflect node capabilities?
  - JP - this we do, we carry in OSPF a TLV to describe.
  - Igor - how to reflect for computation any internal constraints,
    could do via node caps advertisement.
  - JP agrees, though here just doing a discovery, doesn't think
    related as discovering members of mesh.
  - Adrian - two drafts, this is not node capability that is next one
    by JP, cut discussion said to take it to list.

JP - Routing extensions for discovery of TE node capabilities
* Adrian - on process, authors did a group job of splitting draft
  and sending to OSPF and ISIS groups, chairs will follow up with
  those groups.
* Dimitri - should for terminology call TE router?
  - JP - yes.
  - Dimitri - shouldn't be exclusive the TLV?
  - JP - yes.
* Igor - how to distinguish node capabilities?
  - Adrian - do by TLVs, need to do a draft to propose, this draft
    gives you the TLVs, then can follow-up with other drafts to
    describe function want to use it for, take discussion to list.
* JP asked that this be adopted as a WG document.
  - Adrian - Take it to the list

Extensions to GMPLS RSVP graceful restart (Lou Berger)
* Adrian - do editorial respin, let us know, and we will take to
  last call
* Any implementations?
  - Yes - two!

MRN
Requirements (Kohei Shiomoto)
Evaluation draft (JL Le Roux)
Protocol extensions (Dimitri)
* Arthi - what does virtual FA have to do with MRN,
  isn't it general?
  - Dimitri - should we have a specific doc on virtual FA for
    wider scope?
  - Arthi - did you want to scope only to MRN context?
  - Dimitri - no, just not sure if soln doc should be split.
  - Arthi - could be general - so prefer a separate doc on virtual FA.
* Zafar - we need to give a priority capability for TE.
  - Dimitri - new TLV may be needed to describe relationships of
    multiple interfaces
* Zafar - how relates to hierarchy draft?
  - Dimitri - maybe should be as applicability statement,
  - Kireeti - should do on mailing list
* Kireeti - requests to continue work, when re-charter will consider
  for WG drafts.

Routing considerations and CSPF for inter-as (Tomohiro Otani)
* JP - very useful draft, not sure (and concerned) on capability and
  scalability as depends on constraint trying to summarize.
  - Otani - ok, we need more on summarizing capability.
* Kireeti - thinks good and hopes to be a WG draft, though for now
  would request for this draft to continue work, though lets finish
  what ccamp has now and then when re-charter will make this as a
  WG doc.
* Otani - how to handle inter-as cspf constraints?
  - Kireeti - as noted before (continue work).

L2LSP (Dimitri)
* Adrian asked clarification, is this "single hop"?
  - Dimitri - multiple hops each is a LSR, will clarify this in draft
* Kireeti - ADs request a framework doc and include how it relates to
  other SDOs, max 10 pages
  - Dimitri - ok

GMPLS addressing (Richard Rabbat)
* Adrian - as this is first version, recommend continue discussion,
  re-spin draft, and then review again.
* Adrian asked for feedback on the topics, not the technical content
  initially.
* Loa - BCP is a specific type of RFC, describes what we have
  experience with not necessarily what should be (as in this draft)
* Kireeti - warns for everyone with implementations to review the
  draft to ensure direction taken by this draft is right one.
* Lou - should we wait for re-spin or now?
  - Kireeti - wait for re-spin.

L1VPN (Tomonori Takeda)
Framework draft
Applicability draft
* Alex - by next IETF will decide if it should be included in ccamp or
  as separate WG.

Control plane saturation (JL Le Roux)
* Arthi - do we really want to advertise limitations and implications?
* Kireeti - because of time, lets do on list.

Graceful shutdown (Zafar Ali)
* Kireeti - will consider for wg doc after re-charter
* JP - is this part of current charter
  - Kireeti - doesn't matter, we just can not include anymore as WG
    doc until re-charter.

Deployment-augmented (Zafar Ali)
* Arthi- comment is this a FA for router to optical domain
  - Zafar - no just TE link

GMPLS interworking (Kenji)
* Dimitri - why need to adv priority of LSP?
  - Adrian - need to ask on list.

GMPLS interworking (Kohei Shiomoto)
* Adrian - WG doc will be decided after re-charter
  - Welcome that will merge with other draft on augmented,
  - Suggest also look at Kenji's interworking draft to merge.

Cho - ARP signal
* Kireeti - request work with Dimitri on framework draft,
  - When decide direction and interactions with other SDO, may
    decide to form a design team to work on L2,
  - First we need a framework.




Envelope-to: [e-mail]
Delivery-date: Wed, 16 Mar 2005 22:19:21 +0000
Message-ID: <021c01c52a6c$fb0572c0$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Wed, 16 Mar 2005 22:09:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To quote from RFC2578
" Instances of subordinate columnar
   objects of a conceptual row augmentation are identified according to
   the INDEX clause of the base conceptual row corresponding to the
   object named in the AUGMENTS clause.  Further, instances of
   subordinate columnar objects of a conceptual row augmentation exist
   according to the same semantics as instances of subordinate columnar
   objects of the base conceptual row being augmented.  As such, note
   that creation of a base conceptual row implies the correspondent
   creation of any conceptual row augmentations"

exactly; or

- AUGMENTS is an alternative to INDEX in SMIv2
- there is a one to one correspondence between rows in the base table and rows
in the AUGMENTS table(s - can be more than one), same index columns, same index
values
- the column objects in the AUGMENTS table(s) are created when the row in the
base table is created; assuming that the agent implements those columns in the
AUGMENTS table(s) - that is a matter of conformance clauses etc.

Reading the text, I thought these conditions were met - but I was not sure;
seeing the INDEX clauses makes me think I am not understanding the text, I am
missing something:-)

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[e-mail]>
To: "Tom Petch" <[e-mail]>; <[e-mail]>
Sent: Wednesday, March 16, 2005 5:34 PM
Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt


> Hi Tom,
>
> > A minor comment; this document has
> >  false (0),
> > in several places; following RFC 2579, I think this should be
> >  false (2)
>
> Good catch. This is in the example which is why we didn't catch it by
> compiling.
>
> > A larger question,; this mib augments tables in the mpls mib (RFC3812);
> is there
> > a reason why the AUGMENTS construct was not used?
>
> This is not my area of expertise!
> I think that there are two strict augmentations and in these cases
> AUGMENTS was used.
>
> The other cases are, I believe, extensions.
>
> I *think* the difference is that an AUGMENT is always present and an
> extension is only present if used.
> (Feels like I'm on shaky ground!)
>
> Cheers,
> Adrian
>




Envelope-to: [e-mail]
Delivery-date: Wed, 16 Mar 2005 16:42:48 +0000
Message-ID: <024901c52a46$d2018740$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Tom Petch" <[e-mail]>, <[e-mail]>
Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Wed, 16 Mar 2005 16:34:06 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Tom,

> A minor comment; this document has
>  false (0),
> in several places; following RFC 2579, I think this should be
>  false (2)

Good catch. This is in the example which is why we didn't catch it by
compiling.

> A larger question,; this mib augments tables in the mpls mib (RFC3812);
is there
> a reason why the AUGMENTS construct was not used?

This is not my area of expertise!
I think that there are two strict augmentations and in these cases
AUGMENTS was used.

The other cases are, I believe, extensions.

I *think* the difference is that an AUGMENT is always present and an
extension is only present if used.
(Feels like I'm on shaky ground!)

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 16 Mar 2005 12:33:19 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52A23.B41368C0"
Subject: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Wed, 16 Mar 2005 12:28:48 -0000
Message-ID: <[e-mail]>
Thread-Topic: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Thread-Index: AcUqI7dv+wfsAdkETi+h/pzAGwMY7Q==
From: "Philip Crocker" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

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

Hi all,

I have some comments / questions on =
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.

1)  Section 3.  If out-of-band verification is in use, and the passive =
LMP node receives an out-of-band test message with a trace pattern that =
does not correlate to any trace pattern of any data link configured on =
the node, the draft does not specify what should happen and it seems to =
me that there are two possibilities.

	a) The passive node sends a TestStatusFailure message back to the =
active node to fail verification.

	b) The passive node discards the received test message.  The active =
node will continue to retransmit the test message.  Either a subsequent =
test message leads to a successful verification, or the passive node =
eventually times out the verification process of this data link.

Note that this is a new situation occurring only in the out-of-band =
verification procedure, and therefore I believe should be addressed in =
the draft (in the standard link verification procedure an incoming =
in-band test message can always, necessarily, be correlated to the data =
link it was received on). =20

In my opinion, if it is possible for a trace pattern used on a data link =
to be changed and for the change not to be noticed immediately by the =
passive node, then it is more robust if the test message is =
retransmitted as in b) above allowing multiple opportunities for the =
verification to succeed. =20

However, for other implementations this possibility may not exist and so =
option a) would be preferable.  My preference is therefore for this to =
be left as an implementation decision, but for the draft to mention that =
both options are equally valid.  Would anyone care to comment on this?

2)  Section 4.1.9 (InsertTrace Message) specifies that the use of this =
message 'assumes that the remote [node] knows the mapping between the =
local and remote interface_Ids before fulfilling such [a] request'.  =
Isn't this same assumption also true for the TraceMonitor and TraceReq =
messages defined in sections 4.1.1 and 4.1.6 respectively?  If so, I =
suggest copying the text above from section 4.1.9 to the introductory =
paragraphs of sections 4.1.1 and 4.1.6 also.

3)  Section 4.  Is there a good reason why both the TraceMonitor and =
TraceReq (and associated) messages are required?  It seems to me that =
the function of a TraceMonitor message can be replicated by using a =
TraceReq message, then comparing the observed trace pattern to the =
expected pattern.  I realize that the TraceMismatch message is allowed =
to contain information about multiple mismatches at once, and a similar =
function is not available in the TraceReport message, but is this the =
only functional difference between the two sets of messages?

Thanks,

Phil

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have some comments / questions on =
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1)&nbsp; Section 3.&nbsp; If =
out-of-band verification is in use, and the passive LMP node receives an =
out-of-band test message with a trace pattern that does not correlate to =
any trace pattern of any data link configured on the node, the draft =
does not specify what should happen and it seems to me that there are =
two possibilities.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">a) The passive node sends a =
TestStatusFailure message back to the active node to fail =
verification.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">b) The passive node discards the =
received test message.&nbsp; The active node will continue to retransmit =
the test message.&nbsp; Either a subsequent test message leads to a =
successful verification, or the passive node eventually times out the =
verification process of this data link.</FONT></P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Note that this is a new situation =
occurring only in the out-of-band verification procedure, and therefore =
I believe should be addressed in the draft (in the standard link =
verification procedure an incoming in-band test message can always, =
necessarily, be correlated to the data link it was received on).&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In my opinion, if it is possible for a =
trace pattern used on a data link to be changed and for the change not =
to be noticed immediately by the passive node, then it is more robust if =
the test message is retransmitted as in b) above allowing multiple =
opportunities for the verification to succeed.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">However, for other implementations this =
possibility may not exist and so option a) would be preferable.&nbsp; My =
preference is therefore for this to be left as an implementation =
decision, but for the draft to mention that both options are equally =
valid.&nbsp; Would anyone care to comment on this?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2)&nbsp; Section 4.1.9 (InsertTrace =
Message) specifies that the use of this message 'assumes that the remote =
[node] knows the mapping between the local and remote interface_Ids =
before fulfilling such [a] request'.&nbsp; Isn't this same assumption =
also true for the TraceMonitor and TraceReq messages defined in sections =
4.1.1 and 4.1.6 respectively?&nbsp; If so, I suggest copying the text =
above from section 4.1.9 to the introductory paragraphs of sections =
4.1.1 and 4.1.6 also.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3)&nbsp; Section 4.&nbsp; Is there a =
good reason why both the TraceMonitor and TraceReq (and associated) =
messages are required?&nbsp; It seems to me that the function of a =
TraceMonitor message can be replicated by using a TraceReq message, then =
comparing the observed trace pattern to the expected pattern.&nbsp; I =
realize that the TraceMismatch message is allowed to contain information =
about multiple mismatches at once, and a similar function is not =
available in the TraceReport message, but is this the only functional =
difference between the two sets of messages?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Phil</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C52A23.B41368C0--



Envelope-to: [e-mail]
Delivery-date: Wed, 16 Mar 2005 00:46:28 +0000
Message-ID: <01f501c529c0$198d56c0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt
Date: Wed, 16 Mar 2005 00:30:42 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E5_01C529BF.63405520"

This is a multi-part message in MIME format.

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

Hi,
I've got a couple of comments in what seems like quite a long draft.
Adrian

Abstract:
   This document describes protocol specific procedures and extensions=20
   for Generalized Multi-Protocol Label Switching (GMPLS) Resource=20
   ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to=20
   support end-to-end Label Switched Path (LSP) recovery that denotes=20
   protection and restoration.
Not sure what is meant by "denotes" in this context.
Perhaps "is used to provide" ?
=3D=3D=3D
Section 2
OLD
   In addition, the reader is assumed to be familiar with the=20
   terminology used in [RFC3945], [RFC3471], [RFC3473] and referenced=20
   as well as [TERM] and [FUNCT].=20
NEW
   In addition, the reader is assumed to be familiar with the=20
   terminology used in [RFC3945], [RFC3471], [RFC3473],
   as well as in [TERM] and [FUNCT].=20
=3D=3D=3D
Section 2
   Checklog List from revision v01.txt: =20
Please either remove this text or mark it so that the RFC editor will =
remove it.
=3D=3D=3D
Section 3
Although the second paragraph defines "end-to-end protection" I would =
like to see this pulled out into its own paragraph for emphasis, and =
also a little more clarity added to the definition. For example, it =
would appear that your four types of e2e protection are all have the =
protecting and protected LSPs disjoint in some way - this makes it =
appear that this is a property of e2e protection in general and you =
should state this if it is true.
=3D=3D=3D
Section 3 para 5
   In 1:N (N =3D< 1) protection with extra-traffic,
Hopefully you mean N >=3D 1 =20
=3D=3D=3D
Section 3 para 5
I note that you do not distinguish between 1:N and =
1:N-with-extra-traffic.
If there is a reason for this perhaps you could add a note to the text.
=3D=3D=3D
Section 3
OLD
   working one. Here, the recovery resources for the protecting LSP are=20
   pre-reserved and explicit action is required to activate (i.e.=20
NEW
   working one. Here, the recovery resources for the protecting LSP are=20
   pre-reserved but explicit action is required to activate (i.e.=20
                ^^^
=3D=3D=3D
Section 3
OLD
   requirements by allowing multiple protecting LSPs to share common=20
   link and node resources. The recovery resources are pre-reserved and=20
NEW
   requirements by allowing multiple protecting LSPs to share common=20
   link and node resources. The recovery resources are pre-reserved but
                                                                    ^^^=20
=3D=3D=3D
Section 3
   Note that in both=20
   cases, any lower priority LSP that would use the pre-reserved=20
   resources for the protecting LSP(s) MUST be preempted during the=20
   activation of the protecting LSP.=20
This sentence comes out of the blue. The whole of the paragraph up to =
then has not even mentioned extra traffic. I suggest you insert a =
paragraph break and a sentence explaining how the pre-reserved resources =
may be used to support an extra-traffic LSP...
Also, delete "would".
=3D=3D=3D
Section 3
   Full LSP re-routing (or restoration) switches normal traffic to an=20
   alternate LSP that is fully established only after working LSP=20
   failure occurs.
This text does not read well in English. In fact, the same is true of =
pre-planned. What you mean is, I think, as follows...
   Full LSP re-routing (or restoration) switches normal traffic to an=20
   alternate LSP that is not even partially established until after=20
   the working LSP failure occurs.=20
=3D=3D=3D
Section 3
   Note that crankback signaling (see [CRANK]) and LSP segment recovery=20
   are further detailed in dedicated companion documents. Also, there=20
Need to add a citation for LSP segment recovery.
=3D=3D=3D
Section 4.2
OLD
   The recovery attributes includes all the parameters that determine=20
NEW
   The recovery attributes include all the parameters that determine=20
=3D=3D=3D
Section 4.2.1
   - S (Secondary) bit: enables distinction between primary and =20
     secondary LSPs. A primary LSP is a fully established LSP for =20
     which the resource allocation has been committed at the data plane  =

     (i.e. full cross-connection has been performed). Both working and =20
     protecting LSPs can be primary LSPs. A secondary LSP is an LSP =20
I am uneasy about this definition of "primary". In [TERM] the only =
mention of "primary" is in section 2...
   Recovery typically involves the activation of a recovery (or
   alternate) LSP when a failure is encountered in the working (or
   primary) LSP.
This implies that "primary" is a synonym for "working".
Further, RFC3471 has a subtly different meaning for "secondary" in =
section 7.
   Protection Information also indicates if the LSP is a primary or
   secondary LSP.  A secondary LSP is a backup to a primary LSP.  The
   resources of a secondary LSP are not used until the primary LSP
   fails.  The resources allocated for a secondary LSP MAY be used by
   other LSPs until the primary LSP fails over to the secondary LSP.  At
   that point, any LSP that is using the resources for the secondary LSP
   MUST be preempted.
Can we please not modify the interpretation of the S-bit.
If you need to flag a new piece of information (to distinguish between =
resource allocated and not) then please introduce a new flag.
Note that the P-bit appears to be slightly orthogonal because the text =
seems to describe the *current* role of the LSP. (The S-bit in RFC3471 =
describes the role at the time the LSP is set up, I think).
=3D=3D=3D
Section 4.3
OLD
   When used for the working LSP signaling, the Association ID of the=20
NEW
   When used for signaling the working LSP, the Association ID of the=20
=3D=3D=3D
Section 4.3
OLD
   When used for the protecting LSP signaling, this field identifies=20
NEW
   When used for signaling the protecting LSP, this field identifies=20
=3D=3D=3D
Section 5
   When a failure occurs (say at node B) and is detected at end-node D,=20
   the receiver at D selects the normal traffic from the other LSP.=20
   From this perspective, 1+1 unidirectional protection can be seen as=20
   an uncoordinated protection switching mechanism acting independently=20
   at both end-points. Also, for the protected LSP under failure=20
   condition, the Path_State_Removed Flag of the ERROR_SPEC object (see=20
   [RFC3473]) SHOULD NOT be set upon PathErr message generation.=20
So, what you are saying is that in 1+1 protection the network may =
*never* know that the error is so bad that the LSP is dead, but MUST =
leave that choice to the ingress. While this is the operational practice =
in many transport networks, I don't see why you make this as strong as a =
SHOULD NOT.
=3D=3D=3D
Section 5
   Note: one should assume that both paths are SRLG disjoint otherwise,=20
   a failure would impact both working and protecting LSPs.=20
What is this supposed to tell the reader? That he should make the =
assumption or that he should ensure SRLG diversity? ;-)
Actually, I think you want to say that the quality of 1+1 protection may =
vary. Allowing link diverse, node diverse or SRLG diverse 1+1 =
protection.
(ditto section 6 and 7)
=3D=3D=3D
Section 5.1
   Since both LSPs belong to the same session, the SESSION object MUST=20
   be the same for both LSPs.=20
An undisputable conclusion drawn from an unproven premise.
Why must both LSPs belong to the same session? A one line explanation =
would start the section off nicely.
=3D=3D=3D
Section 5.1
   A new PROTECTION object is included in the Path message. This object=20
What is the implication of "new"? I guess you mean the new type defined =
in this draft.
=3D=3D=3D
Section 5.1
   A new PROTECTION object is included in the Path message. This object=20
   carries the desired end-to-end LSP Protection Type (in this case,=20
   "1+1 Unidirectional"). This LSP Protection Type value is applicable=20
   to both uni- and bi-directional LSPs.=20
This is unclear. In section 14.1 you have=20
                0x08    1+1 Unidirectional Protection =20
                0x10    1+1 Bi-directional Protection=20
=3D=3D=3D
Section 5.1
Your description of the use of the P-bit for 1+1 protection isn't clear. =
You mean to say that the P-bit indicates which LSP the ingress would =
*prefer* to be the protecting LSP if all other things are equal, but =
your text (and the description of the P-bit in sections 4.2.1 and 14) =
don't make this clear.
=3D=3D=3D
Section 6.2
   directions. This is done using the Notify message with a new Error=20
   Code indicating "Working LSP Failure (Switchover Request)". The=20
I don't see this in the IANA section, and I wonder if you also mean =
Error Value?
=3D=3D=3D
Section 6.2
   directions. This is done using the Notify message with a new Error=20
   Code indicating "Working LSP Failure (Switchover Request)". The=20
   Notify Ack message MUST be sent to confirm the reception of the=20
   Notify message (see [RFC3473], Section 4.3).   =20
I see no definition of a "Notify Ack message" in RFC3473 (in any =
section).
I am worried that you are confusing the Ack message with a new procedure =
requiring a handshake of Notify messages.
=3D=3D=3D
Section 6.2
        1. If an end-node (A or D) detects the failure of the working =20
           LSP (or a degradation of signal quality over the working =20
           LSP) or receives a Notify message including its SESSION =20
           object within the <upstream/downstream session list> (see =20
           [RFC3473]), it MUST begin receiving on the protecting LSP =20
Note that the sender descriptor or flow descriptor is also present in =
the Notify and this will considerably help resolve ambiguities and race =
conditions since it identifies the LSP.
=3D=3D=3D
Section 6.2
        1. If an end-node (A or D) detects the failure of the working =20
           LSP (or a degradation of signal quality over the working =20
           LSP) or receives a Notify message including its SESSION =20
           object within the <upstream/downstream session list> (see =20
           [RFC3473]), it MUST begin receiving on the protecting LSP =20
I don't think the receipt of a Notify message is sufficient, per se. I =
think the error code and value need to indicate a problem with the LSP.
=3D=3D=3D
Section 6.2
        1. If an end-node (A or D) detects the failure of the working =20
           LSP (or a degradation of signal quality over the working =20
           LSP) or receives a Notify message including its SESSION =20
           object within the <upstream/downstream session list> (see =20
           [RFC3473]), it MUST begin receiving on the protecting LSP =20
           and send a Notify message reliably to the other end-node (D =20
           or A, respectively).
"...send a Notify message reliably" will certainly be misunderstood.
You presumably mean "...send a Notify message including the Message_ID =
object".
=3D=3D=3D
Section 6.2
        2. Upon receipt of the switchover message, the end-node =20
           (D or A, respectively) MUST begin receiving from the =20
           protection LSP and send a (Notify) Ack message to the other =20
           end-node (A or D, respectively) using reliable message =20
           delivery (see [RFC2961]).=20
While this clarifies the use of Ack rather than Notify Ack (not sure why =
you need to include "(Notify)") it is now confused about the delivery of =
the Ack message. How do we achieve reliable delivery of an Ack message?!
=3D=3D=3D
Section 7
   Although the resources for the protecting LSP are pre-allocated,=20
   preemptable traffic may be carried end-to-end using this LSP (i.e.=20
   the protecting LSP is capable of carrying extra-traffic) with the=20
   caveat that this traffic will be preempted if the working LSP fails.=20
Do you mean that the extra traffic is carried "using this LSP" or "using =
some or all of the resources assigned to this LSP"?
=3D=3D=3D
Section 7
   Also, if extra-traffic is carried over the protecting LSP, the=20
   corresponding end-nodes may be notified of the failure in order to=20
   complete the switchover. =20
I think this is "end-nodes may need to be notified"
=3D=3D=3D
Section 7.2
   To co-ordinate the switchover between end-points, an end-to-end=20
   switchover request is needed such that the affected LSP(s) are moved=20
   to the protecting LSP.
In what way may there be more than one affected LSP moved to a single =
protecting LSP?
=3D=3D=3D
Section 7.2
   This operation may be done using a Notify message exchange with a=20
   new Error Code indicating "(Working) LSP Failure (Switchover=20
   Request)". The Notify Ack message MUST be sent to confirm the=20
   reception of the Notify message. =20
All of the same comments as for section 6.2.
Also:
- Why do you say "may be done"?
- Is this the same error code as in 6.2? (the text is slightly =
different)
=3D=3D=3D=20
Section 7.3
OLD
   provisioned protecting LSP is resource-disjoint LSP from the N=20
NEW
   provisioned protecting LSP is resource-disjoint from the N=20
=3D=3D=3D
Section 7.3
Can you highlight that the N working LSPs are all between the same pair =
of end points.
=3D=3D=3D
Section 8
OLD
   this does not mean that the corresponding resources can not used by=20
NEW
   this does not mean that the corresponding resources can not be used =
by=20
=3D=3D=3D
Section 8
   To make bandwidth pre-reserved for a protecting (but not activated)=20
   LSP, available for extra traffic this bandwidth could be included in=20
   the advertised Unreserved Bandwidth at priority lower (means=20
   numerically higher) than the Setup Priority of the protecting LSP.=20
This feels like it should be the Holding Priority. That is, the Setup =
Priority was only important for how it could displace pre-existing LSPs.
=3D=3D=3D
Section 8.3
OLD
   From [GMPLS-ARCH], the secondary LSP is setup with resource pre-
NEW
   From [RFC3945], the secondary LSP is setup with resource pre-
=3D=3D=3D
Section 9
OLD
   plane) a specific protecting LSP instantiated during the (pre-
   )provisioning phase. This requires restoration signaling along the=20
NEW
   plane) a specific protecting LSP instantiated during the (pre-)
   provisioning phase. This requires restoration signaling along the=20
=3D=3D=3D
Section 9
   resource sharing), the LSPs must have the same Session Ids, but the=20
   Session Id includes the target (egress) IP address. These addresses=20
2xs/Id/ID/
Suggest a search for "id"
=3D=3D=3D
Section 9.3
OLD
   From [GMPLS-ARCH], the secondary LSP is setup with resource pre-
NEW
   From [RFC3945], the secondary LSP is setup with resource pre-
=3D=3D=3D
Section 10
OLD
   activated. Additional condition raises from mis-connection avoidance=20
NEW
   activated. An additional condition arises from mis-connection =
avoidance=20
=3D=3D=3D
Section 10
OLD
   Note that step 1 may cause alarms to be raised for the pre-empted=20
   LSP. If alarm suppression is desired the pre-empting node MAY expand=20
   before applying step 1 act as follows.=20
NEW
   Note that step 1 may cause alarms to be raised for the pre-empted=20
   LSP. If alarm suppression is desired the pre-empting node MAY insert
   the following steps before step 1.=20
=3D=3D=3D
Section 10
   At the downstream node (with respect to the pre-empting LSP) the=20
   processing is RECOMMENDED to be as follows:=20
   =20
   1. Receive PathTear (and/or PathErr) message for the pre-empted =20
      LSP(s).=20
   =20
   2a.Release the resources associated with the LSP on the interface=20
      to the pre-empting LSP, remove any cross-connection and release =20
      all other resources associated with the pre-empted LSP.=20
   2b.Forward the PathTear (and/or PathErr) message per [RFC 3473].=20
   =20
   C. Receive the Path message for the pre-empting LSP and process as =20
      normal, forwarding it to the downstream node.=20
   =20
   D. Receive the Resv for the pre-empting LSP and process as normal,=20
      forwarding it to the upstream node.=20
Cool numbering scheme :-)
Any chance of settling on something more conventional?
=3D=3D=3D
Section 11.2
   Note: when the end-to-end LSP Protection Type is set to=20
   "Unprotected", both S and P bit MUST be set to 0 and the LSP SHOULD=20
   NOT be re-routed at the head-end node after failure occurrence. The=20
   Association_ID value MUST be set to the LSP_ID value of the signaled=20
   LSP.=20
Please explain the difference between an attempt to "re-route" and an =
attempt to "re-establish". presumably it could involve:
- a time difference
- the use of make-before-break for failed LSPs.
- the use of the ASSOCIATION object.
I would like to make sure that you are not applying "SHOULD NOT" to LSP =
re-establishment.
=3D=3D=3D
Section 12
OLD
   allocated to the LSP that was originally routed over it even after a=20
NEW
   allocated to the LSP that was originally routed over them even after =
a=20
=3D=3D=3D
Section 12
   - then, apply the reverse 1-phase APS switchover request/response =20
     (or 2-phase APS) described in Section 6.2 (or Section 7.2, =20
This is the first mention of APS
=3D=3D=3D
Section 13
I think this section is going to give us grief during IESG review :-(
Why do we need to tie this so closely with NMS etc. And why describe it =
as external?
Can't we simply describe the function by:
- dropping the first para
- in C, D and E drop "externally"
- in D and E replace "manual" with "requested"
=3D=3D=3D
Section 13 TWICE
OLD
   Recovery signaling operation is initiated externally that switches=20
NEW
   Recovery signaling is initiated externally that switches=20
=3D=3D=3D
Section 13 (A and B)
   is set to either 0x04, or 0x08 or 0x10.=20
I would prefer you to use the meanings rather than the values.
=3D=3D=3D
Section 13 (D and E)
   This, unless a fault condition exists on=20
? "This is allowed"? "This is possible"? "This is successful"?
=3D=3D=3D
Section 14
OLD
   use so that the object can be included in the Notify message to act=20
   a switchover request for 1+1 bi-directional and 1:1 protection. =20
NEW
   use so that the object can be included in the Notify message to act=20
   as a switchover request for 1+1 bi-directional and 1:1 protection. =20
=3D=3D=3D
Section 14.1
I believe we have had this discussion before.
We don't introduce reserved fields for future extensibility. We only do =
it for padding.
If you are certain that we need to extend in the future then please use =
sub-objects or TLVs.
This means that you can:
a. Remove the last four bytes of the Protection object.
b. Retain the C-Type from RFC3473
=3D=3D=3D
Section 15
   This object MUST be=20
   present in the Path message (for the pre-provisioning of the=20
   secondary protecting LSP) if and only if the LSP Protection Type=20
   value is set to "0x02".
"MUST if and only if" is not really in RFC2119.
Can we two statements. One with "MUST" and one with "MUST NOT".
=3D=3D=3D
Section 15
In the case where my protecting LSP protects only one working LSP and =
where the full path of the protecting LSP is known by the ingress =
(strict and explicit) and there is no resource sharing between the =
protected and protecting LSP, I can't see why I must include a PPRO.
In other words, PPRO is an enabler of function (as stated in section =
15.4 "The PPRO enables of sharing recovery resources between a given =
secondary protecting LSP and one or more secondary protecting LSPs if =
their corresponding primary working LSPs have mutually =
(link/node/SRLG)disjoint paths."), but that does not make its presence =
mandatory.
=3D=3D=3D
Section 15.1
   The contents of a PRIMARY_PATH_ROUTE object are a series of=20
   variable-length data items called subobjects. The subobjects are=20
   identical to those that can constitute an EXPLICIT/RECORD ROUTE=20
   object as defined in [RFC3209], [RFC3473] and [RFC3477].=20
This seems in contradiction with section 15.3
=3D=3D=3D
Section 15.4
OLD
   The PPRO enables of sharing recovery resources between a given=20
NEW
   The PPRO enables sharing of recovery resources between a given=20
=3D=3D=3D
Section 16
   The ASSOCIATION object is used to associate LSPs with each other. In=20
   the context of end-to-end LSP recovery, the association MUST only=20
   identify LSPs that support the same Tunnel ID.
Hmmm. presumably same source and destination is relatively important =
too.
=3D=3D=3D
Section 16
   The ASSOCIATION object is used to associate LSPs with each other.  =20
You already said this.
=3D=3D=3D
Section 16.1
      Association ID: 16 bits=20
   =20
        A value that when combined with Association Type and =20
        Association Source uniquely identifies an association. =20
It would be helpful to state who assigns this value.
=3D=3D=3D
Section 16.1
      Association Source: 4 or 16 bytes=20
   =20
        The IP address of the node that originated the association.=20
"The IP address"?
Question. Are two associations with the same Association ID equivalent =
if the Association Source addresses are different but identify the same =
node?
Answer (it transpires) is "no".=20
You need to make this much clearer here.
=3D=3D=3D
Section 17
Isn't Notify modified as well?
And I thought Resv was, but I may have been sleeping.
=3D=3D=3D
Section 18
This is a bit poor.
If you don't modify the "external commands" section, you'll certainly =
have to discuss security for them. After all, a forced failover can be =
pretty disruptive.
But I think you need to discuss misconnection here. In particular when =
there is mesh protection going on.
=3D=3D=3D
Section 19
The IANA section needs some gardening to make it really easy for IANA to =
implement.
- Break it up into clearer subsections.
- Make sure you have included all of the information needed in the =
registry
- Point back at the defining sections of the draft
- Only have suggested values in one place in the document
- Be consistend in using TBD or TBA in the document
=3D=3D=3D
Section 19
Should the IANA section also cover the bits in the ADMIN STATUS object?
=3D=3D=3D
Section 21
Missing references [CRANK], [RFC2205]. Suspect you need to check them =
all.
Will need to add a reference for LSP segment recovery.
=3D=3D=3D
Section 21.1
This seems a very long list of normative references. I hope you can =
split this so that most of the references are informational.
=3D=3D=3D
Section 22
You might change this to "Editors' Addresses"


------=_NextPart_000_01E5_01C529BF.63405520
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,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I've got a couple of comments in what =
seems like=20
quite a long draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Abstract:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This document describes =
protocol=20
specific procedures and extensions <BR>&nbsp;&nbsp; for Generalized=20
Multi-Protocol Label Switching (GMPLS) Resource <BR>&nbsp;&nbsp; =
ReserVation=20
Protocol - Traffic Engineering (RSVP-TE) signaling to <BR>&nbsp;&nbsp; =
support=20
end-to-end Label Switched Path (LSP) recovery that denotes =
<BR>&nbsp;&nbsp;=20
protection and restoration.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Not sure what is meant by "denotes" =
in this=20
context.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Perhaps "is used to provide" =
?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; In addition, the reader =
is assumed=20
to be familiar with the <BR>&nbsp;&nbsp; terminology used in [RFC3945],=20
[RFC3471], [RFC3473] and referenced <BR>&nbsp;&nbsp; as well as [TERM] =
and=20
[FUNCT]. <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; In addition, the reader =
is assumed=20
to be familiar with the <BR>&nbsp;&nbsp; terminology used in [RFC3945],=20
[RFC3471], [RFC3473],<BR>&nbsp;&nbsp; as well as in&nbsp;[TERM] and =
[FUNCT].=20
<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Checklog List from =
revision=20
v01.txt:&nbsp; </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Please either remove this text or =
mark it so that=20
the RFC editor will remove it.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Although the second paragraph defines =
"end-to-end=20
protection" I would like to see this pulled out into its own paragraph =
for=20
emphasis, and also a little more clarity added to the definition. For =
example,=20
it would appear that your four types of e2e protection are all have the=20
protecting and protected LSPs disjoint in some way - this makes it =
appear that=20
this is a property of e2e protection in general and you should state =
this if it=20
is true.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3 para 5</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; In 1:N (N =3D&lt; 1) =
protection with=20
extra-traffic,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Hopefully you mean N &gt;=3D 1&nbsp; =
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3 para 5</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I note that you do not distinguish =
between 1:N=20
and 1:N-with-extra-traffic.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>If there is a reason for this perhaps =
you could=20
add a note to the text.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; working one. Here, the =
recovery=20
resources for the protecting LSP are <BR>&nbsp;&nbsp; pre-reserved and =
explicit=20
action is required to activate (i.e. <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; working one. Here, the =
recovery=20
resources for the protecting LSP are <BR>&nbsp;&nbsp; pre-reserved but =
explicit=20
action is required to activate=20
(i.e.&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^^^</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV><FONT =
face=3DCourier size=3D2>
<DIV><FONT face=3DCourier size=3D2>Section 3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV>&nbsp;&nbsp; requirements by allowing multiple protecting LSPs to =
share=20
common <BR>&nbsp;&nbsp; link and node resources. The recovery resources =
are=20
pre-reserved and <BR>NEW</DIV>
<DIV>&nbsp;&nbsp; requirements by allowing multiple protecting LSPs to =
share=20
common <BR>&nbsp;&nbsp; link and node resources. The recovery resources =
are=20
pre-reserved=20
but<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;^^^=20
</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;Note that in both=20
<BR>&nbsp;&nbsp; cases, any lower priority LSP that would use the =
pre-reserved=20
<BR>&nbsp;&nbsp; resources for the protecting LSP(s) MUST be preempted =
during=20
the <BR>&nbsp;&nbsp; activation of the protecting LSP. <BR>This sentence =
comes=20
out of the blue. The whole of the paragraph up to then has not even =
mentioned=20
extra traffic. I suggest you insert a paragraph break and a sentence =
explaining=20
how the pre-reserved resources may be used to support an extra-traffic=20
LSP...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Also, delete "would".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Full LSP re-routing (or =
restoration)=20
switches normal traffic to an <BR>&nbsp;&nbsp; alternate LSP that is =
fully=20
established only after working LSP <BR>&nbsp;&nbsp; failure =
occurs.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This text does not read well in =
English. In fact,=20
the same is true of pre-planned. What you mean is, I think, as=20
follows...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Full LSP re-routing (or =
restoration)=20
switches normal traffic to an <BR>&nbsp;&nbsp; alternate LSP that is not =
even=20
partially established until after </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; the working =
LSP&nbsp;failure occurs.=20
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Note that crankback =
signaling (see=20
[CRANK]) and LSP segment recovery <BR>&nbsp;&nbsp; are further detailed =
in=20
dedicated companion documents. Also, there <BR>Need to add a citation =
for LSP=20
segment recovery.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR></FONT><FONT =
face=3DCourier size=3D2>Section=20
4.2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; </FONT><FONT =
face=3DCourier size=3D2>The=20
recovery attributes includes all the parameters that=20
determine&nbsp;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>NEW<BR>&nbsp;&nbsp; The recovery =
attributes=20
include all the parameters that determine </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.2.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; - S (Secondary) bit: =
enables=20
distinction between primary and&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; =
secondary=20
LSPs. A primary LSP is a fully established LSP for&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; which the resource allocation has been =
committed at=20
the data plane&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; (i.e. full =
cross-connection=20
has been performed). Both working and&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; =

protecting LSPs can be primary LSPs. A secondary LSP is an LSP&nbsp; =
<BR>I am=20
uneasy about this definition of "primary". In [TERM] the only mention of =

"primary" is in section 2...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Recovery typically =
involves the=20
activation of a recovery (or<BR>&nbsp;&nbsp; alternate) LSP when a =
failure is=20
encountered in the working (or<BR>&nbsp;&nbsp; primary) =
LSP.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This implies that "primary" is a =
synonym for=20
"working".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Further, RFC3471 has a subtly =
different meaning=20
for "secondary" in section 7.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Protection Information =
also=20
indicates if the LSP is a primary or<BR>&nbsp;&nbsp; secondary =
LSP.&nbsp; A=20
secondary LSP is a backup to a primary LSP.&nbsp; The<BR>&nbsp;&nbsp; =
resources=20
of a secondary LSP are not used until the primary LSP</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; fails.&nbsp; The =
resources allocated=20
for a secondary LSP MAY be used by<BR>&nbsp;&nbsp; other LSPs until the =
primary=20
LSP fails over to the secondary LSP.&nbsp; At<BR>&nbsp;&nbsp; that =
point, any=20
LSP that is using the resources for the secondary LSP<BR>&nbsp;&nbsp; =
MUST be=20
preempted.<BR>Can we please not modify the interpretation of the=20
S-bit.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>If you need to flag a new piece of =
information=20
(to distinguish between resource allocated and not) then please =
introduce a new=20
flag.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Note that the P-bit&nbsp;appears to=20
be&nbsp;slightly orthogonal because the text&nbsp;seems to&nbsp;describe =
the=20
*current* role of the LSP. (The S-bit in RFC3471 describes the role at =
the time=20
the LSP is set up, I think).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>Section 4.3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; When used for the =
working LSP=20
signaling, the Association ID of the <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; When used for signaling =
the working=20
LSP, the Association ID of the <BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; When used for the =
protecting LSP=20
signaling, this field identifies <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; When used for signaling =
the=20
protecting LSP, this field identifies <BR>=3D=3D=3D</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>Section 5</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; When a failure occurs =
(say at node=20
B) and is detected at end-node D, <BR>&nbsp;&nbsp; the receiver at D =
selects the=20
normal traffic from the other LSP. <BR>&nbsp;&nbsp; From this =
perspective, 1+1=20
unidirectional protection can be seen as <BR>&nbsp;&nbsp; an =
uncoordinated=20
protection switching mechanism acting independently <BR>&nbsp;&nbsp; at =
both=20
end-points. Also, for the protected LSP under failure <BR>&nbsp;&nbsp;=20
condition, the Path_State_Removed Flag of the ERROR_SPEC object (see=20
<BR>&nbsp;&nbsp; [RFC3473]) SHOULD NOT be set upon PathErr message =
generation.=20
<BR>So, what you are saying is that in 1+1 protection the network may =
*never*=20
know that the error is so bad that the LSP is dead, but MUST leave that =
choice=20
to the ingress. While this is the operational practice in many transport =

networks, I don't see why you make this as strong as a SHOULD=20
NOT.<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 5</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Note: one should assume =
that both=20
paths are SRLG disjoint otherwise, <BR>&nbsp;&nbsp; a failure would =
impact both=20
working and protecting LSPs. <BR>What is this supposed to tell the =
reader? That=20
he should make the assumption or that he should ensure SRLG diversity?=20
;-)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Actually, I think you want to say =
that the=20
quality of 1+1 protection may vary. Allowing link diverse, node diverse =
or SRLG=20
diverse 1+1 protection.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>(ditto section 6 and 7)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 5.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Since both LSPs belong =
to the same=20
session, the SESSION object MUST <BR>&nbsp;&nbsp; be the same for both =
LSPs.=20
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>An undisputable conclusion drawn from =
an unproven=20
premise.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Why must both LSPs belong to the same =
session? A=20
one line explanation would start the section off nicely.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 5.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; A new PROTECTION object =
is included=20
in the Path message. This object <BR>What is the implication of "new"? I =
guess=20
you mean the new type defined in this draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 5.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; A new PROTECTION object =
is included=20
in the Path message. This object <BR>&nbsp;&nbsp; carries the desired =
end-to-end=20
LSP Protection Type (in this case, <BR>&nbsp;&nbsp; "1+1 =
Unidirectional"). This=20
LSP Protection Type value is applicable <BR>&nbsp;&nbsp; to both uni- =
and=20
bi-directional LSPs. <BR>This is unclear. In section 14.1 you have =
</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
0x08&nbsp;&nbsp;&nbsp; 1+1 Unidirectional Protection&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
0x10&nbsp;&nbsp;&nbsp; 1+1 Bi-directional Protection =
<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 5.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Your description of the use of the =
P-bit for 1+1=20
protection isn't clear. You mean to say that the P-bit indicates which =
LSP the=20
ingress would *prefer* to be the protecting LSP if all other things are =
equal,=20
but your text (and the description of the P-bit in sections 4.2.1 and =
14) don't=20
make this clear.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>Section 6.2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; directions. This is done =
using the=20
Notify message with a new Error&nbsp;<BR></FONT><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp; Code indicating "Working LSP Failure (Switchover =
Request)".=20
The <BR>I don't see this in the IANA section, and I wonder if you also =
mean=20
Error Value?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 6.2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; directions. This is done =
using the=20
Notify message with a new Error <BR>&nbsp;&nbsp; Code indicating =
"Working LSP=20
Failure (Switchover Request)". The <BR>&nbsp;&nbsp; Notify Ack message =
MUST be=20
sent to confirm the reception of the <BR>&nbsp;&nbsp; Notify message =
(see=20
[RFC3473], Section 4.3).&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I see no definition of a "Notify Ack =
message" in=20
RFC3473 (in any section).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I am worried that you are confusing =
the Ack=20
message with a new procedure requiring a handshake of Notify=20
messages.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 6.2</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. If=20
an end-node (A or D) detects the failure of the working&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSP (or =
a=20
degradation of signal quality over the working&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSP) or =

receives a Notify message including its SESSION&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; object =
within=20
the &lt;upstream/downstream session list&gt; (see&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[RFC3473]), it=20
MUST begin receiving on the protecting LSP&nbsp; </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Note that the sender descriptor or =
flow=20
descriptor is also present in the Notify and this will considerably help =
resolve=20
ambiguities and race conditions since it identifies the =
LSP.<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 6.2</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. If=20
an end-node (A or D) detects the failure of the working&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSP (or =
a=20
degradation of signal quality over the working&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSP) or =

receives a Notify message including its SESSION&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; object =
within=20
the &lt;upstream/downstream session list&gt; (see&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[RFC3473]), it=20
MUST begin receiving on the protecting LSP&nbsp; <BR>I don't think the =
receipt=20
of a Notify message is sufficient, per se. I think the error code and =
value need=20
to indicate a problem with the LSP.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 6.2</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. If=20
an end-node (A or D) detects the failure of the working&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSP (or =
a=20
degradation of signal quality over the working&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSP) or =

receives a Notify message including its SESSION&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; object =
within=20
the &lt;upstream/downstream session list&gt; (see&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[RFC3473]), it=20
MUST begin receiving on the protecting LSP&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and =
send a=20
Notify message reliably to the other end-node (D&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or A,=20
respectively).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>"...send a Notify message reliably" =
will=20
certainly be misunderstood.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>You presumably mean "...send a Notify =
message=20
including the Message_ID object".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>Section 6.2</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.=20
Upon receipt of the switchover message, the end-node&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (D or =
A,=20
respectively) MUST begin receiving from the&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
protection LSP=20
and send a (Notify) Ack message to the other&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
end-node (A or=20
D, respectively) using reliable message&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
delivery (see=20
[RFC2961]). <BR>While this clarifies the use of Ack rather than Notify =
Ack (not=20
sure why you need to include "(Notify)") it is now confused about the =
delivery=20
of the Ack message. How do we achieve reliable delivery of an Ack=20
message?!</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>Section 7</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Although the resources =
for the=20
protecting LSP are pre-allocated, <BR>&nbsp;&nbsp; preemptable traffic =
may be=20
carried end-to-end using this LSP (i.e. <BR>&nbsp;&nbsp; the protecting =
LSP is=20
capable of carrying extra-traffic) with the <BR>&nbsp;&nbsp; caveat that =
this=20
traffic will be preempted if the working LSP fails. </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Do you mean that the extra traffic is =
carried=20
"using this LSP" or "using some or all of the resources assigned to this =

LSP"?<BR></FONT>=3D=3D=3D</FONT></DIV></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 7</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Also, if extra-traffic =
is carried=20
over the protecting LSP, the <BR>&nbsp;&nbsp; corresponding end-nodes =
may be=20
notified of the failure in order to <BR>&nbsp;&nbsp; complete the=20
switchover.&nbsp; <BR>I think this is "end-nodes may need to be=20
notified"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 7.2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; To co-ordinate the =
switchover=20
between end-points, an end-to-end <BR>&nbsp;&nbsp; switchover request is =
needed=20
such that the affected LSP(s) are moved <BR>&nbsp;&nbsp; to the =
protecting=20
LSP.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>In what way may there be more than =
one affected=20
LSP moved to a single protecting LSP?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 7.2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This operation may be =
done using a=20
Notify message exchange with a <BR>&nbsp;&nbsp; new Error Code =
indicating=20
"(Working) LSP Failure (Switchover <BR>&nbsp;&nbsp; Request)". The =
Notify Ack=20
message MUST be sent to confirm the <BR>&nbsp;&nbsp; reception of the =
Notify=20
message.&nbsp; <BR>All of the same comments as for section =
6.2.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Also:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>-&nbsp;Why do you say "may be =
done"?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- Is this the same error code as in =
6.2? (the=20
text is slightly different)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D&nbsp;<BR>Section =
7.3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; provisioned protecting =
LSP is=20
resource-disjoint LSP from the N <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; provisioned protecting =
LSP=20
is&nbsp;resource-disjoint&nbsp;from the N </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 7.3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Can you highlight that the N working =
LSPs are all=20
between the same pair of end points.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>Section 8</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; this does not mean that =
the=20
corresponding resources can not used by <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; this does not mean that =
the=20
corresponding resources can not be used by <BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 8</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; To make bandwidth =
pre-reserved for a=20
protecting (but not activated) <BR>&nbsp;&nbsp; LSP, available for extra =
traffic=20
this bandwidth could be included in <BR>&nbsp;&nbsp; the advertised =
Unreserved=20
Bandwidth at priority lower (means <BR>&nbsp;&nbsp; numerically higher) =
than the=20
Setup Priority of the protecting LSP. <BR>This feels like it should be =
the=20
Holding Priority. That is, the Setup Priority was only important for how =
it=20
could displace pre-existing LSPs.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 8.3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; From [GMPLS-ARCH], the =
secondary LSP=20
is setup with resource pre-<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; From [RFC3945], the =
secondary LSP is=20
setup with resource pre-<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 9</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; plane) a specific =
protecting LSP=20
instantiated during the (pre-<BR>&nbsp;&nbsp; )provisioning phase. This =
requires=20
restoration signaling along the&nbsp;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>NEW<BR>&nbsp;&nbsp; plane) a specific =
protecting=20
LSP instantiated during the (pre-)<BR>&nbsp;&nbsp; provisioning phase. =
This=20
requires restoration signaling along the <BR></FONT><FONT face=3DCourier =

size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 9</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; resource sharing), the =
LSPs must=20
have the same Session Ids, but the <BR>&nbsp;&nbsp; Session Id includes =
the=20
target (egress) IP address. These addresses <BR>2xs/Id/ID/</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Suggest a search for =
"id"</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 9.3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; From [GMPLS-ARCH], the =
secondary LSP=20
is setup with resource pre-<BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; From [RFC3945], the =
secondary LSP is=20
setup with resource pre-<BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 10</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; activated. Additional =
condition=20
raises from mis-connection avoidance <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; activated. An additional =
condition=20
arises from mis-connection avoidance <BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 10</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Note that step 1 may =
cause alarms to=20
be raised for the pre-empted <BR>&nbsp;&nbsp; LSP. If alarm suppression =
is=20
desired the pre-empting node MAY expand <BR>&nbsp;&nbsp; before applying =
step 1=20
act as follows. <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Note that step 1 may =
cause alarms to=20
be raised for the pre-empted <BR>&nbsp;&nbsp; LSP. If alarm suppression =
is=20
desired the pre-empting node MAY&nbsp;insert</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; the following steps =
before&nbsp;step=20
1. <BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 10</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; At the downstream node =
(with respect=20
to the pre-empting LSP) the <BR>&nbsp;&nbsp; processing is RECOMMENDED =
to be as=20
follows: <BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; 1. Receive PathTear =
(and/or=20
PathErr) message for the pre-empted&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
LSP(s). <BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; 2a.Release the resources =

associated with the LSP on the interface =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to=20
the pre-empting LSP, remove any cross-connection and release&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all other resources associated with =
the=20
pre-empted LSP. <BR>&nbsp;&nbsp; 2b.Forward the PathTear (and/or =
PathErr)=20
message per [RFC 3473]. <BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; C. =
Receive the=20
Path message for the pre-empting LSP and process as&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; normal, forwarding it to the =
downstream node.=20
<BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; D. Receive the Resv for the =
pre-empting=20
LSP and process as normal, <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; forwarding =
it to=20
the upstream node. <BR>Cool numbering scheme :-)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Any chance of settling on something =
more=20
conventional?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 11.2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Note: when the =
end-to-end LSP=20
Protection Type is set to <BR>&nbsp;&nbsp; "Unprotected", both S and P =
bit MUST=20
be set to 0 and the LSP SHOULD <BR>&nbsp;&nbsp; NOT be re-routed at the =
head-end=20
node after failure occurrence. The <BR>&nbsp;&nbsp; Association_ID value =
MUST be=20
set to the LSP_ID value of the signaled <BR>&nbsp;&nbsp; LSP. <BR>Please =
explain=20
the difference between an attempt to "re-route" and an attempt to=20
"re-establish". presumably it could involve:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- a time difference</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- the use of make-before-break for =
failed=20
LSPs.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- the use of the ASSOCIATION =
object.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I would like to make sure that you =
are not=20
applying "SHOULD NOT" to LSP re-establishment.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 12</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; allocated to the LSP =
that was=20
originally routed over it even after a <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; allocated to the LSP =
that was=20
originally routed over them even after a <BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 12</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; - then, apply the =
reverse 1-phase=20
APS switchover request/response&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; (or =
2-phase=20
APS) described in Section 6.2 (or Section 7.2,&nbsp; <BR>This is the =
first=20
mention of APS</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 13</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I think this section is going to give =
us grief=20
during IESG review :-(</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Why do we need to tie this so closely =
with NMS=20
etc. And why describe it as external?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Can't we simply describe the function =

by:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- dropping the first =
para</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- in C, D and E&nbsp;drop=20
"externally"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- in D and E replace "manual" with=20
"requested"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 13 TWICE</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Recovery signaling =
operation is=20
initiated externally that switches </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Recovery =
signaling&nbsp;is initiated=20
externally that switches </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 13 (A and B)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; is set to either 0x04, =
or 0x08 or=20
0x10. <BR>I would prefer you to use the meanings rather than the=20
values.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 13 (D and E)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This, unless a fault =
condition=20
exists on </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>? "This is allowed"? "This is =
possible"? "This is=20
successful"?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 14</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; use so that the object =
can be=20
included in the Notify message to act <BR>&nbsp;&nbsp; a switchover =
request for=20
1+1 bi-directional and 1:1 protection.&nbsp; <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; use so that the object =
can be=20
included in the Notify message to act <BR>&nbsp;&nbsp; as a switchover =
request=20
for 1+1 bi-directional and 1:1 protection.&nbsp; <BR></FONT><FONT =
face=3DCourier=20
size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 14.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I believe we have had this discussion =

before.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>We don't introduce reserved fields =
for future=20
extensibility. We only do it for padding.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>If you are certain that we need to =
extend in the=20
future then please use sub-objects or TLVs.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This means that you can:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>a. Remove the last four bytes of the =
Protection=20
object.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>b. Retain the C-Type from =
RFC3473</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 15</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This object MUST be =
<BR>&nbsp;&nbsp;=20
present in the Path message (for the pre-provisioning of the =
<BR>&nbsp;&nbsp;=20
secondary protecting LSP) if and only if the LSP Protection Type=20
<BR>&nbsp;&nbsp; value is set to "0x02".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>"MUST if and only if" is not really =
in=20
RFC2119.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Can we two statements. One with =
"MUST" and one=20
with "MUST NOT".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 15</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>In the case where my protecting LSP =
protects only=20
one working LSP and where the full path of the protecting LSP is known =
by the=20
ingress (strict and explicit) and there is no resource sharing between =
the=20
protected and protecting LSP, I can't see why I must include a=20
PPRO.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>In other words, PPRO is an enabler of =
function=20
(as stated in section 15.4 "The PPRO enables of sharing recovery =
resources=20
between a given&nbsp;secondary protecting LSP and one or more secondary=20
protecting LSPs&nbsp;if their corresponding primary working LSPs have=20
mutually&nbsp;(link/node/SRLG)disjoint paths."), but that does not make =
its=20
presence mandatory.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 15.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The contents of a =
PRIMARY_PATH_ROUTE=20
object are a series of <BR>&nbsp;&nbsp; variable-length data items =
called=20
subobjects. The subobjects are <BR>&nbsp;&nbsp; identical to those that =
can=20
constitute an EXPLICIT/RECORD ROUTE <BR>&nbsp;&nbsp; object as defined =
in=20
[RFC3209], [RFC3473] and [RFC3477]. <BR>This seems in contradiction with =
section=20
15.3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 15.4</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OLD</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The PPRO enables of =
sharing recovery=20
resources between a given <BR>NEW</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The PPRO =
enables&nbsp;sharing of=20
recovery resources between a given <BR>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 16</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The ASSOCIATION object =
is used to=20
associate LSPs with each other. In <BR>&nbsp;&nbsp; the context of =
end-to-end=20
LSP recovery, the association MUST only <BR>&nbsp;&nbsp; identify LSPs =
that=20
support the same Tunnel ID.<BR>Hmmm. presumably same source and =
destination is=20
relatively important too.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 16</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The ASSOCIATION object =
is used to=20
associate LSPs with each other.&nbsp;&nbsp; <BR>You already said=20
this.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 16.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Association ID: 16=20
bits <BR>&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A=20
value that when combined with Association Type and&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Association Source =
uniquely=20
identifies an association.&nbsp; <BR>It would be helpful to state who =
assigns=20
this value.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 16.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Association=20
Source: 4 or 16 bytes <BR>&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The IP address of the =
node that=20
originated the association. <BR>"The IP address"?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Question. Are two associations with =
the same=20
Association ID equivalent if the Association Source addresses are =
different but=20
identify the same node?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Answer (it transpires) is "no". =
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>You need to make this much clearer=20
here.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 17</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Isn't Notify modified as =
well?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>And I thought Resv was, but I may =
have been=20
sleeping.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>Section 18</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This is a bit poor.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>If you don't modify the "external =
commands"=20
section, you'll certainly have to discuss security for them. After all, =
a forced=20
failover can be pretty disruptive.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>But I think you need to discuss =
misconnection=20
here. In particular when there is mesh protection going on.</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 19</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>The IANA section needs some gardening =
to make it=20
really easy for IANA to implement.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- Break it up into clearer=20
subsections.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- Make sure you have included all of =
the=20
information needed in the registry</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- Point back at the defining sections =
of the=20
draft</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- Only have suggested values in one =
place in the=20
document</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- Be consistend in using TBD or TBA =
in the=20
document</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 19</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Should the IANA section also cover =
the bits in=20
the ADMIN STATUS object?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 21</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Missing references [CRANK], =
[RFC2205]. Suspect=20
you need to check them all.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Will need to add a reference for LSP =
segment=20
recovery.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 21.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This seems a very long list of =
normative=20
references. I hope you can split this so that most of the references are =

informational.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 22</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>You might change this to "Editors'=20
Addresses"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_01E5_01C529BF.63405520--




Envelope-to: [e-mail]
Delivery-date: Tue, 15 Mar 2005 18:59:59 +0000
Message-ID: <[e-mail]>
From: "Stephen Shew" <[e-mail]>
To: [e-mail]
Subject: RE: ASON Lexicography
Date: Tue, 15 Mar 2005 13:58:46 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52990.E2C88F1F"

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_01C52990.E2C88F1F
Content-Type: text/plain

I support this becoming a WG draft.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Kireeti Kompella
> Sent: Thursday, March 10, 2005 15:48
> To: [e-mail]
> Subject: ASON Lexicography
> 
> 
> Dear CCAMP,
> 
> In our meeting this week we heard about 
> draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
> 
> There is some more discussion to be done on the content of 
> this draft but the chairs and the meeting thought that the 
> work is a very important part of CCAMP's job.
> 
> Please indicate your opinion on whether this draft should be 
> made a working draft document by March 20, 2005.
> 
> Thanks,
> Kireeti.
> -------
> 
> 
> 

------_=_NextPart_001_01C52990.E2C88F1F
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>RE: ASON Lexicography</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I support this becoming a WG draft.</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: [e-mail] </FONT>
<BR><FONT SIZE=2>&gt; [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>] On Behalf Of Kireeti Kompella</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, March 10, 2005 15:48</FONT>
<BR><FONT SIZE=2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: ASON Lexicography</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dear CCAMP,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In our meeting this week we heard about </FONT>
<BR><FONT SIZE=2>&gt; draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; There is some more discussion to be done on the content of </FONT>
<BR><FONT SIZE=2>&gt; this draft but the chairs and the meeting thought that the </FONT>
<BR><FONT SIZE=2>&gt; work is a very important part of CCAMP's job.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Please indicate your opinion on whether this draft should be </FONT>
<BR><FONT SIZE=2>&gt; made a working draft document by March 20, 2005.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; Kireeti.</FONT>
<BR><FONT SIZE=2>&gt; -------</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C52990.E2C88F1F--



Envelope-to: [e-mail]
Delivery-date: Tue, 15 Mar 2005 14:53:09 +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: ASON Lexicography
Date: Tue, 15 Mar 2005 08:53:02 -0600
Message-ID: <[e-mail]>
Thread-Topic: ASON Lexicography
Thread-Index: AcUlssurnnG1sm0fQtyjKS8N8axp5gDu9VIg
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>

Yes-
Deborah=20




Envelope-to: [e-mail]
Delivery-date: Tue, 15 Mar 2005 14:51:24 +0000
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4A35979@zrtphxm2>
From: "Don Fedyk" <[e-mail]>
To: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: RE: ASON Lexicography
Date: Tue, 15 Mar 2005 09:48:34 -0500

Hi Kireeti

Yes Valuable. It should be a WG draft. 

Don 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Kireeti Kompella
> Sent: Thursday, March 10, 2005 3:48 PM
> To: [e-mail]
> Subject: ASON Lexicography
> 
> 
> Dear CCAMP,
> 
> In our meeting this week we heard about 
> draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
> 
> There is some more discussion to be done on the content of 
> this draft but the chairs and the meeting thought that the 
> work is a very important part of CCAMP's job.
> 
> Please indicate your opinion on whether this draft should be 
> made a working draft document by March 20, 2005.
> 
> Thanks,
> Kireeti.
> -------
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 15 Mar 2005 12:34:40 +0000
Message-ID: <031301c52952$85dae720$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Tue, 15 Mar 2005 12:29:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

A minor comment; this document has
 false (0),
in several places; following RFC 2579, I think this should be
 false (2)

A larger question,; this mib augments tables in the mpls mib (RFC3812); is there
a reason why the AUGMENTS construct was not used?

Tom Petch




Envelope-to: [e-mail]
Delivery-date: Tue, 15 Mar 2005 12:06:02 +0000
Message-Id: <[e-mail]>
Date: Tue, 15 Mar 2005 21:07:18 +0900
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
From: "[e-mail]" <[e-mail]>
Subject: RE: ASON Lexicography
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

I suppot it too.


Ichiro Inoue




Envelope-to: [e-mail]
Delivery-date: Tue, 15 Mar 2005 12:02:53 +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: ASON Lexicography
Date: Tue, 15 Mar 2005 06:01:20 -0600
Message-ID: <[e-mail]>
Thread-Topic: ASON Lexicography
Thread-Index: AcUlssvSvweURWJyQ4uCzvl6ocGwkwDo4aRA
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>

> Please indicate your opinion on whether this draft should be
> made a working draft document by March 20, 2005.

Yes.

Thanks,
Jerry





Envelope-to: [e-mail]
Delivery-date: Tue, 15 Mar 2005 10:00:42 +0000
Message-ID: <017601c52945$d7aeda50$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Tom Petch" <[e-mail]>, <[e-mail]>
Subject: Re: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt
Date: Tue, 15 Mar 2005 09:53:10 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Good man, Tom.

Thanks.
Adrian
----- Original Message ----- 
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Monday, March 14, 2005 2:19 PM
Subject: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt


> I find the IANA Considerations section less than clear.  I suggest that
you
> differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB
>
> I would also reword it slightly as follows.
>
> **   MPLS and GMPLS related standards track MIB modules are rooted under
the
>    mplsStdMIB subtree.
>
>    One of the MIB modules contained in this document extends tables
>    contained in MPLS MIB modules.
>
> **  The two MIB modules contained in this document, like that in
> GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB
subtree.
>
> **   New assignments in the mplsStdMIB subtree can only be made via a
Standards
> Action as specified   in [RFC2434].
>
> 11.1. IANA Considerations for GMPLS-LSR-STD-MIB
>
>    The IANA is requested to assign { mplsStdMIB xx } to the
>    GMPLS-LSR-STD-MIB module specified in this document.
>
> 11.2. IANA Considerations for GMPLS-LABEL-STD-MIB
>
> ** The IANA is requested to assign { mplsStdMIB yy } to the
>    GMPLS-LABEL-STD-MIB module specified in this document.
>
>
> Tom Petch
>
> draft-ietf-ccamp-gmpls-te-mib-08.txt
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 15 Mar 2005 05:35:04 +0000
Message-ID: <[e-mail]>
Date: Tue, 15 Mar 2005 14:34:01 +0900
From: Kohei Shiomoto <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail]
Subject: Re: ASON Lexicography
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes, it should be a WG draft.
--
Kohei Shiomoto

Kireeti Kompella wrote:

> Dear CCAMP,
> 
> In our meeting this week we heard about
> draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
> 
> There is some more discussion to be done on the content of this draft
> but the chairs and the meeting thought that the work is a very
> important part of CCAMP's job.
> 
> Please indicate your opinion on whether this draft should be made a
> working draft document by March 20, 2005.
> 
> Thanks,
> Kireeti.
> -------
> 
> 
> 

-- 
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone]    Fax [phone]





Envelope-to: [e-mail]
Delivery-date: Tue, 15 Mar 2005 03:15:08 +0000
Date: Tue, 15 Mar 2005 11:10:13 +0800
From: Amit 70405 <[e-mail]>
Subject: Query about recovery hierarchies
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi All,
   I want to clarify some things about hiearchical classification of recovery mechanisms.
   In draft-ietf-ccamp-gmpls-recovery-analysis-04, there are two hierarchies being defined.
   I have below understanding of these hierarchies.
   Plz let me know if this correct.

   Horizontal & Vertical recovery hierachy are the hierarchies.
   Horizontal hierachy basically is about control plane recovery mechanism.
   This includes link, segment and e2e recovery mechanisms.

   Whereas Vertical Hierarchy is about utilising recovery mechanisms at different network layers.
   Suppose for e.g: MSP protection is supported at Layer 1.
   And control plane supports link, segmnent & e2e supports.
   Than the layer 1 & Control plane mechanisms should be independant of each other.

   Is this what the Recovery Hierarchy means?
   Plz correct me if I am wrong.
   Thanks in advance.
Regards,
Amit.





Envelope-to: [e-mail]
Delivery-date: Mon, 14 Mar 2005 15:26:54 +0000
Message-ID: <025a01c528a0$fc6ff040$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt
Date: Mon, 14 Mar 2005 15:19:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I find the IANA Considerations section less than clear.  I suggest that you
differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB

I would also reword it slightly as follows.

**   MPLS and GMPLS related standards track MIB modules are rooted under the
   mplsStdMIB subtree.

   One of the MIB modules contained in this document extends tables
   contained in MPLS MIB modules.

**  The two MIB modules contained in this document, like that in
GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB subtree.

**   New assignments in the mplsStdMIB subtree can only be made via a Standards
Action as specified   in [RFC2434].

11.1. IANA Considerations for GMPLS-LSR-STD-MIB

   The IANA is requested to assign { mplsStdMIB xx } to the
   GMPLS-LSR-STD-MIB module specified in this document.

11.2. IANA Considerations for GMPLS-LABEL-STD-MIB

** The IANA is requested to assign { mplsStdMIB yy } to the
   GMPLS-LABEL-STD-MIB module specified in this document.


Tom Petch

draft-ietf-ccamp-gmpls-te-mib-08.txt




Envelope-to: [e-mail]
Delivery-date: Sun, 13 Mar 2005 00:09:58 +0000
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
From: JP Vasseur <[e-mail]>
Subject: Re: ASON Lexicography
Date: Sat, 12 Mar 2005 11:04:49 -0500
To: Kireeti Kompella <[e-mail]>

in favor.

JP.

On Mar 10, 2005, at 3:48 PM, Kireeti Kompella wrote:

> Dear CCAMP,
>
> In our meeting this week we heard about
> draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
>
> There is some more discussion to be done on the content of this draft
> but the chairs and the meeting thought that the work is a very
> important part of CCAMP's job.
>
> Please indicate your opinion on whether this draft should be made a
> working draft document by March 20, 2005.
>
> Thanks,
> Kireeti.
> -------
>



Envelope-to: [e-mail]
Delivery-date: Sat, 12 Mar 2005 16:32:21 +0000
Message-ID: <[e-mail]>
Date: Sat, 12 Mar 2005 11:31:51 -0500
From: Scott W Brim <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: Re: ASON Lexicography
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 3/12/2005 11:26, Adrian Farrel allegedly wrote:
> Hi Scott,
> 
> Thanks for you input. Obviously we have been discussing the content of the
> draft with people in Q14/15 and in CCAMP and have received quite a lot of
> input. We plan to bring out a new version as soon as we can cut the
> bandwidth.

Looking forward to it.

> In the mean time, are there specific terms that you have an issue with, or
> is it a matter of style.

Concepts, as you saw in my exchange a month ago.  I'll wait for the
new version.

Thanks ... Scott



Envelope-to: [e-mail]
Delivery-date: Sat, 12 Mar 2005 16:27:10 +0000
Message-ID: <004c01c5271f$65f52040$09cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Last call on protection signaling drafts
Date: Sat, 12 Mar 2005 15:59:33 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This email begins a two week working group last call on

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt

Last call will end on Sunday 27th March at 12 noon GMT.

Please send you comments to the list. The chairs can provide an
annonymizing function if you require.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 12 Mar 2005 16:27:03 +0000
Message-ID: <007b01c52720$4d931a10$09cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Scott W Brim" <[e-mail]>, "Kireeti Kompella" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: ASON Lexicography
Date: Sat, 12 Mar 2005 16:26:43 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Scott,

Thanks for you input. Obviously we have been discussing the content of the
draft with people in Q14/15 and in CCAMP and have received quite a lot of
input. We plan to bring out a new version as soon as we can cut the
bandwidth.

In the mean time, are there specific terms that you have an issue with, or
is it a matter of style.

Thanks,
Adrian
----- Original Message ----- 
From: "Scott W Brim" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, March 11, 2005 1:45 AM
Subject: Re: ASON Lexicography


> On Thu, Mar 10, 2005 12:48:29PM -0800, Kireeti Kompella allegedly wrote:
> > Dear CCAMP,
> >
> > In our meeting this week we heard about
> > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
> >
> > There is some more discussion to be done on the content of this draft
> > but the chairs and the meeting thought that the work is a very
> > important part of CCAMP's job.
> >
> > Please indicate your opinion on whether this draft should be made a
> > working draft document by March 20, 2005.
>
> Yes it's a good goal, but the draft is going to need a large amount of
> work.
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 11 Mar 2005 09:41:45 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : ASON Lexicography
Date: Fri, 11 Mar 2005 10:39:33 +0100
Message-ID: <[e-mail]>
Thread-Topic: ASON Lexicography
Thread-Index: AcUlszjabAotRAeTTiSrYKXLl/r2NgAatbNQ
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>

Hi,

This is a highly useful draft.
It should become a WG ID.

Regards,

JL

>-----Message d'origine-----
>De : [e-mail]=20
>[mailto:[e-mail]] De la part de Kireeti Kompella
>Envoy=E9 : jeudi 10 mars 2005 21:48
>=C0 : [e-mail]
>Objet : ASON Lexicography
>
>
>Dear CCAMP,
>
>In our meeting this week we heard about=20
>draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
>
>There is some more discussion to be done on the content of=20
>this draft but the chairs and the meeting thought that the=20
>work is a very important part of CCAMP's job.
>
>Please indicate your opinion on whether this draft should be=20
>made a working draft document by March 20, 2005.
>
>Thanks,
>Kireeti.
>-------
>
>



Envelope-to: [e-mail]
Delivery-date: Fri, 11 Mar 2005 01:48:34 +0000
Date: Thu, 10 Mar 2005 20:45:46 -0500
From: Scott W Brim <[e-mail]>
To: Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Subject: Re: ASON Lexicography
Message-ID: <20050311014546.GA3896@sbrim-w2k02>
Mail-Followup-To: Scott W Brim <[e-mail]>, Kireeti Kompella <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

On Thu, Mar 10, 2005 12:48:29PM -0800, Kireeti Kompella allegedly wrote:
> Dear CCAMP,
> 
> In our meeting this week we heard about
> draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
> 
> There is some more discussion to be done on the content of this draft
> but the chairs and the meeting thought that the work is a very
> important part of CCAMP's job.
> 
> Please indicate your opinion on whether this draft should be made a
> working draft document by March 20, 2005.

Yes it's a good goal, but the draft is going to need a large amount of
work.



Envelope-to: [e-mail]
Delivery-date: Thu, 10 Mar 2005 21:21:04 +0000
Message-Id: <[e-mail]>
From: "Zafar Ali" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: RE: ASON Lexicography
Date: Thu, 10 Mar 2005 16:20:37 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcUltOjMaYubLmzAR8SZWOU+gd66FAAAgozQ

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Kireeti Kompella
> Sent: Thursday, March 10, 2005 3:48 PM
> To: [e-mail]
> Subject: ASON Lexicography
> 
> Dear CCAMP,
> 
> In our meeting this week we heard about
> draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
> 
> There is some more discussion to be done on the content of 
> this draft but the chairs and the meeting thought that the 
> work is a very important part of CCAMP's job.
> 
> Please indicate your opinion on whether this draft should be 
> made a working draft document by March 20, 2005.

In Favor. 

> 
> Thanks,
> Kireeti.
> -------
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 10 Mar 2005 20:49:50 +0000
Date: Thu, 10 Mar 2005 12:48:29 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: ASON Lexicography
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dear CCAMP,

In our meeting this week we heard about
draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt

There is some more discussion to be done on the content of this draft
but the chairs and the meeting thought that the work is a very
important part of CCAMP's job.

Please indicate your opinion on whether this draft should be made a
working draft document by March 20, 2005.

Thanks,
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Thu, 10 Mar 2005 06:17:33 +0000
Message-Id: <[e-mail]>
Date: Thu, 10 Mar 2005 15:14:17 +0900
To: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
From: Atsushi Iwata <[e-mail]>
Subject: RE: Liaison from ITU-T Q14/15 on crankback
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>, "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Kireeti Kompella" <[e-mail]>, "Scott Bradner" <[e-mail]>, "Scott W Brim" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Adrian

I also agree with this.

Thanks.

At 04:40 05/03/10, Ash, Gerald R \(Jerry\), ALABS wrote:
>Adrian,
>
>> However, I propose that we should respond asking to be 
>> involved in the review of the proposed additions of
>> crankback function to the referenced recommendations
>> before that material is consented (last-called) by the
>> ITU-T. This would allow us to correct any
>> misunderstandings about our draft.
>>
>> Please comment on this proposal on the mail list.
>
>Definitely agree.
>
>Thanks,
>Jerry


*--------------------------------------------------------*
Atsushi Iwata, Ph.D. / Senior Manager
System Platforms Research Labs, NEC Corporation
1753 Shimonumabe Nakahara-ku, Kawasaki, 211-8666, Japan
TEL: [phone] (Direct), Fax: [phone] (Direct)
NEC-internal TEL: [phone], NEC-internal FAX: [phone]
NEC-mail: 8-22-60440,  E-mail: [e-mail]







Envelope-to: [e-mail]
Delivery-date: Wed, 09 Mar 2005 23:05:36 +0000
Message-ID: <040a01c524fc$3f4656a0$a4858182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Jean Philippe Vasseur'" <[e-mail]>
Subject: Slides and agenda updated
Date: Wed, 9 Mar 2005 23:00:54 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I've uploaded all of the slides to http://www.olddog.co.uk/ccamp.htm
except for JP's slides on draft-vasseur-ccamp-automesh-00.txt which are
still giving my copy of PowerPoint significant indigestion.

JP, can you check that you can send me a copy saved with all PowerPoint
options deleted?

Thanks
Adrian





Envelope-to: [e-mail]
Delivery-date: Wed, 09 Mar 2005 19:40:58 +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: Liaison from ITU-T Q14/15 on crankback
Date: Wed, 9 Mar 2005 13:40:07 -0600
Message-ID: <[e-mail]>
Thread-Topic: Liaison from ITU-T Q14/15 on crankback
Thread-Index: AcUk1zNT05BSpbiyTOigN342BKTmjwACE/HA
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Kireeti Kompella" <[e-mail]>, "Scott Bradner" <[e-mail]>, "Scott W Brim" <[e-mail]>

Adrian,

> However, I propose that we should respond asking to be=20
> involved in the review of the proposed additions of
> crankback function to the referenced recommendations
> before that material is consented (last-called) by the
> ITU-T. This would allow us to correct any
> misunderstandings about our draft.
>
> Please comment on this proposal on the mail list.

Definitely agree.

Thanks,
Jerry



Envelope-to: [e-mail]
Delivery-date: Wed, 09 Mar 2005 18:38:16 +0000
Message-ID: <037e01c524d7$0a7a8f60$a4858182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Scott Bradner" <[e-mail]>, "Scott W Brim" <[e-mail]>
Subject: Liaison from ITU-T Q14/15 on Transport use of LMP
Date: Wed, 9 Mar 2005 18:37:00 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0379_01C524D6.FB0E0B10"

This is a multi-part message in MIME format.

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

Hi,

This is the second of the two liaisons form an ITU-T meeting held in =
January that arrived today.
It is an informational liaison and no action is required.

However, the liaison suggests that two items are considered within the =
Transport LMP draft. I would appreciate it if the editor and authors of =
that draft sent some thoughts on this to the ccamp list. I can then =
judge consensus on these thoughts and respond to the liaison as =
appropriate.

Thanks,
Adrian

----

The content of the liaison is as follows:

Subject: Liaison Statement to IETF CCAMP WG on the Comparison of LMP and =
ASON Discovery
To: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs
From: Alex Zinin and Bill Fenner, IETF Routing Area Directors
        Scott Bradner, IETF liaison to ITU-T

Thank you for your response to our liaison on this topic.  As noted in =
your liaison some experts from the IETF were able to attend the Q14/15 =
meeting.  As a result of the discussion of terminology we have the =
following observations that we suggest should be incorporated into =
draft-ietf-ccamp-transport-lmp-00.txt to provide some additional context =
that will aid the members of the IETF in understanding the terminology =
used by the ITU-T. =20

In your liaison you state that an SNPP link could easily be mapped to a =
TE link.  However, discussion at the meeting revealed some subtle but =
important differences:

- The SNPP link construct is defined to support hierarchical =
containment.
  However, since the IETF has not yet addressed hierarchical routing the
  current description of a TE link does not (explicitly) include the=20
  notion of hierarchical containment.

- In the ITU the properties of a node are described explicitly in terms =
of=20
  adaptation/termination functions and the binding of these functions to =

  subnetworks (within the node) and links (which are attached to the =
node).
  In the IETF the capabilities and properties of a node are inferred =
from=20
  the description of the properties of the link ends that terminate on =
node.
=20
An electronic copy of this liaison statement can be found at =
ftp://sg15opticalt:[e-mail]/tsg15opticaltransport/COMMUNICAT=
IONS/index.html
------=_NextPart_000_0379_01C524D6.FB0E0B10
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 bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3DCourier size=3D2>Hi,<BR><BR>This is the second of the =
two liaisons=20
form an ITU-T meeting held in January that arrived today.<BR>It is an=20
informational liaison and no action is required.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>However, the liaison suggests that =
two items are=20
considered within the Transport LMP draft. I would appreciate it if the =
editor=20
and authors of that draft sent some thoughts on this to the ccamp list. =
I can=20
then judge consensus on these thoughts and respond to the liaison as=20
appropriate.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</DIV>
<DIV>&nbsp;</DIV>
<DIV>----<BR><BR>The content of the liaison is as =
follows:<BR><BR>Subject:=20
Liaison Statement to IETF CCAMP WG on the Comparison of LMP and ASON=20
Discovery<BR>To: Adrian Farrel and Kireeti Kompella, IETF CCAMP=20
co-chairs<BR>From: Alex Zinin and Bill Fenner, IETF Routing Area=20
Directors<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Scott Bradner, =
IETF=20
liaison to ITU-T<BR><BR>Thank you for your response to our liaison on =
this=20
topic.&nbsp; As noted in your liaison some experts from the IETF were =
able to=20
attend the Q14/15 meeting.&nbsp; As a result of the discussion of =
terminology we=20
have the following observations that we suggest should be incorporated =
into=20
draft-ietf-ccamp-transport-lmp-00.txt to provide some additional context =
that=20
will aid the members of the IETF in understanding the terminology used =
by the=20
ITU-T.&nbsp; </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT><BR><FONT face=3DCourier =
size=3D2>In your=20
liaison you state that an SNPP link could easily be mapped to a TE =
link.&nbsp;=20
However, discussion at the meeting revealed some subtle but important=20
differences:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT><BR><FONT face=3DCourier =
size=3D2>- The SNPP=20
link construct is defined to support hierarchical =
containment.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; However, since the IETF has =
not yet=20
addressed hierarchical routing the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;current description of a =
TE link does=20
not (explicitly) include the </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;notion of hierarchical=20
containment.</FONT></DIV><FONT face=3DCourier size=3D2>
<DIV><BR>- In the ITU the properties of a node are described explicitly =
in terms=20
of </DIV>
<DIV>&nbsp; adaptation/termination functions and the binding of these =
functions=20
to </DIV>
<DIV>&nbsp; subnetworks (within the node) and links (which are attached =
to the=20
node).</DIV>
<DIV>&nbsp; In the IETF the capabilities and properties of a node are =
inferred=20
from </DIV>
<DIV>&nbsp; the description of the properties of the link ends that =
terminate on=20
node.<BR>&nbsp;<BR>An electronic copy of this liaison statement can be =
found at=20
ftp://sg15opticalt:[e-mail]/tsg15opticaltransport/COMMUNICAT=
IONS/index.html</FONT></DIV></BODY></HTML>

------=_NextPart_000_0379_01C524D6.FB0E0B10--




Envelope-to: [e-mail]
Delivery-date: Wed, 09 Mar 2005 18:38:08 +0000
Message-ID: <037801c524d6$39035c50$a4858182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Scott Bradner" <[e-mail]>, "Scott W Brim" <[e-mail]>
Subject: Liaison from ITU-T Q14/15 on crankback
Date: Wed, 9 Mar 2005 18:28:08 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

This is the first of the two liaisons form an ITU-T meeting held in
January that arrived today.
It is an informational liaison and no action is required.

However, I propose that we should respond asking to be involved in the
review of the proposed additions of crankback function to the referenced
recommendations before that material is consented (last-called) by the
ITU-T. This would allow us to correct any misunderstandings about our
draft.

Please comment on this proposal on the mail list.

Thanks,
Adrian
====

The content of this liaison is as follows:

Subject: Liaison Statement to IETF CCAMP WG on Crankback in GMPLS Systems
To: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs
Cc: Alex Zinin and Bill Fenner, IETF Routing Area Directors
     Scott Bradner, IETF liaison to ITU-T

Thank you for your response to our liaison regarding crankback as
described in <draft-ietf-ccamp-crankback-03>.
Q14/15 appreciates the clarifications and will use this to develop
protocol requirements for the next revision of G.7713 ("Distributed call
and connection management").  In particular, we need to incorporate
crankback into the call model.  After that, the protocol details from
<draft-ietf-ccamp-crankback-03> can be incorporated into G.7713.2.

An electronic copy of this liaison statement can be found at
ftp://sg15opticalt:[e-mail]/tsg15opticaltransport/COMMUNICATIONS/index.html




Envelope-to: [e-mail]
Delivery-date: Wed, 09 Mar 2005 18:27:53 +0000
Message-ID: <037201c524d5$12786040$a4858182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>
Subject: Two LSs from ITU-T SG15's Q14/15 to IETF CCAMP WG
Date: Wed, 9 Mar 2005 18:20:46 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received two liaison statements from ITU-T Study Group 15 Question
14.

I have put these on the alternate ccamp web site at
http://www.olddog.co.uk/incoming.htm

I will send separate emails to include the text of the liaisons and
propose actions.

Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Wednesday, March 09, 2005 3:45 PM
Subject: Two LSs from ITU-T SG15's Q14/15 to IETF CCAMP WG


Dear Sirs,

On behalf of the Chairman of ITU-T Study Group 15, I am pleased to send
you two Liaison Statements agreed at the SG15 Q.14/15 Interim Meeting,
24 - 28 January 2005:

1) To IETF CCAMP WG on Crankback in GMPLS Systems
2) To IETF CCAMP WG on the Comparison of LMP and ASON Discovery

Best regards,
Greg Jones
Counsellor, ITU-T Study Group 15





Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 15:41:26 +0000
Date: Tue, 8 Mar 2005 10:40:44 -0500
From: Ashok Narayanan <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

On Tue, Mar 08, 2005 at 03:20:43PM -0000, [e-mail] wrote:
> Ashok,
> 
> I think one of the key points that needs highlighting explicitly which is not clear in the draft or your text below is that there are two separate control networks:
> 1) One control network for the non-PSC core. 
> 2) One control network for the PSC edge nodes.

Maybe that division is not as clear as it needs to be. Which network
of those two do the following belong to?:

1) Path message for an optical LSP generated by a PSC edge node.
2) NOTIFY message from a PSC edge node to the other PSC edge node for
an optical LSP. 
3) Path message for a frame LSP going over an optical LSP generated by
a PSC edge node. 
4) LDP messages exchanged between PSC edge nodes.
5) SIP messages transiting the PSC edge nodes.

There are plenty of different control plane levels here, so rather
than talk about two specific ones, I would like to differentiate
between 

a) "Messages for GMPLS/TE routing/signalling of optical LSPs between
the PSC edge devices and the optical core devices"

b) "everything else".

I want to say that if we use a separated control network for "a)",
then any and all traffic for "b)" MUST NOT go over that control
network. Everything else is to clarify (and may insert additional
ambiguities of its own :-()

> 
> Network (1) has to be OOB as a forced requirement of the co-cs mode.

Not necessarily OOB, but "separated". I think this is the point that
Dimitri was making. DCC is not necessarily considered OOB, but it is a
separated control plane. 

> Network (2) does not have to be OOB but it may be (it's down to operator choice/policy etc.).

Yes, and the specific statement is that traffic in network 2 cannot
transit the separated control plane used for network 1. Whether it is
separated or not is not relevant as you correctly point out.

> 
> If you look at the whole network stack you have trails in the non-PSC core layer network supporting link connections in the PSC layer network.  These non-PSC layer network trails may be used to support link connections in the PSC layer network that may be assigned to carry only 'PSC data traffic' (for the PSC data plane), only 'PSC control traffic' (for the PSC control plane when it's taken OOB) or both 'PSC data and control plane traffic' (when the PSC control plane is inband wrt the PSC data plane).  
> 
> In other words, the non-PSC layer network has it's own data &
> control plane networks that are (or should be) decoupled from the
> PSC layer network (which has its own data & control plane networks).
> non-PSC layer network data plane trails can be used to support PSC
> layer network data (and/or control) plane link connections, but
> non-PSC layer network control plane trails MUST NOT be used to
> support PSC layer network data (and/or control) plane link
> connections.  

I agree. I would phrase this as a "clarification" of b) above;
clarifying that PSC layer network control traffic falls in the
"everything else" category w.r.t the optical network.

> This behaviour should be recursive from the lowest to
> the highest layer in the network stack.

That's not necessarily what I'm saying but it's not bad. 

> 
> Ben
> 
> > -----Original Message-----
> > From: Ashok Narayanan [mailto:[e-mail]]
> > Sent: 08 March 2005 14:52
> > To: Adrian Farrel
> > Cc: Niven-jenkins,B,Ben,XDE73 R; [e-mail]
> > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
> > 
> > 
> > On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote:
> > > Hi,
> > > 
> > > Ben summarized...
> > > 
> > > > Thanks for the explanation.  If I understand correctly 
> > what you are
> > > > saying is that the best current practice is to use an OOB 
> > control plane
> > > > for the non-PSC  layer networks and an in-band control 
> > plane for the
> > > > PSC layer networks.
> > > 
> > > If that is the intention of the authors of this draft, they 
> > will have to
> > > fight me :-)
> > 
> > I better check out this website:
> >  http://www.all-karate.com/how_to_learn_karate.php
> > 
> > > I do not see why an in-band control channel for a PSC 
> > network would be
> > > made a RECOMMEND, SHOULD or MUST.
> > 
> > That is certainly not the recommendation (phew). 
> > 
> > I clarified in a separate email, but basically the point we are making
> > is that in an optical GMPLS/TE network with optical switches in the
> > core and PSC devices on the edge, edge-to-edge protocols not used for
> > GMPLS/TE signalling within the core must be kept off the separated
> > control network. I think the text needs to be tightened up to say
> > this; I sent out an alternative formulation just now, let's see how
> > that goes.
> > 
> > > 
> > > >  So one must avoid using the control plane network (of a non-PSC
> > > > layer network) for the transfer of data (or control) 
> > plane packets from
> > > > the PSC layer network's control & data planes.
> > > 
> > > Yes. But more precisely, one must avoid using the control 
> > channels for
> > > data traffic. Even in-band control channel may use a 
> > different address
> > > space, and those addresses must not be used for data.
> > 
> > Which is fine, but then raises the question: what is "data"? Bearer
> > traffic? SIP messages transiting through a number of hops to get here?
> > IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that
> > for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all*
> > of the aforementioned must be kept off the separated control plane
> > *used for GMPLS within the optical core*. Nothing prevents these other
> > protocols from having their own separated control plane, just as long
> > as that other control plane also goes over a GMPLS/TE LSP or via some
> > other "data" path.
> > 
> > What I'm trying to say is that the optical switches in the core should
> > basically not have to ever see any signalling or data packets that
> > don't pertain to GMPLS/TE signalling within the optical core.
> > 
> > In summary: (is this a better way to write this in the draft?)
> > 
> > 1) A core of optical switches with PSC edge devices running GMPLS may
> > use a separated control network (DCC, OOB Ethernet, or some other) to
> > carry GMPLS/TE signalling messages. Further, this control network may
> > be low-bandwidth and may pass through devices that are not well suited
> > for IP routing.
> > 
> > 2) Bearer data traffic transiting this network MUST NOT be carried on
> > this separated control network.
> > 
> > 3) Further, given the nature of the control network and the devices
> > that maintain it, protocols running between the PSC edge devices that
> > are not used for GMPLS/TE signalling within the core MUST NOT be
> > carried over this control network. (N.B. should this be relaxed to a
> > "SHOULD"?) This does not preclude these other protocols from running
> > separated control planes of their own, as long as the protocol
> > signalling messages do not transit the separated control network used
> > within the GMPLS/TE core.
> > 
> > -Ashok
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > --- Asok the Intern ----------------------------------------
> > Ashok Narayanan
> > IOS Network Protocols, Cisco Systems
> > 1414 Mass Ave, Boxborough MA 01719
> > Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)
> > 

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 15:21:47 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Date: Tue, 8 Mar 2005 15:20:43 -0000
Message-ID: <[e-mail]>
Thread-Topic: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Thread-Index: AcUj7mJ60OKsLVUhR2OZjc+ClTML9wAAe5dQ
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

Ashok,

I think one of the key points that needs highlighting explicitly which =
is not clear in the draft or your text below is that there are two =
separate control networks:
1) One control network for the non-PSC core.=20
2) One control network for the PSC edge nodes.

Network (1) has to be OOB as a forced requirement of the co-cs mode.
Network (2) does not have to be OOB but it may be (it's down to operator =
choice/policy etc.).

If you look at the whole network stack you have trails in the non-PSC =
core layer network supporting link connections in the PSC layer network. =
 These non-PSC layer network trails may be used to support link =
connections in the PSC layer network that may be assigned to carry only =
'PSC data traffic' (for the PSC data plane), only 'PSC control traffic' =
(for the PSC control plane when it's taken OOB) or both 'PSC data and =
control plane traffic' (when the PSC control plane is inband wrt the PSC =
data plane). =20

In other words, the non-PSC layer network has it's own data & control =
plane networks that are (or should be) decoupled from the PSC layer =
network (which has its own data & control plane networks).  non-PSC =
layer network data plane trails can be used to support PSC layer network =
data (and/or control) plane link connections, but non-PSC layer network =
control plane trails MUST NOT be used to support PSC layer network data =
(and/or control) plane link connections.  This behaviour should be =
recursive from the lowest to the highest layer in the network stack.=20

Ben

> -----Original Message-----
> From: Ashok Narayanan [mailto:[e-mail]]
> Sent: 08 March 2005 14:52
> To: Adrian Farrel
> Cc: Niven-jenkins,B,Ben,XDE73 R; [e-mail]
> Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
>=20
>=20
> On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote:
> > Hi,
> >=20
> > Ben summarized...
> >=20
> > > Thanks for the explanation.  If I understand correctly=20
> what you are
> > > saying is that the best current practice is to use an OOB=20
> control plane
> > > for the non-PSC  layer networks and an in-band control=20
> plane for the
> > > PSC layer networks.
> >=20
> > If that is the intention of the authors of this draft, they=20
> will have to
> > fight me :-)
>=20
> I better check out this website:
>  http://www.all-karate.com/how_to_learn_karate.php
>=20
> > I do not see why an in-band control channel for a PSC=20
> network would be
> > made a RECOMMEND, SHOULD or MUST.
>=20
> That is certainly not the recommendation (phew).=20
>=20
> I clarified in a separate email, but basically the point we are making
> is that in an optical GMPLS/TE network with optical switches in the
> core and PSC devices on the edge, edge-to-edge protocols not used for
> GMPLS/TE signalling within the core must be kept off the separated
> control network. I think the text needs to be tightened up to say
> this; I sent out an alternative formulation just now, let's see how
> that goes.
>=20
> >=20
> > >  So one must avoid using the control plane network (of a non-PSC
> > > layer network) for the transfer of data (or control)=20
> plane packets from
> > > the PSC layer network's control & data planes.
> >=20
> > Yes. But more precisely, one must avoid using the control=20
> channels for
> > data traffic. Even in-band control channel may use a=20
> different address
> > space, and those addresses must not be used for data.
>=20
> Which is fine, but then raises the question: what is "data"? Bearer
> traffic? SIP messages transiting through a number of hops to get here?
> IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that
> for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all*
> of the aforementioned must be kept off the separated control plane
> *used for GMPLS within the optical core*. Nothing prevents these other
> protocols from having their own separated control plane, just as long
> as that other control plane also goes over a GMPLS/TE LSP or via some
> other "data" path.
>=20
> What I'm trying to say is that the optical switches in the core should
> basically not have to ever see any signalling or data packets that
> don't pertain to GMPLS/TE signalling within the optical core.
>=20
> In summary: (is this a better way to write this in the draft?)
>=20
> 1) A core of optical switches with PSC edge devices running GMPLS may
> use a separated control network (DCC, OOB Ethernet, or some other) to
> carry GMPLS/TE signalling messages. Further, this control network may
> be low-bandwidth and may pass through devices that are not well suited
> for IP routing.
>=20
> 2) Bearer data traffic transiting this network MUST NOT be carried on
> this separated control network.
>=20
> 3) Further, given the nature of the control network and the devices
> that maintain it, protocols running between the PSC edge devices that
> are not used for GMPLS/TE signalling within the core MUST NOT be
> carried over this control network. (N.B. should this be relaxed to a
> "SHOULD"?) This does not preclude these other protocols from running
> separated control planes of their own, as long as the protocol
> signalling messages do not transit the separated control network used
> within the GMPLS/TE core.
>=20
> -Ashok
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> --- Asok the Intern ----------------------------------------
> Ashok Narayanan
> IOS Network Protocols, Cisco Systems
> 1414 Mass Ave, Boxborough MA 01719
> Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)
>=20



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 14:52:29 +0000
Date: Tue, 8 Mar 2005 09:51:50 -0500
From: Ashok Narayanan <[e-mail]>
To: Adrian Farrel <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i

On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote:
> Hi,
> 
> Ben summarized...
> 
> > Thanks for the explanation.  If I understand correctly what you are
> > saying is that the best current practice is to use an OOB control plane
> > for the non-PSC  layer networks and an in-band control plane for the
> > PSC layer networks.
> 
> If that is the intention of the authors of this draft, they will have to
> fight me :-)

I better check out this website:
 http://www.all-karate.com/how_to_learn_karate.php

> I do not see why an in-band control channel for a PSC network would be
> made a RECOMMEND, SHOULD or MUST.

That is certainly not the recommendation (phew). 

I clarified in a separate email, but basically the point we are making
is that in an optical GMPLS/TE network with optical switches in the
core and PSC devices on the edge, edge-to-edge protocols not used for
GMPLS/TE signalling within the core must be kept off the separated
control network. I think the text needs to be tightened up to say
this; I sent out an alternative formulation just now, let's see how
that goes.

> 
> >  So one must avoid using the control plane network (of a non-PSC
> > layer network) for the transfer of data (or control) plane packets from
> > the PSC layer network's control & data planes.
> 
> Yes. But more precisely, one must avoid using the control channels for
> data traffic. Even in-band control channel may use a different address
> space, and those addresses must not be used for data.

Which is fine, but then raises the question: what is "data"? Bearer
traffic? SIP messages transiting through a number of hops to get here?
IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that
for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all*
of the aforementioned must be kept off the separated control plane
*used for GMPLS within the optical core*. Nothing prevents these other
protocols from having their own separated control plane, just as long
as that other control plane also goes over a GMPLS/TE LSP or via some
other "data" path.

What I'm trying to say is that the optical switches in the core should
basically not have to ever see any signalling or data packets that
don't pertain to GMPLS/TE signalling within the optical core.

In summary: (is this a better way to write this in the draft?)

1) A core of optical switches with PSC edge devices running GMPLS may
use a separated control network (DCC, OOB Ethernet, or some other) to
carry GMPLS/TE signalling messages. Further, this control network may
be low-bandwidth and may pass through devices that are not well suited
for IP routing.

2) Bearer data traffic transiting this network MUST NOT be carried on
this separated control network.

3) Further, given the nature of the control network and the devices
that maintain it, protocols running between the PSC edge devices that
are not used for GMPLS/TE signalling within the core MUST NOT be
carried over this control network. (N.B. should this be relaxed to a
"SHOULD"?) This does not preclude these other protocols from running
separated control planes of their own, as long as the protocol
signalling messages do not transit the separated control network used
within the GMPLS/TE core.

-Ashok







--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 14:30:32 +0000
Date: Tue, 8 Mar 2005 09:29:59 -0500
From: Ashok Narayanan <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

Dimitri,

Thanks for the comments. Hopefully this text will get beaten into
shape with the attention you folks are paying to it.

On Tue, Mar 08, 2005 at 02:56:05PM +0100, dimitri papadimitriou wrote:
> ashok - this section is indeed to be clarified
> 
> 1. for non-PSC it should distinguish the logical from the physical 
> control channel separation with respect to the data plane channels, i do 
> not see for instance why DCC channels could not be used to exchange 
> control plane traffic and still keep a logical separation

Sure; of course we are not saying that. DCC channels although
travelling on the same fiber are logically separated from the data
channel on the same fiber. I don't think there is any statement to the
contrary.

> 
> 2. for PSC - why is there something different in terms of "practice" 
> than what is currently used in MPLS networks ?

We aren't recommending any. The separated L3 control plane idea I had
mentioned was my attempt to understand the kind of application that
Ben was getting at when he asked "why must control protocols (such as
LDP) NOT form adjacencies over the control plane interfaces". See below.

> 
> or
> 
> 3. do you assume that the interconnection of a PSC with non-PSC network 
> (both driven by GMPLS) could indeed introduce change from the current 
> practices operators used to use for their packet networks ? that in case 
> could be further applied to PSC-only networks ?

I'd say the first part of this is slightly true. Let me try and
reformulate; please tell me if this is better:

"Consider a GMPLS/TE network with optical switches in the core and PSC
devices at the edge, with a separated control plane (either OOB or via
DCC). The edge PSC devices have IP reachability with each other via
both the separated control plane network and via any optical GMPLS/TE
LSPs that may be configured between them (the "data traffic
network"). For the reasons mentioned below, traffic on the separated
control network MUST be limited to GMPLS/TE signalling traffic solely
for the purpose of established optical LSPs within the core of optical
switches. All bearer traffic carried through this network MUST be
carried over GMPLS/TE LSPs and MUST NOT be carried over the separated
control network. Further, any protocols that run purely between the
PSC devices that are not used for GMPLS/TE signalling within the
optical switch core (e.g. protocols for carrying bearer traffic like
LDP and BGP) MUST communicate over GMPLS/TE LSPs and MUST NOT form
adjacencies or exchange messages over the separated control network."

So there is in fact a change from the current practice of a PSC
network *only* at the edge of a cloud of optical switches running
GMPLS. If this was a regular cloud of routers then we could say "if
you have IP reachability over link X, use it". But in the case of an
optical switch network we may well have IP reachability through the
separated control network but we don't want to use it.

Regarding the second part of that question: we are not suggesting any
techniques to be applied in PSC-only networks. The separated PSC
control plane I alluded to earlier may be a useful idea, but it merits
separate treatment and is beyond the scope of this section IMHO.

-Ashok


> 
> thanks,
> - dimitri.
> 
> Ashok Narayanan wrote:
> 
> >Ben,
> >
> >Thanks for the comment. We'll try to clarify this in the next
> >version.
> >
> >-Ashok
> >
> >On Tue, Mar 08, 2005 at 01:14:08PM -0000,
> >[e-mail] wrote:
> >
> >>Ashok,
> >>
> >>Thanks for the explanation.  If I understand correctly what you are
> >>saying is that the best current practice is to use an OOB control
> >>plane for the non-PSC  layer networks and an in-band control plane
> >>for the PSC layer networks.  So one must avoid using the control
> >>plane network (of a non-PSC layer network) for the transfer of data
> >>(or control) plane packets from the PSC layer network's control &
> >>data planes.  Fine, I agree that is the BCP, but I don't believe
> >>the current draft articulates that intent very well and section 7.4
> >>probably needs expanding (IMO one or two paragraphs is probably not
> >>enough to discuss/address/detail OOB Vs in-band properly and
> >>unambiguously), for example it is not IMO clear from the current
> >>text that you are talking about 2 separate control plane networks -
> >>one OOB (for non-PSC layer networks/nodes) and one inband (for PSC
> >>layer networks/nodes).
> >>
> >>Thanks Ben
> >>
> >>
> >>>-----Original Message----- From: Ashok Narayanan
> >>>[mailto:[e-mail]] Sent: 08 March 2005 12:59 To:
> >>>Niven-jenkins,B,Ben,XDE73 R Cc: [e-mail] Subject: Re:
> >>>Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
> >>>
> >>>
> >>>
> >>>>I am trying to understand section 7.4 (Separation of
> >>>
> >>>Control and Data Plane Traffic) of 
> >>>draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> >>>
> >>>>The draft states: "PSC-capable nodes implementing an OOB
> >>>>control plane (perhaps to communicate with an optical switch)
> >>>>MUST NOT use the OOB control plane for data traffic.  For
> >>>>example, in the case of MPLS service running on top of a GMPLS
> >>>>LSP, if the peer PSC device is reachable via both the control
> >>>>plane and the data plane, control protocols such as LDP MUST
> >>>>NOT form adjacencies over the control plane interfaces.  This
> >>>>may be provided by a combination of implementation features and
> >>>>deployment guidelines."
> >>>>
> >>>>So, if the control plane is OOB why must control protocols
> >>>>(such as LDP) NOT form adjacencies over the control plane
> >>>>interfaces?  This implies that LDP (for e.g.) MUST form its
> >>>>adjacencies over the data plane interfaces and therefore LDP is
> >>>>not running OOB (and therefore the control plane is not
> >>>>entirely OOB).
> >>>>
> >>>
> >>>That's an interesting question. The draft focuses on GMPLS/TE 
> >>>deployments and the use of an out-of-band control channel as a
> >>>matter of necessity (i.e. because optical switches are not
> >>>capable of handling in-band control traffic). Consider the
> >>>general deployment of a core of optical switches surrounded by
> >>>GMPLS/TE routers at the edge. From the perspective of this
> >>>network (optical switches, edge routers, and the links in
> >>>between), that statement translates to:
> >>>
> >>>_ The GMPLS/TE control plane between the edge routers and the
> >>>optical switches in the core is entirely out-of-band
> >>>
> >>>- All other protocols between the edge routers MUST be entirely
> >>>in-band.
> >>>
> >>>The control plane network may well be a series of point-to-point
> >>>GRE tunnels overlaid on some other low-bandwidth network
> >>>(actually this is what the draft recommends). Ordinarily one
> >>>would establish a GRE tunnel between each pair of neighbors so
> >>>they can talk to each other. But this means that signalling
> >>>messages going from edge router to edge router actually have to
> >>>be routed through the control planes of intermediate switches.
> >>>The two alternatives to avoid this (to create a full mesh of GRE
> >>>tunnels - at least between all the edge routers - or to not use
> >>>GRE at all if the control plane is switched Ethernet, and 
> >>>therefore to essentially permit a full mesh of OSPF peers) are
> >>>not really palatable (and in the case of SDCC, not usable). The
> >>>optical switches in the core should not be in the business of
> >>>routing packets. Sometimes they have to (e.g. Notify messages),
> >>>but they are not designed for this purpose and should not be
> >>>deployed as such.
> >>>
> >>>And practically speaking the control network is expected to be a 
> >>>low-bandwidth network that can "just get the job done". A single 
> >>>10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle
> >>>the control traffic for a GMPLS/TE network, but will probably
> >>>fail if we want to use it to peer LDP or BGP for 10,000
> >>>prefixes/labels between the edge routers.
> >>>
> >>>The best current practice is therefore to use the low-bandwidth 
> >>>control network between routers and switches for GMPLS/TE
> >>>signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical
> >>>TE LSPs signalled between edge routers to do other L3 protocols
> >>>between them.
> >>>
> >>>The issue of a separated control plane between PSC edge routers
> >>>for different L3 protocols for administrative reasons is an
> >>>interesting one. Nothing precludes you from creating multiple
> >>>parallel LSPs between edge routers and using one of them to carry
> >>>control traffic between the two edge routers on behalf of all the
> >>>others; that would still satisfy this requirement. Alternatively,
> >>>one could engineer a more beefy control plane network so that it
> >>>can in fact carry all the control plane traffic (BGP, LDP etc.)
> >>>but that is not the BCP today based on available implementations.
> >>>
> >>>
> >>>-Ashok
> >>>
> >>>On Tue, Mar 08, 2005 at 10:33:54AM -0000, 
> >>>[e-mail] wrote:
> >>>
> >>>>Colleagues,
> >>>>
> >>>>I am trying to understand section 7.4 (Separation of
> >>>
> >>>Control and Data Plane Traffic) of 
> >>>draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> >>>
> >>>>The draft states: "PSC-capable nodes implementing an OOB
> >>>>control plane
> >>>
> >>>(perhaps to communicate with an optical switch) MUST NOT use the
> >>>OOB control plane for data traffic.  For example, in the case of
> >>>MPLS service running on top of a GMPLS LSP, if the peer PSC
> >>>device is reachable via both the control plane and the data
> >>>plane, control protocols such as LDP MUST NOT form adjacencies
> >>>over the control plane interfaces.  This may be provided by a
> >>>combination of implementation features and deployment
> >>>guidelines."
> >>>
> >>>>So, if the control plane is OOB why must control protocols
> >>>
> >>>(such as LDP) NOT form adjacencies over the control plane 
> >>>interfaces?  This implies that LDP (for e.g.) MUST form its 
> >>>adjacencies over the data plane interfaces and therefore LDP is
> >>>not running OOB (and therefore the control plane is not entirely
> >>>OOB).
> >>>
> >>>>Thanks Ben
> >>>>
> >>>>
> >>>>-- Ben Niven-Jenkins Networking Specialist, BT Exact
> >>>>
> >>>>e-mail: [e-mail] tel: [phone] 
> >>>>mob: [phone]
> >>>>
> >>>>pp34/161 B81 Callisto House, Adastral Park, Martlesham,
> >>>
> >>>Ipswich IP5 3RE, UK
> >>>
> >>>>BT Exact is a trademark of British Telecommunications plc 
> >>>>Registered office: 81 Newgate Street London EC1A 7AJ Registered
> >>>>in England no. 1800000
> >>>>
> >>>>This electronic message contains information from British
> >>>
> >>>Telecommunications which may be privileged or confidential. The
> >>>information is intended to be for the use of the individual(s) or
> >>>the entity named above. If you are not the intended recipient be
> >>>aware that any disclosure, copying, distribution or use of the
> >>>contents of this information is prohibited. If you have received
> >>>this electronic message in error, please notify us by telephone
> >>>or email (to the numbers or address above) immediately.
> >>>
> >>>>Activity and use of the British Telecommunications plc
> >>>
> >>>email system is monitored to secure its effective operation and
> >>>for other lawful business purposes. Communications using this
> >>>system will also be monitored and may be recorded to secure
> >>>effective operation and for other lawful business purposes.
> >>>
> >>>--
> >>>
> >>>
> >>>
> >>>--- Asok the Intern ---------------------------------------- 
> >>>Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass
> >>>Ave, Boxborough MA 01719 Ph: 978-936-1608.  Fax: [phone]
> >>>(Attn: Ashok Narayanan)
> >>>
> >
> >

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 14:17:27 +0000
Message-ID: <01b601c523e9$0152c180$a4858182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Date: Tue, 8 Mar 2005 14:12:54 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Ben summarized...

> Thanks for the explanation.  If I understand correctly what you are
> saying is that the best current practice is to use an OOB control plane
> for the non-PSC  layer networks and an in-band control plane for the
> PSC layer networks.

If that is the intention of the authors of this draft, they will have to
fight me :-)

I do not see why an in-band control channel for a PSC network would be
made a RECOMMEND, SHOULD or MUST.

>  So one must avoid using the control plane network (of a non-PSC
> layer network) for the transfer of data (or control) plane packets from
> the PSC layer network's control & data planes.

Yes. But more precisely, one must avoid using the control channels for
data traffic. Even in-band control channel may use a different address
space, and those addresses must not be used for data.

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 13:56:07 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Mar 2005 14:56:05 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Ashok Narayanan <[e-mail]>
CC:  [e-mail],  [e-mail]
Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

ashok - this section is indeed to be clarified

1. for non-PSC it should distinguish the logical from the physical 
control channel separation with respect to the data plane channels, i do 
not see for instance why DCC channels could not be used to exchange 
control plane traffic and still keep a logical separation

2. for PSC - why is there something different in terms of "practice" 
than what is currently used in MPLS networks ?

or

3. do you assume that the interconnection of a PSC with non-PSC network 
(both driven by GMPLS) could indeed introduce change from the current 
practices operators used to use for their packet networks ? that in case 
could be further applied to PSC-only networks ?

thanks,
- dimitri.

Ashok Narayanan wrote:

> Ben,
> 
> Thanks for the comment. We'll try to clarify this in the next
> version.
> 
> -Ashok
> 
> On Tue, Mar 08, 2005 at 01:14:08PM -0000,
> [e-mail] wrote:
> 
>> Ashok,
>> 
>> Thanks for the explanation.  If I understand correctly what you are
>> saying is that the best current practice is to use an OOB control
>> plane for the non-PSC  layer networks and an in-band control plane
>> for the PSC layer networks.  So one must avoid using the control
>> plane network (of a non-PSC layer network) for the transfer of data
>> (or control) plane packets from the PSC layer network's control &
>> data planes.  Fine, I agree that is the BCP, but I don't believe
>> the current draft articulates that intent very well and section 7.4
>> probably needs expanding (IMO one or two paragraphs is probably not
>> enough to discuss/address/detail OOB Vs in-band properly and
>> unambiguously), for example it is not IMO clear from the current
>> text that you are talking about 2 separate control plane networks -
>> one OOB (for non-PSC layer networks/nodes) and one inband (for PSC
>> layer networks/nodes).
>> 
>> Thanks Ben
>> 
>> 
>>> -----Original Message----- From: Ashok Narayanan
>>> [mailto:[e-mail]] Sent: 08 March 2005 12:59 To:
>>> Niven-jenkins,B,Ben,XDE73 R Cc: [e-mail] Subject: Re:
>>> Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
>>> 
>>> 
>>> 
>>>> I am trying to understand section 7.4 (Separation of
>>> 
>>> Control and Data Plane Traffic) of 
>>> draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
>>> 
>>>> The draft states: "PSC-capable nodes implementing an OOB
>>>> control plane (perhaps to communicate with an optical switch)
>>>> MUST NOT use the OOB control plane for data traffic.  For
>>>> example, in the case of MPLS service running on top of a GMPLS
>>>> LSP, if the peer PSC device is reachable via both the control
>>>> plane and the data plane, control protocols such as LDP MUST
>>>> NOT form adjacencies over the control plane interfaces.  This
>>>> may be provided by a combination of implementation features and
>>>> deployment guidelines."
>>>> 
>>>> So, if the control plane is OOB why must control protocols
>>>> (such as LDP) NOT form adjacencies over the control plane
>>>> interfaces?  This implies that LDP (for e.g.) MUST form its
>>>> adjacencies over the data plane interfaces and therefore LDP is
>>>> not running OOB (and therefore the control plane is not
>>>> entirely OOB).
>>>> 
>>> 
>>> That's an interesting question. The draft focuses on GMPLS/TE 
>>> deployments and the use of an out-of-band control channel as a
>>> matter of necessity (i.e. because optical switches are not
>>> capable of handling in-band control traffic). Consider the
>>> general deployment of a core of optical switches surrounded by
>>> GMPLS/TE routers at the edge. From the perspective of this
>>> network (optical switches, edge routers, and the links in
>>> between), that statement translates to:
>>> 
>>> _ The GMPLS/TE control plane between the edge routers and the
>>> optical switches in the core is entirely out-of-band
>>> 
>>> - All other protocols between the edge routers MUST be entirely
>>> in-band.
>>> 
>>> The control plane network may well be a series of point-to-point
>>> GRE tunnels overlaid on some other low-bandwidth network
>>> (actually this is what the draft recommends). Ordinarily one
>>> would establish a GRE tunnel between each pair of neighbors so
>>> they can talk to each other. But this means that signalling
>>> messages going from edge router to edge router actually have to
>>> be routed through the control planes of intermediate switches.
>>> The two alternatives to avoid this (to create a full mesh of GRE
>>> tunnels - at least between all the edge routers - or to not use
>>> GRE at all if the control plane is switched Ethernet, and 
>>> therefore to essentially permit a full mesh of OSPF peers) are
>>> not really palatable (and in the case of SDCC, not usable). The
>>> optical switches in the core should not be in the business of
>>> routing packets. Sometimes they have to (e.g. Notify messages),
>>> but they are not designed for this purpose and should not be
>>> deployed as such.
>>> 
>>> And practically speaking the control network is expected to be a 
>>> low-bandwidth network that can "just get the job done". A single 
>>> 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle
>>> the control traffic for a GMPLS/TE network, but will probably
>>> fail if we want to use it to peer LDP or BGP for 10,000
>>> prefixes/labels between the edge routers.
>>> 
>>> The best current practice is therefore to use the low-bandwidth 
>>> control network between routers and switches for GMPLS/TE
>>> signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical
>>> TE LSPs signalled between edge routers to do other L3 protocols
>>> between them.
>>> 
>>> The issue of a separated control plane between PSC edge routers
>>> for different L3 protocols for administrative reasons is an
>>> interesting one. Nothing precludes you from creating multiple
>>> parallel LSPs between edge routers and using one of them to carry
>>> control traffic between the two edge routers on behalf of all the
>>> others; that would still satisfy this requirement. Alternatively,
>>> one could engineer a more beefy control plane network so that it
>>> can in fact carry all the control plane traffic (BGP, LDP etc.)
>>> but that is not the BCP today based on available implementations.
>>> 
>>> 
>>> -Ashok
>>> 
>>> On Tue, Mar 08, 2005 at 10:33:54AM -0000, 
>>> [e-mail] wrote:
>>> 
>>>> Colleagues,
>>>> 
>>>> I am trying to understand section 7.4 (Separation of
>>> 
>>> Control and Data Plane Traffic) of 
>>> draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
>>> 
>>>> The draft states: "PSC-capable nodes implementing an OOB
>>>> control plane
>>> 
>>> (perhaps to communicate with an optical switch) MUST NOT use the
>>> OOB control plane for data traffic.  For example, in the case of
>>> MPLS service running on top of a GMPLS LSP, if the peer PSC
>>> device is reachable via both the control plane and the data
>>> plane, control protocols such as LDP MUST NOT form adjacencies
>>> over the control plane interfaces.  This may be provided by a
>>> combination of implementation features and deployment
>>> guidelines."
>>> 
>>>> So, if the control plane is OOB why must control protocols
>>> 
>>> (such as LDP) NOT form adjacencies over the control plane 
>>> interfaces?  This implies that LDP (for e.g.) MUST form its 
>>> adjacencies over the data plane interfaces and therefore LDP is
>>> not running OOB (and therefore the control plane is not entirely
>>> OOB).
>>> 
>>>> Thanks Ben
>>>> 
>>>> 
>>>> -- Ben Niven-Jenkins Networking Specialist, BT Exact
>>>> 
>>>> e-mail: [e-mail] tel: [phone] 
>>>> mob: [phone]
>>>> 
>>>> pp34/161 B81 Callisto House, Adastral Park, Martlesham,
>>> 
>>> Ipswich IP5 3RE, UK
>>> 
>>>> BT Exact is a trademark of British Telecommunications plc 
>>>> Registered office: 81 Newgate Street London EC1A 7AJ Registered
>>>> in England no. 1800000
>>>> 
>>>> This electronic message contains information from British
>>> 
>>> Telecommunications which may be privileged or confidential. The
>>> information is intended to be for the use of the individual(s) or
>>> the entity named above. If you are not the intended recipient be
>>> aware that any disclosure, copying, distribution or use of the
>>> contents of this information is prohibited. If you have received
>>> this electronic message in error, please notify us by telephone
>>> or email (to the numbers or address above) immediately.
>>> 
>>>> Activity and use of the British Telecommunications plc
>>> 
>>> email system is monitored to secure its effective operation and
>>> for other lawful business purposes. Communications using this
>>> system will also be monitored and may be recorded to secure
>>> effective operation and for other lawful business purposes.
>>> 
>>> --
>>> 
>>> 
>>> 
>>> --- Asok the Intern ---------------------------------------- 
>>> Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass
>>> Ave, Boxborough MA 01719 Ph: 978-936-1608.  Fax: [phone]
>>> (Attn: Ashok Narayanan)
>>> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 13:55:29 +0000
From: "Rajiv Papneja" <[e-mail]>
To: "'Ashok Narayanan'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Date: Tue, 8 Mar 2005 08:54:56 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcUj39SDCZvsFny6SgaEx790Tq5i2wABSDfQ
Message-Id: <[e-mail]>

See below:

-----Original Message-----
From: Ashok Narayanan [mailto:[e-mail]] 
Sent: Tuesday, March 08, 2005 7:59 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt

> 
> I am trying to understand section 7.4 (Separation of Control and Data
Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> 
> The draft states:
> "PSC-capable nodes implementing an OOB control plane (perhaps to
> communicate with an optical switch) MUST NOT use the OOB control
> plane for data traffic.  For example, in the case of MPLS service
> running on top of a GMPLS LSP, if the peer PSC device is reachable
> via both the control plane and the data plane, control protocols
> such as LDP MUST NOT form adjacencies over the control plane
> interfaces.  This may be provided by a combination of implementation
> features and deployment guidelines."
> 
> So, if the control plane is OOB why must control protocols (such as
> LDP) NOT form adjacencies over the control plane interfaces?  This
> implies that LDP (for e.g.) MUST form its adjacencies over the data
> plane interfaces and therefore LDP is not running OOB (and therefore
> the control plane is not entirely OOB).
> 

That's an interesting question. The draft focuses on GMPLS/TE
deployments and the use of an out-of-band control channel as a matter
of necessity (i.e. because optical switches are not capable of
handling in-band control traffic). Consider the general deployment of
a core of optical switches surrounded by GMPLS/TE routers at the
edge. From the perspective of this network (optical switches, edge
routers, and the links in between), that statement translates to:

 _ The GMPLS/TE control plane between the edge routers and the optical
   switches in the core is entirely out-of-band

 - All other protocols between the edge routers MUST be entirely in-band.

The control plane network may well be a series of point-to-point GRE
tunnels overlaid on some other low-bandwidth network (actually this is
what the draft recommends). Ordinarily one would establish a GRE
tunnel between each pair of neighbors so they can talk to each other.
But this means that signalling messages going from edge router to edge
router actually have to be routed through the control planes of
intermediate switches. The two alternatives to avoid this (to create a
full mesh of GRE tunnels - at least between all the edge routers - or
to not use GRE at all if the control plane is switched Ethernet, and
therefore to essentially permit a full mesh of OSPF peers) are not
really palatable (and in the case of SDCC, not usable). The optical
switches in the core should not be in the business of routing
packets. Sometimes they have to (e.g. Notify messages), but they are
not designed for this purpose and should not be deployed as such.

And practically speaking the control network is expected to be a
low-bandwidth network that can "just get the job done". A single
10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the
control traffic for a GMPLS/TE network, but will probably fail if we
want to use it to peer LDP or BGP for 10,000 prefixes/labels between
the edge routers.

[rp] Furthermore - If LDP adjacencies are formed over the control plane, and
since the LDP forwarding is based on the IP routing and metrics, the PSC
devices will try to forward the IP traffic on the interfaces with the lowest
metric (control interface in this case), and since all the edge nodes in the
GMPLS control plane are adjacent from control plane traffic perspective, one
has to change the metrics of the control plane interface on the PSC devices
to avoid the best path through the control plane (OOB). 

The best current practice is therefore to use the low-bandwidth
control network between routers and switches for GMPLS/TE signaling
(RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs
signalled between edge routers to do other L3 protocols between them.

The issue of a separated control plane between PSC edge routers for
different L3 protocols for administrative reasons is an interesting
one. Nothing precludes you from creating multiple parallel LSPs
between edge routers and using one of them to carry control traffic
between the two edge routers on behalf of all the others; that would
still satisfy this requirement. Alternatively, one could engineer a
more beefy control plane network so that it can in fact carry all the
control plane traffic (BGP, LDP etc.) but that is not the BCP today
based on available implementations.

-Ashok

On Tue, Mar 08, 2005 at 10:33:54AM -0000, [e-mail]
wrote:
> Colleagues,
> 
> I am trying to understand section 7.4 (Separation of Control and Data
Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> 
> The draft states:
> "PSC-capable nodes implementing an OOB control plane (perhaps to
communicate with an optical switch) MUST NOT use the OOB control plane for
data traffic.  For example, in the case of MPLS service running on top of a
GMPLS LSP, if the peer PSC device is reachable via both the control plane
and the data plane, control protocols such as LDP MUST NOT form adjacencies
over the control plane interfaces.  This may be provided by a combination of
implementation features and deployment guidelines."
> 
> So, if the control plane is OOB why must control protocols (such as LDP)
NOT form adjacencies over the control plane interfaces?  This implies that
LDP (for e.g.) MUST form its adjacencies over the data plane interfaces and
therefore LDP is not running OOB (and therefore the control plane is not
entirely OOB).
> 
> Thanks
> Ben
> 
> 
> -- 
> Ben Niven-Jenkins
> Networking Specialist, BT Exact
> 
> e-mail: [e-mail]
> tel: [phone]
> mob: [phone]
> 
> pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE,
UK
> 
> BT Exact is a trademark of British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no. 1800000
> 
> This electronic message contains information from British
Telecommunications which may be privileged or confidential. The information
is intended to be for the use of the individual(s) or the entity named
above. If you are not the intended recipient be aware that any disclosure,
copying, distribution or use of the contents of this information is
prohibited. If you have received this electronic message in error, please
notify us by telephone or email (to the numbers or address above)
immediately. 
> 
> Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful business
purposes. Communications using this system will also be monitored and may be
recorded to secure effective operation and for other lawful business
purposes.

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)







Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 13:21:35 +0000
Date: Tue, 8 Mar 2005 08:21:22 -0500
From: Ashok Narayanan <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

Ben,

Thanks for the comment. We'll try to clarify this in the next version.

-Ashok

On Tue, Mar 08, 2005 at 01:14:08PM -0000, [e-mail] wrote:
> Ashok,
> 
> Thanks for the explanation.  If I understand correctly what you are saying is that the best current practice is to use an OOB control plane for the non-PSC  layer networks and an in-band control plane for the PSC layer networks.  So one must avoid using the control plane network (of a non-PSC layer network) for the transfer of data (or control) plane packets from the PSC layer network's control & data planes.  Fine, I agree that is the BCP, but I don't believe the current draft articulates that intent very well and section 7.4 probably needs expanding (IMO one or two paragraphs is probably not enough to discuss/address/detail OOB Vs in-band properly and unambiguously), for example it is not IMO clear from the current text that you are talking about 2 separate control plane networks - one OOB (for non-PSC layer networks/nodes) and one inband (for PSC layer networks/nodes).
> 
> Thanks
> Ben
> 
> > -----Original Message-----
> > From: Ashok Narayanan [mailto:[e-mail]]
> > Sent: 08 March 2005 12:59
> > To: Niven-jenkins,B,Ben,XDE73 R
> > Cc: [e-mail]
> > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
> > 
> > 
> > > 
> > > I am trying to understand section 7.4 (Separation of 
> > Control and Data Plane Traffic) of 
> > draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> > > 
> > > The draft states:
> > > "PSC-capable nodes implementing an OOB control plane (perhaps to
> > > communicate with an optical switch) MUST NOT use the OOB control
> > > plane for data traffic.  For example, in the case of MPLS service
> > > running on top of a GMPLS LSP, if the peer PSC device is reachable
> > > via both the control plane and the data plane, control protocols
> > > such as LDP MUST NOT form adjacencies over the control plane
> > > interfaces.  This may be provided by a combination of implementation
> > > features and deployment guidelines."
> > > 
> > > So, if the control plane is OOB why must control protocols (such as
> > > LDP) NOT form adjacencies over the control plane interfaces?  This
> > > implies that LDP (for e.g.) MUST form its adjacencies over the data
> > > plane interfaces and therefore LDP is not running OOB (and therefore
> > > the control plane is not entirely OOB).
> > > 
> > 
> > That's an interesting question. The draft focuses on GMPLS/TE
> > deployments and the use of an out-of-band control channel as a matter
> > of necessity (i.e. because optical switches are not capable of
> > handling in-band control traffic). Consider the general deployment of
> > a core of optical switches surrounded by GMPLS/TE routers at the
> > edge. From the perspective of this network (optical switches, edge
> > routers, and the links in between), that statement translates to:
> > 
> >  _ The GMPLS/TE control plane between the edge routers and the optical
> >    switches in the core is entirely out-of-band
> > 
> >  - All other protocols between the edge routers MUST be 
> > entirely in-band.
> > 
> > The control plane network may well be a series of point-to-point GRE
> > tunnels overlaid on some other low-bandwidth network (actually this is
> > what the draft recommends). Ordinarily one would establish a GRE
> > tunnel between each pair of neighbors so they can talk to each other.
> > But this means that signalling messages going from edge router to edge
> > router actually have to be routed through the control planes of
> > intermediate switches. The two alternatives to avoid this (to create a
> > full mesh of GRE tunnels - at least between all the edge routers - or
> > to not use GRE at all if the control plane is switched Ethernet, and
> > therefore to essentially permit a full mesh of OSPF peers) are not
> > really palatable (and in the case of SDCC, not usable). The optical
> > switches in the core should not be in the business of routing
> > packets. Sometimes they have to (e.g. Notify messages), but they are
> > not designed for this purpose and should not be deployed as such.
> > 
> > And practically speaking the control network is expected to be a
> > low-bandwidth network that can "just get the job done". A single
> > 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the
> > control traffic for a GMPLS/TE network, but will probably fail if we
> > want to use it to peer LDP or BGP for 10,000 prefixes/labels between
> > the edge routers.
> > 
> > The best current practice is therefore to use the low-bandwidth
> > control network between routers and switches for GMPLS/TE signaling
> > (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs
> > signalled between edge routers to do other L3 protocols between them.
> > 
> > The issue of a separated control plane between PSC edge routers for
> > different L3 protocols for administrative reasons is an interesting
> > one. Nothing precludes you from creating multiple parallel LSPs
> > between edge routers and using one of them to carry control traffic
> > between the two edge routers on behalf of all the others; that would
> > still satisfy this requirement. Alternatively, one could engineer a
> > more beefy control plane network so that it can in fact carry all the
> > control plane traffic (BGP, LDP etc.) but that is not the BCP today
> > based on available implementations.
> > 
> > -Ashok
> > 
> > On Tue, Mar 08, 2005 at 10:33:54AM -0000, 
> > [e-mail] wrote:
> > > Colleagues,
> > > 
> > > I am trying to understand section 7.4 (Separation of 
> > Control and Data Plane Traffic) of 
> > draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> > > 
> > > The draft states:
> > > "PSC-capable nodes implementing an OOB control plane 
> > (perhaps to communicate with an optical switch) MUST NOT use 
> > the OOB control plane for data traffic.  For example, in the 
> > case of MPLS service running on top of a GMPLS LSP, if the 
> > peer PSC device is reachable via both the control plane and 
> > the data plane, control protocols such as LDP MUST NOT form 
> > adjacencies over the control plane interfaces.  This may be 
> > provided by a combination of implementation features and 
> > deployment guidelines."
> > > 
> > > So, if the control plane is OOB why must control protocols 
> > (such as LDP) NOT form adjacencies over the control plane 
> > interfaces?  This implies that LDP (for e.g.) MUST form its 
> > adjacencies over the data plane interfaces and therefore LDP 
> > is not running OOB (and therefore the control plane is not 
> > entirely OOB).
> > > 
> > > Thanks
> > > Ben
> > > 
> > > 
> > > -- 
> > > Ben Niven-Jenkins
> > > Networking Specialist, BT Exact
> > > 
> > > e-mail: [e-mail]
> > > tel: [phone]
> > > mob: [phone]
> > > 
> > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, 
> > Ipswich IP5 3RE, UK
> > > 
> > > BT Exact is a trademark of British Telecommunications plc
> > > Registered office: 81 Newgate Street London EC1A 7AJ
> > > Registered in England no. 1800000
> > > 
> > > This electronic message contains information from British 
> > Telecommunications which may be privileged or confidential. 
> > The information is intended to be for the use of the 
> > individual(s) or the entity named above. If you are not the 
> > intended recipient be aware that any disclosure, copying, 
> > distribution or use of the contents of this information is 
> > prohibited. If you have received this electronic message in 
> > error, please notify us by telephone or email (to the numbers 
> > or address above) immediately. 
> > > 
> > > Activity and use of the British Telecommunications plc 
> > email system is monitored to secure its effective operation 
> > and for other lawful business purposes. Communications using 
> > this system will also be monitored and may be recorded to 
> > secure effective operation and for other lawful business purposes.
> > 
> > -- 
> > 
> > 
> > 
> > --- Asok the Intern ----------------------------------------
> > Ashok Narayanan
> > IOS Network Protocols, Cisco Systems
> > 1414 Mass Ave, Boxborough MA 01719
> > Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)
> > 

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 13:19:38 +0000
Subject: [WARNING: A/V UNSCANNABLE] Re: Agenda and slides on line
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: multipart/mixed; boundary=Apple-Mail-2-984250060
Message-Id: <[e-mail]>
Cc: <[e-mail]>
From: JP Vasseur <[e-mail]>
Date: Tue, 8 Mar 2005 07:19:12 -0600
To: "Adrian Farrel" <[e-mail]>

--Apple-Mail-2-984250060
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


On Mar 8, 2005, at 2:31 AM, Adrian Farrel wrote:

> Agenda and slides on line at http://www.olddog.co.uk/62/ccamp.htm
>
> All there except...
>
> Status and plans for CCAMP re-charter
>   Alex Zinin. No slides received.
>
> draft-vasseur-ccamp-automesh-00.txt
>   JP Vasseur. Slides received but corrupt
>

=> 
  
--Apple-Mail-2-984250060
Content-Transfer-Encoding: base64
Content-Type: application/vnd.ms-powerpoint;
	x-mac-type=534C4438;
	x-unix-mode=0644;
	x-mac-creator=50505433;
	name="IETF-62-draft-vasseur-ccamp-automesh-00.ppt"
Content-Disposition: attachment;
	filename=IETF-62-draft-vasseur-ccamp-automesh-00.ppt

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPwAAAAAAAAAA
EAAAQgAAAAEAAAD+////AAAAAEAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////PQAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A
AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA
AB4AAAAfAAAAIAAAACEAAAD+/////v///zsAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA
LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6
AAAA/v///zwAAAA+AAAA/v////7/////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////wBS
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAACAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAAA2tC6nI8UB
IwAAAEAGAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAACAAAA2D8AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0
AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAABELAAAAAAAAAUARABvAGMAdQBtAGUAbgB0
AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAFAAAAAAAADwDo
Az4kAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAAkE
vAEAAAAACgQEAAAAVAAAAA8A1w84AAAAAADTDwQAAAA8AAAAAAC6DyQAAABqAHYAYQBzAHMAZQB1
AHIAQABjAGkAcwBjAG8ALgBjAG8AbQAPANcPTgAAAAAA0w8EAAAAPwAAAAAAug86AAAAeQBhAHMA
dQBrAGEAdwBhAC4AcwBlAGkAcwBoAG8AQABsAGEAYgAuAG4AdAB0AC4AYwBvAC4AagBwAA8A1w9Y
AAAAAADTDwQAAABEAAAAAAC6D0QAAABqAGUAYQBuAGwAbwB1AGkAcwAuAGwAZQByAG8AdQB4AEAA
ZgByAGEAbgBjAGUAdABlAGwAZQBjAG8AbQAuAGMAbwBtAA8A1w80AAAAAADTDwQAAABGAAAAAAC6
DyAAAABwAG0AYQBiAGUAeQBAAHEAdwBlAHMAdAAuAGMAbwBtAA8A1w82AAAAAADTDwQAAABHAAAA
AAC6DyIAAABwAHAAcwBlAG4AYQBrAEAAYwBpAHMAYwBvAC4AYwBvAG0ADwDXDzgAAAAAANMPBAAA
AEgAAAAAALoPJAAAAHMAcAByAGUAdgBpAGQAaQBAAGMAaQBzAGMAbwAuAGMAbwBtAA8A8gP6AQAA
LwDIDwwAAAAwANIPBAAAAAEAAAAPANUHMAEAAAAAtw9EAAAAQQByAGkAYQBsAAAAbgBnAHMAAABv
AGQAZQAgAP+/CNz/vzDYAAAQAAkBEEn/vwjc/78w2AEAF7ZAAVxQVpFsIwAABAAQALcPRAAAAEEA
cgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAAAw2AAAEAAJARBJ/78I3P+/MNgBABe2QAFc
UFaRbCOAAAYiIAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAG8AZABlACAATQBTAAAAMNgAABAA
CQEQSf+/CNz/vzDYAQAXtkABXFBWkWwjAgAEADAAtw9EAAAAVABpAG0AZQBzAAAAbgBnAHMAAABv
AGQAZQAgAE0AUwAAADDYAAAQAAkBEEn/vwjc/78w2AEAF7ZAAVxQVpFsIwAABAAAAKQPCgAAAIAA
YAAAAP////8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD/
/T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////EgAAAAAB
AAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsE4AAA
AA8AAPDYAAAAAAAG8IAAAAACPAAADwAAABUAAAAFAAAAAQAAAAcAAAADAAAABAAAAAAAAAAEAAAA
AAAAAAQAAAAFAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAADAAAAAAAAAAEAAAABAAAAAkAAAAA
AAAABAAAAAAAAAAEAAAAAAAAAAQAAAACAAAABAAAAIMAC/AwAAAAgQEEAAAIgwEAAAAIhkEAAAAA
vwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDw
DxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQBxsQAAAfABQEHAAAAAAAFQQUAAAA
upOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABnAAAAZAAAAGcA
AABkAAAAALBuAQAAAAAAAAAAUNj/vwAAAACwDg8BkP7//5D///8BAAAAcAD7AwgAAAAAAAAAcAgA
AHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAALDY/78CAAAA
AKUGAQAAAABnAAAAAMqaOwAAAAAAAAAAAAEAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAf
AAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAALDY/78CAAAAAKUGAQAAAAAUAAAAAMqaOwAA
AAAAAAAAAAEAAA8AiBPcDgAADwCKE7gAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTmAAA
AA8Asw+QAAAAEACvDwgAAAAAAQAABQAAAAAAsQ8oAAAAAAAABAAAAAAAAAAEAQAAAAAAAAQCAAAA
AAAABAMAAAAAAAAEBAAAABAArw8IAAAACQEAAAEAAAAAALEPOAAAAAAAAAQAAAAAAAAABAEAAAAA
AAAEAgAAAAAAAAQDAAAAAAAABAQAAAAAAAAEBQAAAAAAAAQGAAAADwCKE6QBAAAAALoPDgAAAF8A
XwBfAFAAUABUADkAAACLE4YBAAAPAK4PfgEAABAArw8IAAAAAAEAAAUAAAAAAKwPUAAAAAAAAAAA
ABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAAAAAAABAAAwAAAAAA
AAAAAAAAAAAQAAQAAAAAAAAAEACvDwgAAAAIAQAAAQAAAAAArA80AAAAAAAAAgAAAAAAAAAAAAAA
AAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAArw8IAAAACQEAAAEAAAAAAKwP
dAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAAAAAA
ABAAAwAAAAAAAAAAAAAAAAAQAAQAAAAAAAAAAACAAv//AAAAABAABQAAAAAAAAAAAAAAAAAQAAYA
AAAAAAAAEACvDwgAAAADAQAAAQAAAAAArA8mAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAPAIoTaAAAAAAAug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsTRAAAAA8A
iBc8AAAAAACJFzQAAAAAAAAAAAAAAAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAAAI3AAAAAAA
AAAAAACAAgHgDwCKE/gLAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsT0gsAAEAA
GhBmBQAABQAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgA
AAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAA
AAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEA
cgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBn
AHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEA
AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA
AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA
AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA
AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA
eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAA
AAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAA
AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF
AAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAA
AAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAA
AAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAA
AAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEB
AAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQA
AABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAA
ACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAAB
BwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAg
AAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAA
AAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAA
AAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4A
bwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAA
AAAAAAAEAAAADgAJABEAAAAaAAEAABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA
AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA
AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA
BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv
AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA
AAAAAAQAAAAOAAkAEQAAABoAAQ8AGxBABQAAEACvDwgAAAAAAQAABQAAAAAAGRDEAQAAAAAAAAAA
AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA
AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB
AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAA
AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5
AAAAAAEGAAAABAAUAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAAAAAInAAA
AAAAAAIAAACcAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAHgAAAAHAAAABAAAAAAAAAEA
AAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAA
AAEGAAAABAAUAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAQAK8PCAAAAAkB
AAABAAAAAAAZEEwDAAAAAAAAAAAAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAA
AQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAAB
AAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAA
AAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBw
AGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQA
AAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAAB
AAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMA
AAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAA
AAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkA
cABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAUAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAA
ABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgA
AAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAA
AQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkA
YQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBh
AHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAA
AAAAPwDZDwwAAAAAANoPBAAAAAAAJQAPAPAP9Q4AAAAA8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAA
AAAAAJ8PBAAAAAYAAAAAAKgPsQAAAFJvdXRpbmcgZXh0ZW5zaW9ucyBmb3IgZGlzY292ZXJ5IG9m
IE11bHRpcHJvdG9jb2wgKE1QTFMpIExhYmVsIFN3aXRjaCALICAgICAgICAgICAgICAgUm91dGVy
IChMU1IpIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBtZXNoIG1lbWJlcnNoaXAgCwtkcmFmdC12
YXNzZXVyLWNjYW1wLWF1dG9tZXNoLTAwLnR4dAAAoQ86AAAAsgAAAAAAAAAAAIsAAAABAAIAAQAc
AAEAAAAABAAAAAQCAAAAAAgCAAAIIAAkAAAAAAwDAAAMAQAYABAAnw8EAAAABQAAAAAAqA9lAQAA
SmVhbi1QaGlsaXBwZSBWYXNzZXVyIChqdmFzc2V1ckBjaXNjby5jb20pDSAgICAgICAgICAgICAg
ICAgICAgICAgICBKZWFuIExvdWlzIExlIFJvdXggKGplYW5sb3Vpcy5sZXJvdXhAZnJhbmNldGVs
ZWNvbS5jb20pDSAgICAgICAgICAgICAgICAgICAgICAgICBQZXRlciBQc2VuYWsgKHBwc2VuYWtA
Y2lzY28uY29tKQ0gICAgICAgICAgICAgICAgICAgICAgICAgU3RlZmFubyBQcmV2aWRpIChzcHJl
dmlkaUBjaXNjby5jb20pIA0gICAgICAgIFNlaXNobyBZYXN1a2F3YSAoeWFzdWthd2Euc2Vpc2hv
QGxhYi5udHQuY28uanApIA0gICAgICAgICAgICAgICAgICAgICAgICAgUGF1bCBNYWJleSAocG1h
YmV5QHF3ZXN0LmNvbSkNAAChD3oAAAArAAAAAAAAEAAAUADKAAAAAAAAGAAAAABQADkAAAAAAAAQ
AABQADcAAAAAAAAYAAAAAFAAAQAAAAAAABAAAFAAfAAAAAAAAgAUABkAAAAABAIAAAQUACEAAAAA
CAIAAAgUAD0AAAAADAIAAAwUAHMAAAAAEAIAABAUAAAAqg86AQAAFwAAAAAAAAASAAAAAAAAAAEA
AAAAAAAAGgAAAAEAAAAAABQAAAAAAAAACQAAAAEAAAABAAEAAAAAAAAAFAAAAAEAAAABAAQAAAAA
AAAAAQAAAAAAAAAaAAAAAQAAAAAABgAAAAAAAAAHAAAAAQAAAAEAAQAAAAAAAAARAAAAAAAAAAEA
AAAAAAAAGgAAAAEAAAAAABEAAAAAAAAAEgAAAAAAAAALAAAAAAAAAAcAAAABAAAAAQAKAAAAAAAA
AAgAAAABAAAAAQABAAAAAAAAAAoAAAABAAAAAQABAAAAAAAAAAMAAAABAAAAAQAEAAAAAAAAAAIA
AAABAAAAAQABAAAAAAAAABsAAAABAAAAAAAFAAAAAAAAAAYAAAABAAAAAQABAAAAAAAAABAAAAAA
AAAAAwAAAAAAAAAPAPIPGAAAAAAA8w8QAAAAAAAAADwAAAAEAAAACAAA8wAA3w8IAAAAFwAAACkA
AAAPAPIPGAAAAAAA8w8QAAAAAAAAAEQAAAAEAAAACAAA8wAA3w8IAAAAWAAAAHoAAAAPAPIPGAAA
AAAA8w8QAAAAAAAAAEcAAAAEAAAACAAA8wAA3w8IAAAAowAAALQAAAAPAPIPGAAAAAAA8w8QAAAA
AAAAAEgAAAAEAAAACAAA8wAA3w8IAAAA4AAAAPIAAAAPAPIPGAAAAAAA8w8QAAAAAAAAAD8AAAAE
AAAACAAA8wAA3w8IAAAADgEAACsBAAAPAPIPGAAAAAAA8w8QAAAAAAAAAEYAAAAEAAAACAAA8wAA
3w8IAAAAUwEAAGMBAAAAAPMDFAAAAAsAAAAEAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACo
DwoAAABCYWNrZ3JvdW5kEACfDwQAAAABAAAAAACoD1wBAAANZHJhZnQtdmFzc2V1ci1jY2FtcC1y
b3V0ZXItaW5mby0wMC50eHQgKENDQU1QKQ0gICAgIERlc2NyaWJlcyBleHRlbnNpb25zIHRvIE1Q
TFMgVHJhZmZpYyBFbmdpbmVlcmluZyByb3V0aW5nIGZvciB0aGUgYWR2ZXJ0aXNlbWVudCBvZiBU
cmFmZmljIEVuZ2luZWVyaW5nIFJvdXRlciBJbmZvcm1hdGlvbiBhbmQgY2FwYWJpbGl0aWVzLiBU
aGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIGZ1bmN0aW9uYWwgZGVzY3JpcHRpb24gb2YgdGhlc2Ug
ZXh0ZW5zaW9ucyB3aGVyZWFzIHByb3RvY29sIHNwZWNpZmljIGZvcm1hdHMgYW5kIG1lY2hhbmlz
bXMgYXJlIGRlc2NyaWJlZCBpbiBzZXBhcmF0ZSBkb2N1bWVudHMuIAkAAKEPbgAAAAEAAAABAJMQ
AAACAOAAAgBQAC8AAAAAALIQAAADAOAAAgAAAAABUAAtAQAAAAAhEAAAAAAAAAABUAABAAAAAAAC
ABIANAAAAAAEggAABAIAFAAmAQAAAAiCAAAIAgAQAAIAAAAADIIAAAwCABQAAACqDxwAAAABAAAA
AQAAAAAAWQEAAAAAAAADAAAAAQAAAAAAAADzAxQAAAAPAAAAAAAAAAIAAAAJAQAAAAAAAAAAnw8E
AAAAAAAAAAAAqA8WAAAAUXVpY2sgb3ZlcnZpZXcvc3VtbWFyeRAAnw8EAAAAAQAAAAAAqA8cAwAA
VGhlcmUgYXJlIG5vdyB0d28gZHJhZnRzOg1kcmFmdC12YXNzZXVyLWNjYW1wLWF1dG8tbWVzaC0w
MC50eHQNZHJhZnQtdmFzc2V1ci1jY2FtcC10ZS1ub2RlLWNhcC0wMC50eHQNVGhlIFBDRSBkaXNj
b3ZlcnkgYXNwZWN0cyB3aWxsIGJlIGRpc2N1c3NlZCBpbiB0aGUgUENFIFdHDQ1UaGUgc2V0IHVw
IG9mIGEgZnVsbCBtZXNoIG9mIE1QTFMgVEUgTFNQcyBhbW9uZyBhIHNldCBvZiBMYWJlbCBTd2l0
Y2ggUm91dGVyIChMU1IpIGlzIGNvbW1vbiBkZXBsb3ltZW50IHNjZW5hcmlvIG9mIE1QTFMgVHJh
ZmZpYyBFbmdpbmVlcmluZyBlaXRoZXIgZm9yIGJhbmR3aWR0aCBvcHRpbWl6YXRpb24sIGJhbmR3
aWR0aCBndWFyYW50ZWVzIG9yIGZhc3QgcmVyb3V0aW5nIHdpdGggTVBMUyBGYXN0IFJlcm91dGUu
IFN1Y2ggZGVwbG95bWVudCByZXF1aXJlcyB0aGUgY29uZmlndXJhdGlvbiBvZiBwb3RlbnRpYWxs
eSBhIGxhcmdlIG51bWJlciBvZiBURSBMU1BzIChvbiB0aGUgb3JkZXIgb2YgdGhlIHNxdWFyZSBv
ZiB0aGUgbnVtYmVyIExTUnMpLiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBJR1AgICAgICAgICAg
KE9TUEYgYW5kIElTLUlTKSB0cmFmZmljIGVuZ2luZWVyaW5nIGV4dGVuc2lvbnMgc28gYXMgdG8g
cHJvdmlkZSBhbiBhdXRvbWF0aWMgZGlzY292ZXJ5IG9mIHRoZSBzZXQgb2YgTFNScyBtZW1iZXJz
IG9mIGEgbWVzaCwgbGVhZGluZyB0byBhbiBhdXRvbWF0aWMgbWVjaGFuaXNtIHRvIHNldCB1cCBU
RSBMU1AgbWVzaChlcykgKGFsc28gcmVmZXJyZWQgdG8gYXMgYSBURSBtZXNoLWdyb3VwKS4gDQAA
oQ+MAAAAGgAAAAAAABAAAFoAhwAAAAEAABAAAFoAewIAAAAAshAAAAMAIiADAAAAAAFaAAEAAAAA
AAAQAABaABoAAAAAAAIAGAAlAAAAAAQCAAAEFAAnAAAAAAgCAAAIFAA5AAAAAAwCAAAMFAACAAAA
ABACAAAQFAB7AgAAAhQCAAIUGAABAAAAABgCAAAYGAAAAKoPqgAAAGUAAAAAAAAAAQAAAAEAAAAA
AIAAAAAAAAAAAQAAAAEAAAAAADoAAAAAAAAAAQAAAAEAAAAAAEMAAAAAAAAAAQAAAAEAAAAAAEIA
AAAAAAAAAQAAAAEAAAAAAEIAAAAAAAAAAQAAAAEAAAAAAEQAAAAAAAAAAQAAAAEAAAAAAEwAAAAA
AAAAAQAAAAEAAAAAAHIAAAAAAAAAAgAAAAEAAAABACsAAAAAAAAAAADzAxQAAAAIAAAAAAAAAAIA
AAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8TAAAAUHJvcG9zZWQgbmV4dCBzdGVwcwAAoQ8UAAAA
FAAAAAAAAAAAABQAAAAAAAIAKAAQAJ8PBAAAAAEAAAAAAKAPnAEAAA0ARABlAGYAaQBuAGkAdABl
AGwAeQAgAG4AbwB0ACAAYQAgAG4AZQB3ACAASQBEACAAIQANAFAAcgBlAHQAdAB5ACAAcwB0AHIA
YQBpAGcAaAB0AGYAbwByAHcAYQByAGQAIABkAHIAYQBmAHQAIAAmICAAbgBvACAAbwB1AHQAcwB0
AGEAbgBkAGkAbgBnACAAaQBzAHMAdQBlAHMAIABhAHMAIABmAGEAcgAgAGEAcwAgAE8AUwBQAEYA
LwBJAFMASQBTACAAaQBzACAAYwBvAG4AYwBlAHIAbgBlAGQALAANAEkAbQBwAGwAZQBtAGUAbgB0
AGEAdABpAG8AbgBzACAAZQB4AGkAcwB0AHMALAAgAHQAZQBjAGgAbgBvAGwAbwBnAHkAIABkAGUA
cABsAG8AeQBlAGQALgANAE4AbwAgAE0AYQBqAG8AcgAgAHAAbABhAG4AbgBlAGQAIABjAGgAYQBu
AGcAZQBzAA0ATQBhAGsAZQAgAGkAdAAgAGEAIABXAEcAIABkAG8AYwB1AG0AZQBuAHQAPwAAAKEP
RAAAAAEAAAAAAAAAAAAaAAAAAACyAAAAAwAiIAMAAAAAAbQAAAAAAAAAAAABAAAAAAAAABoAAAAC
BAAAAgS0AAAAAAgAAAAIAACqDxIAAAABAAAAAQAAAAAAzgAAAAAAAAAAAOoDAAAAAA8A+APaCQAA
AgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAA9MBgAPAHIAAAAP///wAAAAAAgICAAAAAAAC7
4OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAAmWYAAGAA
8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAAAAAAlpaW
AAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPMzAD/UFAA
/5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAAAIAAAAD/
//8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8AM2bMAACw
AABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABgAPAHIAAA
AGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+XAD///8A
YFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQAAIyeoAAA
AKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP//
/////ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAP8AAGQAFAAAANgAAABAAgAAAAAH
AAAA///vAAAAAAD///////8gAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgA
gAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8A
AGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8MAAAAAAEAAAAFAAAgASABAAAAAAAF
AABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAA
AAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAA
AAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAA
AAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAA
AAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAP
AAwEDAUAAA8AAvAEBQAAEAAI8AgAAAAGAAAABgQAAA8AA/CcBAAADwAE8CgAAAABAAnwEAAAAAAA
AAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIAAAASAArwCAAAAAIEAAAACgAAkwAL
8DYAAAB/AAEABQCAAHBKewmHAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA
AAgAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAABANQADwAN8FQAAAAAAJ8PBAAA
AAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxlAACiDwYAAAAhAAAA
AAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAAAwQAAAAKAACDAAvwMAAAAH8AAQAF
AIAAsE17CYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAA8AMgAWAV
Ew8PABHwEAAAAAAAwwsIAAAAAQAAAAIA1AAPAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xp
Y2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZv
dXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAA
AAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LYAAAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEA
BQCAAGBUewmBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF4PIAFg
BooQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAdQADwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA
AAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAOAAAA+A8EAAAAAAAAAA8ABPDuAAAAEgAK8AgAAAAF
BAAAAAoAAIMAC/AwAAAAfwABAAUAgADwWXsJgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA
AQICAAAIAAAQ8AgAAABeD3cGNhCKEA8AEfAQAAAAAADDCwgAAAADAAAACQLUAA8ADfB2AAAAAACf
DwQAAAAEAAAAAACoDyIAAAA2MnRoIElFVEYsIE1pbm5lYXBvbGlzLCBNYXJjaCAyMDA1AAChDxYA
AAAjAAAAAAAACAAAAQAjAAAAAAACAA4AAACqDxoAAAAXAAAAAAAAAAEAAAABAAAAAAALAAAAAAAA
AA8ABPC4AAAAEgAK8AgAAAAGBAAAAAoAAIMAC/AwAAAAfwABAAUAgABQX3sJgQEEAAAIgwEAAAAI
vwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyAQYBWKEA8AEfAQAAAAAADDCwgAAAAE
AAAACALUAA8ADfBAAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIA
AgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEA
AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A
AAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBf
AFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAmKDDASBAIY8gALoPHAAAAEQAZQBmAGEAdQBsAHQA
IABEAGUAcwBpAGcAbgAPAO4DJAIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAAAAAHAPdgDwAM
BJQBAAAPAALwjAEAADAACPAIAAAAAwAAAAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA
AAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/Ae
AAAAfwAAAAQAgADwIX0JvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAAB6A2AAgBYYBw8AEfAQAAAA
AADDCwgAAAAAAAAADwDUAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAg
AgAAUwAL8B4AAAB/AAAABACAAPCMegm/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPAJAADwFUAO
DwAR8BAAAAAAAMMLCAAAAAEAAAAQANQADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAI
AAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD
CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAA
AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAJigwwHAxiKP
DwDuA5EKAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwD3YA8ADARBCgAADwAC8DkKAABA
AAjwCAAAAAYAAAAIKAAADwAD8NEJAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA
CvAIAAAAACgAAAUAAAAPAATwcgAAABIACvAIAAAAAigAACACAABTAAvwHgAAAH8AAAAEAIAAAExu
C78BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAAAAnAWcV0AIPABHwEAAAAAAAwwsIAAAAAAAAAA0A
1AAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADKAAAIAIAAFMAC/AeAAAAfwAA
AAQAgABgQWwLvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAAAQAgAAJhaHDw8AEfAQAAAAAADDCwgA
AAABAAAADgDUAA8ADfAMAAAAAACeDwQAAAABAAAADwAE8JEDAAASAArwCAAAAAYoAAAACgAAgwAL
8DAAAAB/AAAABQCAALBdawuBAQQAAAiDAQAAAAi/AQAAEQDAAQEAAAj/AQAACQABAgIAAAgAABDw
CAAAANAFAABACzAPDwAR8KAAAAAPAIgTmAAAAA8AihOQAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5
AAAAixNyAAAAAACsD2oAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAIA
AAAAAAAAAAAADwAN8IkCAAAAAJ8PBAAAAAEAAAAAAKgPfwEAAA1kcmFmdC12YXNzZXVyLW9zcGYt
dGUtY2Fwcy0wMC50eHQgKE9TUEYpDQlUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBPU1BGIHRyYWZm
aWMgZW5naW5lZXJpbmcgY2FwYWJpbGl0eSBUTFZzIHJlbGF0ZWQgdG8gdmFyaW91cyBNUExTIFRy
YWZmaWMgRW5naW5lZXJpbmcgY2FwYWJpbGl0aWVzLiBUaGVzZSBPU1BGIFRFIGNhcGFiaWxpdHkg
VExWcyBhcmUgY2FycmllZCB3aXRoaW4gdGhlIE9TUEYgcm91dGVyIGluZm9ybWF0aW9uIExTQSAo
b3BhcXVlIHR5cGUgb2YgNCwgb3BhcXVlIElEIG9mIDApIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRm
LW9zcGYtY2FwLTAyLnR4dC4NZHJhZnQtdmFzc2V1ci1pc2lzLXRlLWNhcHMtMDAudHh0IChJUy1J
UykNCUlTLUlTIHNwZWNpZmljcw0JAAChD9QAAAABAAAAAQCTEAAAAgDgAAIAUAApAAAAAACyEAAA
AwDgAAIAAAAAAVAAGQEAAAAAIRAAAAAAAAAAAVAAKgAAAAAAshAAAAMA4AACAAAAAAFQABMAAAAA
ALMQAAACAOAAAgAAAAABUAABAAAAAACCAAIADgApAAAAAASCAAAEAgAUAP0AAAAACIIAAAgCABAA
GgAAAAEMggABDAIAEAACAAAAABCCAAAQAgAQACsAAAAAFIIAABQCABQAEAAAAAAYggAAGAIADwAC
AAAAAByCAAAcAgAUAAAAqg8SAAAAAQAAAAEAAAAAAH8BAAAAAAAADwAE8GQAAABCAQrwCAAAAAco
AACACgAAowAL8DwAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAYAAAADLAdSUAADR
AQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAGAJ4ArADGAJDwAE8KAEAAASAArwCAAAAAgoAAAACgAA
gwAL8DAAAAB/AAAABQCAAMC2aguBAQQAAAiDAQAAAAi/AQAAEQDAAQEAAAj/AQAACQABAgIAAAgA
ABDwCAAAAMAGcAuAFjcODwAR8G4AAAAPAIgTZgAAAA8AihNeAAAAAAC6Dw4AAABfAF8AXwBQAFAA
VAA5AAAAixNAAAAAAACsDzgAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAgAAAAAA
AAAAAAAAAAACAAAAAAAAAAAAAA8ADfDKAwAAAACfDwQAAAABAAAAAACgDxoDAAAgACAAIAAgACAA
IABUAEUAIABUAEwAVgAgAHIAZQBsAGEAdABlAGQAIAB0AG8AIAB2AGEAcgBpAG8AdQBzACAAYwBh
AHAAYQBiAGkAbABpAHQAaQBlAHMAIABmAHUAbgBjAHQAaQBvAG4AYQBsAGkAdABpAGUAcwANAFAA
QwBFACAAKABQAGEAdABoACAAQwBvAG0AcAB1AHQAYQB0AGkAbwBuACAARQBsAGUAbQBlAG4AdAAp
ACAAZABpAHMAYwBvAHYAZQByAHkAOgAgAHUAcwBlAGQAIABpAG4AIAB2AGEAcgBpAG8AdQBzACAA
YwBvAG4AdABlAHgAdABzACAAcwB1AGMAaAAgAGEAcwAgAEkAbgB0AGUAcgAtAGQAbwBtAGEAaQBu
ACwAIABDAFAAVQAgAGkAbgB0AGUAbgBzAGkAdgBlACAAVABFACAATABTAFAAIABwAGEAdABoACAA
YwBvAG0AcAB1AHQAYQB0AGkAbwBuACAAKABOAFAALQBjAG8AbQBwAGwAZQB0AGUAIABwAGIAcwAs
ACAAJiApACwAIABHAE0AUABMAFMALAAgACYgIAANAFQARQAtAE0ARQBTAEgALQBHAFIATwBVAFAA
OgAgAGEAbABsAG8AdwBzACAAZgBvAHIAIABhAHUAdABvAC0AZABpAHMAYwBvAHYAZQByAHkAIABv
AGYAIABUAEUAIABtAGUAcwBoACAAZwByAG8AdQBwACAAbQBlAG0AYgBlAHIAcwANAFQARQAtAE4A
TwBEAEUALQBDAEEAUAA6ACAAdQBzAGUAZAAgAG8AZgAgAHQAaABlACAAYQBkAHYAZQByAHQAaQBz
AGUAbQBlAG4AdAAgAG8AZgAgAGMAbwBuAHQAcgBvAGwAIABhAG4AZAAgAGQAYQB0AGEAIABwAGwA
YQBuAGUAIABuAG8AZABlACAAYwBhAHAAYQBiAGkAbABpAHQAaQBlAHMAIAAoAGUALgBnAC4AIABQ
ADIATQBQACAAVABFACAAYwBhAHAAYQBiAGwAZQAgAG4AbwBkAGUAKQANAAAAoQ9oAAAAPQAAAAEA
kxAAAAIA4AACAFAAUAEAAAEAkgAAAAMA4AACAAEAAAABAJMQAAACAOAAAgBQAAYAAAAAAIIAAgAO
ADcAAAABBIIAAQQCAA4AnwAAAAAIggAACAIADgCyAAAAAAwCAAAMDgAAAKoPJAAAAAYAAAABAAAA
AADDAAAAAAAAAAMAAAABAAAAAQDCAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABKAAAAAwAAIMAC/Aw
AAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAA
AAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8A7gPwAQAAAgDvAxgAAAABAAAADQ4A
AAAAAAAAAACAAAAAAAcA92APAAwEoAEAAA8AAvCYAQAAIAAI8AgAAAADAAAAAzgAAA8AA/AwAQAA
DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAA4AAAFAAAADwAE8HgAAAAS
AArwCAAAAAI4AAAgAgAAYwAL8CQAAAB/AAAABACAAJAefAm/AQAAAQD/AQAAAQABAwIEAACIAwAA
AAAAABDwCAAAAAAAJwFnFdACDwAR8BAAAAAAAMMLCAAAAAAAAAANANQADwAN8AwAAAAAAJ4PBAAA
AAAAAAAPAATweAAAABIACvAIAAAAAzgAACACAABjAAvwJAAAAH8AAAAEAIAAICB8Cb8BAAABAP8B
AAABAAEDAwQAAIgDAAAAAAAAEPAIAAAAcAIWAIAWXw8PABHwEAAAAAAAwwsIAAAAAQAAAA4A1AAP
AA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABOAAAAAwAAIMAC/AwAAAAgQEAAAAI
gwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAA
AICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8A7gMkAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACA
AAAAAAcA92APAAwElAEAAA8AAvCMAQAAUAAI8AgAAAADAAAAAxQAAA8AA/AkAQAADwAE8CgAAAAB
AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAADwAE8HIAAAASAArwCAAAAAIU
AAAgAgAAUwAL8B4AAAB/AAAABACAAGBnbgu/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAK0AAABg
FZcCDwAR8BAAAAAAAMMLCAAAAAAAAAANANQADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIA
CvAIAAAAAxQAACACAABTAAvwHgAAAH8AAAAEAIAA0DNuC78BAAABAP8BAAABAAEDAwQAAAAAEPAI
AAAAcAJgAOIVdg4PABHwEAAAAAAAwwsIAAAAAQAAAA4A1AAPAA3wDAAAAAAAng8EAAAAAQAAAA8A
BPBIAAAAEgAK8AgAAAABFAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES
ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkA
mcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4I
AAAAnKDDAaA8vrIQABEQYwAAAAAGAAB4nLtwXvDBwo1SDxnQgB0DM8O//5wMbEhijFAMBgIMQPn/
/0FMGA0C/0fBkAJ/gfjfQDtiFAwYYAhCz/mkASYGVpQ8j1ex2Ra95cpHGf8RUkciINp+GoGhbD8A
0NTyeQAAchcwAAAAAQAwAAAAAABGJAAAKC4AAAgAEADlPAAACwAQAFQwAAAPABAA7ToAABIAEAAR
PwAAAAD1DxwAAAAAAQAA6RUAAwAAAAB8PwAAAQAAABIAAAABANwwAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA
AAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA
/v////7/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQ
k5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rgADAAC8AgAAEAAAAAEAAACIAAAAAwAAAJAAAAAP
AAAAqAAAAAQAAAC4AAAABgAAAMAAAAAHAAAAyAAAAAgAAADQAAAACQAAANgAAAAKAAAA4AAAABcA
AADoAAAACwAAAPAAAAAQAAAA+AAAABMAAAAAAQAAFgAAAAgBAAANAAAAEAEAAAwAAABaAgAAAgAA
ABAnAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93AAAeAAAABwAAAE9sZGRvZwABAwAAANg/AAADAAAA
IwAAAAMAAAAEAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAABCwALAAAAAAAAAAsAAAAA
AAAACwAAAAAAAAALAAAAAAAAAB4QAAAJAAAABgAAAEFyaWFsABEAAABBcmlhbCBVbmljb2RlIE1T
AAoAAABXaW5nZGluZ3MABgAAAFRpbWVzAA8AAABEZWZhdWx0IERlc2lnbgCyAAAAUm91dGluZyBl
eHRlbnNpb25zIGZvciBkaXNjb3Zlcnkgb2YgTXVsdGlwcm90b2NvbCAoTVBMUykgTGFiZWwgU3dp
dGNoICAgICAgICAgICAgICAgICD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCr
kQgAKyez2TAAAAAULAAACwAAAAEAAABgAAAAAgAAAGgAAAAEAAAAeAAAAAgAAACIAAAACQAAAJwA
AAASAAAAqAAAAAoAAADIAAAADAAAANQAAAANAAAA4AAAAA8AAADsAAAAEQAAAPQAAAACAAAAECcA
AB4AAAAIAAAAU2xpZGUgMQAeAAAACAAAACBBZHJpYW4AHgAAAAsAAABKUCBWYXNzZXVyAHseAAAA
BAAAADEyOAAeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AAAAAkAAAABAcxaK3AEAAEAAAACA
P1GRmKDDAUAAAAAApk552SPFAQMAAABjAQAARwAAABgrAAD+////UElDVCsQAAAAAACHALQAEQL/
DAD//gAAAEgAAABIAAAAAAAAAIcAtAAAAAAAHgABAAoAAAAAAIcAtACaAAAA/4LQAAAAAACHALQA
AAAEAAAAAABIAAAASAAAABAAIAAEAAgAAAAgAAgRcAAveiwAAAAAAIcAtAAAAAAAhwC0AAAADIH/
gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B
/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/
gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B
/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/
gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wCdgf/D//4A9/8BAADx/wAA9/8AAPT/
AAD3/wEAAOb/BgD/AAD//wD9/wMA/wAA9v8AAPb/AADU//4A9/8BAADx/wAA9/8AAPT/AAD3/wEA
AOb/BgD/AAD//wD9/wMA/wAA9v8AAPb/AADU//4A9/8BAADx/wAA9/8AAPT/AAD3/wEAAOb/BgD/
AAD//wD9/wMA/wAA9v8AAPb/AADe/wGNgf/D/woA//8A/wAA/wD///wAA/8A///+AAH///4ABP//
AAD//gAD/wD///4AFf8AAP8A/wD//wAA/wAA/wAA/wD/AP/9AAz/AAD/AAD/AAD/AP///QAO/wD/
/wD/AAD/AAD/AAD//gAB///7AAT/AP8A//4ADv8AAP8AAP//AAD/AAD/ANT/CgD//wD/AAD/AP//
/AAD/wD///4AAf///gAE//8AAP/+AAP/AP///gAV/wAA/wD/AP//AAD/AAD/AAD/AP8A//0ADP8A
AP8AAP8AAP8A///9AA7/AP//AP8AAP8AAP8AAP/+AAH///sABP8A/wD//gAO/wAA/wAA//8AAP8A
AP8A1P8KAP//AP8AAP8A///8AAP/AP///gAB///+AAT//wAA//4AA/8A///+ABX/AAD/AP8A//8A
AP8AAP8AAP8A/wD//QAM/wAA/wAA/wAA/wD///0ADv8A//8A/wAA/wAA/wAA//4AAf//+wAE/wD/
AP/+AA7/AAD/AAD//wAA/wAA/wDe/wGQgf/D//4ACf8A//8AAP//AP/9AAn/AAD//wD/AP///gAP
/wAA//8AAP8AAP//AAD///4AAv8AAP3/AwAA///+AAP/AP///gAO//8A//8A//8AAP8AAP///gAL
/wD/AP//AP8A/wD//QAE//8AAP/9AAD//QAQ//8A/wAA//8AAP//AP//AADU//4ACf8A//8AAP//
AP/9AAn/AAD//wD/AP///gAP/wAA//8AAP8AAP//AAD///4AAv8AAP3/AwAA///+AAP/AP///gAO
//8A//8A//8AAP8AAP///gAL/wD/AP//AP8A/wD//QAE//8AAP/9AAD//QAQ//8A/wAA//8AAP//
AP//AADU//4ACf8A//8AAP//AP/9AAn/AAD//wD/AP///gAP/wAA//8AAP8AAP//AAD///4AAv8A
AP3/AwAA///+AAP/AP///gAO//8A//8A//8AAP8AAP///gAL/wD/AP//AP8A/wD//QAE//8AAP/9
AAD//QAQ//8A/wAA//8AAP//AP//AADe/wGNgf/D/wwA/wD/AP//AAD//wD//gAH//8AAP//AP/+
AAP/AAD//AAD//8A//0AGf//AAD//wD/AAD//wAA//8AAP//AP//AAD//gAG//8A//8A//sADf//
AAD/AP//AP8A/wD//QAE//8AAP/+ABb//wAA/wD//wD/AAD//wAA//8A//8AANT/DAD/AP8A//8A
AP//AP/+AAf//wAA//8A//4AA/8AAP/8AAP//wD//QAZ//8AAP//AP8AAP//AAD//wAA//8A//8A
AP/+AAb//wD//wD/+wAN//8AAP8A//8A/wD/AP/9AAT//wAA//4AFv//AAD/AP//AP8AAP//AAD/
/wD//wAA1P8MAP8A/wD//wAA//8A//4AB///AAD//wD//gAD/wAA//wAA///AP/9ABn//wAA//8A
/wAA//8AAP//AAD//wD//wAA//4ABv//AP//AP/7AA3//wAA/wD//wD/AP8A//0ABP//AAD//gAW
//8AAP8A//8A/wAA//8AAP//AP//AADe/wFsgf/D/wQA/wAA//4AAP/+AAD//gAD//8A//4AAf//
/gAE/wD/AP/+AAH///wAAP/9AAH///0AA///AP/9AP7/+gAD/wAA//4AA/8AAP/+AAX//wAA///+
AAT/AP8A//4AAP/9AAD/+gAB///+AAL/AP/+AAP/AAD//QDU/wQA/wAA//4AAP/+AAD//gAD//8A
//4AAf///gAE/wD/AP/+AAH///wAAP/9AAH///0AA///AP/9AP7/+gAD/wAA//4AA/8AAP/+AAX/
/wAA///+AAT/AP8A//4AAP/9AAD/+gAB///+AAL/AP/+AAP/AAD//QDU/wQA/wAA//4AAP/+AAD/
/gAD//8A//4AAf///gAE/wD/AP/+AAH///wAAP/9AAH///0AA///AP/9AP7/+gAD/wAA//4AA/8A
AP/+AAX//wAA///+AAT/AP8A//4AAP/9AAD/+gAB///+AAL/AP/+AAP/AAD//QDe/wAogf+w//0A
wP8AAOv/AACq//0AwP8AAOv/AACq//0AwP8AAOv/AADH/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B
/4H/sf8AiIH/k//+AAP//wD//gAB/wD+//0A/v8AAPz/AAD7/wIA///+APz/AgD/AP7/AACC//4A
A///AP/+AAH/AP7//QD+/wAA/P8AAPv/AgD///4A/P8CAP8A/v8AAIL//gAD//8A//4AAf8A/v/9
AP7/AAD8/wAA+/8CAP///gD8/wIA/wD+/wAAvP8AqYH/k//+AAz/AAD/AP8A/wD//wAA/v8DAP//
AP7//gAD/wD///4ACP8AAP//AP8A//0AAP/+AAH/AIT//gAM/wAA/wD/AP8A//8AAP7/AwD//wD+
//4AA/8A///+AAj/AAD//wD/AP/9AAD//gAB/wCE//4ADP8AAP8A/wD/AP//AAD+/wMA//8A/v/+
AAP/AP///gAI/wAA//8A/wD//QAA//4AAf8Avv8ArIH/lP8DAP8A//4AAP/+AAH/AP7//gAE/wD/
/wD9//4AB/8AAP//AP///QAN/wD/AAD/AAD//wAA/wCG/wMA/wD//gAA//4AAf8A/v/+AAT/AP//
AP3//gAH/wAA//8A///9AA3/AP8AAP8AAP//AAD/AIb/AwD/AP/+AAD//gAB/wD+//4ABP8A//8A
/f/+AAf/AAD//wD///0ADf8A/wAA/wAA//8AAP8Av/8AqYH/lP8DAP8A//4AAf8A/v8NAP//AP//
AP8A//8A///9AAH///wABf8A//8A//wACP8AAP//AP//AIb/AwD/AP/+AAH/AP7/DQD//wD//wD/
AP//AP///QAB///8AAX/AP//AP/8AAj/AAD//wD//wCG/wMA/wD//gAB/wD+/w0A//8A//8A/wD/
/wD///0AAf///AAF/wD//wD//AAI/wAA//8A//8Av/8AoIH/lP8DAP8A//4AAf8A/v/+AAD//gAD
/wD///cAAP/+AAH///4ACP8A/wD/AP8A//4AAv//AIb/AwD/AP/+AAH/AP7//gAA//4AA/8A///3
AAD//gAB///+AAj/AP8A/wD/AP/+AAL//wCG/wMA/wD//gAB/wD+//4AAP/+AAP/AP//9wAA//4A
Af///gAI/wD/AP8A/wD//gAC//8Av/8AIIH/k/8AAPD/AACB/+D/AADw/wAAgf/g/wAA8P8AAJr/
AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AKyB/67//gD3/wAA+v8C
AP8A/v/+AAD//gAD/wD///0A+/8DAP8AAPz//gD5/wAA9f8AAPf//AAA//0As//+APf/AAD6/wIA
/wD+//4AAP/+AAP/AP///QD7/wMA/wAA/P/+APn/AAD1/wAA9//8AAD//QCz//4A9/8AAPr/AgD/
AP7//gAA//4AA/8A///9APv/AwD/AAD8//4A+f8AAPX/AAD3//wAAP/9ANL/AS2B/67/CgD//wD/
AAD/AP///gAA//4ACf8A/wD/AP//AAD+/wUA//8A/wD+/wMA/wD/+QAM/wAA//8A//8A/wD///wA
Bv8A//8AAP/+AAb/AAD/AP///gAI//8A//8A//8A/v8AALT/CgD//wD/AAD/AP///gAA//4ACf8A
/wD/AP//AAD+/wUA//8A/wD+/wMA/wD/+QAM/wAA//8A//8A/wD///wABv8A//8AAP/+AAb/AAD/
AP///gAI//8A//8A//8A/v8AALT/CgD//wD/AAD/AP///gAA//4ACf8A/wD/AP//AAD+/wUA//8A
/wD+/wMA/wD/+QAM/wAA//8A//8A/wD///wABv8A//8AAP/+AAb/AAD/AP///gAI//8A//8A//8A
/v8AANP/ASSB/67//gAU/wD//wAA//8A/wAA//8AAP8A//8A/v/+AAD//gAC//8A/v8JAP8AAP//
AP8A//4A/f/8AAT/AAD///0AB/8AAP//AP///AAH/wAA//8A/wD+/wIA///+AAH/ALT//gAU/wD/
/wAA//8A/wAA//8AAP8A//8A/v/+AAD//gAC//8A/v8JAP8AAP//AP8A//4A/f/8AAT/AAD///0A
B/8AAP//AP///AAH/wAA//8A/wD+/wIA///+AAH/ALT//gAU/wD//wAA//8A/wAA//8AAP8A//8A
/v/+AAD//gAC//8A/v8JAP8AAP//AP8A//4A/f/8AAT/AAD///0AB/8AAP//AP///AAH/wAA//8A
/wD+/wIA///+AAH/ANP/ASeB/67/DAD/AP8A//8AAP//AP/8ABL//wD//wD//wD//wD/AP8A//8A
/v8DAP8A//4AAv8A//4A/f8JAP//AP//AAD///4AAf//+QAL/wAA//8AAP//AP8A/v8DAP//AP7/
AAC0/wwA/wD/AP//AAD//wD//AAS//8A//8A//8A//8A/wD/AP//AP7/AwD/AP/+AAL/AP/+AP3/
CQD//wD//wAA///+AAH///kAC/8AAP//AAD//wD/AP7/AwD//wD+/wAAtP8MAP8A/wD//wAA//8A
//wAEv//AP//AP//AP//AP8A/wD//wD+/wMA/wD//gAC/wD//gD9/wkA//8A//8AAP///gAB///5
AAv/AAD//wAA//8A/wD+/wMA//8A/v8AANP/ATmB/67/BAD/AAD//gAA//4AAv8A//4ABP//AP//
/gAA//4ABv8A/wAA/wD+/wMA/wD//gAJ/wD/AAD/AAD///0AA///AP/8AAb//wD/AAD//gAG/wAA
//8A//4AAf8A/v8CAP///gAB/wC0/wQA/wAA//4AAP/+AAL/AP/+AAT//wD///4AAP/+AAb/AP8A
AP8A/v8DAP8A//4ACf8A/wAA/wAA///9AAP//wD//AAG//8A/wAA//4ABv8AAP//AP/+AAH/AP7/
AgD///4AAf8AtP8EAP8AAP/+AAD//gAC/wD//gAE//8A///+AAD//gAG/wD/AAD/AP7/AwD/AP/+
AAn/AP8AAP8AAP///QAD//8A//wABv//AP8AAP/+AAb/AAD//wD//gAB/wD+/wIA///+AAH/ANP/
AEyB/5n/AAD0/wAA5f/9AO///QAC//8A+f8AAJ7/AAD0/wAA5f/9AO///QAC//8A+f8AAJ7/AAD0
/wAA5f/9AO///QAC//8A+f8AANL/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wA4gf+E/wAA
7v8AAPb/AAD+/wAAgf/y/wAA7v8AAPb/AAD+/wAAgf/y/wAA7v8AAPb/AAD+/wAAu/8ApoH/kP8J
AP8A/wD//wAA//4ACv8A//8A/wD/AP///gAJ/wD/AP8A/wD///4AAP/9AAb/AP8AAP8Agf8JAP8A
/wD//wAA//4ACv8A//8A/wD/AP///gAJ/wD/AP8A/wD///4AAP/9AAb/AP8AAP8Agf8JAP8A/wD/
/wAA//4ACv8A//8A/wD/AP///gAJ/wD/AP8A/wD///4AAP/9AAb/AP8AAP8Avv8AqYH/kP8eAAD/
AP8AAP//AP//AAD/AP8AAP8A/wAA//8AAP8A//4ABP8AAP///gAE//8AAP/9AAH/AIL/HgAA/wD/
AAD//wD//wAA/wD/AAD/AP8AAP//AAD/AP/+AAT/AAD///4ABP//AAD//QAB/wCC/x4AAP8A/wAA
//8A//8AAP8A/wAA/wD/AAD//wAA/wD//gAE/wAA///+AAT//wAA//0AAf8Av/8AnYH/kP8EAP//
AP/9AAD//gAI//8A/wD//wD//AAH//8A/wAA///8AAH///4AAf///gAC//8Agv8EAP//AP/9AAD/
/gAI//8A/wD//wD//AAH//8A/wAA///8AAH///4AAf///gAC//8Agv8EAP//AP/9AAD//gAI//8A
/wD//wD//AAH//8A/wAA///8AAH///4AAf///gAC//8Av/8AjoH/kP8GAP//AP8A//sACv//AP8A
//8A/wD//gAD//8A//wAAP/+AAD//QAB///7AIL/BgD//wD/AP/7AAr//wD/AP//AP8A//4AA///
AP/8AAD//gAA//0AAf//+wCC/wYA//8A/wD/+wAK//8A/wD//wD/AP/+AAP//wD//AAA//4AAP/9
AAH///sAv/8AFoH/gf/f/wAAgf/O/wAAgf/O/wAAvP8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B
/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/
sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x
/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ANIH/p/8AAP7/AADF/wAA/P/7AJr/AAD+/wAA
xf8AAPz/+wCa/wAA/v8AAMX/AAD8//sAwP8A5YH/qP/+AAD//QD+/wwA/wAA/wD/AP8A/wD//gD9
/wUA//8A///+AAD//gD9/wIAAP/+AAr/AP8AAP8A/wD///4A/f8GAP8AAP8A//sAov/+AAD//QD+
/wwA/wAA/wD/AP8A/wD//gD9/wUA//8A///+AAD//gD9/wIAAP/+AAr/AP8AAP8A/wD///4A/f8G
AP8AAP8A//sAov/+AAD//QD+/wwA/wAA/wD/AP8A/wD//gD9/wUA//8A///+AAD//gD9/wIAAP/+
AAr/AP8AAP8A/wD///4A/f8GAP8AAP8A//sAx/8A3IH/qf8EAP8A///+AAD//AAE/wD/AP/8AAP/
AAD//QAC//8A/v/7AAD//gAI/wAA/wAA/wD/+QAD/wAA//wACv8AAP8A/wD//wAAov8EAP8A///+
AAD//AAE/wD/AP/8AAP/AAD//QAC//8A/v/7AAD//gAI/wAA/wAA/wD/+QAD/wAA//wACv8AAP8A
/wD//wAAov8EAP8A///+AAD//AAE/wD/AP/8AAP/AAD//QAC//8A/v/7AAD//gAI/wAA/wAA/wD/
+QAD/wAA//wACv8AAP8A/wD//wAAxv8AlIH/qf/+AAX/AAD/AAD9//MA/f/4AP7/AQAA/v/4AAH/
AP7/+wAB/wD9/wQA//8A//oAo//+AAX/AAD/AAD9//MA/f/4AP7/AQAA/v/4AAH/AP7/+wAB/wD9
/wQA//8A//oAo//+AAX/AAD/AAD9//MA/f/4AP7/AQAA/v/4AAH/AP7/+wAB/wD9/wQA//8A//oA
x/8AFoH/gf/+/wAAgf/O/wAAgf/O/wAAnf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB
/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/
gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B
/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wBhgf+e/wQAAP8A//4A+v8AAOX/
AADy/wEAAP7/AADp/wAAqP8EAAD/AP/+APr/AADl/wCZ8v8BmZn+/wCZ6f8AAKj/BAAA/wD//gD6
/wAA5f8AmfL/AZmZ/v8Amen/AADX/wDlgf+m/wMA/wD//gAC/wD/9wAP/wD/AP8A/wD/AP8A/wAA
//4A9P8MAAD//wD/AP8A/wAA//sADP8AAP8A/wD/AP//AP/+AAH/APj/AACw/wMA/wD//gAC/wD/
9wAP/wD/AP8A/wD/AP8A/wAA//4A9P8MmZn//5n/mf+Z/5mZ//uZDP+Zmf+Z/5n/mf//mf/+mQH/
mfj/AACw/wMA/wD//gAC/wD/9wAP/wD/AP8A/wD/AP8A/wAA//4A9P8MmZn//5n/mf+Z/5mZ//uZ
DP+Zmf+Z/5n/mf//mf/+mQH/mfj/AADX/wCggf+m//cAAP/7AAL/AP/8AAH///cAAf8A9P/+AAD/
9AAD/wAA//0AB/8A/wAA/wD//QD4/wAAsP/3AAD/+wAC/wD//AAB///3AAH/APT//pkA//SZA/+Z
mf/9mQf/mf+Zmf+Z//2Z+P8AALD/9wAA//sAAv8A//wAAf//9wAB/wD0//6ZAP/0mQP/mZn//ZkH
/5n/mZn/mf/9mfj/AADX/wBcgf+n//oABv//AP//AP/4AAP//wD/9gAB/wD0/9IAsf/6AAb//wD/
/wD/+AAD//8A//YAAf8A9P/TmQAAsf/6AAb//wD//wD/+AAD//8A//YAAf8A9P/TmQAA1/8AJoH/
lv8CAP8A4P/SAKD/AgD/AOD/05kAAKD/AgD/AOD/05kAANf/AAyB/4H/gf+B/4H/sf8AlIH/n/8A
APz/AAD+/wAA/f/+AOz/AAD7/wAA/f8AAPf/AAD2/wQAAP//APb/AADh/wAAyf8AAPz/AAD+/wAA
/f/+AOz/AJn7/wCZ/f8Amff/AJn2/wSZmf//mfb/AJnh/wAAyf8AAPz/AAD+/wAA/f/+AOz/AJn7
/wCZ/f8Amff/AJn2/wSZmf//mfb/AJnh/wAA9/8BLYH/p/8DAP8A//4AGv8A//8AAP8A/wD/AP//
AP8A/wD/AAD/AP//APT/AwD/AP/9AAb/AAD/AP8A+f8BAP/8AAL/AP/2AAz/AP8AAP8AAP8A/wD/
/gAB/wD0/wEA//4ABP8A//8A0f8DAP8A//4AGv8A//8AAP8A/wD/AP//AP8A/wD/AAD/AP//APT/
A5n/mf/9mQb/mZn/mf+Z+f8Bmf/8mQL/mf/2mQz/mf+Zmf+Zmf+Z/5n//pkB/5n0/wGZ//6ZBP+Z
//8A0f8DAP8A//4AGv8A//8AAP8A/wD/AP//AP8A/wD/AAD/AP//APT/A5n/mf/9mQb/mZn/mf+Z
+f8Bmf/8mQL/mf/2mQz/mf+Zmf+Zmf+Z/5n//pkB/5n0/wGZ//6ZBP+Z//8A9/8A7oH/p//6AAT/
AP8A//wAAv8A//wACP8A/wAA/wD/APT/+AAA//wA+f/8AAP/AAD//QAA//4AAP/9AAD/+AAC/wD/
/QD1/wMA/wD//QAC//8A0f/6AAT/AP8A//wAAv8A//wACP8A/wAA/wD/APT/+JkA//yZ+f/8mQP/
mZn//ZkA//6ZAP/9mQD/+JkC/5n//Zn1/wOZ/5n//ZkC//8A0f/6AAT/AP8A//wAAv8A//wACP8A
/wAA/wD/APT/+JkA//yZ+f/8mQP/mZn//ZkA//6ZAP/9mQD/+JkC/5n//Zn1/wOZ/5n//ZkC//8A
9/8AWYH/qP/6AAH///gAAP/9AAL/AP/7AAL//wD0/6wA0v/6AAH///gAAP/9AAL/AP/7AAL//wD0
/62ZAADS//oAAf//+AAA//0AAv8A//sAAv//APT/rZkAAPf/ABaB/4H/+P+sAKL/rZkAAKL/rZkA
APf/AAyB/4H/gf+B/4H/sf8AYYH/qP8BAAD1/wEAAPj/AADt/wAA/v8BAAD+/wAA6P8AAJ//AQAA
9f8BAAD4/wAA7f8Amf7/AZmZ/v8Amej/AACf/wEAAPX/AQAA+P8AAO3/AJn+/wGZmf7/AJno/wAA
xP8A1oH/qP8GAP8A/wAA//4A/f8FAP8A/wD//gAC/wAA+/8BAP/9AAL/AP/+AAP/AAD//AAM/wAA
/wD/AP8A//8A//4AAf8A9/8AAJ//BgD/AP8AAP/+AP3/BQD/AP8A//4AAv8AAPv/AQD//ZkC/5n/
/pkD/5mZ//yZDP+Zmf+Z/5n/mf//mf/+mQH/mff/AACf/wYA/wD/AAD//gD9/wUA/wD/AP/+AAL/
AAD7/wEA//2ZAv+Z//6ZA/+Zmf/8mQz/mZn/mf+Z/5n//5n//pkB/5n3/wAAxP8Ar4H/qP8CAAD/
+wD8/wIAAP/7AAD//gD8/wUA/wD/AP/7AAD/+wAD/wAA//0AB/8A/wAA/wD//QD3/wAAn/8CAAD/
+wD8/wIAAP/7AAD//gD8/wUA/5n/mf/7mQD/+5kD/5mZ//2ZB/+Z/5mZ/5n//Zn3/wAAn/8CAAD/
+wD8/wIAAP/7AAD//gD8/wUA/5n/mf/7mQD/+5kD/5mZ//2ZB/+Z/5mZ/5n//Zn3/wAAxP8AWYH/
qP8CAP//+wD8/wIA///8AAD//QD8/wEA/9EAn/8CAP//+wD8/wIA///8AAD//QD8/wEA/9KZAACf
/wIA///7APz/AgD///wAAP/9APz/AQD/0pkAAMT/ABiB/4b/0QCB//3/0pkAAIH//f/SmQAAxP8A
DIH/gf+B/4H/gf+x/wB5gf+n/wAA/P8AAPv/AQAA+/8DAP//AOz/BwD//wD//wAA/v8AAOn/AACg
/wAA/P8AAPv/AQAA+/8DAP//AOz/B5n//5n//5mZ/v8Amen/AACg/wAA/P8AAPv/AQAA+/8DAP//
AOz/B5n//5n//5mZ/v8Amen/AADG/wC+gf+o/wcA//8A/wAA//4ABP8A/wD//AAG/wD/AAD/APb/
+gAC/wD/+gAM/wAA/wD/AP8A//8A//4AAf8A+P8AAKH/BwD//wD/AAD//gAE/wD/AP/8AAb/AP8A
AP8A9v/6mQL/mf/6mQz/mZn/mf+Z/5n//5n//pkB/5n4/wAAof8HAP//AP8AAP/+AAT/AP8A//wA
Bv8A/wAA/wD2//qZAv+Z//qZDP+Zmf+Z/5n/mf//mf/+mQH/mfj/AADG/wCXgf+n//sAAP/9AAD/
/gAA//gAAf8A9//+AAD/9QAD/wAA//0AB/8A/wAA/wD//QD4/wAAoP/7AAD//QAA//4AAP/4AAH/
APf//pkA//WZA/+Zmf/9mQf/mf+Zmf+Z//2Z+P8AAKD/+wAA//0AAP/+AAD/+AAB/wD3//6ZAP/1
mQP/mZn//ZkH/5n/mZn/mf/9mfj/AADG/wBTgf+o//cABv8AAP8A///+AAD//AAB/wD3/9MAof/3
AAb/AAD/AP///gAA//wAAf8A9//UmQAAof/3AAb/AAD/AP///gAA//wAAf8A9//UmQAAxv8AGIH/
gv/TAIH/+//UmQAAgf/7/9SZAADG/wAMgf+B/4H/gf+B/7H/AJSB/6f/AAD+/wMA//8A+f8AAPn/
AADo/wAA7f8DAP//APz/BgAA/wD//wDp/wAA/f8AAMP/AAD+/wMA//8A+f8AAPn/AADo/wCZ7f8D
mf//mfz/BpmZ/5n//5np/wCZ/f8AAMP/AAD+/wMA//8A+f8AAPn/AADo/wCZ7f8Dmf//mfz/BpmZ
/5n//5np/wCZ/f8AAOn/AR6B/6j/AAD+/wIAAP/+AAH/APz/DAD/AP8A/wAA/wD//wD+/wMAAP8A
+v8LAP//AP8AAP8A//8A/v8BAAD4/wQA/wAA//4AAP/6AAD//gD5//0A/f8CAP8A/f/+AAL//wDE
/wAA/v8CAAD//gAB/wD8/wwA/wD/AP8AAP8A//8A/v8DAAD/APr/C5n//5n/mZn/mf//mf7/AZmZ
+P8Emf+Zmf/+mQD/+pkA//6Z+f/9mf3/Apn/mf3//pkC//8AxP8AAP7/AgAA//4AAf8A/P8MAP8A
/wD/AAD/AP//AP7/AwAA/wD6/wuZ//+Z/5mZ/5n//5n+/wGZmfj/BJn/mZn//pkA//qZAP/+mfn/
/Zn9/wKZ/5n9//6ZAv//AOn/AOuB/6f/9wAB/wD8/wIA///6AAD//QAD/wD/APr/AgAA//oAAP/9
AAH/APn/9wAA//4AB/8AAP8AAP8A+v/9AP7/BAD/AP8A/v8FAAD/AP8Aw//3AAH/APz/AgD///oA
AP/9AAP/AP8A+v8CmZn/+pkA//2ZAf+Z+f/3mQD//pkH/5mZ/5mZ/5n6//2Z/v8Emf+Z/5n+/wWZ
mf+Z/wDD//cAAf8A/P8CAP//+gAA//0AA/8A/wD6/wKZmf/6mQD//ZkB/5n5//eZAP/+mQf/mZn/
mZn/mfr//Zn+/wSZ/5n/mf7/BZmZ/5n/AOn/AFmB/6j/+AAC/wAA+/8BAP/3AAH///4AAf8A+v+2
AMT/+AAC/wAA+/8BAP/3AAH///4AAf8A+v+3mQAAxP/4AAL/AAD7/wEA//cAAf///gAB/wD6/7eZ
AADp/wAWgf+B//z/tgCY/7eZAACY/7eZAADp/wAMgf+B/4H/gf+B/7H/AGSB/6j/AQAA/P8AAP3/
BgD//wD//wDt/wAA+v8BAADk/wAAnP8BAAD8/wAA/f8GAP//AP//AO3/AJn6/wGZmeT/AACc/wEA
APz/AAD9/wYA//8A//8A7f8Amfr/AZmZ5P8AAMH/ANOB/6j/BwD/AP8AAP8A/f8EAP//AP/+AAL/
AAD7/wEA//0AAv8A//4AA/8AAP/8AAH/AP7/CAAA/wAA//8A//4AAf8A+P8AAJz/BwD/AP8AAP8A
/f8EAP//AP/+AAL/AAD7/wEA//2ZAv+Z//6ZA/+Zmf/8mQH/mf7/CJmZ/5mZ//+Z//6ZAf+Z+P8A
AJz/BwD/AP8AAP8A/f8EAP//AP/+AAL/AAD7/wEA//2ZAv+Z//6ZA/+Zmf/8mQH/mf7/CJmZ/5mZ
//+Z//6ZAf+Z+P8AAMH/AKCB/6j/AwAA///9AP3//QAD/wAA//0A/P8DAP8A//0AA/8AAP/6AAD/
9gAE/wD/AP/9APj/AACc/wMAAP///QD9//0AA/8AAP/9APz/AwD/mf/9mQP/mZn/+pkA//aZBP+Z
/5n//Zn4/wAAnP8DAAD///0A/f/9AAP/AAD//QD8/wMA/5n//ZkD/5mZ//qZAP/2mQT/mf+Z//2Z
+P8AAMH/AFaB/6j/AgD///wA/f8CAP//+gAB/wD8/wEA/9EAnP8CAP///AD9/wIA///6AAH/APz/
AQD/0pkAAJz/AgD///wA/f8CAP//+gAB/wD8/wEA/9KZAADB/wAggf+S/wAA+f/RAIb/AAD5/9KZ
AACG/wAA+f/SmQAAwf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A
DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM
gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8AdoH/jv/7AAf//wAA/wD/AP7/AwD/AAD2/wAA+/8C
AP8A/P8CAP//+QCH//sAB///AAD/AP8A/v8DAP8AAPb/AAD7/wIA/wD8/wIA///5AIf/+wAH//8A
AP8A/wD+/wMA/wAA9v8AAPv/AgD/APz/AgD///kAxv8AW4H/jv8CAAD//QAA//0ABP8AAP//8QD7
//cAAf//+gCH/wIAAP/9AAD//QAE/wAA///xAPv/9wAB///6AIf/AgAA//0AAP/9AAT/AAD///EA
+//3AAH///oAxv8AhYH/jv/+AAb/AAD//wAA/v8AAP7/BgAA/wD/AP/3APz/AgAA//sAA///AP/7
AIf//gAG/wAA//8AAP7/AAD+/wYAAP8A/wD/9wD8/wIAAP/7AAP//wD/+wCH//4ABv8AAP//AAD+
/wAA/v8GAAD/AP8A//cA/P8CAAD/+wAD//8A//sAxv8ALoH/gf8C//8A9f8AAPz/AACB/+H/AAD1
/wAA/P8AAIH/4f8AAPX/AAD8/wAAr/8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/
gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B
/4H/gf+x/wD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUm91
dGVyIChMU1IpIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBtZXNoIG1lbWJlcnNoaXAgICBkcmFm
dC12YXNzZXVyLWNjYW1wLWF1dG9tZXNoLTAwLnR4dAALAAAAQmFja2dyb3VuZAAXAAAAUXVpY2sg
b3ZlcnZpZXcvc3VtbWFyeQAUAAAAUHJvcG9zZWQgbmV4dCBzdGVwcwAMEAAABgAAAB4AAAALAAAA
Rm9udHMgVXNlZAADAAAABAAAAB4AAAAQAAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0A
AABTbGlkZSBUaXRsZXMAAwAAAAQAAAAAAPACAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAA
AQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAABAnAABBAAAAqAIAACQAAAADAAAABwAAAAMAAAAG
AAAAAwAAAAAAAAADAAAABwAAAB8AAAAaAAAAbQBhAGkAbAB0AG8AOgBqAHYAYQBzAHMAZQB1AHIA
QABjAGkAcwBjAG8ALgBjAG8AbQAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAA
AAMAAAAHAAAAHwAAACUAAABtAGEAaQBsAHQAbwA6AHkAYQBzAHUAawBhAHcAYQAuAHMAZQBpAHMA
aABvAEAAbABhAGIALgBuAHQAdAAuAGMAbwAuAGoAcAAAAAAAHwAAAAEAAAAAAAAAAwAAAAcAAAAD
AAAABgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAAKgAAAG0AYQBpAGwAdABvADoAagBlAGEAbgBsAG8A
dQBpAHMALgBsAGUAcgBvAHUAeABAAGYAcgBhAG4AYwBlAHQAZQBsAGUAYwBvAG0ALgBjAG8AbQAA
AB8AAAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAABgAAABtAGEA
aQBsAHQAbwA6AHAAbQBhAGIAZQB5AEAAcQB3AGUAcwB0AC4AYwBvAG0AAAAfAAAAAQAAAAAAAAAD
AAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAAAZAAAAbQBhAGkAbAB0AG8AOgBwAHAA
cwBlAG4AYQBrAEAAYwBpAHMAYwBvAC4AYwBvAG0AAAAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAA
AAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAABoAAABtAGEAaQBsAHQAbwA6AHMAcAByAGUAdgBpAGQA
aQBAAGMAaQBzAGMAbwAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAdQBy
AHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAaAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAA
AD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////
////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2DyIA
AAAUAAAAX8CR47Q/AAAKAPQDAwAiJEpQIFZhc3NldXIIAAAASgBQACAAVgBhAHMAcwBlAHUAcgAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

--Apple-Mail-2-984250060
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed



Thanks.

> draft-ietf-ccamp-rsvp-restart-ext-01.txt
>   Arun Satyanarayana. No slides received
>
> draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt
>   Dimitri Papdimitriou. No slides received
>
> Presenters listed above must use their own laptops.
>
> Cheers,
> Adrian
>

--Apple-Mail-2-984250060--



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 13:14:34 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Date: Tue, 8 Mar 2005 13:14:08 -0000
Message-ID: <[e-mail]>
Thread-Topic: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Thread-Index: AcUj3pQ6K1Bv7p0MQvGsa0GkGiUFAgAAPyaw
From: <[e-mail]>
To: <[e-mail]>

Ashok,

Thanks for the explanation.  If I understand correctly what you are =
saying is that the best current practice is to use an OOB control plane =
for the non-PSC  layer networks and an in-band control plane for the PSC =
layer networks.  So one must avoid using the control plane network (of a =
non-PSC layer network) for the transfer of data (or control) plane =
packets from the PSC layer network's control & data planes.  Fine, I =
agree that is the BCP, but I don't believe the current draft articulates =
that intent very well and section 7.4 probably needs expanding (IMO one =
or two paragraphs is probably not enough to discuss/address/detail OOB =
Vs in-band properly and unambiguously), for example it is not IMO clear =
from the current text that you are talking about 2 separate control =
plane networks - one OOB (for non-PSC layer networks/nodes) and one =
inband (for PSC layer networks/nodes).

Thanks
Ben

> -----Original Message-----
> From: Ashok Narayanan [mailto:[e-mail]]
> Sent: 08 March 2005 12:59
> To: Niven-jenkins,B,Ben,XDE73 R
> Cc: [e-mail]
> Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
>=20
>=20
> >=20
> > I am trying to understand section 7.4 (Separation of=20
> Control and Data Plane Traffic) of=20
> draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> >=20
> > The draft states:
> > "PSC-capable nodes implementing an OOB control plane (perhaps to
> > communicate with an optical switch) MUST NOT use the OOB control
> > plane for data traffic.  For example, in the case of MPLS service
> > running on top of a GMPLS LSP, if the peer PSC device is reachable
> > via both the control plane and the data plane, control protocols
> > such as LDP MUST NOT form adjacencies over the control plane
> > interfaces.  This may be provided by a combination of implementation
> > features and deployment guidelines."
> >=20
> > So, if the control plane is OOB why must control protocols (such as
> > LDP) NOT form adjacencies over the control plane interfaces?  This
> > implies that LDP (for e.g.) MUST form its adjacencies over the data
> > plane interfaces and therefore LDP is not running OOB (and therefore
> > the control plane is not entirely OOB).
> >=20
>=20
> That's an interesting question. The draft focuses on GMPLS/TE
> deployments and the use of an out-of-band control channel as a matter
> of necessity (i.e. because optical switches are not capable of
> handling in-band control traffic). Consider the general deployment of
> a core of optical switches surrounded by GMPLS/TE routers at the
> edge. From the perspective of this network (optical switches, edge
> routers, and the links in between), that statement translates to:
>=20
>  _ The GMPLS/TE control plane between the edge routers and the optical
>    switches in the core is entirely out-of-band
>=20
>  - All other protocols between the edge routers MUST be=20
> entirely in-band.
>=20
> The control plane network may well be a series of point-to-point GRE
> tunnels overlaid on some other low-bandwidth network (actually this is
> what the draft recommends). Ordinarily one would establish a GRE
> tunnel between each pair of neighbors so they can talk to each other.
> But this means that signalling messages going from edge router to edge
> router actually have to be routed through the control planes of
> intermediate switches. The two alternatives to avoid this (to create a
> full mesh of GRE tunnels - at least between all the edge routers - or
> to not use GRE at all if the control plane is switched Ethernet, and
> therefore to essentially permit a full mesh of OSPF peers) are not
> really palatable (and in the case of SDCC, not usable). The optical
> switches in the core should not be in the business of routing
> packets. Sometimes they have to (e.g. Notify messages), but they are
> not designed for this purpose and should not be deployed as such.
>=20
> And practically speaking the control network is expected to be a
> low-bandwidth network that can "just get the job done". A single
> 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the
> control traffic for a GMPLS/TE network, but will probably fail if we
> want to use it to peer LDP or BGP for 10,000 prefixes/labels between
> the edge routers.
>=20
> The best current practice is therefore to use the low-bandwidth
> control network between routers and switches for GMPLS/TE signaling
> (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs
> signalled between edge routers to do other L3 protocols between them.
>=20
> The issue of a separated control plane between PSC edge routers for
> different L3 protocols for administrative reasons is an interesting
> one. Nothing precludes you from creating multiple parallel LSPs
> between edge routers and using one of them to carry control traffic
> between the two edge routers on behalf of all the others; that would
> still satisfy this requirement. Alternatively, one could engineer a
> more beefy control plane network so that it can in fact carry all the
> control plane traffic (BGP, LDP etc.) but that is not the BCP today
> based on available implementations.
>=20
> -Ashok
>=20
> On Tue, Mar 08, 2005 at 10:33:54AM -0000,=20
> [e-mail] wrote:
> > Colleagues,
> >=20
> > I am trying to understand section 7.4 (Separation of=20
> Control and Data Plane Traffic) of=20
> draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> >=20
> > The draft states:
> > "PSC-capable nodes implementing an OOB control plane=20
> (perhaps to communicate with an optical switch) MUST NOT use=20
> the OOB control plane for data traffic.  For example, in the=20
> case of MPLS service running on top of a GMPLS LSP, if the=20
> peer PSC device is reachable via both the control plane and=20
> the data plane, control protocols such as LDP MUST NOT form=20
> adjacencies over the control plane interfaces.  This may be=20
> provided by a combination of implementation features and=20
> deployment guidelines."
> >=20
> > So, if the control plane is OOB why must control protocols=20
> (such as LDP) NOT form adjacencies over the control plane=20
> interfaces?  This implies that LDP (for e.g.) MUST form its=20
> adjacencies over the data plane interfaces and therefore LDP=20
> is not running OOB (and therefore the control plane is not=20
> entirely OOB).
> >=20
> > Thanks
> > Ben
> >=20
> >=20
> > --=20
> > Ben Niven-Jenkins
> > Networking Specialist, BT Exact
> >=20
> > e-mail: [e-mail]
> > tel: [phone]
> > mob: [phone]
> >=20
> > pp34/161 B81 Callisto House, Adastral Park, Martlesham,=20
> Ipswich IP5 3RE, UK
> >=20
> > BT Exact is a trademark of British Telecommunications plc
> > Registered office: 81 Newgate Street London EC1A 7AJ
> > Registered in England no. 1800000
> >=20
> > This electronic message contains information from British=20
> Telecommunications which may be privileged or confidential.=20
> The information is intended to be for the use of the=20
> individual(s) or the entity named above. If you are not the=20
> intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information is=20
> prohibited. If you have received this electronic message in=20
> error, please notify us by telephone or email (to the numbers=20
> or address above) immediately.=20
> >=20
> > Activity and use of the British Telecommunications plc=20
> email system is monitored to secure its effective operation=20
> and for other lawful business purposes. Communications using=20
> this system will also be monitored and may be recorded to=20
> secure effective operation and for other lawful business purposes.
>=20
> --=20
>=20
>=20
>=20
> --- Asok the Intern ----------------------------------------
> Ashok Narayanan
> IOS Network Protocols, Cisco Systems
> 1414 Mass Ave, Boxborough MA 01719
> Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)
>=20



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 13:00:07 +0000
Date: Tue, 8 Mar 2005 07:58:33 -0500
From: Ashok Narayanan <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

> 
> I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> 
> The draft states:
> "PSC-capable nodes implementing an OOB control plane (perhaps to
> communicate with an optical switch) MUST NOT use the OOB control
> plane for data traffic.  For example, in the case of MPLS service
> running on top of a GMPLS LSP, if the peer PSC device is reachable
> via both the control plane and the data plane, control protocols
> such as LDP MUST NOT form adjacencies over the control plane
> interfaces.  This may be provided by a combination of implementation
> features and deployment guidelines."
> 
> So, if the control plane is OOB why must control protocols (such as
> LDP) NOT form adjacencies over the control plane interfaces?  This
> implies that LDP (for e.g.) MUST form its adjacencies over the data
> plane interfaces and therefore LDP is not running OOB (and therefore
> the control plane is not entirely OOB).
> 

That's an interesting question. The draft focuses on GMPLS/TE
deployments and the use of an out-of-band control channel as a matter
of necessity (i.e. because optical switches are not capable of
handling in-band control traffic). Consider the general deployment of
a core of optical switches surrounded by GMPLS/TE routers at the
edge. From the perspective of this network (optical switches, edge
routers, and the links in between), that statement translates to:

 _ The GMPLS/TE control plane between the edge routers and the optical
   switches in the core is entirely out-of-band

 - All other protocols between the edge routers MUST be entirely in-band.

The control plane network may well be a series of point-to-point GRE
tunnels overlaid on some other low-bandwidth network (actually this is
what the draft recommends). Ordinarily one would establish a GRE
tunnel between each pair of neighbors so they can talk to each other.
But this means that signalling messages going from edge router to edge
router actually have to be routed through the control planes of
intermediate switches. The two alternatives to avoid this (to create a
full mesh of GRE tunnels - at least between all the edge routers - or
to not use GRE at all if the control plane is switched Ethernet, and
therefore to essentially permit a full mesh of OSPF peers) are not
really palatable (and in the case of SDCC, not usable). The optical
switches in the core should not be in the business of routing
packets. Sometimes they have to (e.g. Notify messages), but they are
not designed for this purpose and should not be deployed as such.

And practically speaking the control network is expected to be a
low-bandwidth network that can "just get the job done". A single
10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the
control traffic for a GMPLS/TE network, but will probably fail if we
want to use it to peer LDP or BGP for 10,000 prefixes/labels between
the edge routers.

The best current practice is therefore to use the low-bandwidth
control network between routers and switches for GMPLS/TE signaling
(RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs
signalled between edge routers to do other L3 protocols between them.

The issue of a separated control plane between PSC edge routers for
different L3 protocols for administrative reasons is an interesting
one. Nothing precludes you from creating multiple parallel LSPs
between edge routers and using one of them to carry control traffic
between the two edge routers on behalf of all the others; that would
still satisfy this requirement. Alternatively, one could engineer a
more beefy control plane network so that it can in fact carry all the
control plane traffic (BGP, LDP etc.) but that is not the BCP today
based on available implementations.

-Ashok

On Tue, Mar 08, 2005 at 10:33:54AM -0000, [e-mail] wrote:
> Colleagues,
> 
> I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better.
> 
> The draft states:
> "PSC-capable nodes implementing an OOB control plane (perhaps to communicate with an optical switch) MUST NOT use the OOB control plane for data traffic.  For example, in the case of MPLS service running on top of a GMPLS LSP, if the peer PSC device is reachable via both the control plane and the data plane, control protocols such as LDP MUST NOT form adjacencies over the control plane interfaces.  This may be provided by a combination of implementation features and deployment guidelines."
> 
> So, if the control plane is OOB why must control protocols (such as LDP) NOT form adjacencies over the control plane interfaces?  This implies that LDP (for e.g.) MUST form its adjacencies over the data plane interfaces and therefore LDP is not running OOB (and therefore the control plane is not entirely OOB).
> 
> Thanks
> Ben
> 
> 
> -- 
> Ben Niven-Jenkins
> Networking Specialist, BT Exact
> 
> e-mail: [e-mail]
> tel: [phone]
> mob: [phone]
> 
> pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK
> 
> BT Exact is a trademark of British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no. 1800000
> 
> This electronic message contains information from British Telecommunications which may be privileged or confidential. The information is intended to be for the use of the individual(s) or the entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. 
> 
> Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 10:34:59 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Date: Tue, 8 Mar 2005 10:33:54 -0000
Message-ID: <[e-mail]>
Thread-Topic: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt
Thread-Index: AcUjylMWrzJFN4+1Edm5TAAwBQ7M6w==
From: <[e-mail]>
To: <[e-mail]>

Colleagues,

I am trying to understand section 7.4 (Separation of Control and Data =
Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better.

The draft states:
"PSC-capable nodes implementing an OOB control plane (perhaps to =
communicate with an optical switch) MUST NOT use the OOB control plane =
for data traffic.  For example, in the case of MPLS service running on =
top of a GMPLS LSP, if the peer PSC device is reachable via both the =
control plane and the data plane, control protocols such as LDP MUST NOT =
form adjacencies over the control plane interfaces.  This may be =
provided by a combination of implementation features and deployment =
guidelines."

So, if the control plane is OOB why must control protocols (such as LDP) =
NOT form adjacencies over the control plane interfaces?  This implies =
that LDP (for e.g.) MUST form its adjacencies over the data plane =
interfaces and therefore LDP is not running OOB (and therefore the =
control plane is not entirely OOB).

Thanks
Ben


--=20
Ben Niven-Jenkins
Networking Specialist, BT Exact

e-mail: [e-mail]
tel: [phone]
mob: [phone]

pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, =
UK

BT Exact is a trademark of British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000

This electronic message contains information from British =
Telecommunications which may be privileged or confidential. The =
information is intended to be for the use of the individual(s) or the =
entity named above. If you are not the intended recipient be aware that =
any disclosure, copying, distribution or use of the contents of this =
information is prohibited. If you have received this electronic message =
in error, please notify us by telephone or email (to the numbers or =
address above) immediately.=20

Activity and use of the British Telecommunications plc email system is =
monitored to secure its effective operation and for other lawful =
business purposes. Communications using this system will also be =
monitored and may be recorded to secure effective operation and for =
other lawful business purposes.



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 08:45:39 +0000
Message-ID: <012c01c523b9$517e70d0$a4858182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Agenda and slides on line
Date: Tue, 8 Mar 2005 08:31:07 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Agenda and slides on line at http://www.olddog.co.uk/62/ccamp.htm

All there except...

Status and plans for CCAMP re-charter
  Alex Zinin. No slides received.

draft-vasseur-ccamp-automesh-00.txt
  JP Vasseur. Slides received but corrupt

draft-ietf-ccamp-rsvp-restart-ext-01.txt
  Arun Satyanarayana. No slides received

draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt
  Dimitri Papdimitriou. No slides received

Presenters listed above must use their own laptops.

Cheers,
Adrian



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Mar 2005 01:03:16 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
Date: Tue, 8 Mar 2005 01:59:29 +0100
Message-ID: <[e-mail]>
Thread-Topic: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
Thread-Index: AcUik9dvC+GJY5kCSi+DcYbYzFCuDwA5G+Lg
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Hi dimitri

Thanks for these comments

Please see inline

Regards

JL

>-----Message d'origine-----
>De : dimitri papadimitriou [mailto:[e-mail]]=20
>Envoy=E9 : dimanche 6 mars 2005 22:31
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN
>Cc : [e-mail]; [e-mail]
>Objet : Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
>
>
>hi jean-louis
>
>the below discussion raises the issue that the decoupling of=20
>the control=20
>from the (data plane) resource admission control (driven by=20
>the Min/Max=20
>LSP bandwidith) raises the issue of the control plane=20
>saturation due to=20
>LSPs that do not reserve any bandwith/or allow for bandwidth=20
>reuse such=20
>low priority LSPs and therefore the #LSPs actually processed by the=20
>control plane can become much higher than the number of LSPs=20
>that could=20
>result from the Min LSP bandwidth parameter - this is a nice=20
>side effect=20
>of part of bunch of other control plane processing issues such=20
>prioritized treatment of control messages, concurrent requests, etc.
>
>i think the problem statement is rather scoped, however the solution=20
>scope seems to me to be raising correlation issue and further=20
>relationship with the data plane resource re-optimization=20
>issues we were=20
>discussing on this list a couple of times - i could sum'up this in one=20
>sentence is it suitable to flood the state of the signaling control=20
>engine using flooding or is the intention to consider this as an=20
>additional constraint -=20

Yes, in a way, this can be seen as an additional constraint.
A head-end should avoid a saturated LSR when computing a path of a new =
LSP.


>note that in the former case flooding provides=20
>you a notification mechanism after occurrence but does not deliver any=20
>avoidance mechanism -

Yes it does.=20
An LSR could anticipate the saturation, by setting the Saturation bit =
once a threshold is reached.
This is a local decision.

>
>this said is that really a "router capability" or do you mean here the=20
>capability to provide "control plane saturation tracking" ?

No this is not a router capability, this is a control plane status.

>
>therefore, it would be probably advisable to be a bit less=20
>expeditive in=20
>terms of solution

This a light and simple solution that IMHO solves the problem...

Thanks

JL

>
>thanks,
>- dimitri.
>
>LE ROUX Jean-Louis RD-CORE-LAN wrote:
>
>> Hi Adrian,
>>=20
>> Thanks a lot for these comments
>>=20
>> Please see inline
>>=20
>> Regards
>>=20
>> JL
>>=20
>>=20
>>=20
>>=20
>>> -----Message d'origine----- De : Adrian Farrel=20
>>> [mailto:[e-mail]] Envoy=E9 : mardi 1 f=E9vrier 2005 19:41 =
=C0
>>> : LE ROUX Jean-Louis RD-CORE-LAN Cc : [e-mail] Objet :
>>> Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
>>>=20
>>>=20
>>> Jean-Louis,
>>>=20
>>> Thanks for this draft.
>>>=20
>>> A couple of immediate thoughts.
>>>=20
>>> 1. What is wrong with using Error Code 23?
>>=20
>>=20
>> Error code 23 is used for "System Errors". IMHO the saturation=20
>> semantic defined here is quite different.
>>=20
>>=20
>>=20
>>> 2. Will implementations really want to confess to the reason that=20
>>> they are unable to handle more LSPs? It seems to me that it=20
>would be=20
>>> a remarkably honest implementation that implemented this draft.
>>>=20
>>=20
>>=20
>> Bascially the draft proposes to handle properly control plane=20
>> saturation cases. If you want to handle these cases you need a=20
>> dedicated error code, this would allow Head-end LSRs to take=20
>> appropriate actions.
>>=20
>>=20
>>> Isn't it more likely that the LSR would claim an admission control=20
>>> error? 3.
>>=20
>>=20
>> Saturation is not and admission control problem
>>=20
>>=20
>>> "The head-end should not reroute already established LSPs passing=20
>>> through the saturated node." Why ever not? Surely this is local=20
>>> policy, and the ingress may know that the only way to route its new=20
>>> and projected LSPs is to move some of the existing ones.
>>=20
>>=20
>> Stability is better, the LSR is already supporting a set of TE-LSPs,=20
>> it is saturated, why would you want to move these LSPs?
>>=20
>> 4. Why is saturation a good thing to advertise in the
>>=20
>>> IGP? If an LSR wishes to prevent new LSPs being routed=20
>through it, it=20
>>> should withdraw bandwidth just as it would if the signaling=20
>elements=20
>>> of the control plane had failed. 5.
>>=20
>>=20
>> But what about 0 bandwidth LSPs? A head-end may select a node with 0=20
>> bandwidth available, when computing the path of a 0=20
>bandwidth LSP. So=20
>> withdrawing bandwidth is not sufficient to handle properly control=20
>> plane saturations
>>=20
>>=20
>>=20
>>> Much of the draft restates default behavior (e.g. what to=20
>do when you=20
>>> receive a Path message). This is interesting information for the=20
>>> reader, but I am not sure that it is right to present it here.
>>>=20
>>=20
>>=20
>> Agree
>>=20
>> 6. Why does the new Error Codes have three Error Values,
>>=20
>>> but the Saturation TLV only have one bit defined?
>>=20
>>=20
>> Good point, we need to define 3 flags
>>=20
>>=20
>>> 7. Section 5.2. All "MUST" should be "SHOULD" I think.
>>=20
>>=20
>> Why? This is IMHO a mandatory behavior for an implementation=20
>compliant=20
>> with this draft.
>>=20
>>=20
>>> My main question is why you need this draft. It seems that you can=20
>>> already achieve all of these features using existing protocol=20
>>> elements.
>>=20
>>=20
>> I think that this would be cleaner with these light signaling and=20
>> routing extensions.
>>=20
>>=20
>>> At most you might want to write a one page BCP to say what=20
>a transit=20
>>> or egress LSP should do when it cannot handle a new LSP because of=20
>>> some internal resource shortage other than an admission control=20
>>> problem.
>>=20
>>=20
>> But the problem is that we consider that when a transit or=20
>egress LSR=20
>> cannot handle a new LSP because of some internal resource shortage=20
>> other than an admission control problem, it should notify=20
>the head end=20
>> about its saturation, and if you want proper reaction you need a=20
>> specific notification...thus dedicated error code points are required
>>=20
>>=20
>> Again thanks a lot for these comments
>>=20
>> Regards
>>=20
>> JL
>>=20
>>=20
>>=20
>>> Cheers, Adrian
>>>=20
>>>=20
>>> ----- Original Message ----- From: "LE ROUX Jean-Louis=20
>RD-CORE-LAN" =20
>>> <[e-mail]> To: <[e-mail]>
>>> Sent: Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D=20
>>> ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
>>>=20
>>>=20
>>> Hi all,
>>>=20
>>> We just posted a new draft related to (G)MPLS-TE control plane
>>> resource shortages. Your comments/feedbacks on this draft are
>>> welcome.
>>>=20
>>> Regards,
>>>=20
>>> JL
>>>=20
>>>=20
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts=20
>>> directories.
>>>=20
>>>=20
>>> Title : Procedure to handle (G)MPLS-TE control plane saturation
>>> Author(s) : J. Le Roux, et al. Filename :
>>> draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date :
>>> 2005-1-31
>>>=20
>>> This document defines extensions to RSVP-TE (Resource Reservation
>>> Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to
>>>  signal control plane resources saturation, when an LSR runs out of
>>>  control plane resources available to support a new LSP. Such=20
>>> notification may serve as trigger for the impacted Head-end LSR to=20
>>> take appropriate actions.
>>>=20
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat
>>=20
>> uration-0 0.txt
>>=20
>> To remove yourself from the I-D Announcement list, send a message to=20
>> i-d-announce-request at ietf.org with the word unsubscribe=20
>in the body=20
>> of the message. You can also visit=20
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your=20
>> subscription settings.
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP. Login with the=20
>> username "anonymous" and a password of your e-mail address. After=20
>> logging in, type "cd internet-drafts" and then "get=20
>> draft-leroux-ccamp-ctrl-saturation-00.txt".
>>=20
>> A list of Internet-Drafts directories can be found in=20
>> http://www.ietf.org/shadow.html or=20
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>=20
>>=20
>> Internet-Drafts can also be obtained by e-mail.
>>=20
>> Send a message to: mailserv at ietf.org. In the body type: "FILE=20
>> /internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.txt".
>>=20
>> NOTE: The mail server at ietf.org can return the document in=20
>> MIME-encoded form by using the "mpack" utility.  To use this=20
>feature,=20
>> insert the command "ENCODING mime" before the "FILE" command.  To=20
>> decode the response(s), you will need "munpack" or a MIME-compliant=20
>> mail reader.  Different MIME-compliant mail readers exhibit=20
>different=20
>> behavior, especially when dealing with "multipart" MIME=20
>messages (i.e.=20
>> documents which have been split up into multiple messages), so check=20
>> your local documentation on how to manipulate these messages.
>>=20
>>=20
>> Below is the data which will enable a MIME compliant mail reader=20
>> implementation to automatically retrieve the ASCII version of the=20
>> Internet-Draft.=20
>>=20
><ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation
>> -0
>>  0.txt>
>>=20
><ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat
uration-0
>  0.txt>
>=20
>=20
>=20
>=20
> .
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 07 Mar 2005 20:55:58 +0000
Message-ID: <016101c52357$c29c0960$a4858182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: CCAMP Draft status page
Date: Mon, 7 Mar 2005 20:50:03 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I have had a go at updating this.

http://www.olddog.co.uk/ccamp.htm

If there are errors please shout, but not until after this week because I
will simply not find your message in all the rest of the noise!

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 07 Mar 2005 04:56:18 +0000
Message-ID: <006801c522b4$c7517830$a4858182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, "Tomonori TAKEDA" <[e-mail]>, <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>, <[e-mail]>
Subject: Re: What is happenning to CCAMP WG recharter ?
Date: Sun, 6 Mar 2005 18:34:14 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Alex has been press-ganged into coming to the CCAMP meeting.
He will be able to explain where we stand and what the next steps are.

Thanks for pursuing this.
Adrian
----- Original Message ----- 
From: "Kireeti Kompella" <[e-mail]>
To: "Tomonori TAKEDA" <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Monday, February 28, 2005 12:04 AM
Subject: Re: What is happenning to CCAMP WG recharter ?


> On Wed, 23 Feb 2005, Tomonori TAKEDA wrote:
>
> > The same question arises to me. I thought we had good amount of
discussion
> > about new charter items. Is there any open issue?
>
> It's on the ADs' plate.
>
> Alex?  Bill?
>
> Kireeti.
> -------
>
>




Envelope-to: [e-mail]
Delivery-date: Sun, 06 Mar 2005 22:58:45 +0000
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail], LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>, [e-mail]
From: JP Vasseur <[e-mail]>
Subject: Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
Date: Sun, 6 Mar 2005 17:58:07 -0500
To: [e-mail], [e-mail]

Hi Dimitri,

On Mar 6, 2005, at 4:31 PM, dimitri papadimitriou wrote:

> hi jean-louis
>
> the below discussion raises the issue that the decoupling of the =20
> control from the (data plane) resource admission control (driven by =20=

> the Min/Max LSP bandwidith) raises the issue of the control plane =20
> saturation due to LSPs that do not reserve any bandwith/or allow for =20=

> bandwidth reuse such low priority LSPs and therefore the #LSPs =20
> actually processed by the control plane can become much higher than =20=

> the number of LSPs that could result from the Min LSP bandwidth =20
> parameter - this is a nice side effect of part of bunch of other =20
> control plane processing issues such prioritized treatment of control =20=

> messages, concurrent requests, etc.
>
> i think the problem statement is rather scoped, however the solution =20=

> scope seems to me to be raising correlation issue and further =20
> relationship with the data plane resource re-optimization issues we =20=

> were discussing on this list a couple of times - i could sum'up this =20=

> in one sentence is it suitable to flood the state of the signaling =20
> control engine using flooding or is the intention to consider this as =20=

> an additional constraint - note that in the former case flooding =20
> provides you a notification mechanism after occurrence but does not =20=

> deliver any avoidance mechanism -
>

it provides a notification mechanism that a head-end should consider as =20=

a constraint.

> this said is that really a "router capability" or do you mean here the =
=20
> capability to provide "control plane saturation tracking" ?
>

the later.

> therefore, it would be probably advisable to be a bit less expeditive =20=

> in terms of solution
>

"expeditive" ?

Thanks.

JP.

> thanks,
> - dimitri.
>
> LE ROUX Jean-Louis RD-CORE-LAN wrote:
>
>> Hi Adrian,
>> Thanks a lot for these comments
>> Please see inline
>> Regards
>> JL
>>> -----Message d'origine----- De : Adrian Farrel
>>> [mailto:[e-mail]] Envoy=E9 : mardi 1 f=E9vrier 2005 19:41 =
=C0
>>> : LE ROUX Jean-Louis RD-CORE-LAN Cc : [e-mail] Objet :
>>> Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
>>> Jean-Louis,
>>> Thanks for this draft.
>>> A couple of immediate thoughts.
>>> 1. What is wrong with using Error Code 23?
>> Error code 23 is used for "System Errors". IMHO the saturation
>> semantic defined here is quite different.
>>> 2. Will implementations really want to confess to the reason that
>>> they are unable to handle more LSPs? It seems to me that it would
>>> be a remarkably honest implementation that implemented this draft.
>> Bascially the draft proposes to handle properly control plane
>> saturation cases. If you want to handle these cases you need a
>> dedicated error code, this would allow Head-end LSRs to take
>> appropriate actions.
>>> Isn't it more likely that the LSR would claim an admission control
>>> error? 3.
>> Saturation is not and admission control problem
>>> "The head-end should not reroute already established LSPs passing
>>> through the saturated node." Why ever not? Surely this is local =20
>>> policy, and the ingress may know that the only way to route its new
>>> and projected LSPs is to move some of the existing ones.
>> Stability is better, the LSR is already supporting a set of TE-LSPs,
>> it is saturated, why would you want to move these LSPs?
>> 4. Why is saturation a good thing to advertise in the
>>> IGP? If an LSR wishes to prevent new LSPs being routed through it,
>>> it should withdraw bandwidth just as it would if the signaling
>>> elements of the control plane had failed. 5.
>> But what about 0 bandwidth LSPs? A head-end may select a node with 0
>> bandwidth available, when computing the path of a 0 bandwidth LSP. So
>> withdrawing bandwidth is not sufficient to handle properly control
>> plane saturations
>>> Much of the draft restates default behavior (e.g. what to do when
>>> you receive a Path message). This is interesting information for the =
=20
>>> reader, but I am not sure that it is right to present it here.
>> Agree
>> 6. Why does the new Error Codes have three Error Values,
>>> but the Saturation TLV only have one bit defined?
>> Good point, we need to define 3 flags
>>> 7. Section 5.2. All "MUST" should be "SHOULD" I think.
>> Why? This is IMHO a mandatory behavior for an implementation
>> compliant with this draft.
>>> My main question is why you need this draft. It seems that you can
>>> already achieve all of these features using existing protocol
>>> elements.
>> I think that this would be cleaner with these light signaling and
>> routing extensions.
>>> At most you might want to write a one page BCP to say what a
>>> transit or egress LSP should do when it cannot handle a new LSP
>>> because of some internal resource shortage other than an admission
>>> control problem.
>> But the problem is that we consider that when a transit or egress LSR
>> cannot handle a new LSP because of some internal resource shortage
>> other than an admission control problem, it should notify the head
>> end about its saturation, and if you want proper reaction you need a
>> specific notification...thus dedicated error code points are required
>> Again thanks a lot for these comments
>> Regards
>> JL
>>> Cheers, Adrian
>>> ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN"
>>>  <[e-mail]> To: <[e-mail]> Sent: =
=20
>>> Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D
>>> ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
>>> Hi all,
>>> We just posted a new draft related to (G)MPLS-TE control plane =20
>>> resource shortages. Your comments/feedbacks on this draft are
>>> welcome.
>>> Regards,
>>> JL
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> Title : Procedure to handle (G)MPLS-TE control plane saturation =20
>>> Author(s) : J. Le Roux, et al. Filename :
>>> draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date :
>>> 2005-1-31
>>> This document defines extensions to RSVP-TE (Resource Reservation =20=

>>> Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to
>>>  signal control plane resources saturation, when an LSR runs out of
>>>  control plane resources available to support a new LSP. Such =20
>>> notification may serve as trigger for the impacted Head-end LSR to =20=

>>> take appropriate actions.
>>> A URL for this Internet-Draft is: =20
>>> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat
>> uration-0 0.txt
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request at ietf.org 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-leroux-ccamp-ctrl-saturation-00.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: mailserv at ietf.org. In the body type: "FILE
>> /internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.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.
>> <ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-=20
>> saturation-0
>>  0.txt>
>> <ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-=20
>> saturation-0
>>  0.txt>
>> .
>



Envelope-to: [e-mail]
Delivery-date: Sun, 06 Mar 2005 21:33:15 +0000
Message-ID: <[e-mail]>
Date: Sun, 06 Mar 2005 22:31:03 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>
CC:  [e-mail],  [e-mail]
Subject: Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

hi jean-louis

the below discussion raises the issue that the decoupling of the control 
from the (data plane) resource admission control (driven by the Min/Max 
LSP bandwidith) raises the issue of the control plane saturation due to 
LSPs that do not reserve any bandwith/or allow for bandwidth reuse such 
low priority LSPs and therefore the #LSPs actually processed by the 
control plane can become much higher than the number of LSPs that could 
result from the Min LSP bandwidth parameter - this is a nice side effect 
of part of bunch of other control plane processing issues such 
prioritized treatment of control messages, concurrent requests, etc.

i think the problem statement is rather scoped, however the solution 
scope seems to me to be raising correlation issue and further 
relationship with the data plane resource re-optimization issues we were 
discussing on this list a couple of times - i could sum'up this in one 
sentence is it suitable to flood the state of the signaling control 
engine using flooding or is the intention to consider this as an 
additional constraint - note that in the former case flooding provides 
you a notification mechanism after occurrence but does not deliver any 
avoidance mechanism -

this said is that really a "router capability" or do you mean here the 
capability to provide "control plane saturation tracking" ?

therefore, it would be probably advisable to be a bit less expeditive in 
terms of solution

thanks,
- dimitri.

LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi Adrian,
> 
> Thanks a lot for these comments
> 
> Please see inline
> 
> Regards
> 
> JL
> 
> 
> 
> 
>> -----Message d'origine----- De : Adrian Farrel
>> [mailto:[e-mail]] Envoyé : mardi 1 février 2005 19:41 À
>> : LE ROUX Jean-Louis RD-CORE-LAN Cc : [e-mail] Objet :
>> Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
>> 
>> 
>> Jean-Louis,
>> 
>> Thanks for this draft.
>> 
>> A couple of immediate thoughts.
>> 
>> 1. What is wrong with using Error Code 23?
> 
> 
> Error code 23 is used for "System Errors". IMHO the saturation
> semantic defined here is quite different.
> 
> 
> 
>> 2. Will implementations really want to confess to the reason that
>> they are unable to handle more LSPs? It seems to me that it would
>> be a remarkably honest implementation that implemented this draft.
>> 
> 
> 
> Bascially the draft proposes to handle properly control plane
> saturation cases. If you want to handle these cases you need a
> dedicated error code, this would allow Head-end LSRs to take
> appropriate actions.
> 
> 
>> Isn't it more likely that the LSR would claim an admission control
>> error? 3.
> 
> 
> Saturation is not and admission control problem
> 
> 
>> "The head-end should not reroute already established LSPs passing
>> through the saturated node." Why ever not? Surely this is local 
>> policy, and the ingress may know that the only way to route its new
>> and projected LSPs is to move some of the existing ones.
> 
> 
> Stability is better, the LSR is already supporting a set of TE-LSPs,
> it is saturated, why would you want to move these LSPs?
> 
> 4. Why is saturation a good thing to advertise in the
> 
>> IGP? If an LSR wishes to prevent new LSPs being routed through it,
>> it should withdraw bandwidth just as it would if the signaling
>> elements of the control plane had failed. 5.
> 
> 
> But what about 0 bandwidth LSPs? A head-end may select a node with 0
> bandwidth available, when computing the path of a 0 bandwidth LSP. So
> withdrawing bandwidth is not sufficient to handle properly control
> plane saturations
> 
> 
> 
>> Much of the draft restates default behavior (e.g. what to do when
>> you receive a Path message). This is interesting information for 
>> the reader, but I am not sure that it is right to present it here.
>> 
> 
> 
> Agree
> 
> 6. Why does the new Error Codes have three Error Values,
> 
>> but the Saturation TLV only have one bit defined?
> 
> 
> Good point, we need to define 3 flags
> 
> 
>> 7. Section 5.2. All "MUST" should be "SHOULD" I think.
> 
> 
> Why? This is IMHO a mandatory behavior for an implementation
> compliant with this draft.
> 
> 
>> My main question is why you need this draft. It seems that you can
>> already achieve all of these features using existing protocol
>> elements.
> 
> 
> I think that this would be cleaner with these light signaling and
> routing extensions.
> 
> 
>> At most you might want to write a one page BCP to say what a
>> transit or egress LSP should do when it cannot handle a new LSP
>> because of some internal resource shortage other than an admission
>> control problem.
> 
> 
> But the problem is that we consider that when a transit or egress LSR
> cannot handle a new LSP because of some internal resource shortage
> other than an admission control problem, it should notify the head
> end about its saturation, and if you want proper reaction you need a
> specific notification...thus dedicated error code points are required
> 
> 
> Again thanks a lot for these comments
> 
> Regards
> 
> JL
> 
> 
> 
>> Cheers, Adrian
>> 
>> 
>> ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN"
>>  <[e-mail]> To: <[e-mail]> 
>> Sent: Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D
>> ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
>> 
>> 
>> Hi all,
>> 
>> We just posted a new draft related to (G)MPLS-TE control plane 
>> resource shortages. Your comments/feedbacks on this draft are
>> welcome.
>> 
>> Regards,
>> 
>> JL
>> 
>> 
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> 
>> 
>> Title : Procedure to handle (G)MPLS-TE control plane saturation 
>> Author(s) : J. Le Roux, et al. Filename :
>> draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date :
>> 2005-1-31
>> 
>> This document defines extensions to RSVP-TE (Resource Reservation 
>> Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to
>>  signal control plane resources saturation, when an LSR runs out of
>>  control plane resources available to support a new LSP. Such 
>> notification may serve as trigger for the impacted Head-end LSR to 
>> take appropriate actions.
>> 
>> A URL for this Internet-Draft is: 
>> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat
> 
> uration-0 0.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request at ietf.org 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-leroux-ccamp-ctrl-saturation-00.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: mailserv at ietf.org. In the body type: "FILE
> /internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.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.
> <ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation-0
>  0.txt>
> <ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation-0
>  0.txt>
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sun, 06 Mar 2005 18:29:42 +0000
Message-ID: <[e-mail]>
Date: Sun, 06 Mar 2005 19:27:51 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail],  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC:  [e-mail], Igor Bryskin <[e-mail]>,  [e-mail],  [e-mail]
Subject: Re: A philosophical question about FA and FA-LSP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi - see in-line:

Kireeti Kompella wrote:

> On Sat, 5 Mar 2005, dimitri papadimitriou wrote:
> 
> 
>>>What's special?  Nothing really.  A "normal" TE link usually has a
>>>(single) physical interface associated with it; an FA TE link is
>>>usually multi-hop.  A "normal" TE link usually is accompanied by an
>>>IGP adjacency (at least, in the packet domain); an FA TE link usually
>>>doesn't.
>>
>>but if a couple this with your answer "Correct -- LSPs created in IGP A
>>can be advertised as TE links in IGP B. This can be used (say) for
>>inter-area signaling." don't you have now an adjacency accompanying the
>>TE link advertisement in IGP B
> 
> 
> Not necessarily.  Say you have:
> 
>        IGP B - X == IGP A == Y - IGP B
> 
> X and Y participate in both IGPs; X has an LSP to Y, and advertises it
> into IGP B.  All's fine.
> 
> I'm guessing you are referring to the fact that IGP B appears
> partitioned?  Well, to connect up the piece on the right with the
> piece on the left, one can:
>  a) create an adjacency over the FA LSP (only possible if LSP is PSC)

ok but is that not another adjacency accompanying the TE link 
advertisement for (or in) IGP B as stated in my previous reply ?

>  b) have a virtual link (OSPF) from X to Y
>  c) have some other "backdoor" connection between the two parts.

the same applying for the other cases

>>- therefore why is there a need to rename
>>the canonical inheritance i.e. why not just speak in that case about a
>>TE link or a "hierarchical TE link" as it was the case in one of the
>>earlier versions of the LSP-HIER document and keep the FA concept when
>>dealing with a unique instance ?
> 
> You can call it what you like :-)  "FA" in particular refers to the
> idea that the "adjacency" is primarily for forwarding, and not
> necessarily for the control plane.  However, the latter is not ruled
> out (as in case (a) above.)

initially the term has been introduced to implicitly allow for the 
creation of a forwarding adjacency *without introducing a control plane 
adjacency* solving the facto scaling of the control plane both in terms 
of routing (creation of a data plane adjacency does not trigger creation 
of a routing adjacency therefore the number of routing adjacencies 
remains constant independently of the number of data plane adjacencies) 
and signaling (resulting from the LSP nesting operations), and the 
inherent problem associated to the so-called "unknown adjacency" problem 
that was also the achille heel of the IPoverATM approach where one had 
to create a full-mesh of VCs to determine the reachable end-points from 
the IP level

i do believe we are in agreement on this point - if not please let me 
know - now on the issue concerning not ruling out case a) as described 
here above how do you position this with the following paragraph in the 
LSP-Hierarchy document

"   It is expected that FAs will not be used for establishing ISIS/OSPF
    peering relation between the routers at the ends of the adjacency."

probably we do not have to preclude this but it would be advisable to 
consider a self-consistent terminology to describe the sub-cases we are 
dealing with

thanks,
- dimitri.

> Kireeti.
> -------
> 
> .
> 





Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 21:56:38 +0000
Message-ID: <0e6501c521cd$9d8e05f0$19cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>, "Igor Bryskin" <[e-mail]>, "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>, <[e-mail]>
Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
Date: Sat, 5 Mar 2005 16:30:28 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 8bit

Why are we talking about signaling virtual FA LSPs?
I thought the point of a virtual FA was that it was entirely putative.

Seems like you are talking about something more solid than a virtual FA
LSP.

Adrian

----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; "Igor Bryskin"
<[e-mail]>; "LE ROUX Jean-Louis RD-CORE-LAN"
<[e-mail]>; <[e-mail]>
Sent: Saturday, March 05, 2005 3:03 PM
Subject: Re: RE : RE : TR : I-D
ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt


> igor - i will provide a detailed answer concerning a clean method to
> deal with "virtual FAs" that does not rely on the use of the protection
> object (and therefore would deliver a clean method to provide signaling
> for protected "virtual FAs"
>
> hopefully we can discuss this during this IETF meeting,
>
> thanks,
> - dimitri.
>
> Igor Bryskin wrote:
>
> > Dimitri,
> >
> > See at the bottom
> >
> >
> >>>IB>>Well, are they? They give you a way to signal a
> >>>requirement not to commit resources for an LSP
> >
> > until
> >
> >>>further notice and also to require their commitment
> >>>when it becomes necessary. Why not to allow working
> >>>LSP to be signaled as Secondary according to the
> >>>mentioned draft? Then it would be possible even to
> >>>signal protected virtual FAs, which is not as
> >
> > stupid
> >
> >>>as it may sound :=)
> >>
> >>Sorry but this sounds really bad...
> >>Please let me know then how do you signal protected
> >
> > virtual FAs?
> >
> >>IB>> You signal both working and protection LSPs of
> >
> > the FA as Secondary.
> > At
> >
> >>the time when you decide to make FA "real" you
> >
> > re-signal working or both
> >
> >>LSPs (depending on protection type) as Primary.
> >
> > Don't see why this
> > wouldn't
> >
> >>work.
> >>
> >>DP> because what do you do in case the primary
> >
> > (virtual) FA-LSP fails ?
> > you
> >
> >>are simply going to activate the secondary (virtual)
> >
> > FA-LSP which is in
> >
> >>clear
> >>opposition with the notion of virtual-FA - the
> >
> > reason is again because you
> >
> >>are trying to use one bit i.e. S to say something in
> >
> > a context (protection
> >
> >>object) for which it has not been designed for
> >>
> >
> >
> > IB>> Oh-Oh, what do you mean by "primary (virtual)
> > FA-LSP fails" and  "you
> > are simply going to activate the secondary (virtual)
> > FA-LSP "?  I activate
> > protection LSP if I have a failure in the *data plane*
> > of the working LSP.
> > But working LSP of the virtual FA does not have any
> > data plane yet, there is
> > nothing that can trigger the protection LSP activation
> > and switchover.
> >
> > DP> but they are associated to resources they do not
> > use - and the control plane role is to ensure that
> > when they need to be activated resources can be used -
> > the question JL raises is the problem of "how do i
> > protect a virtual FA" and the response is if you are
> > using the S bit for telling i am a virtual FA you can
> > not use it anymore to ensure protection of a primary
> > (and even less a secondary !) - this said an secondary
> > LSP exists only within the context of its primary
> >
> > IB>>Here is what I have in mind.
> >
> > A network operator configures a mesh of virtual FAs.
> > Working FA LSPs are signaled as Secondary. Once they
> > are established the FA TE link ends are advertised.
> > Resources for these LSPs are allocated on the links
> > the LSPs are going through, however, they are not
> > committed (not bound into cross-connects). Two or more
> > virtual FA LSPs may share the resources on common
> > links. This is especially true for those of them that
> > are unlikely to become real at the same time.
> > Furthermore, polices could be such that virtual FA LSP
> > resources could be allowed to get pre-empted by real
> > (not necessarily FA-) LSPs. The mentioned resources
> > also could be involved in mesh restoration schemes and
> > even be bound into extra traffic LSPs.
> >
> > When a virtual FA transforms into real FA, its working
> > FA-LSP is re-signaled as Primary. At this time, the
> > allocated resources are bound into FA-LSP
> > cross-connects. Naturally, all other LSPs – virtual or
> > real – that share resources with the FA-LSP in
> > question are notified and need to be recomputed and/or
> > re-signaled.
> >
> > A virtual FA could be provisioned as protected in a
> > sense that when it becomes real it will have a certain
> > protection scheme already in place. Path computation
> > for backup LSPs of virtual FAs is performed just like
> > of real FAs, that is, by assuming that associated
> > working LSPs are Primary (fully built) LSPs.
> > Regardless of the protection type backup LSPs of
> > virtual FAs are always signaled as Secondary. At the
> > time when a virtual FA is transformed into real one
> > (that is, when its working LSP becomes Primary) its
> > backup LSP(s) may be activated as well (e.g. 1+1
> > protection) or may be left Secondary until the working
> > LSP data plane failure is detected (e.g. shared
> > protection).
> >
> > Igor
> >
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> >
> > .
> >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 18:51:54 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=y4CYz/xM+wVfrTxVflmwKoigseGLCu509ypm9ibzfdfdhXRr6rk2euW3HFD94AVuWddaqc2EGm430rKJQEG3YIiLcgIviWlSn2kz6iO9v9T/fkX0UvKwqpjuMqos8UHo6dJn4Mou9oJIabNX2dtGD0t6FMR0G7BKl7UvD6Oge3Q=  ;
Message-ID: <[e-mail]>
Date: Sat, 5 Mar 2005 10:50:54 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
To: [e-mail], [e-mail]
Cc: [e-mail], Igor Bryskin <[e-mail]>, LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Excellent. Looking forward to the discussion.
Hopefully, I’ll get to understand what is not clean
about the mechanism I suggested.

Before we start the discussion, I’d like to make clear
that all I am asking is a capability to provision
working LSPs as Secondary LSPs. Note that this is a
generic mechanism, and signaling of virtual FAs is one
of possibly many applications that can make use of it.
For example, on many occasions I hear a requirement
from service providers to provide a way of
provisioning a service when part of network resources
are not in place yet with actual service activation
after all resources are installed. This is necessary
to make sure that resources that are in place are not
“grabbed” by other dynamically provisioned services.
This problem could be easily solved by the suggested
mechanism. 

Lastly, despite what you and JL are saying,
provisioning of virtual FAs has a lot to do with
recovery. It is usually a MUST requirement for FAs to
be protected. In this case if you provision virtual FA
as unprotected, and, while it is transformed into real
FA, try to compute/provision protection LSP, the
computation may fail despite that two disjoint paths
do exist and could be determined if they were computed
at the same time. Therefore, it should be possible to
compute working and protection (possibly multiple as
in case of segment protection) path(s) for virtual FA
and signal them, associating them together, without
committing network resource for neither of them.

See you in Minneapolis,
Igor
   


--- dimitri papadimitriou <[e-mail]>
wrote:

> igor - i will provide a detailed answer concerning a
> clean method to 
> deal with "virtual FAs" that does not rely on the
> use of the protection 
> object (and therefore would deliver a clean method
> to provide signaling 
> for protected "virtual FAs"
> 
> hopefully we can discuss this during this IETF
> meeting,
> 
> thanks,
> - dimitri.
> 
> Igor Bryskin wrote:
> 
> > Dimitri,
> > 
> > See at the bottom
> > 
> > 
> >>>IB>>Well, are they? They give you a way to signal
> a
> >>>requirement not to commit resources for an LSP
> > 
> > until
> > 
> >>>further notice and also to require their
> commitment
> >>>when it becomes necessary. Why not to allow
> working
> >>>LSP to be signaled as Secondary according to the
> >>>mentioned draft? Then it would be possible even
> to
> >>>signal protected virtual FAs, which is not as
> > 
> > stupid
> > 
> >>>as it may sound :=)
> >>
> >>Sorry but this sounds really bad...
> >>Please let me know then how do you signal
> protected
> > 
> > virtual FAs?
> > 
> >>IB>> You signal both working and protection LSPs
> of
> > 
> > the FA as Secondary.
> > At
> > 
> >>the time when you decide to make FA "real" you
> > 
> > re-signal working or both
> > 
> >>LSPs (depending on protection type) as Primary.
> > 
> > Don't see why this
> > wouldn't
> > 
> >>work.
> >>
> >>DP> because what do you do in case the primary
> > 
> > (virtual) FA-LSP fails ?
> > you
> > 
> >>are simply going to activate the secondary
> (virtual)
> > 
> > FA-LSP which is in
> > 
> >>clear
> >>opposition with the notion of virtual-FA - the
> > 
> > reason is again because you
> > 
> >>are trying to use one bit i.e. S to say something
> in
> > 
> > a context (protection
> > 
> >>object) for which it has not been designed for
> >>
> > 
> > 
> > IB>> Oh-Oh, what do you mean by "primary (virtual)
> > FA-LSP fails" and  "you
> > are simply going to activate the secondary
> (virtual)
> > FA-LSP "?  I activate
> > protection LSP if I have a failure in the *data
> plane*
> > of the working LSP.
> > But working LSP of the virtual FA does not have
> any
> > data plane yet, there is
> > nothing that can trigger the protection LSP
> activation
> > and switchover.
> > 
> > DP> but they are associated to resources they do
> not
> > use - and the control plane role is to ensure that
> > when they need to be activated resources can be
> used -
> > the question JL raises is the problem of "how do i
> > protect a virtual FA" and the response is if you
> are
> > using the S bit for telling i am a virtual FA you
> can
> > not use it anymore to ensure protection of a
> primary
> > (and even less a secondary !) - this said an
> secondary
> > LSP exists only within the context of its primary
> > 
> > IB>>Here is what I have in mind.
> > 
> > A network operator configures a mesh of virtual
> FAs.
> > Working FA LSPs are signaled as Secondary. Once
> they
> > are established the FA TE link ends are
> advertised.
> > Resources for these LSPs are allocated on the
> links
> > the LSPs are going through, however, they are not
> > committed (not bound into cross-connects). Two or
> more
> > virtual FA LSPs may share the resources on common
> > links. This is especially true for those of them
> that
> > are unlikely to become real at the same time.
> > Furthermore, polices could be such that virtual FA
> LSP
> > resources could be allowed to get pre-empted by
> real
> > (not necessarily FA-) LSPs. The mentioned
> resources
> > also could be involved in mesh restoration schemes
> and
> > even be bound into extra traffic LSPs. 
> > 
> > When a virtual FA transforms into real FA, its
> working
> > FA-LSP is re-signaled as Primary. At this time,
> the
> > allocated resources are bound into FA-LSP
> > cross-connects. Naturally, all other LSPs –
> virtual or
> > real – that share resources with the FA-LSP in
> > question are notified and need to be recomputed
> and/or
> > re-signaled.
> > 
> > A virtual FA could be provisioned as protected in
> a
> > sense that when it becomes real it will have a
> certain
> > protection scheme already in place. Path
> computation
> > for backup LSPs of virtual FAs is performed just
> like
> > of real FAs, that is, by assuming that associated
> > working LSPs are Primary (fully built) LSPs.
> > Regardless of the protection type backup LSPs of
> > virtual FAs are always signaled as Secondary. At
> the
> > time when a virtual FA is transformed into real
> one
> > (that is, when its working LSP becomes Primary)
> its
> > backup LSP(s) may be activated as well (e.g. 1+1
> > protection) or may be left Secondary until the
> working
> > LSP data plane failure is detected (e.g. shared
> > protection).
> > 
> > Igor
> > 
> > 
> > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> > 
> > 
> > .
> > 
> 
>



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/



Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 17:47:18 +0000
Date: Sat, 5 Mar 2005 09:45:55 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail], [e-mail]
cc: Igor Bryskin <[e-mail]>, [e-mail], [e-mail]
Subject: Re: A philosophical question about FA and FA-LSP
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 5 Mar 2005, dimitri papadimitriou wrote:

> > What's special?  Nothing really.  A "normal" TE link usually has a
> > (single) physical interface associated with it; an FA TE link is
> > usually multi-hop.  A "normal" TE link usually is accompanied by an
> > IGP adjacency (at least, in the packet domain); an FA TE link usually
> > doesn't.
>
> but if a couple this with your answer "Correct -- LSPs created in IGP A
> can be advertised as TE links in IGP B. This can be used (say) for
> inter-area signaling." don't you have now an adjacency accompanying the
> TE link advertisement in IGP B

Not necessarily.  Say you have:

       IGP B - X == IGP A == Y - IGP B

X and Y participate in both IGPs; X has an LSP to Y, and advertises it
into IGP B.  All's fine.

I'm guessing you are referring to the fact that IGP B appears
partitioned?  Well, to connect up the piece on the right with the
piece on the left, one can:
 a) create an adjacency over the FA LSP (only possible if LSP is PSC)
 b) have a virtual link (OSPF) from X to Y
 c) have some other "backdoor" connection between the two parts.

> - therefore why is there a need to rename
> the canonical inheritance i.e. why not just speak in that case about a
> TE link or a "hierarchical TE link" as it was the case in one of the
> earlier versions of the LSP-HIER document and keep the FA concept when
> dealing with a unique instance ?

You can call it what you like :-)  "FA" in particular refers to the
idea that the "adjacency" is primarily for forwarding, and not
necessarily for the control plane.  However, the latter is not ruled
out (as in case (a) above.)

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 16:23:41 +0000
Message-ID: <0de601c5219f$988f1e00$19cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: Agenda on-line
Date: Sat, 5 Mar 2005 16:22:49 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Kireeti has submitted the agenda to the Secretariat so you should be able
to see it on their web site.

I have placed an HTML version on the alternative CCAMP pages at
http://www.olddog.co.uk/ccamp.htm

You'll also find a template for your slides there in case you need
something to start with and some reminders of what you should be talking
about.

Would the presenters please send me their slides before midnight on
Monday. (No slides, no presentation :-)

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 15:03:27 +0000
Message-ID: <[e-mail]>
Date: Sat, 05 Mar 2005 16:03:18 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail], Igor Bryskin <[e-mail]>,  LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>, [e-mail]
Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

igor - i will provide a detailed answer concerning a clean method to 
deal with "virtual FAs" that does not rely on the use of the protection 
object (and therefore would deliver a clean method to provide signaling 
for protected "virtual FAs"

hopefully we can discuss this during this IETF meeting,

thanks,
- dimitri.

Igor Bryskin wrote:

> Dimitri,
> 
> See at the bottom
> 
> 
>>>IB>>Well, are they? They give you a way to signal a
>>>requirement not to commit resources for an LSP
> 
> until
> 
>>>further notice and also to require their commitment
>>>when it becomes necessary. Why not to allow working
>>>LSP to be signaled as Secondary according to the
>>>mentioned draft? Then it would be possible even to
>>>signal protected virtual FAs, which is not as
> 
> stupid
> 
>>>as it may sound :=)
>>
>>Sorry but this sounds really bad...
>>Please let me know then how do you signal protected
> 
> virtual FAs?
> 
>>IB>> You signal both working and protection LSPs of
> 
> the FA as Secondary.
> At
> 
>>the time when you decide to make FA "real" you
> 
> re-signal working or both
> 
>>LSPs (depending on protection type) as Primary.
> 
> Don't see why this
> wouldn't
> 
>>work.
>>
>>DP> because what do you do in case the primary
> 
> (virtual) FA-LSP fails ?
> you
> 
>>are simply going to activate the secondary (virtual)
> 
> FA-LSP which is in
> 
>>clear
>>opposition with the notion of virtual-FA - the
> 
> reason is again because you
> 
>>are trying to use one bit i.e. S to say something in
> 
> a context (protection
> 
>>object) for which it has not been designed for
>>
> 
> 
> IB>> Oh-Oh, what do you mean by "primary (virtual)
> FA-LSP fails" and  "you
> are simply going to activate the secondary (virtual)
> FA-LSP "?  I activate
> protection LSP if I have a failure in the *data plane*
> of the working LSP.
> But working LSP of the virtual FA does not have any
> data plane yet, there is
> nothing that can trigger the protection LSP activation
> and switchover.
> 
> DP> but they are associated to resources they do not
> use - and the control plane role is to ensure that
> when they need to be activated resources can be used -
> the question JL raises is the problem of "how do i
> protect a virtual FA" and the response is if you are
> using the S bit for telling i am a virtual FA you can
> not use it anymore to ensure protection of a primary
> (and even less a secondary !) - this said an secondary
> LSP exists only within the context of its primary
> 
> IB>>Here is what I have in mind.
> 
> A network operator configures a mesh of virtual FAs.
> Working FA LSPs are signaled as Secondary. Once they
> are established the FA TE link ends are advertised.
> Resources for these LSPs are allocated on the links
> the LSPs are going through, however, they are not
> committed (not bound into cross-connects). Two or more
> virtual FA LSPs may share the resources on common
> links. This is especially true for those of them that
> are unlikely to become real at the same time.
> Furthermore, polices could be such that virtual FA LSP
> resources could be allowed to get pre-empted by real
> (not necessarily FA-) LSPs. The mentioned resources
> also could be involved in mesh restoration schemes and
> even be bound into extra traffic LSPs. 
> 
> When a virtual FA transforms into real FA, its working
> FA-LSP is re-signaled as Primary. At this time, the
> allocated resources are bound into FA-LSP
> cross-connects. Naturally, all other LSPs – virtual or
> real – that share resources with the FA-LSP in
> question are notified and need to be recomputed and/or
> re-signaled.
> 
> A virtual FA could be provisioned as protected in a
> sense that when it becomes real it will have a certain
> protection scheme already in place. Path computation
> for backup LSPs of virtual FAs is performed just like
> of real FAs, that is, by assuming that associated
> working LSPs are Primary (fully built) LSPs.
> Regardless of the protection type backup LSPs of
> virtual FAs are always signaled as Secondary. At the
> time when a virtual FA is transformed into real one
> (that is, when its working LSP becomes Primary) its
> backup LSP(s) may be activated as well (e.g. 1+1
> protection) or may be left Secondary until the working
> LSP data plane failure is detected (e.g. shared
> protection).
> 
> Igor
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 14:58:56 +0000
Message-ID: <[e-mail]>
Date: Sat, 05 Mar 2005 15:58:29 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: Igor Bryskin <[e-mail]>,  [e-mail],  [e-mail]
Subject: Re: A philosophical question about FA and FA-LSP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi kireeti,

>>My question was what is (if any) special about FA TE link apart from
>>the fact that it is dynamically created/destroyed?
> 
> 
> Actually, an FA TE link doesn't have to be dynamically
> created/destroyed.
> 
> What's special?  Nothing really.  A "normal" TE link usually has a
> (single) physical interface associated with it; an FA TE link is
> usually multi-hop.  A "normal" TE link usually is accompanied by an
> IGP adjacency (at least, in the packet domain); an FA TE link usually
> doesn't.

but if a couple this with your answer "Correct -- LSPs created in IGP A 
can be advertised as TE links in IGP B. This can be used (say) for 
inter-area signaling." don't you have now an adjacency accompanying the 
TE link advertisement in IGP B - therefore why is there a need to rename 
the canonical inheritance i.e. why not just speak in that case about a 
TE link or a "hierarchical TE link" as it was the case in one of the 
earlier versions of the LSP-HIER document and keep the FA concept when 
dealing with a unique instance ?

thanks,
- dimitri

> But from the point of view of the IGP, or an LSR in that IGP, they
> can't tell an FA TE link from any other TE link.
 >
> Kireeti.
> -------
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 14:32:22 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=LAuZJwcYhl7fZX7+DoPjENXM5HaUk0reCo2tH3S1OXRfEtpuyThe5HSF4zZ8pOYKNMjo/FtqL1vRlpyY7h1sBc1huoxgDhp2wfAa5IcclsbgOAG5fvxCADvNx0odLuAUsZLaLHuyfZ0VcmTarclpbF28IDr/Qks5db0CzRvSx2g=  ;
Message-ID: <[e-mail]>
Date: Sat, 5 Mar 2005 06:31:57 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
To: [e-mail], Igor Bryskin <[e-mail]>
Cc: Igor Bryskin <[e-mail]>, [e-mail], LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Dimitri,

See at the bottom

> >
> >IB>>Well, are they? They give you a way to signal a
> >requirement not to commit resources for an LSP
until
> >further notice and also to require their commitment
> >when it becomes necessary. Why not to allow working
> >LSP to be signaled as Secondary according to the
> >mentioned draft? Then it would be possible even to
> >signal protected virtual FAs, which is not as
stupid
> >as it may sound :=)
>
> Sorry but this sounds really bad...
> Please let me know then how do you signal protected
virtual FAs?
>
> IB>> You signal both working and protection LSPs of
the FA as Secondary.
At
> the time when you decide to make FA "real" you
re-signal working or both
> LSPs (depending on protection type) as Primary.
Don't see why this
wouldn't
> work.
>
> DP> because what do you do in case the primary
(virtual) FA-LSP fails ?
you
> are simply going to activate the secondary (virtual)
FA-LSP which is in
> clear
> opposition with the notion of virtual-FA - the
reason is again because you
> are trying to use one bit i.e. S to say something in
a context (protection
> object) for which it has not been designed for
>

IB>> Oh-Oh, what do you mean by "primary (virtual)
FA-LSP fails" and  "you
are simply going to activate the secondary (virtual)
FA-LSP "?  I activate
protection LSP if I have a failure in the *data plane*
of the working LSP.
But working LSP of the virtual FA does not have any
data plane yet, there is
nothing that can trigger the protection LSP activation
and switchover.

DP> but they are associated to resources they do not
use - and the control plane role is to ensure that
when they need to be activated resources can be used -
the question JL raises is the problem of "how do i
protect a virtual FA" and the response is if you are
using the S bit for telling i am a virtual FA you can
not use it anymore to ensure protection of a primary
(and even less a secondary !) - this said an secondary
LSP exists only within the context of its primary

IB>>Here is what I have in mind.

A network operator configures a mesh of virtual FAs.
Working FA LSPs are signaled as Secondary. Once they
are established the FA TE link ends are advertised.
Resources for these LSPs are allocated on the links
the LSPs are going through, however, they are not
committed (not bound into cross-connects). Two or more
virtual FA LSPs may share the resources on common
links. This is especially true for those of them that
are unlikely to become real at the same time.
Furthermore, polices could be such that virtual FA LSP
resources could be allowed to get pre-empted by real
(not necessarily FA-) LSPs. The mentioned resources
also could be involved in mesh restoration schemes and
even be bound into extra traffic LSPs. 

When a virtual FA transforms into real FA, its working
FA-LSP is re-signaled as Primary. At this time, the
allocated resources are bound into FA-LSP
cross-connects. Naturally, all other LSPs – virtual or
real – that share resources with the FA-LSP in
question are notified and need to be recomputed and/or
re-signaled.

A virtual FA could be provisioned as protected in a
sense that when it becomes real it will have a certain
protection scheme already in place. Path computation
for backup LSPs of virtual FAs is performed just like
of real FAs, that is, by assuming that associated
working LSPs are Primary (fully built) LSPs.
Regardless of the protection type backup LSPs of
virtual FAs are always signaled as Secondary. At the
time when a virtual FA is transformed into real one
(that is, when its working LSP becomes Primary) its
backup LSP(s) may be activated as well (e.g. 1+1
protection) or may be left Secondary until the working
LSP data plane failure is detected (e.g. shared
protection).

Igor





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



Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 14:13:27 +0000
Message-ID: <[e-mail]>
Date: Sat, 05 Mar 2005 15:12:17 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: Status of draft-ietf-ccamp-transport-lmp
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian - i did ask a question concerning the introduction of the term 
"unidirectional" for which i did not receive any clear answer - but this 
is an "internal comment" unrelated to comments/questions from the 
previous last call/liaisons/etc.

thanks,
- dimitri.

Adrian Farrel wrote:

> Authors,
> 
> Can you tell me: Does this version of the draft address all of the issues
> raised in the WG last call and the IETF liaison?
> Or do you plan a further revision?
> 
> Thanks,
> Adrian
> ----- Original Message ----- 
> From: <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, February 21, 2005 8:26 PM
> Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-01.txt
> 
> 
> 
>>A New Internet-Draft is available from the on-line Internet-Drafts
> 
> directories.
> 
>>This draft is a work item of the Common Control and Measurement Plane
> 
> Working Group of the IETF.
> 
>>Title : A Transport Network View of LMP
>>Author(s) : D. Fedyk, et al.
>>Filename : draft-ietf-ccamp-transport-lmp-01.txt
>>Pages : 17
>>Date : 2005-2-21
>>
>>The Link Management Protocol (LMP) has been developed as part of the
>>   Generalized MPLS (GMPLS) protocol suite to manage Traffic
>>   Engineering (TE) resources and links. The GMPLS control plane
>>   (routing and signaling) uses TE links for establishing Label
>>   Switched Paths (LSPs). This memo describes the relationship of the
>>   LMP procedures to 'discovery' as defined in the International
>>   Telecommunication Union (ITU-T), and on-going ITU-T work. This
>>   document provides an overview of LMP in the context of the ITU-T
>>   Automatically Switched Optical Networks (ASON) and transport network
>>   terminology and relates it to the ITU-T discovery work to promote a
>>   common understanding for progressing the work of IETF and ITU-T.
>>
>>A URL for this Internet-Draft is:
>>
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-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-transport-lmp-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-transport-lmp-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.
>>
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 12:05:51 +0000
Message-ID: <0b6c01c5217b$4dfb3550$19cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Status of draft-ietf-ccamp-transport-lmp
Date: Sat, 5 Mar 2005 11:59:04 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Authors,

Can you tell me: Does this version of the draft address all of the issues
raised in the WG last call and the IETF liaison?
Or do you plan a further revision?

Thanks,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, February 21, 2005 8:26 PM
Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-01.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.
>
> Title : A Transport Network View of LMP
> Author(s) : D. Fedyk, et al.
> Filename : draft-ietf-ccamp-transport-lmp-01.txt
> Pages : 17
> Date : 2005-2-21
>
> The Link Management Protocol (LMP) has been developed as part of the
>    Generalized MPLS (GMPLS) protocol suite to manage Traffic
>    Engineering (TE) resources and links. The GMPLS control plane
>    (routing and signaling) uses TE links for establishing Label
>    Switched Paths (LSPs). This memo describes the relationship of the
>    LMP procedures to 'discovery' as defined in the International
>    Telecommunication Union (ITU-T), and on-going ITU-T work. This
>    document provides an overview of LMP in the context of the ITU-T
>    Automatically Switched Optical Networks (ASON) and transport network
>    terminology and relates it to the ITU-T discovery work to promote a
>    common understanding for progressing the work of IETF and ITU-T.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-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-transport-lmp-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-transport-lmp-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.
>




Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 10:45:45 +0000
Message-ID: <0a6001c5216f$81cdecd0$19cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Nortel folk on this list
Date: Sat, 5 Mar 2005 10:38:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

If there are any Nortel folk out there you might want to notify everyone
else you know in Nortel that a large number of Nortel addresses are
failing to receive CCAMP email because the company has changed its email
address.

You are kindly requested to remove your old addresses and add yourself
using the the new ones.

Thanks,
Adrian





Envelope-to: [e-mail]
Delivery-date: Sat, 05 Mar 2005 10:33:27 +0000
Message-ID: <0a3701c5216e$2c2c0a10$19cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lam, Hing-Kam \(Kam\)" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Scott Bradner" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: GMPLS Signaling Procedure for Egress Control
Date: Sat, 5 Mar 2005 09:57:24 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To: Mr. Kam Lam, rapporteur ITU-T Question 14/15
Cc: Mr. Scott Bradner, IETF liaison coordinator with the ITU-T
       Alex Zinin and Bill Fenner, IETF Routing Area Directors
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP working group chairs
Subject: GMPLS Signaling Procedure for Egress Control
For: Information

 Dear Mr. Lam

We would like to inform Question 14/15 of the publication of a new GMPLS
RFC.

RFC 4003 (ftp://ftp.rfc-editor.org/in-notes/rfc4003.txt) "GMPLS Signaling
Procedure for Egress Control" describes the procedures for control of
egress ports and labels such as might be used to establish soft permanent
LSPs. The abstract is as follows.

   This document clarifies the procedures for the control of the label
   used on an output/downstream interface of the egress node of a Label
   Switched Path (LSP).  This control is also known as "Egress Control".
   Support for Egress Control is implicit in Generalized Multi-Protocol
   Label Switching (GMPLS) Signaling.  This document clarifies the
   specification of GMPLS Signaling and does not modify GMPLS signaling
   mechanisms and procedures.

The need for clarification of these procedures was first raised by your
Question, and CCAMP is grateful for the questions and discussion that led
to the production of this RFC.

Best regards,
Adrian Farrel and Kireeti Kompella




Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 23:26:51 +0000
To: "Igor Bryskin" <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>, <[e-mail]>, "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
Date: Sat, 5 Mar 2005 00:25:55 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+Jm5ic3A7PEJSPjxCUj48Rk9OVCBTSVpFPTI+PEI+JnF1b3Q7SWdvciBCcnlza2luJnF1b3Q7
ICZsdDtpYnJ5c2tpbkBtb3Zhei5jb20mZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNl
bnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjAz
LzA0LzIwMDUgMTg6MDUgRVNUPC9GT05UPjxCUj48QlI+IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+
IDxGT05UIFNJWkU9Mj4mcXVvdDtJZ29yIEJyeXNraW4mcXVvdDsgJmx0O2lfYnJ5c2tpbkB5YWhv
by5jb20mZ3Q7LCBEaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMPC9GT05U
PjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPiZxdW90O0xFIFJPVVgg
SmVhbi1Mb3VpcyBSRC1DT1JFLUxBTiZxdW90OyAmbHQ7amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0
ZWxlY29tLmNvbSZndDssICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9GT05UPjxCUj4gPEZP
TlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6PC9GT05UPiA8
Rk9OVCBTSVpFPTI+UmU6IFJFIDogUkUgOiBUUiA6IEktRCBBQ1RJT046ZHJhZnQtbGVyb3V4LWNj
YW1wLWdtcGxzLW1ybi1ldmFsLTAwLnR4dDwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05U
IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7SUImZ3Q7Jmd0
O1dlbGwsIGFyZSB0aGV5PyBUaGV5IGdpdmUgeW91IGEgd2F5IHRvIHNpZ25hbCBhPEJSPiZndDsg
Jmd0O3JlcXVpcmVtZW50IG5vdCB0byBjb21taXQgcmVzb3VyY2VzIGZvciBhbiBMU1AgdW50aWw8
QlI+Jmd0OyAmZ3Q7ZnVydGhlciBub3RpY2UgYW5kIGFsc28gdG8gcmVxdWlyZSB0aGVpciBjb21t
aXRtZW50PEJSPiZndDsgJmd0O3doZW4gaXQgYmVjb21lcyBuZWNlc3NhcnkuIFdoeSBub3QgdG8g
YWxsb3cgd29ya2luZzxCUj4mZ3Q7ICZndDtMU1AgdG8gYmUgc2lnbmFsZWQgYXMgU2Vjb25kYXJ5
IGFjY29yZGluZyB0byB0aGU8QlI+Jmd0OyAmZ3Q7bWVudGlvbmVkIGRyYWZ0PyBUaGVuIGl0IHdv
dWxkIGJlIHBvc3NpYmxlIGV2ZW4gdG88QlI+Jmd0OyAmZ3Q7c2lnbmFsIHByb3RlY3RlZCB2aXJ0
dWFsIEZBcywgd2hpY2ggaXMgbm90IGFzIHN0dXBpZDxCUj4mZ3Q7ICZndDthcyBpdCBtYXkgc291
bmQgOj0pPEJSPiZndDs8QlI+Jmd0OyBTb3JyeSBidXQgdGhpcyBzb3VuZHMgcmVhbGx5IGJhZC4u
LjxCUj4mZ3Q7IFBsZWFzZSBsZXQgbWUga25vdyB0aGVuIGhvdyBkbyB5b3Ugc2lnbmFsIHByb3Rl
Y3RlZCB2aXJ0dWFsIEZBcz88QlI+Jmd0OzxCUj4mZ3Q7IElCJmd0OyZndDsgWW91IHNpZ25hbCBi
b3RoIHdvcmtpbmcgYW5kIHByb3RlY3Rpb24gTFNQcyBvZiB0aGUgRkEgYXMgU2Vjb25kYXJ5LjxC
Uj5BdDxCUj4mZ3Q7IHRoZSB0aW1lIHdoZW4geW91IGRlY2lkZSB0byBtYWtlIEZBICZxdW90O3Jl
YWwmcXVvdDsgeW91IHJlLXNpZ25hbCB3b3JraW5nIG9yIGJvdGg8QlI+Jmd0OyBMU1BzIChkZXBl
bmRpbmcgb24gcHJvdGVjdGlvbiB0eXBlKSBhcyBQcmltYXJ5LiBEb24ndCBzZWUgd2h5IHRoaXM8
QlI+d291bGRuJ3Q8QlI+Jmd0OyB3b3JrLjxCUj4mZ3Q7PEJSPiZndDsgRFAmZ3Q7IGJlY2F1c2Ug
d2hhdCBkbyB5b3UgZG8gaW4gY2FzZSB0aGUgcHJpbWFyeSAodmlydHVhbCkgRkEtTFNQIGZhaWxz
ID88QlI+eW91PEJSPiZndDsgYXJlIHNpbXBseSBnb2luZyB0byBhY3RpdmF0ZSB0aGUgc2Vjb25k
YXJ5ICh2aXJ0dWFsKSBGQS1MU1Agd2hpY2ggaXMgaW48QlI+Jmd0OyBjbGVhcjxCUj4mZ3Q7IG9w
cG9zaXRpb24gd2l0aCB0aGUgbm90aW9uIG9mIHZpcnR1YWwtRkEgLSB0aGUgcmVhc29uIGlzIGFn
YWluIGJlY2F1c2UgeW91PEJSPiZndDsgYXJlIHRyeWluZyB0byB1c2Ugb25lIGJpdCBpLmUuIFMg
dG8gc2F5IHNvbWV0aGluZyBpbiBhIGNvbnRleHQgKHByb3RlY3Rpb248QlI+Jmd0OyBvYmplY3Qp
IGZvciB3aGljaCBpdCBoYXMgbm90IGJlZW4gZGVzaWduZWQgZm9yPEJSPiZndDs8QlI+PC9GT05U
PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SUImZ3Q7Jmd0OyBPaC1PaCwgd2hh
dCBkbyB5b3UgbWVhbiBieSAmcXVvdDtwcmltYXJ5ICh2aXJ0dWFsKSBGQS1MU1AgZmFpbHMmcXVv
dDsgYW5kICZuYnNwOyZxdW90O3lvdTxCUj5hcmUgc2ltcGx5IGdvaW5nIHRvIGFjdGl2YXRlIHRo
ZSBzZWNvbmRhcnkgKHZpcnR1YWwpIEZBLUxTUCAmcXVvdDs/ICZuYnNwO0kgYWN0aXZhdGU8QlI+
cHJvdGVjdGlvbiBMU1AgaWYgSSBoYXZlIGEgZmFpbHVyZSBpbiB0aGUgKmRhdGEgcGxhbmUqIG9m
IHRoZSB3b3JraW5nIExTUC48QlI+QnV0IHdvcmtpbmcgTFNQIG9mIHRoZSB2aXJ0dWFsIEZBIGRv
ZXMgbm90IGhhdmUgYW55IGRhdGEgcGxhbmUgeWV0LCB0aGVyZSBpczxCUj5ub3RoaW5nIHRoYXQg
Y2FuIHRyaWdnZXIgdGhlIHByb3RlY3Rpb24gTFNQIGFjdGl2YXRpb24gYW5kIHN3aXRjaG92ZXIu
PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkRQJmd0OyBidXQg
dGhleSBhcmUgYXNzb2NpYXRlZCB0byByZXNvdXJjZXMgdGhleSBkbyBub3QgdXNlIC0gYW5kIHRo
ZSBjb250cm9sIHBsYW5lIHJvbGUgaXMgdG8gZW5zdXJlIHRoYXQgd2hlbiB0aGV5IG5lZWQgdG8g
YmUgYWN0aXZhdGVkIHJlc291cmNlcyBjYW4gYmUgdXNlZCAtIHRoZSBxdWVzdGlvbiBKTCByYWlz
ZXMgaXMgdGhlIHByb2JsZW0gb2YgJnF1b3Q7aG93IGRvIGkgcHJvdGVjdCBhIHZpcnR1YWwgRkEm
cXVvdDsgYW5kIHRoZSByZXNwb25zZSBpcyBpZiB5b3UgYXJlIHVzaW5nIHRoZSBTIGJpdCBmb3Ig
dGVsbGluZyBpIGFtIGEgdmlydHVhbCBGQSB5b3UgY2FuIG5vdCB1c2UgaXQgYW55bW9yZSB0byBl
bnN1cmUgcHJvdGVjdGlvbiBvZiBhIHByaW1hcnkgKGFuZCBldmVuIGxlc3MgYSBzZWNvbmRhcnkg
ISkgLSB0aGlzIHNhaWQgYW4gc2Vjb25kYXJ5IExTUCBleGlzdHMgb25seSB3aXRoaW4gdGhlIGNv
bnRleHQgb2YgaXRzIHByaW1hcnk8L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48UD48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+PEJSPjwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 23:05:34 +0000
Message-ID: <002101c5210e$a1a2d8b0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, <[e-mail]>
Cc: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>, <[e-mail]>
Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
Date: Fri, 4 Mar 2005 18:05:17 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> >
> >IB>>Well, are they? They give you a way to signal a
> >requirement not to commit resources for an LSP until
> >further notice and also to require their commitment
> >when it becomes necessary. Why not to allow working
> >LSP to be signaled as Secondary according to the
> >mentioned draft? Then it would be possible even to
> >signal protected virtual FAs, which is not as stupid
> >as it may sound :=)
>
> Sorry but this sounds really bad...
> Please let me know then how do you signal protected virtual FAs?
>
> IB>> You signal both working and protection LSPs of the FA as Secondary.
At
> the time when you decide to make FA "real" you re-signal working or both
> LSPs (depending on protection type) as Primary. Don't see why this
wouldn't
> work.
>
> DP> because what do you do in case the primary (virtual) FA-LSP fails ?
you
> are simply going to activate the secondary (virtual) FA-LSP which is in
> clear
> opposition with the notion of virtual-FA - the reason is again because you
> are trying to use one bit i.e. S to say something in a context (protection
> object) for which it has not been designed for
>

IB>> Oh-Oh, what do you mean by "primary (virtual) FA-LSP fails" and  "you
are simply going to activate the secondary (virtual) FA-LSP "?  I activate
protection LSP if I have a failure in the *data plane* of the working LSP.
But working LSP of the virtual FA does not have any data plane yet, there is
nothing that can trigger the protection LSP activation and switchover.

Igor




Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 22:51:41 +0000
To: Igor Bryskin <[e-mail]>
Cc: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>, [e-mail]
From: [e-mail]
Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
MIME-Version: 1.0
Date: Fri, 4 Mar 2005 23:51:02 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

>> I wouldn't be so expeditious...
>> Actually we could use a similar mechanism but
>> definitely not the same.
>> Secondary LSP are dedicated to Shared Meshed
>> Restoration.
>> IMHO this would be bad to use the Protection object
>> for soft-FAs. Semantics
>> are pretty different...
>>
>
>IB>>Well, are they? They give you a way to signal a
>requirement not to commit resources for an LSP until
>further notice and also to require their commitment
>when it becomes necessary. Why not to allow working
>LSP to be signaled as Secondary according to the
>mentioned draft? Then it would be possible even to
>signal protected virtual FAs, which is not as stupid
>as it may sound :=)

Sorry but this sounds really bad...
Please let me know then how do you signal protected virtual FAs?

IB>> You signal both working and protection LSPs of the FA as Secondary. At
the time when you decide to make FA "real" you re-signal working or both
LSPs (depending on protection type) as Primary. Don't see why this wouldn't
work.

DP> because what do you do in case the primary (virtual) FA-LSP fails ? you
are simply going to activate the secondary (virtual) FA-LSP which is in
clear
opposition with the notion of virtual-FA - the reason is again because you
are trying to use one bit i.e. S to say something in a context (protection
object) for which it has not been designed for





Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 22:20:14 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=DtxrKT8R6VQU9aRPkJ0XphvKDtZZDdct/0+9EdNXHYtQoZ8b3zIs4KdZ83ZmqZtmOVITo/+gCPtVyfj0RfSN8dNFzPjZ/GN/bmdf06yum5KO1YuodHxGXCmVVdMphWtO5aH2seBEHEilwUJa39j7AhvSHRgtwkEbKb3j4GScNaE=  ;
Message-ID: <[e-mail]>
Date: Fri, 4 Mar 2005 14:19:20 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: A philosophical question about FA and FA-LSP
To: Kireeti Kompella <[e-mail]>, Igor Bryskin <[e-mail]>
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-154085893-1109974760=:69340"

--0-154085893-1109974760=:69340
Content-Type: text/plain; charset=us-ascii

Thanks, Kireeti
 

Kireeti Kompella <[e-mail]> wrote:
On Fri, 4 Mar 2005, Kireeti Kompella wrote:

> But from the point of view of the IGP, or an LSR in that IGP, they
> can't tell an FA TE link from any other TE link.

Correction: it has been pointed out that the above statement about
LSRs applies to all LSRs except those at the two ends of the FA LSP.

Kireeti.
-------


		
---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
 Yahoo! Netrospective: 100 Moments of the Web 
--0-154085893-1109974760=:69340
Content-Type: text/html; charset=us-ascii

<DIV>Thanks, Kireeti</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><B><I>Kireeti Kompella &lt;[e-mail]&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On Fri, 4 Mar 2005, Kireeti Kompella wrote:<BR><BR>&gt; But from the point of view of the IGP, or an LSR in that IGP, they<BR>&gt; can't tell an FA TE link from any other TE link.<BR><BR>Correction: it has been pointed out that the above statement about<BR>LSRs applies to all LSRs except those at the two ends of the FA LSP.<BR><BR>Kireeti.<BR>-------<BR><BR></BLOCKQUOTE><p>
		<hr size=1>Celebrate Yahoo!'s 10th Birthday! <br> 
<a href="http://birthday.yahoo.com/netrospective/">Yahoo! Netrospective: 100 Moments of the Web</a> 
--0-154085893-1109974760=:69340--



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 21:26:21 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=v5G7BiV3M0/ttfSBJZRNwKMjgDqMF4T9KKWTYkcSQ+9e7T8MfRvm1q7pqCFTjiURMCoM23Z+Cd8wrYzcNw8spuR7uJ6Mu2KdDk3EdXerHbyFIamkGl4wQlH6sLUWHmz0w/3m55lhXQYrbf9bO22VbLg819qR1/kxaNNZfGlbDZo=  ;
Message-ID: <[e-mail]>
Date: Fri, 4 Mar 2005 13:25:44 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1320231352-1109971544=:2579"

--0-1320231352-1109971544=:2579
Content-Type: text/plain; charset=us-ascii


>> 
>> I wouldn't be so expeditious...
>> Actually we could use a similar mechanism but
>> definitely not the same.
>> Secondary LSP are dedicated to Shared Meshed
>> Restoration.
>> IMHO this would be bad to use the Protection object
>> for soft-FAs. Semantics
>> are pretty different...
>> 
>
>IB>>Well, are they? They give you a way to signal a
>requirement not to commit resources for an LSP until
>further notice and also to require their commitment
>when it becomes necessary. Why not to allow working
>LSP to be signaled as Secondary according to the
>mentioned draft? Then it would be possible even to
>signal protected virtual FAs, which is not as stupid
>as it may sound :=)

Sorry but this sounds really bad...
Please let me know then how do you signal protected virtual FAs?

IB>> You signal both working and protection LSPs of the FA as Secondary. At the time when you decide to make FA “real” you re-signal working or both LSPs (depending on protection type) as Primary. Don’t see why this wouldn’t work.

Igor


		
---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
 Yahoo! Netrospective: 100 Moments of the Web 
--0-1320231352-1109971544=:2579
Content-Type: text/html; charset=us-ascii

<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 3pt; PADDING-BOTTOM: 0in; BORDER-LEFT: #1010ff 1pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<P class=MsoNormal style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN: 0in 0.5in 0pt 2.5pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">&gt;&gt; <BR>&gt;&gt; I wouldn't be so expeditious...<BR>&gt;&gt; Actually we could use a similar mechanism but<BR>&gt;&gt; definitely not the same.<BR>&gt;&gt; Secondary LSP are dedicated to Shared Meshed<BR>&gt;&gt; Restoration.<BR>&gt;&gt; IMHO this would be bad to use the Protection object<BR>&gt;&gt; for soft-FAs. Semantics<BR>&gt;&gt; are pretty different...<BR>&gt;&gt; <BR>&gt;<BR>&gt;IB&gt;&gt;Well, are they? They give you a way to signal a<BR>&gt;requirement not to commit resources for an LSP until<BR>&gt;further notice and also to require their
 commitment<BR>&gt;when it becomes necessary. Why not to allow working<BR>&gt;LSP to be signaled as Secondary according to the<BR>&gt;mentioned draft? Then it would be possible even to<BR>&gt;signal protected virtual FAs, which is not as stupid<BR>&gt;as it may sound :=)<BR><BR>Sorry but this sounds really bad...<BR>Please let me know then how do you signal protected virtual FAs?<BR><BR>IB&gt;&gt; You signal both working and protection LSPs of the FA as Secondary. At the time when you decide to make FA “real” you re-signal working or both LSPs (depending on protection type) as Primary. Don’t see why this wouldn’t work.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<P class=MsoNormal style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN: 0in 0.5in 0pt 2.5pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Igor</SPAN></P></DIV><p>
		<hr size=1>Celebrate Yahoo!'s 10th Birthday! <br> 
<a href="http://birthday.yahoo.com/netrospective/">Yahoo! Netrospective: 100 Moments of the Web</a> 
--0-1320231352-1109971544=:2579--



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 20:29:18 +0000
Message-ID: <058e01c520f7$26698e30$19cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Richard Rabbat" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Sadler, Jonathan B.'" <[e-mail]>, "'Ong, Lyndon'" <[e-mail]>, "'Richard Rabbat'" <[e-mail]>, <[e-mail]>, "'Greg Bernstein'" <[e-mail]>
Subject: Re: question about RFC 3946
Date: Fri, 4 Mar 2005 19:26:45 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Whatever technical answer we end up with, can we stick with the phrases
"strictly greater" and "greater or equal" as appropriate, and avoid the
(apparently) ambiguous "greater".

Thanks,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: "Richard Rabbat" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
"'Sadler, Jonathan B.'" <[e-mail]>; "'Ong, Lyndon'"
<[e-mail]>; "'Adrian Farrel'" <[e-mail]>; "'Richard
Rabbat'" <[e-mail]>; <[e-mail]>; "'Greg
Bernstein'" <[e-mail]>
Sent: Tuesday, March 01, 2005 6:57 PM
Subject: Re: question about RFC 3946


>
> richard:
>
> "greater" does not mean "strictly greater" it means "greater or equal"
>
> So, what values of NCC and RCC should one use for STS-3c/VC-4?
>
> for STS-3c:
>         An STS-3c SPE signal is formed by the application of RCC with
>         value 1 (standard contiguous concatenation), NCC with value 1,
>         NVC with value 0, MT with value 1 and T with value 0 to an STS-
>         3c SPE Elementary Signal.
>
> for VC-4:
>         A VC-4 signal is formed by the application of RCC with value 0,
>         NCC with value 0, NVC with value 0, MT with value 1 and T with
>         value 0 to a VC-4 Elementary Signal.
>
> do not know if this clarifies -
>
> hint: Note 2 refers to transparent STS-N/STM-N signals (signal type
7->12)
>
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 19:23:03 +0000
Date: Fri, 4 Mar 2005 11:22:43 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: A philosophical question about FA and FA-LSP
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 4 Mar 2005, Kireeti Kompella wrote:

> But from the point of view of the IGP, or an LSR in that IGP, they
> can't tell an FA TE link from any other TE link.

Correction: it has been pointed out that the above statement about
LSRs applies to all LSRs except those at the two ends of the FA LSP.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 18:58:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
Date: Fri, 4 Mar 2005 19:56:22 +0100
Message-ID: <[e-mail]>
Thread-Topic: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
Thread-Index: AcUgvc80KlMsDPzJSDi5II1t1/lYvgAKySNw
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, <[e-mail]>

Igor,

Please see inline

Regards,

JL

>-----Message d'origine-----
>De : Igor Bryskin [mailto:[e-mail]]=20
>Envoy=E9 : vendredi 4 mars 2005 14:26
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN; [e-mail]
>Objet : Re: RE : TR : I-D=20
>ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20
>
>
>JL,
>
>Please, see my comments in-line
>
>Igor
>
>--- LE ROUX Jean-Louis RD-CORE-LAN=20
><[e-mail]> wrote:
>
>> Hi Igor,
>>=20
>> Thanks for these comments
>>=20
>> Please see inline
>>=20
>>=20
>> >-----Message d'origine-----
>> >De : Igor Bryskin [mailto:[e-mail]]
>> >Envoy=E9 : jeudi 3 mars 2005 20:45
>> >=C0 : LE ROUX Jean-Louis RD-CORE-LAN;
>> [e-mail]
>> >Objet : Re: TR : I-D
>> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
>> >
>> >
>> >JL,
>> >
>> >I have a couple of comments/suggestions.
>> >
>> >1.	The draft says that currently GMPLS does not
>> have a
>> >mechanism to provision virtual FAs. I don't think
>> this
>> >is correct - I believe we could use the same
>> mechanism
>> >as was suggested in
>> >draft-ietf-ccamp-gmpls-recovery-e2e-signaling
>> (section
>> >9.3) for signaling of Secondary LSPs
>>=20
>> I wouldn't be so expeditious...
>> Actually we could use a similar mechanism but
>> definitely not the same.
>> Secondary LSP are dedicated to Shared Meshed
>> Restoration.
>> IMHO this would be bad to use the Protection object
>> for soft-FAs. Semantics
>> are pretty different...
>>=20
>
>IB>>Well, are they? They give you a way to signal a
>requirement not to commit resources for an LSP until
>further notice and also to require their commitment
>when it becomes necessary. Why not to allow working
>LSP to be signaled as Secondary according to the
>mentioned draft? Then it would be possible even to
>signal protected virtual FAs, which is not as stupid
>as it may sound :=3D)

Sorry but this sounds really bad...
Please let me know then how do you signal protected virtual FAs?

>
>>=20
>> >2.	I agree that we need TE link adaptation
>> >capabilities to be advertised along with other TE
>> link
>> >attributes such as switching capabilities,
>> protection
>> >capabilities, etc. I suggest also adding TE link
>> termination
>> >capabilities to this list, i.e. decoupling of these
>>=20
>> >capabilities from adaptation capabilities:
>> >to terminate LSP in a particular layer and to adopt
>> >into it LSPs of one or more higher layers are
>> separate
>> >resources and could be considered separately in the
>>=20
>> >inter-layer path computations;
>>=20
>> I agree that our curent terminology may be confusing
>> What we call Internal Adapatation Capability
>> actually refers to Termination capabilities.
>> See the MRN requirement draft (version 01) for an
>=D8	example.
>
>IB>> My point is that termination and adaptation
>capabilities are separate things. For instance, the
>fact that a link can terminate lambdas means the it
>has certain number of available transceivers, while
>the fact whether these lambdas can carry particular
>tributary signals depends, say, on whether SIM cards
>of appropriate type could be cross-connected to the=20
>transceivers. In fact, link termination bandwidth is shared=20
>between multiple adaptation functions. The bottom line is I=20
>think it would be good idea to advertise them separately.
>

IMHO all what is missing in GMPLS-RTG is the advertisement of the =
internal termination capabilities (a.k.a internal adaptation capability =
in our draft...).=20
This is useful only when doing inter-region path computation.=20
IMHO we just need to find an appropriate terminology.

>>=20
>>=20
>> >3.	Everything that is said about regions, region
>> >boundaries, etc. is also applicable for layers
>> >contained within regions. I suggest to do what we
>> have
>> >already done in the PCE WG documents and
>> >presentations: replace word region with word layer everywhere apart=20
>> >from where signaling specific
>> aspects
>> >are discussed.
>>=20
>> See section 3 of the requirement draft.
>> Actually what we define for region also applies to
>> layers, but we prefer to
>=D8	keep the term region here at the time being.
>
>IB>> And my question is why to do so, if FAs and
>everything to do with VNT is about layers, including
>those that start and stop in the middle of the region,
>that is, far away from region boundaries? Furthermore,
>when you say things like creating FA in the lower
>region to carry LSP for the higher region, it is not
>clear what do you mean by that in the case when the
>lower region contains multiple layers.

You are right this applies also to multi-layers.
We will clarify in next revision, but note that this is already =
clarified in the=20
MRN req draft (see section 3).

Thanks again,

JL



>
>Igor
>
>>=20
>> Again, thanks a lot for these comments,
>>=20
>> Regards,
>>=20
>> JL
>>=20
>> >
>> >Thanks,
>> >Igor
>> >  =20
>> >
>> >
>> >--- LE ROUX Jean-Louis RD-CORE-LAN
>> ><[e-mail]> wrote:
>> >
>> >
>> >
>> >>=20
>> >> Hi all,
>> >>=20
>> >> Here is a new draft evaluating current GMPLS
>> >> protocols wrt MRN
>> >> requirements.
>> >> Your comments on this new draft would be highly appreciated.
>> >>=20
>> >> Best Regards,
>> >>=20
>> >> JL
>> >>=20
>> >> To: i-d-announce at ietf.org
>> >> Subject: I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
>> >> From: Internet-Drafts at ietf.org=20
>> >> Date: Tue, 15 Feb 2005 10:14:38 -0500=20
>> >>=20
>> >> A New Internet-Draft is available from the
>> on-line Internet-Drafts
>> >> directories.
>> >>=20
>> >>=20
>> >> 	Title		: Evaluation of existing GMPLS Protocols
>> >> against
>> >> Multi Region Networks
>> >> 	Author(s)	: J. Le Roux, et al.
>> >> 	Filename	:
>> draft-leroux-ccamp-gmpls-mrn-eval-00.txt
>> >> 	Pages		: 11
>> >> 	Date		: 2005-2-14
>> >> =09
>> >> This document provides an evaluation of
>> Generalized Multi-Protocol
>> >>    Label Switching (GMPLS) protocols and
>> mechanisms
>> >> against the=20
>> >>    requirements for Multi Region Networks (MRN).
>> =20
>> >>    In addition, this document identifies areas
>> where
>> >> additional=20
>> >>    protocol extensions or procedures are needed
>> to
>> >> satisfy the=20
>> >>    requirements of Multi Region Networks, and
>> >> provides guidelines for=20
>> >>    potential extensions.
>> >>=20
>> >> A URL for this Internet-Draft is:
>> >>
>>
>>http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr
>> n-eval-00
>> > .txt
>> >=20
>> >=20
>> >=20
>> >=20
>> >
>>=20
>>=20
>>=20
>> =09
>> 	=09
>> __________________________________
>> Celebrate Yahoo!'s 10th Birthday!=20
>> Yahoo! Netrospective: 100 Moments of the Web=20
>> http://birthday.yahoo.com/netrospective/
>>
>
>
>
>=09
>	=09
>__________________________________=20
>Celebrate Yahoo!'s 10th Birthday!=20
>Yahoo! Netrospective: 100 Moments of the Web=20
>http://birthday.yahoo.com/netrospective/
>



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 18:41:08 +0000
Date: Fri, 4 Mar 2005 10:40:45 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: A philosophical question about FA and FA-LSP
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 4 Mar 2005, Igor Bryskin wrote:

> My question was what is (if any) special about FA TE link apart from
> the fact that it is dynamically created/destroyed?

Actually, an FA TE link doesn't have to be dynamically
created/destroyed.

What's special?  Nothing really.  A "normal" TE link usually has a
(single) physical interface associated with it; an FA TE link is
usually multi-hop.  A "normal" TE link usually is accompanied by an
IGP adjacency (at least, in the packet domain); an FA TE link usually
doesn't.

But from the point of view of the IGP, or an LSR in that IGP, they
can't tell an FA TE link from any other TE link.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 18:07:50 +0000
Message-ID: <00ad01c520e5$013fdf90$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: A philosophical question about FA and FA-LSP
Date: Fri, 4 Mar 2005 13:07:18 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

My question was what is (if any) special about FA TE link apart from the
fact that it is dynamically created/destroyed?

Igor


----- Original Message ----- 
From: "Kireeti Kompella" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, March 04, 2005 12:53 PM
Subject: Re: A philosophical question about FA and FA-LSP


> On Fri, 4 Mar 2005, Igor Bryskin wrote:
>
> > I have a question to Kireti and Yakov.
> ...
> > My question is:  can I draw a conclusion from the above that it is
> > not required anymore for an FA to be advertised into the same
> > instance of IGP-TE as was used for the advertising of the FA-LSP
> > constituent TE links.
>
> Correct -- LSPs created in IGP A can be advertised as TE links in IGP B.
> This can be used (say) for inter-area signaling.
>
> > In other words, if an LSP created by one instance of the control
> > plane (say, L1VPN Provider) and advertised as a TE link into another
> > instance of the control plane (say, VPN), would/should such TE link
> > be treated anyhow different from the LSP advertised into the same
> > instance of control plane.
>
> The advertisement into the VPN control plane is just a TE link for the
> VPN IGP-TE.
>
> Kireeti.
> -------
>




Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 17:54:43 +0000
Date: Fri, 4 Mar 2005 09:53:29 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: A philosophical question about FA and FA-LSP
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 4 Mar 2005, Igor Bryskin wrote:

> I have a question to Kireti and Yakov.
...
> My question is:  can I draw a conclusion from the above that it is
> not required anymore for an FA to be advertised into the same
> instance of IGP-TE as was used for the advertising of the FA-LSP
> constituent TE links.

Correct -- LSPs created in IGP A can be advertised as TE links in IGP B.
This can be used (say) for inter-area signaling.

> In other words, if an LSP created by one instance of the control
> plane (say, L1VPN Provider) and advertised as a TE link into another
> instance of the control plane (say, VPN), would/should such TE link
> be treated anyhow different from the LSP advertised into the same
> instance of control plane.

The advertisement into the VPN control plane is just a TE link for the
VPN IGP-TE.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 16:43:33 +0000
Message-ID: <00a201c520d9$290913e0$[e-mail]>
Reply-To: "Igor Bryskin" <[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, "Kireeti Kompella" <[e-mail]>
Cc: <[e-mail]>
Subject: A philosophical question about FA and FA-LSP
Date: Fri, 4 Mar 2005 11:42:31 -0500
Organization: Movaz Networks
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01C520AF.4003BE80"

This is a multi-part message in MIME format.

------=_NextPart_000_009F_01C520AF.4003BE80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

Hi,

=20

I have a question to Kireti and Yakov.

=20

This is from draft-ietf-ccamp-gmpls-routing-09.txt:=20

=20

Traditionally, a TE link is advertised as an adjunct to a "regular"   =
link, i.e., a routing adjacency is brought up on the link, and when   =
the link is up, both the properties of the link used for Shortest   Path =
First (SPF) computations (basically, the SPF metric) and the TE   =
properties of the link are then advertised.    GMPLS challenges this =
notion in three ways.  First, links that are   not capable of sending =
and receiving on a packet-by-packet basis may   yet have TE properties; =
however, a routing adjacency cannot be   brought up on such links.  =
Second, a Label Switched Path can be   advertised as a point-to-point TE =
link (see [LSP-HIER]); thus, an   advertised TE link may be between a =
pair of nodes that don't have a   routing adjacency with each other.  =
Finally, a number of links may be   advertised as a single TE link =
(perhaps for improved scalability), so   again, there is no longer a =
one-to-one association of a regular   routing adjacency and a TE link.   =
 Thus we have a more general notion of a TE link.  A TE link is a   =
"logical" link that has TE properties. . My question is:  can I draw a =
conclusion from the above that it is not required anymore for an FA to =
be advertised into the same instance of IGP-TE as was used for the =
advertising of the FA-LSP constituent TE links. In other words, if an =
LSP created by one instance of the control plane (say, L1VPN Provider) =
and advertised as a TE link into another instance of the control plane =
(say, VPN), would/should such TE link be treated anyhow different from =
the LSP advertised into the same instance of control plane. Thanks,Igor=20

=20

=20

------=_NextPart_000_009F_01C520AF.4003BE80
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.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt">&nbsp;<?xml:namespace =
prefix =3D o=20
ns =3D "urn:schemas-microsoft-com:office:office" /><o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt">Hi,</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt">&nbsp;<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt">I have a question to =
Kireti and=20
Yakov.</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in =
0pt">&nbsp;<o:p></o:p></P><PRE><SPAN style=3D"FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt"><FONT face=3D"Arial Unicode MS">This is from =
draft-ietf-ccamp-gmpls-routing-09.txt:<o:p></o:p></FONT></SPAN></PRE>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt">&nbsp;<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in =
0pt">&nbsp;<o:p></o:p></P><PRE><I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: =
10.0pt">Traditionally, a TE link is advertised as an adjunct to a =
"regular"<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: =
12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>link, i.e., a routing =
adjacency is brought up on the link, and =
when<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>the link is up, both the =
properties of the link used for =
Shortest<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: =
12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Path First (SPF) =
computations (basically, the SPF metric) and the =
TE<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>properties of the link =
are then advertised.<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN =
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: =
10.0pt">&nbsp;<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN =
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp; </SPAN>GMPLS challenges this notion in three =
ways.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>First, links that =
are<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>not capable of sending =
and receiving on a packet-by-packet basis =
may<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>yet have TE properties; =
however, a routing adjacency cannot =
be<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>brought up on such =
links.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Second, a Label =
Switched Path can be<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN =
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp; </SPAN>advertised as a point-to-point TE link (see =
[LSP-HIER]); thus, an<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN =
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp; </SPAN>advertised TE link may be between a pair of =
nodes that don't have a<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN =
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp; </SPAN>routing adjacency with each other.<SPAN =
style=3D"mso-spacerun: yes">&nbsp; </SPAN>Finally, a number of links may =
be<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>advertised as a single =
TE link (perhaps for improved scalability), =
so<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>again, there is no =
longer a one-to-one association of a =
regular<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: =
12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>routing adjacency and a =
TE link.<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: =
12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: =
10.0pt">&nbsp;<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN =
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp; </SPAN>Thus we have a more general notion of a TE =
link.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>A TE link is =
a<o:p></o:p></SPAN></I></PRE><PRE><I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>"logical" link that has =
TE properties. =85</SPAN></I><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: =
10.0pt"><o:p></o:p></SPAN></PRE><PRE><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: =
10.0pt">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN style=3D"FONT-SIZE: =
12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt">My =
question is:  can I draw a conclusion from the above that it is not =
required anymore for an FA to be advertised into the same instance of =
IGP-TE as was used for the advertising of the FA-LSP constituent TE =
links.</SPAN></PRE><PRE><SPAN style=3D"FONT-SIZE: 12pt; FONT-FAMILY: =
'Times New Roman'; mso-bidi-font-size: 10.0pt"> In other words, if an =
LSP created by one instance of the control plane (say, L1VPN Provider) =
and advertised as a TE link into another instance of the control plane =
(say, VPN), would/should such TE link be treated </SPAN></PRE><PRE><SPAN =
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt">anyhow different from the LSP advertised =
into the same instance of control =
plane.<o:p></o:p></SPAN></PRE><PRE><SPAN style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: =
10.0pt">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN style=3D"FONT-SIZE: =
12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: =
10.0pt">Thanks,<o:p></o:p></SPAN></PRE><PRE><SPAN style=3D"FONT-SIZE: =
12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: =
10.0pt">Igor<o:p></o:p></SPAN></PRE>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in =
0pt"><I>&nbsp;<o:p></o:p></I></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt">&nbsp;<o:p></o:p></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt">&nbsp;<o:p></o:p></P></DIV></BODY></HTML>

------=_NextPart_000_009F_01C520AF.4003BE80--




Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 16:03:57 +0000
Message-ID: <007501c520d3$b9d8f940$19cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Zafar Ali" <[e-mail]>, "'Richard Rabbat'" <[e-mail]>, <[e-mail]>
Subject: Re: Draft status updated on alternate CCAMP web page
Date: Fri, 4 Mar 2005 15:40:08 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

When something is left entirely undone, no-one objects.
When something is half done, everyone demands perfection.

Contrary to popular opinion, I am only human.
I hope to complete this task before Minneapolis.

Adrian

----- Original Message ----- 
From: "Zafar Ali" <[e-mail]>
To: "'Richard Rabbat'" <[e-mail]>; "'Adrian Farrel'"
<[e-mail]>; <[e-mail]>
Sent: Tuesday, March 01, 2005 8:08 PM
Subject: RE: Draft status updated on alternate CCAMP web page


> Hi Richard,
>
> Re: the ID (draft-shiomoto-ccamp-gmpls-addressing-00), I did find it
quite
> useful and IMO we should pursue this further in CCAMP.
>
> Having said that, I would like to point that there are a number of ID-es
> that are currently NOT in Adrian's list and I think this has to do with
his
> comment in the original email (quoting Adrian): "I have yet to update
the
> section that covers personal drafts related to CCAMP." Adrian, please
> correct me/ add/ del.
>
> Thanks
>
> Regards... Zafar
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Richard Rabbat
> > Sent: Thursday, February 24, 2005 1:52 PM
> > To: 'Adrian Farrel'; [e-mail]
> > Subject: RE: Draft status updated on alternate CCAMP web page
> >
> > Adrian,
> > Can you add
> > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls
> > -addressing-00
> > .txt
> > to your draft tracker?
> >
> > We sent out email about it and have received feedback
> > off-list. We're planning on discussing this draft in
> > Minneapolis and would love to have more on-list discussions.
> > As you can see from the list of contributors, there is
> > enormous interest in this draft and we hope it serves as a
> > basis for thoughtful discussions.
> > Best,
> > Richard, Rajiv and Kohei.
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > > Sent: Monday, February 21, 2005 10:35 AM
> > > To: Adrian Farrel; [e-mail]
> > > Subject: Re: Draft status updated on alternate CCAMP web page
> > >
> > >
> > > So, I can't type.
> > > Want to make something of it?
> > > http://www.olddog.co.uk/ccamp-drafts.htm
> > >
> > > (Thanks Jean-Louis)
> > >
> > > Adrian
> > >
> > > ----- Original Message -----
> > > From: "Adrian Farrel" <[e-mail]>
> > > To: <[e-mail]>
> > > Sent: Monday, February 21, 2005 12:32 PM
> > > Subject: Draft status updated on alternate CCAMP web page
> > >
> > >
> > > > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to
> > > indicate the
> > > > current status of all CCAMP drafts. I have yet to update
> > the section
> > > that
> > > > covers personal drafts related to CCAMP.
> > > >
> > > > Adrian
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 14:00:20 +0000
To: Igor Bryskin <[e-mail]>
Cc: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
Date: Fri, 4 Mar 2005 14:59:24 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+aWdvciAtIGEgc2hvcnQgaGludCBjb25jZXJuaW5nIHRoZSBmaXJzdCBwb2ludDxCUj48QlI+
PEZPTlQgU0laRT0yPjxCPklnb3IgQnJ5c2tpbiAmbHQ7aV9icnlza2luQHlhaG9vLmNvbSZndDs8
L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+U2VudCBieTogb3duZXItY2NhbXBAb3BzLmlldGYu
b3JnPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDMvMDQvMjAwNSAwNToyNiBQU1Q8L0ZPTlQ+PEJS
PjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQgU0laRT0yPkxFIFJPVVggSmVhbi1M
b3VpcyBSRC1DT1JFLUxBTiAmbHQ7amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29tLmNvbSZn
dDssIGNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+
IDxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6
PC9GT05UPiA8Rk9OVCBTSVpFPTI+UmU6IFJFIDogVFIgOiBJLUQgQUNUSU9OOmRyYWZ0LWxlcm91
eC1jY2FtcC1nbXBscy1tcm4tZXZhbC0wMC50eHQ8L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48
Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SkwsPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPlBsZWFzZSwgc2VlIG15IGNvbW1lbnRzIGluLWxpbmU8QlI+
PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SWdvcjxCUj48L0ZPTlQ+
PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tLS0gTEUgUk9VWCBKZWFuLUxvdWlz
IFJELUNPUkUtTEFOPEJSPiZsdDtqZWFubG91aXMubGVyb3V4QGZyYW5jZXRlbGVjb20uY29tJmd0
OyB3cm90ZTo8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0
OyBIaSBJZ29yLDxCUj4mZ3Q7PEJSPiZndDsgVGhhbmtzIGZvciB0aGVzZSBjb21tZW50czxCUj4m
Z3Q7PEJSPiZndDsgUGxlYXNlIHNlZSBpbmxpbmU8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgJmd0
Oy0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxCUj4mZ3Q7ICZndDtEZSA6IElnb3IgQnJ5c2tp
biBbbWFpbHRvOmlfYnJ5c2tpbkB5YWhvby5jb21dPEJSPiZndDsgJmd0O0Vudm95JmVhY3V0ZTsg
OiBqZXVkaSAzIG1hcnMgMjAwNSAyMDo0NTxCUj4mZ3Q7ICZndDsmQWdyYXZlOyA6IExFIFJPVVgg
SmVhbi1Mb3VpcyBSRC1DT1JFLUxBTjs8QlI+Jmd0OyBjY2FtcEBvcHMuaWV0Zi5vcmc8QlI+Jmd0
OyAmZ3Q7T2JqZXQgOiBSZTogVFIgOiBJLUQ8QlI+Jmd0OyBBQ1RJT046ZHJhZnQtbGVyb3V4LWNj
YW1wLWdtcGxzLW1ybi1ldmFsLTAwLnR4dDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZn
dDsgJmd0O0pMLDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7SSBoYXZlIGEgY291cGxlIG9mIGNv
bW1lbnRzL3N1Z2dlc3Rpb25zLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7MS5UaGUgZHJhZnQg
c2F5cyB0aGF0IGN1cnJlbnRseSBHTVBMUyBkb2VzIG5vdDxCUj4mZ3Q7IGhhdmUgYTxCUj4mZ3Q7
ICZndDttZWNoYW5pc20gdG8gcHJvdmlzaW9uIHZpcnR1YWwgRkFzLiBJIGRvbid0IHRoaW5rPEJS
PiZndDsgdGhpczxCUj4mZ3Q7ICZndDtpcyBjb3JyZWN0IC0gSSBiZWxpZXZlIHdlIGNvdWxkIHVz
ZSB0aGUgc2FtZTxCUj4mZ3Q7IG1lY2hhbmlzbTxCUj4mZ3Q7ICZndDthcyB3YXMgc3VnZ2VzdGVk
IGluPEJSPiZndDsgJmd0O2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtcmVjb3ZlcnktZTJlLXNpZ25h
bGluZzxCUj4mZ3Q7IChzZWN0aW9uPEJSPiZndDsgJmd0OzkuMykgZm9yIHNpZ25hbGluZyBvZiBT
ZWNvbmRhcnkgTFNQczxCUj4mZ3Q7PEJSPiZndDsgSSB3b3VsZG4ndCBiZSBzbyBleHBlZGl0aW91
cy4uLjxCUj4mZ3Q7IEFjdHVhbGx5IHdlIGNvdWxkIHVzZSBhIHNpbWlsYXIgbWVjaGFuaXNtIGJ1
dDxCUj4mZ3Q7IGRlZmluaXRlbHkgbm90IHRoZSBzYW1lLjxCUj4mZ3Q7IFNlY29uZGFyeSBMU1Ag
YXJlIGRlZGljYXRlZCB0byBTaGFyZWQgTWVzaGVkPEJSPiZndDsgUmVzdG9yYXRpb24uPEJSPiZn
dDsgSU1ITyB0aGlzIHdvdWxkIGJlIGJhZCB0byB1c2UgdGhlIFByb3RlY3Rpb24gb2JqZWN0PEJS
PiZndDsgZm9yIHNvZnQtRkFzLiBTZW1hbnRpY3M8QlI+Jmd0OyBhcmUgcHJldHR5IGRpZmZlcmVu
dC4uLjxCUj4mZ3Q7PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
PklCJmd0OyZndDtXZWxsLCBhcmUgdGhleT8gVGhleSBnaXZlIHlvdSBhIHdheSB0byBzaWduYWwg
YTxCUj5yZXF1aXJlbWVudCBub3QgdG8gY29tbWl0IHJlc291cmNlcyBmb3IgYW4gTFNQIHVudGls
PEJSPmZ1cnRoZXIgbm90aWNlIGFuZCBhbHNvIHRvIHJlcXVpcmUgdGhlaXIgY29tbWl0bWVudDxC
Uj53aGVuIGl0IGJlY29tZXMgbmVjZXNzYXJ5LiBXaHkgbm90IHRvIGFsbG93IHdvcmtpbmc8QlI+
TFNQIHRvIGJlIHNpZ25hbGVkIGFzIFNlY29uZGFyeSBhY2NvcmRpbmcgdG8gdGhlPEJSPm1lbnRp
b25lZCBkcmFmdD8gVGhlbiBpdCB3b3VsZCBiZSBwb3NzaWJsZSBldmVuIHRvPEJSPnNpZ25hbCBw
cm90ZWN0ZWQgdmlydHVhbCBGQXMsIHdoaWNoIGlzIG5vdCBhcyBzdHVwaWQ8QlI+YXMgaXQgbWF5
IHNvdW5kIDo9KTxCUj48L0ZPTlQ+PEJSPkRQJmd0OyBiZWNhdXNlIGl0IHdvdWxkIHJlcXVpcmUg
Y29uc2lkZXJpbmcgd29ya2luZyBzZWNvbmRhcmllcyAtIHRoaXMgY29tYmluYXRpb24gaXMgcHJl
Y2x1ZGVkIGFzIGl0IGRvZXMgbm90IG1ha2UgYW55IHNlbnNlIChzZWUgdGhlIGRvY3VtZW50LCBh
IGJpdCBhIHNpbmdsZSBzZW1hbnRpYykgd2hpbGUgdGhlIGNvbWJpbmF0aW9uIHByb3RlY3Rpbmcg
c2Vjb25kYXJ5IGlzIGFscmVhZHkgZGV0ZXJtaW5lZCBhcyBzYWlkIGJ5IEpMICh0aGlzIGlzIHN0
cmljdGx5IHJlbGF0ZWQgdG8gYSBwcm90ZWN0aW9uIG9iamVjdCkgLSBhbnkgb3RoZXIgc2VtYW50
aWMgb3ZlcmxvYWQgd291bGQgYmUgY29uc2lkZXJlZCBoZXJlIGFzIGEgYmFkIHByb3RvY29sIGRl
c2lnbiBwcmFjdGljZSAtIHRoZXJlZm9yZSBpdCBpcyBtdWNoIGFwcHJvcHJpYXRlIHRvIGNvbnNp
ZGVyIGEgc3BlY2lmaWMgZm9yIGRpc3Rpbmd1aXNoaW5nIGJvdGggdmlydHVhbCBmcm9tIG5vbi12
aXJ0dWFsIEZBcyBhbmQgbWFrZSB1c2Ugb2YgdGhlIHByb3RlY3Rpb24gb2JqZWN0IGFzIGRlZmlu
ZWQgaW4gdGhlIGVuZC10by1lbmQgcmVjb3ZlcnkgZG9jdW1lbnQgYXMgcmVxdWlyZWQgaS5lLiBw
cm90ZWN0ZWQgb3Igbm90IHZpcnR1YWwgRkFzLCBwcm90ZWN0ZWQgb3Igbm90IEZBLUxTUHMsIGV0
Yy4gPC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj48QlI+Jmd0OyAmZ3Q7Mi5J
IGFncmVlIHRoYXQgd2UgbmVlZCBURSBsaW5rIGFkYXB0YXRpb248QlI+Jmd0OyAmZ3Q7Y2FwYWJp
bGl0aWVzIHRvIGJlIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBvdGhlciBURTxCUj4mZ3Q7IGxpbms8
QlI+Jmd0OyAmZ3Q7YXR0cmlidXRlcyBzdWNoIGFzIHN3aXRjaGluZyBjYXBhYmlsaXRpZXMsPEJS
PiZndDsgcHJvdGVjdGlvbjxCUj4mZ3Q7ICZndDtjYXBhYmlsaXRpZXMsIGV0Yy4gSSBzdWdnZXN0
IGFsc28gYWRkaW5nIFRFIGxpbms8QlI+Jmd0OyB0ZXJtaW5hdGlvbjxCUj4mZ3Q7ICZndDtjYXBh
YmlsaXRpZXMgdG8gdGhpcyBsaXN0LCBpLmUuIGRlY291cGxpbmcgb2YgdGhlc2U8QlI+Jmd0OzxC
Uj4mZ3Q7ICZndDtjYXBhYmlsaXRpZXMgZnJvbSBhZGFwdGF0aW9uIGNhcGFiaWxpdGllczo8QlI+
Jmd0OyAmZ3Q7dG8gdGVybWluYXRlIExTUCBpbiBhIHBhcnRpY3VsYXIgbGF5ZXIgYW5kIHRvIGFk
b3B0PEJSPiZndDsgJmd0O2ludG8gaXQgTFNQcyBvZiBvbmUgb3IgbW9yZSBoaWdoZXIgbGF5ZXJz
IGFyZTxCUj4mZ3Q7IHNlcGFyYXRlPEJSPiZndDsgJmd0O3Jlc291cmNlcyBhbmQgY291bGQgYmUg
Y29uc2lkZXJlZCBzZXBhcmF0ZWx5IGluIHRoZTxCUj4mZ3Q7PEJSPiZndDsgJmd0O2ludGVyLWxh
eWVyIHBhdGggY29tcHV0YXRpb25zOzxCUj4mZ3Q7PEJSPiZndDsgSSBhZ3JlZSB0aGF0IG91ciBj
dXJlbnQgdGVybWlub2xvZ3kgbWF5IGJlIGNvbmZ1c2luZzxCUj4mZ3Q7IFdoYXQgd2UgY2FsbCBJ
bnRlcm5hbCBBZGFwYXRhdGlvbiBDYXBhYmlsaXR5PEJSPiZndDsgYWN0dWFsbHkgcmVmZXJzIHRv
IFRlcm1pbmF0aW9uIGNhcGFiaWxpdGllcy48QlI+Jmd0OyBTZWUgdGhlIE1STiByZXF1aXJlbWVu
dCBkcmFmdCAodmVyc2lvbiAwMSkgZm9yIGFuPEJSPiZPc2xhc2g7ZXhhbXBsZS48QlI+PC9GT05U
PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SUImZ3Q7Jmd0OyBNeSBwb2ludCBp
cyB0aGF0IHRlcm1pbmF0aW9uIGFuZCBhZGFwdGF0aW9uPEJSPmNhcGFiaWxpdGllcyBhcmUgc2Vw
YXJhdGUgdGhpbmdzLiBGb3IgaW5zdGFuY2UsIHRoZTxCUj5mYWN0IHRoYXQgYSBsaW5rIGNhbiB0
ZXJtaW5hdGUgbGFtYmRhcyBtZWFucyB0aGUgaXQ8QlI+aGFzIGNlcnRhaW4gbnVtYmVyIG9mIGF2
YWlsYWJsZSB0cmFuc2NlaXZlcnMsIHdoaWxlPEJSPnRoZSBmYWN0IHdoZXRoZXIgdGhlc2UgbGFt
YmRhcyBjYW4gY2FycnkgcGFydGljdWxhcjxCUj50cmlidXRhcnkgc2lnbmFscyBkZXBlbmRzLCBz
YXksIG9uIHdoZXRoZXIgU0lNIGNhcmRzPEJSPm9mIGFwcHJvcHJpYXRlIHR5cGUgY291bGQgYmUg
Y3Jvc3MtY29ubmVjdGVkIHRvIHRoZTxCUj50cmFuc2NlaXZlcnMuIEluIGZhY3QsIGxpbmsgdGVy
bWluYXRpb24gYmFuZHdpZHRoIGlzPEJSPnNoYXJlZCBiZXR3ZWVuIG11bHRpcGxlIGFkYXB0YXRp
b24gZnVuY3Rpb25zLiBUaGU8QlI+Ym90dG9tIGxpbmUgaXMgSSB0aGluayBpdCB3b3VsZCBiZSBn
b29kIGlkZWEgdG88QlI+YWR2ZXJ0aXNlIHRoZW0gc2VwYXJhdGVseS48QlI+PC9GT05UPjxCUj48
Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgJmd0OzMu
RXZlcnl0aGluZyB0aGF0IGlzIHNhaWQgYWJvdXQgcmVnaW9ucywgcmVnaW9uPEJSPiZndDsgJmd0
O2JvdW5kYXJpZXMsIGV0Yy4gaXMgYWxzbyBhcHBsaWNhYmxlIGZvciBsYXllcnM8QlI+Jmd0OyAm
Z3Q7Y29udGFpbmVkIHdpdGhpbiByZWdpb25zLiBJIHN1Z2dlc3QgdG8gZG8gd2hhdCB3ZTxCUj4m
Z3Q7IGhhdmU8QlI+Jmd0OyAmZ3Q7YWxyZWFkeSBkb25lIGluIHRoZSBQQ0UgV0cgZG9jdW1lbnRz
IGFuZDxCUj4mZ3Q7ICZndDtwcmVzZW50YXRpb25zOiByZXBsYWNlIHdvcmQgcmVnaW9uIHdpdGgg
d29yZCBsYXllcjxCUj4mZ3Q7ICZndDtldmVyeXdoZXJlIGFwYXJ0IGZyb20gd2hlcmUgc2lnbmFs
aW5nIHNwZWNpZmljPEJSPiZndDsgYXNwZWN0czxCUj4mZ3Q7ICZndDthcmUgZGlzY3Vzc2VkLjxC
Uj4mZ3Q7PEJSPiZndDsgU2VlIHNlY3Rpb24gMyBvZiB0aGUgcmVxdWlyZW1lbnQgZHJhZnQuPEJS
PiZndDsgQWN0dWFsbHkgd2hhdCB3ZSBkZWZpbmUgZm9yIHJlZ2lvbiBhbHNvIGFwcGxpZXMgdG88
QlI+Jmd0OyBsYXllcnMsIGJ1dCB3ZSBwcmVmZXIgdG88QlI+Jk9zbGFzaDtrZWVwIHRoZSB0ZXJt
IHJlZ2lvbiBoZXJlIGF0IHRoZSB0aW1lIGJlaW5nLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9
Ik1vbm9zcGFjZSxDb3VyaWVyIj5JQiZndDsmZ3Q7IEFuZCBteSBxdWVzdGlvbiBpcyB3aHkgdG8g
ZG8gc28sIGlmIEZBcyBhbmQ8QlI+ZXZlcnl0aGluZyB0byBkbyB3aXRoIFZOVCBpcyBhYm91dCBs
YXllcnMsIGluY2x1ZGluZzxCUj50aG9zZSB0aGF0IHN0YXJ0IGFuZCBzdG9wIGluIHRoZSBtaWRk
bGUgb2YgdGhlIHJlZ2lvbiw8QlI+dGhhdCBpcywgZmFyIGF3YXkgZnJvbSByZWdpb24gYm91bmRh
cmllcz8gRnVydGhlcm1vcmUsPEJSPndoZW4geW91IHNheSB0aGluZ3MgbGlrZSBjcmVhdGluZyBG
QSBpbiB0aGUgbG93ZXI8QlI+cmVnaW9uIHRvIGNhcnJ5IExTUCBmb3IgdGhlIGhpZ2hlciByZWdp
b24sIGl0IGlzIG5vdDxCUj5jbGVhciB3aGF0IGRvIHlvdSBtZWFuIGJ5IHRoYXQgaW4gdGhlIGNh
c2Ugd2hlbiB0aGU8QlI+bG93ZXIgcmVnaW9uIGNvbnRhaW5zIG11bHRpcGxlIGxheWVycy48QlI+
PC9GT05UPjwvUD48UD4mbmJzcDs8L1A+PFA+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj5JZ29yPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZn
dDs8QlI+Jmd0OyBBZ2FpbiwgdGhhbmtzIGEgbG90IGZvciB0aGVzZSBjb21tZW50cyw8QlI+Jmd0
OzxCUj4mZ3Q7IFJlZ2FyZHMsPEJSPiZndDs8QlI+Jmd0OyBKTDxCUj4mZ3Q7PEJSPiZndDsgJmd0
OzxCUj4mZ3Q7ICZndDtUaGFua3MsPEJSPiZndDsgJmd0O0lnb3I8QlI+Jmd0OyAmZ3Q7PEJSPiZn
dDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7LS0tIExFIFJPVVggSmVhbi1Mb3VpcyBS
RC1DT1JFLUxBTjxCUj4mZ3Q7ICZndDsmbHQ7amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29t
LmNvbSZndDsgd3JvdGU6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJS
PiZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBIaSBhbGwsPEJSPiZndDsgJmd0OyZndDs8
QlI+Jmd0OyAmZ3Q7Jmd0OyBIZXJlIGlzIGEgbmV3IGRyYWZ0IGV2YWx1YXRpbmcgY3VycmVudCBH
TVBMUzxCUj4mZ3Q7ICZndDsmZ3Q7IHByb3RvY29scyB3cnQgTVJOPEJSPiZndDsgJmd0OyZndDsg
cmVxdWlyZW1lbnRzLjxCUj4mZ3Q7ICZndDsmZ3Q7IFlvdXIgY29tbWVudHMgb24gdGhpcyBuZXcg
ZHJhZnQgd291bGQgYmUgaGlnaGx5PEJSPiZndDsgJmd0OyZndDsgYXBwcmVjaWF0ZWQuPEJSPiZn
dDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBCZXN0IFJlZ2FyZHMsPEJSPiZndDsgJmd0OyZn
dDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBKTDxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDsg
VG86IGktZC1hbm5vdW5jZSBhdCBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IEkt
RDxCUj4mZ3Q7ICZndDsmZ3Q7IEFDVElPTjpkcmFmdC1sZXJvdXgtY2NhbXAtZ21wbHMtbXJuLWV2
YWwtMDAudHh0PEJSPiZndDsgJmd0OyZndDsgRnJvbTogSW50ZXJuZXQtRHJhZnRzIGF0IGlldGYu
b3JnPEJSPiZndDsgJmd0OyZndDsgRGF0ZTogVHVlLCAxNSBGZWIgMjAwNSAxMDoxNDozOCAtMDUw
MDxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQg
aXMgYXZhaWxhYmxlIGZyb20gdGhlPEJSPiZndDsgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8QlI+
Jmd0OyAmZ3Q7Jmd0OyBkaXJlY3Rvcmllcy48QlI+Jmd0OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsm
Z3Q7PEJSPiZndDsgJmd0OyZndDsgVGl0bGU6IEV2YWx1YXRpb24gb2YgZXhpc3RpbmcgR01QTFMg
UHJvdG9jb2xzPEJSPiZndDsgJmd0OyZndDsgYWdhaW5zdDxCUj4mZ3Q7ICZndDsmZ3Q7IE11bHRp
IFJlZ2lvbiBOZXR3b3JrczxCUj4mZ3Q7ICZndDsmZ3Q7IEF1dGhvcihzKTogSi4gTGUgUm91eCwg
ZXQgYWwuPEJSPiZndDsgJmd0OyZndDsgRmlsZW5hbWU6PEJSPiZndDsgZHJhZnQtbGVyb3V4LWNj
YW1wLWdtcGxzLW1ybi1ldmFsLTAwLnR4dDxCUj4mZ3Q7ICZndDsmZ3Q7IFBhZ2VzOiAxMTxCUj4m
Z3Q7ICZndDsmZ3Q7IERhdGU6IDIwMDUtMi0xNDxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0
OyZndDsgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhbiBldmFsdWF0aW9uIG9mPEJSPiZndDsgR2Vu
ZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2w8QlI+Jmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7TGFi
ZWwgU3dpdGNoaW5nIChHTVBMUykgcHJvdG9jb2xzIGFuZDxCUj4mZ3Q7IG1lY2hhbmlzbXM8QlI+
Jmd0OyAmZ3Q7Jmd0OyBhZ2FpbnN0IHRoZTxCUj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDty
ZXF1aXJlbWVudHMgZm9yIE11bHRpIFJlZ2lvbiBOZXR3b3JrcyAoTVJOKS48QlI+Jmd0OzxCUj4m
Z3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBpZGVu
dGlmaWVzIGFyZWFzPEJSPiZndDsgd2hlcmU8QlI+Jmd0OyAmZ3Q7Jmd0OyBhZGRpdGlvbmFsPEJS
PiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwO3Byb3RvY29sIGV4dGVuc2lvbnMgb3IgcHJvY2Vk
dXJlcyBhcmUgbmVlZGVkPEJSPiZndDsgdG88QlI+Jmd0OyAmZ3Q7Jmd0OyBzYXRpc2Z5IHRoZTxC
Uj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtyZXF1aXJlbWVudHMgb2YgTXVsdGkgUmVnaW9u
IE5ldHdvcmtzLCBhbmQ8QlI+Jmd0OyAmZ3Q7Jmd0OyBwcm92aWRlcyBndWlkZWxpbmVzIGZvcjxC
Uj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtwb3RlbnRpYWwgZXh0ZW5zaW9ucy48QlI+Jmd0
OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsmZ3Q7IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0
IGlzOjxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDs8QlI+Jmd0O2h0dHA6Ly93d3cuaWV0Zi5vcmcv
aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlcm91eC1jY2FtcC1nbXBscy1tcjxCUj4mZ3Q7IG4tZXZh
bC0wMDxCUj4mZ3Q7ICZndDsgLnR4dDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg
Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJS
PiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
QlI+Jmd0OyBDZWxlYnJhdGUgWWFob28hJ3MgMTB0aCBCaXJ0aGRheSE8QlI+Jmd0OyBZYWhvbyEg
TmV0cm9zcGVjdGl2ZTogMTAwIE1vbWVudHMgb2YgdGhlIFdlYjxCUj4mZ3Q7IDxBIEhSRUY9aHR0
cDovL2JpcnRoZGF5LnlhaG9vLmNvbS9uZXRyb3NwZWN0aXZlLz5odHRwOi8vYmlydGhkYXkueWFo
b28uY29tL25ldHJvc3BlY3RpdmUvPC9BPjxCUj4mZ3Q7PEJSPjwvRk9OVD48QlI+PEJSPjxCUj48
QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPEJSPkNlbGVicmF0ZSBZYWhvbyEncyAxMHRoIEJpcnRoZGF5ITxCUj5Z
YWhvbyEgTmV0cm9zcGVjdGl2ZTogMTAwIE1vbWVudHMgb2YgdGhlIFdlYjxCUj48QSBIUkVGPWh0
dHA6Ly9iaXJ0aGRheS55YWhvby5jb20vbmV0cm9zcGVjdGl2ZS8+aHR0cDovL2JpcnRoZGF5Lnlh
aG9vLmNvbS9uZXRyb3NwZWN0aXZlLzwvQT48L0ZPTlQ+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 13:27:43 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=l9Aw2FKYoriDOx2y5pEGlsqaU7LHcHLEnIIxrllwOH1Ld5S1ts7XRFdOF94ta00r5rFsoGtD1ZnoHwbnouwgx6xWa53xuvMnnWwFpDqFxYqq3+weOXKfXtGkUsTKsQ3eh3DZy0UCymEw2UU7NZkzu41kmd/AvDzS+HsQddW2Pdc=  ;
Message-ID: <[e-mail]>
Date: Fri, 4 Mar 2005 05:26:24 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

JL,

Please, see my comments in-line

Igor

--- LE ROUX Jean-Louis RD-CORE-LAN
<[e-mail]> wrote:

> Hi Igor, 
> 
> Thanks for these comments
> 
> Please see inline
> 
> 
> >-----Message d'origine-----
> >De : Igor Bryskin [mailto:[e-mail]] 
> >Envoyé : jeudi 3 mars 2005 20:45
> >À : LE ROUX Jean-Louis RD-CORE-LAN;
> [e-mail]
> >Objet : Re: TR : I-D
> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
> >
> >
> >JL,
> >
> >I have a couple of comments/suggestions.
> >
> >1.	The draft says that currently GMPLS does not
> have a
> >mechanism to provision virtual FAs. I don't think
> this
> >is correct - I believe we could use the same
> mechanism
> >as was suggested in 
> >draft-ietf-ccamp-gmpls-recovery-e2e-signaling
> (section
> >9.3) for signaling of Secondary LSPs
> 
> I wouldn't be so expeditious...
> Actually we could use a similar mechanism but
> definitely not the same.
> Secondary LSP are dedicated to Shared Meshed
> Restoration.
> IMHO this would be bad to use the Protection object
> for soft-FAs. Semantics
> are pretty different...
> 

IB>>Well, are they? They give you a way to signal a
requirement not to commit resources for an LSP until
further notice and also to require their commitment
when it becomes necessary. Why not to allow working
LSP to be signaled as Secondary according to the
mentioned draft? Then it would be possible even to
signal protected virtual FAs, which is not as stupid
as it may sound :=)

> 
> >2.	I agree that we need TE link adaptation
> >capabilities to be advertised along with other TE
> link 
> >attributes such as switching capabilities,
> protection 
> >capabilities, etc. I suggest also adding TE link
> termination 
> >capabilities to this list, i.e. decoupling of these
> 
> >capabilities from adaptation capabilities: 
> >to terminate LSP in a particular layer and to adopt
> >into it LSPs of one or more higher layers are
> separate 
> >resources and could be considered separately in the
> 
> >inter-layer path computations;
> 
> I agree that our curent terminology may be confusing
> What we call Internal Adapatation Capability
> actually refers to Termination capabilities.
> See the MRN requirement draft (version 01) for an
Ø	example.

IB>> My point is that termination and adaptation
capabilities are separate things. For instance, the
fact that a link can terminate lambdas means the it
has certain number of available transceivers, while
the fact whether these lambdas can carry particular
tributary signals depends, say, on whether SIM cards
of appropriate type could be cross-connected to the
transceivers. In fact, link termination bandwidth is
shared between multiple adaptation functions. The
bottom line is I think it would be good idea to
advertise them separately.

> 
> 
> >3.	Everything that is said about regions, region
> >boundaries, etc. is also applicable for layers
> >contained within regions. I suggest to do what we
> have
> >already done in the PCE WG documents and
> >presentations: replace word region with word layer
> >everywhere apart from where signaling specific
> aspects
> >are discussed.
> 
> See section 3 of the requirement draft.
> Actually what we define for region also applies to
> layers, but we prefer to
Ø	keep the term region here at the time being.

IB>> And my question is why to do so, if FAs and
everything to do with VNT is about layers, including
those that start and stop in the middle of the region,
that is, far away from region boundaries? Furthermore,
when you say things like creating FA in the lower
region to carry LSP for the higher region, it is not
clear what do you mean by that in the case when the
lower region contains multiple layers.

Igor

> 
> Again, thanks a lot for these comments,
> 
> Regards,
> 
> JL
> 
> >
> >Thanks,
> >Igor
> >   
> >
> >
> >--- LE ROUX Jean-Louis RD-CORE-LAN 
> ><[e-mail]> wrote:
> >
> >
> >
> >> 
> >> Hi all,
> >> 
> >> Here is a new draft evaluating current GMPLS
> >> protocols wrt MRN
> >> requirements.
> >> Your comments on this new draft would be highly
> >> appreciated.
> >> 
> >> Best Regards,
> >> 
> >> JL
> >> 
> >> To: i-d-announce at ietf.org
> >> Subject: I-D
> >> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
> >> From: Internet-Drafts at ietf.org 
> >> Date: Tue, 15 Feb 2005 10:14:38 -0500 
> >> 
> >> A New Internet-Draft is available from the
> on-line Internet-Drafts
> >> directories.
> >> 
> >> 
> >> 	Title		: Evaluation of existing GMPLS Protocols
> >> against
> >> Multi Region Networks
> >> 	Author(s)	: J. Le Roux, et al.
> >> 	Filename	:
> draft-leroux-ccamp-gmpls-mrn-eval-00.txt
> >> 	Pages		: 11
> >> 	Date		: 2005-2-14
> >> 	
> >> This document provides an evaluation of
> Generalized Multi-Protocol
> >>    Label Switching (GMPLS) protocols and
> mechanisms
> >> against the 
> >>    requirements for Multi Region Networks (MRN). 
>  
> >>    In addition, this document identifies areas
> where
> >> additional 
> >>    protocol extensions or procedures are needed
> to
> >> satisfy the 
> >>    requirements of Multi Region Networks, and
> >> provides guidelines for 
> >>    potential extensions.
> >> 
> >> A URL for this Internet-Draft is:
> >>
>
>http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr
> n-eval-00
> > .txt
> > 
> > 
> > 
> > 
> >
> 
> 
> 
> 	
> 		
> __________________________________ 
> Celebrate Yahoo!'s 10th Birthday! 
> Yahoo! Netrospective: 100 Moments of the Web 
> http://birthday.yahoo.com/netrospective/
>



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 09:36:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
Date: Fri, 4 Mar 2005 10:35:10 +0100
Message-ID: <[e-mail]>
Thread-Topic: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
Thread-Index: AcUgKYHELyJ/qyG8QG2tPdoiCwZ9BAAaRajw
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, <[e-mail]>

Hi Igor,=20

Thanks for these comments

Please see inline


>-----Message d'origine-----
>De : Igor Bryskin [mailto:[e-mail]]=20
>Envoy=E9 : jeudi 3 mars 2005 20:45
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN; [e-mail]
>Objet : Re: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20
>
>
>JL,
>
>I have a couple of comments/suggestions.
>
>1.	The draft says that currently GMPLS does not have a
>mechanism to provision virtual FAs. I don't think this
>is correct - I believe we could use the same mechanism
>as was suggested in=20
>draft-ietf-ccamp-gmpls-recovery-e2e-signaling (section
>9.3) for signaling of Secondary LSPs

I wouldn't be so expeditious...
Actually we could use a similar mechanism but definitely not the same.
Secondary LSP are dedicated to Shared Meshed Restoration.
IMHO this would be bad to use the Protection object for soft-FAs. =
Semantics
are pretty different...


>2.	I agree that we need TE link adaptation
>capabilities to be advertised along with other TE link=20
>attributes such as switching capabilities, protection=20
>capabilities, etc. I suggest also adding TE link termination=20
>capabilities to this list, i.e. decoupling of these=20
>capabilities from adaptation capabilities:=20
>to terminate LSP in a particular layer and to adopt
>into it LSPs of one or more higher layers are separate=20
>resources and could be considered separately in the=20
>inter-layer path computations;

I agree that our curent terminology may be confusing
What we call Internal Adapatation Capability actually refers to =
Termination capabilities.
See the MRN requirement draft (version 01) for an example.


>3.	Everything that is said about regions, region
>boundaries, etc. is also applicable for layers
>contained within regions. I suggest to do what we have
>already done in the PCE WG documents and
>presentations: replace word region with word layer
>everywhere apart from where signaling specific aspects
>are discussed.

See section 3 of the requirement draft.
Actually what we define for region also applies to layers, but we prefer =
to
keep the term region here at the time being.

Again, thanks a lot for these comments,

Regards,

JL

>
>Thanks,
>Igor
>  =20
>
>
>--- LE ROUX Jean-Louis RD-CORE-LAN=20
><[e-mail]> wrote:
>
>
>
>>=20
>> Hi all,
>>=20
>> Here is a new draft evaluating current GMPLS
>> protocols wrt MRN
>> requirements.
>> Your comments on this new draft would be highly
>> appreciated.
>>=20
>> Best Regards,
>>=20
>> JL
>>=20
>> To: i-d-announce at ietf.org
>> Subject: I-D
>> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20
>> From: Internet-Drafts at ietf.org=20
>> Date: Tue, 15 Feb 2005 10:14:38 -0500=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>=20
>>=20
>> 	Title		: Evaluation of existing GMPLS Protocols
>> against
>> Multi Region Networks
>> 	Author(s)	: J. Le Roux, et al.
>> 	Filename	: draft-leroux-ccamp-gmpls-mrn-eval-00.txt
>> 	Pages		: 11
>> 	Date		: 2005-2-14
>> =09
>> This document provides an evaluation of Generalized Multi-Protocol
>>    Label Switching (GMPLS) protocols and mechanisms
>> against the=20
>>    requirements for Multi Region Networks (MRN).  =20
>>    In addition, this document identifies areas where
>> additional=20
>>    protocol extensions or procedures are needed to
>> satisfy the=20
>>    requirements of Multi Region Networks, and
>> provides guidelines for=20
>>    potential extensions.
>>=20
>> A URL for this Internet-Draft is:
>>
>http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr
n-eval-00
> .txt
>=20
>=20
>=20
>=20
>



=09
	=09
__________________________________=20
Celebrate Yahoo!'s 10th Birthday!=20
Yahoo! Netrospective: 100 Moments of the Web=20
http://birthday.yahoo.com/netrospective/



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Mar 2005 02:23:25 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Mar 2005 03:21:18 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>,  [e-mail]
Subject: Re: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

igor - i let to jl the opportunit to respond in much more in details but 
here below some hints:

> I have a couple of comments/suggestions.
 >
> 1.	The draft says that currently GMPLS does not have a
> mechanism to provision virtual FAs. I don’t think this
> is correct – I believe we could use the same mechanism
> as was suggested in
> draft-ietf-ccamp-gmpls-recovery-e2e-signaling (section
> 9.3) for signaling of Secondary LSPs

there is no mechanism to setup/delete "virtual FAs" as part of GMPLS 
signaling protocol today the secondary LSP concept, even if the latter 
may look similar to the virtual FA concept - note: this is explicitly 
mentioned as part of the recovery document

however, the advertisement of the corr. TE link must be identical to 
what currently exist for fully provisioned FAs

> 2.	I agree that we need TE link adaptation
> capabilities to be advertised along with other TE link
> attributes such as switching capabilities, protection
> capabilities, etc. I suggest also adding TE link
> termination capabilities to this list, i.e. decoupling
> of these capabilities from adaptation capabilities: 
> to terminate LSP in a particular layer and to adopt
> into it LSPs of one or more higher layers are separate
> resources and could be considered separately in the
> inter-layer path computations;

would you let us know what is missing in terms of termination 
capabilities - before we expand on this ?

> 3.	Everything that is said about regions, region
> boundaries, etc. is also applicable for layers
> contained within regions. I suggest to do what we have
> already done in the PCE WG documents and
> presentations: replace word region with word layer
> everywhere apart from where signaling specific aspects
> are discussed.

i suggest you take a look at section 3.1 of
<http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-reqs-01.txt>
it may help in understand the region vs layer concepts

> Thanks,
> Igor
>    
> 
> 
> --- LE ROUX Jean-Louis RD-CORE-LAN
> <[e-mail]> wrote:
> 
> 
> 
> 
>>Hi all,
>>
>>Here is a new draft evaluating current GMPLS
>>protocols wrt MRN
>>requirements.
>>Your comments on this new draft would be highly
>>appreciated.
>>
>>Best Regards,
>>
>>JL
>>
>>To: i-d-announce at ietf.org 
>>Subject: I-D
>>ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
>>From: Internet-Drafts at ietf.org 
>>Date: Tue, 15 Feb 2005 10:14:38 -0500 
>>
>>A New Internet-Draft is available from the on-line
>>Internet-Drafts
>>directories.
>>
>>
>>	Title		: Evaluation of existing GMPLS Protocols
>>against
>>Multi Region Networks
>>	Author(s)	: J. Le Roux, et al.
>>	Filename	: draft-leroux-ccamp-gmpls-mrn-eval-00.txt
>>	Pages		: 11
>>	Date		: 2005-2-14
>>	
>>This document provides an evaluation of Generalized
>>Multi-Protocol 
>>   Label Switching (GMPLS) protocols and mechanisms
>>against the 
>>   requirements for Multi Region Networks (MRN).   
>>   In addition, this document identifies areas where
>>additional 
>>   protocol extensions or procedures are needed to
>>satisfy the 
>>   requirements of Multi Region Networks, and
>>provides guidelines for 
>>   potential extensions.
>>
>>A URL for this Internet-Draft is:
>>
> 
> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-00
> 
>>.txt
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 	
> 		
> __________________________________ 
> Celebrate Yahoo!'s 10th Birthday! 
> Yahoo! Netrospective: 100 Moments of the Web 
> http://birthday.yahoo.com/netrospective/
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 03 Mar 2005 19:46:40 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=whz4O0VjfNchE7E6GgZw3683yEuAYRgyM6ER/RcFpsO51lUigqpmkiq7/02/XZ8LFI1HshXWRKNkeGqdmWVVpcaLWFdgqXTz5Z5d3GuTNX2ASqFVfSyB3xI4d3h2mFHQCTK0F1RTIIJjvVbaiw8lvgnOQHAkxifhnhRMqwiqKgI=  ;
Message-ID: <[e-mail]>
Date: Thu, 3 Mar 2005 11:45:03 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

JL,

I have a couple of comments/suggestions.

1.	The draft says that currently GMPLS does not have a
mechanism to provision virtual FAs. I don’t think this
is correct – I believe we could use the same mechanism
as was suggested in
draft-ietf-ccamp-gmpls-recovery-e2e-signaling (section
9.3) for signaling of Secondary LSPs
2.	I agree that we need TE link adaptation
capabilities to be advertised along with other TE link
attributes such as switching capabilities, protection
capabilities, etc. I suggest also adding TE link
termination capabilities to this list, i.e. decoupling
of these capabilities from adaptation capabilities: 
to terminate LSP in a particular layer and to adopt
into it LSPs of one or more higher layers are separate
resources and could be considered separately in the
inter-layer path computations;
3.	Everything that is said about regions, region
boundaries, etc. is also applicable for layers
contained within regions. I suggest to do what we have
already done in the PCE WG documents and
presentations: replace word region with word layer
everywhere apart from where signaling specific aspects
are discussed.

Thanks,
Igor
   


--- LE ROUX Jean-Louis RD-CORE-LAN
<[e-mail]> wrote:



> 
> Hi all,
> 
> Here is a new draft evaluating current GMPLS
> protocols wrt MRN
> requirements.
> Your comments on this new draft would be highly
> appreciated.
> 
> Best Regards,
> 
> JL
> 
> To: i-d-announce at ietf.org 
> Subject: I-D
> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
> From: Internet-Drafts at ietf.org 
> Date: Tue, 15 Feb 2005 10:14:38 -0500 
> 
> A New Internet-Draft is available from the on-line
> Internet-Drafts
> directories.
> 
> 
> 	Title		: Evaluation of existing GMPLS Protocols
> against
> Multi Region Networks
> 	Author(s)	: J. Le Roux, et al.
> 	Filename	: draft-leroux-ccamp-gmpls-mrn-eval-00.txt
> 	Pages		: 11
> 	Date		: 2005-2-14
> 	
> This document provides an evaluation of Generalized
> Multi-Protocol 
>    Label Switching (GMPLS) protocols and mechanisms
> against the 
>    requirements for Multi Region Networks (MRN).   
>    In addition, this document identifies areas where
> additional 
>    protocol extensions or procedures are needed to
> satisfy the 
>    requirements of Multi Region Networks, and
> provides guidelines for 
>    potential extensions.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-00
> .txt
> 
> 
> 
> 
>



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/



Envelope-to: [e-mail]
Delivery-date: Wed, 02 Mar 2005 21:53:44 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject:  TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
Date: Wed, 2 Mar 2005 22:51:40 +0100
Message-ID: <[e-mail]>
Thread-Topic:  TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
Thread-Index: AcUfcYD///LTML9cQJ2kXP1XFm9NVwAACgAg
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>

Hi all,

Here is a new draft evaluating current GMPLS protocols wrt MRN
requirements.
Your comments on this new draft would be highly appreciated.

Best Regards,

JL

To: i-d-announce at ietf.org=20
Subject: I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20
From: Internet-Drafts at ietf.org=20
Date: Tue, 15 Feb 2005 10:14:38 -0500=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Evaluation of existing GMPLS Protocols against
Multi Region Networks
	Author(s)	: J. Le Roux, et al.
	Filename	: draft-leroux-ccamp-gmpls-mrn-eval-00.txt
	Pages		: 11
	Date		: 2005-2-14
=09
This document provides an evaluation of Generalized Multi-Protocol=20
   Label Switching (GMPLS) protocols and mechanisms against the=20
   requirements for Multi Region Networks (MRN).  =20
   In addition, this document identifies areas where additional=20
   protocol extensions or procedures are needed to satisfy the=20
   requirements of Multi Region Networks, and provides guidelines for=20
   potential extensions.

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






Envelope-to: [e-mail]
Delivery-date: Tue, 01 Mar 2005 20:09:13 +0000
Message-Id: <[e-mail]>
From: "Zafar Ali" <[e-mail]>
To: "'Richard Rabbat'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Draft status updated on alternate CCAMP web page
Date: Tue, 1 Mar 2005 15:08:28 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcUaovD8B+NmdnguQaCdiCl+oOdUdQD9lc3w

Hi Richard, 

Re: the ID (draft-shiomoto-ccamp-gmpls-addressing-00), I did find it quite
useful and IMO we should pursue this further in CCAMP. 

Having said that, I would like to point that there are a number of ID-es
that are currently NOT in Adrian's list and I think this has to do with his
comment in the original email (quoting Adrian): "I have yet to update the
section that covers personal drafts related to CCAMP." Adrian, please
correct me/ add/ del.  

Thanks

Regards... Zafar 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Richard Rabbat
> Sent: Thursday, February 24, 2005 1:52 PM
> To: 'Adrian Farrel'; [e-mail]
> Subject: RE: Draft status updated on alternate CCAMP web page
> 
> Adrian,
> Can you add
> http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls
> -addressing-00
> .txt
> to your draft tracker?
> 
> We sent out email about it and have received feedback 
> off-list. We're planning on discussing this draft in 
> Minneapolis and would love to have more on-list discussions. 
> As you can see from the list of contributors, there is 
> enormous interest in this draft and we hope it serves as a 
> basis for thoughtful discussions.
> Best,
> Richard, Rajiv and Kohei.
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > Sent: Monday, February 21, 2005 10:35 AM
> > To: Adrian Farrel; [e-mail]
> > Subject: Re: Draft status updated on alternate CCAMP web page
> > 
> > 
> > So, I can't type.
> > Want to make something of it?
> > http://www.olddog.co.uk/ccamp-drafts.htm
> > 
> > (Thanks Jean-Louis)
> > 
> > Adrian
> > 
> > ----- Original Message -----
> > From: "Adrian Farrel" <[e-mail]>
> > To: <[e-mail]>
> > Sent: Monday, February 21, 2005 12:32 PM
> > Subject: Draft status updated on alternate CCAMP web page
> > 
> > 
> > > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to
> > indicate the
> > > current status of all CCAMP drafts. I have yet to update 
> the section
> > that
> > > covers personal drafts related to CCAMP.
> > >
> > > Adrian
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 01 Mar 2005 19:51:02 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "'Sadler, Jonathan B.'" <[e-mail]>, "'Ong, Lyndon'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, "'Greg Bernstein'" <[e-mail]>
Subject: RE: question about RFC 3946
Date: Tue, 1 Mar 2005 11:46:02 -0800
Message-ID: <005901c51e97$537cf400$473ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Dimitri,
Thanks for the answer.
Now, STS-3c and VC-4 share the same signal type. 
Should they still be formed differently?
Richard.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 
> Sent: Tuesday, March 01, 2005 10:58 AM
> To: Richard Rabbat
> Cc: [e-mail]; 
> [e-mail]; 'Sadler, Jonathan B.'; 'Ong, 
> Lyndon'; 'Adrian Farrel'; 'Richard Rabbat'; 
> [e-mail]; 'Greg Bernstein'
> Subject: Re: question about RFC 3946
> 
> 
> 
> richard:
> 
> "greater" does not mean "strictly greater" it means "greater or equal"
> 
> So, what values of NCC and RCC should one use for STS-3c/VC-4?
> 
> for STS-3c:
>         An STS-3c SPE signal is formed by the application of RCC with
>         value 1 (standard contiguous concatenation), NCC with value 1,
>         NVC with value 0, MT with value 1 and T with value 0 
> to an STS-
>         3c SPE Elementary Signal.
> 
> for VC-4:
>         A VC-4 signal is formed by the application of RCC 
> with value 0,
>         NCC with value 0, NVC with value 0, MT with value 1 and T with
>         value 0 to a VC-4 Elementary Signal.
> 
> do not know if this clarifies -
> 
> hint: Note 2 refers to transparent STS-N/STM-N signals 
> (signal type 7->12)
> 
> 
> 
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Tue, 01 Mar 2005 18:59:45 +0000
To: "Richard Rabbat" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Sadler, Jonathan B.'" <[e-mail]>, "'Ong, Lyndon'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, "'Richard Rabbat'" <[e-mail]>, <[e-mail]>, "'Greg Bernstein'" <[e-mail]>
From: [e-mail]
Subject: Re: question about RFC 3946
MIME-Version: 1.0
Date: Tue, 1 Mar 2005 19:57:32 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

richard:

"greater" does not mean "strictly greater" it means "greater or equal"

So, what values of NCC and RCC should one use for STS-3c/VC-4?

for STS-3c:
        An STS-3c SPE signal is formed by the application of RCC with
        value 1 (standard contiguous concatenation), NCC with value 1,
        NVC with value 0, MT with value 1 and T with value 0 to an STS-
        3c SPE Elementary Signal.

for VC-4:
        A VC-4 signal is formed by the application of RCC with value 0,
        NCC with value 0, NVC with value 0, MT with value 1 and T with
        value 0 to a VC-4 Elementary Signal.

do not know if this clarifies -

hint: Note 2 refers to transparent STS-N/STM-N signals (signal type 7->12)








Envelope-to: [e-mail]
Delivery-date: Tue, 01 Mar 2005 18:46:06 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "'Sadler, Jonathan B.'" <[e-mail]>
Cc: "'Ong, Lyndon'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, "'Richard Rabbat'" <[e-mail]>, <[e-mail]>, "'Greg Bernstein'" <[e-mail]>
Subject: question about RFC 3946
Date: Tue, 1 Mar 2005 10:36:16 -0800
Message-ID: <004701c51e8d$91e6a100$473ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01C51E4A.83C36100"

This is a multi-part message in MIME format.

------=_NextPart_000_0048_01C51E4A.83C36100
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Dimitri, Eric, Jonathan,=20
I have a question about RFC 3946.
=20
I'm trying to figure out how to understand text about setting NCC and =
RCC=20
values for STS-3c and VC-4. Here's the context:
=20
Quoting from RFC 3946:
=20
   Note 1: when requesting a SONET STS-Nc SPE with N=3D3*X, the
      Elementary Signal to use must always be an STS-3c_SPE signal type
      and the value of NCC must always be equal to X.  This allows also
      facilitating the interworking between SONET and SDH.  In
      particular, it means that the contiguous concatenation of three
      STS-1 SPEs can not be requested because according to this
      specification, this type of signal must be coded using the STS-3c
      SPE signal type.
=20
Note 1 implies that for SONET STS-3c SPE, NCC =3D1
=20
   Note 2: when requesting a transparent STS-N/STM-N signal
      limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc,
      the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set
      to 1.
=20
Note 2 seems to imply that for STS-3c_SPE/VC-4-1c, RCC =3D NCC =3D 1
=20
Then later on:
=20
   The NCC value must be consistent with the type of contiguous
   concatenation being requested in the RCC field.  In particular, this
   field is irrelevant if no contiguous concatenation is requested (RCC
   =3D 0), in that case it must be set to zero when sent, and should be
   ignored when received.  A RCC value different from 0 must imply a
   number of contiguous components greater than 1.
=20
Given that RCC must be different from 0, the last sentence literally=20
says that an RCC value of 1 (thus different from 0) must imply that NCC =
> 1.
=20
Going on to the examples of Annex 1:
   1.   A VC-4 signal is formed by the application of RCC with value 0,
        NCC with value 0, NVC with value 0, MT with value 1 and T with
        value 0 to a VC-4 Elementary Signal.
...
   8.   An STS-3c SPE signal is formed by the application of RCC with
        value 1 (standard contiguous concatenation), NCC with value 1,
        NVC with value 0, MT with value 1 and T with value 0 to an STS-
        3c SPE Elementary Signal.
=20
So, what values of NCC and RCC should one use for STS-3c/VC-4?
--
Option 1-a:
Set NCC =3D RCC =3D 1 for STS-3c and VC-4. Example 1 of the annex is not =
the
RFC text and should not be followed.
=20
Option 1-b:
Set NCC =3D RCC =3D 0 for STS-3c and VC-4. Example 8 of the annex is not =
the
RFC text and should not be followed.
=20
Option 2:
Set NCC =3D RCC =3D 0 for VC-4 and NCC =3D RCC =3D 1 for STS-3c AND =
convert these
values when moving between SDH and SONET domains
=20
Option 3:
Find some NCC-RCC combination that satisfies:
"  A RCC value different from 0 must imply a
   number of contiguous components greater than 1."
=20
I sent email to Greg Bernstein, and he is of the opinion that options =
1-a or
1-b are best.
If you also agree, we may need an errata along the lines:
=20
Those would be the suggested changes.
=20
FROM:
   The NCC value must be consistent with the type of contiguous
   concatenation being requested in the RCC field.  In particular, this
   field is irrelevant if no contiguous concatenation is requested (RCC
   =3D 0), in that case it must be set to zero when sent, and should be
   ignored when received.  A RCC value different from 0 must imply a
   number of contiguous components greater than 1.
TO:
   The NCC value must be consistent with the type of contiguous
   concatenation being requested in the RCC field.  In particular, this
   field is irrelevant if no contiguous concatenation is requested (RCC
   =3D 0), in that case it must be set to zero when sent, and should be
   ignored when received.  A RCC value different from 0 must imply a
   number of contiguous components greater than or equal to 1.
                                                ^^^^^^^^^^^^<- for =
option
1.a
FROM:
   1.   A VC-4 signal is formed by the application of RCC with value 0,
        NCC with value 0, NVC with value 0, MT with value 1 and T with
        value 0 to a VC-4 Elementary Signal.
=20
   8.   An STS-3c SPE signal is formed by the application of RCC with
        value 1 (standard contiguous concatenation), NCC with value 1,
        NVC with value 0, MT with value 1 and T with value 0 to an STS-
        3c SPE Elementary Signal.
TO:
   1.   A VC-4 signal and an STS-3c SPE signal are formed by the
        application of RCC with value i, NCC with value i, NVC with
        value 0, MT with value 1 and T with value 0 to a VC-4 Elementary
        Signal and an STS-3c SPE Elementary Signal respectively.
        (RR: To replace i with 0 if we choose option 1a and 1 for option =
1b)
=20
   8.   An STS-3c SPE signal is formed as shown in example 1. RFC 3946's
        example 8 is now deprecated.
        In order to support earlier versions of the standard, a node
        should accept RFC 3946-compliant values of NCC =3D RCC =3D !i =
when
        receiving them until all known implementations have updated
        their code to the Errata.=20
        (RR: make sure we accept the other value)
Looking forward to your answer.
Richard.
=20
=20
=20
=20

=20

------=_NextPart_000_0048_01C51E4A.83C36100
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.2604" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D197390123-22022005>Hi Dimitri,=20
Eric, Jonathan, </SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D197390123-22022005>I have a=20
question about&nbsp;RFC 3946.</SPAN></FONT></DIV>
<DIV><FONT size=3D+0><SPAN =
class=3D197390123-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2>I'm trying to figure out =
how to=20
understand text about setting NCC and RCC<SPAN=20
class=3D197390123-22022005>&nbsp;</SPAN><BR>values for STS-3c<SPAN=20
class=3D197390123-22022005> and </SPAN>VC-4<SPAN =
class=3D197390123-22022005>. Here's=20
the context:</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Quoting from RFC =
3946:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; Note 1: when =
requesting a=20
SONET STS-Nc SPE with N=3D3*X, the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Elementary=20
Signal to use must always be an STS-3c_SPE signal=20
type<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the value of NCC must always =
be equal=20
to X.&nbsp; This allows also<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
facilitating the=20
interworking between SONET and SDH.&nbsp; =
In<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
particular, it means that the contiguous concatenation of=20
three<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STS-1 SPEs can not be requested =
because=20
according to this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specification, this =
type of=20
signal must be coded using the STS-3c<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPE=20
signal type.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Note 1 implies that for SONET =
STS-3c SPE,=20
NCC =3D1</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; Note 2: when =
requesting a=20
transparent STS-N/STM-N signal<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; limited =
to a=20
single contiguously concatenated=20
STS-Nc_SPE/VC-4-Nc,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the signal type =
must be=20
STS-N/STM-N, RCC with flag 1 and NCC =
set<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to=20
1.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Note 2 seems to imply that for=20
STS-3c_SPE/VC-4-1c, RCC =3D NCC =3D 1</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Then later on:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; The NCC value must =
be=20
consistent with the type of contiguous<BR>&nbsp;&nbsp; concatenation =
being=20
requested in the RCC field.&nbsp; In particular, this<BR>&nbsp;&nbsp; =
field is=20
irrelevant if no contiguous concatenation is requested =
(RCC<BR>&nbsp;&nbsp; =3D=20
0), in that case it must be set to zero when sent, and should =
be<BR>&nbsp;&nbsp;=20
ignored when received.&nbsp; A RCC value different from 0 must imply=20
a<BR>&nbsp;&nbsp; number of contiguous components greater than =
1.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN =
class=3D197390123-22022005>Given=20
that</SPAN>&nbsp;RCC must be different from 0<SPAN =
class=3D197390123-22022005>,=20
</SPAN>the last sentence literally </FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>says that an RCC value of 1 =
(thus<SPAN=20
class=3D197390123-22022005> </SPAN>different<SPAN =
class=3D197390123-22022005>=20
</SPAN>from 0) must imply that NCC &gt; 1.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Going on to the examples of =
Annex=20
1:<BR>&nbsp;&nbsp; 1.&nbsp;&nbsp; A VC-4 signal is formed by the =
application of=20
RCC with value 0,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NCC with =
value=20
0, NVC with value 0, MT with value 1 and T=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value 0 to a VC-4 =
Elementary=20
Signal.<BR>...<BR>&nbsp;&nbsp; 8.&nbsp;&nbsp; An STS-3c SPE signal is =
formed by=20
the application of RCC =
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value=20
1 (standard contiguous concatenation), NCC with value=20
1,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NVC with value 0, MT =
with value=20
1 and T with value 0 to an =
STS-<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3c=20
SPE Elementary Signal.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>So, what values of NCC and RCC =
should one=20
use for STS-3c/VC-4?</FONT></DIV>
<DIV><SPAN class=3D197390123-22022005><FONT face=3D"Courier New"=20
size=3D2>--</FONT></SPAN></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Option 1<SPAN=20
class=3D197390123-22022005>-a</SPAN>:<BR>Set NCC =3D RCC =3D 1 for =
STS-3c and VC-4.=20
Example 1 of the annex is not the<BR>RFC<SPAN =
class=3D197390123-22022005>=20
</SPAN>text and should not be followed.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Option 1<SPAN=20
class=3D197390123-22022005>-b</SPAN>:<BR>Set NCC =3D RCC =3D&nbsp;<SPAN=20
class=3D197390123-22022005>0</SPAN> for STS-3c and VC-4. =
Example&nbsp;<SPAN=20
class=3D197390123-22022005>8</SPAN> of the annex is not the<BR>RFC<SPAN=20
class=3D197390123-22022005> </SPAN>text and should not be =
followed.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Option 2:<BR>Set NCC =3D RCC =
=3D 0 for VC-4 and=20
NCC =3D RCC =3D 1 for STS-3c AND convert these<BR>values when moving =
between SDH and=20
SONET domains</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Option 3:<BR>Find some NCC-RCC =
combination=20
that satisfies:<BR>"&nbsp; A RCC value different from 0 must imply=20
a<BR>&nbsp;&nbsp; number of contiguous components greater than =
1."</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D197390123-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D197390123-22022005>I sent email=20
to Greg Bernstein, and he is of the opinion that options 1-a or 1-b are=20
best.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D197390123-22022005>If you also=20
agree, we may need an errata along the lines:</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D197390123-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D197390123-22022005>Those would=20
be the suggested changes.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D197390123-22022005>FROM:<BR>&nbsp;&nbsp; The NCC value must be =
consistent=20
with the type of contiguous<BR>&nbsp;&nbsp; concatenation being =
requested in the=20
RCC field.&nbsp; In particular, this<BR>&nbsp;&nbsp; field is irrelevant =
if no=20
contiguous concatenation is requested (RCC<BR>&nbsp;&nbsp; =3D 0), in =
that case it=20
must be set to zero when sent, and should be<BR>&nbsp;&nbsp; ignored =
when=20
received.&nbsp; A RCC value different from 0 must imply =
a<BR>&nbsp;&nbsp; number=20
of contiguous components greater than 1.<BR>TO:<BR>&nbsp;&nbsp; The NCC =
value=20
must be consistent with the type of contiguous<BR>&nbsp;&nbsp; =
concatenation=20
being requested in the RCC field.&nbsp; In particular, =
this<BR>&nbsp;&nbsp;=20
field is irrelevant if no contiguous concatenation is requested=20
(RCC<BR>&nbsp;&nbsp; =3D 0), in that case it must be set to zero when =
sent, and=20
should be<BR>&nbsp;&nbsp; ignored when received.&nbsp; A RCC value =
different=20
from 0 must imply a<BR>&nbsp;&nbsp; number of contiguous components =
greater than=20
or equal to=20
1.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^^^^^^^^^^^^&lt;- for option 1.a<BR>FROM:<BR>&nbsp;&nbsp; 1.&nbsp;&nbsp; =
A VC-4=20
signal is formed by the application of RCC with value=20
0,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NCC with value 0, NVC =
with=20
value 0, MT with value 1 and T=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value 0 to a VC-4 =
Elementary=20
Signal.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D197390123-22022005>&nbsp;&nbsp;=20
8.&nbsp;&nbsp; An STS-3c SPE signal is formed by the application of RCC=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value 1 (standard =
contiguous=20
concatenation), NCC with value =
1,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
NVC with value 0, MT with value 1 and T with value 0 to an=20
STS-<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3c SPE Elementary=20
Signal.<BR>TO:<BR>&nbsp;&nbsp; 1.&nbsp;&nbsp; A VC-4 signal and an =
STS-3c SPE=20
signal are formed by the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
application of RCC with value i, NCC with value i, NVC=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value 0, MT with =
value 1 and=20
T with value 0 to a VC-4=20
Elementary<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Signal and an =
STS-3c=20
SPE Elementary Signal respectively.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D197390123-22022005>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;(RR: To=20
replace i&nbsp;with 0 if we choose option 1a and 1 for option=20
1b)</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D197390123-22022005>&nbsp;&nbsp;=20
8.&nbsp;&nbsp; An STS-3c SPE signal is formed as shown in example 1. RFC =

3946's<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; example 8 is now=20
deprecated.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In order to =
support=20
earlier versions of the standard, a=20
node<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; should accept RFC=20
3946-compliant values of NCC =3D RCC =3D&nbsp;!i=20
when<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; receiving them until =
all=20
known implementations have =
updated<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
their code to the Errata. </SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D197390123-22022005>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(RR: make=20
sure we accept the other value)</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D197390123-22022005>Looking=20
forward to your answer.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D197390123-22022005>Richard.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D197390123-22022005><FONT=20
face=3DArial></FONT>&nbsp;</DIV></SPAN></FONT>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D197390123-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D197390123-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT =
face=3DArial></FONT>&nbsp;</DIV>
<DIV><BR></DIV></FONT>
<DIV><FONT face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0048_01C51E4A.83C36100--