Subject: iPOP2005 Call for Presentation and Exhibition
From: "K. Miyazaki" <[email-masked]>
To: [email-masked]
Date: Mon, 01 Nov 2004 11:23:49 +0900

CALL FOR PRESENTATION AND EXHIBITION
****************************************************************
The International Conference on IP + Optical Network (iPOP 2005)
****************************************************************

GMPLS Interoperability Public Demonstration,
Exhibition and Conference$B!!(B
Tokyo,$B!!(BJapan,
February 21-22, 2005

http://www.pilab.org/ipop2005/

Sponsored by PIL(Photonic Internet Lab),
ISOCORE, and PIF(Photonic Internet Forum)

-----------------------------------------------------------------------
The international conference on IP + Optical network (iPOP 2005) will
be held at the Tokyo Fashion Town (TFT) Hall in Tokyo, Japan, from
February 21 to February 22, 2005.
The conference is intended to share among the industry and the academia
communities, the knowledge, new findings, and experience on the
state-of-the art of IP and optical networking technologies.
It features a public demonstration of GMPLS interoperability showcase
by world-wide vendors, including Protection/Restoration and Multi-layer
interworking, novel GMPLS product exhibitions, and technical sessions.
The opportunity to participate in the showcase is open to all vendors.
-----------------------------------------------------------------------

=============================================
CALL FOR GMPLS INTEROPERABILITY PARTICIPATORS
=============================================

iPOP 2005 is soliciting participation proposals for its GMPLS
interoperability showcase, in addition to PIL and ISOCORE member companies.
The topics of the interoperability will include the following:

* GMPLS Signaling and Routing
* GMPLS-based Protection and Restoration
* Multi-region/layer Interworking, such as Optical and Packet Networks

Please contact

mailto:[email-masked]

for additional information.

=====================
CALL FOR PRESENTATION
=====================
The Technical Program Committee for iPOP 2005 is soliciting presentation
proposals for this conference. Protocol design, experiment, theory,
implementation, and operational experiences are solicited.
The topics of the conference will include the following, but will not be
limited to:

* GMPLS, ASON, OUNI
* Protection & restoration
* Multi-region network
* Inter-area/Inter-AS network
* Routing wavelength assignment
* Impairment/management in all optical network
* Traffic engineering
* Network management, OA&M
* Software/Hardware implementation, interoperability
* Testbed, field trial
* Optical burst switching
* Optical service, such as L1VPN, Bandwidth on Demand, and Photonic Grid
* Application with high-bandwidth demand

If you wish to propose a particular topic for consideration,
please send a one page summary (less than 400 words),
including speaker's name, affiliation, and contact information
to the Technical Program Committee at:

mailto:[email-masked].

See

http://www.pilab.org/ipop2005/

for more details.

Important Dates+++++++++++++++++++++++++++++++++++++++++++++++
$B!!(BNovember 15, 2004 --- Deadline of submission (extended)
$B!!(BDecember 15, 2004 --- Notification of acceptance
$B!!(BJanuary 8, 2005 --- Final camera ready copy
$B!!(BJanuary 31, 2005 --- Deadline of conference pre-registration
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

============================
CALL FOR EXHIBITOR PROPOSALS
============================

You are invited to exhibit at the international conference
on IP + Optical network (iPOP 2005), February 21-22, 2005,
at the Tokyo Fashion Town (TFT) Hall in Tokyo, Japan.

The conference is intended to share among the industry and
the academia communities, the knowledge, new findings, and
experience on the state-of-the-art of
"IP and Optical Networking technologies".
Within this theme we intend to demonstrate GMPLS network equipment
(IP routers, SONET/SDH XCs, Optical/Photonic XCs), GMPLS protocol
test equipment, GMPLS network operation support tools,
Optical Switches, and other related issues. Additionally, we will
provide a showcase for GMPLS interoperability.

iPOP 2005 anticipates a draw of over 200 attendees, made up of
network operators, service providers, and equipment vendors.

Join us and other industry leaders in the IP + Optical network
technologies and leading source of industry information for GMPLS
technologies.
The early bird deadline for exhibitors is November 1, 2004.
Please contact

mailto:[email-masked]

for additional exhibitor prospectus information.

Exhibit space is limited and will be committed on a first-come
first-serve basis.

LOCATION++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The Tokyo Fashion Town (TFT) Hall is located in Tokyo$B!G(Bs newly developed
sea-front area known as Odaiba. It is easily accessible by public
transport from downtown Tokyo and Narita International Airport.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

**************************
iPOP2005 COMMITTEE MEMBERS
**************************

General Chairs:Tomonori Aoyama, University of Tokyo,
and Bijan Jabbari, ISOCORE.

Technical Program Committee
Chairs: Tadanobu Okada, NTT, Japan,
and (TBD).
Vice Chairs: Kohei Shiomoto, NTT, Japan,
and Akira Chugo, Fujitsu, Japan.
Secretary: Keiji Miyazaki, Fujitsu, Japan.

Organization Committee
Chair: Naoaki Yamanaka, Keio University, Japan.
Secretary: Akira Misawa, NTT, Japan.
Treasurer: Shinya Nakamura, NEC, Japan.
Local Arrangement: Hiroyuki Sakamoto, Oki Electric, Japan.
Publication: Shoichiro Seno, Mitsubishi Electric, Japan.

Exhibition Committee
Chair: Satoru Okamoto, NTT, Japan.
Vice Chairs: Shoji Fukutomi, Furukawa Electric, Japan,
and Hideaki Tsushima, Hitachi Communication Technology, Japan.
Secretary: Kazumasa Morita, Furukawa Electric, Japan,
and Naomichi Nonaka, Hitachi, Japan.

***********
SPONSORSHIP
***********

iPOP 2005 is sponsored by PIL and ISOCORE,
and technically co-sponsored by PIF.

------------------------------------------------------------------
PIL
(Photonic Internet Lab, http://www.pilab.org),
founded by 6 vendors and 1 service provider in 2002,
is promoting R&D on next-generation photonic network
control protocols based on photonic technologies
for managed networks.
------------------------------------------------------------------
ISOCORE
(Isocore Internetworking Lab, http://www.isocore.com)
is the leading technology validation lab in the next
generation IP and optical networking.
Its goal is to advance internetworking through technology
validation and product verification and to promote development
and rapid deployment of innovative networking technologies.
------------------------------------------------------------------
PIF
(Photonic Internet Forum, http://www.scat.or.jp/photonic/english/)
is a non-profit organization contributing to the progress of
info-communication technology to realize all optical
ultra-high-speed networks.
------------------------------------------------------------------

Delivery-date: Sun, 31 Oct 2004 21:25:52 +0000
From: "Adrian Farrel" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: L1VPN mailing list archives
Date: Sun, 31 Oct 2004 21:24:28 +0000

Hi Vishal, 

Thanks for flagging this. I raised the problem with the Secretariat some six 
weeks ago, but I didn't follow up. I have raised a new trouble ticket. 

Adrian 

> Hi Adrian, 
> 
> The link to the PCE archives on the PCE signup page does
> not seem to work. Are there no archives of the PCE
> mailing list? 
> 
> -Vishal

Delivery-date: Sun, 31 Oct 2004 19:49:09 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Cc: "'Richard Rabbat'" <[email-masked]>, "'Vishal Sharma'" <[email-masked]>, "'Takeo Hamada'" <[email-masked]>
Subject: Carrier survey update on shared mesh restoration
Date: Sun, 31 Oct 2004 11:48:04 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C4BF3F.7E528A80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
Based on the feedback from the CCAMP WG chairs during last IETF, we have
updated the carrier survey to include all the individual carrier =
responses.
We've also added the couple of missing collated answers.
Information about the draft is below.
=20
We are currently looking for more carriers to answer the survey and have =
put
up the survey on a web page for easy access. We've also added more =
questions
based on feedback from IETF San Diego and on the mailing list.  The page =
is
at: http://perth.mit.edu/~richard/carrier_survey/survey.txt
=20
We're also looking for more feedback on what questions people have that =
they
would want to see captured in the survey.
Thanks a lot,
Richard.
--
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Carrier Survey Results on GMPLS-based Shared-Mesh Transport
Restoration Strategies
Author(s) : R. Rabbat, et al.
Filename : draft-rabbat-ccamp-carrier-survey-01.txt
Pages : 36
Date : 2004-10-25

Optical transport networks operated using a GMPLS-based control plane=20
   enable today=12s network operators to offer valuable new services. =
With=20
   the completion of a number of GMPLS signaling and routing standards=20
   and the availability of products implementing them, providers are now =

   looking at ways to enable additional features, such as shared-mesh=20
   restoration. These can be key to efficient network operation while=20
   providing strict performance guarantees. In that context, several=20
   areas of work still need to be addressed within the CCAMP WG of the=20
   IETF to develop interoperable, standards-based solutions that=20
   carriers can embrace.=20
   =20
   Towards that end, this document presents the results of a serious=20
   attempt to systematically gather and collate carrier inputs on=20
   strategies for shared-mesh restoration and the associated issues. The =

   survey results are presented in aggregate form to provide an overview
   of carrier thinking, while retaining specific carrier response=20
   confidentiality. The goal is to highlight areas of carrier concerns,=20
   and identify specific work items to focus on and facilitate further=20
   discussion on them. This is to enable the CCAMP WG to pursue ongoing=20
   and further work in this area that is focused towards addressing the=20
   identified carrier requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.=
txt

------=_NextPart_000_000D_01C4BF3F.7E528A80
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.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial size=3D2>Based =
on the=20
feedback from the CCAMP WG chairs during last IETF, we have updated the =
carrier=20
survey to include all the individual carrier responses. We've also added =
the=20
couple of missing collated answers.</FONT></SPAN></DIV>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial =
size=3D2>Information about=20
the draft is below.</FONT></SPAN></DIV>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial size=3D2>We are =
currently=20
looking for more carriers to answer the survey and have put up the =
survey on a=20
web page for easy access. We've also added more questions based on =
feedback from=20
IETF San Diego and on the mailing list.&nbsp; The page is at: <A=20
href=3D"http://perth.mit.edu/~richard/carrier_survey/survey.txt">http://p=
erth.mit.edu/~richard/carrier_survey/survey.txt</A></FONT></SPAN></DIV>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial size=3D2>We're =
also looking=20
for more feedback on what questions people have that they would want to =
see=20
captured in the survey.</FONT></SPAN></DIV>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial size=3D2>Thanks =
a=20
lot,</FONT></SPAN></DIV>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20
size=3D2>Richard.</FONT></SPAN></DIV>
<DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20
size=3D2>--</FONT></SPAN></DIV>
<DIV><SPAN class=3D340363419-31102004>A New Internet-Draft is available =
from the=20
on-line Internet-Drafts directories.<BR>Title		: Carrier Survey Results =
on=20
GMPLS-based Shared-Mesh Transport Restoration Strategies<BR>	Author(s)	: =
R.=20
Rabbat, et al.<BR>	Filename	:=20
draft-rabbat-ccamp-carrier-survey-01.txt<BR>	Pages		: 36<BR>	Date		:=20
2004-10-25<BR>	<BR>Optical transport networks operated using a =
GMPLS-based=20
control plane <BR>&nbsp;&nbsp; enable today=12s network operators to =
offer=20
valuable new services. With <BR>&nbsp;&nbsp; the completion of a number =
of GMPLS=20
signaling and routing standards <BR>&nbsp;&nbsp; and the availability of =

products implementing them, providers are now <BR>&nbsp;&nbsp; looking =
at ways=20
to enable additional features, such as shared-mesh <BR>&nbsp;&nbsp; =
restoration.=20
These can be key to efficient network operation while <BR>&nbsp;&nbsp; =
providing=20
strict performance guarantees. In that context, several <BR>&nbsp;&nbsp; =
areas=20
of work still need to be addressed within the CCAMP WG of the =
<BR>&nbsp;&nbsp;=20
IETF to develop interoperable, standards-based solutions that =
<BR>&nbsp;&nbsp;=20
carriers can embrace. <BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; Towards =
that end,=20
this document presents the results of a serious <BR>&nbsp;&nbsp; attempt =
to=20
systematically gather and collate carrier inputs on <BR>&nbsp;&nbsp; =
strategies=20
for shared-mesh restoration and the associated issues. The =
<BR>&nbsp;&nbsp;=20
survey results are presented in aggregate form to provide an=20
overview<BR>&nbsp;&nbsp; of carrier thinking, while retaining specific =
carrier=20
response <BR>&nbsp;&nbsp; confidentiality. The goal is to highlight =
areas of=20
carrier concerns, <BR>&nbsp;&nbsp; and identify specific work items to =
focus on=20
and facilitate further <BR>&nbsp;&nbsp; discussion on them. This is to =
enable=20
the CCAMP WG to pursue ongoing <BR>&nbsp;&nbsp; and further work in this =
area=20
that is focused towards addressing the <BR>&nbsp;&nbsp; identified =
carrier=20
requirements.<BR><BR>A URL for this Internet-Draft is:<BR><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-su=
rvey-01.txt">http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carri=
er-survey-01.txt</A><BR></SPAN></DIV></BODY></HTML>

------=_NextPart_000_000D_01C4BF3F.7E528A80--

Delivery-date: Sun, 31 Oct 2004 19:06:13 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Your input: Use of PCE in Inter-domain
Date: Sun, 31 Oct 2004 11:04:55 -0800

Hi Adrian,

The link to the PCE archives on the PCE signup page does
not seem to work. Are there no archives of the PCE
mailing list?

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, October 19, 2004 12:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Your input: Use of PCE in Inter-domain
> 
> 
> Folks, 
> 
> The chairs and ADs would like your input on 
> http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.
> txt in the 
> context of our inter-domain traffic engineering work. 
> 
> This draft documents an architecture for Path Computation 
> Elements (PCE) and 
> is currently being discussed on the pce mailing list 
> (https://www1.ietf.org/mailman/listinfo/pce) 
> 
> What we would like CCAMP to do is give us your opinion on whether PCE is 
> addresing an inter-domain problem that needs to be addressed, and if so 
> whether the architecture provides an acceptable way to resolve 
> the problem. 
> 
> Answers to the mailing list in advance of the meeting in 
> Washington would be 
> appreciated. 
> 
> Thanks,
> Adrian and Kireeti 
> 
>  
> 
> 
> 

Delivery-date: Sun, 31 Oct 2004 16:52:29 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "ricciato" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Ugo Monaco" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Alessio D'Achille" <[email-masked]>
Subject: RE: update of JSA for inter-domain diverse path & some simulation results
Date: Sun, 31 Oct 2004 08:51:16 -0800

Hello All,

Just to add to what Fabio said ...

First, the draft is now officially on-line, and is available
at
http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region-path
-setup-01.txt

Indeed, the simulation results are helping to provide more insight
into the working of these schemes, and in developing better
intuition about them.

We would encourage CCAMPers to take a look at the revised draft,
and provide their inputs.

We intend to discuss the revised draft and the simulation
results at DC, and look forward to your feedback.

-Vishal

> -----Original Message-----
> From: ricciato [mailto:[email-masked]]
> Sent: Wednesday, October 27, 2004 3:52 AM
> To: [email-masked]
> Cc: [email-masked]; Ugo Monaco; Daniele Alì; Alessio
> D'Achille; Vishal Sharma
> Subject: update of JSA for inter-domain diverse path & some simulation
> results
>
>
> Hi all,
>
> please note that we have have updated the draft on the JSA  method for
> computing diverse paths in inter-domain.
> We have also run some initial simulations on realistic topologies,
> comparing the 1) JSA approach (with ARO) with 2) the method based on
> RRO+XRO (called ISPA in the draft), and 3) the global optimum based on
> complete information.
> We considered a few realistic topologies (details in the draft)
> In summary the results show that :
>
> - if a pair of diverse path exist, the JSA/ARO almost always find them
> at the first shot (it failed in 2-3 cases over thousands of
> simulation run)
> - there are some topologies in which the ISPA/XRO is trapped at the
> first shot (and should therefore revert to cranckback), it happens
> approx. in 10% of cases
> - when a pair of path is found by all the three methods, there is no
> substantial difference in the overall cost between JSA/ARO and optimum
> (we used min-hop metric), with a slight worse performance of ISPA/XRO
>
> Please note that the performance of PCE should be the same as the global
> optimum (since it is computed assuming full global information and
> centralized computation).
>
> Based on these preliminary results, we believe that the JSA/ARO approach
> should not be considered a competitor of PCE (which is provenly "the
> optimum"), but rather a secondary solution which achieves the same
> performances of the optimal method  "almost surely" in the practical
> cases  (still, it is possible to draw cases in which it fails, while
> PCE/optimum finds his way, but these cases seem to be not found in the
> realistic topologies we have investigated).
> On the other hand the JSA/ARO  involves much  less information and
> signaling overhead...
>
>
> In addition to the IETF site, the current version of the draft can be
> found at the following url. It includes quick  description of the
> simualtions and summary of preliminary results. It would be nice to have
> a short slot for presenting them at Washington DC, perhaps ....
>
> We wellcome very much any feedback from the community that helps us in
> refining the simulation scenario (new topologies, suggestions for
> setting the scenario, etc.). Please do not hesitate to send you comment
> (particularly the criticisms, which are the most helpful ones for
> improving our work ...)
>
> ciao
> fabio
>
> PS
> the url for the draft is:
>
> http://www.metanoia-inc.com/Publications/draft-dachille-diverse-in
ter-region-path-setup-01.txt

Delivery-date: Sun, 31 Oct 2004 11:34:09 +0000
Date: Sun, 31 Oct 2004 20:31:46 +0900
From: Kohei Shiomoto <[email-masked]>
Organization: NTT
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Basic agenda structure for Washington DC

Hi all

I would like to ask a time slot at the upcoming CCAMP meeting for the 
MPLS/GMPLS migration draft:

"IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration" <draft-oki-ccamp-gmpls-ip-interworking-04.txt>

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-04.txt

Comments and discussion are highly appreciated.
Best regards,
---
Kohei Shiomoto

Adrian Farrel wrote:

>Hi,
>
>Since San Diego, we have managed to move on quite well with our existing milestones,
>commitments and drafts.
>
>So, the basic agenda structure for Washington DC is as follows:
>
>Admin and WG status
>ASON Solutions
>Protection solutions
>Inter-domain
>    Basic
>    MRN
>    Diverse path
>New work
>   MPLS/GMPLS migration
>   L1VPN
>   Others
>Rechartering
>
>If you would like a slot, please ask and we will attempt to construct an agenda.
>Editors/authors or WG drafts may expect to be asked by the chairs to present on the
>status, issues and next steps for their drafts.
>
>Thanks,
>Adrian
>
>
>
>  
>

-- 
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402    Fax +81 422 59 4549

Delivery-date: Sat, 30 Oct 2004 17:41:25 +0000
To: [email-masked]
From: [email-masked]
Date: Tue, 26 Oct 2004 15:57:45 -0400
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-segment-recovery-01.txt
Reply-To: [email-masked]

--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		: GMPLS Based Segment Recovery
	Author(s)	: L. Berger, et al.
	Filename	: draft-ietf-ccamp-gmpls-segment-recovery-01.txt
	Pages		: 24
	Date		: 2004-10-26
	
This document describes protocol specific procedures for GMPLS
   (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
   ReserVation Protocol - Traffic Engineering) signaling extensions to
   support LSP segment protection and restoration.  These extensions are
   intended to be compliment and be consistent with the Extensions for
   End-to-End GMPLS-based Recovery.  Implications and interactions with
   Fast Reroute are also addressed.  This document also updates the
   handling of Notify_Request objects specified in [RFC3473].

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

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

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

--NextPart--

Delivery-date: Fri, 29 Oct 2004 20:06:33 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, Bill Fenner <[email-masked]>, [email-masked], [email-masked], WG Milestone Tracker <[email-masked]>
Subject: RE: Lliaison to ITU-T SG15/Q14 About GMPLS MIB Modules
Date: Fri, 29 Oct 2004 16:05:19 -0400

Dear Mr. Farrel,

Thank you for the Liaison Statement (LS) on GMPLS MIB Modules. We appreciate the opportunity to provide input to the GMPLS MIB work. Q14/15 will address the LS in its coming meetings and provide a response by 15th December 2004.

Regards,
Kam Lam, Q14/15 Rapporteur

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Friday, October 29, 2004 3:08 PM
> To: Lam, Hing-Kam (Kam)
> Cc: Adrian Farrel; 'Kireeti Kompella'; Bill Fenner; [email-masked];
> [email-masked]; WG Milestone Tracker
> Subject: Lliaison to ITU-T SG15/Q14 About GMPLS MIB Modules
> 
> 
> To:           Mr. Kam Lam, Rapporteur for Question 14 of 
> ITU-T Study Group 15.
> From:         Adrian Farrel and Kireeti Kompella
>               Co-chairs of the CCAMP Working Group of the IETF
> Cc:           Alex Zinin and Bill Fenner, Routing Area 
> Directors of the IETF
> For:          Action
> Deadline:     15th December 2004
> Subject:      GMPLS MIB Modules
> 
> Dear Mr. Lam,
> 
> The IETF's CCAMP Working Group has been working to develop 
> MIB modules to facilitate the
> configuration and monitoring of GMPLS LSRs and Traffic 
> Engineered Tunnels (LSPs).
> 
> The work on these MIB modules is nearing completion and, 
> considering that you Question has
> a task to work on management issues for the ASON 
> architecture, we would appreciate your
> input to the drafts at this stage.
> 
> A timely response will allow us to include consideration of 
> any points that you raise in
> the last and probably final revision of the drafts.
> 
> For reference, the objects modeled in these MIB modules may 
> be considered as connection
> segments (LSPs) and connection controllers (LSRs) in the ASON 
> architecture. There is no
> intention to model calls or call controllers in this version 
> of the drafts, although such
> function might be added in a later set of MIB modules.
> 
> Sincerely,
> Kireeti Kompella & Adrian Farrel, CCAMP WG chairs
> 
> Att/
> draft-ietf-ccamp-gmpls-tc-mib-06.txt
> draft-ietf-ccamp-gmpls-lsr-mib-06.txt
> draft-ietf-ccamp-gmpls-te-mib-06.txt
> 

Delivery-date: Fri, 29 Oct 2004 19:17:04 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Bill Fenner" <[email-masked]>, <[email-masked]>, <[email-masked]>, "WG Milestone Tracker" <[email-masked]>
Subject: Lliaison to ITU-T SG15/Q14 About GMPLS MIB Modules
Date: Fri, 29 Oct 2004 20:07:51 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0E00_01C4BDF2.F8398130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To:           Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study Group 15.
From:         Adrian Farrel and Kireeti Kompella
              Co-chairs of the CCAMP Working Group of the IETF
Cc:           Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
For:          Action
Deadline:     15th December 2004
Subject:      GMPLS MIB Modules

Dear Mr. Lam,

The IETF's CCAMP Working Group has been working to develop MIB modules to facilitate the
configuration and monitoring of GMPLS LSRs and Traffic Engineered Tunnels (LSPs).

The work on these MIB modules is nearing completion and, considering that you Question has
a task to work on management issues for the ASON architecture, we would appreciate your
input to the drafts at this stage.

A timely response will allow us to include consideration of any points that you raise in
the last and probably final revision of the drafts.

For reference, the objects modeled in these MIB modules may be considered as connection
segments (LSPs) and connection controllers (LSRs) in the ASON architecture. There is no
intention to model calls or call controllers in this version of the drafts, although such
function might be added in a later set of MIB modules.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Att/
draft-ietf-ccamp-gmpls-tc-mib-06.txt
draft-ietf-ccamp-gmpls-lsr-mib-06.txt
draft-ietf-ccamp-gmpls-te-mib-06.txt

------=_NextPart_000_0E00_01C4BDF2.F8398130
Content-Type: text/plain;
	name="draft-ietf-ccamp-gmpls-tc-mib-06.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ccamp-gmpls-tc-mib-06.txt"

Network Working Group                              Thomas D. Nadeau, Ed.
Internet Draft                                       Cisco Systems, Inc.
Proposed Status: Standards Track
Expires: April 2005                                   Adrian Farrel, Ed.
                                                      Old Dog Consulting

                                                            October 2004

     Definitions of Textual Conventions for Generalized Multiprotocol
                   Label Switching (GMPLS) Management

                  draft-ietf-ccamp-gmpls-tc-mib-06.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

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

Abstract

   This document defines a Management Information Base (MIB) module
   which contains Textual Conventions to represent commonly used
   Generalized Multiprotocol Label Switching (GMPLS) management
   information. The intent is that these TEXTUAL CONVENTIONS (TCs) will
   be imported and used in GMPLS related MIB modules that would
   otherwise define their own representations.

Nadeau and Farrel (Editors)                                     [Page 1]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-tc-mib-06.txt     October 2004

Table of Contents

   1. Introduction ................................... 2
   2. The SNMP Management Framework .................. 2
   3. GMPLS Textual Conventions MIB Definitions ...... 3
   4. Security Considerations ........................ 5
   5. IANA Considerations ............................ 5
   6. References ..................................... 5
   6.1. Normative References ......................... 5
   6.2. Informational References ..................... 6
   7. Acknowledgments ................................ 7
   8. Authors' Addresses ............................. 7
   9. Intellectual Property Notice ................... 9
   10. Full Copyright Statement ..................... 10

1. Introduction

   This document defines a MIB module which contains Textual Conventions
   for Generalized Multiprotocol Label Switching (GMPLS) networks.
   These Textual Conventions should be imported by MIB modules which
   manage GMPLS networks.

   This MIB module supplements the MIB module in [RFC3811] that defines
   Textual Conventions for Multiprotocol Label Switching (MPLS)
   Management. [RFC3811] may continue to be used without this MIB module
   in networks that support only MPLS.

   Comments should be made directly to the CCAMP mailing list at
   [email-masked].

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

   For an introduction to the concepts of GMPLS, see [GMPLSArch].

2. The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

Nadeau and Farrel (Editors)                                     [Page 2]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-tc-mib-06.txt     October 2004

3. GMPLS Textual Conventions MIB Definitions

   GMPLS-TC-STD-MIB DEFINITIONS ::=3D BEGIN

   IMPORTS
     MODULE-IDENTITY
       FROM SNMPv2-SMI                                    -- [RFC2578]
     TEXTUAL-CONVENTION
       FROM SNMPv2-TC                                     -- [RFC2579]
     mplsStdMIB
       FROM MPLS-TC-STD-MIB                               -- [RFC3811]
   ;

   gmplsTCStdMIB MODULE-IDENTITY
     LAST-UPDATED
       "200410080001Z" -- 8 October 2004 00:00:01 GMT
     ORGANIZATION "Common Control And Measurement Plane (CCAMP)
                   Working Group"
     CONTACT-INFO
       "       Thomas D. Nadeau
               Cisco Systems, Inc.
        Email: [email-masked]

               Adrian Farrel
               Old Dog Consulting
        Email: [email-masked]

        Comments about this document should be emailed direct to the
        CCAMP working group mailing list at [email-masked]"
     DESCRIPTION
       "Copyright (C) The Internet Society (2004). The
        initial version of this MIB module was published
        in RFC xxxx. For full legal notices see the RFC
        itself or see:
              http://www.ietf.org/copyrights/ianamib.html

        This MIB module defines TEXTUAL-CONVENTIONs for concepts used in
        Generalized Multiprotocol Label Switching (GMPLS) networks."

   -- Revision history.
     REVISION
       "200410080001Z" -- 8 October 2004 00:00:01 GMT
     DESCRIPTION
       "Initial version published as part of RFC XXXX."
     -- Please see the IANA Considerations Section.
     -- This MIB module is contained in the OID sub-tree
     -- rooted at mplsStdMIB.
     -- The requested mplsStdMIB subId is xx, i.e.
   ::=3D { mplsStdMIB xx }

Nadeau and Farrel (Editors)                                     [Page 3]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-tc-mib-06.txt     October 2004

   -- Textual Conventions (sorted alphabetically).

   GmplsFreeformLabel ::=3D TEXTUAL-CONVENTION
     STATUS      current
     DESCRIPTION
       "This value represents a freeform generalized MPLS Label. This
        can be used to represent label types which are not standard
        in the drafts. It may also be used by systems that do not
        wish to represent the labels using the specific label types."
     REFERENCE
       "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
        Functional Description, RFC 3471."
     SYNTAX OCTET STRING (SIZE (0..64))

   GmplsGeneralizedLabelTypes ::=3D TEXTUAL-CONVENTION
     STATUS      current
     DESCRIPTION
       "Determines the interpretation that should be applied to a
        label."
     REFERENCE
       "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
        Functional Description, RFC 3471."
     SYNTAX INTEGER {
       gmplsMplsLabel(1),
       gmplsPortWavelengthLabel(2),
       gmplsFreeformGeneralizedLabel(3),
       gmplsSonetLabel(4),
       gmplsSdhLabel(5),
       gmplsWavebandLabel(6)
     }

   GmplsSegmentDirection ::=3D TEXTUAL-CONVENTION
     STATUS      current
     DESCRIPTION
       "The direction of data flow on an LSP segment with respect to the
        head of the LSP.

        Where an LSP is signaled using a conventional signaling
        protocol, the 'head' of the LSP is the source of the signaling
        (also known as the ingress) and the 'tail' is the destination
        (also known as the egress). For unidirectional LSPs, this
        usually matches the direction of flow of data.

        For manually configured unidirectional LSPs the direction of the
        LSP segment matches the direction of flow of data. For manually
        configured bidirecitonal LSPs, an arbitrary decision must be
        made about which LER is the 'head'."

Nadeau and Farrel (Editors)                                     [Page 4]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-tc-mib-06.txt     October 2004

     SYNTAX  INTEGER {
       forward(1),
       reverse(2)
     }

   END

4. Security Considerations

   This module does not define any management objects.  Instead, it
   defines a set of textual conventions which may be used by other MPLS
   MIB modules to define management objects.

   Meaningful security considerations can only be written in the MIB
   modules that define management objects.  Therefore, this document has
   no impact on the security of the Internet.

5. IANA Considerations

   IANA is requested to root MIB objects in this MIB module
   under the mplsStdMIB subtree by assigning an OID to
   gmplsTCStdMIB.

   In the future, GMPLS related standards track MIB modules should be
   rooted under the mplsStdMIB (sic) subtree. IANA has been requested
   to manage that namespace.  New assignments can only be made via a
   Standards Action as specified in [RFC2434].

   The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB.

6. References

6.1. Normative References

   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]        McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                    Case, J., Rose, M. and S. Waldbusser, "Structure of
                    Management Information Version 2 (SMIv2)", STD 58,
                    RFC 2578, April 1999.

   [RFC2579]        McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                    Case, J., Rose, M. and S. Waldbusser, "Textual
                    Conventions for SMIv2", STD 58, RFC 2579, April
                    1999.

   [RFC2580]        McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                    Case, J., Rose, M. and S. Waldbusser, "Conformance
                    Statements for SMIv2", STD 58, RFC 2580, April 1999.

Nadeau and Farrel (Editors)                                     [Page 5]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-tc-mib-06.txt     October 2004

   [RFC3471]        Berger, L. (Editor), "Generalized Multi-Protocol
                    Label Switching (GMPLS) Signaling Functional
                    Description", RFC 3471, January 2003.

6.2. Informational References

   [RFC2434]        Narten, T. and H. Alvestrand, "Guidelines for
                    Writing an IANA Considerations Section in RFCs",
                    BCP: 26, RFC 2434, October 1998.

   [RFC3031]        Rosen, E., Viswananthan, A., and R. Callon,
                    Multiprotocol Label Switching Architecture",
                    RFC 3031, January 2001.

   [RFC3209]        Awduche, D., Berger, L., Gan, D., Li, T.,
                    Srinivasan, V., Swallow, G., "RSVP-TE: Extensions to
                    RSVP for LSP Tunnels", RFC 3209, December 2001.

   [RFC3212]        Jamoussi, B., (editor), et. al.  "Constraint-Based
                    LSP Setup using LDP", RFC 3212, January 2002.

   [RFC3410]        Case, J., Mundy, R., Partain, D. and B. Stewart,
                    "Introduction and Applicability Statements for
                    Internet-Standard Management Framework", RFC 3410,
                    December 2002.

   [RFC3411]        Harrington, D., Presuhn, R., and B. Wijnen, "An
                    Architecture for Describing Simple Network
                    Management Protocol (SNMP) Management Frameworks",
                    STD 62, RFC 3411, December 2002.

   [RFC3472]        Ashwood-Smith, P., Berger, L. (Editors),
                    "Generalized MPLS Signaling - CR-LDP Extensions",
                    RFC 3472, January 2003.

   [RFC3473]        Berger, L. (Editor), "Generalized MPLS Signaling -
                    RSVP-TE Extensions", RFC 3473 January 2003.

   [RFC3811]        Nadeau, T. and J. Cucchiara, "Definition of Textual
                    Conventions and for Multiprotocol Label Switching
                    (MPLS) Management", RFC 3811, June 2004.

   [GMPLSSonetSDH]  Mannie, E., Papadimitriou, D. (Editors),
                    "Generalized Multi-Protocol Label Switching
                    Extensions for SONET and SDH Control", Internet
                    Draft <draft-ietf-ccamp-gmpls-sonet-sdh-08.txt>,
                    February 2003, work in progress.

Nadeau and Farrel (Editors)                                     [Page 6]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-tc-mib-06.txt     October 2004

   [GMPLSLSRMIB]    Nadeau, T., Farrel, A. (Editors) "Generalized
                    Multiprotocol Label Switching (GMPLS) Label
                    Switching Router (LSR) Management Information Base",
                    draft-ietf-ccamp-gmpls-lsr-mib-06.txt, October 2004,
                    work in progress.

   [GMPLSTEMIB]     Nadeau, T., Farrel, A. (Editors) "Generalized
                    Multiprotocol Label Switching (GMPLS) Traffic
                    Engineering Management Information Base",
                    draft-ietf-ccamp-gmpls-te-mib-06.txt, October 2004,
                    work in progress.

   [GMPLSArch]      Mannie, E. (Editor), "Generalized Multiprotocol
                    Label Switching (GMPLS) Architecture", Internet
                    Draft <draft-many-gmpls-architecture-07.txt>, May
                    2003, work in progress.

7. Acknowledgements

   This draft is the work of the five authors listed in the next
   section.

   Special thanks to Joan Cucchiara for her help with compilation
   issues.

8. Authors' Addresses

   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Apollo Drive
   Chelmsford, MA 01824
   Phone: +1-978-244-3051
   Email: [email-masked]

   Cheenu Srinivasan
   Bloomberg L.P.
   499 Park Ave.,
   New York, NY 10022
   Phone: +1-212-893-3682
   Email: [email-masked]

   Adrian Farrel
   Old Dog Consulting
   Phone: +44 1978 860944
   Email: [email-masked]

Nadeau and Farrel (Editors)                                     [Page 7]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-tc-mib-06.txt     October 2004

   Tim Hall
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex
   EN2 6BQ, UK
   Phone: +44 20 8366 1177
   Email: [email-masked]

   Ed Harrison
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex
   EN2 6BQ, UK
   Phone: +44 20 8366 1177
   Email: [email-masked]

9. Intellectual Property Considerations

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

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

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

10. Full Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

Nadeau and Farrel (Editors)                                     [Page 8]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-tc-mib-06.txt     October 2004

   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Nadeau and Farrel (Editors)                                     [Page 9]
=0C

------=_NextPart_000_0E00_01C4BDF2.F8398130
Content-Type: text/plain;
	name="draft-ietf-ccamp-gmpls-lsr-mib-06.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ccamp-gmpls-lsr-mib-06.txt"

Network Working Group                              Thomas D. Nadeau, Ed.
Internet Draft                                       Cisco Systems, Inc.
Proposed Status: Standards Track
Expires: April 2005                                   Adrian Farrel, Ed.
                                                      Old Dog Consulting

                                                            October 2004

         Generalized Multiprotocol Label Switching (GMPLS)
      Label Switching Router (LSR) Management Information Base

              draft-ietf-ccamp-gmpls-lsr-mib-06.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

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

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects to configure and/or
   monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
   Switching Router (LSR).

Nadeau and Farrel (Editors)                                     [Page 1]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

Table of Contents
   1. Introduction ..................................... 2
   1.1. Migration Strategy ....................... ..... 2
   2. Terminology ...................................... 3
   3. The SNMP Management Framework .................... 3
   4. Outline .......................................... 3
   4.1. Summary of the GMPLS LSR MIB Module ............ 4
   4.1.1 Summary of the GMPLS LSR MIB Module ........... 4
   4.1.2 Summary of the GMPLS Label MIB Module ......... 5
   5. Bidirectional LSPs ............................... 5
   6. Example of LSP Setup ............................. 5
   7. GMPLS Label Switching Router MIB Definitions ..... 9
   8. GMPLS Label MIB Definitions ..................... 19
   9. Security Considerations ......................... 32
   10. Acknowledgments ................................ 34
   11. IANA Considerations ............................ 34
   11.1. IANA Considerations for GMPLS-LSR-STD-MIB .... 34
   11.2. IANA Considerations FOR GMPLS-LABEL-STD-MIB .. 34
   12. References ..................................... 34
   12.1. Normative References ......................... 34
   12.2. Informational References ..................... 36
   13. Authors' Addresses ............................. 37
   14. Full Copyright Statement ....................... 37
   15. Intellectual Property Notice ................... 38

1. Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for modeling a
   Generalized Multiprotocol Label Switching (GMPLS) [GMPLSArch] Label
   Switching Router (LSR).

   Comments should be made directly to the CCAMP mailing list at
   [email-masked].

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

1.1. Migration Strategy

   There are two MIB modules in this document. The GMPLS LSR MIB module
   extends the LSR MIB module defined for use with MPLS [RFC3813]. The
   only changes made are additions for support of GMPLS or changes that
   are necessary to support the increased complexity of a GMPLS system.
   The GMPLS Label MIB module may be referenced using a row pointer from
   objects within the LSR MIB module.

Nadeau and Farrel (Editors)                                     [Page 2]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   The companion document modeling and managing GMPLS based traffic
   engineering [GMPLSTEMIB] extends the MPLS TE MIB module [RFC3812]
   with the same intentions.

   Textual conventions and OBJECT-IDENTIFIERS are defined in
   [GMPLSTCMIB] which extends the set of textual conventions originally
   defined in [RFC3811].

2. Terminology

   This document uses terminology from the document describing the MPLS
   architecture [RFC3031] and the GMPLS architecture [GMPLSArch].

   A label switched path (LSP) is modeled as a connection consisting of
   one or more incoming segments (in-segments) and/or one or more
   outgoing segments (out-segments) at an LSR. The association or
   interconnection of the in-segments and out-segments is accomplished
   by using a cross-connect. We use the terminology "connection" and
   "LSP" interchangeably where the meaning is clear from the context.

      in-segment     This is analogous to a GMPLS label on an interface.
      out-segment    This is analogous to a GMPLS label on an interface.
      cross-connect  This describes the conceptual connection between a
                     set of in-segments and out-segments.
                     Note that either set may be empty; for example, a
                     cross-connect may connect only out-segments
                     together with no in-segments in the case where an
                     LSP is originating on an LSR.

3.  The SNMP Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

4. Outline

   Configuring statically provisioned GMPLS LSPs through an LSR involves
   the following steps:

   -  Configuring an interface using the MPLS LSR MIB module.

Nadeau and Farrel (Editors)                                     [Page 3]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   -  Enabling GMPLS on GMPLS capable interfaces using this MIB module.

   -  Configuring in-segments and out-segments using the MPLS LSR MIB
      module.

   -  Configuring GMPLS extensions to the in-segments and out-segments
      using this MIB module.

   -  Setting up the cross-connect table in the MPLS LSR MIB module to
      associate segments and/or to indicate connection origination and
      termination.

   -  Optionally setting up labels in the label table in this MIB module
      if the textual convention MplsLabel is not capable of holding the
      required label (for example, if the label requires more than 32
      bits to encode it), or if the operator wishes to disambiguate
      GMPLS label types.

   -  Optionally specifying label stack actions in the MPLS LSR MIB
      module.

   -  Optionally specifying segment traffic parameters in the MPLS LSR
      MIB module.

4.1 MIB Modules

   There are two MIB modules defined in this document.

   The GMPLS LSR MIB module contains tables that extend tables defined
   in the MPLS LSR MIB module. This MIB module is used in conjunction
   with the MPLS LSR MIB module in systems that support GMPLS.

   The GMPLS Label MIB module contains objects for managing GMPLS labels
   when they cannot be represented using the textual conventions of the
   MPLS TC MIB module, or when more detailed access to the sub-fields of
   the labels is required.

4.1.1 Summary of the GMPLS LSR MIB Module

   The MIB tables in this MIB module are as follows.

   -  The interface configuration table (gmplsInterfaceTable), which
      extends mplsInterfaceTable to enable the GMPLS protocol on MPLS-
      capable interfaces.

   -  The in-segment (gmplsInSegmentTable) and out-segment
      (gmplsOutSegmentTable) tables extend mplsInSegmentTable and
      mplsOutSegmentTable to configuring GMPLS-specific parameters for
      LSP segments at an LSR.

   These tables are described in the subsequent sections.

Nadeau and Farrel (Editors)                                     [Page 4]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

4.1.2 Summary of the GMPLS Label MIB Module

   There is one MIB table in this MIB module as follows.

   -  The gmplsLabelTable allows Generalized
      Labels to be defined and managed in a central location.
      Generalized Labels can be of variable length and have distinct
      bit-by-bit interpretations according to the use that is made of
      them.

   These tables are described in the subsequent sections.

5. Bidirectional LSPs

   This MIB module supports bidirectional LSPs as required for GMPLS.
   A single value of mplsXCIndex is shared by all of the segments for
   the entire bidirectional LSP. This facilitates a simple reference
   from [RFC3812] and [GMPLSTEMIB], and makes fate-sharing more obvious.

   It is, however, important that the direction of segments is
   understood to avoid connecting all in-segments to all out-segments.
   This is achieved by an object in each segment that indicates the
   direction of the segment with respect to data flow.

   A segment that is marked as 'forward' carries data from the 'head' of
   the LSP to the 'tail'. A segment marked as 'reverse' carries data in
   the reverse direction.

   Where an LSP is signaled using a conventional signaling protocol, the
   'head' of the LSP is the source of the signaling (also known as the
   ingress) and the 'tail' is the destination (also known as the
   egress). For manually configured LSPs an arbitrary decision must be
   made about which segments are 'forward' and which 'reverse'. For
   consistency this decision should be made across all LSRs that
   participate in the LSP by assigning 'head' and 'tail' ends to the
   LSP.

6. Example of LSP Setup

   In this section we provide a brief example of using the MIB objects
   described in sections 7 and 8 to set up an LSP. While this example is
   not meant to illustrate every nuance of the MIB, it is intended as an
   aid to understanding some of the key concepts. It is meant to be read
   after going through the MIB itself. A prerequisite is an
   understanding of [RFC3813].

   Suppose that one would like to manually create a best-effort,
   bi-directional LSP. Assume that, in the forward direction, the LSP
   enters the LSR via MPLS interface A with ifIndex 12 and exits the LSR
   via MPLS interface B with ifIndex 13. For the reverse direction, we
   assume the LSP enters via interface B and leaves via interface A

Nadeau and Farrel (Editors)                                     [Page 5]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   (i.e. the forward and reverse directions use the same bi-directional
   interfaces). Let us also assume that we do not wish to have a label
   stack beneath the top label on the outgoing labeled packets. The
   following example illustrates which rows and corresponding objects
   might be created to accomplish this.

   We must first create rows in the gmplsLabelTable corresponding to the
   labels required for each of the forward and reverse direction in- and
   out-segments.  For the purpose of this example the forward and
   reverse labels on each interface will be the same, hence we need to
   create just two rows in the gmplsLabelTable - one for each interface.

   In gmplsLabelTable:
   {
     gmplsLabelInterface           =3D 12,
     gmplsLabelIndex               =3D 1,
     gmplsLabelSubindex            =3D 0,
     gmplsLabelType                =3D gmplsFreeformGeneralizedLabel(3),
     gmplsLabelFreeform            =3D 0x123456789ABCDEF0
     gmplsLabelRowStatus           =3D createAndGo(4)
   }

   In gmplsLabelTable:
   {
     gmplsLabelInterface           =3D 13,
     gmplsLabelIndex               =3D 1,
     gmplsLabelSubindex            =3D 0,
     gmplsLabelType                =3D gmplsFreeformGeneralizedLabel(3),
     gmplsLabelFreeform            =3D 0xFEDCBA9876543210
     gmplsLabelRowStatus           =3D createAndGo(4)
   }

   We must next create the appropriate in-segment and out-segment
   entries. These are done in [RFC3813] using the mplsInSegmentTable and
   mplsOutSegmentTable.  Note that we use a row pointer to the two rows
   in the gmplsLableTable rather than specifying the labels explicitly
   in the in- and out-segment tables.  Also note that the row status for
   each row is set to createAndWait(5) to allow corresponding entries in
   the gmplsInSegmentTable and gmplsOutSegmentTable to be created.

   For the forward direction.

   In mplsInSegmentTable:
   {
      mplsInSegmentIndex           =3D 0x00000015
      mplsInSegmentLabel           =3D 0, -- incoming label in label =
table
      mplsInSegmentNPop            =3D 1,
      mplsInSegmentInterface       =3D 12, -- incoming interface

      -- RowPointer MUST point to the first accesible column.
      mplsInSegmentTrafficParamPtr    =3D 0.0,

Nadeau and Farrel (Editors)                                     [Page 6]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

      mplsInSegmentLabelPtr           =3D gmplsLabelTable (12, 1, 0)
      mplsInSegmentRowStatus          =3D createAndWait(5)
   }

   In mplsOutSegmentTable:
   {
      mplsOutSegmentIndex          =3D 0x00000012,
      mplsOutSegmentInterface      =3D 13, -- outgoing interface
      mplsOutSegmentPushTopLabel   =3D true(1),
      mplsOutSegmentTopLabel       =3D 0, -- outgoing label in label =
table

      -- RowPointer MUST point to the first accesible column.
      mplsOutSegmentTrafficParamPtr   =3D 0.0,
      mplsOutSegmentLabelPtr          =3D gmplsLabelTable (13, 1, 0)
      mplsOutSegmentRowStatus         =3D createAndWait(5)
   }

   For the reverse direction.

   In mplsInSegmentTable:
   {
      mplsInSegmentIndex           =3D 0x00000016

      mplsInSegmentLabel           =3D 0, -- incoming label in label =
table
      mplsInSegmentNPop            =3D 1,
      mplsInSegmentInterface       =3D 13, -- incoming interface

      -- RowPointer MUST point to the first accesible column.
      mplsInSegmentTrafficParamPtr    =3D 0.0,
      mplsInSegmentLabelPtr           =3D gmplsLabelTable (13, 1, 0)

      mplsInSegmentRowStatus          =3D createAndWait(5)
   }

   In mplsOutSegmentTable:
   {
      mplsOutSegmentIndex          =3D 0x00000013,
      mplsOutSegmentInterface      =3D 12, -- outgoing interface
      mplsOutSegmentPushTopLabel   =3D true(1),
      mplsOutSegmentTopLabel       =3D 0, -- outgoing label in label =
table

      -- RowPointer MUST point to the first accesible column.
      mplsOutSegmentTrafficParamPtr   =3D 0.0,
      mplsOutSegmentLabelPtr          =3D gmplsLabelTable (12, 1, 0)

      mplsOutSegmentRowStatus         =3D createAndWait(5)
   }

   These table entries are extended by entries in gmplsInSegmentTable
   and gmplsOutSegmentTable. Note that the nature of the 'extends'
   relationship is that the entry in gmplsInSegmentTable has the same

Nadeau and Farrel (Editors)                                     [Page 7]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   index values as the entry in mplsInSegmentTable. Similarly, the entry
   in gmplsOutSegmentTable has the same index values as the entry in
   mplsOutSegmentTable.

   First for the forward direction:

   In gmplsInSegmentTable(0x00000015)
   {
     gmplsInSegmentDirection          =3D forward (1)
   }

   In gmplsOutSegmentTable(0x00000012)
   {
     gmplsOutSegmentDirection         =3D forward (1)
   }

   Next for the reverse direction:

   In gmplsInSegmentTable(0x00000016)
   {
     gmplsInSegmentDirection          =3D reverse (2)
   }

   In gmplsOutSegmentTable(0x00000013)
   {
     gmplsOutSegmentDirection         =3D reverse (2)
   }

   Next, two cross-connect entries are created in the mplsXCTable of the
   MPLS LSR MIB, thereby associating the newly created segments
   together.

   In mplsXCTable:
   {
      mplsXCIndex                =3D 0x01,
      mplsXCInSegmentIndex       =3D 0x00000015,
      mplsXCOutSegmentIndex      =3D 0x00000012,
      mplsXCLspId                =3D 0x0102 -- unique ID
      mplsXCLabelStackIndex      =3D 0x00, -- only a single outgoing =
label
      mplsXCRowStatus            =3D createAndGo(4)
   }

   In mplsXCTable:
   {
      mplsXCIndex                =3D 0x02,
      mplsXCInSegmentIndex       =3D 0x00000016,
      mplsXCOutSegmentIndex      =3D 0x00000013,
      mplsXCLspId                =3D 0x0102 -- unique ID
      mplsXCLabelStackIndex      =3D 0x00, -- only a single outgoing =
label
      mplsXCRowStatus            =3D createAndGo(4)
   }

Nadeau and Farrel (Editors)                                     [Page 8]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   Finally, the in-segments and out-segments are activated.

   In mplsInSegmentTable(0x00000015):
   {
      mplsInSegmentRowStatus          =3D active(1)
   }
   In mplsInSegmentTable(0x00000016):
   {
      mplsInSegmentRowStatus          =3D active(1)
   }
   In mplsOutSegmentTable(0x00000012):
   {
      mplsOutSegmentRowStatus         =3D active(1)
   }
   In mplsOutSegmentTable(0x00000013):
   {
      mplsOutSegmentRowStatus         =3D active(1)
   }

7. GMPLS Label Switching Router MIB Definitions

   GMPLS-LSR-STD-MIB DEFINITIONS ::=3D BEGIN

   IMPORTS
     MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, zeroDotZero
       FROM SNMPv2-SMI                                   -- [RFC2578]
     MODULE-COMPLIANCE, OBJECT-GROUP
       FROM SNMPv2-CONF                                  -- [RFC2580]
     RowPointer
       FROM SNMPv2-TC                                    -- [RFC2579]
     GmplsSegmentDirection
       FROM GMPLS-TC-STD-MIB                             -- [GMPLSTCMIB]
     mplsInterfaceIndex, mplsInSegmentIndex, mplsOutSegmentIndex
       FROM MPLS-LSR-STD-MIB                             -- [RFC3813]
     mplsStdMIB
       FROM MPLS-TC-STD-MIB                              -- [RFC3811]
   ;

   gmplsLsrStdMIB MODULE-IDENTITY
     LAST-UPDATED
       "200410080001Z" -- 8 October 2004 00:00:01 GMT
     ORGANIZATION
       "Common Control And Measurement Plane (CCAMP) Working Group"
     CONTACT-INFO
       "       Thomas D. Nadeau
               Cisco Systems, Inc.
        Email: [email-masked]

               Adrian Farrel
               Old Dog Consulting
        Email: [email-masked]

Nadeau and Farrel (Editors)                                     [Page 9]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

        Comments about this document should be emailed direct to the
        CCAMP working group mailing list at [email-masked]"
     DESCRIPTION
       "Copyright (C) The Internet Society (2004). The
        initial version of this MIB module was published
        in RFC xxxx. For full legal notices see the RFC
        itself or see: http://www.ietf.org/copyrights/ianamib.html

        This MIB module contains managed object definitions
        for the Generalized Multiprotocol (GMPLS) Label Switching
        Router as defined in:
        Generalized Multi-Protocol Label Switching (GMPLS)
        Architecture,Mannie et al.,
        draft-ietf-ccamp-gmpls-architecture-07.txt, May 2003,
        work in progress."

     -- Revision history.

     REVISION
       "200410080001Z" -- 8 October 2004 00:00:01 GMT
     DESCRIPTION
       "Initial version issued as part of RFC XXXX."
     ::=3D { mplsStdMIB xx }

   -- Top level components of this MIB module.

   -- Notifications
   -- no notifications are currently defined.
   gmplsLsrNotifications OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 0 }

   -- Tables, Scalars
   gmplsLsrObjects       OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 1 }

   -- Conformance
   gmplsLsrConformance   OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 2 }

   -- GMPLS Interface Table.

   gmplsInterfaceTable OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsInterfaceEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "This table specifies per-interface GMPLS capability
        and associated information. It extends the
        information in mplsInterfaceTable."
     ::=3D { gmplsLsrObjects 1 }

Nadeau and Farrel (Editors)                                    [Page 10]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   gmplsInterfaceEntry OBJECT-TYPE
     SYNTAX        GmplsInterfaceEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "A conceptual row in this table is created
        automatically by an LSR for every interface capable
        of supporting GMPLS and which is configured to do
        so. A conceptual row in this table will exist if and
        only if a corresponding entry in mplsInterfaceTable
        exists, and a corresponding entry in ifTable exists
        with ifType =3D mpls(166). If the associated entry in
        ifTable is operationally disabled (thus removing the
        GMPLS capabilities on the interface) or the entry in
        mplsInterfaceTable is deleted, the corresponding
        entry in this table MUST be deleted shortly
        thereafter.

        The indexing is the same as that for mplsInterfaceTable.
        Thus, the entry with index 0 represents the per-platform
        label space and contains parameters that apply to all
        interfaces that participate in the per-platform label space."
     INDEX { mplsInterfaceIndex }
   ::=3D { gmplsInterfaceTable 1 }

   GmplsInterfaceEntry ::=3D SEQUENCE {
     gmplsInterfaceSignalingCaps      BITS,
     gmplsInterfaceRsvpHelloPeriod    Unsigned32
   }

   gmplsInterfaceSignalingCaps OBJECT-TYPE
     SYNTAX  BITS {
       unknown (0),
       rsvpGmpls (1),
       crldpGmpls (2), -- note the use of CR-LDP is deprecated
       otherGmpls (3)
     }
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Defines the signaling capabilities on this
        interface. Multiple bits may legitimately be set at
        once. Setting no bits implies that GMPLS signaling
        cannot be performed on this interface and all LSPs
        must be manually provisioned or that this table
        entry is only present to supplement an entry in
        the mplsInterfaceTable by providing the information
        carried in other objects in this row."
     DEFVAL { { rsvpGmpls } }
   ::=3D { gmplsInterfaceEntry 1 }

Nadeau and Farrel (Editors)                                    [Page 11]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE
     SYNTAX       Unsigned32
     UNITS        "milliseconds"
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Period, in milliseconds, between sending RSVP Hello
        messages on this interface.  A value of 0 indicates
        that no Hello messages should be sent on this interface."
     REFERENCE
       "Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L.
        (Editor), RFC 3473, January 2003."
     DEFVAL { 3000 }
   ::=3D { gmplsInterfaceEntry 2 }

   -- End of gmplsInterfaceTable

   -- In-segment table.

   gmplsInSegmentTable  OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsInSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "This table extends the mplsInSegmentTable to provide GMPLS-
        specific information about incoming segments to an LSR."
   ::=3D { gmplsLsrObjects 2 }

   gmplsInSegmentEntry  OBJECT-TYPE
     SYNTAX        GmplsInSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An entry in this table extends the representation of
        an incoming segment represented by an entry in
        mplsInSegmentTable. An entry can be created by a
        network administrator or an SNMP agent, or a GMPLS
        signaling protocol.

        Note that the storage type for this entry SHOULD be
        inherited from the corresponding entry in the
        mplsInSegmentTable given by the value of the
        mplsInSegmentStorageType object."
     INDEX { mplsInSegmentIndex }
   ::=3D { gmplsInSegmentTable 1 }

   GmplsInSegmentEntry ::=3D SEQUENCE {
     gmplsInSegmentDirection        GmplsSegmentDirection,
     gmplsInSegmentExtraParamsPtr   RowPointer
   }

Nadeau and Farrel (Editors)                                    [Page 12]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   gmplsInSegmentDirection OBJECT-TYPE
     SYNTAX        GmplsSegmentDirection
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This object indicates the direction of data flow on
        this segment. This object cannot be modified if
        mplsInSegmentRowStatus for the associated entry in
        the mplsInSegmentTable is active(1)."
     DEFVAL        { forward }
   ::=3D { gmplsInSegmentEntry 1 }

   gmplsInSegmentExtraParamsPtr  OBJECT-TYPE
     SYNTAX       RowPointer
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Some Tunnels will run over transports that can
        usefully support technology-specific additional parameters
        (for example, SONET resource usage). Such can be supplied from
        an external table and referenced from here.
        A value of zeroDotzero in this attribute indicates that there
        is no such additional information."
     DEFVAL      { zeroDotZero }
     ::=3D { gmplsInSegmentEntry 2 }

   -- End of gmplsInSegmentTable

   -- Out-segment table.

   gmplsOutSegmentTable  OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsOutSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "This table extends the mplsOutSegmentTable to
        provide GMPLS-specific information about outgoing
        segments from an LSR."
   ::=3D { gmplsLsrObjects 3 }

   gmplsOutSegmentEntry  OBJECT-TYPE
     SYNTAX        GmplsOutSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An entry in this table extends the representation of
        an outgoing segment represented by an entry in
        mplsOutSegmentTable. An entry can be created by a
        network administrator or an SNMP agent, or a GMPLS
        signaling protocol.

Nadeau and Farrel (Editors)                                    [Page 13]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

        Note that the storage type for this entry SHOULD be
        inherited from the corresponding entry in the
        mplsOutSegmentTable given by the value of the
        mplsOutSegmentStorageType object."
     INDEX  { mplsOutSegmentIndex }
   ::=3D { gmplsOutSegmentTable 1 }

   GmplsOutSegmentEntry ::=3D SEQUENCE {
     gmplsOutSegmentDirection       GmplsSegmentDirection,
     gmplsOutSegmentTTLDecrement    Unsigned32,
     gmplsOutSegmentExtraParamsPtr  RowPointer
   }

   gmplsOutSegmentDirection OBJECT-TYPE
     SYNTAX        GmplsSegmentDirection
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This object indicates the direction of data flow on
        this segment. This object cannot be modified if
        mplsOutSegmentRowStatus for the associated entry in
        the mplsOutSegmentTable is active(1)."
     DEFVAL  { forward }
   ::=3D { gmplsOutSegmentEntry 1 }

   gmplsOutSegmentTTLDecrement OBJECT-TYPE
     SYNTAX        Unsigned32 (0..255)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This object indicates the amount by which to
        decrement the TTL of any payload packets forwarded
        on this segment if per-hop decrementing is being
        done.
        A value of zero indicates that no decrement should
        be made or that per-hop decrementing is not in
        force.
        See the gmplsTunnelTTLDecrement object in the
        gmplsTunnelTable of [GMPLSTEMIB] for a value by
        which to decrement the TTL for the whole of a
        tunnel.
        This object cannot be modified if
        mplsOutSegmentRowStatus for the associated entry in
        the mplsOutSegmentTable is active(1)."
     REFERENCE
       "Time To Live (TTL) Processing in Multi-Protocol Label Switching
        (MPLS) Networks, Agarwal, P., Akyol, B., RFC 3443, January 2003"
     DEFVAL  { 0 }
   ::=3D { gmplsOutSegmentEntry 2 }

Nadeau and Farrel (Editors)                                    [Page 14]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   gmplsOutSegmentExtraParamsPtr  OBJECT-TYPE
     SYNTAX       RowPointer
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Some Tunnels will run over transports that can
        usefully support technology-specific additional parameters
        (for example, SONET resource usage). Such can be supplied from
        an external table and referenced from here.
        A value of zeroDotzero in this attribute indicates that there
        is no such additional information."
     DEFVAL      { zeroDotZero }
     ::=3D { gmplsOutSegmentEntry 3 }

   -- End of gmplsOutSegmentTable

   -- Module compliance.

   gmplsLsrGroups
     OBJECT IDENTIFIER ::=3D { gmplsLsrConformance 1 }

   gmplsLsrCompliances
     OBJECT IDENTIFIER ::=3D { gmplsLsrConformance 2 }

   -- Compliance requirement for fully compliant implementations.

   gmplsLsrModuleFullCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance statement for agents that provide full
        support for GMPLS-LSR-STD-MIB."

     MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.

     MANDATORY-GROUPS {
       ifGeneralInformationGroup,
       ifCounterDiscontinuityGroup
     }

     MODULE MPLS-LSR-STD-MIB -- The MPLS LSR MIB

     MANDATORY-GROUPS {
       mplsInterfaceGroup,
       mplsInSegmentGroup,
       mplsOutSegmentGroup,
       mplsXCGroup,
       mplsPerfGroup,
       mplsLsrNotificationGroup
     }

Nadeau and Farrel (Editors)                                    [Page 15]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     MODULE -- this module

     MANDATORY-GROUPS    {
       gmplsInterfaceGroup,
       gmplsInSegmentGroup,
       gmplsOutSegmentGroup
     }

     -- gmplsInSegmentTable

     OBJECT      gmplsInSegmentDirection
     SYNTAX      GmplsSegmentDirection
     MIN-ACCESS  read-write
     DESCRIPTION
       "Only forward(1) needs to be supported by
        implementations that only support unidirectional
        LSPs."

     -- gmplsOutSegmentTable

     OBJECT      gmplsOutSegmentDirection
     SYNTAX      GmplsSegmentDirection
     MIN-ACCESS  read-write
     DESCRIPTION
       "Only forward(1) needs to be supported by
        implementations that only support unidirectional
        LSPs."

     OBJECT      gmplsOutSegmentTTLDecrement
     SYNTAX      Unsigned32 (0..255)
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   ::=3D { gmplsLsrCompliances 1 }

   -- Compliance requirement for implementations that provide read-only
   -- access.

   gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance requirement for implementations that only
        provide read-only support for GMPLS-LSR-STD-MIB. Such
        devices can then be monitored but cannot be configured
        using this MIB modules."

     MODULE IF-MIB -- The interfaces Group MIB, RFC 2863

Nadeau and Farrel (Editors)                                    [Page 16]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     MANDATORY-GROUPS {
       ifGeneralInformationGroup,
       ifCounterDiscontinuityGroup
     }

     MODULE MPLS-LSR-STD-MIB

     MANDATORY-GROUPS {
       mplsInterfaceGroup,
       mplsInSegmentGroup,
       mplsOutSegmentGroup,
       mplsXCGroup,
       mplsPerfGroup
     }

     MODULE -- this module

     MANDATORY-GROUPS {
       gmplsInterfaceGroup,
       gmplsInSegmentGroup,
       gmplsOutSegmentGroup
     }

     -- gmplsInterfaceGroup

     OBJECT      gmplsInterfaceSignalingCaps
     SYNTAX  BITS {
       unknown (0),
       rsvpGmpls (1),
       crldpGmpls (2),
       otherGmpls (3)
     }
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsInterfaceRsvpHelloPeriod
     SYNTAX      Unsigned32
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     -- gmplsInSegmentTable

     OBJECT      gmplsInSegmentDirection
     SYNTAX      GmplsSegmentDirection
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required. Only forward(1) needs
        to be supported by implementations that only support
        unidirectional LSPs."

Nadeau and Farrel (Editors)                                    [Page 17]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     OBJECT      gmplsInSegmentExtraParamsPtr
     SYNTAX      RowPointer
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     -- gmplsOutSegmentTable

     OBJECT      gmplsOutSegmentDirection
     SYNTAX      GmplsSegmentDirection
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required. Only forward(1) needs
        to be supported by implementations that only support
        unidirectional LSPs."

     OBJECT      gmplsOutSegmentTTLDecrement
     SYNTAX      Unsigned32 (0..255)
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsOutSegmentExtraParamsPtr
     SYNTAX      RowPointer
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   ::=3D { gmplsLsrCompliances 2 }

   -- Units of conformance.

   gmplsInterfaceGroup OBJECT-GROUP
     OBJECTS {
       gmplsInterfaceSignalingCaps,
       gmplsInterfaceRsvpHelloPeriod
     }
     STATUS  current
     DESCRIPTION
       "Collection of objects needed for GMPLS interface
        configuration and performance information."
   ::=3D { gmplsLsrGroups 1 }

   gmplsInSegmentGroup  OBJECT-GROUP
     OBJECTS {
       gmplsInSegmentDirection,
       gmplsInSegmentExtraParamsPtr
     }
     STATUS  current

Nadeau and Farrel (Editors)                                    [Page 18]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     DESCRIPTION
       "Collection of objects needed to implement a GMPLS
        in-segment."
   ::=3D { gmplsLsrGroups 2 }

   gmplsOutSegmentGroup  OBJECT-GROUP
     OBJECTS {
       gmplsOutSegmentDirection,
       gmplsOutSegmentTTLDecrement,
       gmplsOutSegmentExtraParamsPtr
     }
     STATUS  current
     DESCRIPTION
       "Collection of objects needed to implement a GMPLS
        out-segment."
   ::=3D { gmplsLsrGroups 3 }
   END

8. GMPLS Label MIB Definitions

   GMPLS-LABEL-STD-MIB DEFINITIONS ::=3D BEGIN

   IMPORTS
     MODULE-IDENTITY, OBJECT-TYPE, Unsigned32,
     Integer32
       FROM SNMPv2-SMI                                   -- [RFC2578]
     MODULE-COMPLIANCE, OBJECT-GROUP
       FROM SNMPv2-CONF                                  -- [RFC2580]
     RowStatus, StorageType
       FROM SNMPv2-TC                                    -- [RFC2579]
     InterfaceIndexOrZero
       FROM IF-MIB                                       -- [RFC2863]
     IndexIntegerNextFree
       FROM DIFFSERV-MIB                                 -- [RFC3289]
     MplsLabel
       FROM MPLS-TC-STD-MIB                              -- [RFC3811]
     GmplsGeneralizedLabelTypes, GmplsFreeformLabel
       FROM GMPLS-TC-STD-MIB                             -- [GMPLSTCMIB]
     mplsStdMIB
       FROM MPLS-TC-STD-MIB                              -- [RFC3811]
   ;

   gmplsLabelStdMIB MODULE-IDENTITY
     LAST-UPDATED
       "200410080001Z" -- 8 October 2004 00:00:01 GMT
     ORGANIZATION
       "Common Control And Measurement Plane (CCAMP) Working Group"
     CONTACT-INFO
       "       Thomas D. Nadeau
               Cisco Systems, Inc.
        Email: [email-masked]

Nadeau and Farrel (Editors)                                    [Page 19]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

               Adrian Farrel
               Old Dog Consulting
        Email: [email-masked]

        Comments about this document should be emailed direct to the
        CCAMP working group mailing list at [email-masked]"
     DESCRIPTION
       "Copyright (C) The Internet Society (2004). The
        initial version of this MIB module was published
        in RFC xxxx. For full legal notices see the RFC
        itself or see: http://www.ietf.org/copyrights/ianamib.html

        This MIB module contains managed object definitions
        for labels within GMPLS systems as defined in:

        Generalized Multi-Protocol Label Switching (GMPLS)
        Signaling Functional Description, Berger, L. (Editor),
        RFC 3471, January 2003."

     -- Revision history.
     REVISION
       "200410080001Z" -- 8 October 2004 00:00:01 GMT
     DESCRIPTION
       "Initial version issued as part of RFC XXXX."
     ::=3D { mplsStdMIB xx }

   -- Top level components of this MIB module.

   -- Notifications
   -- no notifications are currently defined.
   gmplsLabelNotifications  OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 0 =
}

   -- Tables, Scalars
   gmplsLabelObjects        OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 1 =
}

   -- Conformance
   gmplsLabelConformance    OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 2 =
}

   -- GMPLS Label Table.

   gmplsLabelIndexNext OBJECT-TYPE
     SYNTAX        IndexIntegerNextFree
     MAX-ACCESS    read-only
     STATUS        current
     DESCRIPTION
         "This object contains an unused value for
          gmplsLabelIndex, or a zero to indicate
          that no unused value exists or is available.

          An management application wishing to create
          a row in the gmplsLabelTable may read this

Nadeau and Farrel (Editors)                                    [Page 20]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

          object and then attempt to create a row in
          the table. If row creation fails (because
          another application has already created a row
          with the supplied index) the management
          application should read this object again
          to get a new index value.

          When a row is created in the gmplsLabelTable
          with the gmplsLabelIndex value held by this
          object, an implementation MUST change the value
          in this object."
     ::=3D { gmplsLabelObjects 1 }

   gmplsLabelTable OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsLabelEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "Table of GMPLS Labels.  This table allows the representation
        of the more complex label forms required for GMPLS which
        cannot be held within the textual convention MplsLabel. That
        is labels that cannot be encoded within 32 bits. It is,
        nevertheless also capable of holding 32 bit labels or
        regular MPLS labels if desired.

        Each entry in this table represents an individual
        GMPLS label value.  Labels in the tables in other
        MIBs are referred to using row pointer into this
        table. The indexing of this table provides for
        arbitrary indexing and also for concatenation of
        labels."
   ::=3D { gmplsLabelObjects 2 }

   gmplsLabelEntry OBJECT-TYPE
     SYNTAX        GmplsLabelEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An entry in this table represents a single label
        value. There are three indexes into the table.
        -  The interface index may be helpful to distinguish
           which labels are in use on which interfaces or to
           handle cases where there are a very large number
           of labels in use in the system. When label
           representation is desired to apply to the whole
           system or when it is not important to distinguish
           labels by their interfaces, this index MAY be set
           to zero.
        -  The label index provides a way of identifying the
           label.

Nadeau and Farrel (Editors)                                    [Page 21]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

        -  The label sub-index is only used for concatenated
           labels. It identifies each component label. When
           non-concatenated labels are used, this index
           SHOULD be set to zero.

        A storage type object is supplied to control the
        storage type for each entry, but implementations
        should note that the storage type of conceptual rows
        in other tables that include row pointers to an
        entry in this table SHOULD dictate the storage type
        of the rows in this table where the row in the other
        table is more persistent."
     INDEX {
       gmplsLabelInterface,
       gmplsLabelIndex,
       gmplsLabelSubindex }
   ::=3D { gmplsLabelTable 1 }

   GmplsLabelEntry ::=3D SEQUENCE {
     gmplsLabelInterface           InterfaceIndexOrZero,
     gmplsLabelIndex               Unsigned32,
     gmplsLabelSubindex            Unsigned32,
     gmplsLabelType                GmplsGeneralizedLabelTypes,
     gmplsLabelMplsLabel           MplsLabel,
     gmplsLabelPortWavelength      Unsigned32,
     gmplsLabelFreeform            GmplsFreeformLabel,
     gmplsLabelSonetSdhSignalIndex Integer32,
     gmplsLabelSdhVc               Integer32,
     gmplsLabelSdhVcBranch         Integer32,
     gmplsLabelSonetSdhBranch      Integer32,
     gmplsLabelSonetSdhGroupBranch Integer32,
     gmplsLabelWavebandId          Unsigned32,
     gmplsLabelWavebandStart       Unsigned32,
     gmplsLabelWavebandEnd         Unsigned32,
     gmplsLabelRowStatus           RowStatus,
     gmplsLabelStorageType         StorageType
   }

   gmplsLabelInterface OBJECT-TYPE
     SYNTAX        InterfaceIndexOrZero
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "The interface on which this label is used. If the
        label has or could have applicability across the
        whole system, this object SHOULD be set to zero."
   ::=3D { gmplsLabelEntry 1 }

   gmplsLabelIndex OBJECT-TYPE
     SYNTAX        Unsigned32 (0..4294967295)
     MAX-ACCESS    not-accessible

Nadeau and Farrel (Editors)                                    [Page 22]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     STATUS        current
     DESCRIPTION
       "An arbitrary index into the table to identify a label.
        Note that implementations that are representing 32 bit
        labels within this table MAY choose to align this index
        with the value of the label, but should be aware of the
        implications of sparsely populated tables.
        A management application may read the gmplsLabelIndexNext
        object to find a suitable value for this object."
   ::=3D { gmplsLabelEntry 2 }

   gmplsLabelSubindex OBJECT-TYPE
     SYNTAX        Unsigned32 (0..4294967295)
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "In conjunction with gmplsLabelInterface and gmplsLabelIndex,
        this object uniquely identifies this row. This sub-index
        allows a single GMPLS label to be defined as a concatenation
        of labels. This is particularly useful in TDM.

        The ordering of sub-labels is strict with the sub-label with
        lowest gmplsLabelSubindex appearing first. Note that all
        sub-labels of a single GMPLS label must share the same
        gmplsLabelInterface and gmplsLabelIndex values. For labels
        that are not composed of concatenated sub-labels, this value
        SHOULD be set to zero."
   ::=3D { gmplsLabelEntry 3 }

   gmplsLabelType OBJECT-TYPE
     SYNTAX        GmplsGeneralizedLabelTypes
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "Identifies the type of this label. Note that this object
        does not determine whether MPLS or GMPLS signaling is in
        use: a value of gmplsMplsLabel (1) denotes that a 23 bit
        MPLS packet label is present, but does not describe
        whether this is signaled using MPLS or GMPLS.

        The value of this object helps determine which of
        the following objects are valid.
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
      REFERENCE
        "Generalized Multi-Protocol Label Switching (GMPLS)
         Signaling Functional Description, Berger, L. (Editor),
         RFC 3471, January 2003."
   ::=3D { gmplsLabelEntry 4 }

Nadeau and Farrel (Editors)                                    [Page 23]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   gmplsLabelMplsLabel OBJECT-TYPE
     SYNTAX         MplsLabel
     MAX-ACCESS     read-create
     STATUS         current
     DESCRIPTION
       "The value of an MPLS label (that is a packet label)
        if this table is used to store it. This may be used
        in MPLS systems even though the label values can be
        adequately stored in the MPLS MIB modules. Further,
        in mixed MPLS and GMPLS systems it may be
        advantageous to store all labels in a single label
        table. Lastly, in GMPLS systems where packet labels
        are used (that is in systems that use GMPLS
        signaling and GMPLS labels for packet switching) it
        may be desirable to use this table.
        This object is only valid if gmplsLabelType is set
        to gmplsMplsLabel (1).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "MPLS Label Stack Encoding, Rosen, E. et al, RFC 3032,
        January 2001."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 6 }

   gmplsLabelPortWavelength OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The value of a Port or Wavelength Label when carried
        as a Generalized Label. Only valid if gmplsLabelType
        is set to gmplsPortWavelengthLabel(2).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "Generalized Multi-Protocol Label Switching (GMPLS)
        Signaling Functional Description, Berger, L. (Editor),
        RFC 3471, January 2003."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 7 }

   gmplsLabelFreeform OBJECT-TYPE
     SYNTAX        GmplsFreeformLabel
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The value of a freeform Generalized Label that does
        not conform to one of the standardized label
        encoding or that an implementation chooses to
        represent as an octet string without further

Nadeau and Farrel (Editors)                                    [Page 24]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

        decoding. Only valid if gmplsLabelType is set to
        gmplsFreeformGeneralizedLabel(3). This object
        cannot be modified if gmplsLabelRowStatus is active(1)."
   ::=3D { gmplsLabelEntry 8 }

   gmplsLabelSonetSdhSignalIndex OBJECT-TYPE
     SYNTAX        Integer32 (0..4095)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The Signal Index value (S) of a SONET or SDH
        Generalized Label. Zero indicates that this field is
        not significant. Only valid if gmplsLabelType is set
        to gmplsSonetLabel(4) or gmplsSdhLabel(5).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "Generalized Multi-Protocol Label Switching Extensions
        for SONET and SDH Control, Mannie, E., Papadimitriou, D.
        (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
        February 2003, work in progress."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 9 }

   gmplsLabelSdhVc OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The VC Indicator (U) of an SDH Generalized Label.
        Zero indicates that this field is non-significant.
        Only valid if gmplsLabelType is set to gmplsSdhLabel(5).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "Generalized Multi-Protocol Label Switching Extensions
        for SONET and SDH Control, Mannie, E., Papadimitriou, D.
        (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
        February 2003, work in progress."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 10 }

   gmplsLabelSdhVcBranch OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The VC Branch Indicator (K) of an SDH Generalized
        Label. Zero indicates that this field is non-significant.
        Only valid if gmplsLabelType is set to gmplsSdhLabel(5). This
        object cannot be modified if gmplsLabelRowStatus is active(1)."

Nadeau and Farrel (Editors)                                    [Page 25]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     REFERENCE
       "Generalized Multi-Protocol Label Switching Extensions
        for SONET and SDH Control, Mannie, E., Papadimitriou, D.
        (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
        February 2003, work in progress."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 11 }

   gmplsLabelSonetSdhBranch OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The Branch Indicator (L) of a SONET or SDH
        Generalized Label. Zero indicates that this field is
        non-significant. Only valid gmplsLabelType is set to
        gmplsSonetLabel(4) or gmplsSdhLabel(5).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "Generalized Multi-Protocol Label Switching Extensions
        for SONET and SDH Control, Mannie, E., Papadimitriou, D.
        (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
        February 2003, work in progress."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 12 }

   gmplsLabelSonetSdhGroupBranch OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The Group Branch Indicator (M) of a SONET or SDH
        Generalized Label. Zero indicates that this field is
        non-significant. Only valid if gmplsLabelType is set
        to gmplsSonetLabel(4) or gmplsSdhLabel(5).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "Generalized Multi-Protocol Label Switching Extensions
        for SONET and SDH Control, Mannie, E., Papadimitriou, D.
        (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
        February 2003, work in progress."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 13 }

   gmplsLabelWavebandId OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current

Nadeau and Farrel (Editors)                                    [Page 26]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     DESCRIPTION
       "The waveband identifier component of a waveband label. Only
        valid if gmplsLabelType is set to gmplsWavebandLabel(6). This
        object cannot be modified if gmplsLabelRowStatus is active(1)."
     REFERENCE
       "Generalized Multi-Protocol Label Switching (GMPLS)
        Signaling Functional Description, Berger, L. (Editor),
        RFC 3471, January 2003."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 14 }

   gmplsLabelWavebandStart OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The starting label component of a waveband label.
        Only valid if gmplsLabelType is set to
        gmplsWavebandLabel(6).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "Generalized Multi-Protocol Label Switching (GMPLS)
        Signaling Functional Description, Berger, L. (Editor),
        RFC 3471, January 2003."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 15 }

   gmplsLabelWavebandEnd OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The end label component of a waveband label. Only
        valid if gmplsLabelType is set to gmplsWavebandLabel(6).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "Generalized Multi-Protocol Label Switching (GMPLS)
        Signaling Functional Description, Berger, L. (Editor),
        RFC 3471, January 2003."
     DEFVAL        { 0 }
   ::=3D { gmplsLabelEntry 16 }

   gmplsLabelRowStatus OBJECT-TYPE
     SYNTAX        RowStatus
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This variable is used to create, modify, and/or
        delete a row in this table. When a row in this

Nadeau and Farrel (Editors)                                    [Page 27]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

        table has a row in the active(1) state, no objects in this row
        can be modified except the gmplsLabelRowStatus and
        gmplsLabelStorageType."
   ::=3D { gmplsLabelEntry 17 }

   gmplsLabelStorageType OBJECT-TYPE
     SYNTAX        StorageType
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This variable indicates the storage type for this object.
        The agent MUST ensure that this object's value remains
        consistent with the storage type of any rows in other
        tables that contain pointers to this row. In particular,
        the storage type of this row must be at least as permanent
        as that of any row that point to it.
        Conceptual rows having the value 'permanent' need not
        allow write-access to any columnar objects in the row."
     REFERENCE
       "See RFC2579."
     DEFVAL { volatile }
   ::=3D { gmplsLabelEntry 18 }

   -- End of GMPLS Label Table

   -- Module compliance.

   gmplsLabelGroups
     OBJECT IDENTIFIER ::=3D { gmplsLabelConformance 1 }

   gmplsLabelCompliances
     OBJECT IDENTIFIER ::=3D { gmplsLabelConformance 2 }

   gmplsLabelModuleFullCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance statement for agents that support
        the GMPLS Label MIB module."

     MODULE -- this module

     -- The mandatory groups have to be implemented by LSRs claiming
     -- support for this MIB module. This MIB module is, however, not
     -- mandatory for a working implementation of a GMPLS LSR with full
     -- MIB support if the GMPLS labels in use can be represented within
     -- a 32 bit quantity.

     MANDATORY-GROUPS {
       gmplsLabelTableGroup
     }

Nadeau and Farrel (Editors)                                    [Page 28]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     -- Units of conformance.

     GROUP gmplsLabelTableGroup
     DESCRIPTION
       "This group is mandatory for devices which support
        the gmplsLabelTable."

     GROUP gmplsLabelPacketGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for
        implementations that support packet labels."

     GROUP gmplsLabelPortWavelengthGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for
        implementations that support port and wavelength
        labels."

     GROUP gmplsLabelFreeformGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for
        implementations that support freeform labels."

     GROUP gmplsLabelSonetSdhGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for
        implementations that support SONET or SDH labels."

     GROUP gmplsLabelWavebandGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for
        implementations that support Waveband labels."

     -- gmplsLabelTable

     OBJECT      gmplsLabelType
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelMplsLabel
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelPortWavelength
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

Nadeau and Farrel (Editors)                                    [Page 29]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     OBJECT      gmplsLabelFreeform
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSonetSdhSignalIndex
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSdhVc
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSdhVcBranch
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSonetSdhBranch
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSonetSdhGroupBranch
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelWavebandId
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelWavebandStart
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelWavebandEnd
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT       gmplsLabelRowStatus
     SYNTAX       RowStatus {
       active(1),
       notInService(2)
     }

Nadeau and Farrel (Editors)                                    [Page 30]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

     WRITE-SYNTAX RowStatus {
       active(1),
       notInService(2),
       createAndGo(4),
       destroy(6)
     }
     DESCRIPTION
       "Support for notInService, createAndWait and notReady
        is not required."

     OBJECT      gmplsLabelStorageType
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   ::=3D { gmplsLabelCompliances 1 }

   -- Units of conformance.

   gmplsLabelTableGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelIndexNext,
       gmplsLabelType,
       gmplsLabelRowStatus,
       gmplsLabelStorageType
     }
     STATUS  current
     DESCRIPTION
       "Necessary, but not sufficient, set of objects to
        implement label table support.  In addition,
        depending on the type of labels supported (for
        example, wavelength labels), the following other
        groups defined below are mandatory:
        gmplsLabelPacketGroup and/or
        gmplsLabelPortWavelengthGroup and/or
        gmplsLabelFreeformGroup and/or
        gmplsLabelSonetSdhGroup."
   ::=3D { gmplsLabelGroups 1 }

   gmplsLabelPacketGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelMplsLabel
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Packet (MPLS) labels."
   ::=3D { gmplsLabelGroups 2 }

Nadeau and Farrel (Editors)                                    [Page 31]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   gmplsLabelPortWavelengthGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelPortWavelength
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Port and Wavelength
        labels."
   ::=3D { gmplsLabelGroups 3 }

   gmplsLabelFreeformGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelFreeform
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Freeform labels."
   ::=3D { gmplsLabelGroups 4 }

   gmplsLabelSonetSdhGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelSonetSdhSignalIndex,
       gmplsLabelSdhVc,
       gmplsLabelSdhVcBranch,
       gmplsLabelSonetSdhBranch,
       gmplsLabelSonetSdhGroupBranch
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement SONET and SDH labels."
   ::=3D { gmplsLabelGroups 5 }

   gmplsLabelWavebandGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelWavebandId,
       gmplsLabelWavebandStart,
       gmplsLabelWavebandEnd
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Waveband labels."
   ::=3D { gmplsLabelGroups 6 }

   END

9. Security Considerations

   It is clear that the MIB modules described in this document in
   association with the MPLS-LSR-STD-MIB are potentially useful for
   monitoring of GMPLS LSRs. These MIB modules can also be used for
   configuration of certain objects, and anything that can be configured

Nadeau and Farrel (Editors)                                    [Page 32]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   can be incorrectly configured, with potentially disastrous results.

   There are a number of management objects defined in these MIB modules
   with a MAX-ACCESS clause of read-write and/or read-create. Such
   objects may be considered sensitive or vulnerable in some network
   environments. The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations. These are the tables and objects and their
   sensitivity/vulnerability:

   o  the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable
      and gmplsLabelTable collectively contain objects to provision
      GMPLS interfaces, LSPs and their associated parameters on a Label
      Switching Router (LSR). Unauthorized write access to objects in
      these tables, could result in disruption of traffic on the
      network. This is especially true if an LSP has already been
      established. The use of stronger mechanisms such as SNMPv3
      security should be considered where possible. Specifically, SNMPv3
      VACM and USM MUST be used with any SNMPv3 agent which implements
      these MIB modules.

   Some of the readable objects in these MIB modules "i.e., objects with
   a MAX-ACCESS other than not-accessible" may be considered sensitive
   or vulnerable in some network environments. It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP. These are the tables and objects and their
   sensitivity/vulnerability:

   o  the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable
      and gmplsLabelTable collectively show the LSP network topology and
      its capabilities. If an Administrator does not want to reveal this
      information, then these tables should be considered
      sensitive/vulnerable.

   SNMP versions prior to SNMPv3 did not include adequate security. Even
   if the network itself is secure "for example by using IPSec", even
   then, there is no control as to who on the secure network is allowed
   to access and GET/SET "read/change/create/delete" the objects in
   these MIB modules. It is RECOMMENDED that implementers consider the
   security features as provided by the SNMPv3 framework "see [RFC3410],
   section 8", including full support for the SNMPv3 cryptographic
   mechanisms "for authentication and privacy".

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module, is properly configured to give access to
   the objects only to those principals "users" that have legitimate
   rights to indeed GET or SET "change/create/delete" them.

Nadeau and Farrel (Editors)                                    [Page 33]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

10. Acknowledgments

   This draft is the work of the five authors listed in the Authors'
   Addresses section.

   This document extends [RFC3813]. The authors would like to express
   their gratitude to all those who worked on that earlier MIB document.

   The authors would like to express their thanks to Dan Joyle for his
   careful review and comments on early versions of the Label Table.
   Special thanks to Joan Cucchiara and Len Nieman for their help with
   compilation issues.

11. IANA Considerations

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

   As requested in requested in the GMPLS-TC-STD-MIB [GMPLSTCMIB] the
   two MIB modules contained in this document should be placed in the
   mplsStdMIB subtree as well.

   New assignments 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 xx } to the
   GMPLS-LABEL-STD-MIB module specified in this document.

12. References

12.1. Normative References

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]         McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                     Case, J., Rose, M., and S. Waldbusser, "Structure
                     of Management Information Version 2 (SMIv2)", STD
                     58, RFC 2578, April 1999.

Nadeau and Farrel (Editors)                                    [Page 34]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   [RFC2579]         McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                     Case, J., Rose, M., and S. Waldbusser, "Textual
                     Conventions for SMIv2", STD 58, RFC 2579, April
                     1999.

   [RFC2580]         McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                     Case, J., Rose, M., and S. Waldbusser, "Conformance
                     Statements for SMIv2", STD 58, RFC 2580, April
                     1999.

   [RFC2863]         McCloghrie, K. and F. Kastenholtz, "The Interfaces
                     Group MIB", RFC 2863, June 2000.

   [RFC3289]         Baker, F., Chan, K., and A. Smith, "Management
                     Information Base for the Differentiated Services
                     Architecture", RFC 3289, May 2002.

   [RFC3443]         Agarwal, P. and Akyol, B., "Time To Live (TTL)
                     Processing in Multi-Protocol Label Switching
                     (MPLS) Networks", RFC 3443, January 2003.

   [RFC3811]         Nadeau, T. and J. Cucchiara, "Definition of Textual
                     Conventions and for Multiprotocol Label Switching
                     (MPLS) Management", RFC 3811, June 2004.

   [RFC3813]         Srinivasan, C., Viswanathan, A., and T.  Nadeau,
                     "Multiprotocol Label Switching (MPLS) Label
                     Switching (LSR) Router Management Information Base
                     (MIB)", RFC 3813, June 2004.

   [GMPLSArch]       Mannie, E. (Editor), "Generalized Multiprotocol
                     Label Switching (GMPLS) Architecture",
                     draft-many-gmpls-architecture-07.txt, May 2003,
                     work in progress.

   [GMPLSSonetSDH]   Mannie, E., Papadimitriou, D. (Editors),
                     "Generalized Multi-Protocol Label Switching
                     Extensions for SONET and SDH Control",
                     draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
                     February 2003, work in progress.

   [GMPLSTCMIB]      Nadeau, T., Farrel, A., (Editors) "Definitions of
                     Textual Conventions for Multiprotocol Label
                     Switching (MPLS) Management",
                     draft-ietf-ccamp-gmpls-te-mib-06.txt, October 2004,
                     work in progress.

Nadeau and Farrel (Editors)                                    [Page 35]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   [GMPLSTEMIB]      Nadeau, T., Farrel, A. (Editors) "Generalized
                     Multiprotocol Label Switching (GMPLS) Traffic
                     Engineering Management Information Base",
                     draft-ietf-ccamp-gmpls-te-mib-06.txt, October 2004,
                     work in progress.

12.2. Informational References

   [RFC2026]         S. Bradner, "The Internet Standards Process --
                     Revision 3", RFC 2026, October 1996.

   [RFC2434]         Narten, T. and H. Alvestrand, "Guidelines for
                     Writing an IANA Considerations Section in RFCs",
                     BCP: 26, RFC 2434, October 1998.

   [RFC3031]         Rosen, E., Viswanathan, A., and R. Callon,
                     "Multiprotocol Label Switching Architecture", RFC
                     3031, January 2001.

   [RFC3032]         Rosen, E. et al, "MPLS Label Stack Encoding",
                     RFC 3032, January 2001.

   [RFC3209]         Awduche, D., Berger, L., Gan, D., Li, T.,
                     Srinivasan, V., and G. Swallow, "RSVP-TE:
                     Extensions to RSVP for LSP Tunnels", RFC 3209,
                     December 2001.

   [RFC3212]         Jamoussi, B., Aboul-Magd, O., Andersson, L.,
                     Ashwood-Smith, P., Hellstrand, F., Sundell, K.,
                     Callon, R., Dantu, R., Wu, L., Doolan, P., Worster,
                     T., Feldman, N., Fredette, A., Girish, M., Gray,
                     E., Halpern, J., Heinanen, J., Kilty, T., Malis,
                     A., and P. Vaananen, "Constraint-Based LSP Setup
                     using LDP", RFC 3212, December 2001."

   [RFC3410]         Case, J., Mundy, R., Partain, D. and B. Stewart,
                     "Introduction and Applicability Statements for
                     Internet-Standard Management Framework", RFC 3410,
                     December 2002.

   [RFC3411]         Harrington, D., Presuhn, R., and B. Wijnen, "An
                     Architecture for Describing Simple Network
                     Management Protocol (SNMP) Management Frameworks",
                     RFC 3411, December 2002.

   [RFC3413]         Levi, D., Meyer, P., Stewart, B., "SNMP
                     Applications", RFC 3413, December 2002.

   [RFC3471]         Berger, L. (Editor), "Generalized Multi-Protocol
                     Label Switching (GMPLS) Signaling Functional
                     Description", RFC 3471, January 2003.

Nadeau and Farrel (Editors)                                    [Page 36]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   [RFC3472]         Ashwood-Smith, P., Berger, L. (Editors),
                     "Generalized MPLS Signaling - CR-LDP Extensions",
                     RFC 3472, January 2003.

   [RFC3473]         Berger, L. (Editor), "Generalized MPLS Signaling -
                     RSVP-TE Extensions", RFC 3473 January 2003.

   [RFC3812]         Srinivasan, C., Viswanathan, A., and T. Nadeau,
                     "Multiprotocol Label Switching (MPLS) Traffic
                     Engineering (TE) Management Information Base
                     (MIB)", RFC 3812, June 2004.

13. Authors' Addresses

   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Apollo Drive
   Chelmsford, MA 01824
   Phone: +1-978-244-3051
   Email: [email-masked]

   Cheenu Srinivasan
   Bloomberg L.P.
   499 Park Ave.,
   New York, NY 10022
   Phone: +1-212-893-3682
   Email: [email-masked]

   Adrian Farrel
   Old Dog Consulting
   Phone: +44-(0)-1978-860944
   Email: [email-masked]

   Tim Hall
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex, EN2 6BQ, UK
   Phone: +44 20 8366 1177
   Email: [email-masked]

   Ed Harrison
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex, EN2 6BQ, UK
   Phone: +44 20 8366 1177
   Email: [email-masked]

14. Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to

Nadeau and Farrel (Editors)                                    [Page 37]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

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

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

15. Full Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

16. Changes

   This section must be removed before the draft progresses to RFC.

16.1. Changes from version 5 to version 6

   - ID nits and MIB bolierplate

16.2. Changes from version 4 to version 5

   - New IPR and copyright boiler plate.
   - Clarify description of gmplsInterfaceSignalingCaps.

Nadeau and Farrel (Editors)                                    [Page 38]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-lsr-mib-06.txt    October 2004

16.3. Changes from version 3 to version 4
   - Update references.
   - Allow configuration of the Hello timer per interface.
   - Provide support for monitoring technology-specific resources or
     performance through an arbitrary row pointer.
   - Retire unnecessary gmplsLabelFreeformLength.
   - Update examples.

16.4. Changes from version 2 to version 3

   - Work on basic compilation issues.
   - Provide a next index object to supply the next available
     arbitrary index into the Label Table.
   - Update references.
   - Update examples.

Nadeau and Farrel (Editors)                                    [Page 39]
=0C

------=_NextPart_000_0E00_01C4BDF2.F8398130
Content-Type: text/plain;
	name="draft-ietf-ccamp-gmpls-te-mib-06.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ccamp-gmpls-te-mib-06.txt"

CCAMP Working Group                                Thomas D. Nadeau, Ed.
Internet Draft                                       Cisco Systems, Inc.
Proposed Status: Standards Track
Expires: April 2005                                   Adrian Farrel, Ed.
                                                      Old Dog Consulting

                                                            October 2004

      Generalized Multiprotocol Label Switching (GMPLS) Traffic
               Engineering Management Information Base

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

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

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

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for Generalized
   Multiprotocol Label Switching (GMPLS) based traffic engineering.

Nadeau and Farrel (Editors)                                     [Page 1]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

Table of Contents

   1. Introduction ........................................... 2
   1.1. Migration Strategy ................................... 3
   2. Terminology ............................................ 3
   3. The SNMP Management Framework .......................... 3
   4. Outline ................................................ 4
   4.1. Summary of GMPLS Traffic Engineering MIB Module ...... 4
   5. Brief Description of GMPLS TE MIB Objects .............. 4
   5.1. gmplsTunnelTable ..................................... 4
   5.2. gmplsTunnelHopTable .................................. 5
   5.3. gmplsTunnelARHopTable ................................ 5
   5.4. gmplsTunnelCHopTable ................................. 5
   5.5. gmplsTunnelErrorTable ................................ 5
   5.6. gmplsTunnelReversePerfTable .......................... 5
   6. Cross-referencing to the mplsLabelTable ................ 6
   7. Example of GMPLS Tunnel Setup .......................... 6
   8. GMPLS Traffic Engineering MIB Definitions ............. 10
   9. Security Considerations ............................... 43
   10. Acknowledgments ...................................... 44
   11. IANA Considerations .................................. 44
   11.1. IANA Considerations for GMPLS-TE-STD-MIB ........... 44
   12. References ........................................... 45
   12.1. Normative Refenerces ............................... 45
   12.2. Informational References ........................... 46
   13. Authors' Addresses ................................... 47
   14. Full Copyright Statement ............................. 48
   15. Intellectual Property Notice ......................... 48

1. Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for modeling
   Generalized Multiprotocol Label Switching (GMPLS) [GMPLSArch] based
   traffic engineering. The tables and objects defined in this document
   extend those defined in the equivalent document for MPLS traffic
   engineering [RFC3812], and management of GMPLS traffic engineering is
   built on management of MPLS traffic engineering.

   This MIB module should be used in conjunction with the companion
   document [GMPLSLSRMIB] for GMPLS based traffic engineering
   configuration and management.

   Comments should be made direct to the CCAMP mailing list at
   [email-masked].

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

Nadeau and Farrel (Editors)                                     [Page 2]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

1.1. Migration Strategy

   This MIB module extends the traffic engineering MIB module defined
   for use with MPLS [RFC3812]. It provides additions for support of
   GMPLS tunnels.

   The companion document for modeling and managing GMPLS based LSRs
   [GMPLSLSRMIB] extends MPLS LSR MIB [RFC3813] with the same
   intentions.

   Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811]
   and [GMPLSTCMIB].

2. Terminology

   This document uses terminology from the MPLS architecture document
   [RFC3031], from the GMPLS architecture document [GMPLSArch], and from
   the MPLS Traffic Engineering MIB [RFC3812]. Some frequently used
   terms are described next.

   An explicitly routed LSP (ERLSP) is referred to as a GMPLS tunnel. It
   consists of in-segment(s) and/or out-segment(s) at the egress/ingress
   LSRs, each segment being associated with one GMPLS enabled interface.
   These are also referred to as tunnel segments.

   Additionally, at an intermediate LSR, we model a connection as
   consisting of one or more in-segments and/or one or more
   out-segments. The binding or interconnection between in-segments and
   out-segments in performed using a cross-connect.

   These segment and cross-connect objects are defined in the MPLS Label
   Switch Router MIB [RFC3813], but see also the GMPLS Label Switch
   Router MIB [GMPLSLSRMIB] for the GMPLS-specific extensions to these
   objects.

3. The SNMP Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

Nadeau and Farrel (Editors)                                     [Page 3]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

4. Outline

   Support for GMPLS traffic-engineered tunnels requires the following
   configuration.

   - Setting up tunnels with appropriate MPLS configuration parameters
     using [RFC3812].
   - Extending the tunnels with GMPLS configuration parameters.
   - Configuring tunnel loose and strict source routed hops.

   These actions may need to be accompanied with corresponding actions
   using [RFC3813] and [GMPLSLSRMIB] to establish and configure tunnel
   segments, if this is done manually. Also, the in-segment and
   out-segment performance tables, mplsInSegmentPerfTable and
   mplsOutSegmentPerfTable [RFC3813], should be used to determine
   performance of the tunnels and tunnel segments although it should be
   noted that those tables may not be appropriate for measuring
   performance on some types of GMPLS links.

4.1. Summary of GMPLS Traffic Engineering MIB Module

   The MIB objects for performing the actions listed above that cannot
   be performed solely using the MIB objects defined in [RFC3812]
   consist of the following tables.

   - Tunnel Table (gmplsTunnelTable) for providing GMPLS-specific
     tunnel configuration parameters.
   - Tunnel specified, actual, and computed hop tables
     (gmplsTunnelHopTable, gmplsTunnelARHopTable, and
     gmplsTunnelCHopTable) for providing additional configuration of
     strict and loose source routed tunnel hops.
   - Performance and error reporting tables (gmplsTunnelReversePerfTable
     and gmplsTunnelErrorTable).

   These tables are described in the subsequent sections.

   Additionally, this MIB module contains a new Notification.

   - The GMPLS Tunnel Down Notification (gmplsTunnelDown) is intended to
     be used in place of the mplsTunnelDown Notification defined in
     [RFC3812]. As well as indicating that a tunnel has transitioned to
     operational down state, this new Notificaiton indicates the cause
     of the failure.

5. Brief Description of GMPLS TE MIB Objects

   The objects described in this section support the functionality
   described in [RFC3473] and [RFC3472] for GMPLS tunnels.
   The tables support both manually configured and signaled tunnels.

Nadeau and Farrel (Editors)                                     [Page 4]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

5.1. gmplsTunnelTable

   The gmplsTunnelTable extends the MPLS traffic engineering MIB module
   to allow GMPLS tunnels to be created between an LSR and a remote
   endpoint, and existing GMPLS tunnels to be reconfigured or removed.

   Note that we only support point-to-point tunnel segments, although
   multi-point-to-point and point-to-multi-point connections are
   supported by an LSR acting as a cross-connect.

   Each tunnel can thus have one out-segment originating at an LSR
   and/or one in-segment terminating at that LSR.

5.2. gmplsTunnelHopTable

   The gmplsTunnelHopTable is used to indicate additional parameters for
   the hops, strict or loose, of a GMPLS tunnel defined in
   gmplsTunnelTable, when it is established using signaling.  Multiple
   tunnels may share hops by pointing to the same entry in this table.

5.3. gmplsTunnelARHopTable

   The gmplsTunnelARHopTable is used to indicate the actual hops
   traversed by a tunnel as reported by the signaling protocol after the
   tunnel is setup.  The support of this table is optional since not all
   GMPLS signaling protocols support this feature.

5.4. gmplsTunnelCHoptable

   The gmplsTunnelCHopTable lists the actual hops computed by a
   constraint-based routing algorithm based on the gmplsTunnelHopTable.
   The support of this table is optional since not all implementations
   support computation of hop lists using a constraint-based routing
   protocol.

5.5. gmplsTunnelErrorTable

   The gmplsTunnelErrorTable provides access to information about the
   last error that occurred on each tunnel known about by the MIB.  It
   indicates the nature of the error, when and how it was reported and
   can give recovery advice through a display string.

5.6. gmplsTunnelReversePerfTable

   gmplsTunnelReversePerfTable provides additional counters to measure
   the performance of bidirectional GMPLS tunnels in which packets are
   visible. It supplements the counters in mplsTunnelPerfTable and
   augments gmplsTunnelTable.

   Note that not all counters may be appropriate or available for some
   types of tunnel.

Nadeau and Farrel (Editors)                                     [Page 5]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

6. Cross-referencing to the gmplsLabelTable

   The gmplsLabelTable is found in a MIB module in [GMPLSLSRMIB] and
   provides a way to model labels in a GMPLS system where labels might
   not be simple 32 bit integers.

   The hop tables in this document (gmplsHopTable, gmplsCHopTable and
   gmplsARHopTable) and the segment tables in the [RFC3813]
   (mplsInSegmentTable and mplsOutSegmentTable) contain objects with
   syntax MplsLabel.

   MplsLabel (defined in [RFC3811]) is a 32-bit integer that is capable
   of representing any MPLS label and most GMPLS labels. However, some
   GMPLS labels are larger than 32 bits and may be of arbitrary length.
   Further, some labels that may be safely encoded in 32 bits are
   constructed from multiple sub-fields. Additionally, some GMPLS
   technologies support the concatenation of individual labels to
   represent a data flow carried as multiple sub-flows.

   These GMPLS cases require that something other than a simple 32-bit
   integer is made available to represent the labels. This is achieved
   through the gmplsLabelTable contained in [GMPLSLSRMIB].

   The tables in this document and [RFC3813] that include objects with
   syntax MplsLabel also include companion objects that are row
   pointers. If the row pointer is set to zeroDotZero (0.0) then object
   of syntax MplsLabel contains the label encoded as a 32-bit integer.
   But otherwise the row pointer indicates a row in another MIB table
   that includes the label. In these cases, the row pointer may indicate
   a row in the gmplsLabelTable.

   This provides both a good way to support legacy systems that
   implement the previous version of this MIB module [RFC3812], and a
   significant simplification in GMPLS systems that are limited to a
   single, simple label type.

   Note that gmplsLabelTable supports concatenated labels through the
   use of a label sub-index (gmplsLabelSubindex).

7. Example of GMPLS Tunnel Setup

   This section contains an example of which MIB objects should be
   modified to create a GMPLS tunnel.  This example shows a best effort,
   loosely routed, bidirectional traffic engineered tunnel, which spans
   two hops of a simple network, uses Generalized Label requests with
   Lambda encoding, has label recording and shared link layer
   protection.  Note that these objects should be created on the
   "head-end" LSR.

Nadeau and Farrel (Editors)                                     [Page 6]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   First in the mplsTunnelTable:
   {
     mplsTunnelIndex                =3D 1,
     mplsTunnelInstance             =3D 1,
     mplsTunnelIngressLSRId         =3D 123.123.125.1,
     mplsTunnelEgressLSRId          =3D 123.123.126.1,
     mplsTunnelName                 =3D "My first tunnel",
     mplsTunnelDescr                =3D "Here to there and back again",
     mplsTunnelIsIf                 =3D true (1),
     mplsTunnelXCPointer            =3D mplsXCIndex.3.0.0.12,
     mplsTunnelSignallingProto      =3D none (1),
     mplsTunnelSetupPrio            =3D 0,
     mplsTunnelHoldingPrio          =3D 0,
     mplsTunnelSessionAttributes    =3D recordRoute (4),
     mplsTunnelOwner                =3D snmp (2),
     mplsTunnelLocalProtectInUse    =3D false (0),
     mplsTunnelResourcePointer      =3D mplsTunnelResourceIndex.6,
     mplsTunnelInstancePriority     =3D 1,
     mplsTunnelHopTableIndex        =3D 1,

     mplsTunnelPrimaryInstance      =3D 0,
     mplsTunnelIncludeAnyAffinity   =3D 0,
     mplsTunnelIncludeAllAffinity   =3D 0,
     mplsTunnelExcludeAnyAffinity   =3D 0,
     mplsTunnelPathInUse            =3D 1,
     mplsTunnelRole                 =3D head(1),
     mplsTunnelRowStatus            =3D createAndWait (5),
   }

   In gmplsTunnelTable(1,1,123.123.125.1,123.123.126.1):
   {
     gmplsTunnelUnnumIf             =3D true (1),
     gmplsTunnelAttributes          =3D labelRecordingRequired (1),
     gmplsTunnelLSPEncoding         =3D tunnelLspLambda (8),
     gmplsTunnelSwitchingType       =3D lsc (150),
     gmplsTunnelLinkProtection      =3D shared (2),
     gmplsTunnelGPid                =3D lambda (37),
     gmplsTunnelSecondary           =3D false(0),
     gmplsTunnelDirection           =3D bidirectional (1)
     gmplsTunnelPathComp            =3D explicit(2),
     gmplsTunnelUpNotRecip          =3D 0x7B7B7D01,
     gmplsTunnelDownNotRecip        =3D 0x00000000,
     gmplsTunnelAdminStatusFlags    =3D 0,
     gmplsTunnelExtraParamsPtr      =3D 0.0
   }

   Entries in the mplsTunnelResourceTable, mplsTunnelHopTable and
   gmplsTunnelHopTable are created and activated at this time.

Nadeau and Farrel (Editors)                                     [Page 7]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   In mplsTunnelResourceTable:
   {
     mplsTunnelResourceIndex        =3D 6,
     mplsTunnelResourceMaxRate      =3D 0,
     mplsTunnelResourceMeanRate     =3D 0,
     mplsTunnelResourceMaxBurstSize =3D 0,
     mplsTunnelResourceRowStatus    =3D createAndGo (4)
   }

   The next two instances of mplsTunnelHopEntry are used to denote the
   hops this tunnel will take across the network.

   The following denotes the beginning of the network, or the first hop.
   We have used the fictitious LSR identified by "123.123.125.1" as our
   example head-end router.

   In mplsTunnelHopTable:
   {
     mplsTunnelHopListIndex         =3D 1,
     mplsTunnelPathOptionIndex      =3D 1,
     mplsTunnelHopIndex             =3D 1,
     mplsTunnelHopAddrType          =3D ipV4 (1),
     mplsTunnelHopIpv4Addr          =3D 123.123.125.1,
     mplsTunnelHopIpv4PrefixLen     =3D 9,
     mplsTunnelHopType              =3D strict (1),
     mplsTunnelHopRowStatus         =3D createAndWait (5),
   }

   The following denotes the end of the network, or the last hop in our
   example. We have used the fictitious LSR identified by
   "123.123.126.1" as our end router.

   In mplsTunnelHopTable:
   {
     mplsTunnelHopListIndex         =3D 1,
     mplsTunnelPathOptionIndex      =3D 1,
     mplsTunnelHopIndex             =3D 2,
     mplsTunnelHopAddrType          =3D ipV4 (1),
     mplsTunnelHopIpv4Addr          =3D 123.123.126.1,
     mplsTunnelHopIpv4PrefixLen     =3D 9,
     mplsTunnelHopType              =3D loose (2),
     mplsTunnelHopRowStatus         =3D createAndGo (4)
   }

   Now an associated entry in the gmplsTunnelHopTable is created to
   provide additional GMPLS hop configuration indicating that the first
   hop is an unnumbered link using explicit forward and reverse labels.
   An entry in the gmplsLabelTable is created first to include the
   explicit label.

Nadeau and Farrel (Editors)                                     [Page 8]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   In gmplsLabelTable:
   {
     gmplsLabelInterface            =3D 2,
     gmplsLabelIndex                =3D 1,
     gmplsLabelSubindex             =3D 0,
     gmplsLabelType                 =3D =
gmplsFreeformGeneralizedLabel(3),
     gmplsLabelFreeform             =3D 0xFEDCBA9876543210
     gmplsLabelRowStatus            =3D createAndGo(4)
   }

   In gmplsTunnelHopTable(1,1,1):
   {
     gmplsTunnelHopLabelStatuses    =3D forwardPresent(0)
                                                +reversePresent(1),
     gmplsTunnelHopExpLabelPtr      =3D gmplsLabelTable (2, 1, 0)
     gmplsTunnelHopExpRvrsLabelPtr  =3D gmplsLabelTable (2, 1, 0)
   }

   The first hop is now activated:

   In mplsTunnelHopTable(1,1,1):
   {
     mplsTunnelHopRowStatus         =3D active (1)
   }

   No gmplsTunnelHopEntry is created for the second hop as it contains
   no special GMPLS features.

   Finally the mplsTunnelEntry is activated:

   In mplsTunnelTable(1,1,123.123.125.1,123.123.126.1)
   {
     mplsTunnelRowStatus            =3D active(1)
   }

Nadeau and Farrel (Editors)                                     [Page 9]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

8. GMPLS Traffic Engineering MIB Definitions

   GMPLS-TE-STD-MIB DEFINITIONS ::=3D BEGIN

   IMPORTS
     MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
     Integer32, Unsigned32, Counter32,
     Counter64, IpAddress, zeroDotZero
       FROM SNMPv2-SMI                                   -- [RFC2578]
     MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
       FROM SNMPv2-CONF                                  -- [RFC2580]
     TruthValue, TimeStamp, DisplayString, RowPointer
       FROM SNMPv2-TC                                    -- [RFC2579]
     InetAddress
       FROM INET-ADDRESS-MIB                             -- [RFC3291]
     mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId,
     mplsTunnelEgressLSRId, mplsTunnelHopListIndex,
     mplsTunnelHopPathOptionIndex, mplsTunnelHopIndex,
     mplsTunnelARHopListIndex, mplsTunnelARHopIndex,
     mplsTunnelCHopListIndex, mplsTunnelCHopIndex,
     mplsTunnelEntry,
     mplsTunnelAdminStatus, mplsTunnelOperStatus
       FROM MPLS-TE-STD-MIB                              -- [RFC3812]
     mplsStdMIB
       FROM MPLS-TC-STD-MIB                              -- [RFC3811]
   ;

   gmplsTeStdMIB MODULE-IDENTITY
         LAST-UPDATED
           "200410080001Z" -- 8 October 2004 00:00:01 GMT
         ORGANIZATION
           "Common Control And Measurement Plane (CCAMP) Working Group"
         CONTACT-INFO
           "       Thomas D. Nadeau
                   Cisco Systems, Inc.
            Email: [email-masked]
                   Adrian Farrel

                   Old Dog Consulting
            Email: [email-masked]

            Comments about this document should be emailed direct to the
            CCAMP working group mailing list at [email-masked]"

         DESCRIPTION
           "Copyright (C) The Internet Society (2004). The
            initial version of this MIB module was published
            in RFC xxxx. For full legal notices see the RFC
            itself or see: http://www.ietf.org/copyrights/ianamib.html

Nadeau and Farrel (Editors)                                    [Page 10]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

            This MIB module contains managed object definitions
            for GMPLS Traffic Engineering (TE) as defined in:
            1. Generalized Multi-Protocol Label Switching (GMPLS)
               Signaling Functional Description, Berger, L. (Editor),
               RFC 3471, January 2003.
            2. Generalized MPLS Signaling - RSVP-TE Extensions, Berger,
               L. (Editor), RFC 3473, January 2003."

   -- Revision history.
         REVISION
           "200410080001Z" -- 8 October 2004 00:00:01 GMT
         DESCRIPTION
           "Initial version issued as part of RFC XXXX."
   ::=3D { mplsStdMIB xx }

   -- Top level components of this MIB.

   -- Notifications
   gmplsTeNotifications OBJECT IDENTIFIER ::=3D { gmplsTeStdMIB 0 }
   -- tables, scalars
   gmplsTeScalars OBJECT IDENTIFIER ::=3D { gmplsTeStdMIB 1 }
   gmplsTeObjects OBJECT IDENTIFIER ::=3D { gmplsTeStdMIB 2 }
   -- conformance
   gmplsTeConformance OBJECT IDENTIFIER ::=3D { gmplsTeStdMIB 3 }

   -- GMPLS Tunnel scalars.

   gmplsTunnelsConfigured OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "The number of GMPLS tunnels configured on this device. A GMPLS
        tunnel is considered configured if an entry for the tunnel
        exists in the gmplsTunnelTable and the associated
        mplsTunnelRowStatus is active(1)."
   ::=3D { gmplsTeScalars 1 }

   gmplsTunnelsActive OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "The number of GMPLS tunnels active on this device. A GMPLS
        tunnel is considered active if there is an entry in the
        gmplsTunnelTable and the associated mplsTunnelOperStatus
        for the tunnel is up(1)."
   ::=3D { gmplsTeScalars 2 }

   -- End of GMPLS Tunnel scalars.

Nadeau and Farrel (Editors)                                    [Page 11]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   -- GMPLS tunnel table.

   gmplsTunnelTable OBJECT-TYPE
     SYNTAX  SEQUENCE OF GmplsTunnelEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "The gmplsTunnelTable 'extends' the mplsTunnelTable.
        It allows GMPLS tunnels to be created between an LSR
        and a remote endpoint, and existing tunnels to be
        reconfigured or removed.

        Note that only point-to-point tunnel segments are
        supported, although multi-point-to-point and
        point-to-multi-point connections are supported by an LSR
        acting as a cross-connect. Each tunnel can thus have
        one out-segment originating at this LSR and/or one
        in-segment terminating at this LSR.

        The row status of an entry in this table is
        controlled by mplsTunnelRowStatus in the
        corresponding entry in mplsTunnelTable. That is,
        it is not permitted to create a row in this table,
        nor to modify an existing row, when the
        corresponding mplsTunnelRowStatus has value
        active(1).

        The exception to this rule is the gmplsTunnelAdminStatusFlags
        object, which can be modified whilst the tunnel is active."
   ::=3D { gmplsTeObjects 1 }

   gmplsTunnelEntry OBJECT-TYPE
     SYNTAX  GmplsTunnelEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "An entry in this table in association with the
        corresponding entry in the mplsTunnelTable
        represents a GMPLS tunnel.

        An entry can be created by a network administrator
        or by an SNMP agent as instructed by a signaling
        protocol."
     INDEX {
       mplsTunnelIndex,
       mplsTunnelInstance,
       mplsTunnelIngressLSRId,
       mplsTunnelEgressLSRId
     }
   ::=3D { gmplsTunnelTable 1 }

Nadeau and Farrel (Editors)                                    [Page 12]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   GmplsTunnelEntry ::=3D SEQUENCE {
     gmplsTunnelUnnumIf            TruthValue,
     gmplsTunnelAttributes         BITS,
     gmplsTunnelLSPEncoding        Integer32,
     gmplsTunnelSwitchingType      Integer32,
     gmplsTunnelLinkProtection     BITS,
     gmplsTunnelGPid               Integer32,
     gmplsTunnelSecondary          TruthValue,
     gmplsTunnelDirection          INTEGER,
     gmplsTunnelPathComp           INTEGER,
     gmplsTunnelUpNotRecip         IpAddress,
     gmplsTunnelDownNotRecip       IpAddress,
     gmplsTunnelAdminStatusFlags   BITS,
     gmplsTunnelExtraParamsPtr     RowPointer
   }

   gmplsTunnelUnnumIf OBJECT-TYPE
     SYNTAX  TruthValue
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "Denotes whether or not this tunnel corresponds to an
        unnumbered interface represented in the interfaces
        group table.

        This object is only used if mplsTunnelIsIf is set to
        'true'.

        If both this object and the mplsTunnelIsIf object
        are set to 'true', the originating LSR adds an
        LSP_TUNNEL_INTERFACE_ID object to the outgoing Path
        message.

        This object contains information that is only used
        by the terminating LSR."
     REFERENCE
       "Signalling Unnumbered Links in RSVP-TE, Kompella, K.
        and Rekhter, Y., RFC 3477, January 2003."
     DEFVAL  { false }
   ::=3D { gmplsTunnelEntry 1 }

   gmplsTunnelAttributes OBJECT-TYPE
     SYNTAX BITS {
       labelRecordingDesired (0)
     }
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "This bitmask indicates optional parameters for this
        tunnel. These bits should be taken in addition to
        those defined in mplsTunnelSessionAttributes in

Nadeau and Farrel (Editors)                                    [Page 13]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

        order to determine the full set of options to be
        signaled (for example SESSION_ATTRIBUTES flags in
        RSVP-TE).
        The following describes these bitfields:

        labelRecordingDesired
          This flag indicates that label information should be
          included when doing a route record.  This bit is not
          valid unless the recordRoute bit is set."

     REFERENCE
       "RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche
        et al, RFC 3209, December 2001."
     DEFVAL  { { } }
   ::=3D { gmplsTunnelEntry 2 }

   gmplsTunnelLSPEncoding OBJECT-TYPE
     SYNTAX  Integer32 (0..255)
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "This object indicates the encoding of the LSP being requested.

        A value of zero indicates that GMPLS signaling is
        not in use. Some objects in this MIB module may be
        of use for MPLS signaling extensions that do not use
        GMPLS signaling. By setting this object to zero, an
        application may indicate that only those objects
        meaningful in MPLS should be examined.
        The values to use are currently defined in
        Generalized Multi-Protocol Label Switching (GMPLS)
        Signaling Functional Description, RFC 3471. Further
        values may be defined in future RFCs.
          tunnelLspPacket (1),
          tunnelLspEthernet (2),
          tunnelLspAnsiEtsiPdh (3),
          -- the value 4 is deprecated
          tunnelLspSdhSonet (5),
          -- the value 6 is deprecated
          tunnelLspDigitalWrapper (7),
          tunnelLspLambda (8),
          tunnelLspFiber (9),
          -- the value 10 is deprecated
          tunnelLspFiberChannel (11),
          tunnelDigitalPath (12),
          tunnelOpticalChannel (13)"
     REFERENCE
       "1. Berger, L., et al., Generalized Multi-Protocol
           Label Switching (GMPLS) Signaling Functional
           Description, RFC 3471, January 2003.

Nadeau and Farrel (Editors)                                    [Page 14]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

        2. D. Papadimitriou (Editor), Generalized MPLS
           Signalling Extensions for G.709 Optical Transport
           Networks Control, draft-ietf-ccamp-gmpls-g709-06.txt,
           January 2004, work in progress."
     DEFVAL  { 0 }
   ::=3D { gmplsTunnelEntry 3 }

   gmplsTunnelSwitchingType OBJECT-TYPE
     SYNTAX  Integer32 (0..255)
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "Indicates the type of switching that should be performed on
        a particular link. This field is needed for links that
        advertise more than one type of switching capability. Values
        of this object are as the Switching Capability field defined
        in Internet Draft OSPF Extensions in Support of Generalized
        MPLS. Further values may be defined in future RFCs.
          unknown (0),
          psc1 (1),
          psc2 (2),
          psc3 (3),
          psc4 (4),
          l2sc (51),
          tdm (100),
          lsc (150),
          fsc (200)
        This object is only meaningful if
        gmplsTunnelLSPEncoding is not set to 0."
     REFERENCE
       "1. Kompella, K., Rekhter, Y. (Editors), Routing Extensions in
           Support of Generalized Multi-Protocol Label Switching,
           draft-ietf-ccamp-gmpls-routing-09.txt, October 2003, work in
           progress.
        2. Berger, L., et al., Generalized Multi-Protocol
           Label Switching (GMPLS) Signaling Functional
           Description, RFC 3471, January 2003."
     DEFVAL  { 0 }
   ::=3D { gmplsTunnelEntry 4 }

   gmplsTunnelLinkProtection OBJECT-TYPE
     SYNTAX  BITS {
       extraTraffic(0),
       unprotected(1),
       shared (2),
       dedicatedOneToOne (3),
       dedicatedOnePlusOne(4),
       enhanced(5)
     }
     MAX-ACCESS read-create
     STATUS  current

Nadeau and Farrel (Editors)                                    [Page 15]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

     DESCRIPTION
       "This bitmask indicates the level of link protection
        required. A value of zero (no bits set) indicates
        that any protection may be used.
        The following describes these bitfields:

        extraTraffic
          Indicates that the LSP should use links that are
          protecting other (primary) traffic.  Such LSPs may
          be preempted when the links carrying the (primary)
          traffic being protected fail.

        unprotected
          Indicates that the LSP should not use any link layer
          protection.

        shared
          Indicates that a shared link layer protection scheme,
          such as 1:N protection, should be used to support the LSP.

        dedicatedOneToOne
          Indicates that a dedicated link layer protection scheme,
          i.e., 1:1 protection, should be used to support the LSP.

        dedicatedOnePlusOne
          Indicates that a dedicated link layer protection scheme,
          i.e., 1+1 protection, should be used to support the LSP.

        enhanced
          Indicates that a protection scheme that is more reliable than
          Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING.

        This object is only meaningful if gmplsTunnelLSPEncoding is
        not set to 0."
     REFERENCE
        "Berger, L., et al., Generalized Multi-Protocol
         Label Switching (GMPLS) Signaling Functional
         Description, RFC 3471, January 2003."
     DEFVAL  { { } }
   ::=3D { gmplsTunnelEntry 5 }

   gmplsTunnelGPid OBJECT-TYPE
     SYNTAX  Integer32 (0..65535)
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "This object indicates the payload carried by the
        LSP. It is only required when GMPLS will be used for
        this LSP.

Nadeau and Farrel (Editors)                                    [Page 16]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

        The values to use are currently defined in
        Generalized Multi-Protocol Label Switching (GMPLS)
        Signaling Functional Description, RFC 3471. Further
        values may be defined in future RFCs.

          unknown(0),
          asynchE4(5),
          asynchDS3T3(6),
          asynchE3(7),
          bitsynchE3(8),
          bytesynchE3(9),
          asynchDS2T2(10),
          bitsynchDS2T2(11),
          asynchE1(13),
          bytesynchE1(14),
          bytesynch31ByDS0(15),
          asynchDS1T1(16),
          bitsynchDS1T1(17),
          bytesynchDS1T1(18),
          VC11VC12(19),
          ds1SFAsynch(22),
          ds1ESFAsynch(23),
          ds3M23Asynch(24),
          ds3CBitParityAsynch(25),
          vtLovc(26),
          stsSpeHovc(27),
          posNoScramble16BitCrc(28),
          posNoScramble32BitCrc(29),
          posScramble16BitCrc(30),
          posScramble32BitCrc(31),
          atm(32)
          ethernet(33),
          sdhSonet(34),
          digitalwrapper(36),
          lambda(37),
          ansiEtsiPdh (38),
          lapsSdh (40),
          fddi (41),
          dqdb (42),
          fiberChannel3 (43),
          hdlc (44),
          ethernetV2DixOnly (45),
          ethernet802dot3Only (46),
          g709ODUj (47),
          g709OTUk (48),
          g709CBRorCBRa (49),
          g709CBRb (50),
          g709BSOT (51),
          g709BSNT (52),
          gfpIPorPPP (53),
          gfpEthernetMAC (54),

Nadeau and Farrel (Editors)                                    [Page 17]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

          gfpEthernetPHY (55),
          g709ESCON (56),
          g709FICON (57),
          g709FiberChannel (58)

        This object is only meaningful if
        gmplsTunnelLSPEncoding is not set to 0."
     REFERENCE
       "1. Berger, L., et al., Generalized Multi-Protocol
           Label Switching (GMPLS) Signaling Functional
           Description, RFC 3471, January 2003.
        2. D. Papadimitriou (Editor), Generalized MPLS
           Signalling Extensions for G.709 Optical Transport
           Networks Control, draft-ietf-ccamp-gmpls-g709-06.txt,
           January 2004, work in progress."
     DEFVAL  { 0 }
   ::=3D { gmplsTunnelEntry 6 }

   gmplsTunnelSecondary OBJECT-TYPE
     SYNTAX  TruthValue
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "Indicates that the requested LSP is a secondary LSP.
        This object is only meaningful if
        gmplsTunnelLSPEncoding is not set to 0."
     REFERENCE
       "Berger, L., et al., Generalized Multi-Protocol
        Label Switching (GMPLS) Signaling Functional
        Description, RFC 3471, January 2003."
     DEFVAL  { false }
   ::=3D { gmplsTunnelEntry 7 }

   gmplsTunnelDirection OBJECT-TYPE
     SYNTAX  INTEGER {
       forward (0),
       bidirectional (1)
     }
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "Whether this tunnel carries forward data only (is
        unidirectional) or is bidirectional.
        Values of this object other than 'forward' are meaningful
        only if gmplsTunnelLSPEncoding is not set to 0."
     DEFVAL { forward }
   ::=3D { gmplsTunnelEntry 8 }

Nadeau and Farrel (Editors)                                    [Page 18]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   gmplsTunnelPathComp OBJECT-TYPE
     SYNTAX  INTEGER {
       dynamicFull(1),   -- CSPF fully computed
       explicit(2),      -- fully specified path
       dynamicPartial(3) -- CSPF partially computed
     }
     MAX-ACCESS read-create
     STATUS current
     DESCRIPTION
       "This value instructs the source node on how to perform
        path computation on the explicit route specified by the
        associated entries in the gmplsTunnelHopTable.

        dynamicFull
          The user specifies at least the source and
          destination of the path and expects that the CSPF
          will calculate the remainder of the path.
        explicit
          The user specifies the entire path for the tunnel to
          take. This path may contain strict or loose hops.
          Evaluation of the explicit route will be performed
          hop by hop through the network.
        dynamicPartial
          The user specifies at least the source and
          destination of the path and expects that the CSPF
          will calculate the remainder of the path. The path
          computed by CSPF is allowed to be only partially
          computed allowing the remainder of the path to be
          filled in across the network.

        This object deprecates mplsTunnelHopEntryPathComp."
     DEFVAL { dynamicFull }
   ::=3D { gmplsTunnelEntry 9 }

   gmplsTunnelUpNotRecip OBJECT-TYPE
     SYNTAX  IpAddress
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "Indicates the address of the upstream recipient for Notify
        messages relating to this tunnel.

        This object is only valid when signaling a tunnel using
        RSVP.  It is also not valid at the tail end of the tunnel.
        If set to 0, no Notify Request object will be included in
        outgoing Path messages."
     REFERENCE
       "Generalized MPLS Signaling - RSVP-TE Extensions, Berger,
        L. (Editor), RFC 3473, January 2003."
     DEFVAL { '00000000'H } -- 0.0.0.0
   ::=3D { gmplsTunnelEntry 10 }

Nadeau and Farrel (Editors)                                    [Page 19]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   gmplsTunnelDownNotRecip OBJECT-TYPE
     SYNTAX  IpAddress
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "Indicates the address of the upstream recipient for Notify
        messages relating to this tunnel.

        This object is only valid when signaling a tunnel using
        RSVP.  It is also not valid at the head end of the tunnel.

        If set to 0, no Notify Request object will be included in
        outgoing Resv messages."

     REFERENCE
       "Generalized MPLS Signaling - RSVP-TE Extensions, Berger,
        L. (Editor), RFC 3473, January 2003."
     DEFVAL { '00000000'H } -- 0.0.0.0
   ::=3D { gmplsTunnelEntry 11 }

   gmplsTunnelAdminStatusFlags OBJECT-TYPE
      SYNTAX      BITS {
             delInProgress (0),
             adminDown (1),
             testing (2),
             reflect (31)
             }
      MAX-ACCESS   read-create
      STATUS       current
      DESCRIPTION
        "Determines the setting of the Admin Status flags in the
         Admin Status object or TLV, as described in
         RFC 3471.  Setting this field to a non-zero value will
         result in the inclusion of the admin status object on
         signaling messages.

         This value of this object can be modified when the
         corresponding mplsTunnelRowStatus and mplsTunnelAdminStatus
         is active(1).  By doing so, a new signaling message will be
         triggered including the requested Admin Status object or
         TLV."
     REFERENCE
       "Berger, L., et al., Generalized Multi-Protocol
        Label Switching (GMPLS) Signaling Functional
        Description, RFC 3471, January 2003."
     DEFVAL  { { } }
     ::=3D { gmplsTunnelEntry 12 }

   gmplsTunnelExtraParamsPtr  OBJECT-TYPE
     SYNTAX       RowPointer
     MAX-ACCESS   read-create

Nadeau and Farrel (Editors)                                    [Page 20]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

     STATUS       current
     DESCRIPTION
       "Some Tunnels will run over transports that can usefully support
        technology-specific additional parameters (for example, SONET
        resource usage). Such parameters can be supplied in an external
        table and referenced from here.

        A value of zeroDotzero in this attribute indicates that there
        is no such additional information."
     DEFVAL  { zeroDotZero }
     ::=3D { gmplsTunnelEntry 13 }

   -- End of gmplsTunnelTable

   -- Begin gmplsTunnelHopTable

   gmplsTunnelHopTable  OBJECT-TYPE
     SYNTAX  SEQUENCE OF GmplsTunnelHopEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "The gmplsTunnelHopTable 'extends' the mplsTunnelHopTable.
        It is used to indicate the explicit labels to be used in an
        explicit path for a GMPLS tunnel defined in mplsTunnelTable
        and gmplsTunnelTable, when it is established using signaling.
        It does not insert new hops, but does define new values for
        hops defined in mplsTunnelHopTable.

        Each row in this table is indexed by the same
        indexes as mplsTunnelHopTable. It is acceptable for
        some rows in mplsTunnelHopTable to have
        corresponding entries in this table and some to have
        no corresponding entry in this table.

        The storage type for an entry in this table is
        inherited from mplsTunnelHopStorageType in the
        corresponding entry in mplsTunnelHopTable.

        The row status of an entry in this table is
        controlled by mplsTunnelHopRowStatus in the
        corresponding entry in mplsTunnelHopTable. That is,
        it is not permitted to create a row in this table,
        nor to modify an existing row, when the
        corresponding mplsTunnelHopRowStatus has value
        active(1)."
     REFERENCE
       "Generalized MPLS Signaling - RSVP-TE Extensions, Berger,
        L. (Editor), RFC 3473, January 2003."
   ::=3D { gmplsTeObjects 2 }

Nadeau and Farrel (Editors)                                    [Page 21]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   gmplsTunnelHopEntry  OBJECT-TYPE
     SYNTAX  GmplsTunnelHopEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "An entry in this table represents additions to a
        tunnel hop defined in mplsTunnelHopEntry. At an
        ingress to a tunnel an entry in this table is
        created by a network administrator for an ERLSP to
        be set up by a signaling protocol. At transit and
        egress nodes an entry in this table may be used to
        represent the explicit path instructions received
        using the signaling protocol."
     INDEX {
       mplsTunnelHopListIndex,
       mplsTunnelHopPathOptionIndex,
       mplsTunnelHopIndex
     }
   ::=3D { gmplsTunnelHopTable 1 }

   GmplsTunnelHopEntry ::=3D SEQUENCE {
     gmplsTunnelHopLabelStatuses     BITS,
     gmplsTunnelHopExpLabel          Unsigned32,
     gmplsTunnelHopExpLabelPtr       RowPointer,
     gmplsTunnelHopExpRvrsLabel      Unsigned32,
     gmplsTunnelHopExpRvrsLabelPtr   RowPointer
   }

   gmplsTunnelHopLabelStatuses OBJECT-TYPE
     SYNTAX  BITS {
       forwardPresent (0),
       reversePresent (1)
     }
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "This bitmask indicates the presence of labels
        indicated by the gmplsTunnelHopExpLabel or
        gmplsTunnelHopExpLabelPtr and
        gmplsTunnelHopExpRvrsLabel or gmplsTunnelHopExpRvrsLabel
        objects.

        For the Present bits, a set bit indicates that a
        label is present for this hop in the route. This
        allows zero to be a valid label value."
     DEFVAL  { { } }
   ::=3D { gmplsTunnelHopEntry 1 }

Nadeau and Farrel (Editors)                                    [Page 22]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   gmplsTunnelHopExpLabel OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "If gmplsTunnelHopLabelStatuses object indicates that a
        forward label is present and gmplsTunnelHopExpLabelPtr
        contains the value zeroDotZero, then the label to use on this
        hop is found in this object encoded within a 32-bit integer."
   ::=3D { gmplsTunnelHopEntry 2 }

   gmplsTunnelHopExpLabelPtr OBJECT-TYPE
     SYNTAX  RowPointer
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelHopLabelStatuses object indicates
        that a forward label is present, this object contains
        a pointer to a row in another MIB table (such as the
        gmplsLabelTable) that contains the label to use on
        this hop in the forward direction.
        If the gmplsTunnelHopLabelStatuses object indicates that
        a forward label is present and this object contains the
        value zeroDotZero, then the label to use on this hop is
        found in the gmplsTunnelHopExpLabel object."
     DEFVAL  { zeroDotZero }
   ::=3D { gmplsTunnelHopEntry 3 }

   gmplsTunnelHopExpRvrsLabel OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelHopLabelStatuses object indicates that a
        reverse label is present and gmplsTunnelHopExpRvrsLabelPtr
        contains the value zeroDotZero, then the label to use on
        this hop is found in this object encoded as a 32-bit integer."
   ::=3D { gmplsTunnelHopEntry 4 }

   gmplsTunnelHopExpRvrsLabelPtr OBJECT-TYPE
     SYNTAX  RowPointer
     MAX-ACCESS read-create
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelHopLabelStatuses object indicates
        that a reverse label is present, this object contains
        a pointer to a row in another MIB table (such as the
        gmplsLabelTable) that contains the label to use on
        this hop in the reverse direction.

Nadeau and Farrel (Editors)                                    [Page 23]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

        If the gmplsTunnelHopLabelStatuses object indicates that
        a reverse label is present and this object contains the
        value zeroDotZero, then the label to use on this hop is
        found in the gmplsTunnelHopExpRvrsLabel object."
     DEFVAL  { zeroDotZero }
   ::=3D { gmplsTunnelHopEntry 5 }

   -- End of gmplsTunnelHopTable

   -- Tunnel Actual Route Hop table.

   gmplsTunnelARHopTable  OBJECT-TYPE
     SYNTAX  SEQUENCE OF GmplsTunnelARHopEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "The gmplsTunnelARHopTable 'extends' the
        mplsTunnelARHopTable. It is used to indicate the
        labels currently in use for a GMPLS tunnel defined
        in mplsTunnelTable and gmplsTunnelTable, as reported
        by the signaling protocol. It does not insert new
        hops, but does define new values for hops defined in
        mplsTunnelARHopTable.

        Each row in this table is indexed by the same indexes as
        mplsTunnelARHopTable. It is acceptable for some rows in
        mplsTunnelARHopTable to have corresponding entries in this
        table and some to have no corresponding entry in this table.

        Note that since the information necessary to build
        entries within this table is not provided by some
        signaling protocols and might not be returned in all
        cases of other signaling protocols, implementation
        of this table and mplsTunnelARHopTable is optional.
        Furthermore, since the information in this table is
        actually provided by the signaling protocol after
        the path has been set-up, the entries in this table
        are provided only for observation, and hence, all
        variables in this table are accessible exclusively
        as read-only."
     REFERENCE
       "1. Extensions to RSVP for LSP Tunnels, Awduche et
           al, RFC 3209, December 2001
        2. Generalized MPLS Signaling - RSVP-TE Extensions, Berger,
           L. (Editor), RFC 3473, January 2003."
   ::=3D { gmplsTeObjects 3 }

   gmplsTunnelARHopEntry  OBJECT-TYPE
     SYNTAX  GmplsTunnelARHopEntry
     MAX-ACCESS not-accessible
     STATUS  current

Nadeau and Farrel (Editors)                                    [Page 24]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

     DESCRIPTION
       "An entry in this table represents additions to a
        tunnel hop visible in mplsTunnelARHopEntry. An entry
        is created by the signaling protocol for a signaled
        ERLSP set up by the signaling protocol.

        At any node on the LSP (ingress, transit or egress)
        Thus at this table and mplsTunnelARHopTable (if the
        tables are supported and if the signaling protocol
        is recording actual route information) contains the
        actual route of the whole tunnel. If the signaling
        protocol is not recording the actual route, this
        table MAY report the information from the
        gmplsTunnelHopTable or the gmplsTunnelCHopTable.

        Note that the recording of actual labels is distinct
        from the recording of the actual route in some
        signaling protocols. This feature is enabled using
        the gmplsTunnelAttributes object."
     INDEX {
       mplsTunnelARHopListIndex,
       mplsTunnelARHopIndex
     }
   ::=3D { gmplsTunnelARHopTable 1 }

   GmplsTunnelARHopEntry ::=3D SEQUENCE {
     gmplsTunnelARHopLabelStatuses     BITS,
     gmplsTunnelARHopExpLabel          Unsigned32,
     gmplsTunnelARHopExpLabelPtr       RowPointer,
     gmplsTunnelARHopExpRvrsLabel      Unsigned32,
     gmplsTunnelARHopExpRvrsLabelPtr   RowPointer,
     gmplsTunnelARHopProtection        BITS
   }

   gmplsTunnelARHopLabelStatuses OBJECT-TYPE
     SYNTAX  BITS {
       forwardPresent (0),
       reversePresent (1),
       forwardGlobal (2),
       reverseGlobal (3)
     }
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "This bitmask indicates the presence and status of
        labels indicated by the
        gmplsTunnelARHopExpLabel or gmplsTunnelARHopExpLabelPtr and
        gmplsTunnelARHopExpRvrsLabel or gmplsTunnelARHopExpRvrsLabelPtr
        objects.

Nadeau and Farrel (Editors)                                    [Page 25]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

        For the Present bits, a set bit indicates that a label
        is present for this hop in the route. For the Global bits,
        a set bit indicates that the label comes from the Global
        Label Space. A clear bit indicates that this is a
        Per-Interface label. A Global bit only has meaning if the
        corresponding Present bit is set."
   ::=3D { gmplsTunnelARHopEntry 1 }

   gmplsTunnelARHopExpLabel OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelARHopLabelStatuses object indicates
        that a forward label is present and
        gmplsTunnelARHopExpLabelPtr contains the value
        zeroDotZero, then the label in use on this hop is
        found in this object encoded within a 32-bit integer."
   ::=3D { gmplsTunnelARHopEntry 2 }

   gmplsTunnelARHopExpLabelPtr OBJECT-TYPE
     SYNTAX  RowPointer
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelARHopLabelStatuses object indicates
        that a forward label is present, this object contains
        a pointer to a row in another MIB table (such as the
        gmplsLabelTable) that contains the label in use on
        this hop in the forward direction.
        If the gmplsTunnelARHopLabelStatuses object indicates that
        a forward label is present and this object contains the
        value zeroDotZero, then the label in use on this hop is
        found in the gmplsTunnelARHopExpLabel object."
   ::=3D { gmplsTunnelARHopEntry 3 }

   gmplsTunnelARHopExpRvrsLabel OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelARHopLabelStatuses object indicates
        that a reverse label is present and
        gmplsTunnelARHopExpRvrsLabelPtr contains the value
        zeroDotZero, then the label in use on this hop is
        found in this object encoded as a 32-bit integer."
   ::=3D { gmplsTunnelARHopEntry 4 }

Nadeau and Farrel (Editors)                                    [Page 26]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   gmplsTunnelARHopExpRvrsLabelPtr OBJECT-TYPE
     SYNTAX  RowPointer
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelARHopLabelStatuses object indicates
        that a reverse label is present, this object contains
        a pointer to a row in another MIB table (such as the
        gmplsLabelTable) that contains the label in use on
        this hop in the reverse direction.
        If the gmplsTunnelARHopLabelStatuses object indicates that
        a reverse label is present and this object contains the
        value zeroDotZero, then the label in use on this hop is
        found in the gmplsTunnelARHopExpRvrsLabel object."
   ::=3D { gmplsTunnelARHopEntry 5 }

   gmplsTunnelARHopProtection  OBJECT-TYPE
     SYNTAX  BITS {
       localAvailable (0),
       localInUse (1)
     }
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
      "Availability and usage of protection on the reported link.

       localAvailable
          Indicates that the link downstream of this node
          is protected via a local repair mechanism.
       localInUse
          Indicates that a local repair mechanism is in use to
          maintain this tunnel (usually in the face of an outage
          of the link it was previously routed over)."
   ::=3D { gmplsTunnelARHopEntry 6 }

   -- End of mplsTunnelARHopTable

   -- Tunnel Computed Hop table.

   gmplsTunnelCHopTable  OBJECT-TYPE
     SYNTAX  SEQUENCE OF GmplsTunnelCHopEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "The gmplsTunnelCHopTable 'extends' the mplsTunnelCHopTable.
        It is used to indicate additional information about the
        hops of a GMPLS tunnel defined in mplsTunnelTable and
        gmplsTunnelTable, as computed by a constraint-based
        routing protocol, based on the mplsTunnelHopTable
        and the gmplsTunnelHopTable.

Nadeau and Farrel (Editors)                                    [Page 27]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

        Each row in this table is indexed by the same indexes as
        mplsTunnelCHopTable. It is acceptable for some rows in
        mplsTunnelCHopTable to have corresponding entries in this
        table and some to have no corresponding entry in this table.

        Please note that since the information necessary to
        build entries within this table may not be supported
        by some LSRs, implementation of this table is optional.

        Furthermore, since the information in this table is actually
        provided by a path computation component after the path has
        been computed, the entries in this table are provided only
        for observation, and hence, all objects in this table are
        accessible exclusively as read-only."
     REFERENCE
       "Generalized MPLS Signaling - RSVP-TE Extensions, Berger,
        L. (Editor), RFC 3473, January 2003."
   ::=3D { gmplsTeObjects 4 }

   gmplsTunnelCHopEntry  OBJECT-TYPE
     SYNTAX  GmplsTunnelCHopEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "An entry in this table represents additions to a
        computed tunnel hop visible in mplsTunnelCHopEntry.
        An entry is created by a path computation component
        based on the hops specified in the corresponding
        mplsTunnelHopTable and gmplsTunnelHopTable.

        At a transit LSR this table (if the table is
        supported) MAY contain the path computed by path
        computation engine on (or on behalf of) the transit LSR."
     INDEX {
       mplsTunnelCHopListIndex,
       mplsTunnelCHopIndex
     }
   ::=3D { gmplsTunnelCHopTable 1 }

   GmplsTunnelCHopEntry ::=3D SEQUENCE {
     gmplsTunnelCHopLabelStatuses     BITS,
     gmplsTunnelCHopExpLabel          Unsigned32,
     gmplsTunnelCHopExpLabelPtr       RowPointer,
     gmplsTunnelCHopExpRvrsLabel      Unsigned32,
     gmplsTunnelCHopExpRvrsLabelPtr   RowPointer
   }

Nadeau and Farrel (Editors)                                    [Page 28]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   gmplsTunnelCHopLabelStatuses OBJECT-TYPE
     SYNTAX  BITS {
       forwardPresent (0),
       reversePresent (1)
     }
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "This bitmask indicates the presence of labels indicated by the
        gmplsTunnelCHopExpLabel or gmplsTunnelCHopExpLabelPtr and
        gmplsTunnelCHopExpRvrsLabel or gmplsTunnelCHopExpRvrsLabelPtr
        objects.
        A set bit indicates that a label is present for this hop in
        the route thus allowing zero to be a valid label value."
   ::=3D { gmplsTunnelCHopEntry 1 }

   gmplsTunnelCHopExpLabel OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelCHopLabelStatuses object indicates
        that a forward label is present and
        gmplsTunnelCHopExpLabelPtr contains the value
        zeroDotZero, then the label to use on this hop is
        found in this object encoded within a 32-bit integer."
   ::=3D { gmplsTunnelCHopEntry 2 }

   gmplsTunnelCHopExpLabelPtr OBJECT-TYPE
     SYNTAX  RowPointer
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelCHopLabelStatuses object indicates
        that a forward label is present, this object contains
        a pointer to a row in another MIB table (such as the
        gmplsLabelTable) that contains the label to use on
        this hop in the forward direction.
        If the gmplsTunnelCHopLabelStatuses object indicates that
        a forward label is present and this object contains the
        value zeroDotZero, then the label to use on this hop is
        found in the gmplsTunnelCHopExpLabel object."
   ::=3D { gmplsTunnelCHopEntry 3 }

   gmplsTunnelCHopExpRvrsLabel OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelCHopLabelStatuses object indicates
        that a reverse label is present and

Nadeau and Farrel (Editors)                                    [Page 29]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

        gmplsTunnelCHopExpRvrsLabelPtr contains the value
        zeroDotZero, then the label to use on this hop is
        found in this object encoded as a 32-bit integer."
   ::=3D { gmplsTunnelCHopEntry 4 }

   gmplsTunnelCHopExpRvrsLabelPtr OBJECT-TYPE
     SYNTAX  RowPointer
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "If the gmplsTunnelCHopLabelStatuses object indicates
        that a reverse label is present, this object contains
        a pointer to a row in another MIB table (such as the
        gmplsLabelTable) that contains the label to use on
        this hop in the reverse direction.

        If the gmplsTunnelCHopLabelStatuses object indicates that
        a reverse label is present and this object contains the
        value zeroDotZero, then the label to use on this hop is
        found in the gmplsTunnelCHopExpRvrsLabel object."
   ::=3D { gmplsTunnelCHopEntry 5 }
   -- End of gmplsTunnelCHopTable

   -- GMPLS Tunnel Reverse Direction Performance Table.

   gmplsTunnelReversePerfTable  OBJECT-TYPE
     SYNTAX  SEQUENCE OF GmplsTunnelReversePerfEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "This table 'augments' the gmplsTunnelTable to provides
        per-tunnel packet performance information for the
        reverse direction of a bidirectional tunnel. It can be
        seen as supplementing the mplsTunnelPerfTable which
        augments the mplsTunnelTable."
     REFERENCE
       "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
        Management Information Base (MIB), Srinivasan, C., Viswanathan,
        A., Nadeau, T., RFC 3812, June 2004."
   ::=3D { gmplsTeObjects 5 }

   gmplsTunnelReversePerfEntry OBJECT-TYPE
     SYNTAX  GmplsTunnelReversePerfEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "An entry in this table is created by the LSR for every
        bidirectional GMPLS tunnel where packets are visible to
        the LSR."
     AUGMENTS { gmplsTunnelEntry }
   ::=3D { gmplsTunnelReversePerfTable 1 }

Nadeau and Farrel (Editors)                                    [Page 30]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   GmplsTunnelReversePerfEntry ::=3D SEQUENCE {
     gmplsTunnelReversePerfPackets     Counter32,
     gmplsTunnelReversePerfHCPackets   Counter64,
     gmplsTunnelReversePerfErrors      Counter32,
     gmplsTunnelReversePerfBytes       Counter32,
     gmplsTunnelReversePerfHCBytes     Counter64
   }

   gmplsTunnelReversePerfPackets OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "Number of packets forwarded on the tunnel in the
        reverse direction if it is bidirectional."
   ::=3D { gmplsTunnelReversePerfEntry 1 }

   gmplsTunnelReversePerfHCPackets OBJECT-TYPE
     SYNTAX  Counter64
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "High capacity counter for number of packets forwarded on
       the tunnel in the reverse direction if it is bidirectional."
   ::=3D { gmplsTunnelReversePerfEntry 2 }

   gmplsTunnelReversePerfErrors OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "Number of errored packets received on the tunnel in
        the reverse direction if it is bidirectional."
   ::=3D { gmplsTunnelReversePerfEntry 3 }

   gmplsTunnelReversePerfBytes OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "Number of bytes forwarded on the tunnel in the
        reverse direction if it is bidirectional."
   ::=3D { gmplsTunnelReversePerfEntry 4 }

   gmplsTunnelReversePerfHCBytes OBJECT-TYPE
     SYNTAX  Counter64
     MAX-ACCESS read-only
     STATUS  current

Nadeau and Farrel (Editors)                                    [Page 31]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

     DESCRIPTION
       "High capacity counter for number of bytes forwarded
        on the tunnel in the reverse direction if it is
        bidirectional."
   ::=3D { gmplsTunnelReversePerfEntry 5 }

   -- End of gmplsTunnelReversePerfTable

   -- GMPLS Tunnel Error Table.

   gmplsTunnelErrorTable  OBJECT-TYPE
     SYNTAX  SEQUENCE OF GmplsTunnelErrorEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "This table 'augments' the mplsTunnelTable
        This table provides per-tunnel information about
        errors. Errors may be detected locally or reported
        through the signaling protocol.
        Error reporting is not exclusive to GMPLS and this
        table may be applied in MPLS systems."
     REFERENCE
       "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
        Management Information Base (MIB), Srinivasan, C., Viswanathan,
        A., Nadeau, T., RFC 3812, June 2004."
   ::=3D { gmplsTeObjects 6 }

   gmplsTunnelErrorEntry OBJECT-TYPE
     SYNTAX  GmplsTunnelErrorEntry
     MAX-ACCESS not-accessible
     STATUS  current
     DESCRIPTION
       "An entry in this table is created by the LSR for
        every tunnel where error information is visible to
        the LSR.
        Note that systems which read the objects in this table
        one at a time may experience a discontinuity as the
        result of a new error occurring in between object reads.
        Systems that are vulnerable to this should read
        gmplsTunnelErrorLastTime before and after reading the
        other objects."
     AUGMENTS { mplsTunnelEntry }
   ::=3D { gmplsTunnelErrorTable 1 }

   GmplsTunnelErrorEntry ::=3D SEQUENCE {
     gmplsTunnelErrorLastErrorType      INTEGER,
     gmplsTunnelErrorLastTime           TimeStamp,
     gmplsTunnelErrorReporterType       INTEGER,
     gmplsTunnelErrorReporter           InetAddress,
     gmplsTunnelErrorCode               Unsigned32,
     gmplsTunnelErrorSubcode            Unsigned32,

Nadeau and Farrel (Editors)                                    [Page 32]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

     gmplsTunnelErrorTLVs               OCTET STRING,
     gmplsTunnelErrorHelpString         DisplayString
   }

   gmplsTunnelErrorLastErrorType OBJECT-TYPE
     SYNTAX  INTEGER {
       noError (0),
       unknown (1),
       localProtocol (2),
       remoteProtocol (3),
       configuration (4),
       pathComputation (5),
       localResources (6)
     }
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "The nature of the last error. Provides
        interpretation context for
        gmplsTunnelErrorProtocolCode and
        gmplsTunnelErrorProtocolSubcode. A value of noError
        (0) shows that there is no error associated with
        this tunnel and means that the other objects in this
        entry have no meaning."
   ::=3D { gmplsTunnelErrorEntry 1 }

   gmplsTunnelErrorLastTime OBJECT-TYPE
     SYNTAX  TimeStamp
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "The time at which the last error occurred. This is
        presented as the value of SysUpTime when the error
        occurred or was reported to this node.
        If gmplsTunnelErrorLastErrorType has the value
        noError (0), then this object is ignored."
   ::=3D { gmplsTunnelErrorEntry 2 }

   gmplsTunnelErrorReporterType OBJECT-TYPE
      SYNTAX  INTEGER {
        unknown (0),
        localNode (1),
        localIpV4 (2),
        remoteIpV4 (3),
        localIpV6 (4),
        remoteIpV6 (5)
      }
      MAX-ACCESS read-only
      STATUS  current

Nadeau and Farrel (Editors)                                    [Page 33]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

      DESCRIPTION
        "The reporter of the last error recorded.
         This object is used principally to aid in interpretation
         of gmplsTunnelErrorReporterIpv4Addr and
         gmplsTunnelErrorReporterIpv6Addr. Where the error has
         been locally generated and there is no requirement to
         associate the error with any specific local address (such
         as an interface), the value localNode (2) may be used.
         If gmplsTunnelErrorLastError has the value noError
         (0), then this object is ignored."
   ::=3D { gmplsTunnelErrorEntry 3 }

   gmplsTunnelErrorReporter OBJECT-TYPE
     SYNTAX  InetAddress
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "The address of the node reporting the last error, or
        the address of the resource (such as an interface)
        associated with the error.
        If gmplsTunnelErrorLastErrorType has the value
        noError (0), then this object is ignored.
        This object should be interpreted in the context of
        the value of the object gmplsTunnelErrorReporterType.
        If that object has value localIpV4 (2) or remoteIpV4 (3),
        this object should be viewed as having a syntax of
        InetAddressIPv4. If gmplsTunnelErrorReporterType has
        value localIpV6 (3) or remoteIpV6 (5), this object should be
        viewed as having a syntax of InetAddressIPv6. Otherwise the
        object should contain the value zero and should be ignored."
     REFERENCE
       "RFC3291, Textual Conventions for Internet Network
        Addresses, Section 4. Usage Hints."
   ::=3D { gmplsTunnelErrorEntry 4 }

   gmplsTunnelErrorCode OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "The primary error code associated with the last error.

        The interpretation of this error code depends on the
        value of gmplsTunnelErrorLastErrorType. If the value
        of gmplsTunnelErrorLastErrorType is noError (0) the
        value of this object should be 0 and should be
        ignored. If the value of
        gmplsTunnelErrorLastErrorType is localProtocol (2)
        or remoteProtocol (3) the error should be
        interpreted in the context of the signling protocol
        identified by the mplsTunnelSignallingProto object.

Nadeau and Farrel (Editors)                                    [Page 34]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

        Values in excess 32767 of are not used by signaling
        protocols and may safely be used as
        implementation-specific error codes. "
     REFERENCE
       "1. Braden, R. (Ed.) et al., Resource ReserVation Protocol --
           Version 1 Functional Specification, RFC 2205, September 1997.
        2. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche
           et al, RFC 3209, December 2001.
        3. Generalized MPLS Signaling - RSVP-TE Extensions, Berger,
           L. (Editor), RFC 3473, January 2003."
   ::=3D { gmplsTunnelErrorEntry 5 }

   gmplsTunnelErrorSubcode OBJECT-TYPE
     SYNTAX  Unsigned32
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "The secondary error code associated with the last error and the
        protocol used to signal this tunnel. This value is interpreted
        in the context of the value of gmplsTunnelErrorCode.
        If the value of gmplsTunnelErrorLastErrorType is
        noError (0) the value of this object should be 0 and
        should be ignored."
     REFERENCE
       "1. Braden, R. (Ed.) et al., Resource ReserVation Protocol --
           Version 1 Functional Specification, RFC 2205, September 1997.
        2. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche
           et al, RFC 3209, December 2001.
        3. Generalized MPLS Signaling - RSVP-TE Extensions, Berger,
           L. (Editor), RFC 3473, January 2003."
   ::=3D { gmplsTunnelErrorEntry 6 }

   gmplsTunnelErrorTLVs OBJECT-TYPE
     SYNTAX  OCTET STRING
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "The sequence of interface identifier TLVs reported
        with the error by the protocol code. The interpretation
        of the TLVs and the encoding within the protocol are
        described in the references.
        A value of zero in the first octet indicates that no
        TLVs are present."
      REFERENCE
       "Generalized MPLS Signaling - RSVP-TE Extensions, Berger,
        L. (Editor), RFC 3473, January 2003."
   ::=3D { gmplsTunnelErrorEntry 7 }

Nadeau and Farrel (Editors)                                    [Page 35]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   gmplsTunnelErrorHelpString OBJECT-TYPE
     SYNTAX  DisplayString
     MAX-ACCESS read-only
     STATUS  current
     DESCRIPTION
       "A textual string containing information about the
        last error, recovery actions and support advice. If
        there is no help string this object contains a zero
        length string.
        If the value of gmplsTunnelErrorLastErrorType is
        noError (0) this object should contain a zero length
        string, but may contain a help string indicating
        that there is no error."
   ::=3D { gmplsTunnelErrorEntry 8 }

   -- GMPLS Notifications.

   gmplsTunnelDown NOTIFICATION-TYPE
   OBJECTS  {
     mplsTunnelAdminStatus,
     mplsTunnelOperStatus,
     gmplsTunnelErrorLastErrorType,
     gmplsTunnelErrorReporterType,
     gmplsTunnelErrorReporter,
     gmplsTunnelErrorCode,
     gmplsTunnelErrorSubcode
   }
   STATUS      current
   DESCRIPTION
        "This notification is generated when a
         mplsTunnelOperStatus object for one of the
         configured tunnels is about to enter the down state
         from some other state (but not from the notPresent
         state). This other state is indicated by the
         included value of mplsTunnelOperStatus.

         The objects in this notification provide additional
         error information that indicates the reason why the
         tunnel has transitioned down.

         Note that an implementation SHOULD only issue one of
         mplsTunnelDown and gmplsTunnelDown for a single event
         on a single tunnel."
   ::=3D { gmplsTeNotifications 1 }

   -- End of notifications.

Nadeau and Farrel (Editors)                                    [Page 36]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   -- Module compliance.

   gmplsTeGroups
     OBJECT IDENTIFIER ::=3D { gmplsTeConformance 1 }

   gmplsTeCompliances
     OBJECT IDENTIFIER ::=3D { gmplsTeConformance 2 }

   gmplsTeModuleCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance statement for agents that support the
        GMPLS TE MIB."
     MODULE -- this module

   -- The mandatory group has to be implemented by all
   -- LSRs that originate/terminate ESLSPs/tunnels.
   -- In addition, depending on the type of tunnels
   -- supported, other groups become mandatory as
   -- explained below.

   MANDATORY-GROUPS {
     gmplsTunnelGroup,
     gmplsTunnelScalarGroup
   }

-- GROUP gmplsTunnelManualGroup
--   DESCRIPTION
--     "This group is mandatory for devices which support
--      manual configuration of tunnels, in addition to
--      gmplsTunnelGroup.  The following constraints apply:
--      mplsTunnelSignallingProto should be at least
--      read-only with a value of none(1)."

   GROUP gmplsTunnelSignaledGroup
     DESCRIPTION
       "This group is mandatory for devices which support
        signaled tunnel set up, in addition to
        gmplsTunnelGroup.  The following constraints apply:

        mplsTunnelSignallingProto should be at least
        read-only returning a value of ldp(2), or rsvp(3)."

   GROUP gmplsTunnelIsNotIntfcGroup
     DESCRIPTION
       "This group is mandatory for devices which support
        tunnels that are not interfaces, in addition to
        gmplsTunnelGroup.  The following constraints apply:
        gmplsTunnelIsIf must at least be read-only returning no(0)."

Nadeau and Farrel (Editors)                                    [Page 37]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   GROUP gmplsTunnelIsIntfcGroup
     DESCRIPTION
       "This group is mandatory for devices which support
        tunnels that are interfaces, in addition to gmplsTunnelGroup."

   GROUP gmplsTunnelOptionalGroup
     DESCRIPTION
       "Objects in this group are optional."

   GROUP gmplsTeNotificationGroup
   DESCRIPTION "This group is mandatory for those implementations
                which can implement the notifications contained
                in this group."

   -- GMPLS Tunnel scalars.
   -- All scalars have max access read-only

   -- gmplsTunnelTable

   OBJECT gmplsTunnelAttributes
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelLSPEncoding
     SYNTAX Integer32
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelSwitchingType
     SYNTAX Integer32
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelLinkProtection
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelGPid
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelSecondary
     SYNTAX TruthValue
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

Nadeau and Farrel (Editors)                                    [Page 38]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   OBJECT gmplsTunnelDirection
     SYNTAX INTEGER {
       forward (0),
       bidirectional (1)
     }
     MIN-ACCESS  read-only
     DESCRIPTION
       "Only forward (0) is required."

   OBJECT gmplsTunnelPathComp
     SYNTAX INTEGER {
       dynamicFull(1),   -- CSPF fully computed
       explicit(2),      -- fully
       dynamicPartial(3) -- CSPF partially computed
     }

     MIN-ACCESS  read-only
     DESCRIPTION
       "Only explicit (2) is required."

   OBJECT gmplsTunnelUpNotRecip
     SYNTAX  IpAddress
     MIN-ACCESS read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelDownNotRecip
     SYNTAX  IpAddress
     MIN-ACCESS read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelAdminStatusFlags
      SYNTAX      BITS {
             delInProgress (0),
             adminDown (1),
             testing (2),
             reflect (31)
             }
      MIN-ACCESS   read-only
      DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelExtraParamsPtr
     SYNTAX  RowPointer
     MIN-ACCESS read-only
     DESCRIPTION
       "Write access is not required."

   -- gmplsTunnelHopTable

Nadeau and Farrel (Editors)                                    [Page 39]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   -- gmplsTunnelHopLabelStatuses has max access read-only

   OBJECT gmplsTunnelHopExpLabel
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelHopExpLabelPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelHopExpRvrsLabel
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   OBJECT gmplsTunnelHopExpRvrsLabelPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   -- gmplsTunnelARHopTable
   -- all objects have max access read-only

   -- glmpsTunnelCHopTable
   -- all objects have max access read-only

   -- gmplsTunnelReversePerfTable
   -- all objects have max access read-only

   -- gmplsTunnelErrorTable
   -- all objects have max access read-only
   ::=3D { gmplsTeCompliances 1 }

   -- Units of conformance.

   gmplsTunnelGroup OBJECT-GROUP
     OBJECTS {
       gmplsTunnelDirection,
       gmplsTunnelReversePerfPackets,
       gmplsTunnelReversePerfHCPackets,
       gmplsTunnelReversePerfErrors,
       gmplsTunnelReversePerfBytes,
       gmplsTunnelReversePerfHCBytes,
       gmplsTunnelErrorLastErrorType,
       gmplsTunnelErrorLastTime,
       gmplsTunnelErrorReporterType,
       gmplsTunnelErrorReporter,
       gmplsTunnelErrorCode,
       gmplsTunnelErrorSubcode,

Nadeau and Farrel (Editors)                                    [Page 40]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

       gmplsTunnelErrorTLVs,
       gmplsTunnelErrorHelpString
     }
     STATUS  current
     DESCRIPTION
       "Necessary, but not sufficient, set of objects to implement
        tunnels.  In addition, depending on the type of the tunnels
        supported (for example, manually configured or signaled,
        persistent or non-persistent, etc.), the following other
        groups defined below are mandatory: gmplsTunnelManualGroup
        and/or gmplsTunnelSignaledGroup, gmplsTunnelIsNotIntfcGroup
        and/or gmplsTunnelIsIntfcGroup."
   ::=3D { gmplsTeGroups 1 }

-- gmplsTunnelManualGroup  OBJECT-GROUP
--   OBJECTS {
--     mplsTunnelSignallingProto
--   }
--   STATUS  current
--   DESCRIPTION
--     "Object(s) needed to implement manually configured
--      tunnels."
-- ::=3D { gmplsTeGroups 2 }

   gmplsTunnelSignaledGroup OBJECT-GROUP
     OBJECTS {
       gmplsTunnelAttributes,
       gmplsTunnelLSPEncoding,
       gmplsTunnelSwitchingType,
       gmplsTunnelLinkProtection,
       gmplsTunnelGPid,
       gmplsTunnelSecondary,
       gmplsTunnelPathComp,
       gmplsTunnelUpNotRecip,
       gmplsTunnelDownNotRecip,
       gmplsTunnelAdminStatusFlags,
       gmplsTunnelHopLabelStatuses,
       gmplsTunnelHopExpLabel,
       gmplsTunnelHopExpLabelPtr,
       gmplsTunnelHopExpRvrsLabel,
       gmplsTunnelHopExpRvrsLabelPtr
     }

     STATUS  current
     DESCRIPTION
       "Objects needed to implement signaled tunnels."
   ::=3D { gmplsTeGroups 3 }

Nadeau and Farrel (Editors)                                    [Page 41]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   gmplsTunnelScalarGroup OBJECT-GROUP
     OBJECTS {
       gmplsTunnelsConfigured,
       gmplsTunnelsActive
     }
     STATUS  current
     DESCRIPTION
       "Scalar objects needed to implement MPLS tunnels."
   ::=3D { gmplsTeGroups 4 }

   gmplsTunnelIsIntfcGroup OBJECT-GROUP
     OBJECTS {
       gmplsTunnelUnnumIf
     }
     STATUS  current
     DESCRIPTION
       "Objects needed to implement tunnels that are
        interfaces."
   ::=3D { gmplsTeGroups 5 }

   gmplsTunnelIsNotIntfcGroup OBJECT-GROUP
     OBJECTS {
       gmplsTunnelUnnumIf
     }
     STATUS  current
     DESCRIPTION
       "Objects needed to implement tunnels that are not
        interfaces."
   ::=3D { gmplsTeGroups 6 }

   gmplsTunnelOptionalGroup OBJECT-GROUP
     OBJECTS {
       gmplsTunnelExtraParamsPtr,
       gmplsTunnelARHopLabelStatuses,
       gmplsTunnelARHopExpLabel,
       gmplsTunnelARHopExpLabelPtr,
       gmplsTunnelARHopExpRvrsLabel,
       gmplsTunnelARHopExpRvrsLabelPtr,
       gmplsTunnelARHopProtection,
       gmplsTunnelCHopLabelStatuses,
       gmplsTunnelCHopExpLabel,
       gmplsTunnelCHopExpLabelPtr,
       gmplsTunnelCHopExpRvrsLabel,
       gmplsTunnelCHopExpRvrsLabelPtr
     }
     STATUS  current
     DESCRIPTION
       "The objects in this group are optional."
   ::=3D { gmplsTeGroups 7 }

Nadeau and Farrel (Editors)                                    [Page 42]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   gmplsTeNotificationGroup NOTIFICATION-GROUP
     NOTIFICATIONS {
        gmplsTunnelDown
     }
     STATUS  current
     DESCRIPTION
       "Set of notifications implemented in this module.
        None is mandatory."
   ::=3D { gmplsTeGroups 8 }

   END

9. Security Considerations

   It is clear that the MIB modules described in this document in
   association with the MPLS-TE-STD-MIB are potentially useful for
   monitoring of MPLS and GMPLS tunnels. These MIB modules can also be
   used for configuration of certain objects, and anything that can be
   configured can be incorrectly configured, with potentially disastrous
   results.

   There are a number of management objects defined in these MIB modules
   with a MAX-ACCESS clause of read-write and/or read-create. Such
   objects may be considered sensitive or vulnerable in some network
   environments. The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations. These are the tables and objects and their

   sensitivity/vulnerability:

   o  the gmplsTunnelTable and gmplsTunnelHopTable collectively contain
      objects to provision GMPLS tunnels interfaces at their ingress
      LSRs. Unauthorized write access to objects in these tables, could
      result in disruption of traffic on the network. This is especially
      true if a tunnel has already been established. The use of stronger
      mechanisms such as SNMPv3 security should be considered where
      possible. Specifically, SNMPv3 VACM and USM MUST be used with any
      SNMPv3 agent which implements these MIB modules.

   Some of the readable objects in these MIB modules "i.e., objects with
   a MAX-ACCESS other than not-accessible" may be considered sensitive
   or vulnerable in some network environments. It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP. These are the tables and objects and their
   sensitivity/vulnerability:

   o  the gmplsTunnelTable, gmplsTunnelHopTable, gmplsTunnelARHopTable,
      gmplsTunnelCHopTable, gmplsTunnelReversePerfTable,
      gmplsTunnelErrorTable collectively show the tunnel network
      topology and status. If an Administrator does not want to reveal

Nadeau and Farrel (Editors)                                    [Page 43]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

      this information, then these tables should be considered
      sensitive/vulnerable.

   SNMP versions prior to SNMPv3 did not include adequate security. Even
   if the network itself is secure "for example by using IPSec", even
   then, there is no control as to who on the secure network is allowed
   to access and GET/SET "read/change/create/delete" the objects in
   these MIB modules. It is RECOMMENDED that implementers consider the
   security features as provided by the SNMPv3 framework "see [RFC3410],
   section 8", including full support for the SNMPv3 cryptographic
   mechanisms "for authentication and privacy".

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module, is properly configured to give access to
   the objects only to those principals "users" that have legitimate
   rights to indeed GET or SET "change/create/delete" them.

10. Acknowledgments

   This draft is the work of the five authors listed in the Authors'
   Addresses section.

   This document extends [RFC3812]. The authors would like to express
   their gratitude to all those who worked on that earlier MIB document.
   Thanks also to Tony Zinicola and Jeremy Crossen for their valuable
   contributions during an early implementation, and to Baktha
   Muralidharan for his review.

   Special thanks to Joan Cucchiara and Len Nieman for their help with
   compilation issues.

11.  IANA Considerations

   As requested in the GMPLS-TC-STD-MIB [GMPLSTCMIB], GMPLS related
   standards track MIB modules should be rooted under the mplsStdMIB
   subtree.  There is one GMPLS MIB Module contained in this document,
   and the following "IANA Considerations" subsection requests IANA for
   a new assignment under the mplsStdMIB subtree.  New assignments can
   only be made via a Standards Action as specified in [RFC2434].

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

   IANA is requested to assign an OID to the GMPLS-TE-STD-MIB module
   specified in this document as { mplsStdMIB xx }.

Nadeau and Farrel (Editors)                                    [Page 44]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

12. References

12.1. Normative References

   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]        McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                    Case, J., Rose, M., and S. Waldbusser, "Structure
                    of Management Information Version 2 (SMIv2)", STD
                    58, RFC 2578, April 1999.

   [RFC2579]        McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                    Case, J., Rose, M., and S. Waldbusser, "Textual
                    Conventions for SMIv2", STD 58, RFC 2579, April
                    1999.

   [RFC2580]        McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                    Case, J., Rose, M., and S. Waldbusser, "Conformance
                    Statements for SMIv2", STD 58, RFC 2580, April
                    1999.

   [RFC3031]        Rosen, E., Viswanathan, A., and R. Callon,
                    "Multiprotocol Label Switching Architecture", RFC
                    3031, January 2001.

   [RFC3209]        Awduche, D., Berger, L., Gan, D., Li, T.,
                    Srinivasan, V., and G. Swallow, "RSVP-TE:
                    Extensions to RSVP for LSP Tunnels", RFC 3209,
                    December 2001.

   [RFC3212]        Jamoussi, B., Aboul-Magd, O., Andersson, L.,
                    Ashwood-Smith, P., Hellstrand, F., Sundell, K.,
                    Callon, R., Dantu, R., Wu, L., Doolan, P., Worster,
                    T., Feldman, N., Fredette, A., Girish, M., Gray,
                    E., Halpern, J., Heinanen, J., Kilty, T., Malis,
                    A., and P. Vaananen, "Constraint-Based LSP Setup
                    using LDP", RFC 3212, December 2001.

   [RFC3291]        Daniele, M., Haberman, B., Routhier, S.,
                    Schoenwaelder, J., and Braunschweig, TU, "Textual
                    Conventions for Internet Network Addresses",
                    RFC3291, May 2002

   [RFC3471]        Berger, L. (Editor), "Generalized Multi-Protocol
                    Label Switching (GMPLS) Signaling Functional
                    Description", RFC 3471, January 2003.

   [RFC3472]        Ashwood-Smith, P., Berger, L. (Editors),
                    "Generalized MPLS Signaling - CR-LDP Extensions",
                    RFC 3472, January 2003.

Nadeau and Farrel (Editors)                                    [Page 45]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   [RFC3473]        Berger, L. (Editor), "Generalized MPLS Signaling -
                    RSVP-TE Extensions", RFC 3473, January 2003.

   [RFC3477]        Kompella, K. and Rekhter, Y., "Signalling Unnumbered
                    Links in RSVP-TE", RFC 3477, January 2003.

   [RFC3480]        Kompella, K., Rekhter, Y. and Kullberg, A.,
                    "Signalling Unnumbered Links in CR-LDP", RFC 3480,
                    February 2003.

   [RFC3811]        Nadeau, T. and J. Cucchiara, "Definition of Textual
                    Conventions and for Multiprotocol Label Switching
                    (MPLS) Management", RFC 3811, June 2004.

   [RFC3812]        Srinivasan, C., Viswanathan, A., and T. Nadeau,
                    "Multiprotocol Label Switching (MPLS) Traffic
                    Engineering (TE) Management Information Base (MIB)",
                    RFC 3812, June 2004.

   [RFC3813]        Srinivasan, C., Viswanathan, A., and T.  Nadeau,
                    "Multiprotocol Label Switching (MPLS) Label
                    Switching (LSR) Router Management Information Base
                    (MIB)", RFC 3813, June 2004.

   [GMPLSArch]      Mannie, E. (Editor), "Generalized Multiprotocol
                    Label Switching (GMPLS) Architecture",
                    draft-many-gmpls-architecture-07.txt, May
                    2003, work in progress.

   [GMPLSLSRMIB]    Nadeau, T., Farrel, A., (Editors) "Generalized
                    Multiprotocol Label Switching (GMPLS) Label
                    Switching Router (LSR) Management Information
                    Base", draft-ietf-ccamp-gmpls-lsr-mib-06.txt,
                    October 2004, work in progress.

   [GMPLSOSPF]      Kompella, K., et al., "OSPF Extensions in Support
                    of Generalized MPLS",
                    draft-ietf-ccamp-ospf-gmpls-extensions-12.txt,
                    October 2003, work in progress.

   [GMPLSTCMIB]     Nadeau, T., Farrel, A., (Editors) "Definitions of
                    Textual Conventions for Multiprotocol Label
                    Switching (MPLS) Management",
                    draft-ietf-ccamp-gmpls-te-mib-06.txt, October 2004,
                    work in progress.

12.2. Informational References

   [RFC2026]        S. Bradner, "The Internet Standards Process --
                    Revision 3", RFC 2026, October 1996.

Nadeau and Farrel (Editors)                                    [Page 46]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   [RFC2434]        Narten, T. and H. Alvestrand.,  "Guidelines for
                    Writing an IANA Considerations Section in RFCs",
                    BCP 26, RFC 2434, October 1998.

   [RFC3413]        Levi, D., Meyer, P., Stewart, B., "SNMP
                    Applications", RFC 3413, December 2002.

   [RFC3410]        Case, J., Mundy, R., Partain, D. and B. Stewart,
                    "Introduction and Applicability Statements for
                    Internet-Standard Management Framework", RFC 3410,
                    December 2002.

   [RFC3411]        Harrington, D., Presuhn, R., and B. Wijnen, "An
                    Architecture for Describing Simple Network
                    Management Protocol (SNMP) Management Frameworks",
                    RFC 3411, December 2002.

   [GMPLS-G709]     D. Papadimitriou (Editor), "Generalized MPLS
                    Signalling Extensions for G.709 Optical Transport
                    Networks Control", draft-ietf-ccamp-gmpls-g709-
                    07.txt, September 2004, work in progress.

13. Authors' Addresses

   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Apollo Drive
   Chelmsford, MA 01824
   Phone: +1-978-244-3051
   Email: [email-masked]

   Cheenu Srinivasan
   Bloomberg L.P.
   499 Park Ave.,
   New York, NY 10022
   Phone: +1-212-893-3682
   Email: [email-masked]

   Adrian Farrel
   Old Dog Consulting
   Phone: +44-(0)-1978-860944
   Email: [email-masked]

   Tim Hall
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex
   EN2 6BQ, UK
   Phone: +44 20 8366 1177
   Email: [email-masked]

Nadeau and Farrel (Editors)                                    [Page 47]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

   Ed Harrison
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex
   EN2 6BQ, UK
   Phone: +44 20 8366 1177
   Email: [email-masked]

14. Intellectual Property Considerations

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

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

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

15. Full Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Nadeau and Farrel (Editors)                                    [Page 48]
=0C
Internet Draft     draft-ietf-ccamp-gmpls-te-mib-06.txt     October 2004

16. Changes

   This section to be removed before the draft progresses to RFC.

16.1. Changes from version 5 to version 6

   - ID nits and MIB boilerplate

16.2. Changes from version 4 to version 5

   - New IPR and copyright boiler plate.
   - Correct typo in name of gmplsTunnelExtraParamsPtr
   - Add to list of encoding types and GPids for G.709
   - Add G.709 reference

16.3. Changes from version 3 to version 4

   - Provide a way to configure additional tunnel parameters such as
     tunnel resources through an arbitrary row pointer.
   - Update references.
   - Change reporting IP addresses to use InetAddress syntax
   - Add support for IF_ID error reporting.
   - Add a new notification, gmplsTunnelDown, containing cause
     information.
   - Clarify relationship to the gmplsLabelTable.
   - Update descriptive text.
   - Bring usage of labels in line with latest [RFC3813].

16.4. Changes from version 2 to version 3

   - Work on basic compilation issues.
   - Resolve defaults for objects with syntax BITS.
   - Update references.
   - Clarify which objects can be modified when rowStatus and
     adminStatus are set to active.
   - Control and reporting of upstream and downstream Notify
     Recipients.
   - Add support for control and reporting of GMPLS Administrative
     Status object.
   - Update examples.

Nadeau and Farrel (Editors)                                    [Page 49]
=0C

------=_NextPart_000_0E00_01C4BDF2.F8398130--

Delivery-date: Thu, 28 Oct 2004 18:54:49 +0000
Date: Thu, 28 Oct 2004 15:53:04 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------jxcmzzcdpynymiatkxqa
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Predators<br><br>

<br> :)<img src="cid:qmsinzbumx.gif"><br>
<br>
</body></html>

----------jxcmzzcdpynymiatkxqa
Content-Type: image/gif; name="qmsinzbumx.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="qmsinzbumx.gif"
Content-ID: 

----------jxcmzzcdpynymiatkxqa
Content-Type: application/octet-stream; name="Dog.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Dog.zip"

----------jxcmzzcdpynymiatkxqa--

Delivery-date: Thu, 28 Oct 2004 14:42:16 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt
Date: Thu, 28 Oct 2004 10:39:52 -0400

--NextPart

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

	Title		: RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
	Author(s)	: J. Lang, et al.
	Filename	: draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt
	Pages		: 36
	Date		: 2004-10-27
	
This document describes protocol specific procedures for GMPLS
   (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
   ReserVation Protocol - Traffic Engineering) signaling extensions to
   support end-to-end LSP recovery (protection and restoration). A
   generic functional description of GMPLS recovery can be found in a
   companion document.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 27 Oct 2004 10:54:04 +0000
Date: Wed, 27 Oct 2004 12:52:23 +0200
From: ricciato <[email-masked]>
To: [email-masked]
CC: [email-masked], Ugo Monaco <[email-masked]>,  =?ISO-8859-1?Q?Daniele_Al=EC?= <[email-masked]>,  Alessio D'Achille <[email-masked]>, "Vishal Sharma" <[email-masked]>
Subject: update of JSA for inter-domain diverse path & some simulation results

Hi all,

please note that we have have updated the draft on the JSA  method for 
computing diverse paths in inter-domain.
We have also run some initial simulations on realistic topologies, 
comparing the 1) JSA approach (with ARO) with 2) the method based on 
RRO+XRO (called ISPA in the draft), and 3) the global optimum based on 
complete information.
We considered a few realistic topologies (details in the draft)
In summary the results show that :

- if a pair of diverse path exist, the JSA/ARO almost always find them 
at the first shot (it failed in 2-3 cases over thousands of simulation run)
- there are some topologies in which the ISPA/XRO is trapped at the 
first shot (and should therefore revert to cranckback), it happens 
approx. in 10% of cases
- when a pair of path is found by all the three methods, there is no 
substantial difference in the overall cost between JSA/ARO and optimum 
(we used min-hop metric), with a slight worse performance of ISPA/XRO

Please note that the performance of PCE should be the same as the global 
optimum (since it is computed assuming full global information and 
centralized computation).

Based on these preliminary results, we believe that the JSA/ARO approach 
should not be considered a competitor of PCE (which is provenly "the 
optimum"), but rather a secondary solution which achieves the same 
performances of the optimal method  "almost surely" in the practical 
cases  (still, it is possible to draw cases in which it fails, while 
PCE/optimum finds his way, but these cases seem to be not found in the 
realistic topologies we have investigated).
On the other hand the JSA/ARO  involves much  less information and 
signaling overhead...

In addition to the IETF site, the current version of the draft can be 
found at the following url. It includes quick  description of the 
simualtions and summary of preliminary results. It would be nice to have 
a short slot for presenting them at Washington DC, perhaps ....

We wellcome very much any feedback from the community that helps us in 
refining the simulation scenario (new topologies, suggestions for 
setting the scenario, etc.). Please do not hesitate to send you comment 
(particularly the criticisms, which are the most helpful ones for 
improving our work ...)

ciao
fabio

PS
the url for the draft is:

http://www.metanoia-inc.com/Publications/draft-dachille-diverse-inter-region-path-setup-01.txt

Delivery-date: Tue, 26 Oct 2004 19:59:17 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-segment-recovery-01.txt
Date: Tue, 26 Oct 2004 15:57:45 -0400

--NextPart

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

	Title		: GMPLS Based Segment Recovery
	Author(s)	: L. Berger, et al.
	Filename	: draft-ietf-ccamp-gmpls-segment-recovery-01.txt
	Pages		: 24
	Date		: 2004-10-26
	
This document describes protocol specific procedures for GMPLS
   (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
   ReserVation Protocol - Traffic Engineering) signaling extensions to
   support LSP segment protection and restoration.  These extensions are
   intended to be compliment and be consistent with the Extensions for
   End-to-End GMPLS-based Recovery.  Implications and interactions with
   Fast Reroute are also addressed.  This document also updates the
   handling of Notify_Request objects specified in [RFC3473].

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 26 Oct 2004 19:59:09 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt
Date: Tue, 26 Oct 2004 15:58:04 -0400

--NextPart

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

	Title		: Node ID based RSVP Hello: A Clarification Statement
	Author(s)	: Z. Ali, et al.
	Filename	: draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt
	Pages		: 7
	Date		: 2004-10-26
	
performed by some means other than exchanging RSVP Hello messages, 
   use of Node-ID based Hello session is optimal for detecting signaling 
   adjacency failure for Resource reSerVation Protocol-Traffic 
   Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear 
   and this document formalizes use of Node-ID based RSVP Hello session 
   as a best current practice (BCP) in some scenarios. The procedure 
   described in this document applies to both Multi-Protocol Label 
   Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 26 Oct 2004 14:39:31 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "MPLS" <[email-masked]>, "CCAMP" <[email-masked]>, "L2PPVPN" <[email-masked]>, "L3PPVPN" <[email-masked]>, "PWE3" <[email-masked]>
Cc: "Monique J. Morrow" <[email-masked]>, "Thomas Nadeau" <[email-masked]>, "Loa Andersson" <[email-masked]>
Subject: Deadline extended: "Inter-Provider Service Quality..." IEEE Comm. Mag. CFP
Date: Tue, 26 Oct 2004 07:37:22 -0700

Folks,

Due to responses from several quarters for this CFP, and the
authors requesting for more time to submit, we are happy to
let you know that the deadline for submission for this
Feature Topic issue has been extended up to:
**26 November 2004**.

So, we invite those working in this area who are considering
sending in their contributions, but were held back by the deadline
to rush to do so!

If you intend to submit a paper for this special issue, please do drop
one of the Guest Editors a
note, so that we can plan the issue.

We look forward to your continued participation!

Thanks,
-Vishal

=========================================================================
CALL FOR PAPERS
IEEE Communications Magazine

Feature Topic on
"Challenges in Enabling Inter-Provider Service Quality on the Internet"
*************************************************************************

** Submission deadline extended to 26 November 2004.**

As carriers and service providers build multi-services networks based on
IP/MPLS-
enabled infrastructures that are able to meet evermore stringent service
level
agreements (SLAs) and quality-of-service (QoS) requirements, it becomes a
key
issue to extend the ability to deliver these services across carrier and
service
provider domain boundaries, while at the same time preserving the same SLAs
and
QoS assurances as those provided within a given provider's network.

The advent of new end-user applications, as well as new services based on
MPLS  technology, such as Layer 2 Virtual Private LAN Services (VPLS) and
Layer 3 Virtual  Private Networks (L3VPNs), also means the emergence of
added service quality
requirements from operators deploying and interoperating these networks and
the
end-users themselves. As a result, providers and vendors require efficient
means to
enable inter-provider service quality, which comprises of several key
elements
including quality of service, class of service, security, OAM, and
restoration and
repair.

This will is lead to the emergence of improved or novel tools and techniques
to address these aspects, with the goal of guaranteeing service quality
end-to-end,
improving security and billing/accounting, and reducing operating costs.
Standards
organizations such as the IETF and the ITU are taking on significant work in
this
area, and various aspects of this subject are also being investigated by
bodies such
as the OIF, the MSF, the MPLS/Frame Relay Alliance, the IEEE, and the Metro
Ethernet Forum, and are the themes for numerous upcoming conferences.

This feature topic issue of the IEEE Communications Magazine has a
multi-pronged
focus on the delivery of inter-provider service quality:

*	Highlight operator and end-user concerns and requirements.
*	Feature current and/or planned deployment experiences.
*	Survey modern research and engineering developments.
*	Spotlight contemporary standards activity.

Thus, focused tutorial and survey contributions as well as research papers
are
solicited on (but certainly not limited to) the following topics:

*	Carrier requirements for efficient inter-provider service quality: Current
        operational needs, bottlenecks, future demands
*	Deployment experience with inter-provider service quality on IP/MPLS-
         based networks: comparative analysis, case studies
*	QoS management in an inter-provider environment: interconnection
        architectures using MPLS, Diffserv, QoS performance, path
        characterization, routing policies
*	Service assurance in inter-provider infrastructures: End-to-end SLA
        management, service billing/reporting, admission control
*	Failure and restoration requirements/challenges in inter-provider contexts
*	Interoperability and inter-working of diverse equipment types and
        technologies (ATM, FR, Ethernet)
*	Current engineering and research developments: E.g. Passive and active
        performance measurement and monitoring, TE, modelling and simulation
*	Standards activities and initiatives: new services and network
architectures

On-line CFP with submission instructions can be found at:
http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.htm

Submission

Articles should be tutorial in nature and should be written in a style
comprehensible
to readers outside the specialty of the article. Articles may be edited for
clarity  and grammatical accuracy, and will be copyedited according to the
Magazine's style.
Mathematical equations should not be used (in justified cases up to three
simple
equations could be allowed, provided there is consent of the Guest Editor;
more than
three equations require permission from the Editor-in-Chief). Articles
should have no
more than 4,500 words, no more than 6 tables/figures, and no more than 15
references. Guidelines for prospective authors can be found on-line at
http://www.comsoc.org/pubs/commag/sub_guidelines.html.

** Please submit no later than 26 November 2004.**
Accepted papers will also be included in Communications
Interactive (CI), the online version of Communications Magazine.

Manuscript Due:                                         **26 November 2004**
Acceptance Notification:                                 15 January  2004
Final Manuscript Due:                                    28 February 2005
Publication Date:                                        June  2005

(Deadline extended from 30th October 2004 to 26th November 2004.)

Guest Editors

Monique J. Morrow, Cisco Systems, ([email-masked])
Vishal Sharma, Metanoia, Inc. ([email-masked])
Thomas D.Nadeau, Cisco Systems ([email-masked])
Loa Andersson, Acreo ([email-masked])

****************************************************************
Vishal Sharma, Ph.D.
Metanoia, Inc. (Critical Systems Thinking)
888 Villa Street, Suite 200, Mountain View, CA 94041-1261
Phone: +1 650-641-0082. Fax: +1 650-641-0086
Email: [email-masked]. http://www.metanoia-inc.com
****************************************************************

Delivery-date: Mon, 25 Oct 2004 12:44:36 +0000
Date: Mon, 25 Oct 2004 21:43:59 +0900
From: Tomohiro Otani <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: Basic agenda structure for Washington DC

Hi everyone,

We have updated the GMPLS inter-AS TE document, following the discussion
in the last IETF meeting.

/http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.txt/

We welcome your comments and feedback until the meeting as well as in
the meeting.

With best regards,

tomo

----------------------------------------------
Tomo Otani
KDDI R&D Laboratories, Inc.

>
>We have updated two documents related to L1VPNs, and would like to discuss 
>them as part of L1VPN slot in the proposed basic agenda.
>
>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt
>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt 
>(should be available soon)
>
>Also :
>http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt
>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt
>
>
>For information, here is status update.
>
>o Framework ID:
>    http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt
>    - Terminology refinement (section 2 and throughout the document)
>    - Security considerations (section 9)
>    - Further clarification on service models (sections 7.2 and 7.3)
>
>o Applicability ID:
>    http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt 
>(should be available soon)
>    - Addition of a new co-author (Deborah Brungard)
>    - Itemization and preliminary analysis of several alternatives (if any) 
>as guidelines for filling the gap between existing GMPLS and required 
>functions for L1VPNs
>    - Addition of network usage of L1VPN service models as additional 
>information (appendix)
>    - Addition of security management (section 8.3)
>    - Merge of "Overlay Service Model" and "Overlay Extension Service 
>Model" (section 6)
>
>Comments are highly appreciated.
>
>At 12:11 04/10/08 +0100, Adrian Farrel wrote:
>>Hi,
>>
>>Since San Diego, we have managed to move on quite well with our existing 
>>milestones,
>>commitments and drafts.
>>
>>So, the basic agenda structure for Washington DC is as follows:
>>
>>Admin and WG status
>>ASON Solutions
>>Protection solutions
>>Inter-domain
>>     Basic
>>     MRN
>>     Diverse path
>>New work
>>    MPLS/GMPLS migration
>>    L1VPN
>>    Others
>>Rechartering
>>
>>If you would like a slot, please ask and we will attempt to construct an agenda.
>>Editors/authors or WG drafts may expect to be asked by the chairs to 
>>present on the
>>status, issues and next steps for their drafts.
>>
>>Thanks,
>>Adrian
>
>-----
>Tomonori TAKEDA
>NTT Network Service Systems Lab.
>Phone: +81-422-59-7434
>
>
>
>  
>

Delivery-date: Mon, 25 Oct 2004 12:44:28 +0000
Date: Mon, 25 Oct 2004 14:44:04 +0200
From: [email-masked]
Subject: request for a slot for Washington DC
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Hi Adrian,

we have submitted a reviewed version of our draft "draft-dachille-inter-r=
egion-path-setup"
before the deadline of 25th October. The diverse path issue is an explici=
t
topic proposed for this meeting and since our work directly address this
problem and was asked to be discussed at a subsequent IETF, we kindly ask=

for a slot in the CCAMP Agenda in Washington DC.  In this version we have=

included a report describing the results of a series of simulation tests
that we have performed on JSA; these results enforce our considerations
about our approach and other approaches and we would like to present a su=
mmary
of these results in Washington.

We look forward your answer.

Thank you for your kind attention.

Best Regards,
Alessio D'Achille,

Delivery-date: Mon, 25 Oct 2004 12:08:29 +0000
Date: Mon, 25 Oct 2004 21:05:35 +0900
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
From: Tomonori TAKEDA <[email-masked]>
Subject: Re: Basic agenda structure for Washington DC

Hi,

We have updated two documents related to L1VPNs, and would like to discuss 
them as part of L1VPN slot in the proposed basic agenda.

http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt 
(should be available soon)

Also :
http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt

For information, here is status update.

o Framework ID:
    http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt
    - Terminology refinement (section 2 and throughout the document)
    - Security considerations (section 9)
    - Further clarification on service models (sections 7.2 and 7.3)

o Applicability ID:
    http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt 
(should be available soon)
    - Addition of a new co-author (Deborah Brungard)
    - Itemization and preliminary analysis of several alternatives (if any) 
as guidelines for filling the gap between existing GMPLS and required 
functions for L1VPNs
    - Addition of network usage of L1VPN service models as additional 
information (appendix)
    - Addition of security management (section 8.3)
    - Merge of "Overlay Service Model" and "Overlay Extension Service 
Model" (section 6)

Comments are highly appreciated.

At 12:11 04/10/08 +0100, Adrian Farrel wrote:
>Hi,
>
>Since San Diego, we have managed to move on quite well with our existing 
>milestones,
>commitments and drafts.
>
>So, the basic agenda structure for Washington DC is as follows:
>
>Admin and WG status
>ASON Solutions
>Protection solutions
>Inter-domain
>     Basic
>     MRN
>     Diverse path
>New work
>    MPLS/GMPLS migration
>    L1VPN
>    Others
>Rechartering
>
>If you would like a slot, please ask and we will attempt to construct an agenda.
>Editors/authors or WG drafts may expect to be asked by the chairs to 
>present on the
>status, issues and next steps for their drafts.
>
>Thanks,
>Adrian

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: +81-422-59-7434

Delivery-date: Mon, 25 Oct 2004 03:43:17 +0000
Date: Sun, 24 Oct 2004 23:41:22 -0400
To: [email-masked]
From: Alia Atlas <[email-masked]>
Subject: Re: Your input: Use of PCE in Inter-domain

I think that the PCE is addressing an important inter-domain problem.  The 
architecture given seems to provide a good framework to address this 
problem; clearly there are a number of details to be worked out.

Alia

At 03:11 PM 10/19/2004, Adrian Farrel wrote:
>Folks,
>The chairs and ADs would like your input on 
>http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in 
>the context of our inter-domain traffic engineering work.
>This draft documents an architecture for Path Computation Elements (PCE) 
>and is currently being discussed on the pce mailing list 
>(https://www1.ietf.org/mailman/listinfo/pce)
>What we would like CCAMP to do is give us your opinion on whether PCE is 
>addresing an inter-domain problem that needs to be addressed, and if so 
>whether the architecture provides an acceptable way to resolve the problem.
>Answers to the mailing list in advance of the meeting in Washington would 
>be appreciated.
>Thanks,
>Adrian and Kireeti
>

Delivery-date: Sun, 24 Oct 2004 14:39:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Proposed liaison to ITU-T SG15/Q14 About GMPLS MIB Modules
Date: Sun, 24 Oct 2004 14:25:13 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0854_01C4B9D5.469EC780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

The ITU-T's study group 15 is responsible for deriving a management =
structure for the ASON architecture. In view of this, we should liaise =
the GMPLS MIBs to them for input and information.

Please comment on the attached liaison statement which I intend to send =
on Friday 29th.

Thanks,
Adrian

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

To:           Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study =
Group 15.
From:         Adrian Farrel and Kireeti Kompella
              Co-chairs of the CCAMP Working Group of the IETF
Cc:           Alex Zinin and Bill Fenner, Routing Area Directors of the =
IETF
For:          Action
Deadline:     15th December 2004
Subject:      GMPLS MIB Modules
=20
Dear Mr. Lam,

The IETF's CCAMP Working Group has been working to develop MIB modules =
to facilitate the configuration and monitoring of GMPLS LSRs and Traffic =
Engineered Tunnels (LSPs).

The work on these MIB modules is nearing completion and, considering =
that you Question has a task to work on management issues for the ASON =
architecture, we would appreciate your input to the drafts at this =
stage.

A timely response will allow us to include consideration of any points =
that you raise in the last and probably final revision of the drafts.

For reference, the objects modeled in these MIB modules may be =
considered as connection segments (LSPs) and connection controllers =
(LSRs) in the ASON architecture. There is no intention to model calls or =
call controllers in this version of the drafts, although such function =
might be added in a later set of MIB modules.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Att/
draft-ietf-ccamp-gmpls-tc-mib-06.txt
draft-ietf-ccamp-gmpls-lsr-mib-06.txt
draft-ietf-ccamp-gmpls-te-mib-06.txt
------=_NextPart_000_0854_01C4B9D5.469EC780
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>The ITU-T's study group 15 is =
responsible for=20
deriving a management structure for the ASON architecture. In view of =
this, we=20
should liaise the GMPLS MIBs to them for input and =
information.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Please comment on the attached =
liaison statement=20
which I intend to send on Friday 29th.</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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp; Mr. Kam Lam, Rapporteur for Question 14 of =
ITU-T Study=20
Group 15.<BR>From:&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Adrian =
Farrel and=20
Kireeti=20
Kompella<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
Co-chairs of the CCAMP Working Group of the IETF<BR>Cc:=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alex Zinin and =
Bill=20
Fenner, Routing Area Directors of the=20
IETF<BR>For:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;=20
Action<BR>Deadline:&nbsp;&nbsp;&nbsp;&nbsp; 15th December=20
2004<BR>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GMPLS MIB=20
Modules<BR>&nbsp;<BR>Dear Mr. Lam,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The IETF's CCAMP Working Group has =
been working=20
to develop MIB modules to facilitate the configuration and monitoring of =
GMPLS=20
LSRs and Traffic Engineered Tunnels (LSPs).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The work on these MIB modules is =
nearing=20
completion and, considering that you Question has a task to work on =
management=20
issues for the ASON architecture, we would appreciate your input to the =
drafts=20
at this stage.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>A timely response will allow us to =
include=20
consideration of any points that you raise in the last and probably =
final=20
revision of the drafts.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>For reference, the objects modeled in =
these MIB=20
modules may be considered as connection segments (LSPs) and connection=20
controllers (LSRs) in the ASON architecture. There is no intention to =
model=20
calls or call controllers in this version of the drafts, although such =
function=20
might be added in a later set of MIB modules.</DIV>
<DIV>&nbsp;</DIV>
<DIV></FONT><FONT face=3DCourier size=3D2>Sincerely,<BR>Kireeti Kompella =
&amp;=20
Adrian Farrel, CCAMP WG chairs<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Att/</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>draft-ietf-ccamp-gmpls-tc-mib-06.txt</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>draft-ietf-ccamp-gmpls-lsr-mib-06.txt</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>draft-ietf-ccamp-gmpls-te-mib-06.txt</DIV></FONT></BODY></HTML>

------=_NextPart_000_0854_01C4B9D5.469EC780--

Delivery-date: Sat, 23 Oct 2004 18:07:25 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: BCP 96,RFC 3936 on Procedures for Modifying the Resource reSerVationProtocol (RSVP)
Date: Sat, 23 Oct 2004 19:03:06 +0100

You will want to be aware of this RFC if you are working on extensions to RSVP-TE for
GMPLS.

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 22, 2004 10:45 PM
Subject: BCP 96,RFC 3936 on Procedures for Modifying the Resource reSerVationProtocol
(RSVP)

>
> A new Request for Comments is now available in online RFC libraries.
>
>
>         BCP 96
>         RFC 3936
>
>         Title:      Procedures for Modifying the Resource reSerVation
>                     Protocol (RSVP)
>         Author(s):  K. Kompella, J. Lang
>         Status:     Best Current Practice
>         Date:       October 2004
>         Mailbox:    [email-masked], [email-masked]
>         Pages:      7
>         Characters: 15314
>         Updates:    3209, 2205
>         SeeAlso:    BCP 96
>
>         I-D Tag:    draft-kompella-rsvp-change-02.txt
>
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3936.txt
>
>
> This memo specifies procedures for modifying the Resource reSerVation
> Protocol (RSVP).  This memo also lays out new assignment guidelines
> for number spaces for RSVP messages, object classes, class-types, and
> sub-objects.
>
> This document specifies an Internet Best Current Practices for the
> Internet Community, and requests discussion and suggestions for
> improvements.  Distribution of this memo is unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
> help: ways_to_get_rfcs.  For example:
>
>         To: [email-masked]
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions to RFC
> Authors, for further information.
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
>
> ...
>
> Below is the data which will enable a MIME compliant Mail Reader
> implementation to automatically retrieve the ASCII version
> of the RFCs.
>

Delivery-date: Fri, 22 Oct 2004 20:24:50 +0000
Cc: <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: PCE capabilities
Date: Fri, 22 Oct 2004 16:24:18 -0400
To: "Igor Bryskin" <[email-masked]>

Hi Igor,

On Oct 22, 2004, at 4:00 PM, Igor Bryskin wrote:

> Hi,
>
> I wonder if it would be a good idea for a PCE to advertise among other
> things the list of areaIDs/ AS numbers that it covers. Then a PCE can 
> select
> proper PCE(s) to work with, provided that it can identify (with the 
> help of
> routing) the area/AS of the path computation target. To go a step 
> further a
> PCE may separate areas/ASs that it covers directly (because it is 
> within
> their TE visibility) from those covered indirectly (because it learned 
> about
> other PCEs taking care of such areas/ASs).
>

Really nice to see that we're in sync. In the TE-related ID, such 
sub-TLV are defined.

Thanks for the discussion, by the way, we still need to discuss about 
GMPLS specific extensions.

Cheers.

JP.

> Igor
>
>
>

Delivery-date: Fri, 22 Oct 2004 20:04:22 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Fw: PCE capabilities
Date: Fri, 22 Oct 2004 16:04:11 -0400

Sorry, I meant a PCC/PCE can select proper PCEs to perform path computation.

----- Original Message ----- 
From: "Igor Bryskin" <[email-masked]>
To: "JP Vasseur" <>; "Adrian Farrel" <>; <>
Cc: "Adrian Farrel" <[email-masked]>; "Dimitri Papadimitriou"
<[email-masked]>; <>
Sent: Friday, October 22, 2004 4:00 PM
Subject: PCE capabilities

> Hi,
>
> I wonder if it would be a good idea for a PCE to advertise among other
> things the list of areaIDs/ AS numbers that it covers. Then a PCE can
select
> proper PCE(s) to work with, provided that it can identify (with the help
of
> routing) the area/AS of the path computation target. To go a step further
a
> PCE may separate areas/ASs that it covers directly (because it is within
> their TE visibility) from those covered indirectly (because it learned
about
> other PCEs taking care of such areas/ASs).
>
> Igor
>

Delivery-date: Fri, 22 Oct 2004 20:00:34 +0000
From: "Igor Bryskin" <[email-masked]>
To: "JP Vasseur" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>
Subject: PCE capabilities
Date: Fri, 22 Oct 2004 16:00:05 -0400

Hi,

I wonder if it would be a good idea for a PCE to advertise among other
things the list of areaIDs/ AS numbers that it covers. Then a PCE can select
proper PCE(s) to work with, provided that it can identify (with the help of
routing) the area/AS of the path computation target. To go a step further a
PCE may separate areas/ASs that it covers directly (because it is within
their TE visibility) from those covered indirectly (because it learned about
other PCEs taking care of such areas/ASs).

Igor

Delivery-date: Fri, 22 Oct 2004 19:32:15 +0000
Date: Thu, 21 Oct 2004 19:44:24 -0700
To: "Adrian Farrel" <[email-masked]>, [email-masked]
From: raymond zhang <[email-masked]>
Subject: Re: Your input: Use of PCE in Inter-domain
Cc: [email-masked], [email-masked]

Hi,

A PCE-based solution, as documented in "draft-ash-pce-architecture-00.txt" 
provides an acceptable solution to address # of requirements in dynamically 
establishing optimized inter-domain TE LSPs which would otherwise become 
unmanageable as the interconnect density increases in both # of 
interconnections per provider pair and # of provider interconnects.

Regards,
Raymond

At 12:11 PM 10/19/2004, Adrian Farrel wrote:
>Folks,
>The chairs and ADs would like your input on 
>http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in 
>the context of our inter-domain traffic engineering work.
>This draft documents an architecture for Path Computation Elements (PCE) 
>and is currently being discussed on the pce mailing list 
>(https://www1.ietf.org/mailman/listinfo/pce)
>What we would like CCAMP to do is give us your opinion on whether PCE is 
>addresing an inter-domain problem that needs to be addressed, and if so 
>whether the architecture provides an acceptable way to resolve the problem.
>Answers to the mailing list in advance of the meeting in Washington would 
>be appreciated.
>Thanks,
>Adrian and Kireeti
>
>
>

Delivery-date: Fri, 22 Oct 2004 15:35:53 +0000
content-class: urn:content-classes:message
Subject: RE: Your input: Use of PCE in Inter-domain
Date: Fri, 22 Oct 2004 10:34:59 -0500
From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>, <[email-masked]>

Adrian, Kireeti, All,

I believe that the PCE approach is a valid approach to meeting
inter-domain TE requirements.  Several SPs (Infonet, KDDI, France
Telecom, NTT, AT&T, Telefonica, MCI) provided requirements at the IETF60
PCE BOF supporting the PCE architecture in an inter-domain application
(see minutes at http://ietf.org/proceedings/04aug/index.html).  AT&T's
requirements are summarized in
http://ietf.org/proceedings/04aug/slides/pce-0/sld16.htm and include PCE
support for inter-area/AS/SP TE.  The PCE architecture document
addresses these requirements quite well.

Thanks,
Jerry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, October 19, 2004 3:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Your input: Use of PCE in Inter-domain

Folks,=20

The chairs and ADs would like your input on=20
http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in
the=20
context of our inter-domain traffic engineering work.=20

This draft documents an architecture for Path Computation Elements (PCE)
and=20
is currently being discussed on the pce mailing list=20
(https://www1.ietf.org/mailman/listinfo/pce)=20

What we would like CCAMP to do is give us your opinion on whether PCE is

addresing an inter-domain problem that needs to be addressed, and if so=20
whether the architecture provides an acceptable way to resolve the
problem.=20

Answers to the mailing list in advance of the meeting in Washington
would be=20
appreciated.=20

Thanks,
Adrian and Kireeti

Delivery-date: Fri, 22 Oct 2004 13:50:48 +0000
To: JP Vasseur <[email-masked]>, Adrian Farrel <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, Dimitri Papadimitriou <[email-masked]>, <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
From: [email-masked]
Subject: Re: Your input: Use of PCE in Inter-domain
Date: Fri, 22 Oct 2004 15:48:59 +0200

hi jp and adrian:

--> see in-line [dp]

Hi Dimitri and Adrian,

On Oct 22, 2004, at 12:23 AM, Adrian Farrel wrote:

> Thanks Dimitri,
>
> Looks like you had a profitable flight back from Washington!
>
>> hi all, let's probably speak first about which problem we are trying
>> to address here and look at what a PCE approach would provide
>
> Yes. This is important. We need to identify the problem space we are
> trying to address and the specific problem within that space. If we
> cannot do this we cannot justify the work on PCE.

Indeed - Dimitri please note the SP's presentation during the PCE. Many
of them presented by requirements *and* the problem space quite clearly.

[dp] indeed, i see a set of applications that needs to be structured in a
consistent way in order to define what the group has to produce and the
effort it is expected to deliver - as such one of the discussion point is
for which purpose this effort requires a standard approach -

>> as (by definition) a PCE enlarges the path computation domain scope
>> behind the local routing domain/system, it allows the requestor
>> included in this routing domain/system, to obtain the result of this
>> better PCE visibility from the one the requestor would have had himself
>> if it would have performed the same path computation task, so the
>> inter-domain problem takes then multiple aspects:
>>
>> - case 1. multi-area basis one can assume that the PCE entity can have
>> such better visibility, so here the questions are twofold how better
>> should this visibility be from what the routing provides and how it is
>> self - impacting (what is the right level of details the PCE needs to
>> have to accomplish what it is expected to deliver)
>
> Agree. It does not follow that the PCE consulted has full visibility.
> Nor does it even follow that cooperating PCEs achieve full visibility.
> The only assumption is that the visibility (and therefore the optimality
> or success likelihood of the LSP) is increased.

There are indeed multiple cases here ... In some case, it has the full
visibility (Head-end and Tail-end located in locally attached area), in
other cases, it could get rely of collaboration between PCEs, in other
case, it could have full visibility (for inter-area).

>> - case 2. multi-AS (single provider) basis the issue is different as
>> one could assume that the local PCE will be able to determine what is
>> the best entry point (and the network capabilities to which it gives
>> access) to the next AS for a given set of request towards e.g. reachable
>> prefixes, AS paths, etc.
>
> I don't completely agree. It depends on "best". The local PCE may be
> able to select the best TE path to an entry point to the next AS, and
> even a least cost metric influence to the choice of that entry point
> given the reachability through the next AS, BUT from a TE perspective
> the local PCE cannot select
> - the next AS
> - the best entry point into the next AS
> This requires TE information that is not currently known to the local
> PCE. Thus a multi-PCE approach is likely.

indeed

[dp] there are several levels where this collaboration can happen and the
first (after none) is that both of us listed but the point is that do we
want
to make it available via PCE exchange since it does not necessarily mean
that
the PCE of both ASs have to directly communicate for this reason (also the
PCE is not going to manage these entry points himself so the sync about
their status raise the same problem in both cases) - note also that there
is a transitivity issue that may have to be addressed here -

>> - case 3. multi-AS (multi-provider) basis the issue is also different
>> as the primary assumption would be that any exchange of such information
>> will be restricted if not excluded without any prior agreement between
>> operators and then only one could assume that the case 2. applies
>
> Yes. Confidentiality is a significant constraint to any solution. But
> recall that the only exchange between PCEs might be limited to request
> and response (not to TED information). There are two interesting
solutions
> that spring to mind (that would need to be added to the architecture).
> 1. Vertical inter-PCE communication
> That is a hierarchical relationship of PCEs rather than a peering
> relationship. This would allow a trusted party to do the work. (But note
> that an ERO might violate confidentiality)
> 2. The use of cookies or encryption in EROs so that the ERO is only
> expanded to the computed path at the ASBR.

[dp] the last method raises the issue of moving the problem into another
space so would require to address them until some extend

Yes, in addition other solutions already exist which all preserve
confidentiality and allows for inter-domain shortest paths computation
without requiring any (summarized of not) leaking between domains of
course.

[dp] in these solutions that exist (where ?) would you tell whether domain
applies to AS or area ?

>> there are also several assumptions that should also be made in order
>> to result in a reasonable working item:
>> 1. the PCE to contact is known in advance by the requestor in case
>>    there are multiple PCEs that can be queried (and no other
>>    assumption are made upon their sync in terms of topological
>>    information) i would like to point out here that in case of
>>    multiple PCEs, the sync of PCE raises the same class of issues as
>>    the initial problem it intents to solve
>
> I agree that PCE "discovery" and selection need to be covered. I do not
> believe that they are rocket science within an area.

Note that solutions have been proposed for inter-area and must be
further worked out for inter-AS.

> Inter PCE choice may be harder, but DNS seems to handle similar issues.
>
> I disagree that synchronisation of PCEs is a substantial issue.

Agree with your disagreement. This might be required for some architecture
and be absolutely not required in others.

[dp] i said "sync of PCE raises the same class of issues as the initial
problem it intents to solve" i do not say it is a *more* substantial issue
than the problem it tries to solve, i say that these issues turns around a
similar class of problems in case of multiple PCEs: sync., discovery,
selection, redundancy, information validity, timing, etc.

[dp] concerning the point you raise "This might be required for some
architecture and be absolutely not required in others" it would be imho
really an issue to start with the simplest problems by ignoring that much
more complex issues can happen/raise in others

> We already have this problem with MPLS PCEs (that is, ingress LSRs) since
> a. The TED relies on
>     i.   IGP convergence
>     ii.  threshold dampening in the advertising LSRs
> b. To LSPs could be initiated from different ingresses at the same time
>    targeting the same resource
> Thus, I don't believe we have any new concerns. An LSP setup may fail
> and need to have its computation retried.

Agree

[dp] see above - it is not new - my point is that these are now moved
within the "PCE space"

>> 2. the approach consisting in having a query sequence
>>     PCC->PCE[1]->PCE[2]->...->PCE[n]
>>     has the same limitations as the three cases listed here above (in
>>     brief PCC and PCE[i], i =< n should belong to the same AS, (note:
>>     case 2 can be considered as a particular case here)
>
> Why is this?
> PCE[i] can request of PCE[i+1] if there is some form of "trust"
> relationship.
> This may be horizontal or vertical.

[dp] should start probably to put this on paper to have a more formal view
of the problem scope, would be beneficial imho

> There must be at least limited trust since an LSP service is to be
> provided!
>
>> 3. related to the above, it should be considered that the local AS
>>    is unaware and so its decisions are independent from the potential
>>    use of a PCE approach by the peering AS is also using a PCE approach
>>    (or vice versa), this implies that the PCC makes a request to a PCE
>>    that MAY be further decomposed but this is not within the knowledge
>>    scope of the PCC i.e. PCC should be assumed to be unaware of the
>>    PCE relationship (if any existing within a single AS)
>
> Ah, now this is a VERY good point. If I understand you right, you ask
> how we set up an LSP if the source domain uses PCE but the next domain
> does not.
>
> Firstly, we are no worse off than we are today (i.e. we can still target
> a domain boundary node with a loose hop to the destination).

[dp] true (note: my point is that this needs to be taken account)

> We would discover that this needed to be done when the local PCE found
> that it did not know about (or could not find) a PCE for the next domain.
> The local PCE would return a loose ERO.
>
> Note that the local PCE might know about PCEs in the next-next domain
> and contact them and add to the ERO accordingly.
>
> We might need to be careful not to bias the path selection according
> to PCE existence since that might miss some optimal paths.

Moreover, multiple path computations may be adopted in different
domains, although an optimal path can no longer be guaranteed but
fall-back approaches are usually to cope with this case and piggybacked
this information of the path computation method used in each domain in
the signaling.

>> 4. a PCE having a better visibility also implies it has a set of corr.
>>    path computation capabilities so question happens to be what is the
>>    minimum set of capabilities we have to assume to make such an
approach
>>    workable and interoperable ?
>
> Do we have to determine that list before we decide whether PCE is
> worth investigating?

[dp] no, but this could be part of the work items to achieve so

> Seems to me we have to decide to start the work in order to do this.

PCE capability can be learned dynamically by means of appropriate IGP
extensions

> A reasonable compromise would certainly be to have CCAMP work on the
> requirements for this and pass them to a new/existing WG that works
> on PCE.

Fully in sync with you Adrian

[dp] this seems reasonable -

>> last, it becomes clearer now that the RSVP constraint passing approach
>> should be the primary focus of the CCAMP since the PCE approach (in
>> particular for the multi-AS cases) is workable iff such constraints
>> can be exchanged during the resource reservation phase -
>
> I absolutely agree/disagree. It depends what you mean by
> "constraint-passing".

[dp] the same as the below 2 (those that would ideally be used at any
subsequent computation) and 3 (those that MUST be used at subsequent
computations), in this case

> We currently pass various constraints that are used both for path
> computation and for resource reservation.
>
> During path computation there are four types of constraint
> 1. those that apply only at the ingress computation
> 2. those that would ideally be used at any subsequent computation

Note that 1. and 2. are rarely disjoint ;-)

> 3. those that MUST be used at subsequent computations
> 4. those that are needed for resource reservation

3 and 4 may indeed may not identical

> Clearly 4. must be signalled

[dp] and 4. should be outside the scope of the PCE effort

> Full PCE cooperation can result in only one computation being
> necessary except in legacy (non-PCE) networks. In this case, signalling
> additional constraints will not help. But I would not want to rule out
> multiple computations and would  expect to investigate classes 2 and 3
> further.

Yes and this is probably one of the items that the potential PCE WG
should focus one.

[dp] this task implying constraint-passing is mainly part of the CCAMP WG
multi-domain effort imho -

> Thanks to you to for your detailed thought about this.
> But I am not sure how to interpret your response.
>
> Yes/no/maybe?

[dp] within the current visibility of the problem statement:
case 1: Yes
case 2: "Maybe" (imho also requires more details the problem and the
        involved architectural issues - as we have many operators in the
        loop probably a good opportunity here to ask about their thought
        on this),
case 3: Not for the time being

note: nothing prevents from taking this as a first step and see how to make
progress

in any case it would be helful that the group takes into account the above
working assumptions for this effort to result in a reasonable working item

Delivery-date: Fri, 22 Oct 2004 11:37:31 +0000
Cc: "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: Your input: Use of PCE in Inter-domain
Date: Fri, 22 Oct 2004 07:35:32 -0400
To: Adrian Farrel <[email-masked]>, Dimitri Papadimitriou <[email-masked]>

Hi Dimitri and Adrian,

On Oct 22, 2004, at 12:23 AM, Adrian Farrel wrote:

> Thanks Dimitri,
>
> Looks like you had a profitable flight back from Washington!
>
>> hi all, let's probably speak first about which problem we are trying  
>> to
>> address here and look at what a PCE approach would provide
>
> Yes. This is important. We need to identify the problem space we are  
> trying to address and
> the specific problem within that space. If we cannot do this we cannot  
> justify the work on
> PCE.
>

Indeed - Dimitri please note the SP's presentation during the PCE. Many  
of them presented by requirements *and* the problem space quite  
clearly.

>> as (by definition) a PCE enlarges the path computation domain scope
>> behind the local routing domain/system, it allows the requestor  
>> included
>> in this routing domain/system, to obtain the result of this better PCE
>> visibility from the one the requestor would have had himself if it  
>> would
>> have performed the same path computation task, so the inter-domain
>> problem takes then multiple aspects:
>>
>> - case 1. multi-area basis one can assume that the PCE entity can have
>> such better visibility, so here the questions are twofold how better
>> should this visibility be from what the routing provides and how it is
>> self - impacting (what is the right level of details the PCE needs to
>> have to accomplish what it is expected to deliver)
>
> Agree. It does not follow that the PCE consulted has full visibility.  
> Nor does it even
> follow that cooperating PCEs achieve full visibility. The only  
> assumption is that the
> visibility (and therefore the optimality or success likelihood of the  
> LSP) is increased.
>

There are indeed multiple cases here ... In some case, it has the full  
visibility (Head-end and Tail-end located in locally attached area), in  
other cases, it could get rely of collaboration between PCEs, in other  
case, it could have full visibility (for inter-area).

>> - case 2. multi-AS (single provider) basis the issue is different as  
>> one
>> could assume that the local PCE will be able to determine what is the
>> best entry point (and the network capabilities to which it gives  
>> access)
>> to the next AS for a given set of request towards e.g. reachable
>> prefixes, AS paths, etc.
>
> I don't completely agree. It depends on "best". The local PCE may be  
> able to select the
> best TE path to an entry point to the next AS, and even a least cost  
> metric influence to
> the choice of that entry point given the reachability through the next  
> AS, BUT from a TE
> perspective the local PCE cannot select
> - the next AS
> - the best entry point into the next AS
> This requires TE information that is not currently known to the local  
> PCE. Thus a
> multi-PCE approach is likely.
indeed
>
>> - case 3. multi-AS (multi-provider) basis the issue is also different  
>> as
>> the primary assumption would be that any exchange of such information
>> will be restricted if not excluded without any prior agreement between
>> operators and then only one could assume that the case 2. applies
>
> Yes. Confidentiality is a significant constraint to any solution. But  
> recall that the
> only exchange between PCEs might be limited to request and response  
> (not to TED
> information). There are two interesting solutions that spring to mind  
> (that would need to
> be added to the architecture).
> 1. Vertical inter-PCE communication
> That is a hierarchical relationship of PCEs rather than a peering  
> relationship. This would
> allow a trusted party to do the work. (But note that an ERO might  
> violate confidentiality)
> 2. The use of cookies or encryption in EROs so that the ERO is only  
> expanded to the
> computed path at the ASBR.
>
Yes, in addition other solutions already exist which all preserve  
confidentiality and allows for inter-domain shortest paths computation  
without requiring any (summarized of not) leaking between domains of  
course.
>> there are also several assumptions that should also be made in order  
>> to
>> result in a reasonable working item:
>> 1. the PCE to contact is known in advance by the requestor in case
>>     there are multiple PCEs that can be queried (and no other  
>> assumption
>>     are made upon their sync in terms of topological information) i  
>> would
>>     like to point out here that in case of multiple PCEs, the sync of  
>> PCE
>>     raises the same class of issues as the initial problem it intents  
>> to
>>     solve
>
> I agree that PCE "discovery" and selection need to be covered. I do  
> not believe that they
> are rocket science within an area.
Note that solutions have been proposed for inter-area and must be  
further worked out for inter-AS.
>  Inter PCE choice may be harder, but DNS seems to handle
> similar issues.
>
> I disagree that synchronisation of PCEs is a substantial issue.
Agree with your disagreement. This might be required for some  
architecture and be absolutely not required in others.
> We already have this
> problem with MPLS PCEs (that is, ingress LSRs) since
> a. The TED relies on
>     i.   IGP convergence
>     ii.  threshold dampening in the advertising LSRs
> b. To LSPs could be initiated from different ingresses at the same
>     time targeting the same resource
> Thus, I don't believe we have any new concerns. An LSP setup may fail  
> and need to have its
> computation retried.
Agree
>
>> 2. the approach consisting in having a query sequence
>>     PCC->PCE[1]->PCE[2]->...->PCE[n]
>>     has the same limitations as the three cases listed here above (in
>>     brief PCC and PCE[i], i =< n should belong to the same AS, (note:
>>     case 2 can be considered as a particular case here)
>
> Why is this?
> PCE[i] can request of PCE[i+1] if there is some form of "trust"  
> relationship.
> This may be horizontal or vertical.
> There must be at least limited trust since an LSP service is to be  
> provided!
>
>> 3. related to the above, it should be considered that the local AS
>>     is unaware and so its decisions are independent from the potential
>>     use of a PCE approach by the peering AS is also using a PCE  
>> approach
>>     (or vice versa), this implies that the PCC makes a request to a  
>> PCE
>>     that MAY be further decomposed but this is not within the  
>> knowledge
>>     scope of the PCC i.e. PCC should be assumed to be unaware of the  
>> PCE
>>     relationship (if any existing within a single AS)
>
> Ah, now this is a VERY good point. If I understand you right, you ask  
> how we set up an LSP
> if the source domain uses PCE but the next domain does not.
>
> Firstly, we are no worse off than we are today (i.e. we can still  
> target a domain boundary
> node with a loose hop to the destination). We would discover that this  
> needed to be done
> when the local PCE found that it did not know about (or could not  
> find) a PCE for the next
> domain. The local PCE would return a loose ERO.
>
> Note that the local PCE might know about PCEs in the next-next domain  
> and contact them and
> add to the ERO accordingly.
>
> We might need to be careful not to bias the path selection according  
> to PCE existence
> since that might miss some optimal paths.
>

Moreover, multiple path computations may be adopted in different  
domains, although an optimal path can no longer be guaranteed but  
fall-back approaches are usually to cope with this case and piggybacked  
this information of the path computation method used in each domain in  
the signaling.

>> 4. a PCE having a better visibility also implies it has a set of corr.
>>     path computation capabilities so question happens to be what is  
>> the
>>     minimum set of capabilities we have to assume to make such an
>>     approach workable and interoperable ?
>
> Do we have to determine that list before we decide whether PCE is  
> worth investigating?
> Seems to me we have to decide to start the work in order to do this.
>
PCE capability can be learned dynamically by means of appropriate IGP  
extensions
> A reasonable compromise would certainly be to have CCAMP work on the  
> requirements for
> this and pass them to a new/existing WG that works on PCE.
Fully in sync with you Adrian
>
>> last, it becomes clearer now that the RSVP constraint passing approach
>> should be the primary focus of the CCAMP since the PCE approach (in
>> particular for the multi-AS cases) is workable iff such constraints  
>> can
>> be exchanged during the resource reservation phase -
>
> I absolutely agree/disagree. It depends what you mean by  
> "constraint-passing".
> We currently pass various constraints that are used both for path  
> computation and for
> resource reservation.
>
> During path computation there are four types of constraint
> 1. those that apply only at the ingress computation
> 2. those that would ideally be used at any subsequent computation
>
Note that 1. and 2. are rarely disjoint ;-)
> 3. those that MUST be used at subsequent computations
> 4. those that are needed for resource reservation
>
3 and 4 may indeed may not identical
> Clearly 4. must be signalled
> Full PCE cooperation can result in only one computation being  
> necessary except in legacy
> (non-PCE) networks. In this case, signalling additional constraints  
> will not help.
> But I would not want to rule out multiple computations and would  
> expect to investigate
> classes 2 and 3 further.
Yes and this is probably one of the items that the potential PCE WG  
should focus one.
>
>> thanks,
>> - dimitri.
>

JP.

> Thanks to you to for your detailed thought about this.
> But I am not sure how to interpret your response.
>
> Yes/no/maybe?
>
> Adrian
>> ---
>>
>> Adrian Farrel wrote:
>>> Folks,
>>> The chairs and ADs would like your input on
>>> http://www.ietf.org/internet-drafts/draft-ash-pce-architecture 
>>> -00.txt in
>>> the context of our inter-domain traffic engineering work.
>>> This draft documents an architecture for Path Computation Elements  
>>> (PCE)
>>> and is currently being discussed on the pce mailing list
>>> (https://www1.ietf.org/mailman/listinfo/pce)
>>> What we would like CCAMP to do is give us your opinion on whether  
>>> PCE is
>>> addresing an inter-domain problem that needs to be addressed, and if  
>>> so
>>> whether the architecture provides an acceptable way to resolve the  
>>> problem.
>>> Answers to the mailing list in advance of the meeting in Washington
>>> would be appreciated.
>>> Thanks,
>>> Adrian and Kireeti
>>>
>>>
>>>
>>>
>>>
>>> .
>>>
>>
>>
>
>
>

Delivery-date: Fri, 22 Oct 2004 08:32:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Dimitri Papadimitriou" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Your input: Use of PCE in Inter-domain
Date: Fri, 22 Oct 2004 05:23:25 +0100

Thanks Dimitri,

Looks like you had a profitable flight back from Washington!

> hi all, let's probably speak first about which problem we are trying to
> address here and look at what a PCE approach would provide

Yes. This is important. We need to identify the problem space we are trying to address and
the specific problem within that space. If we cannot do this we cannot justify the work on
PCE.

> as (by definition) a PCE enlarges the path computation domain scope
> behind the local routing domain/system, it allows the requestor included
> in this routing domain/system, to obtain the result of this better PCE
> visibility from the one the requestor would have had himself if it would
> have performed the same path computation task, so the inter-domain
> problem takes then multiple aspects:
>
> - case 1. multi-area basis one can assume that the PCE entity can have
> such better visibility, so here the questions are twofold how better
> should this visibility be from what the routing provides and how it is
> self - impacting (what is the right level of details the PCE needs to
> have to accomplish what it is expected to deliver)

Agree. It does not follow that the PCE consulted has full visibility. Nor does it even
follow that cooperating PCEs achieve full visibility. The only assumption is that the
visibility (and therefore the optimality or success likelihood of the LSP) is increased.

> - case 2. multi-AS (single provider) basis the issue is different as one
> could assume that the local PCE will be able to determine what is the
> best entry point (and the network capabilities to which it gives access)
> to the next AS for a given set of request towards e.g. reachable
> prefixes, AS paths, etc.

I don't completely agree. It depends on "best". The local PCE may be able to select the
best TE path to an entry point to the next AS, and even a least cost metric influence to
the choice of that entry point given the reachability through the next AS, BUT from a TE
perspective the local PCE cannot select
- the next AS
- the best entry point into the next AS
This requires TE information that is not currently known to the local PCE. Thus a
multi-PCE approach is likely.

> - case 3. multi-AS (multi-provider) basis the issue is also different as
> the primary assumption would be that any exchange of such information
> will be restricted if not excluded without any prior agreement between
> operators and then only one could assume that the case 2. applies

Yes. Confidentiality is a significant constraint to any solution. But recall that the
only exchange between PCEs might be limited to request and response (not to TED
information). There are two interesting solutions that spring to mind (that would need to
be added to the architecture).
1. Vertical inter-PCE communication
That is a hierarchical relationship of PCEs rather than a peering relationship. This would
allow a trusted party to do the work. (But note that an ERO might violate confidentiality)
2. The use of cookies or encryption in EROs so that the ERO is only expanded to the
computed path at the ASBR.

> there are also several assumptions that should also be made in order to
> result in a reasonable working item:
> 1. the PCE to contact is known in advance by the requestor in case
>     there are multiple PCEs that can be queried (and no other assumption
>     are made upon their sync in terms of topological information) i would
>     like to point out here that in case of multiple PCEs, the sync of PCE
>     raises the same class of issues as the initial problem it intents to
>     solve

I agree that PCE "discovery" and selection need to be covered. I do not believe that they
are rocket science within an area. Inter PCE choice may be harder, but DNS seems to handle
similar issues.

I disagree that synchronisation of PCEs is a substantial issue. We already have this
problem with MPLS PCEs (that is, ingress LSRs) since
a. The TED relies on
    i.   IGP convergence
    ii.  threshold dampening in the advertising LSRs
b. To LSPs could be initiated from different ingresses at the same
    time targeting the same resource
Thus, I don't believe we have any new concerns. An LSP setup may fail and need to have its
computation retried.

> 2. the approach consisting in having a query sequence
>     PCC->PCE[1]->PCE[2]->...->PCE[n]
>     has the same limitations as the three cases listed here above (in
>     brief PCC and PCE[i], i =< n should belong to the same AS, (note:
>     case 2 can be considered as a particular case here)

Why is this?
PCE[i] can request of PCE[i+1] if there is some form of "trust" relationship.
This may be horizontal or vertical.
There must be at least limited trust since an LSP service is to be provided!

> 3. related to the above, it should be considered that the local AS
>     is unaware and so its decisions are independent from the potential
>     use of a PCE approach by the peering AS is also using a PCE approach
>     (or vice versa), this implies that the PCC makes a request to a PCE
>     that MAY be further decomposed but this is not within the knowledge
>     scope of the PCC i.e. PCC should be assumed to be unaware of the PCE
>     relationship (if any existing within a single AS)

Ah, now this is a VERY good point. If I understand you right, you ask how we set up an LSP
if the source domain uses PCE but the next domain does not.

Firstly, we are no worse off than we are today (i.e. we can still target a domain boundary
node with a loose hop to the destination). We would discover that this needed to be done
when the local PCE found that it did not know about (or could not find) a PCE for the next
domain. The local PCE would return a loose ERO.

Note that the local PCE might know about PCEs in the next-next domain and contact them and
add to the ERO accordingly.

We might need to be careful not to bias the path selection according to PCE existence
since that might miss some optimal paths.

> 4. a PCE having a better visibility also implies it has a set of corr.
>     path computation capabilities so question happens to be what is the
>     minimum set of capabilities we have to assume to make such an
>     approach workable and interoperable ?

Do we have to determine that list before we decide whether PCE is worth investigating?
Seems to me we have to decide to start the work in order to do this.

A reasonable compromise would certainly be to have CCAMP work on the requirements for
this and pass them to a new/existing WG that works on PCE.

> last, it becomes clearer now that the RSVP constraint passing approach
> should be the primary focus of the CCAMP since the PCE approach (in
> particular for the multi-AS cases) is workable iff such constraints can
> be exchanged during the resource reservation phase -

I absolutely agree/disagree. It depends what you mean by "constraint-passing".
We currently pass various constraints that are used both for path computation and for
resource reservation.

During path computation there are four types of constraint
1. those that apply only at the ingress computation
2. those that would ideally be used at any subsequent computation
3. those that MUST be used at subsequent computations
4. those that are needed for resource reservation

Clearly 4. must be signalled
Full PCE cooperation can result in only one computation being necessary except in legacy
(non-PCE) networks. In this case, signalling additional constraints will not help.
But I would not want to rule out multiple computations and would expect to investigate
classes 2 and 3 further.

> thanks,
> - dimitri.

Thanks to you to for your detailed thought about this.
But I am not sure how to interpret your response.

Yes/no/maybe?

Adrian
> ---
>
> Adrian Farrel wrote:
> > Folks,
> > The chairs and ADs would like your input on
> > http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in
> > the context of our inter-domain traffic engineering work.
> > This draft documents an architecture for Path Computation Elements (PCE)
> > and is currently being discussed on the pce mailing list
> > (https://www1.ietf.org/mailman/listinfo/pce)
> > What we would like CCAMP to do is give us your opinion on whether PCE is
> > addresing an inter-domain problem that needs to be addressed, and if so
> > whether the architecture provides an acceptable way to resolve the problem.
> > Answers to the mailing list in advance of the meeting in Washington
> > would be appreciated.
> > Thanks,
> > Adrian and Kireeti
> >
> >
> >
> >
> >
> > .
> >
>
>

Delivery-date: Thu, 21 Oct 2004 22:24:02 +0000
Reply-To: <[email-masked]>
From: "Dean Cheng \(dcheng\)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: Your input: Use of PCE in Inter-domain
Date: Thu, 21 Oct 2004 15:22:46 -0700

The solution as suggested by the PCE I-D and on-going
work do provide a practical way to solve inter-domain
TE routing problem, which has been discussed in the
CCAMP for a while. While there are several solution
models to solve the problem, perhaps the two common
ones are to rely on the ABR/ASBR and the out-of-band 
route server. The I-D however defines the PCE in a
generic manner that can be with both of these, so
is very well in-line with the problem solving effort.

Dean  

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Tuesday, October 19, 2004 12:11 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Your input: Use of PCE in Inter-domain
>
>
>Folks, 
>
>The chairs and ADs would like your input on 
>http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-
>00.txt in the 
>context of our inter-domain traffic engineering work. 
>
>This draft documents an architecture for Path Computation 
>Elements (PCE) and 
>is currently being discussed on the pce mailing list 
>(https://www1.ietf.org/mailman/listinfo/pce) 
>
>What we would like CCAMP to do is give us your opinion on 
>whether PCE is 
>addresing an inter-domain problem that needs to be addressed, 
>and if so 
>whether the architecture provides an acceptable way to resolve 
>the problem. 
>
>Answers to the mailing list in advance of the meeting in 
>Washington would be 
>appreciated. 
>
>Thanks,
>Adrian and Kireeti 
>
> 
>
>
>

Delivery-date: Thu, 21 Oct 2004 18:58:24 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Your input: Use of PCE in Inter-domain
Date: Thu, 21 Oct 2004 14:57:26 -0400

The PCE-based architecture introduced in the draft provides probably the
only practical solution for computing of one or several disjoint paths for
TE tunnels spanning multiple TE advertising domains (IGP areas, ASs, etc.)

However, the limited TE visibility is not the only problem that can be
addressed by the proposed architecture. Generally speaking, it allows for
clear (logical and physical) separation of the path computation function
from the rest of (MPLS-based, GMPLS-based or any other dynamic) control
plane, which opens up numerous possibilities such as:

1) outsourcing of the path computation function by a controller that is not
capable to perform the function due to:
a) lack of information (does not run TE advertising protocol);
b) lack of software or computation resources;

2) making use of advanced path computation algorithms without upgrading
control plane software;

3) solving problems that require information more than usually available via
TE advertising protocols. Examples: global (re-)optimization of TE tunnel
placement, computing path for shared recovery (e.g. full mesh restoration),
etc.

4) making use of intensive NP-hard algorithms (e.g. multi-criteria
optimization, paths traversing multiple switching layers, paths satisfying
optical constraints with the re-generation loops, etc.)

Igor Bryskin,
Movaz networks

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 19, 2004 3:11 PM
Subject: Your input: Use of PCE in Inter-domain

> Folks,
>
> The chairs and ADs would like your input on
> http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in
the
> context of our inter-domain traffic engineering work.
>
> This draft documents an architecture for Path Computation Elements (PCE)
and
> is currently being discussed on the pce mailing list
> (https://www1.ietf.org/mailman/listinfo/pce)
>
> What we would like CCAMP to do is give us your opinion on whether PCE is
> addresing an inter-domain problem that needs to be addressed, and if so
> whether the architecture provides an acceptable way to resolve the
problem.
>
> Answers to the mailing list in advance of the meeting in Washington would
be
> appreciated.
>
> Thanks,
> Adrian and Kireeti
>
>
>
>
>

Envelope-to: [email-masked]
Delivery-date: Thu, 21 Oct 2004 17:20:05 +0000
To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Subject: Last Call: 'Generalized MPLS (GMPLS) Signaling Extensions for G.709  Optical Transport Networks Control' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Message-Id: <[email-masked]>
Date: Thu, 21 Oct 2004 13:02:31 -0400

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider the following document:

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-11-18 (note a 4-week
Last Call because of the upcoming IETF meeting).

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-08.txt

Envelope-to: [email-masked]
Delivery-date: Thu, 21 Oct 2004 17:19:50 +0000
To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Subject: Last Call: 'Generalize Multiprotocol Label Switching(GMPLS)  User-Network Interface (UNI): Resource ReserVation Protocol-Traffic  Engineering (RSVP-TE) Support for the Overlay Model' to Proposed  Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Message-Id: <[email-masked]>
Date: Thu, 21 Oct 2004 13:03:11 -0400

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider 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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-11-18 (note a 4-week
Last Call because of the upcoming IETF meeting).

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt

Delivery-date: Thu, 21 Oct 2004 14:51:32 +0000
Date: Thu, 21 Oct 2004 23:49:14 +0900
From: Kenji Kumaki <[email-masked]>
To: [email-masked]
Subject: Re: Your input: Use of PCE in Inter-domain
Cc: [email-masked]

Hi all,

We have already deployed inter-domain MPLS VPN services in commercial
network. We face the problem that it is difficult to get a end-to-end
shortest path and reoptimize inter-AS TE LSPs through inter-SP
environment as I made a presentation in the last PCE BOF.

We consider that the PCE-based approach is well suited to inter-AS TE,
as it can solve the above problem without major impact on signaling and
routing protocols.

Regards,
Kenji

On Tue, 19 Oct 2004 20:11:23 +0100
"Adrian Farrel" <[email-masked]> wrote:

> Folks, 
> 
> The chairs and ADs would like your input on 
> http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in the 
> context of our inter-domain traffic engineering work. 
> 
> This draft documents an architecture for Path Computation Elements (PCE) and 
> is currently being discussed on the pce mailing list 
> (https://www1.ietf.org/mailman/listinfo/pce) 
> 
> What we would like CCAMP to do is give us your opinion on whether PCE is 
> addresing an inter-domain problem that needs to be addressed, and if so 
> whether the architecture provides an acceptable way to resolve the problem. 
> 
> Answers to the mailing list in advance of the meeting in Washington would be 
> appreciated. 
> 
> Thanks,
> Adrian and Kireeti 
> 
>  
> 
> 

-- 
Kenji Kumaki <[email-masked]>

Delivery-date: Thu, 21 Oct 2004 11:15:17 +0000
Date: Thu, 21 Oct 2004 13:14:04 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: [email-masked]
CC: Adrian Farrel <[email-masked]>,  [email-masked]
Subject: Re: Your input: Use of PCE in Inter-domain

hi all, let's probably speak first about which problem we are trying to 
address here and look at what a PCE approach would provide

as (by definition) a PCE enlarges the path computation domain scope 
behind the local routing domain/system, it allows the requestor included 
in this routing domain/system, to obtain the result of this better PCE 
visibility from the one the requestor would have had himself if it would 
have performed the same path computation task, so the inter-domain 
problem takes then multiple aspects:

- case 1. multi-area basis one can assume that the PCE entity can have 
such better visibility, so here the questions are twofold how better 
should this visibility be from what the routing provides and how it is 
self - impacting (what is the right level of details the PCE needs to 
have to accomplish what it is expected to deliver)

- case 2. multi-AS (single provider) basis the issue is different as one 
could assume that the local PCE will be able to determine what is the 
best entry point (and the network capabilities to which it gives access) 
to the next AS for a given set of request towards e.g. reachable 
prefixes, AS paths, etc.

- case 3. multi-AS (multi-provider) basis the issue is also different as 
the primary assumption would be that any exchange of such information 
will be restricted if not excluded without any prior agreement between 
operators and then only one could assume that the case 2. applies

there are also several assumptions that should also be made in order to 
result in a reasonable working item:
1. the PCE to contact is known in advance by the requestor in case
    there are multiple PCEs that can be queried (and no other assumption
    are made upon their sync in terms of topological information) i would
    like to point out here that in case of multiple PCEs, the sync of PCE
    raises the same class of issues as the initial problem it intents to
    solve
2. the approach consisting in having a query sequence
    PCC->PCE[1]->PCE[2]->...->PCE[n]
    has the same limitations as the three cases listed here above (in
    brief PCC and PCE[i], i =< n should belong to the same AS, (note:
    case 2 can be considered as a particular case here)
3. related to the above, it should be considered that the local AS
    is unaware and so its decisions are independent from the potential
    use of a PCE approach by the peering AS is also using a PCE approach
    (or vice versa), this implies that the PCC makes a request to a PCE
    that MAY be further decomposed but this is not within the knowledge
    scope of the PCC i.e. PCC should be assumed to be unaware of the PCE
    relationship (if any existing within a single AS)
4. a PCE having a better visibility also implies it has a set of corr.
    path computation capabilities so question happens to be what is the
    minimum set of capabilities we have to assume to make such an
    approach workable and interoperable ?

last, it becomes clearer now that the RSVP constraint passing approach 
should be the primary focus of the CCAMP since the PCE approach (in 
particular for the multi-AS cases) is workable iff such constraints can 
be exchanged during the resource reservation phase -

thanks,
- dimitri.
---

Adrian Farrel wrote:
> Folks,
> The chairs and ADs would like your input on 
> http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in 
> the context of our inter-domain traffic engineering work.
> This draft documents an architecture for Path Computation Elements (PCE) 
> and is currently being discussed on the pce mailing list 
> (https://www1.ietf.org/mailman/listinfo/pce)
> What we would like CCAMP to do is give us your opinion on whether PCE is 
> addresing an inter-domain problem that needs to be addressed, and if so 
> whether the architecture provides an acceptable way to resolve the problem.
> Answers to the mailing list in advance of the meeting in Washington 
> would be appreciated.
> Thanks,
> Adrian and Kireeti
> 
> 
> 
> 
> 
> .
> 

Delivery-date: Thu, 21 Oct 2004 09:10:55 +0000
Content-class: urn:content-classes:message
Subject: RE: RE : Your input: Use of PCE in Inter-domain
Date: Thu, 21 Oct 2004 11:09:23 +0200
From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
To: <[email-masked]>

Hello,

Many requirements that would be well addressed by a PCE based approach =
were presented by SPs at the PCE BOF in LA. A very significant =
proportion of those involved inter-domain environments.
My opinion is that PCE is clearly "addresing an inter-domain problem =
that needs to be addressed" and is "an acceptable way to resolve the =
problem" .

Francois=20

>>-----Message d'origine-----
>>De : [email-masked]
>>[mailto:[email-masked]] De la part de Adrian Farrel
>>Envoy=E9 : mardi 19 octobre 2004 21:11
>>=C0 : [email-masked]
>>Cc : [email-masked]
>>Objet : Your input: Use of PCE in Inter-domain
>>
>>
>>Folks,
>>
>>The chairs and ADs would like your input on
>>http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-
>00.txt in the=20
>context of our inter-domain traffic engineering work.=20
>
>This draft documents an architecture for Path Computation=20
>Elements (PCE) and=20
>is currently being discussed on the pce mailing list=20
>(https://www1.ietf.org/mailman/listinfo/pce)=20
>
>What we would like CCAMP to do is give us your opinion on=20
>whether PCE is=20
>addresing an inter-domain problem that needs to be addressed,=20
>and if so=20
>whether the architecture provides an acceptable way to resolve=20
>the problem.=20
>
>Answers to the mailing list in advance of the meeting in=20
>Washington would be=20
>appreciated.=20
>
>Thanks,
>Adrian and Kireeti=20

Delivery-date: Thu, 21 Oct 2004 05:30:26 +0000
Date: Wed, 20 Oct 2004 22:29:53 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ccamp-gmpls-overlay-05.txt

Thanks, Adrian. I've requested an IETF LC for this document (a 4-week one
because of the upcoming IETF meeting).

-- 
Alex
http://www.psg.com/~zinin

Friday, October 15, 2004, 4:45:13 PM, Adrian Farrel wrote:
> Hi Alex,

> We have finally got our act together and updated this draft after AD and routing
> directorate review.

> Could you please take it on to the IESG.

> Thanks,
> Adrian
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, October 15, 2004 8:35 PM
> Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-05.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 : Generalize Multiprotocol Label Switching(GMPLS)
>>   User-Network Interface (UNI): Resource ReserVation
>>   Protocol-Traffic Engineering (RSVP-TE) Support for the
>>     Overlay Model
>> Author(s) : G. Swallow, et al.
>> Filename : draft-ietf-ccamp-gmpls-overlay-05.txt
>> Pages : 12
>> Date : 2004-10-15
>>
>> 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.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the username
>> "anonymous" and a password of your e-mail address. After logging in,
>> type "cd internet-drafts" and then
>> "get draft-ietf-ccamp-gmpls-overlay-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:
>> [email-masked].
>> In the body type:
>> "FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-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.
>>

> --------------------------------------------------------------------------------

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

Delivery-date: Thu, 21 Oct 2004 05:17:31 +0000
Date: Wed, 20 Oct 2004 22:16:56 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
CC: [email-masked]
Subject: Re: CCAMP ASON requirements drafts ready for IESG

Adrian,

  Thanks for following up on the comments.
  I've placed the documents on the agenda for IESG telechat on Oct-28.

-- 
Alex
http://www.psg.com/~zinin

Thursday, October 14, 2004, 1:23:59 AM, Adrian Farrel wrote:
> Hi Alex,

> The two ASON requirements drafts (draft-ietf-ccamp-gmpls-ason-reqts and
> draft-ietf-ccamp-gmpls-ason-routing-reqts) have just been republished.

> These revisions contain updates to address the comments raised by AD review and I have
> checked that the points have been correctly addressed. The revisions also contain updates
> to handle the concerns raised in San Diego that the drafts did not adequately handle the
> ITU-T issue of "subnetwork opacity".

> Can you please put these two drafts on your list to take to the IESG.

> Thanks,
> Adrian

Delivery-date: Thu, 21 Oct 2004 04:42:52 +0000
From: "Zafar Ali" <[email-masked]>
To: "'LE ROUX Jean-Louis RD-CORE-LAN'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RE : Your input: Use of PCE in Inter-domain
Date: Thu, 21 Oct 2004 00:40:58 -0400

>
>>-----Message d'origine-----
>>De : [email-masked]
>>[mailto:[email-masked]] De la part de Adrian Farrel
>>Envoy=E9 : mardi 19 octobre 2004 21:11
>>=C0 : [email-masked]
>>Cc : [email-masked]
>>Objet : Your input: Use of PCE in Inter-domain
>>
>>
>>Folks,
>>
>>The chairs and ADs would like your input on
>>http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-
>00.txt in the=20
>context of our inter-domain traffic engineering work.=20
>
>This draft documents an architecture for Path Computation=20
>Elements (PCE) and=20
>is currently being discussed on the pce mailing list=20
>(https://www1.ietf.org/mailman/listinfo/pce)=20
>
>What we would like CCAMP to do is give us your opinion on=20
>whether PCE is=20
>addresing an inter-domain problem that needs to be addressed,=20
>and if so=20
>whether the architecture provides an acceptable way to resolve=20
>the problem.=20

Yes, as we witness at the PCE BOF that various SPs see a need for a PCE
based solution. Architecture document by Adrian et al addresses these
requirements quite well.=20

N.b. At PCE BOF during last IETF, various SPs presented requirement for =
PCE
which are beyond TE in an inter-domain environment. The architecture
document also capture these additional applications of PCE architecture =
as
well.=20

Thanks

Regards... Zafar=20

>
>Answers to the mailing list in advance of the meeting in=20
>Washington would be=20
>appreciated.=20
>
>Thanks,
>Adrian and Kireeti=20
>
>=20
>
>
>
>

Delivery-date: Wed, 20 Oct 2004 08:53:38 +0000
Content-class: urn:content-classes:message
Subject: RE : Your input: Use of PCE in Inter-domain
Date: Wed, 20 Oct 2004 10:45:25 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Adrian, all

There is a requirement to compute inter-domain constrained shortest path =
(see tewg inter-area/as requirements).
There are several approaches to achieve this objective, as well listed =
in your inter-domain framework draft.
We (France Telecom) consider that PCE-based approach is particularly =
well suited to inter-domain TE, as it allows achieving our objective =
without major impact on signaling and routing protocols.

The PCE architecture draft well addresses inter-domain path computation, =
particularly section 5.3 and 5.4, by identifying distributed-PCE =
computation modes.=20

Regards,

JL

>-----Message d'origine-----
>De : [email-masked]=20
>[mailto:[email-masked]] De la part de Adrian Farrel
>Envoy=E9 : mardi 19 octobre 2004 21:11
>=C0 : [email-masked]
>Cc : [email-masked]
>Objet : Your input: Use of PCE in Inter-domain
>
>
>Folks,=20
>
>The chairs and ADs would like your input on=20
>http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-
00.txt in the=20
context of our inter-domain traffic engineering work.=20

This draft documents an architecture for Path Computation Elements (PCE) =
and=20
is currently being discussed on the pce mailing list=20
(https://www1.ietf.org/mailman/listinfo/pce)=20

What we would like CCAMP to do is give us your opinion on whether PCE is =

addresing an inter-domain problem that needs to be addressed, and if so=20
whether the architecture provides an acceptable way to resolve the =
problem.=20

Answers to the mailing list in advance of the meeting in Washington =
would be=20
appreciated.=20

Thanks,
Adrian and Kireeti=20

=20

Delivery-date: Tue, 19 Oct 2004 19:13:49 +0000
From: "Adrian Farrel" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Your input: Use of PCE in Inter-domain
Date: Tue, 19 Oct 2004 20:11:23 +0100

Folks, 

The chairs and ADs would like your input on 
http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in the 
context of our inter-domain traffic engineering work. 

This draft documents an architecture for Path Computation Elements (PCE) and 
is currently being discussed on the pce mailing list 
(https://www1.ietf.org/mailman/listinfo/pce) 

What we would like CCAMP to do is give us your opinion on whether PCE is 
addresing an inter-domain problem that needs to be addressed, and if so 
whether the architecture provides an acceptable way to resolve the problem. 

Answers to the mailing list in advance of the meeting in Washington would be 
appreciated. 

Thanks,
Adrian and Kireeti 

Delivery-date: Sat, 16 Oct 2004 01:02:28 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: draft-ietf-ccamp-gmpls-overlay-05.txt
Date: Sat, 16 Oct 2004 00:45:13 +0100

Hi Alex,

We have finally got our act together and updated this draft after AD and routing
directorate review.

Could you please take it on to the IESG.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 15, 2004 8:35 PM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-05.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 : Generalize Multiprotocol Label Switching(GMPLS)
>   User-Network Interface (UNI): Resource ReserVation
>   Protocol-Traffic Engineering (RSVP-TE) Support for the
>     Overlay Model
> Author(s) : G. Swallow, et al.
> Filename : draft-ietf-ccamp-gmpls-overlay-05.txt
> Pages : 12
> Date : 2004-10-15
>
> 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.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ccamp-gmpls-overlay-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:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-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.
>

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

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

Delivery-date: Fri, 15 Oct 2004 19:37:33 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-05.txt
Date: Fri, 15 Oct 2004 15:35:24 -0400

--NextPart

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

	Title		: Generalize Multiprotocol Label Switching(GMPLS) 
			  User-Network Interface (UNI): Resource ReserVation 
			  Protocol-Traffic Engineering (RSVP-TE) Support for the 
  			  Overlay Model
	Author(s)	: G. Swallow, et al. 
	Filename	: draft-ietf-ccamp-gmpls-overlay-05.txt
	Pages		: 12
	Date		: 2004-10-15
	
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.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-overlay-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-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="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 14 Oct 2004 08:24:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: CCAMP ASON requirements drafts ready for IESG
Date: Thu, 14 Oct 2004 09:23:59 +0100

Hi Alex,

The two ASON requirements drafts (draft-ietf-ccamp-gmpls-ason-reqts and
draft-ietf-ccamp-gmpls-ason-routing-reqts) have just been republished.

These revisions contain updates to address the comments raised by AD review and I have
checked that the points have been correctly addressed. The revisions also contain updates
to handle the concerns raised in San Diego that the drafts did not adequately handle the
ITU-T issue of "subnetwork opacity".

Can you please put these two drafts on your list to take to the IESG.

Thanks,
Adrian

Delivery-date: Thu, 14 Oct 2004 08:14:00 +0000
Date: Thu, 14 Oct 2004 12:48:19 +0530
From: Harish M <[email-masked]>
Subject: RE: LMP - GMPLS
To: [email-masked]
Reply-to: [email-masked]

This can be computed using the Length field (16 bits) in LMP object.

-----Original Message-----
From: Harish M [mailto:[email-masked]]
Sent: Thursday, October 14, 2004 11:07 AM
To: [email-masked]
Subject: LMP - GMPLS

Hi,

Referring to the draft-ietf_ccamp-lmp-10.txt

"LinkSummary Message can have multiple DATA_LINK objects and each DATA_LINK
object can have more than one variable length sub-object (for including
multiple capabilities of a data link)."

Since a LinkSummary Message can contain multiple DATA_LINK Objects (Class =
12) and as there is no field/mechanism to indicate the number of sub-objects
under a DATA_LINK object, how can we know where the next DATA_LINK object
starts ?

   <LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
                             <DATA_LINK> [<DATA_LINK>...]

---------------------------------------------------------------------------
| IP Header | UDP Header | LMP Header | LMP Object-1 | ... | LMP Object-n |
---------------------------------------------------------------------------

Thanks,
Harish M.

Delivery-date: Wed, 13 Oct 2004 20:32:52 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-07.txt
Date: Wed, 13 Oct 2004 16:31:49 -0400

--NextPart

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

	Title		: Requirements for Generalized MPLS (GMPLS) Signaling 
			  Usage and Extensions for Automatically Switched 
			  Optical Network (ASON)
	Author(s)	: D. Papadimitriou, et al.
	Filename	: draft-ietf-ccamp-gmpls-ason-reqts-07.txt
	Pages		: 14
	Date		: 2004-10-13
	
The Generalized MPLS (GMPLS) suite of protocol 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).
This document concentrates on the signaling aspects of the GMPLS
suite of protocols. It identifies the features to be covered by the
GMPLS signalling protocol to support the capabilities of an
Automatically Switched Optical Network (ASON). This document
provides a problem statement and additional requirements on the
GMPLS signaling protocol to support the ASON functionality.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-07.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 13 Oct 2004 20:32:44 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
Date: Wed, 13 Oct 2004 16:31:03 -0400

--NextPart

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

	Title		: Requirements for Generalized MPLS (GMPLS) Routing 
			  for Automatically Switched Optical Network (ASON)
	Author(s)	: D. Brungard
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
	Pages		: 19
	Date		: 2004-10-13
	
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.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-ason-routing-reqts-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-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="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 12 Oct 2004 21:13:46 +0000
Date: Tue, 12 Oct 2004 14:10:02 -0700
To: Adrian Farrel <[email-masked]>, <[email-masked]>, <[email-masked]>
From: raymond zhang <[email-masked]>
Subject: Re: [mpls] Mailing List for Path Computation Element (PCE)
Cc: [email-masked], [email-masked], [email-masked]

Hi Adrian, JP, Jerry,

I've gone through the I-D "draft-ash-pce-architecture-00.txt" and  I think 
this document has very well stated the architectural objectives and need 
for a separate WG for this area.

Also please find some minor comments below:

- section 3. Definitions

" Path Computation Element (PCE) is an entity that is capable of
computing a network path or route based on a network graph, and
applying
computational constraints. The PCE entity can be located within an
application"

(RZ: I'd suggest some rewording here: The PCE entity is an application process
that can be located on a network node or component, on an out-of-
network server, etc.)

- Page 4, first paragraph:
1) Path computation is applicable in both intra-domain, inter-domain,
and inter-layer contexts. Inter-domain path computation may involve the
correlation of topology and routing information between domains.
Overlapping domains are not within the scope of this document.
In the inter-domain case, the domains may belong to a single or
multiple

(RZ:"inter-layer contexts" is mentioned at the beginning of this
paragraph so it would be good to explain this a bit as did for
inter-domain)

- Page 4. 3) "Centralized computation model" ... There would (RZ: add "be")...
- Page 6, 2nd paragraph:
(RZ: From SP's perspective, it is not a difficult thing to migrate a
legacy IGP plane, e.g. ISIS with narrow metrics to a new ISIS plane
supporting TE ext. So I dont seem to see a strong case for this...)

- Page 6, section 4.4. (RZ: there maybe some inconsistence here to say on 
one hand this
scenario does not relay on loose hops, yet on the other hand PCE based
solution provides loose hops in the computed paths ?)

- Page 7, section 5.1.  5.1. Composite PCE

"Figure 1 below shows the components of a typical composite PCE node
(that is, a router that also implements the PCE functionality) that
utilizes path computation. The routing protocol is used to exchange TE
information from which the TED is constructed. Service requests are
received by the node and converted into signaling requests"

(RZ:it would be good to clarify between service requests to the PCE or inter-
PCE requests and service requests to signal a TE-LSP request) ...

- Page 12, first paragraph (RZ: It would be probably more appropriate to 
rename to this section to
"Service Request/Response Synchronization" vs. "TED Sync" in a
subsequent section.  It may be more productive here in describing service 
request/reponse sync of PCC-PCE and PCE-PCE
as part of the architectural discussion, rather than illustrating more detailed
procedures since these procedures could be discussed in a detailed spec
document in which it may transform to something different.)

- page 13, 2nd paragrah:
"No assumption is made at this stage about whether the PCC-PCE and
PCE-PCE communication protocols are identical."

(RZ: but I think it would be architectrually more scalable if they are 
same, so are such comments are warranted here (same protocols for both 
PCC-PCE/PCE-PCE...) in an arch doc ?

- Section 6.8: (RZ: since this is an arch doc, does it imply that 
implementation of either scheme would meet the arch framework established 
here ?)

- A general comment:  there are a lot of very good, analytical discussions 
in the document presenting different cases.  It would be good I think if 
the authors could provide some guidance in drawing up some architecture 
recommendations after comparing/analyzing some of these cases or simply say 
all cases presented in some of these sections are considered valid 
architectural options ?

Regards,
Raymond

Delivery-date: Mon, 11 Oct 2004 23:45:20 +0000
Cc: [email-masked], [email-masked], Gerald <[email-masked]>, [email-masked], [email-masked], "Zafar Ali" <[email-masked]>, [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, 
Date: Mon, 11 Oct 2004 19:43:25 -0400
To: [email-masked]

Hi Igor,

On Oct 9, 2004, at 10:45 AM, [email-masked] wrote:

> Hi guys,
>
> I think this is a vey sound document. I have a suggestion though.
>
> It would be extreamely useful if a PCE could advertise its capabilities
> such as:
>
> a) set of constraints that it can account for (diversity, SRLGs,  
> optical
> impairements, wavelenght continuity, etc.)
>
> b) number of switching capability layers (and which);
>
> c) number of path selection criterias (and which);
>
> d) whether it is a stateless path calculator or can send updates about
> better paths that might be available in future;
>
> e) whether it can compute P2MP trees (and which types);
>
> f) whether it can ensure the resource sharing between backup tunnels;
>
> g) etc.
>
> This information would help a lot for a potential PCC that dynamically
> learns about PCEs available on the network to decide which of them to  
> use.
>

I cannot agree more ! See the two PCE cap related drafts:
	draft-vasseur-ospf--te-caps (and isis)

Such draft would probably ends up being discussed here, should we end  
up creating a WG.

JP.

> Igor
>
>
>> Hi Adrian, Jerry, JP, et al,
>>
>> Thanks for putting the PCE Architecture document
>> (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture 
>> -00.txt), I
>> found it very useful in scoping PCE WG and applicability of PCE in  
>> MPLS/
>> GMPLS TE networks. In the following I have a few questions/ comments  
>> about
>> this ID.
>>
>> I would also like to request about what would be a tentative agenda  
>> for
>> PCE
>> BOF Part II in DC? I think the discussion in SD went very well in  
>> favor of
>> PCE WG, pending this architecture ID. What is the present plan of  
>> record?
>>
>> - What did you meant by "the level of robustness of the path  
>> resources",
>> in
>> PCC-PCE communication? I am expecting that the client can also  
>> specify an
>> exclude list, include list (this is in addition of SRLG to include/
>> exclude).
>>
>> - Can you please elaborate more on advantages of Stateful PCE and  
>> what are
>> the pits fall of using Stateful PCE in a distributed PCE environment.  
>> You
>> have information about Out-of-band TED synchronization but I am  
>> thinking
>> there is some complexity involved in such mechanism and stateful PCE  
>> in a
>> distributed PCE setup. More description on the applicability of  
>> Stateful
>> PCE
>> & Out-of-band TED synchronization would be useful to better scope core
>> vs..
>> advanced features of PCE.
>>
>> - When PCE is distributed, are there any considerations in path
>> computation
>> (minimum guidelines, like constraints based shortest path based on the
>> specified optimization criteria, optimization criteria does not  
>> change for
>> the same setup when multiple PCE are involved in path computation,  
>> etc.)
>> to
>> make Path Computations in a distributed PCE scheme, that you think we  
>> need
>> to add to the text of this document.
>>
>> - When a number of disjoint paths are required, we need a mechanism to
>> specify if near disjoint Paths are acceptable (but this is need not  
>> to be
>> in
>> architecture doc).
>>
>> The rest of the document look very good to me.
>>
>> Regards... Zafar
>>
>>
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
>

Delivery-date: Mon, 11 Oct 2004 19:42:14 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-00.txt
Date: Mon, 11 Oct 2004 15:38:15 -0400

--NextPart

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

	Title		: Extensions to GMPLS RSVP Graceful Restart
	Author(s)	: A. Satyanarayana, R. Rahman
	Filename	: draft-ietf-ccamp-rsvp-restart-ext-00.txt
	Pages		: 21
	Date		: 2004-10-11
	
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-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-rsvp-restart-ext-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-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="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 11 Oct 2004 10:51:32 +0000
Content-class: urn:content-classes:message
Subject: RE : RE : [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded.
Date: Mon, 11 Oct 2004 12:46:52 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Dillikar Satyanarayana-G19471" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Dillikar,

E =3D 1, so both trees are valid.

Regards,

JL

>-----Message d'origine-----
>De : Dillikar Satyanarayana-G19471 [mailto:[email-masked]]=20
>Envoy=E9 : vendredi 8 octobre 2004 16:09
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]; =
[email-masked]
>Cc : [email-masked]
>Objet : RE: RE : [mpls]=20
>draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded.
>
>
>Hi JL,
>  Thanks for your explanation. As the hardware data-plane=20
>branch capability is not known to CSPF=20
>Path-Computation-Engine(PCE). PCE only has to rely on E-bit=20
>and B-bit of the nodes.
>  PCE computing trees T1 and T2 based on given R3 bit status.=20
>Please tell us  which tree is valid and which tree is not=20
>valid and why?
>=20
>Tree T1: Ingress =3D R1 Egresses =3D R2,R3
>=20
>      R1
>      |
>  R2--R3
>=20
>R3(E=3D1, B=3D0)
>
>
>Tree T2: Ingress =3D R1 Egresses =3D R2,R3
>=20
>      R1
>      |
>  R2--R3
>=20
>R3(E=3D1, B=3D1)
>
>TIA,
>Satya=20
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of LE ROUX=20
>> Jean-Louis RD-CORE-LAN
>> Sent: Friday, October 08, 2004 3:57 AM
>> To: Satyanarayana Dillikar; [email-masked]; [email-masked]
>> Cc: [email-masked]
>> Subject: RE : [mpls]=20
>> draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded.
>>=20
>>=20
>> Hi Dillikar,
>>=20
>> Sorry for this delayed answer.
>> Thanks for these useful comments, that will help clarifying
>> this spec. Please see inline. Regards,
>>=20
>> JL
>>=20
>> PS: I'm copying ccamp
>>=20
>> >-----Message d'origine-----
>> >De : [email-masked]=20
>[mailto:[email-masked]]=20
>> >De la part de Satyanarayana Dillikar
>> >Envoy=E9 : mercredi 6 octobre 2004 10:38
>> >=C0 : [email-masked]; [email-masked]
>> >Objet : [mpls] draft-vasseur-ccamp-te-router-info-00.txt=20
>> >clarificationneeded.
>> >
>> >
>> >Hi,
>> > We have some confusion in understanding the Data
>> >Plane Capability Flags (B-bit & E-bit) from=20
>> >draft-vasseur-ccamp-te-router-info-00.txt
>> >
>> >(a) Does E-bit ON implies B-bit ON always ? (assuming
>> >ON =3D set and OFF =3D unset).
>>=20
>> Basically bud (transit + Egress) capability requires some
>> branching in the data plane so in general E ON will imply B=20
>> ON, but note that these capabilities does not necessarily=20
>> reflect real hardware capabilities as they may be=20
>> activated/deactivated by the operator for various reasons. We=20
>> will clarify this point in next revision.
>>=20
>>=20
>> >(b) E-bit =3D ON & B-bit =3D OFF, is it a valid
>> >combination.
>>=20
>> Yes see above, there may be cases where the operator want to
>> deactivate branch capability on a node (He does't want that=20
>> the node act as a branch LSR), even if its data plane is=20
>> physically branch capable, but he allows the node to act as a=20
>> bud-LSR (transit + egress). This gives more operational flexibility.
>>=20
>> >(c) Please tell us the E-bit and B-bit status for a
>> >node which is a destination node but does not have
>> >branch capability.
>>=20
>> If its data plane is not branch capable then it will also
>> probably not be bud capable so=20
>> E =3D 0 and B =3D 0
>>=20
>> In return, if its data plane is branch capable but branch LSR
>> capability has been deactivated by configuration and bud-LSR=20
>> capability is activated, then E =3D 1 and B =3D 0
>>=20
>> >
>> >
>> >We are also curious to know
>> >(1)The idea behind combing two things (egress status & transit=20
>> >status) in a single E-bit. rather than making use of B-bit(branch)=20
>> >and having E-bit just for egress status.
>>=20
>> Remind that these capabilities are used for tree computation
>> purpose, and the egress is an entry=20
>> of the computation. So, IMHO it does't really make any sense=20
>> to advertise egress capability only.=20
>>=20
>> >(2) Why the TE Node Capability Descriptor TLV should
>> >have E-bit & how it should be used in CSPF path
>> >computation.
>>=20
>> This allows advertising if an LSR can be transit and egress.
>> This is particulary useful for steiner tree topologies.=20
>> See the following example:=20
>> Tree T: Ingress =3D R1 Egresses =3D R2, R3, R4
>>=20
>>      R1
>>      |
>>  R2--R3---R4
>>=20
>> Such tree can be setup only if R3 has Egress + Transit capability.
>>=20
>>=20
>> Regards,
>>=20
>> JL
>>=20
>>=20
>>=20
>> >
>> >Thanks
>> >Satya
>> >
>> >
>> >	=09
>> >_______________________________
>> >Do you Yahoo!?
>> >Declare Yourself - Register online to vote today!
>http://vote.yahoo.com
>>
>>_______________________________________________
>>mpls mailing list
>>[email-masked] https://www1.ietf.org/mailman/listinfo/mpls
>>
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mpls
>

Delivery-date: Sat, 09 Oct 2004 14:47:20 +0000
Date: Sat, 9 Oct 2004 10:45:47 -0400 (EDT)
Subject: Re: Path Computation Element (PCE) Architecture and mailing list,
From: [email-masked]
To: "Zafar Ali" <[email-masked]>
Cc: [email-masked], "'Adrian Farrel'" <[email-masked]>, [email-masked], "Gerald" <[email-masked]>, "ALABS'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]

Hi guys,

I think this is a vey sound document. I have a suggestion though.

It would be extreamely useful if a PCE could advertise its capabilities
such as:

a) set of constraints that it can account for (diversity, SRLGs, optical
impairements, wavelenght continuity, etc.)

b) number of switching capability layers (and which);

c) number of path selection criterias (and which);

d) whether it is a stateless path calculator or can send updates about
better paths that might be available in future;

e) whether it can compute P2MP trees (and which types);

f) whether it can ensure the resource sharing between backup tunnels;

g) etc.

This information would help a lot for a potential PCC that dynamically
learns about PCEs available on the network to decide which of them to use.

Igor

> Hi Adrian, Jerry, JP, et al,
>
> Thanks for putting the PCE Architecture document
> (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), I
> found it very useful in scoping PCE WG and applicability of PCE in MPLS/
> GMPLS TE networks. In the following I have a few questions/ comments about
> this ID.
>
> I would also like to request about what would be a tentative agenda for
> PCE
> BOF Part II in DC? I think the discussion in SD went very well in favor of
> PCE WG, pending this architecture ID. What is the present plan of record?
>
> - What did you meant by "the level of robustness of the path resources",
> in
> PCC-PCE communication? I am expecting that the client can also specify an
> exclude list, include list (this is in addition of SRLG to include/
> exclude).
>
> - Can you please elaborate more on advantages of Stateful PCE and what are
> the pits fall of using Stateful PCE in a distributed PCE environment. You
> have information about Out-of-band TED synchronization but I am thinking
> there is some complexity involved in such mechanism and stateful PCE in a
> distributed PCE setup. More description on the applicability of Stateful
> PCE
> & Out-of-band TED synchronization would be useful to better scope core
> vs..
> advanced features of PCE.
>
> - When PCE is distributed, are there any considerations in path
> computation
> (minimum guidelines, like constraints based shortest path based on the
> specified optimization criteria, optimization criteria does not change for
> the same setup when multiple PCE are involved in path computation, etc.)
> to
> make Path Computations in a distributed PCE scheme, that you think we need
> to add to the text of this document.
>
> - When a number of disjoint paths are required, we need a mechanism to
> specify if near disjoint Paths are acceptable (but this is need not to be
> in
> architecture doc).
>
> The rest of the document look very good to me.
>
> Regards... Zafar
>
>

Delivery-date: Fri, 08 Oct 2004 21:06:53 +0000
From: "Zafar Ali" <[email-masked]>
To: <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, "'Ash, Gerald R \(Jerry\), ALABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Path Computation Element (PCE) Architecture and mailing list, 
Date: Fri, 8 Oct 2004 17:05:35 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C4AD59.08795340
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Adrian, Jerry, JP, et al,=20
=20
Thanks for putting the PCE Architecture document
(http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), =
I
found it very useful in scoping PCE WG and applicability of PCE in MPLS/
GMPLS TE networks. In the following I have a few questions/ comments =
about
this ID.=20
=20
I would also like to request about what would be a tentative agenda for =
PCE
BOF Part II in DC? I think the discussion in SD went very well in favor =
of
PCE WG, pending this architecture ID. What is the present plan of =
record?=20
=20
- What did you meant by "the level of robustness of the path resources", =
in
PCC-PCE communication? I am expecting that the client can also specify =
an
exclude list, include list (this is in addition of SRLG to include/
exclude). =20
=20
- Can you please elaborate more on advantages of Stateful PCE and what =
are
the pits fall of using Stateful PCE in a distributed PCE environment. =
You
have information about Out-of-band TED synchronization but I am thinking
there is some complexity involved in such mechanism and stateful PCE in =
a
distributed PCE setup. More description on the applicability of Stateful =
PCE
& Out-of-band TED synchronization would be useful to better scope core =
vs..
advanced features of PCE.=20
=20
- When PCE is distributed, are there any considerations in path =
computation
(minimum guidelines, like constraints based shortest path based on the
specified optimization criteria, optimization criteria does not change =
for
the same setup when multiple PCE are involved in path computation, etc.) =
to
make Path Computations in a distributed PCE scheme, that you think we =
need
to add to the text of this document.=20
=20
- When a number of disjoint paths are required, we need a mechanism to
specify if near disjoint Paths are acceptable (but this is need not to =
be in
architecture doc). =20
=20
The rest of the document look very good to me.=20
=20
Regards... Zafar
=20

------=_NextPart_000_0008_01C4AD59.08795340
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.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>Hi =
Adrian, Jerry,=20
JP, et al, </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D151055918-08102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2>Thanks<SPAN =
class=3D151055918-08102004> for=20
putting the PCE Architecture document (<A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00=
.txt">http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.t=
xt</A>),=20
I found it very useful in scoping PCE WG and applicability of PCE in =
MPLS/ GMPLS=20
TE networks. In the following I&nbsp;have a few questions/ comments =
about this=20
ID. </SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D151055918-08102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>I =
would also like to=20
request about what would be a tentative agenda for PCE BOF Part II in =
DC? I=20
think the discussion in SD went very well in favor of PCE WG, pending =
this=20
architecture ID. What is the present plan of record? =
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D151055918-08102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>- What =
did you meant=20
by "the level of robustness of the path resources", in PCC-PCE =
communication? I=20
am expecting that the client can also specify an exclude list, include =
list=20
(this is&nbsp;in addition&nbsp;of SRLG to include/ exclude).=20
&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D151055918-08102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>- Can =
you please=20
elaborate more on advantages of Stateful PCE and what are the pits fall =
of using=20
Stateful PCE in a distributed PCE environment. You have information =
about=20
Out-of-band TED synchronization but I am thinking there is some =
complexity=20
involved in such mechanism and stateful PCE in a distributed PCE setup. =
More=20
description on the applicability of Stateful PCE &amp; Out-of-band TED=20
synchronization would be useful to better scope core vs.. advanced =
features of=20
PCE. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D151055918-08102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>- When =
PCE is=20
distributed, are there any considerations in path computation (minimum=20
guidelines, like constraints based shortest path based on the specified=20
optimization criteria, optimization criteria does not change for the =
same setup=20
when multiple PCE are involved in path computation, etc.) to make Path=20
Computations in a distributed PCE scheme, that you think we need to add =
to the=20
text of this document. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>- When =
a number of=20
disjoint paths are required, we need a mechanism to specify&nbsp;if near =

disjoint Paths&nbsp;are acceptable (but this is need not to be in =
architecture=20
doc).&nbsp;&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>The =
rest of the=20
document look very good to me. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Regards... =
Zafar</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0008_01C4AD59.08795340--

Delivery-date: Fri, 08 Oct 2004 20:49:39 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: GMPLS MIBs
Date: Fri, 8 Oct 2004 21:48:09 +0100

Hi,
New versions of the GMPLS MIB modules are now available in the repository.

The changes are minor:
- boilerplate
- apply lessons learned from MPLS MIBs
- add more references
- smilint
- update references
- reformat

The conformance statements are still sub-standard, but Tom plans to work on them soon.
Otherwise we believe that these drafts are 'cooked' and we know of a couple of
implementations that seem to be working OK.

Once the conformance statements are done we will be taking these to the MIB doctors and
asking the WG about last call. Your review input at this stage would be most welcome.

Thanks,
Adrian

Delivery-date: Fri, 08 Oct 2004 20:49:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-crankback-03.txt
Date: Fri, 8 Oct 2004 21:48:50 +0100

The changes in this version are trivial (boilerplate and typos).

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 08, 2004 8:33 PM
Subject: I-D ACTION:draft-ietf-ccamp-crankback-03.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 : Crankback Signaling Extensions for MPLS Signaling
> Author(s) : A. Farrel, et al.
> Filename : draft-ietf-ccamp-crankback-03.txt
> Pages : 31
> Date : 2004-10-8
>
> In a distributed, constraint-based routing environment, the
>    information used to compute a path may be out of date. This means
>    that Multiprotocol Label Switching (MPLS) label switched path (LSP)
>    setup requests may be blocked by links or nodes without sufficient
>    resources. Crankback is a scheme whereby setup failure information is
>    returned from the point of failure to allow new setup attempts to be
>    made avoiding the blocked resources. Crankback can also be applied to
>    LSP restoration to indicate the location of the failed link or node.
>
>    This document specifies crankback signaling extensions for use in
>    MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to
>    RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be
>    retried on an alternate path that detours around blocked links or
>    nodes. This offers significant improvements in the successful setup
>    and recovery ratios for LSPs, especially in situations where a large
>    number of setup requests are triggered at the same time.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-03.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ccamp-crankback-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-crankback-03.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

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

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

Delivery-date: Fri, 08 Oct 2004 19:35:43 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-06.txt
Date: Fri, 08 Oct 2004 15:35:00 -0400

--NextPart

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

	Title		: Generalized Multiprotocol Label Switching (GMPLS) 
			  Traffic Engineering Management Information Base
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-te-mib-06.txt
	Pages		: 49
	Date		: 2004-10-8
	
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for Generalized Multiprotocol Label Switching (GMPLS) based traffic
engineering.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-te-mib-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-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="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-06.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 08 Oct 2004 19:35:41 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-crankback-03.txt
Date: Fri, 08 Oct 2004 15:33:12 -0400

--NextPart

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

	Title		: Crankback Signaling Extensions for MPLS Signaling
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-crankback-03.txt
	Pages		: 31
	Date		: 2004-10-8
	
In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date. This means
   that Multiprotocol Label Switching (MPLS) label switched path (LSP)
   setup requests may be blocked by links or nodes without sufficient
   resources. Crankback is a scheme whereby setup failure information is
   returned from the point of failure to allow new setup attempts to be
   made avoiding the blocked resources. Crankback can also be applied to
   LSP restoration to indicate the location of the failed link or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to
   RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be
   retried on an alternate path that detours around blocked links or
   nodes. This offers significant improvements in the successful setup
   and recovery ratios for LSPs, especially in situations where a large
   number of setup requests are triggered at the same time.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-crankback-03.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 08 Oct 2004 19:35:27 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-06.txt
Date: Fri, 08 Oct 2004 15:34:31 -0400

--NextPart

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

	Title		: Generalized Multiprotocol Label Switching (GMPLS) 
			  Label Switching Router (LSR) Management Information Base
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-06.txt
	Pages		: 39
	Date		: 2004-10-8
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
Switching Router (LSRs).

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-lsr-mib-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-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="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-06.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 08 Oct 2004 19:35:25 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-06.txt
Date: Fri, 08 Oct 2004 15:33:53 -0400

--NextPart

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

	Title		: Definitions of Textual Conventions for Generalized 
			  Multi-Protocol Label Switching (GMPLS) Management
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-tc-mib-06.txt
	Pages		: 9
	Date		: 2004-10-8
	
This document defines a Management Information Base (MIB) module
which contains Textual Conventions to represent commonly used
Generalized Multi-Protocol Label Switching (GMPLS) management
information. The intent is that these TEXTUAL CONVENTIONS (TCs) will
be imported and used in GMPLS related MIB modules that would
otherwise define their own representations.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-tc-mib-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-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="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-06.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 08 Oct 2004 11:11:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Basic agenda structure for Washington DC
Date: Fri, 8 Oct 2004 12:11:49 +0100

Hi,

Since San Diego, we have managed to move on quite well with our existing milestones,
commitments and drafts.

So, the basic agenda structure for Washington DC is as follows:

Admin and WG status
ASON Solutions
Protection solutions
Inter-domain
    Basic
    MRN
    Diverse path
New work
   MPLS/GMPLS migration
   L1VPN
   Others
Rechartering

If you would like a slot, please ask and we will attempt to construct an agenda.
Editors/authors or WG drafts may expect to be asked by the chairs to present on the
status, issues and next steps for their drafts.

Thanks,
Adrian

Delivery-date: Fri, 08 Oct 2004 11:07:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ASON Opacity and liaisons
Date: Fri, 8 Oct 2004 12:05:50 +0100

Hi Kam,

> In particular about the requirements drafts, my intent is just a reminder to
> send on these more finalized drafts to ITU-T SG15 formally.

Oh, most certainly.
My intention is that whenever we finalize a CCAMP draft we will liaise it to all
interested parties.

> Regarding the Q14/15 Februrary liaison statement, in deed it was
> for action about the ASON signalling solutions discussion (not
> signaling requirements).

Well, I see three separate documents from that date.
wd35r1_liaison_ccamp_sig-req.doc has the title "Liaison Statement To IETF CCAMP WG on
<draft-ietf-ccamp-gmpls-ason-reqts-05.txt"
wd34r3_liaison_ccamp_routing.doc has the title "Response To IETF CCAMP WG on ASON Routing
Requirements"
wd33r3_signalling-liaison-to-ccamp.doc has the title "Response to IETF CCAMP WG regarding
Comments on G.7713.2"

Thus, two liaisons were explicitly about the requirements drafts, and one was in response
to the liaison from CCAMP about G.7713.2. It was the third of these that you pointed to in
your orriginal email and it includes some useful background material that will definitiely
be taken on board by the GMPLS ASON signaling draft authors when they work on the next
revision.

Unfortunately, work on the solutions draft has been blocked pending the completion of the
requirements drafts, but it looks like we are about ready to start moving again.

> Nonetheless, liaison responses would have seemed to have been
> a good springboard for stimulating further joint work.

Yes, and when the authors have the oportunity to work on the draft further, I'm sure they
will generate a response.

> Perhaps we can follow up on this together?

I'm sure we can.

Regards,
Adrian

Delivery-date: Thu, 07 Oct 2004 22:46:30 +0000
Content-class: urn:content-classes:message
Subject: RE : [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded.
Date: Fri, 8 Oct 2004 00:26:57 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Satyanarayana Dillikar" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Dillikar,

Sorry for this delayed answer.
Thanks for these useful comments, that will help clarifying this spec.
Please see inline.
Regards,

JL

PS: I'm copying ccamp

>-----Message d'origine-----
>De : [email-masked]=20
>[mailto:[email-masked]] De la part de=20
>Satyanarayana Dillikar
>Envoy=E9 : mercredi 6 octobre 2004 10:38
>=C0 : [email-masked]; [email-masked]
>Objet : [mpls] draft-vasseur-ccamp-te-router-info-00.txt=20
>clarificationneeded.
>
>
>Hi,
> We have some confusion in understanding the Data
>Plane Capability Flags (B-bit & E-bit) from=20
>draft-vasseur-ccamp-te-router-info-00.txt
>
>(a) Does E-bit ON implies B-bit ON always ? (assuming
>ON =3D set and OFF =3D unset).

Basically bud (transit + Egress) capability requires some branching in =
the data plane so in general E ON will imply B ON,
but note that these capabilities does not necessarily reflect real =
hardware capabilities as they
may be activated/deactivated by the operator for various reasons.
We will clarify this point in next revision.

>(b) E-bit =3D ON & B-bit =3D OFF, is it a valid
>combination.

Yes see above, there may be cases where the operator want to deactivate =
branch capability on a node (He does't want that the node act as a =
branch LSR), even if its data plane is physically branch capable, but he =
allows the node to act as a bud-LSR (transit + egress).
This gives more operational flexibility.

>(c) Please tell us the E-bit and B-bit status for a
>node which is a destination node but does not have
>branch capability.

If its data plane is not branch capable then it will also probably not =
be bud capable so=20
E =3D 0 and B =3D 0

In return, if its data plane is branch capable but branch LSR capability =
has been deactivated by configuration and bud-LSR capability is =
activated, then
E =3D 1 and B =3D 0

>
>
>We are also curious to know
>(1)The idea behind combing two things (egress status &
>transit status) in a single E-bit. rather than making
>use of B-bit(branch) and having E-bit just for egress
>status.

Remind that these capabilities are used for tree computation purpose, =
and the egress is an entry=20
of the computation. So, IMHO it does't really make any sense to =
advertise egress capability only.=20

>(2) Why the TE Node Capability Descriptor TLV should
>have E-bit & how it should be used in CSPF path
>computation.

This allows advertising if an LSR can be transit and egress.=20
This is particulary useful for steiner tree topologies.=20
See the following example:=20
Tree T: Ingress =3D R1 Egresses =3D R2, R3, R4

     R1
     |
 R2--R3---R4

Such tree can be setup only if R3 has Egress + Transit capability.

Regards,

JL

>
>Thanks
>Satya=20
>
>
>	=09
>_______________________________
>Do you Yahoo!?
>Declare Yourself - Register online to vote today! http://vote.yahoo.com
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mpls
>

Delivery-date: Thu, 07 Oct 2004 17:41:19 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: [email-masked], [email-masked], Bill Fenner <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: RE: ASON Opacity and liaisons
Date: Thu, 7 Oct 2004 13:38:21 -0400 

Hi Adrian,

Thank you for the detail information on the history.

Regarding my email, please don't take that as a criticism. 
In particular about the requirements drafts, my intent is just a reminder to send on these more finalized drafts to ITU-T SG15 formally. Regarding the Q14/15 Februrary liaison statement, in deed it was for action about the ASON signalling solutions discussion (not signaling requirements). Nonetheless, liaison responses would have seemed to have been a good springboard for stimulating further joint work. Perhaps we can follow up on this together?

Regards,
Kam

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, October 06, 2004 8:16 PM
> To: Lam, Hing-Kam (Kam)
> Cc: [email-masked]; [email-masked]; Bill Fenner; 'Kireeti Kompella'
> Subject: Re: ASON Opacity and liaisons
> 
> 
> Hello Kam,
> 
> Thanks for the email. Let me go over the history before 
> coming to your specific points.
> 
> The review and liaison in Chicago were in direct response to 
> CCAMP passing the latest
> copies of the drafts to SG15 and soliciting input. They were 
> notified to the CCAMP mailing
> list on 1st March, (and so copied to the ASON signaling and 
> routing requirements design
> teams), published on the CCAMP alternative web pages, and 
> published on the IETF's liaison
> pages.
> 
> The CCAMP design teams responsible for the ASON signaling and 
> routing requirements drafts
> were certainly grateful for the review comments received in a 
> formal liaison from SG15.
> You may be sure that the points raised were fully considered, 
> especially since I was in
> the room in Chicago when drafts were reviewed and the liaison 
> statement was drafted.
> 
> The liaisons were subsequently presented to CCAMP in Seoul by 
> Lyndon Ong and the efforts
> of the ITU-T were recognized from the chair.
> 
> On return from Seoul, the editor of the ASON Signaling 
> Requirements draft was able to
> agree upon the points for inclusion in the draft after 
> discussion with his design team.
> The changes made were largely in line with those suggested by 
> the liaison.
> 
> After Seoul, the editor of the ASON Routing Requirements 
> draft was able to reach agreement
> on all but three points. She quickly took these remaining 
> issues to the CCAMP mailing list
> where they were (hotly) debated. After a while it was 
> possible to separate the requirement
> issues from the discussion of solutions and progress was made 
> thanks to the participation
> of no fewer than seven people who regularly attend and 
> participate in SG15. The debate
> quietened down after March 19th with sufficient consensus for 
> the design team to move
> forward.
> 
> A working group last call was issued for the ASON Routing 
> Requirements draft on April 15th
> and included the text...
> > The ASON Routing Reqts DT has updated the following draft based on
> > ITU Q14/15's Liaison and CCAMP mail list comments.
> This means that the SG15 comments were included as modified 
> by the discussions on the
> CCAMP mailing list, and that the draft had been agreed upon 
> by the whole design team.
> 
> A working group last call was issued for the ASON Signaling 
> Requirements draft on April
> 26th and included the text...
> > The authors of this draft have updated it to reflect the 
> comments on the
> > mailing list and the helpful feedback from ITU-T SG15 Question 14.
> This means that the SG15 comments were included. In fact, the 
> draft had been updated and
> agreed upon by the whole design team. The fact of the last 
> call was circulated to the
> IETF's OSPF, IS-IS and Routing working groups in order to 
> ensure a wide coverage of
> potential reviewers.
> 
> It is unthinkable that either draft would have been published 
> or put up for last call if
> any member of the design team had raised an objection.
> 
> A working group last call is public and is not confined to 
> any particular body. It gives
> an opportunity for everyone who is subscribed to the mailing 
> list to comment. This covers
> a considerable number of participants in SG15 and, of course, 
> includes the whole of the
> design team.
> 
> The ASON Routing Requirements draft completed last call with 
> a few minor comments. It
> turned out that most of these comments were questioning the 
> validity of text in G.7715.1,
> and CCAMP's position was (of course) that the draft must 
> reflect the statements in that
> recommendation and not try to invent different requirements. 
> The other comments were
> editorial nits. The draft was duly updated with agreement 
> from the design team, and
> re-published on May 6th with notification on the CCAMP mailing list.
> 
> The ASON Signaling Requirements draft completed last call 
> with no comments.
> 
> Both drafts were passed to the AD for review.
> 
> On May 10th a further liaison was received from SG15 Q.14/15 
> thanking CCAMP and the
> members of the ASON Routing Requirements Design Team for 
> their efforts to understand and
> capture ASON Routing Requirements for the future work in 
> IETF. This liaison was published
> and notified on the CCAMP mailing list.
> 
> In the run-up to the San Diego IETF, both drafts were 
> reviewed by the AD and were updated
> accordingly. The changes were minor and for clarification 
> only. Again, the design team
> agreed the changes. The drafts were not published before San 
> Diego, but were made publicly
> available.
> 
> In San Diego, both drafts were presented and the plan to 
> forward them to the IESG was
> announced. However, Jonathan Sadler raised an important 
> concern that the drafts did not
> sufficiently capture the notion of subnetwork opacity. This 
> was picked up by a number of
> people attending the meeting and it was immediately agreed 
> that a gathering of the design
> team, working group chairs and other interested parties 
> should be held at once. Although
> the process had already been completed with ample chance for 
> the authors, the design team
> and external reviewers to discover and raise this point, the 
> gathering agreed that
> Jonathan should be deputed to review the drafts in the light 
> of his concerns and raise any
> specific issues with me.
> 
> Over the next couple of months, Jonathan raised a few points 
> with me and I passed them on
> to the design team and to the CCAMP mailing list. A quick 
> analysis revealed that only a
> very minor change was required. This was agreed upon by the 
> design teams and the drafts
> were published.
> 
> The drafts are now on their way to the IESG for review.
> 
> It is worth pointing out that the two design teams concerned 
> are joint design teams of the
> IETF's CCAMP working group and the ITU-T's SG15. The reason 
> for having a joint design team
> is so that the work progresses faster and in tandem. One 
> might reasonably assume that the
> SG15 members of the team were regularly reporting back to the 
> ITU-T on the progress of the
> drafts, as the CCAMP members were required by the working 
> group to do. So, while the
> liaison process was useful for collecting together the formal 
> review comments, it was
> somewhat secondary to the joint development of the drafts by 
> members of both groups.
> 
> Now to your specific email.
> 
> > We very much appreciate to continue the process of exchange 
> and liaison with CCAMP.
> 
> Thank you. On the whole I think it has been valuable and has 
> ensured that the two groups
> are in synch with regard to the requirements on GMPLS 
> networks for the support of ASON.
> Certainly, given the unanimity of support in the design teams 
> for the two drafts, we have
> been successful.
> 
> Of course, i am considerably concerned by the extremely long 
> time that it has taken to
> produce this relatively simple draft. Truly, design by 
> committee is a long-winded process.
> But, in this case, it has been worth it to ensure the 
> complete agreement that we have
> achieved.
> 
> > The second paragraph of your email however reminds me that these
> > drafts have not been formally liaised to SG15 yet.
> 
> This is so, and I am surprised that you expect any different. 
> Certainly the ITU-T is not
> in the habit of liaising its draft recomendations to the IETF 
> and gaiting their progress
> pending a response.
> 
> But recall that the previous version of the draft was liaised 
> ot SG15, and SG15 reviewed
> it thoroughly and rseponded fully.
> Since the review comments were significantly incorporated, a 
> further liaison of the drafts
> was clearly unnecessary. In any case, the design teams had 
> had ample oportunity to review
> the drafts, and many members of the SG15 community had also 
> been afforded that oportunity
> through the normal open and public IETF process.
> 
> >It also reminds me that the Q14/15 Liaison Statement from the
> > Februrary 2004 Chicago meeting to CCAMP
> >
> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
> /COMMUNICATIONS/ccamp/IETF_ccamp_G.7713.2_comments.html
> > has never been responded by CCAMP yet.
> 
> That is true.
> 
> I'm afraid that I was not aware that a response was either 
> required or desired (although I
> admit that it would have been polite if Kireeti and I had 
> acknowledged the receipt). This
> may be due to the fact that I do not understand ITU-T 
> phrasing, because I see that the
> liaison is marked as "For: Action" with "Deadline: 12th April 
> 2004". This was interpretted
> as meaning that SG15 would like CCAMP and the design teams to 
> act on the liaison before
> 12th April - which they did.
> 
> Had there been a direct request for a response we would have 
> endeavored to reply in the
> specified timescale. (Although we are all human, and have day 
> jobs, so sometimes these
> things do get dropped.)
> 
> If you feel that it would be helpful for CCAMP to generate a 
> liaison about these drafts,
> please let me know and we will be glad to supply one.
> 
> The paragraph from my email that you cite reads as follows.
> 
> > > As you will recall, these drafts (which have been through WG
> > > last call and have had a full process of exchange and liaison
> > > with the ITU-T's Study Group 15) had been reviewed by the
> > > AD and a few comments were raised. These comments were
> > > addressed immediately before the San Diego IETF, but the
> > > editors just missed the publication deadline.
> 
> I think you will agree that the liaison process for these 
> drafts has been very full.
> Probably more extensive than any for a long time. And the 
> fact that the drafts were
> authored by design teams deliberately picked to include 
> members of both groups is evidence
> of the lengths to which this process was taken.
> 
> I hope this answers all of your questions, but please do let 
> me know if there is more
> information that would help you.
> 
> Regards,
> Adrian
> 
> 

Delivery-date: Thu, 07 Oct 2004 00:18:29 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: ASON Opacity and liaisons
Date: Thu, 7 Oct 2004 01:16:25 +0100

Hello Kam,

Thanks for the email. Let me go over the history before coming to your specific points.

The review and liaison in Chicago were in direct response to CCAMP passing the latest
copies of the drafts to SG15 and soliciting input. They were notified to the CCAMP mailing
list on 1st March, (and so copied to the ASON signaling and routing requirements design
teams), published on the CCAMP alternative web pages, and published on the IETF's liaison
pages.

The CCAMP design teams responsible for the ASON signaling and routing requirements drafts
were certainly grateful for the review comments received in a formal liaison from SG15.
You may be sure that the points raised were fully considered, especially since I was in
the room in Chicago when drafts were reviewed and the liaison statement was drafted.

The liaisons were subsequently presented to CCAMP in Seoul by Lyndon Ong and the efforts
of the ITU-T were recognized from the chair.

On return from Seoul, the editor of the ASON Signaling Requirements draft was able to
agree upon the points for inclusion in the draft after discussion with his design team.
The changes made were largely in line with those suggested by the liaison.

After Seoul, the editor of the ASON Routing Requirements draft was able to reach agreement
on all but three points. She quickly took these remaining issues to the CCAMP mailing list
where they were (hotly) debated. After a while it was possible to separate the requirement
issues from the discussion of solutions and progress was made thanks to the participation
of no fewer than seven people who regularly attend and participate in SG15. The debate
quietened down after March 19th with sufficient consensus for the design team to move
forward.

A working group last call was issued for the ASON Routing Requirements draft on April 15th
and included the text...
> The ASON Routing Reqts DT has updated the following draft based on
> ITU Q14/15's Liaison and CCAMP mail list comments.
This means that the SG15 comments were included as modified by the discussions on the
CCAMP mailing list, and that the draft had been agreed upon by the whole design team.

A working group last call was issued for the ASON Signaling Requirements draft on April
26th and included the text...
> The authors of this draft have updated it to reflect the comments on the
> mailing list and the helpful feedback from ITU-T SG15 Question 14.
This means that the SG15 comments were included. In fact, the draft had been updated and
agreed upon by the whole design team. The fact of the last call was circulated to the
IETF's OSPF, IS-IS and Routing working groups in order to ensure a wide coverage of
potential reviewers.

It is unthinkable that either draft would have been published or put up for last call if
any member of the design team had raised an objection.

A working group last call is public and is not confined to any particular body. It gives
an opportunity for everyone who is subscribed to the mailing list to comment. This covers
a considerable number of participants in SG15 and, of course, includes the whole of the
design team.

The ASON Routing Requirements draft completed last call with a few minor comments. It
turned out that most of these comments were questioning the validity of text in G.7715.1,
and CCAMP's position was (of course) that the draft must reflect the statements in that
recommendation and not try to invent different requirements. The other comments were
editorial nits. The draft was duly updated with agreement from the design team, and
re-published on May 6th with notification on the CCAMP mailing list.

The ASON Signaling Requirements draft completed last call with no comments.

Both drafts were passed to the AD for review.

On May 10th a further liaison was received from SG15 Q.14/15 thanking CCAMP and the
members of the ASON Routing Requirements Design Team for their efforts to understand and
capture ASON Routing Requirements for the future work in IETF. This liaison was published
and notified on the CCAMP mailing list.

In the run-up to the San Diego IETF, both drafts were reviewed by the AD and were updated
accordingly. The changes were minor and for clarification only. Again, the design team
agreed the changes. The drafts were not published before San Diego, but were made publicly
available.

In San Diego, both drafts were presented and the plan to forward them to the IESG was
announced. However, Jonathan Sadler raised an important concern that the drafts did not
sufficiently capture the notion of subnetwork opacity. This was picked up by a number of
people attending the meeting and it was immediately agreed that a gathering of the design
team, working group chairs and other interested parties should be held at once. Although
the process had already been completed with ample chance for the authors, the design team
and external reviewers to discover and raise this point, the gathering agreed that
Jonathan should be deputed to review the drafts in the light of his concerns and raise any
specific issues with me.

Over the next couple of months, Jonathan raised a few points with me and I passed them on
to the design team and to the CCAMP mailing list. A quick analysis revealed that only a
very minor change was required. This was agreed upon by the design teams and the drafts
were published.

The drafts are now on their way to the IESG for review.

It is worth pointing out that the two design teams concerned are joint design teams of the
IETF's CCAMP working group and the ITU-T's SG15. The reason for having a joint design team
is so that the work progresses faster and in tandem. One might reasonably assume that the
SG15 members of the team were regularly reporting back to the ITU-T on the progress of the
drafts, as the CCAMP members were required by the working group to do. So, while the
liaison process was useful for collecting together the formal review comments, it was
somewhat secondary to the joint development of the drafts by members of both groups.

Now to your specific email.

> We very much appreciate to continue the process of exchange and liaison with CCAMP.

Thank you. On the whole I think it has been valuable and has ensured that the two groups
are in synch with regard to the requirements on GMPLS networks for the support of ASON.
Certainly, given the unanimity of support in the design teams for the two drafts, we have
been successful.

Of course, i am considerably concerned by the extremely long time that it has taken to
produce this relatively simple draft. Truly, design by committee is a long-winded process.
But, in this case, it has been worth it to ensure the complete agreement that we have
achieved.

> The second paragraph of your email however reminds me that these
> drafts have not been formally liaised to SG15 yet.

This is so, and I am surprised that you expect any different. Certainly the ITU-T is not
in the habit of liaising its draft recomendations to the IETF and gaiting their progress
pending a response.

But recall that the previous version of the draft was liaised ot SG15, and SG15 reviewed
it thoroughly and rseponded fully.
Since the review comments were significantly incorporated, a further liaison of the drafts
was clearly unnecessary. In any case, the design teams had had ample oportunity to review
the drafts, and many members of the SG15 community had also been afforded that oportunity
through the normal open and public IETF process.

>It also reminds me that the Q14/15 Liaison Statement from the
> Februrary 2004 Chicago meeting to CCAMP
>
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_G.7713.2_comments.html
> has never been responded by CCAMP yet.

That is true.

I'm afraid that I was not aware that a response was either required or desired (although I
admit that it would have been polite if Kireeti and I had acknowledged the receipt). This
may be due to the fact that I do not understand ITU-T phrasing, because I see that the
liaison is marked as "For: Action" with "Deadline: 12th April 2004". This was interpretted
as meaning that SG15 would like CCAMP and the design teams to act on the liaison before
12th April - which they did.

Had there been a direct request for a response we would have endeavored to reply in the
specified timescale. (Although we are all human, and have day jobs, so sometimes these
things do get dropped.)

If you feel that it would be helpful for CCAMP to generate a liaison about these drafts,
please let me know and we will be glad to supply one.

The paragraph from my email that you cite reads as follows.

> > As you will recall, these drafts (which have been through WG
> > last call and have had a full process of exchange and liaison
> > with the ITU-T's Study Group 15) had been reviewed by the
> > AD and a few comments were raised. These comments were
> > addressed immediately before the San Diego IETF, but the
> > editors just missed the publication deadline.

I think you will agree that the liaison process for these drafts has been very full.
Probably more extensive than any for a long time. And the fact that the drafts were
authored by design teams deliberately picked to include members of both groups is evidence
of the lengths to which this process was taken.

I hope this answers all of your questions, but please do let me know if there is more
information that would help you.

Regards,
Adrian

Delivery-date: Wed, 06 Oct 2004 21:16:59 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: ASON Opacity
Date: Wed, 6 Oct 2004 17:15:10 -0400 

Hi Adrian,

We very much appreciate to continue the process of exchange and liaison with CCAMP.
The second paragraph of your email however reminds me that these drafts have not been formally liaised to SG15 yet. It also reminds me that the Q14/15 Liaison Statement from the Februrary 2004 Chicago meeting to CCAMP 
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_G.7713.2_comments.html
has never been responded by CCAMP yet. 

Regards,
Kam Lam 
ITU-T Q14/15

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2004 8:54 PM
> To: [email-masked]
> Subject: ASON Opacity
> 
> 
> Hi,
> 
> Here is my summary of the changes proposed by Jonathan Sadler 
> for inclusion in the CCAMP
> ASON Signaling and Routing Requirements drafts.
> 
> As you will recall, these drafts (which have been through WG 
> last call and have had a full
> process of exchange and liaison with the ITU-T's Study Group 
> 15) had been reviewed by the
> AD and a few comments were raised. These comments were 
> addressed immediately before the
> San Diego IETF, but the editors just missed the publication deadline.
> 
> Normally we would have gone ahead and submitted the drafts by 
> now and they would have gone
> through the IESG. However, Jonathan spoke up in the CCAMP 
> meeting in San Diego to express
> his reservations about the inadequate description of how the 
> "opacity" of a sub-network
> should be preserved. We were concerned to get the drafts 
> right and so held back from
> re-publication.
> 
> Jonathan was kind enough to agree to review the two drafts 
> and document his concerns in
> greater detail. Pressure of work has unfortunately meant that 
> Jonathan has been unable to
> do more than send me a draft of his worries. Since we must 
> move forward with these
> documents I am taking the liberty of interpreting his draft 
> and expressing my views on
> what changes should be made. This will allow the editors of 
> the two documents to debate
> the points, make any necessary changes, and submit the 
> documents. There are plenty of SG15
> people on this list, so I know that any errors I make in my 
> representation on Jonathan's
> views will be immediately jumped upon.
> 
> Since the changes suggested to the document are so very 
> small, I shall not be calling for
> a further WG last call. This means that I expect the editors 
> to make a call on the changes
> necessary and to inform the WG of what they have done. I do 
> not expect a long discussion.
> 
> Thanks,
> Adrian
> 
> ====
> 
> ASON Signaling Requirements Draft
> 
> Issue:
> The draft states that it provides "signaling requirements for 
> G.8080 distributed call and
> connection management based on GMPLS, within a GMPLS based 
> control domain (I-NNI) and
> between GMPLS based control domains (E-NNI)." (Section 4, PP 
> 2)  This implies that the
> requirements are consistent regardless of where the ingress 
> and egress of a connection is,
> as long as all control domains involved in the connection use GMPLS.
> Response:
> I believe that Jonathan's inferred implication is correct and 
> that the text as it
> currently stands is reliable. That is, the requirements are 
> for GMPLS signaling at I-NNI
> and E-NNI reference points and that no statement is made 
> about the location of the ingress
> or egress of calls or connections. No change to the text is 
> needed to clarify this.
> 
> Issue:
> It should be noted that the draft does allow for different 
> non-GMPLS Control Plane
> signaling protocols to be used in adjoining domains (Section 
> 4, PP2), and states that
> interworking between signaling protocols is outside of the 
> scope of the requirements
> document.  This statement eludes to the opacity of the 
> subnetwork, but does not explicitly
> state it.
> Response:
> This is correct, but it might depend on the definition of 
> "sub-network" and "opacity".
> Since the term "opaque" is neither defined nor used in G.805, 
> G.8080 or G.7713 it would be
> inappropriate to introduce the term in this draft. In fact, 
> in the context of this
> paragraph, the point seems to be well covered by exactly what 
> is stated here. The draft is
> looking at signaling protocols (not at next hop routing, nor 
> path computation) and must
> express how the signaling message is passed from one 
> GMPLS-capable node to the next. This
> it does, and I don't believe any further change to the 
> document is necessary.
> 
> Issue:
> The draft further goes on to say that for Call requests, 
> "end-to-end signaling should be
> facilitated regardless of the administrative boundaries and 
> protocols within the network."
> (Section 4, PP 2)  While subnetwork boundaries are instituted 
> to realize administrative
> and signalling protocol boundaries in the network, there are 
> other reasons to create
> subnetwork boundaries, including differences in how a 
> subnetwork connection is realized
> within the subnetwork.
> Response:
> I understand this point, but the logic is reversed. The draft 
> does not refer to
> subnetworks and so the reasons for their existence are not 
> important in this context.
> Further, it should be noted that an important feature of 
> G.8080 is that a "control
> network" can include multiple "subnetworks". Still further, I 
> am unclear how the
> realization of Connections within a subnetwork is important 
> to the end-to-end nature of
> Call request signaling. However, it might be appropriate (or 
> harmless) to change the text
> to say "end-to-end signaling should be facilitated regardless 
> of the administrative
> boundaries, protocols within the network or method of 
> realization of connections within
> any part of the network."
> 
> Issue:
> Further to this point, Jonathan and I have discussed whether 
> the end-to-end requirements
> as expressed in Section 4 PP2 and the "end-to-end principle" 
> applied to Internet protocols
> are compatible with the need to establish ASON Connections. I 
> believe, however, that my
> response to him indicated that the "end-to-end principle" 
> dictates not that state is only
> held at end points, but that state is only held on a 
> need-to-know basis. Thus Call state
> is only held at UNI and E-NNI reference points, while 
> Connection state is held at UNI,
> E-NNI and I-NNI reference points. It would be incorrect to 
> require that Call state should
> be held at I-NNI reference points (even if that state is held 
> unprocessed in a transparent
> manner). No change to the text is required for this point.
> 
> ======
> 
> ASON Routing Requirements Draft
> 
> Jonathan points out that the draft already contains 
> requirements that are developed from
> the autonomous nature of Routing Areas. There is a tendency, 
> I feel, in what Jonathan says
> to tie a subnetwork too closely to the concept of a Routing 
> Area where G.7715 clearly
> refers to "a subnetwork or a routing area" as distinct things 
> that may be commonly
> referred to as a "node". Further, neither G.7715, nor 
> G.7715.1 uses the term "opaque" so
> it is a little hard to conjure a precise wording for 
> additions to this draft.
> 
> Nevertheless, Jonathan makes a couple of simple suggestions 
> for additions to the draft as
> follows.
> 
> Issue:
> A routing area is a subnetwork with visibility to the egress 
> links connected to the
> subnetworks ports (see G.8080 Sec 6.2)
> Response:
> This is not the definition of Routing Area that I find in 
> section 6.2 of G.8080 (perhaps I
> have a different version?). However, the definition found in 
> G.8080 *is* useful and should
> be included in our draft. It runs...
> "Within the context of this Recommendation a routing area 
> exists within a single layer
> network. A routing area is defined by a set of subnetworks, 
> the SNPP links that
> interconnect them, and the SNPPs representing the ends of the 
> SNPP links exiting that
> routing area. A routing area may contain smaller routing 
> areas interconnected by SNPP
> links. The limit of subdivision results in a routing area 
> that contains two subnetworks
> and one link."
> Fortunately, this definition is included (verbatim) in 
> Appendix 2 of the draft. So no text
> change is required.
> 
> Issue:
> The method used by a subnetwork to realize a subnetwork 
> connection is not visible to a
> route calculation being performed in the containing area.
> Response:
> This statement seems to mix routing areas and subnetworks too 
> freely. A routing area can
> surely see all realizations within subnetworks that comprise 
> the routing area itself.
> However, if we are talking about hierarchical routing areas 
> then, yes, this is precisely
> the definition of the hierarchical routing area and the draft 
> goes into considerable
> detail about the way in which reachability information may be 
> exchanged, but that routing
> information abstraction is used to limit the visibility into 
> the child RAs topology and
> capabilities. I don't believe any further additions are required.
> 
> Issue:
> The subnetwork may provide an abstracted representation of 
> the connectivity available
> through the domain to the higher level routing area.  This is 
> done at the discretion of
> routing controller(s) within the subnetwork, and not through 
> filtering performed by the
> higher level routing controllers.
> Response:
> There are two statements here. The first is true and is 
> described in some detail in
> section 4.2 of the draft. The second statement again mixes 
> subnetworks and routing areas,
> but if we re-state it fully in terms of RAs we also find text 
> that covers this situation
> in section 4.2 of the draft. Further, we should note that 
> G.7715.1 actually also allows
> the filtering within the parent RA...
> "In the second approach, the Level N+1 RC listens to the 
> routing protocol exchange
> occurring in each contained Level N RA and retrieves the 
> endpoints being announced by the
> Level N routing instance(s) and the full Level N topology.  
> This information may be
> summarized into one or more address prefixes and an 
> abstracted topology in order to
> facilitate scalability."
> Thus, I think no change to the draft is required on this 
> account either.
> 
> 
> 
> 
> 

Delivery-date: Wed, 06 Oct 2004 14:09:53 +0000
Date: Wed, 06 Oct 2004 11:07:21 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------zemlrixqlxjwempbnumz
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Lovely  animals<br><br>

<br>Password:  <img src="cid:yecuwcpzvb.gif"><br>
<br>
</body></html>

----------zemlrixqlxjwempbnumz
Content-Type: image/gif; name="yecuwcpzvb.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="yecuwcpzvb.gif"
Content-ID: 

----------zemlrixqlxjwempbnumz
Content-Type: application/octet-stream; name="Garry.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Garry.zip"

----------zemlrixqlxjwempbnumz--

Delivery-date: Tue, 05 Oct 2004 14:10:57 +0000
content-class: urn:content-classes:message
Subject: RE: ASON Opacity
Date: Tue, 5 Oct 2004 09:08:48 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Adrian,

The ASON Routing Requirements DT agrees with your analysis regarding the
ASON Routing Requirements Draft. We will provide an updated draft by
next Friday.
Thanks,
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Wednesday, September 29, 2004 8:54 PM
To: [email-masked]
Subject: ASON Opacity

Hi,

Here is my summary of the changes proposed by Jonathan Sadler for
inclusion in the CCAMP
ASON Signaling and Routing Requirements drafts.

As you will recall, these drafts (which have been through WG last call
and have had a full
process of exchange and liaison with the ITU-T's Study Group 15) had
been reviewed by the
AD and a few comments were raised. These comments were addressed
immediately before the
San Diego IETF, but the editors just missed the publication deadline.

Normally we would have gone ahead and submitted the drafts by now and
they would have gone
through the IESG. However, Jonathan spoke up in the CCAMP meeting in San
Diego to express
his reservations about the inadequate description of how the "opacity"
of a sub-network
should be preserved. We were concerned to get the drafts right and so
held back from
re-publication.

Jonathan was kind enough to agree to review the two drafts and document
his concerns in
greater detail. Pressure of work has unfortunately meant that Jonathan
has been unable to
do more than send me a draft of his worries. Since we must move forward
with these
documents I am taking the liberty of interpreting his draft and
expressing my views on
what changes should be made. This will allow the editors of the two
documents to debate
the points, make any necessary changes, and submit the documents. There
are plenty of SG15
people on this list, so I know that any errors I make in my
representation on Jonathan's
views will be immediately jumped upon.

Since the changes suggested to the document are so very small, I shall
not be calling for
a further WG last call. This means that I expect the editors to make a
call on the changes
necessary and to inform the WG of what they have done. I do not expect a
long discussion.

Thanks,
Adrian

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

ASON Signaling Requirements Draft

Issue:
The draft states that it provides "signaling requirements for G.8080
distributed call and
connection management based on GMPLS, within a GMPLS based control
domain (I-NNI) and
between GMPLS based control domains (E-NNI)." (Section 4, PP 2)  This
implies that the
requirements are consistent regardless of where the ingress and egress
of a connection is,
as long as all control domains involved in the connection use GMPLS.
Response:
I believe that Jonathan's inferred implication is correct and that the
text as it
currently stands is reliable. That is, the requirements are for GMPLS
signaling at I-NNI
and E-NNI reference points and that no statement is made about the
location of the ingress
or egress of calls or connections. No change to the text is needed to
clarify this.

Issue:
It should be noted that the draft does allow for different non-GMPLS
Control Plane
signaling protocols to be used in adjoining domains (Section 4, PP2),
and states that
interworking between signaling protocols is outside of the scope of the
requirements
document.  This statement eludes to the opacity of the subnetwork, but
does not explicitly
state it.
Response:
This is correct, but it might depend on the definition of "sub-network"
and "opacity".
Since the term "opaque" is neither defined nor used in G.805, G.8080 or
G.7713 it would be
inappropriate to introduce the term in this draft. In fact, in the
context of this
paragraph, the point seems to be well covered by exactly what is stated
here. The draft is
looking at signaling protocols (not at next hop routing, nor path
computation) and must
express how the signaling message is passed from one GMPLS-capable node
to the next. This
it does, and I don't believe any further change to the document is
necessary.

Issue:
The draft further goes on to say that for Call requests, "end-to-end
signaling should be
facilitated regardless of the administrative boundaries and protocols
within the network."
(Section 4, PP 2)  While subnetwork boundaries are instituted to realize
administrative
and signalling protocol boundaries in the network, there are other
reasons to create
subnetwork boundaries, including differences in how a subnetwork
connection is realized
within the subnetwork.
Response:
I understand this point, but the logic is reversed. The draft does not
refer to
subnetworks and so the reasons for their existence are not important in
this context.
Further, it should be noted that an important feature of G.8080 is that
a "control
network" can include multiple "subnetworks". Still further, I am unclear
how the
realization of Connections within a subnetwork is important to the
end-to-end nature of
Call request signaling. However, it might be appropriate (or harmless)
to change the text
to say "end-to-end signaling should be facilitated regardless of the
administrative
boundaries, protocols within the network or method of realization of
connections within
any part of the network."

Issue:
Further to this point, Jonathan and I have discussed whether the
end-to-end requirements
as expressed in Section 4 PP2 and the "end-to-end principle" applied to
Internet protocols
are compatible with the need to establish ASON Connections. I believe,
however, that my
response to him indicated that the "end-to-end principle" dictates not
that state is only
held at end points, but that state is only held on a need-to-know basis.
Thus Call state
is only held at UNI and E-NNI reference points, while Connection state
is held at UNI,
E-NNI and I-NNI reference points. It would be incorrect to require that
Call state should
be held at I-NNI reference points (even if that state is held
unprocessed in a transparent
manner). No change to the text is required for this point.

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

ASON Routing Requirements Draft

Jonathan points out that the draft already contains requirements that
are developed from
the autonomous nature of Routing Areas. There is a tendency, I feel, in
what Jonathan says
to tie a subnetwork too closely to the concept of a Routing Area where
G.7715 clearly
refers to "a subnetwork or a routing area" as distinct things that may
be commonly
referred to as a "node". Further, neither G.7715, nor G.7715.1 uses the
term "opaque" so
it is a little hard to conjure a precise wording for additions to this
draft.

Nevertheless, Jonathan makes a couple of simple suggestions for
additions to the draft as
follows.

Issue:
A routing area is a subnetwork with visibility to the egress links
connected to the
subnetworks ports (see G.8080 Sec 6.2)
Response:
This is not the definition of Routing Area that I find in section 6.2 of
G.8080 (perhaps I
have a different version?). However, the definition found in G.8080 *is*
useful and should
be included in our draft. It runs...
"Within the context of this Recommendation a routing area exists within
a single layer
network. A routing area is defined by a set of subnetworks, the SNPP
links that
interconnect them, and the SNPPs representing the ends of the SNPP links
exiting that
routing area. A routing area may contain smaller routing areas
interconnected by SNPP
links. The limit of subdivision results in a routing area that contains
two subnetworks
and one link."
Fortunately, this definition is included (verbatim) in Appendix 2 of the
draft. So no text
change is required.

Issue:
The method used by a subnetwork to realize a subnetwork connection is
not visible to a
route calculation being performed in the containing area.
Response:
This statement seems to mix routing areas and subnetworks too freely. A
routing area can
surely see all realizations within subnetworks that comprise the routing
area itself.
However, if we are talking about hierarchical routing areas then, yes,
this is precisely
the definition of the hierarchical routing area and the draft goes into
considerable
detail about the way in which reachability information may be exchanged,
but that routing
information abstraction is used to limit the visibility into the child
RAs topology and
capabilities. I don't believe any further additions are required.

Issue:
The subnetwork may provide an abstracted representation of the
connectivity available
through the domain to the higher level routing area.  This is done at
the discretion of
routing controller(s) within the subnetwork, and not through filtering
performed by the
higher level routing controllers.
Response:
There are two statements here. The first is true and is described in
some detail in
section 4.2 of the draft. The second statement again mixes subnetworks
and routing areas,
but if we re-state it fully in terms of RAs we also find text that
covers this situation
in section 4.2 of the draft. Further, we should note that G.7715.1
actually also allows
the filtering within the parent RA...
"In the second approach, the Level N+1 RC listens to the routing
protocol exchange
occurring in each contained Level N RA and retrieves the endpoints being
announced by the
Level N routing instance(s) and the full Level N topology.  This
information may be
summarized into one or more address prefixes and an abstracted topology
in order to
facilitate scalability."
Thus, I think no change to the draft is required on this account either.

Delivery-date: Mon, 04 Oct 2004 19:45:49 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-05.txt
Date: Mon, 04 Oct 2004 15:44:49 -0400

--NextPart

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

	Title		: 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-05.txt
	Pages		: 20
	Date		: 2004-10-4
	
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-05.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-recovery-terminology-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-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="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-05.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 04 Oct 2004 19:45:41 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-functional-03.txt
Date: Mon, 04 Oct 2004 15:44:12 -0400

--NextPart

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

	Title		: Generalized Multi-Protocol Label Switching (GMPLS) 
			  Recovery Functional Specification
	Author(s)	: J. Lang, B. Rajagopalan
	Filename	: draft-ietf-ccamp-gmpls-recovery-functional-03.txt
	Pages		: 20
	Date		: 2004-10-4
	
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-03.txt

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 04 Oct 2004 19:45:33 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-04.txt
Date: Mon, 04 Oct 2004 15:44:07 -0400

--NextPart

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

	Title		: Analysis of 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-04.txt
	Pages		: 42
	Date		: 2004-10-4
	
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-04.txt

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 04 Oct 2004 15:45:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: CCAMP Protection and Restoration Drafts
Date: Mon, 4 Oct 2004 16:41:58 +0100

Hi Alex,

The three CCAMP protection and restoration drafts have been updated to handle your
comments from AD review, and new copies are in the repository.

Kireeti was shepherding chair under the PROTO Team Pilot, and has cleared the drafts.

Could you please take the drafts to the IESG (probably as a block).

Thanks,
Adrian

Delivery-date: Mon, 04 Oct 2004 11:45:23 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Node-ID-based Hello Workging Group last call complete
Date: Sun, 3 Oct 2004 21:28:05 +0100

This email concludes the Working Group last call on
draft-ietf-ccamp-rsvp-node-id-based-hello

Authors,

Please address the comments made during last call by updating the draft and republishing.
Please inform the list of any changes you make.

Thanks,
Adrian

Delivery-date: Mon, 04 Oct 2004 11:45:15 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Communication of Alarm Info Workging Group last call complete
Date: Sun, 3 Oct 2004 21:29:08 +0100

This email concludes the Working Group last call on draft-ietf-ccamp-gmpls-alarm-spec

Authors,

Please address the comments made during last call by updating the draft and republishing.
Please inform the list of any changes you make.

Thanks,
Adrian

Delivery-date: Sat, 02 Oct 2004 10:03:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Fw: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-04.txt
Date: Sat, 2 Oct 2004 11:01:36 +0100

Hi Alex,

With some help from Eric Gray, the authors have completed the updates to this draft to
resolve the issues that you raised as a result of your review and the review by the
Routing Directorate. I have looked through the changes and can confirm that they have
caught all of the points raised.

Could you please take this draft to the IESG now.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 01, 2004 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-04.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 : Framework for GMPLS-based Control of SDH/SONET Networks
> Author(s) : G. Bernstein, et al.
> Filename : draft-ietf-ccamp-sdhsonet-control-04.txt
> Pages : 30
> Date : 2004-10-1
>
> GMPLS consists of a suite of protocol extensions to MPLS to make
>    these protocols more generally applicable, to include - for example
>    - control of non-packet based switching, and particularly, optical
>    switching.  One area of prime consideration is to use Generalized
>    MPLS (GMPLS) protocols in upgrading the control plane of optical
>    transport networks.  This document illustrates this process by
>    describing those extensions to GMPLS protocols that are directed
>    towards controlling SDH/SONET networks.  SDH/SONET networks make
>    very good examples of this process since they possess a rich
>    multiplex structure, a variety of protection/restoration options,
>    are well defined, and are widely deployed. The document discusses
>    extensions to GMPLS routing protocols to disseminate information
>    needed in transport path computation and network operations,
>    together with the extensions to GMPLS label distribution protocols
>    needed for the provisioning of transport circuits. New capabilities
>    that an GMPLS control plane would bring to SDH/SONET networks, such
>    as new restoration methods and multi-layer circuit establishment,
>    are also discussed.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-04.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ccamp-sdhsonet-control-04.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-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.
>

Delivery-date: Fri, 01 Oct 2004 19:51:12 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-04.txt
Date: Fri, 01 Oct 2004 15:50:14 -0400

--NextPart

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

	Title		: Framework for GMPLS-based Control of SDH/SONET Networks
	Author(s)	: G. Bernstein, et al. 
	Filename	: draft-ietf-ccamp-sdhsonet-control-04.txt
	Pages		: 30
	Date		: 2004-10-1
	
GMPLS consists of a suite of protocol extensions to MPLS to make 
   these protocols more generally applicable, to include - for example
   - control of non-packet based switching, and particularly, optical 
   switching.  One area of prime consideration is to use Generalized 
   MPLS (GMPLS) protocols in upgrading the control plane of optical 
   transport networks.  This document illustrates this process by 
   describing those extensions to GMPLS protocols that are directed 
   towards controlling SDH/SONET networks.  SDH/SONET networks make 
   very good examples of this process since they possess a rich 
   multiplex structure, a variety of protection/restoration options, 
   are well defined, and are widely deployed. The document discusses 
   extensions to GMPLS routing protocols to disseminate information 
   needed in transport path computation and network operations, 
   together with the extensions to GMPLS label distribution protocols 
   needed for the provisioning of transport circuits. New capabilities 
   that an GMPLS control plane would bring to SDH/SONET networks, such 
   as new restoration methods and multi-layer circuit establishment, 
   are also discussed.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-04.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 01 Oct 2004 19:07:56 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: draft-ietf-ccamp-gmpls-architecture-07.txt in RFC Ed Q
Date: Fri, 1 Oct 2004 20:05:23 +0100

Folks,

To keep you in the loop....

Kireeti and I have been discussing with the ADs and RFC Ed. the backlog of drafts in the
RFC Ed. Q.

A huge number are hung up on the GMPLS Architecture draft which is, itself blocked by a
huge number of drafts.

Although we have almost cleared the backlog, this is not progressing fast enough. So we
have decided to adjust the list of drafts marked as normative in the Architecture. After
all, we reason, the Architecture should not have normative dependencies on drafts that are
an implementation of the Architecture.

The email trail below shows the changes proposed.

Thanks,
Adrian

----- Original Message ----- 
From: "RFC Editor" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "Bill Fenner" <[email-masked]>; "'Kireeti Kompella'"
<[email-masked]>; "RFC Editor" <[email-masked]>
Sent: Friday, October 01, 2004 7:52 PM
Subject: Re: draft-ietf-ccamp-gmpls-architecture-07.txt in RFC Ed Q

> Adrian,
>
> We will incorporate the new reference section as indicated below.
>
> Alex and/or Bill, please let us know that you agree to these changes.
>
> RFC Editor
>
>
> On Fri, Oct 01, 2004 at 12:39:49AM +0100, Adrian Farrel wrote:
> > Thanks, this is excellent.
> >
> > Below is a list of the changes.
> >
> > This has been discussed with Alex and Bill (in fact, they have leant on me to make the
> > changes) so i don't suppose it will be hard to get their positive ack.
> >
> > Regards,
> > Adrian
> >
> > ======
> >
> > New designation of Normative/Informational References in
> > "Generalized Multi-Protocol Label Switching Architecture"
> > draft-ietf-ccamp-gmpls-architecture-07.txt
> >
> > ==== Previous designation as appearing in published draft ====
> >
> > 18. References
> >
> > 18.1 Normative References
> >
> >    [ANSI-T1.105]   "Synchronous Optical Network (SONET): Basic
> >                    Description Including Multiplex Structure, Rates,
> >                    And Formats," ANSI T1.105, 2000.
> >
> >    [BUNDLE]        K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
> >                    in MPLS Traffic Engineering," Work in Progress,
> >                    draft-ietf-mpls-bundle-04.txt.
> >
> >    [GMPLS-FUNCT]   J.P.Lang and B.Rajagopalan (Editors) et al.,
> >                    "Generalized MPLS Recovery Functional
> >                    Specification," Work in Progress, draft-ietf-ccamp-
> >                    gmpls-recovery-functional-01.txt.
> >
> >    [GMPLS-G709]    D.Papadimitriou (Editor) et al., "GMPLS Signaling
> >                    Extensions for G.709 Optical Transport Networks
> >                    Control," Work in progress, draft-ietf-ccamp-gmpls-
> >                    g709-03.txt.
> >
> >    [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the
> >                    Overlay Model," Work in Progress, draft-ietf-ccamp-
> >                    gmpls-overlay-01.txt.
> >
> >    [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing
> >                    Extensions in Support of Generalized MPLS," Work in
> >                    Progress, draft-ietf-ccamp-gmpls-routing-05.txt.
> >
> >    [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al.,
> >                    "Generalized MPLS Extensions for SONET and SDH
> >                    Control," Work in progress, draft-ietf-ccamp-gmpls-
> >                    sonet-sdh-08.txt.
> >
> >    [HIERARCHY]     K.Kompella and Y.Rekhter, "LSP Hierarchy with
> >                    Generalized MPLS TE," Work in Progress, draft-ietf-
> >                    mpls-lsp-hierarchy-08.txt.
> >
> >    [ITUT-G.707]    ITU-T, "Network Node Interface for the Synchronous
> >                    Digital Hierarchy", Recommendation G.707, October
> >                    2000.
> >
> >    [ITUT-G.709]    ITU-T, "Interface for the Optical Transport Network
> >                    (OTN)," Recommendation G.709 version 1.0 (and
> >                    Amendment 1), February 2001 (and October 2001).
> >
> >    [ITUT-G.841]    ITU-T, "Types and Characteristics of SDH Network
> >                    Protection Architectures," Recommendation G.841,
> >                    October 1998.
> >
> >    [LMP]           J.P.Lang (Editor) et al., "Link Management Protocol
> >                    (LMP)," Work in progress, draft-ietf-ccamp-lmp-
> >                    09.txt.
> >
> >    [LMP-WDM]       A.Fredette and J.P.Lang (Editors) et al., "LMP for
> >                    WDM Optical Line Systems (LMP-WDM)," Work in
> >                    progress, draft-ietf-ccamp-lmp-wdm-02.txt.
> >
> >    [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions
> >                    in Support of Generalized MPLS," Work in Progress,
> >                    draft-ietf-ccamp-ospf-gmpls-extensions-09.txt.
> >
> >    [OSPF-TE]    D.Katz, D.Yeung, and K.Kompella, "Traffic
> >                 Engineering Extensions to OSPF", Work in Progress,
> >                 draft-katz-yeung-ospf-traffic-09.txt.
> >
> >    [RFC1393]    G.Malkin, "Traceroute Using an IP Option", IETF RFC
> >                 1393, January 1993.
> >
> >    [RFC2026]    S.Bradner, "The Internet Standards Process -- Revision
> >                 3," BCP 9, IETF RFC 2026, October 1996.
> >
> >    [RFC2119]    S.Bradner, "Key words for use in RFCs to Indicate
> >                 Requirement Levels", BCP 14, IETF RFC 2119, March 1997.
> >
> >    [RFC2151]    G.Kessler and S.Shepard, "A Primer On Internet and
> >                 TCP/IP Tools and Utilities", IETF RFC 2151, June 1997.
> >
> >    [RFC2385]    A.Heffernan, "Protection of BGP Sessions via the TCP
> >                 MD5 Signature Option," IETF RFC 2385, August 1998.
> >
> >    [RFC2402]    S.Kent and R.Atkinson, "IP Authentication Header," IETF
> >                 RFC 2402, November 1998.
> >
> >    [RFC2406]    S.Kent and R. Atkinson, "IP Encapsulating Security
> >                 Payload (ESP)," IETF RFC 2406, November 1998.
> >
> >    [RFC2409]    D.Harkins and D.Carrel, "The Internet Key Exchange
> >                 (IKE)," IETF RFC 2409, November 1998.
> >
> >    [RFC2747]    F.Baker et al., "RSVP Cryptographic Authentication,"
> >                 IETF RFC 2747, January 2000.
> >
> >    [RFC2753]    R.Yavatkar, D.Pendarakis and R.Guerin, "A Framework for
> >                 Policy-based Admission Control," IETF RFC 2753, January
> >                 2000.
> >
> >    [RFC2925]    K.White, "Definitions of Managed Objects for Remote
> >                 Ping, Traceroute, and Lookup Operations," IETF RFC
> >                 2925, September 2000.
> >
> >    [RFC3031]    E.Rosen, A.Viswanathan, and R.Callon, "Multiprotocol
> >                 Label Switching Architecture," IETF RFC 3031, January
> >                 2001.
> >
> >    [RFC3036]    L.Andersson, P.Doolan, N.Feldman, A.Fredette, and
> >                 B.Thomas, "LDP Specification," IETF RFC 3036, January
> >                 2001.
> >
> >    [RFC3209]    D.Awduche, et al., "RSVP-TE: Extensions to RSVP for
> >                 LSP Tunnels," IETF RFC 3209, December 2001.
> >
> >    [RFC3212]    B.Jamoussi (Editor) et al., "Constraint-Based LSP Setup
> >                 using LDP," IETF RFC 3212, January 2002.
> >
> >    [RFC3411]    D.Harrington, R.Presuhn and B.Wijnen, "An Architecture
> >                 for Describing Simple Network Management Protocol
> >                 (SNMP) Management Frameworks," IETF RFC 3411, December
> >                 2002.
> >
> >    [RFC3414]    U.Blumenthal and B.Wijnen, "User-based Security Model
> >                 (USM) for version 3 of the Simple Network Management
> >                 Protocol (SNMPv3)," IETF RFC 3414, December 2002.
> >
> >    [RFC3415]    B.Wijnen, R.Presuhn, and K.McCloghrie, "View-based
> >                 Access Control Model (VACM) for the Simple Network
> >                 Management Protocol (SNMP)," IETF RFC 3415, December
> >                 2002.
> >
> >    [RFC3416]    R.Presuhn (Editor), "Version 2 of the Protocol
> >                 Operations for the Simple Network Management Protocol
> >                 (SNMP)," IETF RFC 3416, December 2002.
> >
> >    [RFC3417]    R.Presuhn (Editor), "Transport Mappings for the Simple
> >                 Network Management Protocol (SNMP)," IETF RFC 3417,
> >                 December 2002.
> >
> >    [RFC3477]    K.Kompella and Y.Rekhter, "Signalling Unnumbered
> >                 Links in Resource ReSerVation Protocol - Traffic
> >                 Engineering (RSVP-TE)," IETF RFC 3477, January 2003.
> >
> >    [RFC3471]    L.Berger (Editor) et al., "Generalized MPLS -
> >                 Signaling Functional Description," IETF RFC 3471,
> >                 January 2003.
> >
> >    [RFC3472]    P.Ashwood-Smith and L.Berger (Editors) et al.,
> >                 "Generalized MPLS Signaling - CR-LDP Extensions," IETF
> >                 RFC 3472, January 2003.
> >
> >    [RFC3473]    L.Berger (Editor) et al., "Generalized MPLS
> >                 Signaling - RSVP-TE Extensions," IETF RFC 3473, January
> >                 2003.
> >
> >    [RFC3479]    A.Farrel (Editor) et al., "Fault Tolerance for the
> >                 Label Distribution Protocol (LDP)," IETF RFC 3479,
> >                 February 2003.
> >
> >    [RFC3480]    K.Kompella, Y.Rekhter and A.Kullberg, "Signalling
> >                 Unnumbered Links in CR-LDP," IETF RFC 3480, February
> >                 2003.
> >
> > 18.2 Informative References
> >
> >    [ISIS-TE]    H.Smit and T.Li, "IS-IS extensions for Traffic
> >                 Engineering," Work in Progress, draft-ietf-isis-
> >                 traffic-04.txt.
> >
> >    [ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS
> >                 Extensions in Support of Generalized MPLS," Work in
> >                 Progress, draft-ietf-isis-gmpls-extensions-16.txt.
> >
> >    [MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution
> >                 of Transport Network Survivability," IEEE
> >                 Communications Magazine, August 1999.
> >
> >    [OIF-UNI]    The Optical Internetworking Forum, "User Network
> >                 Interface (UNI) 1.0 Signaling Specification -
> >                 Implementation Agreement OIF-UNI-01.0," October 2001.
> >
> >    [OLI-REQ]    A.Fredette (Editor), "Optical Link Interface
> >                 Requirements," Work in Progress.
> >
> >    [RFC2702]    D.Awduche, et al., "Requirements for Traffic
> >                 Engineering Over MPLS," IETF RFC 2702, September 1999.
> >
> >    [RFC3386]    W.Lai, D.McDysan, et al., "Network Hierarchy and Multi-
> >                 layer Survivability," IETF RFC 3386, November 2002.
> >
> >    [RFC3410]    J.Case, R.Mundy, D.Partain, and B. Stewart,
> >                 "Introduction and Applicability Statements for
> >                 Internet-Standard Management Framework," IETF RFC 3410,
> >                 December 2002.
> >
> >    [RFC3469]    V.Sharma and F.Hellstrand (Editors), "Framework for
> >                 Multi-Protocol Label Switching (MPLS)-based Recovery,"
> >                 IETF RFC 3469, February 2003.
> >
> >    [SONET-SDH-GMPLS-FRM] G.Bernstein, E.Mannie and V.Sharma,
> >                 "Framework for GMPLS-based Control of SDH/SONET
> >                 Networks," Work in Progress.
> >
> >
> > ==== New designation (without updating references to latest versions) ====
> >
> > 18. References
> >
> > 18.1 Normative References
> >
> >    [RFC2026]    S.Bradner, "The Internet Standards Process -- Revision
> >                 3," BCP 9, IETF RFC 2026, October 1996.
> >
> >    [RFC2119]    S.Bradner, "Key words for use in RFCs to Indicate
> >                 Requirement Levels", BCP 14, IETF RFC 2119, March 1997.
> >
> >
> >    [RFC3031]    E.Rosen, A.Viswanathan, and R.Callon, "Multiprotocol
> >                 Label Switching Architecture," IETF RFC 3031, January
> >                 2001.
> >
> >    [RFC3209]    D.Awduche, et al., "RSVP-TE: Extensions to RSVP for
> >                 LSP Tunnels," IETF RFC 3209, December 2001.
> >
> >    [RFC3212]    B.Jamoussi (Editor) et al., "Constraint-Based LSP Setup
> >                 using LDP," IETF RFC 3212, January 2002.
> >
> >    [RFC3471]    L.Berger (Editor) et al., "Generalized MPLS -
> >                 Signaling Functional Description," IETF RFC 3471,
> >                 January 2003.
> >
> >    [RFC3472]    P.Ashwood-Smith and L.Berger (Editors) et al.,
> >                 "Generalized MPLS Signaling - CR-LDP Extensions," IETF
> >                 RFC 3472, January 2003.
> >
> >    [RFC3473]    L.Berger (Editor) et al., "Generalized MPLS
> >                 Signaling - RSVP-TE Extensions," IETF RFC 3473, January
> >                 2003.
> >
> > 18.2 Informative References
> >
> >    [ANSI-T1.105]   "Synchronous Optical Network (SONET): Basic
> >                    Description Including Multiplex Structure, Rates,
> >                    And Formats," ANSI T1.105, 2000.
> >
> >    [BUNDLE]        K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
> >                    in MPLS Traffic Engineering," Work in Progress,
> >                    draft-ietf-mpls-bundle-04.txt.
> >
> >    [GMPLS-FUNCT]   J.P.Lang and B.Rajagopalan (Editors) et al.,
> >                    "Generalized MPLS Recovery Functional
> >                    Specification," Work in Progress, draft-ietf-ccamp-
> >                    gmpls-recovery-functional-01.txt.
> >
> >    [GMPLS-G709]    D.Papadimitriou (Editor) et al., "GMPLS Signaling
> >                    Extensions for G.709 Optical Transport Networks
> >                    Control," Work in progress, draft-ietf-ccamp-gmpls-
> >                    g709-03.txt.
> >
> >    [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the
> >                    Overlay Model," Work in Progress, draft-ietf-ccamp-
> >                    gmpls-overlay-01.txt.
> >
> >    [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing
> >                    Extensions in Support of Generalized MPLS," Work in
> >                    Progress, draft-ietf-ccamp-gmpls-routing-05.txt.
> >
> >    [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al.,
> >                    "Generalized MPLS Extensions for SONET and SDH
> >                    Control," Work in progress, draft-ietf-ccamp-gmpls-
> >                    sonet-sdh-08.txt.
> >
> >    [HIERARCHY]     K.Kompella and Y.Rekhter, "LSP Hierarchy with
> >                    Generalized MPLS TE," Work in Progress, draft-ietf-
> >                    mpls-lsp-hierarchy-08.txt.
> >
> >    [ISIS-TE]       H.Smit and T.Li, "IS-IS extensions for Traffic
> >                    Engineering," Work in Progress, draft-ietf-isis-
> >                    traffic-04.txt.
> >
> >    [ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS
> >                    Extensions in Support of Generalized MPLS," Work in
> >                    Progress, draft-ietf-isis-gmpls-extensions-16.txt.
> >
> >    [ITUT-G.707]    ITU-T, "Network Node Interface for the Synchronous
> >                    Digital Hierarchy", Recommendation G.707, October
> >                    2000.
> >
> >    [ITUT-G.709]    ITU-T, "Interface for the Optical Transport Network
> >                    (OTN)," Recommendation G.709 version 1.0 (and
> >                    Amendment 1), February 2001 (and October 2001).
> >
> >    [ITUT-G.841]    ITU-T, "Types and Characteristics of SDH Network
> >                    Protection Architectures," Recommendation G.841,
> >                    October 1998.
> >
> >    [LMP]           J.P.Lang (Editor) et al., "Link Management Protocol
> >                    (LMP)," Work in progress, draft-ietf-ccamp-lmp-
> >                    09.txt.
> >
> >    [LMP-WDM]       A.Fredette and J.P.Lang (Editors) et al., "LMP for
> >                    WDM Optical Line Systems (LMP-WDM)," Work in
> >                    progress, draft-ietf-ccamp-lmp-wdm-02.txt.
> >
> >    [MANCHESTER]    J.Manchester, P.Bonenfant and C.Newton, "The
> >                    Evolution of Transport Network Survivability," IEEE
> >                    Communications Magazine, August 1999.
> >
> >    [OIF-UNI]       The Optical Internetworking Forum, "User Network
> >                    Interface (UNI) 1.0 Signaling Specification -
> >                    Implementation Agreement OIF-UNI-01.0," October 2001.
> >
> >    [OLI-REQ]       A.Fredette (Editor), "Optical Link Interface
> >                    Requirements," Work in Progress.
> >
> >    [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions
> >                    in Support of Generalized MPLS," Work in Progress,
> >                    draft-ietf-ccamp-ospf-gmpls-extensions-09.txt.
> >
> >    [OSPF-TE]       D.Katz, D.Yeung, and K.Kompella, "Traffic
> >                    Engineering Extensions to OSPF", Work in Progress,
> >                    draft-katz-yeung-ospf-traffic-09.txt.
> >
> >    [RFC1393]       G.Malkin, "Traceroute Using an IP Option", IETF RFC
> >                    1393, January 1993.
> >
> >    [RFC2151]       G.Kessler and S.Shepard, "A Primer On Internet and
> >                    TCP/IP Tools and Utilities", IETF RFC 2151, June
> >                    1997.
> >
> >    [RFC2385]       A.Heffernan, "Protection of BGP Sessions via the TCP
> >                    MD5 Signature Option," IETF RFC 2385, August 1998.
> >
> >    [RFC2402]       S.Kent and R.Atkinson, "IP Authentication Header,"
> >                    IETF RFC 2402, November 1998.
> >
> >    [RFC2406]       S.Kent and R. Atkinson, "IP Encapsulating Security
> >                    Payload (ESP)," IETF RFC 2406, November 1998.
> >
> >    [RFC2409]       D.Harkins and D.Carrel, "The Internet Key Exchange
> >                    (IKE)," IETF RFC 2409, November 1998.
> >
> >    [RFC2702]       D.Awduche, et al., "Requirements for Traffic
> >                    Engineering Over MPLS," IETF RFC 2702, September
> >                    1999.
> >
> >    [RFC2747]       F.Baker et al., "RSVP Cryptographic Authentication,"
> >                    IETF RFC 2747, January 2000.
> >
> >    [RFC2753]       R.Yavatkar, D.Pendarakis and R.Guerin, "A Framework
> >                    for Policy-based Admission Control," IETF RFC 2753,
> >                    January 2000.
> >
> >    [RFC2925]       K.White, "Definitions of Managed Objects for Remote
> >                    Ping, Traceroute, and Lookup Operations," IETF RFC
> >                    2925, September 2000.
> >
> >    [RFC3036]       L.Andersson, P.Doolan, N.Feldman, A.Fredette, and
> >                    B.Thomas, "LDP Specification," IETF RFC 3036, January
> >                    2001.
> >
> >    [RFC3386]       W.Lai, D.McDysan, et al., "Network Hierarchy and
> >                    Multi-layer Survivability," IETF RFC 3386, November
> >                    2002.
> >
> >    [RFC3410]       J.Case, R.Mundy, D.Partain, and B. Stewart,
> >                    "Introduction and Applicability Statements for
> >                    Internet-Standard Management Framework," IETF RFC
> >                    3410, December 2002.
> >
> >    [RFC3411]       D.Harrington, R.Presuhn and B.Wijnen, "An
> >                    Architecture for Describing Simple Network Management
> >                    Protocol (SNMP) Management Frameworks," IETF RFC
> >                    3411, December 2002.
> >
> >    [RFC3414]       U.Blumenthal and B.Wijnen, "User-based Security Model
> >                    (USM) for version 3 of the Simple Network Management
> >                    Protocol (SNMPv3)," IETF RFC 3414, December 2002.
> >
> >    [RFC3415]       B.Wijnen, R.Presuhn, and K.McCloghrie, "View-based
> >                    Access Control Model (VACM) for the Simple Network
> >                    Management Protocol (SNMP)," IETF RFC 3415, December
> >                    2002.
> >
> >    [RFC3416]       R.Presuhn (Editor), "Version 2 of the Protocol
> >                    Operations for the Simple Network Management Protocol
> >                    (SNMP)," IETF RFC 3416, December 2002.
> >
> >    [RFC3417]       R.Presuhn (Editor), "Transport Mappings for the
> >                    Simple Network Management Protocol (SNMP)," IETF RFC
> >                    3417,December 2002.
> >
> >    [RFC3469]       V.Sharma and F.Hellstrand (Editors), "Framework for
> >                    Multi-Protocol Label Switching (MPLS)-based
> >                    Recovery," IETF RFC 3469, February 2003.
> >
> >    [RFC3477]       K.Kompella and Y.Rekhter, "Signalling Unnumbered
> >                    Links in Resource ReSerVation Protocol - Traffic
> >                    Engineering (RSVP-TE)," IETF RFC 3477, January 2003.
> >
> >    [RFC3479]       A.Farrel (Editor) et al., "Fault Tolerance for the
> >                    Label Distribution Protocol (LDP)," IETF RFC 3479,
> >                    February 2003.
> >
> >    [RFC3480]       K.Kompella, Y.Rekhter and A.Kullberg, "Signalling
> >                    Unnumbered Links in CR-LDP," IETF RFC 3480, February
> >                    2003.
> >
> >    [SONET-SDH-GMPLS-FRM] G.Bernstein, E.Mannie and V.Sharma,
> >                    "Framework for GMPLS-based Control of SDH/SONET
> >                    Networks," Work in Progress.
> >
> > =========
> >
> > ----- Original Message ----- 
> > From: "RFC Editor" <[email-masked]>
> > To: "Adrian Farrel" <[email-masked]>
> > Cc: <[email-masked]>; "Bill Fenner" <[email-masked]>; "'Kireeti Kompella'"
> > <[email-masked]>; "RFC Editor" <[email-masked]>
> > Sent: Friday, October 01, 2004 12:33 AM
> > Subject: Re: draft-ietf-ccamp-gmpls-architecture-07.txt in RFC Ed Q
> >
> >
> > > Adrian,
> > >
> > > You do not need to send us a revised version of the draft.  Please
> > > send us the new references sections for the varying documents.
> > > However, please note that because we are altering the normative
> > > reference section, we need approval from the ADs as well.
> > >
> > > Please let us know if you have any further questions.
> > >
> > > Thank you.
> > >
> > > RFC Editor
> > >
> > >
> > > On Sat, Sep 25, 2004 at 08:11:24PM +0100, Adrian Farrel wrote:
> > > > Hi,
> > > >
> > > > It has been brought to my attention that
draft-ietf-ccamp-gmpls-architecture-07.txt is
> > > > blocking the progress of very many drafts because of its excessive normative
> > > > references.
> > > > It would appear that this issue was raised when the draft was reviewed by the
IESG,
> > > > but nothing was done to fix it.
> > > >
> > > > Although we (in CCAMP) are doing our utmost to progress all of the associated
drafts,
> > > > it also seems worth while to sort out the references so that it and the 15 or so
other
> > > > drafts blocked by it can move forward.
> > > >
> > > > Can I ask you how we should best do this. Should I submit a new version of the
draft
> > > > or simply send you a new references section?
> > > >
> > > > Thanks,
> > > > Adrian
> > > > (CCAMP co-chair)
> > >
> > >
>
>

Delivery-date: Fri, 01 Oct 2004 10:38:57 +0000
Date: Fri, 01 Oct 2004 12:36:32 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: ASON Opacity

hi adrian,

i agree with your analysis and response concerning the ason signaling 
requirements document,

i will make the proposed change (and resubmit) unless i hear before next 
friday

thanks,
- dimitri.
---

Adrian Farrel wrote:

> Hi,
> 
> Here is my summary of the changes proposed by Jonathan Sadler for inclusion in the CCAMP
> ASON Signaling and Routing Requirements drafts.
> 
> As you will recall, these drafts (which have been through WG last call and have had a full
> process of exchange and liaison with the ITU-T's Study Group 15) had been reviewed by the
> AD and a few comments were raised. These comments were addressed immediately before the
> San Diego IETF, but the editors just missed the publication deadline.
> 
> Normally we would have gone ahead and submitted the drafts by now and they would have gone
> through the IESG. However, Jonathan spoke up in the CCAMP meeting in San Diego to express
> his reservations about the inadequate description of how the "opacity" of a sub-network
> should be preserved. We were concerned to get the drafts right and so held back from
> re-publication.
> 
> Jonathan was kind enough to agree to review the two drafts and document his concerns in
> greater detail. Pressure of work has unfortunately meant that Jonathan has been unable to
> do more than send me a draft of his worries. Since we must move forward with these
> documents I am taking the liberty of interpreting his draft and expressing my views on
> what changes should be made. This will allow the editors of the two documents to debate
> the points, make any necessary changes, and submit the documents. There are plenty of SG15
> people on this list, so I know that any errors I make in my representation on Jonathan's
> views will be immediately jumped upon.
> 
> Since the changes suggested to the document are so very small, I shall not be calling for
> a further WG last call. This means that I expect the editors to make a call on the changes
> necessary and to inform the WG of what they have done. I do not expect a long discussion.
> 
> Thanks,
> Adrian
> 
> ====
> 
> ASON Signaling Requirements Draft
> 
> Issue:
> The draft states that it provides "signaling requirements for G.8080 distributed call and
> connection management based on GMPLS, within a GMPLS based control domain (I-NNI) and
> between GMPLS based control domains (E-NNI)." (Section 4, PP 2)  This implies that the
> requirements are consistent regardless of where the ingress and egress of a connection is,
> as long as all control domains involved in the connection use GMPLS.
> Response:
> I believe that Jonathan's inferred implication is correct and that the text as it
> currently stands is reliable. That is, the requirements are for GMPLS signaling at I-NNI
> and E-NNI reference points and that no statement is made about the location of the ingress
> or egress of calls or connections. No change to the text is needed to clarify this.
> 
> Issue:
> It should be noted that the draft does allow for different non-GMPLS Control Plane
> signaling protocols to be used in adjoining domains (Section 4, PP2), and states that
> interworking between signaling protocols is outside of the scope of the requirements
> document.  This statement eludes to the opacity of the subnetwork, but does not explicitly
> state it.
> Response:
> This is correct, but it might depend on the definition of "sub-network" and "opacity".
> Since the term "opaque" is neither defined nor used in G.805, G.8080 or G.7713 it would be
> inappropriate to introduce the term in this draft. In fact, in the context of this
> paragraph, the point seems to be well covered by exactly what is stated here. The draft is
> looking at signaling protocols (not at next hop routing, nor path computation) and must
> express how the signaling message is passed from one GMPLS-capable node to the next. This
> it does, and I don't believe any further change to the document is necessary.
> 
> Issue:
> The draft further goes on to say that for Call requests, "end-to-end signaling should be
> facilitated regardless of the administrative boundaries and protocols within the network."
> (Section 4, PP 2)  While subnetwork boundaries are instituted to realize administrative
> and signalling protocol boundaries in the network, there are other reasons to create
> subnetwork boundaries, including differences in how a subnetwork connection is realized
> within the subnetwork.
> Response:
> I understand this point, but the logic is reversed. The draft does not refer to
> subnetworks and so the reasons for their existence are not important in this context.
> Further, it should be noted that an important feature of G.8080 is that a "control
> network" can include multiple "subnetworks". Still further, I am unclear how the
> realization of Connections within a subnetwork is important to the end-to-end nature of
> Call request signaling. However, it might be appropriate (or harmless) to change the text
> to say "end-to-end signaling should be facilitated regardless of the administrative
> boundaries, protocols within the network or method of realization of connections within
> any part of the network."
> 
> Issue:
> Further to this point, Jonathan and I have discussed whether the end-to-end requirements
> as expressed in Section 4 PP2 and the "end-to-end principle" applied to Internet protocols
> are compatible with the need to establish ASON Connections. I believe, however, that my
> response to him indicated that the "end-to-end principle" dictates not that state is only
> held at end points, but that state is only held on a need-to-know basis. Thus Call state
> is only held at UNI and E-NNI reference points, while Connection state is held at UNI,
> E-NNI and I-NNI reference points. It would be incorrect to require that Call state should
> be held at I-NNI reference points (even if that state is held unprocessed in a transparent
> manner). No change to the text is required for this point.
> 
> ======
> 
> ASON Routing Requirements Draft
> 
> Jonathan points out that the draft already contains requirements that are developed from
> the autonomous nature of Routing Areas. There is a tendency, I feel, in what Jonathan says
> to tie a subnetwork too closely to the concept of a Routing Area where G.7715 clearly
> refers to "a subnetwork or a routing area" as distinct things that may be commonly
> referred to as a "node". Further, neither G.7715, nor G.7715.1 uses the term "opaque" so
> it is a little hard to conjure a precise wording for additions to this draft.
> 
> Nevertheless, Jonathan makes a couple of simple suggestions for additions to the draft as
> follows.
> 
> Issue:
> A routing area is a subnetwork with visibility to the egress links connected to the
> subnetworks ports (see G.8080 Sec 6.2)
> Response:
> This is not the definition of Routing Area that I find in section 6.2 of G.8080 (perhaps I
> have a different version?). However, the definition found in G.8080 *is* useful and should
> be included in our draft. It runs...
> "Within the context of this Recommendation a routing area exists within a single layer
> network. A routing area is defined by a set of subnetworks, the SNPP links that
> interconnect them, and the SNPPs representing the ends of the SNPP links exiting that
> routing area. A routing area may contain smaller routing areas interconnected by SNPP
> links. The limit of subdivision results in a routing area that contains two subnetworks
> and one link."
> Fortunately, this definition is included (verbatim) in Appendix 2 of the draft. So no text
> change is required.
> 
> Issue:
> The method used by a subnetwork to realize a subnetwork connection is not visible to a
> route calculation being performed in the containing area.
> Response:
> This statement seems to mix routing areas and subnetworks too freely. A routing area can
> surely see all realizations within subnetworks that comprise the routing area itself.
> However, if we are talking about hierarchical routing areas then, yes, this is precisely
> the definition of the hierarchical routing area and the draft goes into considerable
> detail about the way in which reachability information may be exchanged, but that routing
> information abstraction is used to limit the visibility into the child RAs topology and
> capabilities. I don't believe any further additions are required.
> 
> Issue:
> The subnetwork may provide an abstracted representation of the connectivity available
> through the domain to the higher level routing area.  This is done at the discretion of
> routing controller(s) within the subnetwork, and not through filtering performed by the
> higher level routing controllers.
> Response:
> There are two statements here. The first is true and is described in some detail in
> section 4.2 of the draft. The second statement again mixes subnetworks and routing areas,
> but if we re-state it fully in terms of RAs we also find text that covers this situation
> in section 4.2 of the draft. Further, we should note that G.7715.1 actually also allows
> the filtering within the parent RA...
> "In the second approach, the Level N+1 RC listens to the routing protocol exchange
> occurring in each contained Level N RA and retrieves the endpoints being announced by the
> Level N routing instance(s) and the full Level N topology.  This information may be
> summarized into one or more address prefixes and an abstracted topology in order to
> facilitate scalability."
> Thus, I think no change to the draft is required on this account either.
> 
> 
> 
> 
> 
> 
> .
>