Subject: RE: draft-ietf-ccamp-gmpls-recovery-terminology-02.txt (repeat #1)
From: "Vikram Anantha" <[email-masked]>
To: <[email-masked]>
Date: Thu, 30 Oct 2003 16:58:16 -0800

I was hoping somebody could throw some light about how Selectors and
Bridges would be modelled in GMPLS.

- Would they be considered part of a LSP or would they be a separate
entity? Or
- Maybe in addition to "Label Stacking" and "Label Switching", maybe
there is also a "Label Selecting" and "Label Bridging" operation.

Then we could rename GMPLS to GMPLSSS&B.

Cheers

Vik

-----Original Message-----
From: Vikram Anantha 
Sent: Tuesday, October 21, 2003 5:11 PM
To: [email-masked]
Subject: re: draft-ietf-ccamp-gmpls-recovery-terminology-02.txt

I was wondering if Selectors, Bridges and other types of "Adaptation
Functions" as mentioned in the above draft are considered as components
of a LSP.

Thx

Vik

 

Delivery-date: Thu, 30 Oct 2003 10:11:49 +0000
From: Nurit Sprecher <[email-masked]>
To: 'Adrian Farrel' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: RSVP Graceful Restart
Date: Thu, 30 Oct 2003 12:10:02 +0200

Hi,
I have a question on notifications when FRR is activated.
If an LSP has been established with the 'one-to-one local protection
desired' and a detour has been established at each PLR --> all hops along
the LSP are considered FRR protected. 
Is for example, a problem occurs on one of these detours and the hop becomes
to be unprotected, the consequent Resv message will indicate that the
relevant node is not protected any more and the ARHop table will be updated
with the information. However, a management station has no idea of the
event, unless it keeps polling the ARHop table, which is not a reasonable
operation. I think that an appropriate notification/trap should be sent to
the management station indicating the protection status has been changed to
trigger the management station polling the ARHop table and verifying which
node is not protected any more, or which node that has not been protected is
now protected. 
Is it possible to add such a kind of trap to the TE MIB?
Thanks in advance, Nurit.

Delivery-date: Wed, 29 Oct 2003 20:45:54 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "CCAMP" <[email-masked]>, "MPLS" <[email-masked]>, "L2PPVPN" <[email-masked]>, "L3PPVPN" <[email-masked]>, "PWE3" <[email-masked]>, <[email-masked]>
Cc: "Monique J. Morrow" <[email-masked]>, "Tom Nadeau" <[email-masked]>
Subject: Update: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue 
Date: Wed, 29 Oct 2003 12:39:42 -0800

Folks,

The deadline for this FT issue is fast approaching, and this
is for those who may have either missed the earlier announcements
or have been in "thinking about it" mode. :-)

We really appreciate the interest the issue has received, and
are excited to have already received titles and abstracts from
several contributors.

If you have been thinking about contributing, please send
us, the title and abstract for your contribution at the
earliest.

The thoughts and insights of the community are what make
the issues such as this valuable, and so far we seem to be making
very good progress on that front.

Again, thanks to those who are already contributing, and we look
forward to additional participation!

Regards,
-Vishal, Monique, Tom

PS: The submission process is automated and very easy. Pl. check
instructions below.

==================================
CALL FOR PAPERS
IEEE Communications Magazine

Feature Topic on "OAM in MPLS-Based Networks"
**********************************************

As carriers and service providers converge multiple services and
associated networks on to an MPLS-based infrastructure, OAM functionality
becomes pivotal for enabling them to provide service level agreement
(SLA) guarantees, service assurance, quality of service (QoS) assurance
and overall interworking service management.  The advent of new applications
of MPLS such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3
Virtual Private Networks (L3VPNs) also means the emergence of added OAM
requirements from operators deploying those networks. As a result, providers
today require more efficient means of monitoring network health,
performance, and robustness, and of quickly identifying and resolving
performance problems. This is leading to the emergence of improved or
novel tools and techniques, whose goal is to improve security and
billing/accounting, aid in verifying QoS commitments, and reduce
operating costs. Standards organizations such as the IETF and the
ITU have in the recent past done significant work in this area, and
this subject is also being investigated by the IEEE and the Metro
Ethernet Forum.

This feature topic issue of the IEEE Communications Magazine has
a dual focus: to highlight operator requirements and deployment
experiences with OAM in MPLS-based networks, and to present a
survey of the current engineering and research developments in
this area.

Thus, focused tutorial and survey contributions as well as
research papers are solicited on (but not limited to) the following:

* Operational consequences of inadequate OAM capabilities
* Service provider requirements for efficient OAM - current operational
  needs and future demands
* Deployment experiences with OAM over MPLS-based networks
* Overview or comparative analysis of different
  approaches/philosophies for OAM
* Standards activities
	o Emerging architectures
	o New mechanisms for OAM in development
         (e.g. IETF LSP ping, ITU-T Y.1711, virtual circuit
         connection verification (VCCV))
* Platform support for OAM
* OAM impact on edge services (such as metro Ethernet)
  using MPLS transport
* Interoperability issues, interworking with
  other technologies (e.g. ATM)
* Review of current research in the area - E.g. setting
  parameters for connectivity verification and their impact on
  LSP recovery, trade-offs between bandwidth usage by OAM traffic
  and efficiency of failure/anomaly detection, and results from testbed
  deployments or simulations

On-line CFP with submission instructions can be found at:
http://www.comsoc.org/pubs/commag/cfpcommag1004.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 the 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 November 30, 2003. Accepted papers will
also be included in Communications Interactive (CI), the online version
of Communications Magazine.

Schedule:

Manuscript Due:                November 30, 2003
Acceptance Notification:       February 28, 2004
Final Manuscript Due:          April 15, 2004
Publication Date:              October 2004

Guest Editors:

Monique J. Morrow
Cisco Systems, Inc.
Glatt-com
CH-8301 Glattzentrum
Switzerland

Email: [email-masked]

Tom Nadeau
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824, USA.

Email: [email-masked]

Vishal Sharma
Metanoia, Inc.
1600 Villa Street, Unit 352
Mountain View, CA 94041, USA.

Email: [email-masked]

About the IEEE Communications Magazine:

The IEEE Comm. Mag. is the official technical publication of
conferences such as Supercomm, and has the unique distinction of
being the most widely read IEEE journal, with its over 50,000 paid
subscribers representing key communications engineers and
technical managers in our industry. More information
on the IEEE Comm. Mag., may be found here:
www.comsoc.org/adv/pp/Adpp2003revisedweb.ppt

Delivery-date: Wed, 29 Oct 2003 08:31:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Agenda for Minneapolis
Date: Wed, 29 Oct 2003 08:30:14 -0000

All,

Below is the agenda for Minneapolis.
As you will see, we have focused on the charter milestones and existing WG drafts. It is
our responsibility as a working group to clear these off our plate before we pick up new
work.

The likelihood is that many of you will be disappointed and will not get a chance to
discuss your draft at the meeting. Sorry. My recommendation is to proactively take your
discussion to the mailing list. Ask specific questions and raise particular concerns. Use
the feedback that you get (if there is support!) to advance your draft so that it is in a
better state when the WG has the bandwidth at a future meeting.

It is also important for you to look at your draft in the light of the new CCAMP charter.
Precisely how does your draft fit in? Is there a charter item or milestone that your draft
helps to meet? If so, then please be very explicit about this within your draft - there
was a practice of putting a "Summary for the Sub-IP Area" at the start of drafts, and this
captured the reference to the charter. If you find you can't match your draft to a
specific charter item, it is unlikely to see early adoption by the WG and you will need to
raise the wider discussion of the need for your draft.

This brings me on to the subject of requirements...  Please be sure that your draft
includes a very clear requirements statement (either a reference to a requirements draft,
or specific in-line requirements). Don't assume that just because the requirements are
clear to you and your colleagues they will be clear to everyone. If the readers of your
draft don't fully grasp the requirements it is likely they will ignore your draft. It is
therefore your responsibility to convey the requirements fully.

Those of you who take editing drafts seriously might want to consider attending...
> >     Sunday, November 9, 2003
> >     ============> >     1330-1500  Editor's Training -- Conrad C
> >
> >     Training for current or aspiring IETF document
> >     editors.  Covers the roles and responsibilities
> >     of a document editor, and includes advice on
> >     producing a high-quality IETF specification.

Finally, before I stop preaching, if you would like to speed up the progress of the WG so
that it reaches your drafts sometime in the current century, I would like to invite you to
make concrete contributions to the existing WG drafts. The sooner we complete them, the
sooner we can move on.

Discussion leaders...
- please recall you are leading a discussion
- you are not presenting your draft (the audience has read it)
- highlight the remaining technical issues
- ask opinions on controversial points
- outline the next steps
- explain how you will meet any associated milestones

</homily>

Adrian and Kireeti

58th IETF Minneapolis
CCAMP WG Agenda
=======Time available 150 minutes

Agenda bashing - chairs (5 mins)

Minute takers and blue sheets - chairs (5 mins)

Old charter, new RFCs - chairs (5 mins)

New charter - chairs (5 mins)

Summary of draft statuses - chairs (5 mins)

Summary of interactions with other WGs - chairs (5 mins)

ITU-T Liaison - Wesam (10 mins)

(40 minutes used)

Charter Work
*** Please include a statement of your charter ***
*** milestones and how you will meet them.     ***

   GMPLS MIBs
     Tom (10 mins)
      - draft-ccamp-ietf-gmpls-tc-mib-01.txt
      - draft-ccamp-ietf-gmpls-lsr-mib-01.txt
      - draft-ccamp-ietf-gmpls-te-mib-01.txt

   Protection and Restoration
     Dimitri (15 mins)
      - draft-ietf-ccamp-gmpls-recovery-terminology-02.txt
      - draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
      - draft-ietf-ccamp-gmpls-recovery-functional-01.txt
      - draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt

   ASON Signaling Requirements
     Jerry (10 mins)
      - draft-ietf-ccamp-gmpls-ason-reqts-03.txt
     Lyndon (10 mins)
      - draft-ong-ccamp-3473-3474-iw-00.txt
     Jerry (5 mins)
      - draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
     Adrian (2 mins)
      - draft-iwata-mpls-crankback-07.txt

   ASON Routing Requirements
     Deborah (10 mins)
      - draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt
      - Liaison statement to ITU-T

   Tunneling Protocol
     Ron (10 mins)
      - draft-bonica-tunproto-05.txt

   Multi-Area/AS/Region
     Arthi (5 mins)
      - draft-ayyangar-inter-region-te-01.txt
     JP (5 mins)
      - draft-vasseur-inter-as-te-01.txt

(122 minutes used)

Other drafts according to time available
*** Please be quick to allow others a chance.  ***
*** If you don't have time, you should discuss ***
*** your draft on the mailing list.            ***

   Communication of Alarms
     Lou (10 mins)
      - draft-berger-ccamp-gmpls-alarm-spec-00.txt

   Generalized MPLS Signaling for Layer-2 LSPs
     Dimitri (10 mins)
      - draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt

   Component Link Recording and Resource Control for GMPLS
   Link Bundles
     Zafar (10 mins)
      - draft-zamfir-explicit-resource-control-bundle-02.txt

   Requirements for time-bounded notification of faults
     Richard (5 mins)
      - draft-rabbat-expedited-flooding-00.txt

   Potential solutions for time-bounded notification of
   faults
     Vishal (5 mins)
      - draft-rabbat-fault-notification-protocol-04.txt
      - draft-rabbat-fnp-applicability-00.txt

   Control plane architecture in GMPLS networks
     Kohei (5 mins)
      - draft-shiomoto-ccamp-cplane-architecture-00.txt

   Extra class LSP service using protecting resources in
   GMPLS networks
     Kohei (5 mins)
      - draft-pil-ccamp-extra-lsp-01.txt

   Control plane resilience
     Y. Kim (5 mins)
      - draft-kim-ccamp-cc-protection-04.txt

   Interaction between GMPLS RSVP-TE and LCAS
     Y. Kim (5 mins)
      - draft-kim-ccamp-interaction-grsvpte-lcas-00.txt

   Multi-Granularity Optical Cross-Connect
     Dae-Gun Kim (5 mins)
      - draft-kim-ccamp-gmpls-mgoxc-01.txt

   Resource Mapping for GMPLS with Heterogeneous Interfaces
     Gyu Myoung Lee (5 mins)
      - draft-choi-gmpls-resource-mapping-01.txt

   Requirements of Burst-Level Control in Optical Networks
     Jung Yul Choi (5 mins)
      - draft-choi-burst-control-01.txt

   Signaling Extension for the End-to-End restoration with SRLG
     Jung Yul Choi (5 mins)
      - draft-choi-ccamp-e2e-restoration-srlg-01.txt

Delivery-date: Wed, 29 Oct 2003 05:31:43 +0000
Date: Wed, 29 Oct 2003 14:29:53 +0900
From: Kohei Shiomoto <[email-masked]>
Organization: NTT
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-oki-ccamp-gmpls-ip-interworking-01.txt]

This is a multi-part message in MIME format.
--------------060009000305050208060306
Content-Type: multipart/alternative;
 boundary="------------040406020609060007090803"

--------------040406020609060007090803
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

Please notice that the draft on GMPLS migration has been posted. This
draft addresses the migration mechanism from MPLS to GMPLS. I believe
the topic is worth discussion at the IETF 58 ccamp meeting.
Comments and feedback are highly appreciated.
Thanks,
-- 
Kohei Shiomoto
NTT Network Innovation Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402 Fax +81 422 59 6387
-------- Original Message --------
Subject: 	I-D ACTION:draft-oki-ccamp-gmpls-ip-interworking-01.txt
Date: 	Mon, 27 Oct 2003 17:09:17 -0500
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: GMPLS and IP/MPLS Interworking Architecture
	Author(s)	: E. Oki
	Filename	: draft-oki-ccamp-gmpls-ip-interworking-01.txt
	Pages		: 10
	Date		: 2003-10-24
	
Generalized MPLS extends MPLS to support various transport technologies.
One important GMPLS target is to seamlessly integrate IP-only-capable or
IP+MPLS-capable networks (we call them IP/MPLS networks in this docu-
ment) with various transport networks such as SONET/SDH and wavelength
switched networks.  IP/MPLS networks (supporting only packet LSPs)
migration to GMPLS networks (supporting both packet and non-packet LSPs)
will coexist at some point in time. Such IP/MPLS nodes that do not sup-
port GMPLS protocols must also operate with GMPLS networks. IP/MPLS
nodes that do not support the processing non-packet LSP specifics of
GMPLS protocols must also operate with such GMPLS networks.  This
document addresses operational considerations on GMPLS and IP/MPLS
interworking, and provides examples on both routing and signaling
aspects. For the existing routing protocol, information on the data
plane in the GMPLS network is needed to be available to make appropriate
routing tables at IP routers in the IP/MPLS networks.  Selected informa-
tion on GMPLS nodes and GMPLS TE links in the GMPLS network needs to be
advertised to the IP/MPLS net- works by emulating information that can
be understood by IP routers.  These advertised nodes and links need to
appear as IP router entries and behave as conventional IP subnetworks.
>From the signaling aspects, a comparison between two methods, the tunnel
method and the stitch method, are presented.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-oki-ccamp-gmpls-ip-interworking-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-oki-ccamp-gmpls-ip-interworking-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.

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type"
 content="text/html;charset=ISO-2022-JP">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hello all,<br>
<br>
Please notice that the draft on GMPLS migration has been posted. This
draft addresses the migration mechanism from MPLS to GMPLS. I believe
the topic is worth discussion at the IETF 58 ccamp meeting. <br>
Comments and feedback are highly appreciated.<br>
Thanks,<br>
-- <br>
Kohei Shiomoto<br>
NTT Network Innovation Laboratories<br>
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan<br>
Phone +81 422 59 4402 Fax +81 422 59 6387<br>
-------- Original Message --------
<table cellpadding="0" cellspacing="0" border="0">
  <tbody>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Subject: </th>
      <td>I-D ACTION:draft-oki-ccamp-gmpls-ip-interworking-01.txt</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Date: </th>
      <td>Mon, 27 Oct 2003 17:09:17 -0500</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">From: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Reply-To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">To: </th>
      <td>IETF-Announce: ;</td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: GMPLS and IP/MPLS Interworking Architecture
	Author(s)	: E. Oki
	Filename	: draft-oki-ccamp-gmpls-ip-interworking-01.txt
	Pages		: 10
	Date		: 2003-10-24
	
Generalized MPLS extends MPLS to support various transport technologies.
One important GMPLS target is to seamlessly integrate IP-only-capable or
IP+MPLS-capable networks (we call them IP/MPLS networks in this docu-
ment) with various transport networks such as SONET/SDH and wavelength
switched networks.  IP/MPLS networks (supporting only packet LSPs)
migration to GMPLS networks (supporting both packet and non-packet LSPs)
will coexist at some point in time. Such IP/MPLS nodes that do not sup-
port GMPLS protocols must also operate with GMPLS networks. IP/MPLS
nodes that do not support the processing non-packet LSP specifics of
GMPLS protocols must also operate with such GMPLS networks.  This
document addresses operational considerations on GMPLS and IP/MPLS
interworking, and provides examples on both routing and signaling
aspects. For the existing routing protocol, information on the data
plane in the GMPLS network is needed to be available to make appropriate
routing tables at IP routers in the IP/MPLS networks.  Selected informa-
tion on GMPLS nodes and GMPLS TE links in the GMPLS network needs to be
advertised to the IP/MPLS net- works by emulating information that can
be understood by IP routers.  These advertised nodes and links need to
appear as IP router entries and behave as conventional IP subnetworks.
&gt;From the signaling aspects, a comparison between two methods, the tunnel
method and the stitch method, are presented.

A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-01.txt">http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-01.txt</a>

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-oki-ccamp-gmpls-ip-interworking-01.txt".

A list of Internet-Drafts directories can be found in
<a class="moz-txt-link-freetext" href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> 
or <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>

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

Send a message to:
	<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>.
In the body type:
	"FILE /internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-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.

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

--------------040406020609060007090803--

--------------060009000305050208060306
Content-Type: Message/External-body;
 name="draft-oki-ccamp-gmpls-ip-interworking-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-oki-ccamp-gmpls-ip-interworking-01.txt"

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

--------------060009000305050208060306--

Delivery-date: Tue, 28 Oct 2003 22:11:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "John Drake" <[email-masked]>, "Vishal Sharma \(E-mail 2\)" <[email-masked]>, "Anca Zamfir" <[email-masked]>
Cc: "Zafar Ali" <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: Component Link Recording for TE Link Bundles  (draft-zamfir-ex plicit-resource-control-bundle-01.txt has been  updated)  
Date: Tue, 28 Oct 2003 22:08:09 -0000

This is a multi-part message in MIME format.

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

Looks good.
Please look at the crankback draft (iwata-mpls-crankback) to see if this already meets your needs for reporting component links on PathErr.

Thanks,
Adrian
  ----- Original Message ----- 
  From: Anca Zamfir 
  To: [email-masked] ; John Drake ; Adrian Farrel ; Vishal Sharma (E-mail 2) 
  Cc: Zafar Ali ; [email-masked] ; 'Kireeti Kompella' 
  Sent: Tuesday, October 28, 2003 8:30 PM
  Subject: RE: Component Link Recording for TE Link Bundles (draft-zamfir-ex plicit-resource-control-bundle-01.txt has been updated) 

  Hi,

  Based on our initial thoughts and the feedback received from you so far, I am summarizing below the list of requirements that should be made clear in this proposal and that will be included in the next version.

  TE Link bundling is a mechanism proposed in draft-ietf-mpls-bundle-04.txt with the purpose of reducing the amount of TE specific routing information within an IGP-TE domain. With this mechanism, a number of physical and/ or logical links are presented as a single TE-link to all participant nodes and typically the decision and knowledge on which resources (component links and labels) are used for a given LSP is left as a local decision.

  However, there are cases when more information or control over used resources may be needed for a non-local node. The following cases require the component link information to be propagated to a non-local/ head node.
  - As in the case of Labels, a network operator wishes to retrieve from a head node information about the resources taken by an LSP and use this for diagnostics or further network planning. One way to achieve this is to perform component link route recording as in our proposal.
  - Also, a network operator desires to enforce a given resource allocation for a segment of an LSP or set of LSPs that span a bundled link. This 
  can be done by using the ERO proposal part of the draft.

  Items that were brought up that are not covered by this proposal are:
  - Component Link failure notifications or PathErr -- feedback from John: if some the requirement for this is clarified, a new ErrorCode may be acceptable.
  - Protection mechanisms within a bundle -- feedback from John: cover this in span protection work item.

  Other input we will incorporate in the next version (coming from Adrian):
  - rewrite the Introducation section to make it more readable and provide clear scope of the problem the proposal is trying to solve.
  - correct the 'Sub-IP Id Summary' to read "This draft is targeted at CCAMP WG....."

  Please let us know if you have any further comments or if anything was missed.

  Thanks,
  the authors.

  At 01:38 PM 10/23/2003 -0700, John Drake wrote:

    "urn:schemas-microsoft-com:office:office"> 
    Private note 
      -----Original Message----- 
      From: Vishal Sharma [mailto:[email-masked]] 
      Sent: Wednesday, October 22, 2003 3:28 PM 
      To: zafar ali; [email-masked] 
      Cc: [email-masked]; [email-masked]; 'Adrian Farrel'; 'Kireeti Kompella' 
      Subject: RE: Component Link Recording for TE Link Bundles (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated) 
      Hi Zafar, 
       
      Thanks for your note. Although I've not had an opportunity yet to look at the most 
      recent version of the document, I have read through the previous version, and think 
      the idea of recording component link information in the RRO is useful in several 
      contexts: 
       
      i) Disseminating the component link information to the edge nodes (and provider 
      NMSs) can be very useful for restoration. E.g. when a failure that affects only 
      a small subset of LSPs occurs (as opposed to a fiber cut or link failure that 
      affects all LSPs in the bundle), it would be valuable to send the component 
      link info. in the Notify (or equivalent) message and have the end node(s) recognize it 
      and take corrective action. 

      JD:  The whole point of bundled links is to hide infomation for scalability.  The end nodes 
      would not know what to do with component link information if they were to get it.  In the 
      absence of bundled links, an ingress node can exclude a failed node or link from its CSPF 
      using the information contained in Path Error or Notify in the interval before it receives the 
      LSA describing the failed node or link.  In the presence bundled links, a new error code 
      indicating 'component link failure' could be added to Path Error or Notify.  This would 
      allow an ingress node to NOT exclude the bundled link with the failed component link 
      in the interval before it receives the LSA describing the bundled link's reduced bandwidth. 
      Also, the nodes that experienced the component link failure will know exactly what is 
      going on and will be able to communicate directly with the NMS.  Putting component 
      link information in Path Error or Notify does not change this in any way. 

      ii) By extension, it would be useful for a provider to know that a partial failure 
      of the bundle has occurred, and to be able to identify which component has failed. 
      This could be useful in on-line/off-line path selection and CSPF. 

      JD:  See above.  Component link information is expressed in the link state database 
      as a given bundled link having more or less available bandwidth.  

      iii) I also think that the semantics defined to identify the component link can be 
      useful in an of themselves, as they  may be usable by other mechanisms/methods that 
      rely on disseminating component link failure info. to various nodes in the network. 

      JD:  We don't want nodes in the network to know about component links!  Note that I 
      am in favor of adding component link information into the ERO to handle the case of 
      a neurotic network operator that wants complete control of their network - this is why 
      explicit label was added and component link information completes this. 

      BTW, I'm not sure if you've seen Nic Neate's post on MPLS and CCAMP yet, but 
      it seems some of what you've proposed is related to or may partially address 
      what he's proposing (but I need to think a bit more carefully about that). 
       
      -Vishal 
      -----Original Message----- 
      From: [email-masked] [mailto:[email-masked]]On Behalf Of zafar ali 
      Sent: Monday, October 20, 2003 9:48 AM 
      To: [email-masked] 
      Cc: 'zafar ali'; [email-masked]; [email-masked]; 'Adrian Farrel'; 'Kireeti Kompella' 
      Subject: Component Link Recording for TE Link Bundles (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated) 
      Dear Ccamp'ers: 

      This is a follow-up on our AI from last ccamp WG meeting on the above-mentioned ID. We don't think the crux of this ID came across right, during the presentation and the follow-up questions and answers. As Zafar mentioned during the ccamp wg meeting discussions, this ID mainly addresses problem that exists in the RRO. Specifically, when TE links are bundled, identification of label resource in RRO is not enough for the administrative purpose. Network service providers would like to know the component link that is being used by a given the LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along the TE link identifier and Label. 
       
      In current specification, we cannot record component link selected by an intermediate node in the RRO, which posses an administrative deficiency. The ID mainly addresses this shortage by defining the extensions to RSVP-TE to specify component link identifiers for resource recording in a network containing TE link (a.k.a. link bundles). 
       
      This is true that the ID also defines the ERO counter-part. It seems from our last meeting discussions that one shall try to maintain as symmetry between the ERO and RRO definitions as much as possible. Nonetheless, the ERO definition also addresses a current deficiency in the standard definition. Specifically, explicit resource control for bi-directional LSP when forward and reverse legs of the LSP are to follow different component links within a TE bundle is not possible using current specification. But for the time being, this is not the main motivation behind this ID. 
      We think that during the CCAMP WG meeting, somehow everyone was commenting on the practically of the ERO counterpart. But as Zafar also mentioned in the question answer session that it is unfair to discuss merit and fate of this ID based on the ERO extensions contained herein. 
      In the light of the above, we would like the WG to discuss the ID based on its merit and applicably to resource recording in a network containing bundled TE link. Clearly, the proposed RRO extensions are a useful tool for administrative purpose. 
       
      N.B. We have also updated the ID, based on comments during last Ccamp WG meeting; An updated copy will be available at IETF Web site in a couple of days. In the mean time, a mirror version of the ID can be viewed at, http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt. 
       
      Comments on usefulness on Component Link Recording for TE Link Bundles will be very much appreciated. 

      Thanks 
       
      Regards... Anca, Zafar and Dimitri. 
       
      ===================================================================== 
      Zafar Ali, Ph. D.       100 South Main St. #200, 
      Technical Leader,       Ann Arbor, MI 48104, USA. 
      Cisco Systems.       (734) 276-2459. 
      ===================================================================== 

------=_NextPart_000_00C4_01C39D9F.F8BCA7A0
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=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1170" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Looks good.</FONT></DIV>
<DIV><FONT face=Arial size=2>Please look at the crankback draft 
(iwata-mpls-crankback) to see if this already meets your needs for reporting 
component links on PathErr.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Thanks,</FONT></DIV>
<DIV><FONT face=Arial size=2>Adrian</FONT></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=[email-masked] href="mailto:[email-masked]">Anca Zamfir</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">John Drake</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">Adrian Farrel</A> 
  ; <A title=[email-masked] href="mailto:[email-masked]">Vishal Sharma 
  (E-mail 2)</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">Zafar Ali</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> 
  ; <A title=[email-masked] href="mailto:[email-masked]">'Kireeti 
  Kompella'</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, October 28, 2003 8:30 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: Component Link Recording for 
  TE Link Bundles (draft-zamfir-ex plicit-resource-control-bundle-01.txt has 
  been updated) </DIV>
  <DIV><BR></DIV>Hi,<BR><BR>Based on our initial thoughts and the feedback 
  received from you so far, I am summarizing below the list of requirements that 
  should be made clear in this proposal and that will be included in the next 
  version.<BR><BR>TE Link bundling is a mechanism proposed in 
  draft-ietf-mpls-bundle-04.txt with the purpose of reducing the amount of TE 
  specific routing information within an IGP-TE domain. With this mechanism, a 
  number of physical and/ or logical links are presented as a single TE-link to 
  all participant nodes and typically the decision and knowledge on which 
  resources (component links and labels) are used for a given LSP is left as a 
  local decision.<BR><BR>However, there are cases when more information or 
  control over used resources may be needed for a non-local node. The following 
  cases require the component link information to be propagated to a non-local/ 
  head node.<BR>- As in the case of Labels, a network operator wishes to 
  retrieve from a head node information about the resources taken by an LSP and 
  use this for diagnostics or further network planning. One way to achieve this 
  is to perform component link route recording as in our proposal.<BR>- Also, a 
  network operator desires to enforce a given resource allocation for a segment 
  of an LSP or set of LSPs that span a bundled link. This <BR>can be done by 
  using the ERO proposal part of the draft.<BR><BR>Items that were brought up 
  that are not covered by this proposal are:<BR>- Component Link failure 
  notifications or PathErr -- feedback from John: if some the requirement for 
  this is clarified, a new ErrorCode may be acceptable.<BR>- Protection 
  mechanisms within a bundle -- feedback from John: cover this in span 
  protection work item.<BR><BR>Other input we will incorporate in the next 
  version (coming from Adrian):<BR>- rewrite the Introducation section to make 
  it more readable and provide clear scope of the problem the proposal is trying 
  to solve.<BR>- correct the 'Sub-IP Id Summary' to read "This draft is targeted 
  at CCAMP WG....."<BR><BR>Please let us know if you have any further comments 
  or if anything was missed.<BR><BR>Thanks,<BR>the authors.<BR><BR>At 01:38 PM 
  10/23/2003 -0700, John Drake wrote:<BR>
  <BLOCKQUOTE cite="" 
    type="cite">"urn:schemas-microsoft-com:office:office"&gt; <BR><FONT 
    face=arial color=#0000ff size=2>Private note</FONT> 
    <DL><FONT face=tahoma size=2>
      <DD>-----Original Message----- 
      <DD>From: Vishal Sharma [<A href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] 
      <DD>Sent: Wednesday, October 22, 2003 3:28 PM 
      <DD>To: zafar ali; [email-masked] 
      <DD>Cc: [email-masked]; [email-masked]; 'Adrian 
      Farrel'; 'Kireeti Kompella' 
      <DD>Subject: RE: Component Link Recording for TE Link Bundles 
      (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated) 
      </FONT><FONT face=arial color=#0000ff size=2>
      <DD>Hi Zafar,</FONT> 
      <DD><FONT face=arial color=#0000ff size=2> 
      <DD>Thanks for your note. Although I've not had an opportunity yet to look 
      at the most 
      <DD>recent version of the document, I have read through the previous 
      version, and think 
      <DD>the idea of recording component link information in the RRO is useful 
      in several 
      <DD>contexts:</FONT> 
      <DD><FONT face=arial color=#0000ff size=2> 
      <DD>i) Disseminating the component link information to the edge nodes (and 
      provider 
      <DD>NMSs) can be very useful for restoration. E.g. when a failure that 
      affects only 
      <DD>a small subset of LSPs occurs (as opposed to a fiber cut or link 
      failure that 
      <DD>affects all LSPs in the bundle), it would be valuable to send the 
      component 
      <DD>link info. in the Notify (or equivalent) message and have the end 
      node(s) recognize it 
      <DD>and take corrective action. </FONT>
      <DD> 
      <DD><FONT face=arial color=#0000ff size=2> 
      <DD>JD:&nbsp; The whole point of bundled links is to hide infomation for 
      scalability.&nbsp; The end nodes 
      <DD>would not know what to do with component link information if they were 
      to get it.&nbsp; In the 
      <DD>absence of bundled links, an ingress node can exclude a failed node or 
      link from its CSPF 
      <DD>using the information contained in Path Error or Notify in the 
      interval before it receives the 
      <DD>LSA describing the failed node or link.&nbsp; In the presence bundled 
      links, a new error code 
      <DD>indicating 'component link failure' could be added to Path Error or 
      Notify.&nbsp; This would 
      <DD>allow an ingress node to NOT exclude the bundled link with the failed 
      component link 
      <DD>in the interval before it receives the LSA describing the bundled 
      link's reduced bandwidth. 
      <DD>Also, the nodes that experienced the component link failure will know 
      exactly what is 
      <DD>going on and will be able to communicate directly with the NMS.&nbsp; 
      Putting component 
      <DD>link information in Path Error or Notify does not change this in any 
      way. </FONT>
      <DD> 
      <DD><FONT face=arial color=#0000ff size=2> 
      <DD>ii) By extension, it would be useful for a provider to know that a 
      partial failure 
      <DD>of the bundle has occurred, and to be able to identify which component 
      has failed. 
      <DD>This could be useful in on-line/off-line path selection and CSPF. 
      </FONT>
      <DD> 
      <DD><FONT face=arial color=#0000ff size=2> 
      <DD>JD:&nbsp; See above.&nbsp; Component link information is expressed in 
      the link state database 
      <DD>as a given bundled link having more or less available bandwidth.&nbsp; 
      </FONT>
      <DD> 
      <DD><FONT face=arial color=#0000ff size=2> 
      <DD>iii) I also think that the semantics defined to identify the component 
      link can be 
      <DD>useful in an of themselves, as they&nbsp; may be usable by other 
      mechanisms/methods that 
      <DD>rely on disseminating component link failure info. to various nodes in 
      the network. </FONT>
      <DD> 
      <DD><FONT face=arial color=#0000ff size=2> 
      <DD>JD:&nbsp; We don't want nodes in the network to know about component 
      links!&nbsp; Note that I 
      <DD>am in favor of adding component link information into the ERO to 
      handle the case of 
      <DD>a neurotic network operator that wants complete control of their 
      network - this is why 
      <DD>explicit label was added and component link information completes 
      this.</FONT> 
      <DD> 
      <DD><FONT face=arial color=#0000ff size=2> 
      <DD>BTW, I'm not sure if you've seen Nic Neate's post on MPLS and CCAMP 
      yet, but 
      <DD>it seems some of what you've proposed is related to or may partially 
      address 
      <DD>what he's proposing (but I need to think a bit more carefully about 
      that).</FONT> 
      <DD><FONT face=arial color=#0000ff size=2> 
      <DD>-Vishal</FONT><FONT face=tahoma size=2> 
      <DD>-----Original Message----- 
      <DD>From: [email-masked] [<A 
      href="mailto:[email-masked]%5DOn" 
      eudora="autourl">mailto:[email-masked]]On</A> Behalf Of zafar 
      ali 
      <DD>Sent: Monday, October 20, 2003 9:48 AM 
      <DD>To: [email-masked] 
      <DD>Cc: 'zafar ali'; [email-masked]; [email-masked]; 
      'Adrian Farrel'; 'Kireeti Kompella' 
      <DD>Subject: Component Link Recording for TE Link Bundles 
      (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated) 
      </FONT><FONT face=arial size=2>
      <DD>Dear Ccamp'ers:</FONT> 
      <DD><BR><BR><FONT face=arial size=2>&nbsp;
      <DD>This is a follow-up on our AI from last ccamp WG meeting on the 
      above-mentioned ID. We don't think the crux of this ID came across right, 
      during the presentation and the follow-up questions and answers. As Zafar 
      mentioned during the ccamp wg meeting discussions, this ID mainly 
      addresses problem that exists in the RRO. Specifically, when TE links are 
      bundled, identification of label resource in RRO is not enough for the 
      administrative purpose. Network service providers would like to know the 
      component link that is being used by a given the LSP. In other words, when 
      link bundling is used, resource recording requires mechanisms to specify 
      the component link identifier, along the TE link identifier and Label. 
      <DD> 
      <DD>In current specification, we cannot record component link selected by 
      an intermediate node in the RRO, which posses an administrative 
      deficiency. The ID mainly addresses this shortage by defining the 
      extensions to RSVP-TE to specify component link identifiers for resource 
      recording in a network containing TE link (a.k.a. link bundles). 
      <DD> 
      <DD>This is true that the ID also defines the ERO counter-part. It seems 
      from our last meeting discussions that one shall try to maintain as 
      symmetry between the ERO and RRO definitions as much as possible. 
      Nonetheless, the ERO definition also addresses a current deficiency in the 
      standard definition. Specifically, explicit resource control for 
      bi-directional LSP when forward and reverse legs of the LSP are to follow 
      different component links within a TE bundle is not possible using current 
      specification. But for the time being, this is not the main motivation 
      behind this ID. 
      <DD>We think that during the CCAMP WG meeting, somehow everyone was 
      commenting on the practically of the ERO counterpart. But as Zafar also 
      mentioned in the question answer session that it is unfair to discuss 
      merit and fate of this ID based on the ERO extensions contained herein. 
      <DD>In the light of the above, we would like the WG to discuss the ID 
      based on its merit and applicably to resource recording in a network 
      containing bundled TE link. Clearly, the proposed RRO extensions are a 
      useful tool for administrative purpose. 
      <DD> 
      <DD>N.B. We have also updated the ID, based on comments during last Ccamp 
      WG meeting; An updated copy will be available at IETF Web site in a couple 
      of days. In the mean time, a mirror version of the ID can be viewed at, <A 
      href="http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt">http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt</A>. 

      <DD> 
      <DD>Comments on usefulness on Component Link Recording for TE Link Bundles 
      will be very much appreciated. </FONT>
      <DD><BR><BR><FONT face=arial size=2>&nbsp;
      <DD>Thanks 
      <DD> 
      <DD>Regards... Anca, Zafar and Dimitri.</FONT><FONT face=arial 
      color=#000080 size=2> </FONT>
      <DD><FONT face=arial size=2> 
      <DD>===================================================================== 
      <DD>Zafar Ali, Ph. D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100 South Main 
      St. #200, 
      <DD>Technical Leader,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ann Arbor, MI 
      48104, USA. 
      <DD>Cisco Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (734) 276-2459. 
      <DD>=====================================================================</FONT> 
      </DD></DL></BLOCKQUOTE><BR></BLOCKQUOTE><FONT 
face="Courier New, Courier"></FONT></BODY></HTML>

------=_NextPart_000_00C4_01C39D9F.F8BCA7A0--

Delivery-date: Tue, 28 Oct 2003 20:32:33 +0000
Date: Tue, 28 Oct 2003 15:30:55 -0500
To: <[email-masked]>, John Drake <[email-masked]>, Adrian Farrel <[email-masked]>, "Vishal Sharma (E-mail 2)" <[email-masked]>
From: Anca Zamfir <[email-masked]>
Subject: RE: Component Link Recording for TE Link Bundles (draft-zamfir-ex plicit-resource-control-bundle-01.txt has been updated)  
Cc: Zafar Ali <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>

<html>
Hi,<br>
<br>
Based on our initial thoughts and the feedback received from you so far,
I am summarizing below the list of requirements that should be made clear
in this proposal and that will be included in the next version.<br>
<br>
TE Link bundling is a mechanism proposed in draft-ietf-mpls-bundle-04.txt
with the purpose of reducing the amount of TE specific routing
information within an IGP-TE domain. With this mechanism, a number of
physical and/ or logical links are presented as a single TE-link to all
participant nodes and typically the decision and knowledge on which
resources (component links and labels) are used for a given LSP is left
as a local decision.<br>
<br>
However, there are cases when more information or control over used
resources may be needed for a non-local node. The following cases require
the component link information to be propagated to a non-local/ head
node.<br>
- As in the case of Labels, a network operator wishes to retrieve from a
head node information about the resources taken by an LSP and use this
for diagnostics or further network planning. One way to achieve this is
to perform component link route recording as in our proposal.<br>
- Also, a network operator desires to enforce a given resource allocation
for a segment of an LSP or set of LSPs that span a bundled link. This
<br>
can be done by using the ERO proposal part of the draft.<br>
<br>
Items that were brought up that are not covered by this proposal
are:<br>
- Component Link failure notifications or PathErr -- feedback from John:
if some the requirement for this is clarified, a new ErrorCode may be
acceptable.<br>
- Protection mechanisms within a bundle -- feedback from John: cover this
in span protection work item.<br>
<br>
Other input we will incorporate in the next version (coming from
Adrian):<br>
- rewrite the Introducation section to make it more readable and provide
clear scope of the problem the proposal is trying to solve.<br>
- correct the 'Sub-IP Id Summary' to read &quot;This draft is targeted at
CCAMP WG.....&quot;<br>
<br>
Please let us know if you have any further comments or if anything was
missed.<br>
<br>
Thanks,<br>
the authors.<br>
<br>
At 01:38 PM 10/23/2003 -0700, John Drake wrote:<br>
<blockquote type=cite cite>&quot;urn:schemas-microsoft-com:office:office&quot;&gt;
<br>
<font face="arial" size=2 color="#0000FF">Private note</font> 
<dl><font face="tahoma" size=2>
<dd>-----Original Message----- 
<dd>From: Vishal Sharma
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>] 
<dd>Sent: Wednesday, October 22, 2003 3:28 PM 
<dd>To: zafar ali; [email-masked] 
<dd>Cc: [email-masked]; [email-masked]; 'Adrian
Farrel'; 'Kireeti Kompella' 
<dd>Subject: RE: Component Link Recording for TE Link Bundles
(draft-zamfir-explicit-resource-control-bundle-01.txt has been updated)
</font><font face="arial" size=2 color="#0000FF">
<dd>Hi Zafar,</font> 
<dd>&nbsp;<font face="arial" size=2 color="#0000FF"> 
<dd>Thanks for your note. Although I've not had an opportunity yet to
look at the most 
<dd>recent version of the document, I have read through the previous
version, and think 
<dd>the idea of recording component link information in the RRO is useful
in several 
<dd>contexts:</font> 
<dd>&nbsp;<font face="arial" size=2 color="#0000FF"> 
<dd>i) Disseminating the component link information to the edge nodes
(and provider 
<dd>NMSs) can be very useful for restoration. E.g. when a failure that
affects only 
<dd>a small subset of LSPs occurs (as opposed to a fiber cut or link
failure that 
<dd>affects all LSPs in the bundle), it would be valuable to send the
component 
<dd>link info. in the Notify (or equivalent) message and have the end
node(s) recognize it 
<dd>and take corrective action. </font>
<dd>&nbsp; 
<dd>&nbsp;<font face="arial" size=2 color="#0000FF"> 
<dd>JD:&nbsp; The whole point of bundled links is to hide infomation for
scalability.&nbsp; The end nodes 
<dd>would not know what to do with component link information if they
were to get it.&nbsp; In the 
<dd>absence of bundled links, an ingress node can exclude a failed node
or link from its CSPF 
<dd>using the information contained in Path Error or Notify in the
interval before it receives the 
<dd>LSA describing the failed node or link.&nbsp; In the presence bundled
links, a new error code 
<dd>indicating 'component link failure' could be added to Path Error or
Notify.&nbsp; This would 
<dd>allow an ingress node to NOT exclude the bundled link with the failed
component link 
<dd>in the interval before it receives the LSA describing the bundled
link's reduced bandwidth. 
<dd>Also, the nodes that experienced the component link failure will know
exactly what is 
<dd>going on and will be able to communicate directly with the NMS.&nbsp;
Putting component 
<dd>link information in Path Error or Notify does not change this in any
way. </font>
<dd>&nbsp; 
<dd>&nbsp;<font face="arial" size=2 color="#0000FF"> 
<dd>ii) By extension, it would be useful for a provider to know that a
partial failure 
<dd>of the bundle has occurred, and to be able to identify which
component has failed. 
<dd>This could be useful in on-line/off-line path selection and CSPF.
</font>
<dd>&nbsp; 
<dd>&nbsp;<font face="arial" size=2 color="#0000FF"> 
<dd>JD:&nbsp; See above.&nbsp; Component link information is expressed in
the link state database 
<dd>as a given bundled link having more or less available
bandwidth.&nbsp; </font>
<dd>&nbsp; 
<dd>&nbsp;<font face="arial" size=2 color="#0000FF"> 
<dd>iii) I also think that the semantics defined to identify the
component link can be 
<dd>useful in an of themselves, as they&nbsp; may be usable by other
mechanisms/methods that 
<dd>rely on disseminating component link failure info. to various nodes
in the network. </font>
<dd>&nbsp; 
<dd>&nbsp;<font face="arial" size=2 color="#0000FF"> 
<dd>JD:&nbsp; We don't want nodes in the network to know about component
links!&nbsp; Note that I 
<dd>am in favor of adding component link information into the ERO to
handle the case of 
<dd>a neurotic network operator that wants complete control of their
network - this is why 
<dd>explicit label was added and component link information completes
this.</font> 
<dd>&nbsp; 
<dd>&nbsp;<font face="arial" size=2 color="#0000FF"> 
<dd>BTW, I'm not sure if you've seen Nic Neate's post on MPLS and CCAMP
yet, but 
<dd>it seems some of what you've proposed is related to or may partially
address 
<dd>what he's proposing (but I need to think a bit more carefully about
that).</font> 
<dd>&nbsp;<font face="arial" size=2 color="#0000FF"> 
<dd>-Vishal</font><font face="tahoma" size=2> 
<dd>-----Original Message----- 
<dd>From: [email-masked]
[<a href="mailto:[email-masked]%5DOn" eudora="autourl">mailto:[email-masked]]On</a>
Behalf Of zafar ali 
<dd>Sent: Monday, October 20, 2003 9:48 AM 
<dd>To: [email-masked] 
<dd>Cc: 'zafar ali'; [email-masked]; [email-masked];
'Adrian Farrel'; 'Kireeti Kompella' 
<dd>Subject: Component Link Recording for TE Link Bundles
(draft-zamfir-explicit-resource-control-bundle-01.txt has been updated)
</font><font face="arial" size=2>
<dd>Dear Ccamp'ers:</font> 
<dd>&nbsp;<br>
<br>
<font face="arial" size=2>
<dd>This is a follow-up on our AI from last ccamp WG meeting on the
above-mentioned ID. We don't think the crux of this ID came across right,
during the presentation and the follow-up questions and answers. As Zafar
mentioned during the ccamp wg meeting discussions, this ID mainly
addresses problem that exists in the RRO. Specifically, when TE links are
bundled, identification of label resource in RRO is not enough for the
administrative purpose. Network service providers would like to know the
component link that is being used by a given the LSP. In other words,
when link bundling is used, resource recording requires mechanisms to
specify the component link identifier, along the TE link identifier and
Label. 
<dd>&nbsp; 
<dd>In current specification, we cannot record component link selected by
an intermediate node in the RRO, which posses an administrative
deficiency. The ID mainly addresses this shortage by defining the
extensions to RSVP-TE to specify component link identifiers for resource
recording in a network containing TE link (a.k.a. link bundles). 
<dd>&nbsp; 
<dd>This is true that the ID also defines the ERO counter-part. It seems
from our last meeting discussions that one shall try to maintain as
symmetry between the ERO and RRO definitions as much as possible.
Nonetheless, the ERO definition also addresses a current deficiency in
the standard definition. Specifically, explicit resource control for
bi-directional LSP when forward and reverse legs of the LSP are to follow
different component links within a TE bundle is not possible using
current specification. But for the time being, this is not the main
motivation behind this ID. 
<dd>We think that during the CCAMP WG meeting, somehow everyone was
commenting on the practically of the ERO counterpart. But as Zafar also
mentioned in the question answer session that it is unfair to discuss
merit and fate of this ID based on the ERO extensions contained herein. 
<dd>In the light of the above, we would like the WG to discuss the ID
based on its merit and applicably to resource recording in a network
containing bundled TE link. Clearly, the proposed RRO extensions are a
useful tool for administrative purpose. 
<dd>&nbsp; 
<dd>N.B. We have also updated the ID, based on comments during last Ccamp
WG meeting; An updated copy will be available at IETF Web site in a
couple of days. In the mean time, a mirror version of the ID can be
viewed at,
<a href="http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt">http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt</a>. 
<dd>&nbsp; 
<dd>Comments on usefulness on Component Link Recording for TE Link
Bundles will be very much appreciated. </font>
<dd>&nbsp;<br>
<br>
<font face="arial" size=2>
<dd>Thanks 
<dd>&nbsp; 
<dd>Regards... Anca, Zafar and
Dimitri.</font><font face="arial" size=2 color="#000080"> </font>
<dd>&nbsp;<font face="arial" size=2> 
<dd>=================================== 
<dd>Zafar Ali, Ph. D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100 South Main
St. #200, 
<dd>Technical Leader,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ann Arbor, MI
48104, USA. 
<dd>Cisco Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (734) 276-2459. 
<dd>===================================</font> 
</dl></blockquote><br>

<font face="Courier New, Courier"></font></html>

Delivery-date: Tue, 28 Oct 2003 18:52:52 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Richard Rabbat" <[email-masked]>, <[email-masked]>
Cc: "'zafar ali'" <[email-masked]>
Subject: RE: Updates on drafts on Protection and Restoration for optical transport networks
Date: Tue, 28 Oct 2003 10:49:01 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0002_01C39D41.19539910
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Folks,

Just to add to this...

i) The expedited flooding draft provides a fairly detailed comparison of
signaling and flooding for
time-constrained notification.
In fact, it provides several detailed network examples to explain the
requirements that sharing imposes,
and then discusses some worst-case scenarios for both flooding and
signaling.
We would be greatly interested in feedback on the discussion therein.

It is also worth emphasizing that the draft does not propose any specific
way of
implementing flooding, and allows different proposals to achieve it.

ii) The FNP draft has now been restructured to separate the description of
fault timing in
optical transport networks from the details of the actual protocol. This
makes it easier
to see exactly where in the recovery process the protocol comes into play,
and clearly
see how the protocol operates.

Note that FNP is implementation-agnostic, so it does not mandate that
flooding be realized
by any particular protocol. Instead, it merely provides an abstract
description of the
elements needed for its operation, and allows for different realizations of
FNP.

iii) Finally, the applicability draft is designed to provide a clear idea of
how FNP applies to optical
transport networks. So, it talks of the nodes, network, and fault models for
which FNP
currently works, and also discusses impact on network operation, and on
stability.
We look forward to more feedback on the applicability draft.

Together the above drafts answer several questions raised by Roberto, Alex,
Neil, Zafar, Kireeti,
Jonathan (Sadler & Lang :-)), Adrian, etc. on various aspects of the scheme
and its operation,
and allow for a new round of discussions.

-Vishal
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of Richard Rabbat
  Sent: Monday, October 27, 2003 9:24 PM
  To: [email-masked]
  Cc: [email-masked]; 'zafar ali'; 'Richard Rabbat'
  Subject: Updates on drafts on Protection and Restoration for optical
transport networks

  Hi CCAMP'ers,

  Following the interest that was developed on our draft proposals and the
number of questions and requests for clarifications, we have written up a
couple of drafts to answer these and updated our main draft.

  We first wrote a draft on why we would need expedited flooding for fault
notification.  This draft highlights how expedited flooding notification
could be used to deliver time-bounded notification for optical transport
networks that implement shared recovery.  It's available at:

  http://www.ietf.org/internet-drafts/draft-rabbat-expedited-flooding-00.txt

  We also wrote a draft to discuss the applicability of the fault
notification protocol FNP. It's available at:

  http://www.ietf.org/internet-drafts/draft-rabbat-fnp-applicability-00.txt

  This draft basically describes the faults and network model context where
we use FNP.

  We finally updated the draft on the Fault Notification Protocol

http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol
-04.txt

  This update is a reorganization to make it more readable and focus on the
proposed protocol specifically.

  Announcements on CCAMP should follow shortly. We'd like to ask people to
read these drafts and send us comments.

  I hope these drafts address the numerous discussions that we have had so
that we can move the work forward on the agenda of the working group.

  Thanks a lot for everybody's emails and time spent to help advance this
work.

  Richard.

------=_NextPart_000_0002_01C39D41.19539910
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=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 5.50.4807.2300" name=GENERATOR>
<STYLE>@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: \@MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2>Folks,</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>Just 
to add to this...</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>i) The 
expedited flooding draft provides a fairly detailed comparison of signaling and 
flooding for</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2>time-constrained notification. </FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003></SPAN><SPAN class=866282718-28102003><FONT 
face=Arial color=#0000ff size=2>In fact, it provides several detailed network 
examples to explain the requirements that sharing imposes,</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>and 
then discusses some worst-case scenarios for both flooding and 
signaling.</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>We 
would be greatly interested in feedback on the discussion 
therein.</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>It is 
also worth emphasizing that the draft does not propose any specific way of 
</FONT></SPAN></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=866282718-28102003>implementing </SPAN><SPAN 
class=866282718-28102003>flooding, and allows different proposals to achieve 
it.</SPAN></FONT></FONT></FONT></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>ii) 
The FNP draft has now been restructured to separate the description of fault 
timing in </FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2>optical transport networks from the details of the actual protocol. This 
makes it easier</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>to see 
exactly where in the recovery process the protocol comes into play, and 
clearly</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>see 
how the protocol operates.</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>Note 
that FNP is implementation-agnostic, so it does not mandate that flooding be 
realized</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>by any 
particular protocol. Instead, it merely provides an abstract description of 
the</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2>elements needed for its operation, and allows for different realizations 
of FNP.</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>iii) 
Finally, the applicability draft is designed to provide a clear idea of how FNP 
applies to optical</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2>transport networks. So, it talks of the nodes, network, and fault models 
for which FNP </FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2>currently works, and also discusses impact on network operation, 
and&nbsp;on stability.</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>We 
look forward to more feedback on the applicability draft.</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2>Together the above drafts answer several questions raised by Roberto, 
Alex, Neil, Zafar, Kireeti, </FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2>Jonathan (Sadler &amp; Lang :-)), </FONT></SPAN><SPAN 
class=866282718-28102003><FONT face=Arial color=#0000ff size=2>Adrian, etc. on 
various aspects of the scheme and its operation,</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff size=2>and 
allow for a new round of discussions.</FONT></SPAN></DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=866282718-28102003><FONT face=Arial color=#0000ff 
size=2>-Vishal</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
  [mailto:[email-masked]]<B>On Behalf Of </B>Richard 
  Rabbat<BR><B>Sent:</B> Monday, October 27, 2003 9:24 PM<BR><B>To:</B> 
  [email-masked]<BR><B>Cc:</B> [email-masked]; 'zafar ali'; 'Richard 
  Rabbat'<BR><B>Subject:</B> Updates on drafts on Protection and Restoration for 
  optical transport networks<BR><BR></FONT></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi CCAMP&#8217;ers,</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Following the interest that was 
  developed on our draft proposals and the number of questions and requests for 
  clarifications, we have written up a couple of drafts to answer these and 
  updated our main draft.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">We first wrote a draft on why we 
  would need expedited flooding for fault notification.&nbsp; This draft 
  highlights how expedited flooding notification could be used to deliver 
  time-bounded notification for optical transport networks that implement shared 
  recovery.&nbsp; It&#8217;s available at:</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
  href="http://www.ietf.org/internet-drafts/draft-rabbat-expedited-flooding-00.txt">http://www.ietf.org/internet-drafts/draft-rabbat-expedited-flooding-00.txt</A></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">We also wrote a draft to discuss 
  the applicability of the fault notification protocol FNP. </SPAN></FONT><FONT 
  face=Arial size=2><SPAN lang=FR 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">It&#8217;s available 
  at:</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN lang=FR 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
  href="http://www.ietf.org/internet-drafts/draft-rabbat-fnp-applicability-00.txt">http://www.ietf.org/internet-drafts/draft-rabbat-fnp-applicability-00.txt</A></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">This draft basically describes the 
  faults and network model context where we use FNP.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">We finally updated the draft on 
  the Fault Notification Protocol</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
  href="http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-04.txt">http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-04.txt</A></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">This update is a reorganization to 
  make it more readable and focus on the proposed protocol 
  specifically.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Announcements on CCAMP should 
  follow shortly. We&#8217;d like to ask people to read these drafts and send us 
  comments. </SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">I hope these drafts address the 
  numerous discussions that we have had so that we can move the work forward on 
  the agenda of the working group.&nbsp; </SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks a lot for everybody&#8217;s 
  emails and time spent to help advance this work.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Richard.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0002_01C39D41.19539910--

Delivery-date: Tue, 28 Oct 2003 15:55:41 +0000
From: Nurit Sprecher <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, Nic Neate <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: RSVP Graceful Restart
Date: Tue, 28 Oct 2003 17:55:16 +0200

Hi,
1. There are also issues not necessarily related to multiple errors in the
network. A MP of multiple detours should know which detour should be
refreshed downstream, etc.
2. You say, "A practical solution (that may not satisfy all) is for GR to
recover 'regular' LSPs sessions, and to re-initiate FRR sessions; and to
abort GR if a second failure occurs that would have necessitated FRR.". 
a. The entire LSP should be tuned with this (upstream detours that are
merged in the restarted node are affected, etc.).  This becomes to be not so
graceful

I think that this interworking of FRR and graceful restart should be
analyzed and the protocol may be needed to support it.
Nurit,

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tuesday, October 28, 2003 16:47
To: Nic Neate
Cc: [email-masked]'; [email-masked]'
Subject: RE: RSVP Graceful Restart

Hi Nic,

On Mon, 27 Oct 2003, Nic Neate wrote:

> The issue with that is not with overlap in the problems they are solving,
> but in recovering FRR backup and protected LSPs (which may not be being
> refreshed from upstream) after a restart.  Is this a problem that
interests
> you?

Thanks for clarifying.  I agree that networks will have both GR and
FRR.  In principle, I agree that this (recovering FRR sessions during
GR) is a problem that needs to be solved.  However, the premise here
is that during GR (hopefully a small time window, say a couple of
minutes), you have a second failure (of a link or a node).

Yes, it's possible to have multiple failures, but the combination of a
control plane failure recoverable by GR and a link/node failure that
requires FRR seems remote.

A practical solution (that may not satisfy all) is for GR to recover
'regular' LSPs sessions, and to re-initiate FRR sessions; and to abort
GR if a second failure occurs that would have necessitated FRR.

On the other hand, let me not discourage you.  Let's take a look at
solutions, and see how simple/complex they are before ruling on the
protocol work.

Kireeti.
-------

Delivery-date: Tue, 28 Oct 2003 15:55:28 +0000
Date: Tue, 28 Oct 2003 07:54:27 -0800 (PST)
From: Arthi Ayyangar <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-ayyangar-inter-region-te-01.txt]

-------- Original Message --------
Subject: I-D ACTION:draft-ayyangar-inter-region-te-01.txt
Date: Mon, 27 Oct 2003 15:56:04 -0500
From: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Inter-region MPLS Traffic Engineering
	Author(s)	: A. Ayyangar, J. Vasseur
	Filename	: draft-ayyangar-inter-region-te-01.txt
	Pages		: 23
	Date		: 2003-10-27

This draft proposes mechanisms for the establishment and maintenance of
MPLS Traffic Engineering (TE) Label Switched Paths (LSP) that traverse
multiple regions, where a region could be an IGP Area or an Autonomous
System or a GMPLS overlay network. This document also outlines different
mechanisms that an operator could employ within his region to facilitate
the setup of these inter-region TE LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ayyangar-inter-region-te-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-ayyangar-inter-region-te-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-ayyangar-inter-region-te-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.

Delivery-date: Tue, 28 Oct 2003 15:48:35 +0000
From: Nic Neate <[email-masked]>
To: 'Alia Atlas' <[email-masked]>, Juniper - Kireeti Kompella <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: RSVP Graceful Restart
Date: Tue, 28 Oct 2003 15:47:27 -0000

Hi Alia,

The problem I described was actually at a merge point.

The sequence of events is this.
1.  MP set up as usual.
2.  Upstream failure on protected LSP triggers a reroute at the upstream
PLR.  The MP stops receiving Path Refreshes on the protected LSP.  It
continues to receive them on the merging backup over which data traffic is
also now arriving.
3.  MP has a control plane failure, but data plane survives.
4.  MP control plane restarts and GR mechanisms at that node have to
construct a Path Refresh to send downstream on the protected LSP when the
only Path Refreshes being received are on the merging backup.  There are
various issues here as described in my last email.

I don't think this is an insignificant timing window.  The lack of refreshes
at the MP should be resolved by either local revertive behavior on the
protected LSP or a make-before-break of the protected LSP, but that may take
some time.

Because no Path Refreshes are arriving on the protected LSP in this period,
it is not an option to just use regular restart mechanisms to recover the
LSP and then reinitiate the FRR protection.

Let me know if anything's not clear,

Nic

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]]
Sent: Tuesday, October 28, 2003 3:26 PM
To: Juniper - Kireeti Kompella
Cc: Nic Neate; [email-masked]'; [email-masked]'
Subject: RE: RSVP Graceful Restart

Hi Nic & Kireeti,

Why is it necessary to recover a protected LSP between the active PLR and 
the merge node?  That protected LSP will not be used; if one reverts back 
to it, then it can be actively recreated, which has to happen today anyhow.

The merge node can ensure that the primary is recovered for itself and 
downstream.  The PLR can ensure it recovers its backup and the primary
itself.

What I am missing in the problem statement?

Thanks,
Alia

At 09:47 AM 10/28/2003, Kireeti Kompella wrote:
>Hi Nic,
>
>On Mon, 27 Oct 2003, Nic Neate wrote:
>
> > The issue with that is not with overlap in the problems they are
solving,
> > but in recovering FRR backup and protected LSPs (which may not be being
> > refreshed from upstream) after a restart.  Is this a problem that
interests
> > you?
>
>Thanks for clarifying.  I agree that networks will have both GR and
>FRR.  In principle, I agree that this (recovering FRR sessions during
>GR) is a problem that needs to be solved.  However, the premise here
>is that during GR (hopefully a small time window, say a couple of
>minutes), you have a second failure (of a link or a node).
>
>Yes, it's possible to have multiple failures, but the combination of a
>control plane failure recoverable by GR and a link/node failure that
>requires FRR seems remote.
>
>A practical solution (that may not satisfy all) is for GR to recover
>'regular' LSPs sessions, and to re-initiate FRR sessions; and to abort
>GR if a second failure occurs that would have necessitated FRR.
>
>On the other hand, let me not discourage you.  Let's take a look at
>solutions, and see how simple/complex they are before ruling on the
>protocol work.
>
>Kireeti.
>-------

Delivery-date: Tue, 28 Oct 2003 15:24:13 +0000
Date: Tue, 28 Oct 2003 10:26:28 -0500
To: Kireeti Kompella <[email-masked]>
From: Alia Atlas <[email-masked]>
Subject: RE: RSVP Graceful Restart
Cc: Nic Neate <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>

Hi Nic & Kireeti,

Why is it necessary to recover a protected LSP between the active PLR and 
the merge node?  That protected LSP will not be used; if one reverts back 
to it, then it can be actively recreated, which has to happen today anyhow.

The merge node can ensure that the primary is recovered for itself and 
downstream.  The PLR can ensure it recovers its backup and the primary itself.

What I am missing in the problem statement?

Thanks,
Alia

At 09:47 AM 10/28/2003, Kireeti Kompella wrote:
>Hi Nic,
>
>On Mon, 27 Oct 2003, Nic Neate wrote:
>
> > The issue with that is not with overlap in the problems they are solving,
> > but in recovering FRR backup and protected LSPs (which may not be being
> > refreshed from upstream) after a restart.  Is this a problem that interests
> > you?
>
>Thanks for clarifying.  I agree that networks will have both GR and
>FRR.  In principle, I agree that this (recovering FRR sessions during
>GR) is a problem that needs to be solved.  However, the premise here
>is that during GR (hopefully a small time window, say a couple of
>minutes), you have a second failure (of a link or a node).
>
>Yes, it's possible to have multiple failures, but the combination of a
>control plane failure recoverable by GR and a link/node failure that
>requires FRR seems remote.
>
>A practical solution (that may not satisfy all) is for GR to recover
>'regular' LSPs sessions, and to re-initiate FRR sessions; and to abort
>GR if a second failure occurs that would have necessitated FRR.
>
>On the other hand, let me not discourage you.  Let's take a look at
>solutions, and see how simple/complex they are before ruling on the
>protocol work.
>
>Kireeti.
>-------

Delivery-date: Tue, 28 Oct 2003 14:50:26 +0000
Date: Tue, 28 Oct 2003 06:47:11 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Nic Neate <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: RSVP Graceful Restart

Hi Nic,

On Mon, 27 Oct 2003, Nic Neate wrote:

> The issue with that is not with overlap in the problems they are solving,
> but in recovering FRR backup and protected LSPs (which may not be being
> refreshed from upstream) after a restart.  Is this a problem that interests
> you?

Thanks for clarifying.  I agree that networks will have both GR and
FRR.  In principle, I agree that this (recovering FRR sessions during
GR) is a problem that needs to be solved.  However, the premise here
is that during GR (hopefully a small time window, say a couple of
minutes), you have a second failure (of a link or a node).

Yes, it's possible to have multiple failures, but the combination of a
control plane failure recoverable by GR and a link/node failure that
requires FRR seems remote.

A practical solution (that may not satisfy all) is for GR to recover
'regular' LSPs sessions, and to re-initiate FRR sessions; and to abort
GR if a second failure occurs that would have necessitated FRR.

On the other hand, let me not discourage you.  Let's take a look at
solutions, and see how simple/complex they are before ruling on the
protocol work.

Kireeti.
-------

Delivery-date: Tue, 28 Oct 2003 05:26:28 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "'zafar ali'" <[email-masked]>, "'Richard Rabbat'" <[email-masked]>
Subject: Updates on drafts on Protection and Restoration for optical transport networks
Date: Mon, 27 Oct 2003 21:24:02 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C39CD0.A578E4C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi CCAMP'ers,

Following the interest that was developed on our draft proposals and the
number of questions and requests for clarifications, we have written up a
couple of drafts to answer these and updated our main draft.

We first wrote a draft on why we would need expedited flooding for fault
notification.  This draft highlights how expedited flooding notification
could be used to deliver time-bounded notification for optical transport
networks that implement shared recovery.  It's available at:

http://www.ietf.org/internet-drafts/draft-rabbat-expedited-flooding-00.txt

We also wrote a draft to discuss the applicability of the fault notification
protocol FNP. It's available at:

http://www.ietf.org/internet-drafts/draft-rabbat-fnp-applicability-00.txt

This draft basically describes the faults and network model context where we
use FNP.

We finally updated the draft on the Fault Notification Protocol

http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol
-04.txt

This update is a reorganization to make it more readable and focus on the
proposed protocol specifically.

Announcements on CCAMP should follow shortly. We'd like to ask people to
read these drafts and send us comments. 

I hope these drafts address the numerous discussions that we have had so
that we can move the work forward on the agenda of the working group.  

Thanks a lot for everybody's emails and time spent to help advance this
work.

Richard.

------=_NextPart_000_0009_01C39CD0.A578E4C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">

<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Hi CCAMP&#8217;ers,</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Following the interest that was developed on our draft
proposals and the number of questions and requests for clarifications, we have
written up a couple of drafts to answer these and updated our main draft.</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>We first wrote a draft on why we would need expedited
flooding for fault notification.&nbsp; This draft highlights how expedited flooding
notification could be used to deliver time-bounded notification for optical transport
networks that implement shared recovery.&nbsp; It&#8217;s available at:</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><a
href="http://www.ietf.org/internet-drafts/draft-rabbat-expedited-flooding-00.txt">http://www.ietf.org/internet-drafts/draft-rabbat-expedited-flooding-00.txt</a></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>We also wrote a draft to discuss the applicability of the
fault notification protocol FNP. </span></font><font size=2 face=Arial><span
lang=FR style='font-size:10.0pt;font-family:Arial'>It&#8217;s available at:</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=FR style='font-size:10.0pt;
font-family:Arial'><a
href="http://www.ietf.org/internet-drafts/draft-rabbat-fnp-applicability-00.txt">http://www.ietf.org/internet-drafts/draft-rabbat-fnp-applicability-00.txt</a></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>This draft basically describes the faults and network model context
where we use FNP.</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>We finally updated the draft on the Fault Notification
Protocol</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><a
href="http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-04.txt">http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-04.txt</a></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>This update is a reorganization to make it more readable and
focus on the proposed protocol specifically.</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Announcements on CCAMP should follow shortly. We&#8217;d
like to ask people to read these drafts and send us comments. </span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>I hope these drafts address the numerous discussions that we
have had so that we can move the work forward on the agenda of the working
group.&nbsp; </span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Thanks a lot for everybody&#8217;s emails and time spent to help
advance this work.</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Richard.</span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0009_01C39CD0.A578E4C0--

Delivery-date: Mon, 27 Oct 2003 20:29:29 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-02.txt
Date: Mon, 27 Oct 2003 15:27:44 -0500

--NextPart

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

	Title		: GMPLS RSVP Support for the Overlay Model
	Author(s)	: G. Swallow
	Filename	: draft-ietf-ccamp-gmpls-overlay-02.txt
	Pages		: 11
	Date		: 2003-10-27
	
Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport
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-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-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-overlay-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-overlay-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-overlay-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: Mon, 27 Oct 2003 14:03:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Nic Neate" <[email-masked]>, "Juniper - Kireeti Kompella" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Re: RSVP Graceful Restart
Date: Mon, 27 Oct 2003 14:00:19 -0000

Nic,

Could you set out the problem in a couple of paragraphs (perhaps with an example) and let
everyone see what it is you're working on so that they can join in the discussions.

Thanks,
Adrian
----- Original Message ----- 
From: "Nic Neate" <[email-masked]>
To: "Juniper - Kireeti Kompella" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>; <[email-masked]>
Sent: Monday, October 27, 2003 1:23 PM
Subject: RE: RSVP Graceful Restart

> Hi Kireeti,
>
> As you say, FRR and GR solve very different problems, and that is why it's
> desirable to have both in the same network.
>
> The issue with that is not with overlap in the problems they are solving,
> but in recovering FRR backup and protected LSPs (which may not be being
> refreshed from upstream) after a restart.  Is this a problem that interests
> you?
>
> Nic
>
> -----Original Message-----
> From: Juniper - Kireeti Kompella
> Sent: Friday, October 24, 2003 7:40 PM
> To: Nic Neate
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: RSVP Graceful Restart
>
>
> Hi Nic,
>
> On Wed, 22 Oct 2003, Nic Neate wrote:
>
> > Together with some colleagues at Data Connection, I have done some work
> > looking at how GMPLS Restart could work with RSVP Fast Reroute LSPs.
>
> FRR and GR solve *very* different problems: the first is for link or
> node failures where the data plane is affected, the second for control
> plane failures (a special subset of node failures).
>
> Could you explain the problem you see here?
>
> Kireeti.
>
>

Delivery-date: Mon, 27 Oct 2003 13:30:53 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: An updated reference of the control plane resililence for GMPLS
Date: Mon, 27 Oct 2003 22:26:36 +0900

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

------_=_NextPart_000_01C39C8D.F2516C10
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C39C8D.F2516C10"

------_=_NextPart_001_01C39C8D.F2516C10
Content-Type: text/plain;
	charset="euc-kr"

Hi ccampers,

Thank you for your comments of "A reference of the control plane
resililence for GMPLS".
>From several comments, I reviewed ITU-T documents such as the latest G.7712
and G.8080.
For an updated reference, attached the ITU-T(G.7712and G.8080) contents for
control plane resililence is here.
Then, I updated my draft presented in the 57th meeting into draft-kim-ccamp-
cc-protection-04.txt.

I think that there is a clear difference between ITUT-T's resilience and my
draft's resilience in control plane.
I think that my draft focuses on the resilience capability of control plane
from the view-point of the protection and restoration of control channels
between two adjacent nodes with associated, non-associated, and quasi-
associated control relations.
while the ITU-T documents focus on the resilience capability of control
plane from the view-point of the protection and restoration of LSPs between
ingress and egress nodes.

If possible, I'd like to propose the control plane resilience as a
recharter item, based on draft-kim-ccamp-cc-protection-04.txt.
But, still I'm not sure whether the control plane resilience is included in
the existing charter or not.
I want to get comments about this point from ccampers.

------_=_NextPart_001_01C39C8D.F2516C10
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>An updated reference of the control plane resililence for GMPLS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi ccampers,</FONT>
</P>

<P><FONT SIZE=2>Thank you for your comments of &quot;A reference of the control plane resililence for GMPLS&quot;.</FONT>
<BR><FONT SIZE=2>From several comments, I reviewed ITU-T documents such as the latest G.7712 and G.8080.</FONT>
<BR><FONT SIZE=2>For an updated reference, attached the ITU-T(G.7712and G.8080) contents for control plane resililence is here.</FONT>
<BR><FONT SIZE=2>Then, I updated my draft presented in the 57th meeting into draft-kim-ccamp-cc-protection-04.txt.</FONT>
</P>

<P><FONT SIZE=2>I think that there is a clear difference between ITUT-T's resilience and my draft's resilience in control plane.</FONT>
<BR><FONT SIZE=2>I think that my draft focuses on the resilience capability of control plane from the view-point of the protection and restoration of control channels between two adjacent nodes with associated, non-associated, and quasi-associated control relations.</FONT></P>

<P><FONT SIZE=2>while the ITU-T documents focus on the resilience capability of control plane from the view-point of the protection and restoration of LSPs between ingress and egress nodes.</FONT></P>

<P><FONT SIZE=2>If possible, I'd like to propose the control plane resilience as a recharter item, based on draft-kim-ccamp-cc-protection-04.txt.</FONT></P>

<P><FONT SIZE=2>But, still I'm not sure whether the control plane resilience is included in the existing charter or not.</FONT>
<BR><FONT SIZE=2>I want to get comments about this point from ccampers.</FONT>
</P>

<P><FONT FACE="±¼¸²" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C39C8D.F2516C10--

------_=_NextPart_000_01C39C8D.F2516C10
Content-Type: application/msword;
	name="T-REC-G.7712-G.8080 (CP).doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="T-REC-G.7712-G.8080 (CP).doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAGAAAAhwAAAAAAAAAA
EAAAiQAAAAMAAAD+////AAAAAIUAAACGAAAA+AAAAH8BAAD4AQAAewIAAP//////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////wEAAAAQAAAA////////////////////////////////////////////
////////////////////AQAAABAAAP8BAAAAEQAA/wEAAAASAAD/AQAAABMAAP8BAAAAFAAA/wEA
AAAVAAD/AQAAABYAAAABAAAAFwAAAAEAAAAYAIww////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////Ur0AHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsQAAAPhGgBEYSY/l6E
aAFghJj+T0oBAFFKAQBvKAABAC3w/////ziwQAcgAAAAAAAAABdAAAAAAAAAAAAAAAAAAAAbAQAA
CwAAAE9KAQBRSgEAbygAAQC38P//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_000_01C39C8D.F2516C10--

Delivery-date: Mon, 27 Oct 2003 11:50:47 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>
Subject: Agenda for Minneapolis
Date: Mon, 27 Oct 2003 11:47:45 -0000

Folks,

We are putting the finishing touches to the CCAMP agenda for Minneapolis. Treat this as a
last call for a slot.

We have a *lot* of requests for slots. As a result it is very unlikely that everyone who
wants a go will get a chance.

The focus of the agenda will be (in order) on WG milestones, WG drafts, other drafts that
address charter items, other drafts.

Can we ask everyone to remember that timeslots are not for you to present your draft. They
are for the WG to discuss the technical issues and to ask questions. You should assume
that everyone in the room has read your draft. You should be telling us what your plans
are - what problems you have left to solve, and what your schedule is.

The quicker you are, the more drafts will get a go.
Prizes will be awarded for the people who save most agenda time.

Thanks,
Adrian

Delivery-date: Sat, 25 Oct 2003 15:16:46 +0000
Date: Sat, 25 Oct 2003 11:12:57 -0400
To: [email-masked], [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Slots for the next IETF in CCAMP
Cc: [email-masked], raymond zhang <[email-masked]>, yuichi Ikejiri <[email-masked]>

Hi Kireeti and Adrian,

May I ask you two slots for:

(1) draft-vasseur-mpls-loose-path-reopt-02.txt - 5mn
(2) draft-vasseur-inter-as-te-01.txt - 5mn

Thanks.

JP.

Delivery-date: Fri, 24 Oct 2003 18:41:35 +0000
Date: Fri, 24 Oct 2003 11:39:44 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Nic Neate <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: RSVP Graceful Restart

Hi Nic,

On Wed, 22 Oct 2003, Nic Neate wrote:

> Together with some colleagues at Data Connection, I have done some work
> looking at how GMPLS Restart could work with RSVP Fast Reroute LSPs.

FRR and GR solve *very* different problems: the first is for link or
node failures where the data plane is affected, the second for control
plane failures (a special subset of node failures).

Could you explain the problem you see here?

Kireeti.

Delivery-date: Fri, 24 Oct 2003 14:23:23 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-02.txt
Date: Fri, 24 Oct 2003 10:22: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 Switch Router Management Information Base
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-02.txt
	Pages		: 31
	Date		: 2003-10-23
	
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-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-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-lsr-mib-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 24 Oct 2003 14:23:15 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-02.txt
Date: Fri, 24 Oct 2003 10:21:42 -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, et al.
	Filename	: draft-ietf-ccamp-gmpls-tc-mib-02.txt
	Pages		: 8
	Date		: 2003-10-23
	
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-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-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-tc-mib-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 24 Oct 2003 13:06:01 +0000
content-class: urn:content-classes:message
Subject: RE: A reference of the control plane resililence for GMPLS
Date: Fri, 24 Oct 2003 09:04:11 -0400
From: "Lazer, Monica A, ALABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C39A2F.5183816F
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

G.8080 (Am1) also describe control plane resiliency. You may want to look into that as well.

Monica A. Lazer<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 23, 2003 10:01 PM
To: [email-masked]
Subject: A reference of the control plane resililence for GMPLS

I'd like to discuss the control plane resililence for GMPLS. 
As a seed I presented this topic in the 57th meeting. 
For a reference, here is attached the ITU-T(G.7712) content for control plane resililence. 
Individullay I think the way described in the document is not good for GMPLS. 

------_=_NextPart_001_01C39A2F.5183816F
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ks_c_5601-1987">
<TITLE>A reference of the control plane resililence for GMPLS</TITLE>

<META content="MSHTML 6.00.2800.1264" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=626580213-24102003><FONT face=Arial color=#0000ff size=2>G.8080 
(Am1) also describe control plane resiliency. You may want to look into that as 
well.</FONT></SPAN></DIV>
<DIV><SPAN class=626580213-24102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=626580213-24102003>
<DIV class=Section1>
<P style="MARGIN: 0in 0in 0pt"><SPAN 
style="FONT-SIZE: 14pt; FONT-FAMILY: 'Monotype Corsiva'; mso-bidi-font-size: 12.0pt">Monica 
A. Lazer<?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<P class=MsoNormal></SPAN><FONT face=Tahoma size=2>-----Original 
Message-----<BR><B>From:</B> [email-masked] 
[mailto:[email-masked]]<BR><B>Sent:</B> Thursday, October 23, 2003 10:01 
PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> A reference of the 
control plane resililence for GMPLS<BR><BR></FONT></P></DIV></DIV>
<P><FONT size=2>I'd like to discuss the control plane resililence for 
GMPLS.</FONT> <BR><FONT size=2>As a seed I presented this topic in the 57th 
meeting.</FONT> <BR><FONT size=2>For a reference, here is attached the 
ITU-T(G.7712) content for control plane resililence.</FONT> <BR><FONT 
size=2>Individullay I think the way described in the document is not good for 
GMPLS.</FONT> </P>
<P><FONT face=±¼¸² color=#000000 size=2></FONT> </P></BODY></HTML>

------_=_NextPart_001_01C39A2F.5183816F--

Delivery-date: Fri, 24 Oct 2003 02:05:25 +0000
From: [email-masked]
To: [email-masked]
Subject: A reference of the control plane resililence for GMPLS
Date: Fri, 24 Oct 2003 11:00:48 +0900

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

------_=_NextPart_000_01C399D2.A4F33510
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C399D2.A4F33510"

------_=_NextPart_001_01C399D2.A4F33510
Content-Type: text/plain;
	charset="euc-kr"

I'd like to discuss the control plane resililence for GMPLS.
As a seed I presented this topic in the 57th meeting.
For a reference, here is attached the ITU-T(G.7712) content for control
plane resililence.
Individullay I think the way described in the document is not good for
GMPLS.

------_=_NextPart_001_01C399D2.A4F33510
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>A reference of the control plane resililence for GMPLS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I'd like to discuss the control plane resililence for GMPLS.</FONT>
<BR><FONT SIZE=2>As a seed I presented this topic in the 57th meeting.</FONT>
<BR><FONT SIZE=2>For a reference, here is attached the ITU-T(G.7712) content for control plane resililence.</FONT>
<BR><FONT SIZE=2>Individullay I think the way described in the document is not good for GMPLS.</FONT>
</P>

<P><FONT FACE="±¼¸²" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C399D2.A4F33510--

------_=_NextPart_000_01C399D2.A4F33510
Content-Type: application/msword;
	name="T-REC-G[1].7712-200303-P!!MSW-E(Sec 6.2.4).doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="T-REC-G[1].7712-200303-P!!MSW-E(Sec 6.2.4).doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAFwAAAAAAAAAA
EAAAGQAAAAMAAAD+////AAAAABYAAAB+AAAA8QAAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////AQAAABAAAAD/////////////////////////////
//////////////////////////////////8BAAAAEAAA/wEAAAARAAD/AQAAABIAAP8BAAAAEwAA
/wEAAAAUAAD/AQAAABUAAP8BAAAAFgAAAAEAAAAXAAAAAQAAABgAjDD/////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////wxq9wggAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACxAA
AA+EaAERhJj+XoRoAWCEmP5PSgEAUUoBAG8oAAEALfD/////cGr3CCAAAAAAAAAAF0AAAAAAAAAA
AAAAAAAAABsBAAALAAAAT0oBAFFKAQBvKAABALfw////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_000_01C399D2.A4F33510--

Delivery-date: Fri, 24 Oct 2003 01:00:12 +0000
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-kim-ccamp-interaction-grsvpte-lcas-00.txt
Date: Fri, 24 Oct 2003 09:54:49 +0900

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

------_=_NextPart_001_01C399C9.6CD91C70
Content-Type: text/plain;
	charset="euc-kr"

Hi, ccampers !
Here is my draft for this 58th meeting.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		    : Interaction between GMPLS RSVP-TE and LCAS
	Author(s)	: Y. Kim, et. al.
	Filename	: draft-kim-ccamp-interaction-grsvpte-lcas-00.txt
	Pages		: 10
	Date		   : 2003-10-20
	
This document describes interaction aspects between a signaling 
protocol and LCAS. The signaling protocol handled by IETF could be 
GMPLS RSVP-TE. GMPLS CR-LDP requires further study for this draft. 
The LCAS protocol handled by ITU-T is a protocol that is used to 
change the bandwidth capacity of a virtual concatenated signal used 
by transport networks (i.e. SDH and OTN), which should be initiated
only in a unidirection by EMS or NMS systems. However, the GMPLS 
signaling protocol has a feature of being capable of establishing bi-
directional connections over a LSP. In current, there is no 
interaction between the signaling protocol and LCAS. In this document, 
when a signaling protocol such as GMPLS RSVP-TE and LCAS are used 
together within a node and the bi-directional connection is requested 
over the same route, the relevant requirements are identified 
to help the initiation process of egress node by EMS or 
NMS systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-interaction-grsvpte-
lcas-00.txt
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

------_=_NextPart_001_01C399C9.6CD91C70
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>I-D ACTION:draft-kim-ccamp-interaction-grsvpte-lcas-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi, ccampers !</FONT>
<BR><FONT SIZE=2>Here is my draft for this 58th meeting.</FONT>
<BR><FONT SIZE=2>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++</FONT>
<BR><FONT SIZE=2>A New Internet-Draft is available from the on-line Internet-Drafts directories.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; : Interaction between GMPLS RSVP-TE and LCAS</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Y. Kim, et. al.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : draft-kim-ccamp-interaction-grsvpte-lcas-00.txt</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 10</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; : 2003-10-20</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<BR><FONT SIZE=2>This document describes interaction aspects between a signaling </FONT>
<BR><FONT SIZE=2>protocol and LCAS. The signaling protocol handled by IETF could be </FONT>
<BR><FONT SIZE=2>GMPLS RSVP-TE. GMPLS CR-LDP requires further study for this draft. </FONT>
<BR><FONT SIZE=2>The LCAS protocol handled by ITU-T is a protocol that is used to </FONT>
<BR><FONT SIZE=2>change the bandwidth capacity of a virtual concatenated signal used </FONT>
<BR><FONT SIZE=2>by transport networks (i.e. SDH and OTN), which should be initiated</FONT>
<BR><FONT SIZE=2>only in a unidirection by EMS or NMS systems. However, the GMPLS </FONT>
<BR><FONT SIZE=2>signaling protocol has a feature of being capable of establishing bi-</FONT>
<BR><FONT SIZE=2>directional connections over a LSP. In current, there is no </FONT>
<BR><FONT SIZE=2>interaction between the signaling protocol and LCAS. In this document, </FONT>
<BR><FONT SIZE=2>when a signaling protocol such as GMPLS RSVP-TE and LCAS are used </FONT>
<BR><FONT SIZE=2>together within a node and the bi-directional connection is requested </FONT>
<BR><FONT SIZE=2>over the same route, the relevant requirements are identified </FONT>
<BR><FONT SIZE=2>to help the initiation process of egress node by EMS or </FONT>
<BR><FONT SIZE=2>NMS systems.</FONT>
</P>

<P><FONT SIZE=2>A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=2><A HREF="http://www.ietf.org/internet-drafts/draft-kim-ccamp-interaction-grsvpte-lcas-00.txt" TARGET="_blank">http://www.ietf.org/internet-drafts/draft-kim-ccamp-interaction-grsvpte-lcas-00.txt</A></FONT>
<BR><FONT SIZE=2>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C399C9.6CD91C70--

Delivery-date: Thu, 23 Oct 2003 15:31:02 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shiomoto-ccamp-cplane-architecture-00.txt
Date: Thu, 23 Oct 2003 11:29:23 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Control plane architecture in GMPLS networks
	Author(s)	: K. Shiomoto, et. al.
	Filename	: draft-shiomoto-ccamp-cplane-architecture-00.txt
	Pages		: 0
	Date		: 2003-10-23
	
This document addresses control plane architecutre in GMPLS enabled IP-
Optical networks. Two different control plane architectures are consid-
ered: symmetical and asymmetrical control plane architectures. Addressing (router-ID, control plane address, and TE link address) and RSVP message handling (routing, HOP and ERO objects processing) are discussed for both architectures.The document also recommends normal practises for identification of TE links. Interwork between symmetrical and asymmetrical control plane is addressed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-cplane-architecture-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-shiomoto-ccamp-cplane-architecture-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-shiomoto-ccamp-cplane-architecture-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-shiomoto-ccamp-cplane-architecture-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-shiomoto-ccamp-cplane-architecture-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: Thu, 23 Oct 2003 15:15:40 +0000
From: Nurit Sprecher <[email-masked]>
To: 'Nic Neate' <[email-masked]>, Nurit Sprecher <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Ilan Barda <[email-masked]>,  Guy Attar <[email-masked]>
Subject: RE: RSVP Graceful Restart
Date: Thu, 23 Oct 2003 17:13:26 +0200

Hi all,
We are in Seabridge are very interesting in such a solution. The FRR
mechanism is described in the MPLS WG. There is a very general description
in the GMPLS document (in the CCAMP WG) on the graceful restart procedure.
Unfortunately these two mechanisms do not work 'so good' together in the
same network. 
We would like to see a standard document, supplying a mechanism to support
both mechanisms together in the same network and let them work correctly. We
hope that the IETF will cover the issue.
Nurit.

 -----Original Message-----
From: 	Nic Neate [mailto:[email-masked]] 
Sent:	Wednesday, October 22, 2003 17:41
To:	Seabridge - Nurit Sprecher; [email-masked]'; [email-masked]';
[email-masked]'
Cc:	[email-masked]'; [email-masked]'
Subject:	RE: RSVP Graceful Restart

All,

Together with some colleagues at Data Connection, I have done some work
looking at how GMPLS Restart could work with RSVP Fast Reroute LSPs.  While
Restart was originally intended as a recovery mechanism for optical networks
and Fast Reroute more as a packet network protection scheme, they do both
provide data traffic preservation mechanisms that could be usefully deployed
in the same network.  We'd be interested in working with anyone looking at
progressing a solution for this.

There are various complications in recovering RSVP state when a node
supporting backup LSPs restarts, in particular following a failure of the
upstream or downstream protected LSP.  New mechanisms will be required to
reconstruct the FAST_REROUTE, DETOUR, ERO, RRO, SENDER_TSPEC, FLOWSPEC and
SESSION_ATTRIBUTES objects.

Again, we've got some ideas on this.  What is the general level of interest
in this area?

Nic

-----Original Message-----
From: Seabridge - Nurit Sprecher
Sent: Wednesday, October 22, 2003 10:43 AM
To: [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RSVP Graceful Restart

Hi,
I did not have the chance yet to read the draft, but I really believe there
is a need to extend the general description in the GMPL document.
I hope that you new definition for the ERO recovery would help also to let
the Ingress LER to recover.

One more thing that I would like to see in the extension, is how graceful
restart works together with Fast Reroute Protection. Specifically the
problematic points are the MP and the PLR. Do you have any intention to
cover it as well?

Thanks in advance, Nurit.

Delivery-date: Thu, 23 Oct 2003 14:27:06 +0000
From: Nurit Sprecher <[email-masked]>
To: 'Reshad Rahman' <[email-masked]>, Nurit Sprecher <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: RSVP Graceful Restart
Date: Thu, 23 Oct 2003 16:24:55 +0200

Thanks for responding me. I am glad to see a (in the way) standard for the
Ingress recovery.
Regarding the FRR and Graceful restart I am not sure that the protocol
should not be modified. I'll investigate the issue next week and let you
know. But for sure an informational section should be applied.
Best regards, Nurit.

-----Original Message-----
From: Reshad Rahman [mailto:[email-masked]]
Sent: Thursday, October 23, 2003 02:21
To: Nurit Sprecher
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'
Subject: Re: RSVP Graceful Restart

Nurit Sprecher wrote:

>Hi,
>I did not have the chance yet to read the draft, but I really believe there
>is a need to extend the general description in the GMPL document.
>I hope that you new definition for the ERO recovery would help also to let
>the Ingress LER to recover.
>

Hi,

Yes, this will also let the ingress recover the ERO.

>
>One more thing that I would like to see in the extension, is how graceful
>restart works together with Fast Reroute Protection. Specifically the
>problematic points are the MP and the PLR. Do you have any intention to
>cover it as well?
>
Regarding GR + FRR, we currently believe that an informational section
would be sufficient, i.e. no need for protocol extensions.

Regards,
Reshad.

>
>Thanks in advance, Nurit.
> 
>

Delivery-date: Thu, 23 Oct 2003 01:09:52 +0000
From: "zafar ali" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: RE: Component Link Recording for TE Link Bundles (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated)  
Date: Wed, 22 Oct 2003 21:08:22 -0400
Organization: Cisco Systems

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C398E0.A1B6E4C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Vishal, 
 
Thanks your your useful comments and pointer to Nic's email and
contribution. I am adding Nic to "to list" to solicit his comments and
use of this draft in the application he is proposing. I will search
further on the mailing list achieve to understand the applicability
myself. 
 
Thanks
 
Regards... Zafar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vishal Sharma
Sent: Wednesday, October 22, 2003 6:28 PM
To: zafar ali; [email-masked]
Cc: [email-masked]; [email-masked]; 'Adrian Farrel';
'Kireeti Kompella'
Subject: RE: Component Link Recording for TE Link Bundles
(draft-zamfir-explicit-resource-control-bundle-01.txt has been updated) 

Hi Zafar,
 
Thanks for your note. Although I've not had an opportunity yet to look
at the most
recent version of the document, I have read through the previous
version, and think
the idea of recording component link information in the RRO is useful in
several 
contexts:
 
i) Disseminating the component link information to the edge nodes (and
provider
NMSs) can be very useful for restoration. E.g. when a failure that
affects only
a small subset of LSPs occurs (as opposed to a fiber cut or link failure
that
affects all LSPs in the bundle), it would be valuable to send the
component
link info. in the Notify (or equivalent) message and have the end
node(s) recognize it 
and take corrective action.
 
ii) By extension, it would be useful for a provider to know that a
partial failure
of the bundle has occurred, and to be able to identify which component
has failed.
This could be useful in on-line/off-line path selection and CSPF.
 
iii) I also think that the semantics defined to identify the component
link can be
useful in an of themselves, as they  may be usable by other
mechanisms/methods that
rely on disseminating component link failure info. to various nodes in
the network.
 
BTW, I'm not sure if you've seen Nic Neate's post on MPLS and CCAMP yet,
but
it seems some of what you've proposed is related to or may partially
address
what he's proposing (but I need to think a bit more carefully about
that).
 
-Vishal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of zafar ali
Sent: Monday, October 20, 2003 9:48 AM
To: [email-masked]
Cc: 'zafar ali'; [email-masked]; [email-masked];
'Adrian Farrel'; 'Kireeti Kompella'
Subject: Component Link Recording for TE Link Bundles
(draft-zamfir-explicit-resource-control-bundle-01.txt has been updated) 

Dear Ccamp'ers:
 
This is a follow-up on our AI from last ccamp WG meeting on the
above-mentioned ID. We don't think the crux of this ID came across
right, during the presentation and the follow-up questions and answers.
As Zafar mentioned during the ccamp wg meeting discussions, this ID
mainly addresses problem that exists in the RRO. Specifically, when TE
links are bundled, identification of label resource in RRO is not enough
for the administrative purpose. Network service providers would like to
know the component link that is being used by a given the LSP. In other
words, when link bundling is used, resource recording requires
mechanisms to specify the component link identifier, along the TE link
identifier and Label. 

In current specification, we cannot record component link selected by an
intermediate node in the RRO, which posses an administrative deficiency.
The ID mainly addresses this shortage by defining the extensions to
RSVP-TE to specify component link identifiers for resource recording in
a network containing TE link (a.k.a. link bundles).

This is true that the ID also defines the ERO counter-part. It seems
from our last meeting discussions that one shall try to maintain as
symmetry between the ERO and RRO definitions as much as possible.
Nonetheless, the ERO definition also addresses a current deficiency in
the standard definition. Specifically, explicit resource control for
bi-directional LSP when forward and reverse legs of the LSP are to
follow different component links within a TE bundle is not possible
using current specification. But for the time being, this is not the
main motivation behind this ID.

We think that during the CCAMP WG meeting, somehow everyone was
commenting on the practically of the ERO counterpart. But as Zafar also
mentioned in the question answer session that it is unfair to discuss
merit and fate of this ID based on the ERO extensions contained herein. 

In the light of the above, we would like the WG to discuss the ID based
on its merit and applicably to resource recording in a network
containing bundled TE link. Clearly, the proposed RRO extensions are a
useful tool for administrative purpose. 

N.B. We have also updated the ID, based on comments during last Ccamp WG
meeting; An updated copy will be available at IETF Web site in a couple
of days. In the mean time, a mirror version of the ID can be viewed at,
<http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-b
undle-02.txt>
http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bu
ndle-02.txt.

Comments on usefulness on Component Link Recording for TE Link Bundles
will be very much appreciated. 

Thanks

Regards. Anca, Zafar and Dimitri. 

==================================Zafar Ali, Ph. D.       100 South Main St. #200,
Technical Leader,       Ann Arbor, MI 48104, USA.
Cisco Systems.       (734) 276-2459.
==================================

------=_NextPart_000_002E_01C398E0.A1B6E4C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = 
"urn:schemas-microsoft-com:office:office"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1264" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=344335200-23102003><FONT face=Arial color=#0000ff size=2>Hi 
Vishal, </FONT></SPAN></DIV>
<DIV><SPAN class=344335200-23102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=344335200-23102003><FONT face=Arial color=#0000ff size=2>Thanks 
your your useful comments and pointer to Nic's email and contribution. 
</FONT></SPAN><SPAN class=344335200-23102003><FONT face=Arial color=#0000ff 
size=2>I am adding Nic to "to list" to solicit his comments and use of this 
draft in the application he is proposing. I will search further on the mailing 
list achieve to understand the applicability myself. </FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV align=left><FONT face=Arial color=#0000ff size=2>Thanks</FONT></DIV>
<DIV align=left><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV align=left><FONT face=Arial color=#0000ff size=2>Regards... 
Zafar</FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  [email-masked] [mailto:[email-masked]] <B>On Behalf Of 
  </B>Vishal Sharma<BR><B>Sent:</B> Wednesday, October 22, 2003 6:28 
  PM<BR><B>To:</B> zafar ali; [email-masked]<BR><B>Cc:</B> [email-masked]; 
  [email-masked]; 'Adrian Farrel'; 'Kireeti 
  Kompella'<BR><B>Subject:</B> RE: Component Link Recording for TE Link Bundles 
  (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated) 
  <BR><BR></FONT></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>Hi 
  Zafar,</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2>Thanks for your note. Although I've not had an opportunity yet to look 
  at the most</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2>recent version of the document, I have&nbsp;read through&nbsp;the 
  previous version, and think</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>the 
  idea of recording component link information in the RRO is useful in several 
  </FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2>contexts:</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>i) 
  Disseminating the component link information to the edge nodes (and 
  provider</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2>NMSs) can be very useful for restoration. E.g. when a failure that 
  affects only</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>a 
  small subset of LSPs occurs (as opposed to a fiber cut or link failure 
  that</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2>affects all LSPs in the bundle), it would be valuable to send the 
  component</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>link 
  info. in the Notify (or equivalent) message and have the end node(s) recognize 
  it </FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>and 
  </FONT></SPAN><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2>take corrective action.</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>ii) 
  By extension, it would be useful for a provider to know that a partial 
  failure</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>of 
  the bundle has occurred, and to be able to identify which component has 
  failed.</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>This 
  could be useful in on-line/off-line path selection and 
  CSPF.</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>iii) 
  I also think that the semantics defined to identify the component link can 
  be</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2>useful in an of themselves, as&nbsp;they &nbsp;may be usable by other 
  mechanisms/methods that</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>rely 
  on disseminating component link failure info. to various nodes in the 
  network.</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>BTW, 
  I'm not sure if you've seen Nic Neate's post on MPLS and CCAMP yet, 
  but</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>it 
  seems some of what you've proposed is related to or may partially 
  address</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>what 
  he's proposing (but I need to think a bit more carefully about 
  that).</FONT></SPAN></DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
  size=2>-Vishal</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
    [mailto:[email-masked]]<B>On Behalf Of </B>zafar 
    ali<BR><B>Sent:</B> Monday, October 20, 2003 9:48 AM<BR><B>To:</B> 
    [email-masked]<BR><B>Cc:</B> 'zafar ali'; [email-masked]; 
    [email-masked]; 'Adrian Farrel'; 'Kireeti 
    Kompella'<BR><B>Subject:</B> Component Link Recording for TE Link Bundles 
    (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated) 
    <BR><BR></FONT></DIV>
    <DIV>
    <DIV><SPAN class=702311602-15102003><FONT face=Arial size=2>Dear&nbsp;<SPAN 
    class=822482913-20102003>C</SPAN>camp'ers:</FONT></SPAN></DIV>
    <DIV><SPAN class=702311602-15102003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=702311602-15102003>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial size=2>This 
    is a follow-up on our AI&nbsp;<SPAN class=822482913-20102003>from 
    last&nbsp;ccamp WG&nbsp;meeting </SPAN><SPAN class=822482913-20102003>on 
    the&nbsp;above-mentioned&nbsp;ID</SPAN>.&nbsp;We don&#8217;t think the crux of 
    this ID came across right, during the presentation and the follow-up 
    questions and answers. As Zafar mentioned during the ccamp wg meeting 
    discussions, this ID&nbsp;<SPAN class=822482913-20102003>mainly</SPAN> 
    address<SPAN class=822482913-20102003>es</SPAN> problem that exists in the 
    RRO. Specifically, when TE links are bundled, identification of label 
    resource in RRO is not enough for the administrative purpose. Network 
    service providers would like to know the component link that is being used 
    by a given the LSP. In other words, when link bundling is used, resource 
    recording requires mechanisms to specify the component link identifier, 
    along the TE link identifier and Label. </FONT></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
    size=2>&nbsp;</FONT></o:p></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
    size=2>In current specification, we cannot record component link selected by 
    an intermediate node in the RRO, which posses an administrative deficiency. 
    The ID mainly addresses this shortage by defining the extensions to RSVP-TE 
    to specify component link identifiers for resource recording in a network 
    containing TE link (a.k.a. link bundles)<SPAN 
    class=822482913-20102003>.</SPAN></FONT></FONT></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
    size=2>&nbsp;</FONT></o:p></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
    size=2>This is true that the ID also defines the ERO 
    counter-part.&nbsp;<SPAN class=822482913-20102003>I</SPAN>t seems from our 
    last meeting discussions that one shall try to maintain as symmetry between 
    the ERO and RRO definitions as much as possible<SPAN 
    class=822482913-20102003>. </SPAN>Nonetheless, the ERO definition also 
    addresses a current deficiency in the standard definition. Specifically, 
    explicit resource control for bi-directional LSP when forward and reverse 
    legs of the LSP are to follow different component links within a TE bundle 
    is not possible using current specification. <SPAN 
    style="mso-spacerun: yes">But for the time being, this is not the main 
    motivation behind this ID.</SPAN></FONT></FONT></P><SPAN 
    class=625492000-14102003>
    <P><FONT face=Arial size=2>We think that during the CCAMP WG 
    meeting</FONT></SPAN><FONT face=Arial size=2>, somehow everyone was 
    commenting on the practically of the ERO counterpart. But as&nbsp;<SPAN 
    class=625492000-14102003>Zafar</SPAN> also mentioned in the question answer 
    session that it is unfair to discuss merit and fate of this ID based 
    on&nbsp;<SPAN class=625492000-14102003>the </SPAN>ERO extensions<SPAN 
    class=625492000-14102003> contained herein</SPAN>. </FONT></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
    size=2>In the light of the above, we would like the WG to discuss the ID 
    based on its merit and applicably to resource recording in a network 
    containing bundled TE link. Clearly, the proposed RRO extensions are a 
    useful tool for administrative&nbsp;<SPAN class=822482913-20102003>purpose. 
    </SPAN></FONT></FONT></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p></o:p><FONT face=Arial 
    size=2>&nbsp;</FONT></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><SPAN 
    class=822482913-20102003><FONT face=Arial size=2>N.B. We have also updated 
    the ID, based on comments during&nbsp;last Ccamp WG meeting; An&nbsp;updated 
    copy will be available at IETF Web site in a couple of days. In the mean 
    time, a mirror version of the ID can be viewed at, </FONT><A 
    href="http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt"><U><FONT 
    face=Arial color=#000000 
    size=2>http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt</FONT></U></A><FONT 
    face=Arial size=2>.</FONT></P></SPAN></o:p>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p></o:p><FONT face=Arial 
    size=2>&nbsp;</FONT></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
    size=2>Comments<SPAN class=822482913-20102003> on usefulness on Component 
    Link Recording for TE Link Bundles will be very much appreciated. 
    </SPAN></FONT></FONT></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
    size=2></FONT></o:p>&nbsp;</P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
    size=2>Thanks</FONT></P>
    <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
    size=2>&nbsp;</FONT></o:p></P>
    <DIV 
    style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 1pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: windowtext 1pt solid; mso-border-bottom-alt: solid windowtext .75pt">
    <P class=MsoNormal 
    style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-bottom-alt: solid windowtext .75pt; mso-padding-alt: 0in 0in 1.0pt 0in"><FONT 
    color=#000080><FONT face=Arial><FONT size=2><FONT color=#000000>Regards&#8230; 
    Anca, Zafar and Dimitri.</FONT> 
    </FONT></FONT></FONT></P></DIV></SPAN></DIV></DIV>
    <DIV><FONT face=Arial color=#000080 size=2></FONT>&nbsp;</DIV>
    <DIV><FONT face=Arial 
    size=2>=====================================================================<BR>Zafar 
    Ali, Ph. D. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100 South Main St. 
    #200,<BR>Technical Leader, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ann Arbor, MI 
    48104, USA.<BR>Cisco Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (734) 
    276-2459.<BR>=====================================================================<BR></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_002E_01C398E0.A1B6E4C0--

Delivery-date: Thu, 23 Oct 2003 00:23:38 +0000
Date: Wed, 22 Oct 2003 20:21:27 -0400
From: Reshad Rahman <[email-masked]>
To: Nurit Sprecher <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: RSVP Graceful Restart

Nurit Sprecher wrote:

>Hi,
>I did not have the chance yet to read the draft, but I really believe there
>is a need to extend the general description in the GMPL document. 
>I hope that you new definition for the ERO recovery would help also to let
>the Ingress LER to recover.
>

Hi,

Yes, this will also let the ingress recover the ERO.

>
>One more thing that I would like to see in the extension, is how graceful
>restart works together with Fast Reroute Protection. Specifically the
>problematic points are the MP and the PLR. Do you have any intention to
>cover it as well?
>
Regarding GR + FRR, we currently believe that an informational section 
would be sufficient, i.e. no need for protocol extensions.

Regards,
Reshad.

>
>Thanks in advance, Nurit.
>  
>

Delivery-date: Wed, 22 Oct 2003 22:50:47 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt
Date: Wed, 22 Oct 2003 18:49:54 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Generalized MPLS Signaling for Layer-2 Label Switched 
			  Paths (LSP)
	Author(s)	: D. Papadimitriou, et. al.
	Filename	: draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt
	Pages		: 8
	Date		: 2003-10-22
	
Most efforts on Generalized MPLS (GMPLS) have been focused to
environments of single switching capability devices e.g. one data
plane layer covering either Packet LSPs or Circuit oriented LSPs
(Sonet/SDH, OTH, etc.). Relatively few have been said about the
GMPLS signaling capability to support Layer-2 Label Switched Paths
(LSPs), and in particular native Ethernet LSPs.

This document does not extend these capabilities but simply
details their utilization in several network environments including
overlays. As such, it may be referred to as detailing the
applicability statements for GMPLS for Ethernet switching
environments in support of various deployment scenarios, including
the peer model and the overlay model (e.g. Generalized VPN (GVPN)
and user-network interfaces).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-papadimitriou-ccamp-gmpls-l2sc-lsp-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-papadimitriou-ccamp-gmpls-l2sc-lsp-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-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-papadimitriou-ccamp-gmpls-l2sc-lsp-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: Wed, 22 Oct 2003 22:35:33 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "zafar ali" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: RE: Component Link Recording for TE Link Bundles (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated)  
Date: Wed, 22 Oct 2003 15:28:03 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C398B1.157CF550
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

MessageHi Zafar,

Thanks for your note. Although I've not had an opportunity yet to look at
the most
recent version of the document, I have read through the previous version,
and think
the idea of recording component link information in the RRO is useful in
several
contexts:

i) Disseminating the component link information to the edge nodes (and
provider
NMSs) can be very useful for restoration. E.g. when a failure that affects
only
a small subset of LSPs occurs (as opposed to a fiber cut or link failure
that
affects all LSPs in the bundle), it would be valuable to send the component
link info. in the Notify (or equivalent) message and have the end node(s)
recognize it
and take corrective action.

ii) By extension, it would be useful for a provider to know that a partial
failure
of the bundle has occurred, and to be able to identify which component has
failed.
This could be useful in on-line/off-line path selection and CSPF.

iii) I also think that the semantics defined to identify the component link
can be
useful in an of themselves, as they  may be usable by other
mechanisms/methods that
rely on disseminating component link failure info. to various nodes in the
network.

BTW, I'm not sure if you've seen Nic Neate's post on MPLS and CCAMP yet, but
it seems some of what you've proposed is related to or may partially address
what he's proposing (but I need to think a bit more carefully about that).

-Vishal
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of zafar ali
  Sent: Monday, October 20, 2003 9:48 AM
  To: [email-masked]
  Cc: 'zafar ali'; [email-masked]; [email-masked];
'Adrian Farrel'; 'Kireeti Kompella'
  Subject: Component Link Recording for TE Link Bundles
(draft-zamfir-explicit-resource-control-bundle-01.txt has been updated)

  Dear Ccamp'ers:

  This is a follow-up on our AI from last ccamp WG meeting on the
above-mentioned ID. We don't think the crux of this ID came across right,
during the presentation and the follow-up questions and answers. As Zafar
mentioned during the ccamp wg meeting discussions, this ID mainly addresses
problem that exists in the RRO. Specifically, when TE links are bundled,
identification of label resource in RRO is not enough for the administrative
purpose. Network service providers would like to know the component link
that is being used by a given the LSP. In other words, when link bundling is
used, resource recording requires mechanisms to specify the component link
identifier, along the TE link identifier and Label.

  In current specification, we cannot record component link selected by an
intermediate node in the RRO, which posses an administrative deficiency. The
ID mainly addresses this shortage by defining the extensions to RSVP-TE to
specify component link identifiers for resource recording in a network
containing TE link (a.k.a. link bundles).

  This is true that the ID also defines the ERO counter-part. It seems from
our last meeting discussions that one shall try to maintain as symmetry
between the ERO and RRO definitions as much as possible. Nonetheless, the
ERO definition also addresses a current deficiency in the standard
definition. Specifically, explicit resource control for bi-directional LSP
when forward and reverse legs of the LSP are to follow different component
links within a TE bundle is not possible using current specification. But
for the time being, this is not the main motivation behind this ID.

  We think that during the CCAMP WG meeting, somehow everyone was commenting
on the practically of the ERO counterpart. But as Zafar also mentioned in
the question answer session that it is unfair to discuss merit and fate of
this ID based on the ERO extensions contained herein.

  In the light of the above, we would like the WG to discuss the ID based on
its merit and applicably to resource recording in a network containing
bundled TE link. Clearly, the proposed RRO extensions are a useful tool for
administrative purpose.

  N.B. We have also updated the ID, based on comments during last Ccamp WG
meeting; An updated copy will be available at IETF Web site in a couple of
days. In the mean time, a mirror version of the ID can be viewed at,
http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle
-02.txt.

  Comments on usefulness on Component Link Recording for TE Link Bundles
will be very much appreciated.

  Thanks

  Regards. Anca, Zafar and Dimitri.

  ==================================  Zafar Ali, Ph. D.       100 South Main St. #200,
  Technical Leader,       Ann Arbor, MI 48104, USA.
  Cisco Systems.       (734) 276-2459.
  ==================================

------=_NextPart_000_0003_01C398B1.157CF550
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = 
"urn:schemas-microsoft-com:office:office"><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>Hi 
Zafar,</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>Thanks 
for your note. Although I've not had an opportunity yet to look at the 
most</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>recent 
version of the document, I have&nbsp;read through&nbsp;the previous version, and 
think</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>the 
idea of recording component link information in the RRO is useful in several 
</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2>contexts:</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>i) 
Disseminating the component link information to the edge nodes (and 
provider</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>NMSs) 
can be very useful for restoration. E.g. when a failure that affects 
only</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>a 
small subset of LSPs occurs (as opposed to a fiber cut or link failure 
that</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2>affects all LSPs in the bundle), it would be valuable to send the 
component</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>link 
info. in the Notify (or equivalent) message and have the end node(s) recognize 
it </FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>and 
</FONT></SPAN><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2>take corrective action.</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>ii) By 
extension, it would be useful for a provider to know that a partial 
failure</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>of the 
bundle has occurred, and to be able to identify which component has 
failed.</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>This 
could be useful in on-line/off-line path selection and CSPF.</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>iii) I 
also think that the semantics defined to identify the component link can 
be</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>useful 
in an of themselves, as&nbsp;they &nbsp;may be usable by other 
mechanisms/methods that</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>rely 
on disseminating component link failure info. to various nodes in the 
network.</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>BTW, 
I'm not sure if you've seen Nic Neate's post on MPLS and CCAMP yet, 
but</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>it 
seems some of what you've proposed is related to or may partially 
address</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff size=2>what 
he's proposing (but I need to think a bit more carefully about 
that).</FONT></SPAN></DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=898211822-22102003><FONT face=Arial color=#0000ff 
size=2>-Vishal</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
  [mailto:[email-masked]]<B>On Behalf Of </B>zafar ali<BR><B>Sent:</B> 
  Monday, October 20, 2003 9:48 AM<BR><B>To:</B> 
  [email-masked]<BR><B>Cc:</B> 'zafar ali'; [email-masked]; 
  [email-masked]; 'Adrian Farrel'; 'Kireeti 
  Kompella'<BR><B>Subject:</B> Component Link Recording for TE Link Bundles 
  (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated) 
  <BR><BR></FONT></DIV>
  <DIV>
  <DIV><SPAN class=702311602-15102003><FONT face=Arial size=2>Dear&nbsp;<SPAN 
  class=822482913-20102003>C</SPAN>camp'ers:</FONT></SPAN></DIV>
  <DIV><SPAN class=702311602-15102003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=702311602-15102003>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial size=2>This is 
  a follow-up on our AI&nbsp;<SPAN class=822482913-20102003>from last&nbsp;ccamp 
  WG&nbsp;meeting </SPAN><SPAN class=822482913-20102003>on 
  the&nbsp;above-mentioned&nbsp;ID</SPAN>.&nbsp;We don&#8217;t think the crux of this 
  ID came across right, during the presentation and the follow-up questions and 
  answers. As Zafar mentioned during the ccamp wg meeting discussions, this 
  ID&nbsp;<SPAN class=822482913-20102003>mainly</SPAN> address<SPAN 
  class=822482913-20102003>es</SPAN> problem that exists in the RRO. 
  Specifically, when TE links are bundled, identification of label resource in 
  RRO is not enough for the administrative purpose. Network service providers 
  would like to know the component link that is being used by a given the LSP. 
  In other words, when link bundling is used, resource recording requires 
  mechanisms to specify the component link identifier, along the TE link 
  identifier and Label. </FONT></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
  size=2>&nbsp;</FONT></o:p></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
  size=2>In current specification, we cannot record component link selected by 
  an intermediate node in the RRO, which posses an administrative deficiency. 
  The ID mainly addresses this shortage by defining the extensions to RSVP-TE to 
  specify component link identifiers for resource recording in a network 
  containing TE link (a.k.a. link bundles)<SPAN 
  class=822482913-20102003>.</SPAN></FONT></FONT></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
  size=2>&nbsp;</FONT></o:p></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
  size=2>This is true that the ID also defines the ERO counter-part.&nbsp;<SPAN 
  class=822482913-20102003>I</SPAN>t seems from our last meeting discussions 
  that one shall try to maintain as symmetry between the ERO and RRO definitions 
  as much as possible<SPAN class=822482913-20102003>. </SPAN>Nonetheless, the 
  ERO definition also addresses a current deficiency in the standard definition. 
  Specifically, explicit resource control for bi-directional LSP when forward 
  and reverse legs of the LSP are to follow different component links within a 
  TE bundle is not possible using current specification. <SPAN 
  style="mso-spacerun: yes">But for the time being, this is not the main 
  motivation behind this ID.</SPAN></FONT></FONT></P><SPAN 
  class=625492000-14102003>
  <P><FONT face=Arial size=2>We think that during the CCAMP WG 
  meeting</FONT></SPAN><FONT face=Arial size=2>, somehow everyone was commenting 
  on the practically of the ERO counterpart. But as&nbsp;<SPAN 
  class=625492000-14102003>Zafar</SPAN> also mentioned in the question answer 
  session that it is unfair to discuss merit and fate of this ID based 
  on&nbsp;<SPAN class=625492000-14102003>the </SPAN>ERO extensions<SPAN 
  class=625492000-14102003> contained herein</SPAN>. </FONT></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
  size=2>In the light of the above, we would like the WG to discuss the ID based 
  on its merit and applicably to resource recording in a network containing 
  bundled TE link. Clearly, the proposed RRO extensions are a useful tool for 
  administrative&nbsp;<SPAN class=822482913-20102003>purpose. 
  </SPAN></FONT></FONT></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p></o:p><FONT face=Arial 
  size=2>&nbsp;</FONT></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><SPAN 
  class=822482913-20102003><FONT face=Arial size=2>N.B. We have also updated the 
  ID, based on comments during&nbsp;last Ccamp WG meeting; An&nbsp;updated copy 
  will be available at IETF Web site in a couple of days. In the mean time, a 
  mirror version of the ID can be viewed at, </FONT><A 
  href="http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt"><U><FONT 
  face=Arial color=#000000 
  size=2>http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt</FONT></U></A><FONT 
  face=Arial size=2>.</FONT></P></SPAN></o:p>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p></o:p><FONT face=Arial 
  size=2>&nbsp;</FONT></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
  size=2>Comments<SPAN class=822482913-20102003> on usefulness on Component Link 
  Recording for TE Link Bundles will be very much appreciated. 
  </SPAN></FONT></FONT></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
  size=2></FONT></o:p>&nbsp;</P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
  size=2>Thanks</FONT></P>
  <P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
  size=2>&nbsp;</FONT></o:p></P>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 1pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: windowtext 1pt solid; mso-border-bottom-alt: solid windowtext .75pt">
  <P class=MsoNormal 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-bottom-alt: solid windowtext .75pt; mso-padding-alt: 0in 0in 1.0pt 0in"><FONT 
  color=#000080><FONT face=Arial><FONT size=2><FONT color=#000000>Regards&#8230; Anca, 
  Zafar and Dimitri.</FONT> </FONT></FONT></FONT></P></DIV></SPAN></DIV></DIV>
  <DIV><FONT face=Arial color=#000080 size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial 
  size=2>=====================================================================<BR>Zafar 
  Ali, Ph. D. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100 South Main St. 
  #200,<BR>Technical Leader, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ann Arbor, MI 48104, 
  USA.<BR>Cisco Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (734) 
  276-2459.<BR>=====================================================================<BR></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0003_01C398B1.157CF550--

Delivery-date: Wed, 22 Oct 2003 09:45:14 +0000
From: Nurit Sprecher <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RSVP Graceful Restart
Date: Wed, 22 Oct 2003 11:42:40 +0200

Hi,
I did not have the chance yet to read the draft, but I really believe there
is a need to extend the general description in the GMPL document. 
I hope that you new definition for the ERO recovery would help also to let
the Ingress LER to recover.

One more thing that I would like to see in the extension, is how graceful
restart works together with Fast Reroute Protection. Specifically the
problematic points are the MP and the PLR. Do you have any intention to
cover it as well?

Thanks in advance, Nurit.

Delivery-date: Wed, 22 Oct 2003 00:14:21 +0000
content-class: urn:content-classes:message
Subject: re: draft-ietf-ccamp-gmpls-recovery-terminology-02.txt
Date: Tue, 21 Oct 2003 17:10:48 -0700
From: "Vikram Anantha" <[email-masked]>
To: <[email-masked]>

I was wondering if Selectors, Bridges and other types of "Adaptation
Functions" as mentioned in the above draft are considered as components
of a LSP.

Thx

Vik

<MANDATORY CORPORATE DISCLAIMER>
This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply email and
destroy all copies of the original message. Elematics, Inc.
http://www.elematics.com
</MANDATORY CORPORATE DISCLAIMER>

Delivery-date: Tue, 21 Oct 2003 20:02:56 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ong-ccamp-3473-3474-iw-00.txt
Date: Tue, 21 Oct 2003 15:58:43 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Interworking of RFC 3473 and 3474
	Author(s)	: L. Ong, et. al.
	Filename	: draft-ong-ccamp-3473-3474-iw-00.txt
	Pages		: 5
	Date		: 2003-10-21
	
This document defines interworking procedures between [RFC 3473]
(Generalized MPLS (GMPLS) RSVP-TE) and [RFC 3474] (GMPLS RSVP-TE 
Usage and Extensions for ASON) signaling. RFC 3474 extensions
are used in ITU-T Recommendation [G.7713.2].  Two basic interworking 
scenarios are discussed. 

RFC 3474 was intended to use the same basic mechanisms as and
to be backwards compatible to RFC 3473.  Some objects in 3474
are carried transparently over an RFC 3473 network, in
accordance with RSVP procedures for unrecognized objects.
Other objects must be mapped or generated at the interworking
point.

The mechanisms described in this document are applicable to
any types of interfaces common to RFC 3473 and Recommendation 
G.7713.2, esp. time-division multiplexed, lambda or
fiber switching interfaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ong-ccamp-3473-3474-iw-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ong-ccamp-3473-3474-iw-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-ong-ccamp-3473-3474-iw-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-ong-ccamp-3473-3474-iw-00.txt

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

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

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Tue, 21 Oct 2003 14:49:26 +0000
Message-Id: <[email-masked]>
From: The IESG <[email-masked]>
To: IETF-Announce: ;
Cc: Kireeti Kompella <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: WG Action: RECHARTER: Common Control and Measurement Plane (ccamp)
Date: Tue, 21 Oct 2003 10:45:04 -0400

The Common Control and Measurement Plane (ccamp) working group in the Routing 
Area of the IETF has been rechartered.  For additional information, 
please contact the Area Directors or the working group Chairs.

With this announcement, the Common Control and Measurement Plane (ccamp) WG 
is moved to the Routing Area with Alex Zinin as the responsible area director.

Common Control and Measurement Plane (ccamp)
--------------------------------------------

Current Status: Active Working Group

Chair(s):

Kireeti Kompella <[email-masked]>
Adrian Farrel <[email-masked]>

Routing Area Director(s):

Bill Fenner <[email-masked]>
Alex Zinin <[email-masked]>

Routing Area Advisor:

Alex Zinin <[email-masked]>

Technical Advisor(s):

Alex Zinin <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: subscribe ccamp
Archive: http://ops.ietf.org/lists/ccamp

Description of Working Group:

Organizational Overview

The CCAMP working group coordinates the work within the IETF defining
a common control plane and a separate common measurement plane for
physical path and core tunneling technologies of Internet and telecom
service providers (ISPs and SPs), e.g. O-O and O-E-O optical
switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
with the MPLS WG. In this context, measurement refers to the
acquisition and distribution of attributes relevant to the setting up
of tunnels and paths.

CCAMP WG work scope includes:

- Definition of protocol-independent metrics and parameters
  (measurement attributes) for describing links and paths that are
  required for routing and signaling. These will be developed in
  conjunction with requests and requirements from other WGs (e.g.
  TEWG) to insure overall usefulness.

- Definition of protocol(s) and extensions to them required for
  link and path attribute measurement. Link Management Protocol (LMP)
  is included here.

- Functional specification of extensions for routing (OSPF, ISIS) and
  signalling (RSVP-TE) required for path establishment. Protocol 
  formats and procedures that embody these extensions will be done
  jointly with the WGs supervising those protocols.

- Definition of the mechanisms required to determine the route and
  properties of an established path (tunnel tracing).

- Definition of MIB modules relevant to the protocols and extensions
  specified within the WG.

CCAMP WG currently works on the following tasks:

- Define how the properties of network resources gathered by a
  measurement protocol can be distributed in existing routing
  protocols, such as OSPF and IS-IS. CCAMP defines the generic
  description of the properties and how they are distributed in OSPF.
  The specifics of distribution within IS-IS are being addressed in
  the ISIS WG.

- Define signaling and routing mechanisms to make possible the creation
  of paths that span multiple IGP areas, multiple ASes, and multiple
  providers, including techniques for crankback.

- Define abstract link and path properties needed for link and path
  protection. Specify signalling mechanisms for path protection,
  diverse routing and fast path restoration. Ensure that multi-layer
  path protection and restoration functions are achievable using the
  defined signalling, routing, and measurement protocols, either
  separately or in combination.

- Identify which requirements for signaling and routing for ASON are
  not currently met by protocols defined in CCAMP; based on these,
  define mechanisms to address these requirements.

- Define a protocol that can determine the actual route and other
  properties of paths set up by CCAMP signaling protocols, as well
  as other types of tunnels (tunnel tracing).

In doing this work, the WG will work closely with at least the 
following other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate 
with ITU-T.

Goals and Milestones:
Done Post strawman WG goals and charter
Done Identify and document a limited set of candidate solutions for signalling
        and for measurement. Among candidate control solutions to be considered 
        are the existing GMPLS drafts
Done Build appropriate design teams
Done Submit WG document defining path setup portions of common control plane 
        protocol
Done Submit WG document defining common measurement plane protocol
Nov 03 Submit LMP MIB to IESG
Dec 03 Submit GMPLS MIBs to IESG
Dec 03 Submit protection & restoration documents to IESG
Dec 03 Submit ASON signaling requirements doc to IESG
Jan 04 Produce CCAMP WG document for multi-area/AS signaling and routing
Jan 04 Produce CCAMP WG document for generic tunnel tracing protocol
Jan 04 Submit ASON routing requirements doc to IESG
Mar 04 Submit revised charter and milestones to IESG for IESG consideration of
          more detailed deliverables and determination of usefulness of 
          continuation of WG

Delivery-date: Mon, 20 Oct 2003 16:53:13 +0000
From: "zafar ali" <[email-masked]>
To: <[email-masked]>
Cc: "'zafar ali'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Component Link Recording for TE Link Bundles (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated)  
Date: Mon, 20 Oct 2003 12:48:17 -0400
Organization: Cisco Systems

This is a multi-part message in MIME format.

------=_NextPart_000_007C_01C39708.7077D560
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Ccamp'ers:
 
This is a follow-up on our AI from last ccamp WG meeting on the
above-mentioned ID. We don't think the crux of this ID came across
right, during the presentation and the follow-up questions and answers.
As Zafar mentioned during the ccamp wg meeting discussions, this ID
mainly addresses problem that exists in the RRO. Specifically, when TE
links are bundled, identification of label resource in RRO is not enough
for the administrative purpose. Network service providers would like to
know the component link that is being used by a given the LSP. In other
words, when link bundling is used, resource recording requires
mechanisms to specify the component link identifier, along the TE link
identifier and Label. 

In current specification, we cannot record component link selected by an
intermediate node in the RRO, which posses an administrative deficiency.
The ID mainly addresses this shortage by defining the extensions to
RSVP-TE to specify component link identifiers for resource recording in
a network containing TE link (a.k.a. link bundles).

This is true that the ID also defines the ERO counter-part. It seems
from our last meeting discussions that one shall try to maintain as
symmetry between the ERO and RRO definitions as much as possible.
Nonetheless, the ERO definition also addresses a current deficiency in
the standard definition. Specifically, explicit resource control for
bi-directional LSP when forward and reverse legs of the LSP are to
follow different component links within a TE bundle is not possible
using current specification. But for the time being, this is not the
main motivation behind this ID.

We think that during the CCAMP WG meeting, somehow everyone was
commenting on the practically of the ERO counterpart. But as Zafar also
mentioned in the question answer session that it is unfair to discuss
merit and fate of this ID based on the ERO extensions contained herein. 

In the light of the above, we would like the WG to discuss the ID based
on its merit and applicably to resource recording in a network
containing bundled TE link. Clearly, the proposed RRO extensions are a
useful tool for administrative purpose. 

N.B. We have also updated the ID, based on comments during last Ccamp WG
meeting; An updated copy will be available at IETF Web site in a couple
of days. In the mean time, a mirror version of the ID can be viewed at,
<http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-b
undle-02.txt>
http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bu
ndle-02.txt.

Comments on usefulness on Component Link Recording for TE Link Bundles
will be very much appreciated. 

Thanks

Regards. Anca, Zafar and Dimitri. 

==================================Zafar Ali, Ph. D.       100 South Main St. #200,
Technical Leader,       Ann Arbor, MI 48104, USA.
Cisco Systems.       (734) 276-2459.
==================================

------=_NextPart_000_007C_01C39708.7077D560
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = 
"urn:schemas-microsoft-com:office:office"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1264" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV><SPAN class=702311602-15102003><FONT face=Arial size=2>Dear&nbsp;<SPAN 
class=822482913-20102003>C</SPAN>camp'ers:</FONT></SPAN></DIV>
<DIV><SPAN class=702311602-15102003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=702311602-15102003>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial size=2>This is a 
follow-up on our AI&nbsp;<SPAN class=822482913-20102003>from last&nbsp;ccamp 
WG&nbsp;meeting </SPAN><SPAN class=822482913-20102003>on 
the&nbsp;above-mentioned&nbsp;ID</SPAN>.&nbsp;We don&#8217;t think the crux of this ID 
came across right, during the presentation and the follow-up questions and 
answers. As Zafar mentioned during the ccamp wg meeting discussions, this 
ID&nbsp;<SPAN class=822482913-20102003>mainly</SPAN> address<SPAN 
class=822482913-20102003>es</SPAN> problem that exists in the RRO. Specifically, 
when TE links are bundled, identification of label resource in RRO is not enough 
for the administrative purpose. Network service providers would like to know the 
component link that is being used by a given the LSP. In other words, when link 
bundling is used, resource recording requires mechanisms to specify the 
component link identifier, along the TE link identifier and Label. </FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
size=2>&nbsp;</FONT></o:p></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT size=2>In 
current specification, we cannot record component link selected by an 
intermediate node in the RRO, which posses an administrative deficiency. The ID 
mainly addresses this shortage by defining the extensions to RSVP-TE to specify 
component link identifiers for resource recording in a network containing TE 
link (a.k.a. link bundles)<SPAN 
class=822482913-20102003>.</SPAN></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
size=2>&nbsp;</FONT></o:p></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
size=2>This is true that the ID also defines the ERO counter-part.&nbsp;<SPAN 
class=822482913-20102003>I</SPAN>t seems from our last meeting discussions that 
one shall try to maintain as symmetry between the ERO and RRO definitions as 
much as possible<SPAN class=822482913-20102003>. </SPAN>Nonetheless, the ERO 
definition also addresses a current deficiency in the standard definition. 
Specifically, explicit resource control for bi-directional LSP when forward and 
reverse legs of the LSP are to follow different component links within a TE 
bundle is not possible using current specification. <SPAN 
style="mso-spacerun: yes">But for the time being, this is not the main 
motivation behind this ID.</SPAN></FONT></FONT></P><SPAN 
class=625492000-14102003>
<P><FONT face=Arial size=2>We think that during the CCAMP WG 
meeting</FONT></SPAN><FONT face=Arial size=2>, somehow everyone was commenting 
on the practically of the ERO counterpart. But as&nbsp;<SPAN 
class=625492000-14102003>Zafar</SPAN> also mentioned in the question answer 
session that it is unfair to discuss merit and fate of this ID based 
on&nbsp;<SPAN class=625492000-14102003>the </SPAN>ERO extensions<SPAN 
class=625492000-14102003> contained herein</SPAN>. </FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT size=2>In 
the light of the above, we would like the WG to discuss the ID based on its 
merit and applicably to resource recording in a network containing bundled TE 
link. Clearly, the proposed RRO extensions are a useful tool for 
administrative&nbsp;<SPAN class=822482913-20102003>purpose. 
</SPAN></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p></o:p><FONT face=Arial 
size=2>&nbsp;</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><SPAN 
class=822482913-20102003><FONT face=Arial size=2>N.B. We have also updated the 
ID, based on comments during&nbsp;last Ccamp WG meeting; An&nbsp;updated copy 
will be available at IETF Web site in a couple of days. In the mean time, a 
mirror version of the ID can be viewed at, </FONT><A 
href="http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt"><U><FONT 
face=Arial color=#000000 
size=2>http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt</FONT></U></A><FONT 
face=Arial size=2>.</FONT></P></SPAN></o:p>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p></o:p><FONT face=Arial 
size=2>&nbsp;</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial><FONT 
size=2>Comments<SPAN class=822482913-20102003> on usefulness on Component Link 
Recording for TE Link Bundles will be very much appreciated. 
</SPAN></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
size=2></FONT></o:p>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face=Arial 
size=2>Thanks</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face=Arial 
size=2>&nbsp;</FONT></o:p></P>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 1pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: windowtext 1pt solid; mso-border-bottom-alt: solid windowtext .75pt">
<P class=MsoNormal 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-bottom-alt: solid windowtext .75pt; mso-padding-alt: 0in 0in 1.0pt 0in"><FONT 
color=#000080><FONT face=Arial><FONT size=2><FONT color=#000000>Regards&#8230; Anca, 
Zafar and Dimitri.</FONT> </FONT></FONT></FONT></P></DIV></SPAN></DIV></DIV>
<DIV><FONT face=Arial color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial 
size=2>=====================================================================<BR>Zafar 
Ali, Ph. D. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100 South Main St. #200,<BR>Technical 
Leader, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ann Arbor, MI 48104, USA.<BR>Cisco 
Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (734) 
276-2459.<BR>=====================================================================<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_007C_01C39708.7077D560--

Delivery-date: Sat, 18 Oct 2003 06:59:28 +0000
Date: Fri, 17 Oct 2003 23:51:21 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Vishal Sharma <[email-masked]>
cc: "Brungard, Deborah A" <[email-masked]>, [email-masked]
Subject: RE: ITU Liaison regarding ASON Requirements Design Team

Hi Vishal,

On Fri, 17 Oct 2003, Vishal Sharma wrote:

> Hi Kireeti,
>
> Just a note to clarify that my comment was neither aimed
> at revisiting the charter of the DT, nor was it aimed at
> dictating what the ITU-T should do.
>
> And, at least I wasn't proposing any change to the wording
> of the liason statement -- merely making sure I correctly
> understood it's intent.
>
> As I mentioned in my reply to Lyndon, my query was well answered
> by Lyndon's response to it.

Great, we're all on the same page.  Thanks, Vishal and Lyndon!

Kireeti.

> -Vishal
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Kireeti Kompella
> > Sent: Friday, October 17, 2003 9:45 PM
> > To: Brungard, Deborah A
> > Cc: [email-masked]
> > Subject: RE: ITU Liaison regarding ASON Requirements Design Team
> >
> >
> > Hi Deborah, All:
> >
> > On Fri, 17 Oct 2003, Brungard, Deborah A wrote:
> >
> > > Thanks for your review. As your comment and Adrian's are related to
> > > the text of the charter itself which preceded the DT, I will concede
> > > to our Chairs for decision;-)
> >
> > The time for commenting on and tweaking the DT charter has long past.
> > I think the proposed changes, while fine, are semantic twiddling.  It
> > wouldn't be fair to the DT to spend an unbounded time revisiting their
> > charter.
> >
> > Given that the DT charter is what it is, I think the Liaison should
> > reflect that.
> >
> > Note that the ITU-T knows better than we do whether the work on ASON
> > routing requirements is done or not.  We cannot dictate that to them.
> >
> > Kireeti.

Delivery-date: Sat, 18 Oct 2003 06:48:52 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Brungard, Deborah A" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: ITU Liaison regarding ASON Requirements Design Team
Date: Fri, 17 Oct 2003 23:43:43 -0700

Hi Kireeti,

Just a note to clarify that my comment was neither aimed
at revisiting the charter of the DT, nor was it aimed at
dictating what the ITU-T should do.

And, at least I wasn't proposing any change to the wording 
of the liason statement -- merely making sure I correctly 
understood it's intent.

As I mentioned in my reply to Lyndon, my query was well answered 
by Lyndon's response to it.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Friday, October 17, 2003 9:45 PM
> To: Brungard, Deborah A
> Cc: [email-masked]
> Subject: RE: ITU Liaison regarding ASON Requirements Design Team
> 
> 
> Hi Deborah, All:
> 
> On Fri, 17 Oct 2003, Brungard, Deborah A wrote:
> 
> > Thanks for your review. As your comment and Adrian's are related to
> > the text of the charter itself which preceded the DT, I will concede
> > to our Chairs for decision;-)
> 
> The time for commenting on and tweaking the DT charter has long past.
> I think the proposed changes, while fine, are semantic twiddling.  It
> wouldn't be fair to the DT to spend an unbounded time revisiting their
> charter.
> 
> Given that the DT charter is what it is, I think the Liaison should
> reflect that.
> 
> Note that the ITU-T knows better than we do whether the work on ASON
> routing requirements is done or not.  We cannot dictate that to them.
> 
> Kireeti.
> 

Delivery-date: Sat, 18 Oct 2003 04:56:20 +0000
Date: Fri, 17 Oct 2003 21:44:41 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: "Brungard, Deborah A" <[email-masked]>
cc: [email-masked]
Subject: RE: ITU Liaison regarding ASON Requirements Design Team

Hi Deborah, All:

On Fri, 17 Oct 2003, Brungard, Deborah A wrote:

> Thanks for your review. As your comment and Adrian's are related to
> the text of the charter itself which preceded the DT, I will concede
> to our Chairs for decision;-)

The time for commenting on and tweaking the DT charter has long past.
I think the proposed changes, while fine, are semantic twiddling.  It
wouldn't be fair to the DT to spend an unbounded time revisiting their
charter.

Given that the DT charter is what it is, I think the Liaison should
reflect that.

Note that the ITU-T knows better than we do whether the work on ASON
routing requirements is done or not.  We cannot dictate that to them.

Kireeti.

Delivery-date: Sat, 18 Oct 2003 01:05:14 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, "Brungard, Deborah A" <[email-masked]>, <[email-masked]>
Subject: RE: ITU Liaison regarding ASON Requirements Design Team
Date: Fri, 17 Oct 2003 18:00:19 -0700

Hi Lyndon,

Thanks for the clarifications. I think you've answered
the question I had (comments in-line).

Regards,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Ong, Lyndon
> Sent: Friday, October 17, 2003 2:28 PM
> To: [email-masked]'; Brungard, Deborah A; [email-masked]
> Subject: RE: ITU Liaison regarding ASON Requirements Design Team
> 
> 
> Hi Vishal,
> 
> I think you can interpret the statement in a couple of ways:
> -- first as a guideline to the Design Team to work based on
> the routing requirements defined in Question 12 and 14 and
> resist the temptation to insert new ones

Agreed, this is what I understood.

> -- second as a recognition that the work is in fact still in
> progress at ITU - G.8080 and G.7715 are approved but other
> specifications and amendments (for example, G.7715.1) may
> affect this that are not yet complete.  G.7715.1 is scheduled
> for consent at this October meeting of SG 15 providing that
> it is ready for approval.  If 7715.1 (requirements
> for link state routing) is not ready I would hope that the
> design team should continue refining its conclusions as the
> work in ITU proceeds.  

Great, thanks. This is the part I wasn't so clear about. I now
understand the the SG15 output itself is evolving (even
though some big portions are largely decided), and that
the ASON DT will be tracking it.

> 
> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Thursday, October 16, 2003 6:41 PM
> To: Brungard, Deborah A; [email-masked]
> Subject: RE: ITU Liaison regarding ASON Requirements Design Team
> 
> 
> Deborah,
> 
> The liason statement looks good. 
> 
> A quick clarification, however.
> 
> The statement reads:
> "... no requirement will be considered in this document that is not 
> an ASON routing requirement (as decided by those working on 
> Questions 12 and 14 of Study Group 15)."
> 
> The parenthetical phrase above seems to suggest that the 
> ASON routing requirements within the ITU-T are themselves not fully 
> finalized yet.
> 
> Is there some doubt about what the exact ASON routing requirements
> are? And, are they not clearly specified and agreed to by SG15 yet. 
> 
> If so, how does the DT hope to make its recommendations?
> 
> Thanks,
> -Vishal 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Brungard, Deborah A
> > Sent: Wednesday, October 15, 2003 1:22 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: ITU Liaison regarding ASON Requirements Design Team
> > 
> > 
> > CCAMP,
> > 
> > The design team proposes the following ITU-T liaison on the 
> > creation of the ASON Routing Requirements DT and it's charter. We 
> > would like to request consensus from CCAMP for forwarding this 
> > liaison to ITU-T SG15. The next meeting of SG15 is Oct. 21-31. We 
> > would like to request comments by October 21 to allow for this 
> > liaison to be forwarded next week to SG15 (cc to Q12/15 
> > Rapporteur, Malcolm Betts, [email-masked] and Q14/15 
> > Rapporteur, Kam Lam, [email-masked]).
> > 
> > Thanks,
> > Deborah
> > 
> > ------------------------------------------------------------------
> > -------------------------------------
> > We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has 
> > initiated a Design Team on GMPLS ASON Routing Requirements. The 
> > GMPLS ASON Routing Requirements Design Team's Charter is as follows:
> > 
> > "To understand the requirements for ASON routing so as to capture 
> > what's missing from current CCAMP work in a "GMPLS ASON Routing 
> > Requirements" document.  The ground rules are the same as for 
> > ASON signaling requirements: no requirement will be considered in 
> > this document that is not an ASON routing requirement (as decided 
> > by those working on Questions 12 and 14 of Study Group 15).  
> > Requirements should be justified briefly and prioritized. If 
> > needed, a section on terminology should be included. No attempt 
> > should be made in this document to do protocol design or suggest 
> > protocol extensions."
> > 
> > We expect to liaison to you a draft of the above WG document 
> > during Nov. 2003. We wish to work with you cooperatively on this 
> > document and we would appreciate your assistance in reviewing 
> this draft.
> > 
> > 
> > 
> > 
> 
> 
> 

Delivery-date: Fri, 17 Oct 2003 21:30:52 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Brungard, Deborah A" <[email-masked]>, [email-masked]
Subject: RE: ITU Liaison regarding ASON Requirements Design Team
Date: Fri, 17 Oct 2003 14:27:59 -0700

Hi Vishal,

I think you can interpret the statement in a couple of ways:
-- first as a guideline to the Design Team to work based on
the routing requirements defined in Question 12 and 14 and
resist the temptation to insert new ones
-- second as a recognition that the work is in fact still in
progress at ITU - G.8080 and G.7715 are approved but other
specifications and amendments (for example, G.7715.1) may
affect this that are not yet complete.  G.7715.1 is scheduled
for consent at this October meeting of SG 15 providing that
it is ready for approval.  If 7715.1 (requirements
for link state routing) is not ready I would hope that the
design team should continue refining its conclusions as the
work in ITU proceeds.  

Cheers,

Lyndon

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Thursday, October 16, 2003 6:41 PM
To: Brungard, Deborah A; [email-masked]
Subject: RE: ITU Liaison regarding ASON Requirements Design Team

Deborah,

The liason statement looks good. 

A quick clarification, however.

The statement reads:
"... no requirement will be considered in this document that is not 
an ASON routing requirement (as decided by those working on 
Questions 12 and 14 of Study Group 15)."

The parenthetical phrase above seems to suggest that the 
ASON routing requirements within the ITU-T are themselves not fully 
finalized yet.

Is there some doubt about what the exact ASON routing requirements
are? And, are they not clearly specified and agreed to by SG15 yet. 

If so, how does the DT hope to make its recommendations?

Thanks,
-Vishal 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brungard, Deborah A
> Sent: Wednesday, October 15, 2003 1:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: ITU Liaison regarding ASON Requirements Design Team
> 
> 
> CCAMP,
> 
> The design team proposes the following ITU-T liaison on the 
> creation of the ASON Routing Requirements DT and it's charter. We 
> would like to request consensus from CCAMP for forwarding this 
> liaison to ITU-T SG15. The next meeting of SG15 is Oct. 21-31. We 
> would like to request comments by October 21 to allow for this 
> liaison to be forwarded next week to SG15 (cc to Q12/15 
> Rapporteur, Malcolm Betts, [email-masked] and Q14/15 
> Rapporteur, Kam Lam, [email-masked]).
> 
> Thanks,
> Deborah
> 
> ------------------------------------------------------------------
> -------------------------------------
> We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has 
> initiated a Design Team on GMPLS ASON Routing Requirements. The 
> GMPLS ASON Routing Requirements Design Team's Charter is as follows:
> 
> "To understand the requirements for ASON routing so as to capture 
> what's missing from current CCAMP work in a "GMPLS ASON Routing 
> Requirements" document.  The ground rules are the same as for 
> ASON signaling requirements: no requirement will be considered in 
> this document that is not an ASON routing requirement (as decided 
> by those working on Questions 12 and 14 of Study Group 15).  
> Requirements should be justified briefly and prioritized. If 
> needed, a section on terminology should be included. No attempt 
> should be made in this document to do protocol design or suggest 
> protocol extensions."
> 
> We expect to liaison to you a draft of the above WG document 
> during Nov. 2003. We wish to work with you cooperatively on this 
> document and we would appreciate your assistance in reviewing this draft.
> 
> 
> 
> 

Delivery-date: Fri, 17 Oct 2003 19:36:35 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
Date: Fri, 17 Oct 2003 15:32:56 -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		: OSPF Extensions in Support of Generalized 
			  Multi-Protocol Label Switching
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
	Pages		: 12
	Date		: 2003-10-17
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ospf-gmpls-extensions-12.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-ospf-gmpls-extensions-12.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-ospf-gmpls-extensions-12.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-ospf-gmpls-extensions-12.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, 17 Oct 2003 19:36:04 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-09.txt
Date: Fri, 17 Oct 2003 15:33:06 -0400

--NextPart

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

	Title		: Routing Extensions in Support of Generalized 
         		  Multi-Protocol Label Switching
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-gmpls-routing-09.txt
	Pages		: 25
	Date		: 2003-10-17
	
This document specifies routing extensions in support of carrying
link state information for Generalized Multi-Protocol Label Switching
(GMPLS).  This document enhances the routing extensions required to
support MPLS Traffic Engineering (TE).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-routing-09.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-09.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 17 Oct 2003 15:02:01 +0000
Content-Class: urn:content-classes:message
Subject: RE: ITU Liaison regarding ASON Requirements Design Team
Date: Fri, 17 Oct 2003 08:00:34 -0700
From: "Jonathan Lang" <[email-masked]>
To: "Brungard, Deborah A" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Deborah,
  Looks good to me.

Thanks,
Jonathan

> -----Original Message-----
> From: Brungard, Deborah A [mailto:[email-masked]] 
> Sent: Wednesday, October 15, 2003 1:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: ITU Liaison regarding ASON Requirements Design Team
> 
> 
> CCAMP,
> 
> The design team proposes the following ITU-T liaison on the 
> creation of the ASON Routing Requirements DT and it's 
> charter. We would like to request consensus from CCAMP for 
> forwarding this liaison to ITU-T SG15. The next meeting of 
> SG15 is Oct. 21-31. We would like to request comments by 
> October 21 to allow for this liaison to be forwarded next 
> week to SG15 (cc to Q12/15 Rapporteur, Malcolm Betts, 
> [email-masked] and Q14/15 Rapporteur, Kam Lam, 
> [email-masked]).
> 
> Thanks,
> Deborah
> 
> --------------------------------------------------------------
> -----------------------------------------
> We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG 
> has initiated a Design Team on GMPLS ASON Routing 
> Requirements. The GMPLS ASON Routing Requirements Design 
> Team's Charter is as follows:
> 
> "To understand the requirements for ASON routing so as to 
> capture what's missing from current CCAMP work in a "GMPLS 
> ASON Routing Requirements" document.  The ground rules are 
> the same as for ASON signaling requirements: no requirement 
> will be considered in this document that is not an ASON 
> routing requirement (as decided by those working on Questions 
> 12 and 14 of Study Group 15).  Requirements should be 
> justified briefly and prioritized. If needed, a section on 
> terminology should be included. No attempt should be made in 
> this document to do protocol design or suggest protocol extensions."
> 
> We expect to liaison to you a draft of the above WG document 
> during Nov. 2003. We wish to work with you cooperatively on 
> this document and we would appreciate your assistance in 
> reviewing this draft.
> 
> 
> 
> 
> 

Delivery-date: Fri, 17 Oct 2003 14:06:55 +0000
content-class: urn:content-classes:message
Subject: RE: ITU Liaison regarding ASON Requirements Design Team
Date: Fri, 17 Oct 2003 09:04:14 -0500
From: "Brungard, Deborah A" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Vishal,

Thanks for your review. As your comment and Adrian's are related to the text of the charter itself which preceded the DT, I will concede to our Chairs for decision;-)
Deborah

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Thursday, October 16, 2003 9:41 PM
To: Brungard, Deborah A; [email-masked]
Subject: RE: ITU Liaison regarding ASON Requirements Design Team

Deborah,

The liason statement looks good. 

A quick clarification, however.

The statement reads:
"... no requirement will be considered in this document that is not 
an ASON routing requirement (as decided by those working on 
Questions 12 and 14 of Study Group 15)."

The parenthetical phrase above seems to suggest that the 
ASON routing requirements within the ITU-T are themselves not fully 
finalized yet.

Is there some doubt about what the exact ASON routing requirements
are? And, are they not clearly specified and agreed to by SG15 yet. 

If so, how does the DT hope to make its recommendations?

Thanks,
-Vishal 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brungard, Deborah A
> Sent: Wednesday, October 15, 2003 1:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: ITU Liaison regarding ASON Requirements Design Team
> 
> 
> CCAMP,
> 
> The design team proposes the following ITU-T liaison on the 
> creation of the ASON Routing Requirements DT and it's charter. We 
> would like to request consensus from CCAMP for forwarding this 
> liaison to ITU-T SG15. The next meeting of SG15 is Oct. 21-31. We 
> would like to request comments by October 21 to allow for this 
> liaison to be forwarded next week to SG15 (cc to Q12/15 
> Rapporteur, Malcolm Betts, [email-masked] and Q14/15 
> Rapporteur, Kam Lam, [email-masked]).
> 
> Thanks,
> Deborah
> 
> ------------------------------------------------------------------
> -------------------------------------
> We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has 
> initiated a Design Team on GMPLS ASON Routing Requirements. The 
> GMPLS ASON Routing Requirements Design Team's Charter is as follows:
> 
> "To understand the requirements for ASON routing so as to capture 
> what's missing from current CCAMP work in a "GMPLS ASON Routing 
> Requirements" document.  The ground rules are the same as for 
> ASON signaling requirements: no requirement will be considered in 
> this document that is not an ASON routing requirement (as decided 
> by those working on Questions 12 and 14 of Study Group 15).  
> Requirements should be justified briefly and prioritized. If 
> needed, a section on terminology should be included. No attempt 
> should be made in this document to do protocol design or suggest 
> protocol extensions."
> 
> We expect to liaison to you a draft of the above WG document 
> during Nov. 2003. We wish to work with you cooperatively on this 
> document and we would appreciate your assistance in reviewing this draft.
> 
> 
> 
> 

Delivery-date: Fri, 17 Oct 2003 06:26:35 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-crankback-07.txt
Date: Wed, 15 Oct 2003 15:32:23 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Crankback Signaling Extensions for MPLS Signaling
	Author(s)	: A. Farrel, A. Iwata, et. al.
	Filename	: draft-iwata-mpls-crankback-07.txt
	Pages		: 29
	Date		: 2003-10-15
	
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-iwata-mpls-crankback-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-iwata-mpls-crankback-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-iwata-mpls-crankback-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-iwata-mpls-crankback-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-iwata-mpls-crankback-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: Fri, 17 Oct 2003 01:48:48 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Brungard, Deborah A" <[email-masked]>, <[email-masked]>
Subject: RE: ITU Liaison regarding ASON Requirements Design Team
Date: Thu, 16 Oct 2003 18:41:02 -0700

Deborah,

The liason statement looks good. 

A quick clarification, however.

The statement reads:
"... no requirement will be considered in this document that is not 
an ASON routing requirement (as decided by those working on 
Questions 12 and 14 of Study Group 15)."

The parenthetical phrase above seems to suggest that the 
ASON routing requirements within the ITU-T are themselves not fully 
finalized yet.

Is there some doubt about what the exact ASON routing requirements
are? And, are they not clearly specified and agreed to by SG15 yet. 

If so, how does the DT hope to make its recommendations?

Thanks,
-Vishal 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brungard, Deborah A
> Sent: Wednesday, October 15, 2003 1:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: ITU Liaison regarding ASON Requirements Design Team
> 
> 
> CCAMP,
> 
> The design team proposes the following ITU-T liaison on the 
> creation of the ASON Routing Requirements DT and it's charter. We 
> would like to request consensus from CCAMP for forwarding this 
> liaison to ITU-T SG15. The next meeting of SG15 is Oct. 21-31. We 
> would like to request comments by October 21 to allow for this 
> liaison to be forwarded next week to SG15 (cc to Q12/15 
> Rapporteur, Malcolm Betts, [email-masked] and Q14/15 
> Rapporteur, Kam Lam, [email-masked]).
> 
> Thanks,
> Deborah
> 
> ------------------------------------------------------------------
> -------------------------------------
> We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has 
> initiated a Design Team on GMPLS ASON Routing Requirements. The 
> GMPLS ASON Routing Requirements Design Team's Charter is as follows:
> 
> "To understand the requirements for ASON routing so as to capture 
> what's missing from current CCAMP work in a "GMPLS ASON Routing 
> Requirements" document.  The ground rules are the same as for 
> ASON signaling requirements: no requirement will be considered in 
> this document that is not an ASON routing requirement (as decided 
> by those working on Questions 12 and 14 of Study Group 15).  
> Requirements should be justified briefly and prioritized. If 
> needed, a section on terminology should be included. No attempt 
> should be made in this document to do protocol design or suggest 
> protocol extensions."
> 
> We expect to liaison to you a draft of the above WG document 
> during Nov. 2003. We wish to work with you cooperatively on this 
> document and we would appreciate your assistance in reviewing this draft.
> 
> 
> 
> 

Delivery-date: Thu, 16 Oct 2003 08:33:11 +0000
Date: Thu, 16 Oct 2003 10:29:31 +0200
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: "Brungard, Deborah A" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: ITU Liaison regarding ASON Requirements Design Team

Deborah,

I'm fine with that proposal.

Regards

Gert

"Brungard, Deborah A" wrote:

> CCAMP,
>
> The design team proposes the following ITU-T liaison on the creation of the ASON Routing Requirements DT and it's charter. We would like to request consensus from CCAMP for forwarding this liaison to ITU-T SG15. The next meeting of SG15 is Oct. 21-31. We would like to request comments by October 21 to allow for this liaison to be forwarded next week to SG15 (cc to Q12/15 Rapporteur, Malcolm Betts, [email-masked] and Q14/15 Rapporteur, Kam Lam, [email-masked]).
>
> Thanks,
> Deborah
>
> -------------------------------------------------------------------------------------------------------
> We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has initiated a Design Team on GMPLS ASON Routing Requirements. The GMPLS ASON Routing Requirements Design Team's Charter is as follows:
>
> "To understand the requirements for ASON routing so as to capture what's missing from current CCAMP work in a "GMPLS ASON Routing Requirements" document.  The ground rules are the same as for ASON signaling requirements: no requirement will be considered in this document that is not an ASON routing requirement (as decided by those working on Questions 12 and 14 of Study Group 15).  Requirements should be justified briefly and prioritized. If needed, a section on terminology should be included. No attempt should be made in this document to do protocol design or suggest protocol extensions."
>
> We expect to liaison to you a draft of the above WG document during Nov. 2003. We wish to work with you cooperatively on this document and we would appreciate your assistance in reviewing this draft.

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Wed, 15 Oct 2003 22:23:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Brungard, Deborah A" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ITU Liaison regarding ASON Routing Requirements Design Team
Date: Wed, 15 Oct 2003 22:55:39 +0100

Deborah,

Thanks to you and the team for getting this done.

Would it be possible to strengthen this slightly to help reassure SG15 by saying that
_all_ of the ASON routing requirements will be included.

Thanks,
Adrian
----- Original Message ----- 
From: "Brungard, Deborah A" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 15, 2003 9:22 PM
Subject: ITU Liaison regarding ASON Requirements Design Team

CCAMP,

The design team proposes the following ITU-T liaison on the creation of the ASON Routing
Requirements DT and it's charter. We would like to request consensus from CCAMP for
forwarding this liaison to ITU-T SG15. The next meeting of SG15 is Oct. 21-31. We would
like to request comments by October 21 to allow for this liaison to be forwarded next week
to SG15 (cc to Q12/15 Rapporteur, Malcolm Betts, [email-masked] and Q14/15
Rapporteur, Kam Lam, [email-masked]).

Thanks,
Deborah

------------------------------------------------------------------------------------------
-------------
We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has initiated a Design Team
on GMPLS ASON Routing Requirements. The GMPLS ASON Routing Requirements Design Team's
Charter is as follows:

"To understand the requirements for ASON routing so as to capture what's missing from
current CCAMP work in a "GMPLS ASON Routing Requirements" document.  The ground rules are
the same as for ASON signaling requirements: no requirement will be considered in this
document that is not an ASON routing requirement (as decided by those working on Questions
12 and 14 of Study Group 15).  Requirements should be justified briefly and prioritized.
If needed, a section on terminology should be included. No attempt should be made in this
document to do protocol design or suggest protocol extensions."

We expect to liaison to you a draft of the above WG document during Nov. 2003. We wish to
work with you cooperatively on this document and we would appreciate your assistance in
reviewing this draft.

Delivery-date: Wed, 15 Oct 2003 21:47:58 +0000
Date: Wed, 15 Oct 2003 14:43:57 -0700
From: David Meyer <[email-masked]>
To: "Brungard, Deborah A" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: ITU Liaison regarding ASON Requirements Design Team

>> The design team proposes the following ITU-T liaison on the
>> creation of the ASON Routing Requirements DT and it's charter. We
>> would like to request consensus from CCAMP for forwarding this
>> liaison to ITU-T SG15. The next meeting of SG15 is Oct. 21-31. We
>> would like to request comments by October 21 to allow for this
>> liaison to be forwarded next week to SG15 (cc to Q12/15
>> Rapporteur, Malcolm Betts, [email-masked] and Q14/15
>> Rapporteur, Kam Lam, [email-masked]). 

	Looks fine to me. Thanks Deborah.

	Dave

>> 
>> Thanks,
>> Deborah
>> 
>> -------------------------------------------------------------------------------------------------------
>> We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has initiated a Design Team on GMPLS ASON Routing Requirements. The GMPLS ASON Routing Requirements Design Team's Charter is as follows:
>> 
>> "To understand the requirements for ASON routing so as to capture what's missing from current CCAMP work in a "GMPLS ASON Routing Requirements" document.  The ground rules are the same as for ASON signaling requirements: no requirement will be considered in this document that is not an ASON routing requirement (as decided by those working on Questions 12 and 14 of Study Group 15).  Requirements should be justified briefly and prioritized. If needed, a section on terminology should be included. No attempt should be made in this document to do protocol design or suggest protocol extensions."
>> 
>> We expect to liaison to you a draft of the above WG document during Nov. 2003. We wish to work with you cooperatively on this document and we would appreciate your assistance in reviewing this draft.
>> 
>> 
>> 
>> 

Delivery-date: Wed, 15 Oct 2003 20:29:30 +0000
Date: Wed, 15 Oct 2003 13:28:42 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: "Brungard, Deborah A" <[email-masked]>
cc: [email-masked]
Subject: Re: ITU Liaison regarding ASON Requirements Design Team

Hi Deborah,

On Wed, 15 Oct 2003, Brungard, Deborah A wrote:

> CCAMP,
>
> The design team proposes the following ITU-T liaison on the creation of the ASON Routing Requirements DT and it's charter. We would like to request consensus from CCAMP for forwarding this liaison to ITU-T SG15. The next meeting of SG15 is Oct. 21-31. We would like to request comments by October 21 to allow for this liaison to be forwarded next week to SG15 (cc to Q12/15 Rapporteur, Malcolm Betts, [email-masked] and Q14/15 Rapporteur, Kam Lam, [email-masked]).

Looks good to me.

Thanks,
Kireeti.

> -------------------------------------------------------------------------------------------------------
> We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has initiated a Design Team on GMPLS ASON Routing Requirements. The GMPLS ASON Routing Requirements Design Team's Charter is as follows:
>
> "To understand the requirements for ASON routing so as to capture what's missing from current CCAMP work in a "GMPLS ASON Routing Requirements" document.  The ground rules are the same as for ASON signaling requirements: no requirement will be considered in this document that is not an ASON routing requirement (as decided by those working on Questions 12 and 14 of Study Group 15).  Requirements should be justified briefly and prioritized. If needed, a section on terminology should be included. No attempt should be made in this document to do protocol design or suggest protocol extensions."
>
> We expect to liaison to you a draft of the above WG document during Nov. 2003. We wish to work with you cooperatively on this document and we would appreciate your assistance in reviewing this draft.

Delivery-date: Wed, 15 Oct 2003 20:24:58 +0000
content-class: urn:content-classes:message
Subject: ITU Liaison regarding ASON Requirements Design Team
Date: Wed, 15 Oct 2003 15:22:19 -0500
From: "Brungard, Deborah A" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

CCAMP,

The design team proposes the following ITU-T liaison on the creation of the ASON Routing Requirements DT and it's charter. We would like to request consensus from CCAMP for forwarding this liaison to ITU-T SG15. The next meeting of SG15 is Oct. 21-31. We would like to request comments by October 21 to allow for this liaison to be forwarded next week to SG15 (cc to Q12/15 Rapporteur, Malcolm Betts, [email-masked] and Q14/15 Rapporteur, Kam Lam, [email-masked]).

Thanks,
Deborah

-------------------------------------------------------------------------------------------------------
We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has initiated a Design Team on GMPLS ASON Routing Requirements. The GMPLS ASON Routing Requirements Design Team's Charter is as follows:

"To understand the requirements for ASON routing so as to capture what's missing from current CCAMP work in a "GMPLS ASON Routing Requirements" document.  The ground rules are the same as for ASON signaling requirements: no requirement will be considered in this document that is not an ASON routing requirement (as decided by those working on Questions 12 and 14 of Study Group 15).  Requirements should be justified briefly and prioritized. If needed, a section on terminology should be included. No attempt should be made in this document to do protocol design or suggest protocol extensions."

We expect to liaison to you a draft of the above WG document during Nov. 2003. We wish to work with you cooperatively on this document and we would appreciate your assistance in reviewing this draft.

Delivery-date: Wed, 15 Oct 2003 19:38:47 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-crankback-07.txt
Date: Wed, 15 Oct 2003 15:32:23 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Crankback Signaling Extensions for MPLS Signaling
	Author(s)	: A. Farrel, A. Iwata, et. al.
	Filename	: draft-iwata-mpls-crankback-07.txt
	Pages		: 29
	Date		: 2003-10-15
	
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-iwata-mpls-crankback-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-iwata-mpls-crankback-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-iwata-mpls-crankback-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-iwata-mpls-crankback-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-iwata-mpls-crankback-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, 15 Oct 2003 00:18:46 +0000
Date: Tue, 14 Oct 2003 17:17:16 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: CCAMP 58 Time Slots

Hi,

If you'd like a time slot in the IETF 58 CCAMP meeting, please send
your request to Adrian and myself, keeping this subject line.

Remember: no presentations!  A brief description of issues and
resolutions, or in the case of new docs, a very brief intro and
relevance to CCAMP is all there is time for.  Note too that except in
*very* exceptional cases, there MUST be an ID in the repository in
order to get a time slot.

For new docs, it would be a big help to CCAMP attendees to socialize
your document on the mailing list, generate interest and garner
feedback.

Thanks,
Kireeti.

Delivery-date: Tue, 14 Oct 2003 21:26:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Internet-Draft Cutoff Dates for Minneapolis
Date: Tue, 14 Oct 2003 22:24:36 +0100

Please don't wait until the last minute to submit your drafts. Get them out as soon as
possible to lessen the load on the administrators, and to give the Working Group a chance
to read them.

In summary, the dates are:

9am ET, October 20th: Cut-off for initial submissions (new documents).
9am ET, October 27th: Cut-off for all other submissions

Thanks,
Adrian

----- Original Message ----- 
From: "Internet-Drafts Administrator" <[email-masked]>
To: <IETF-Announce:>
Sent: Tuesday, October 14, 2003 3:15 PM
Subject: Internet-Draft Cutoff Dates for Minneapolis, MN, USA

> NOTE: There are two (2) Internet-Draft Cutoff dates.
>
> October 20th: Cutoff for Initial Submissions (new documents).
>
> All initial submissions(-00) must be submitted by Monday, October 20th,
> at 09:00 ET.  Initial submissions received after this time will NOT be
> made available in the Internet-Drafts directory, and will have to be
> resubmitted.
>
> As before, all initial submissions (-00.txt) with a filename beginning
> with a draft-ietf MUST be approved by the appropriate WG Chair prior to
> processing and announcing. WG Chair approval must be received by
> Wednesday, October 15th.
>
> Please do NOT wait until the last minute to submit.
>
> Be advised: NO placeholders. Updates to initial submissions received
>             the week of October 20th will NOT be accepted.
>
> October 27th: FINAL Internet-Draft Cutoff
>
> All revised Internet-Draft submissions must be submitted by Monday,
> October 27th, 2003 at 09:00 ET.  Internet-Drafts received after this
> time will NOT be announced NOR made available in the Internet-Drafts
> Directories.
>
> We will begin accepting Internet-Draft submissions starting Monday,
> November 10th.
>
> Thank you for your understanding and cooperation. Please do not hesitate
> to contact us if you have any questions or concerns.
>
> FYI: These and other significant dates can be found at
>      http://www.ietf.org/meetings/cutoff_dates_58.html

Delivery-date: Tue, 14 Oct 2003 19:39:07 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-04.txt
Date: Tue, 14 Oct 2003 15:33:32 -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-04.txt
	Pages		: 13
	Date		: 2003-10-14
	
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-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-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-ason-reqts-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-ason-reqts-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-reqts-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: Sun, 12 Oct 2003 09:14:33 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-03.txt
Date: Wed, 08 Oct 2003 10:36:18 -0400

--NextPart

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

	Title		: Requirements for Generalized MPLS (GMPLS) Signaling 
			  Usage and Extensions for Automatically Switched 
			  Optical Network (ASON)
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-ason-reqts-03.txt
	Pages		: 14
	Date		: 2003-10-8
	
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-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-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-ason-reqts-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-ason-reqts-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-reqts-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, 10 Oct 2003 23:21:06 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: RSVP-TE Session Attribute Bit Shortage
Date: Sat, 11 Oct 2003 00:15:49 +0100

* Discussions of this topic should be carried out on the MPLS WG mailing list  [email-masked]
*

All,

At the last IETF it was observed that there was a shortage of bit flags in the Session
Attribute object.

Building on a similar feature recently proposed in the OSPF WG, and on a requirement and
solution similarly expressed in draft-vasseur-inter-as-te we are suggesting a new protocol
object to allow more space for attribute bit flags and also to allow arbitrary attribute
TLVs.

We would welcome your comments.
In particular, we have introduced two objects, one with C-num 11bbbbbb and one with C-num
0bbbbbbb. Are they both necessary?

Please make your comments on the MPLS list to keep the cross-list traffic down.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <IETF-Announce:>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, October 10, 2003 8:37 PM
Subject: I-D ACTION:draft-farrel-mpls-rsvpte-attributes-00.txt

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Encoding of Attributes for  Multiprotocol Label
>   Switching (MPLS) Label Switched Path (LSP)
>   Establishment Using RSVP-TE
> Author(s) : A. Farrel, D. Papadimitriou, J. Vasseur
> Filename : draft-farrel-mpls-rsvpte-attributes-00.txt
> Pages : 11
> Date : 2003-10-10
>
> Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
> be established using the Resource Reservation Protocol Traffic
> Engineering extensions (RSVP-TE). This protocol includes an object
> (the SESSION_ATTRIBUTE object) which carries a flags field used to
> indicate options and attributes of the LSP. That flags field has
> eight bits allowing for eight options to be set.
>
> Recent proposals in many documents that extend RSVP-TE for signaling
> additional features and function for MPLS LSPs have suggested uses
> for each of the previously unused bits.
>
> This document defines a new object for RSVP-TE messages that allows
> the signaling of further attribute bits and also the carriage of
> arbitrary attribute parameters. This makes RSVP-TE easily extensible
> to support new requirements.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-mpls-rsvpte-attributes-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> 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-farrel-mpls-rsvpte-attributes-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-farrel-mpls-rsvpte-attributes-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.
>

Delivery-date: Fri, 10 Oct 2003 19:40:46 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-10.txt
Date: Fri, 10 Oct 2003 15:37:50 -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		: Link Management Protocol (LMP)
	Author(s)	: J. Lang
	Filename	: draft-ietf-ccamp-lmp-10.txt
	Pages		: 77
	Date		: 2003-10-10
	
For scalability purposes, multiple data links can be combined to
form a single traffic engineering (TE) link.  Furthermore, the
management of TE links is not restricted to in-band messaging, but
instead can be done using out-of-band techniques.  This document
specifies a link management protocol (LMP) that runs between a pair
of nodes and is used to manage TE links.  Specifically, LMP will be
used to maintain control channel connectivity, verify the physical
connectivity of the data links, correlate the link property
information, suppress downstream alarms, and localize link failures
for protection/restoration purposes in multiple kinds of networks.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lmp-10.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-lmp-10.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-lmp-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-10.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, 10 Oct 2003 19:40:15 +0000
To: IETF-Announce: ;
Cc: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-farrel-mpls-rsvpte-attributes-00.txt
Date: Fri, 10 Oct 2003 15:37:56 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Encoding of Attributes for  Multiprotocol Label 
			  Switching (MPLS) Label Switched Path (LSP) 
			  Establishment Using RSVP-TE
	Author(s)	: A. Farrel, D. Papadimitriou, J. Vasseur
	Filename	: draft-farrel-mpls-rsvpte-attributes-00.txt
	Pages		: 11
	Date		: 2003-10-10
	
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
be established using the Resource Reservation Protocol Traffic
Engineering extensions (RSVP-TE). This protocol includes an object
(the SESSION_ATTRIBUTE object) which carries a flags field used to
indicate options and attributes of the LSP. That flags field has
eight bits allowing for eight options to be set.

Recent proposals in many documents that extend RSVP-TE for signaling
additional features and function for MPLS LSPs have suggested uses
for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows
the signaling of further attribute bits and also the carriage of
arbitrary attribute parameters. This makes RSVP-TE easily extensible
to support new requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-farrel-mpls-rsvpte-attributes-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-farrel-mpls-rsvpte-attributes-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-farrel-mpls-rsvpte-attributes-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-farrel-mpls-rsvpte-attributes-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-farrel-mpls-rsvpte-attributes-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: Fri, 10 Oct 2003 14:40:10 +0000
content-class: urn:content-classes:message
Subject: Handling protection in GMPLS...
Date: Fri, 10 Oct 2003 10:38:00 -0400
From: "Karthik Radakrishnan" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C38F3C.1AF70072
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I have a question about making use of SONET level protection in GMPLS.
There seem to be conflicting descriptions of how it is handled. I'm
particularly interested in the way it is handled for the dedicated 1:1
case. draft-ietf-ccamp-gmpls-recovery-functional-01.txt describes the
way it should be handled in signaling and routing as follows

Routing: A single TE link encompassing both working and protection links
is announced with Link Protection Type "Dedicated 1:1". If Extra Traffic
is supported over the protection link, then the bandwidth parameters for
the protection link must also be announced. The differentiation between
bandwidth for working and protect links is made using priority
mechanisms. In other words, the network must be configured such that
bandwidth at priority X or lower is considered Extra Traffic.
 
Signaling: To establish an LSP on the working link, the Link Protection
object/TLV indicating "Dedicated 1:1" should be included in the
signaling request message for that LSP. To establish an LSP on the
protection link, the appropriate priority (indicating Extra Traffic)
should be used for that LSP. These objects/TLVs are defined in
[GMPLS-SIG]. If the Link Protection object/TLV is not used, link
selection is a matter of local policy.
 
This suggests that the working and the protect links are advertised as a
single interface in routing and protection object and priority together
are used in signaling to identify that extra traffic type protection is
requested. If this is true, why do we need "Extra traffic" as a type of
protection in signaling and routing as defined in RFC 3471 and
draft-ietf-ccamp-gmpls-routing-08.txt. At least it's not obvious from
these documents that one should use a single interface to represent a
1:1 dedicated protection group and use the priority in conjunction with
the protection type to identify the 'extra-traffic' type protection and
also use the priority to describe bandwidth resources on the 'extra
traffic' link. If that's the intent, then it would serve well to state
that explicitly in the signaling and routing documents. Please apologize
and point me to the appropriate sections if that indeed is stated in
these documents.
 
Thanks,
Karthik   

------_=_NextPart_001_01C38F3C.1AF70072
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">

<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>I have a question about making use of SONET level protection
in GMPLS. There seem to be conflicting descriptions of how it is handled. I&#8217;m
particularly interested in the way it is handled for the dedicated 1:1 case. </span></font>draft-ietf-ccamp-gmpls-recovery-functional-01.txt
describes the way it should be handled in signaling and routing as follows</p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

<pre><font size=2 face="Courier New"><span style='font-size:10.0pt'>Routing: A single TE link encompassing both working and protection links is announced with Link Protection Type &quot;Dedicated 1:1&quot;. If Extra Traffic is supported over the protection link, then the bandwidth parameters for the protection link must also be announced. The differentiation between bandwidth for working and protect links is made using priority mechanisms. In other words, the network must be configured such that bandwidth at priority X or lower is considered Extra Traffic.</span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Signaling: To establish an LSP on the working link, the Link Protection object/TLV indicating &quot;Dedicated 1:1&quot; should be included in the signaling request message for that LSP. To establish an LSP on the protection link, the appropriate priority (indicating Extra Traffic) should be used for that LSP. These objects/TLVs are defined in [GMPLS-SIG]. If the Link Protection object/TLV is not used, link selection is a matter of local policy.</span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>This suggests that the working and the protect links are advertised as a single interface in routing and protection object and priority together are used in signaling to identify that extra traffic type protection is requested. If this is true, why do we need &#8220;Extra traffic&#8221; as a type of protection in signaling and routing as defined in RFC 3471 and </span></font>draft-ietf-ccamp-gmpls-routing-08.txt. <font
face=Arial><span style='font-family:Arial'>At least it&#8217;s not obvious from these documents that one should use a single interface to represent a 1:1 dedicated protection group and use the priority in conjunction with the protection type to identify the &#8216;extra-traffic&#8217; type protection and also use the priority to describe bandwidth resources on the &#8216;extra traffic&#8217; link. If that&#8217;s the intent, then it would serve well to state that explicitly in the signaling and routing documents. Please apologize and point me to the appropriate sections if that indeed is stated in these documents.</span></font></pre><pre><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></pre><pre><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Thanks,</span></font></pre><pre><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Karthik &nbsp;</span></font>&nbsp;</pre><pre><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></pre></div>

</body>

</html>

------_=_NextPart_001_01C38F3C.1AF70072--

Delivery-date: Fri, 10 Oct 2003 12:46:26 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-08.txt
Date: Wed, 08 Oct 2003 10:38: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		: Routing Extensions in Support of Generalized
          		  Multi-Protocol Label Switching
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-gmpls-routing-08.txt
	Pages		: 27
	Date		: 2003-10-8
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-routing-08.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-routing-08.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, 08 Oct 2003 22:47:59 +0000
Date: Wed, 8 Oct 2003 15:45:56 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Vikram Anantha <[email-masked]>
cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-routing-08.txt

On Wed, 8 Oct 2003, Vikram Anantha wrote:

> I did a quick search for "OC-3c" in GR-253 and couldn't find any
> reference to it. Is it possible there is a typo in the following lines
> in Section 2.1, point 3 about inheritable attributes:
>
> SNIPPET BEGIN
> "If an OC-192 link is 1+1 protected (a duplicate OC-192 exists for
> protection), then an OC-3c within that OC-192 (a higher layer) would
> inherit the same protection property."
> SNIPPET END
>
>
> Maybe it was supposed to read "STS3c" and not "OC-3c".

Where were you when we were doing the WG Last Call(s) and the IETF
Last Call? :-)

You're right.  This will be fixed along with other typos.

> On the same note, consider a STS3c LSP that traverses one "Enhanced"
> OC48 Link and one "Dedicated 1+1" OC48 Link. If this STS3c LSP is
> considered as a FA and a TE-Link in turn, what would be the protection
> property of this TE-Link?
>
> Would it be "Lowest Common Protection Type" ?

Yes, although one has to define how the LCPT is derived.  It might be
more appropriate to do this in the doc that specifies multi-layer
interaction and inheritance.

Kireeti.

Delivery-date: Wed, 08 Oct 2003 21:55:46 +0000
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-routing-08.txt
Date: Wed, 8 Oct 2003 14:48:40 -0700
From: "Vikram Anantha" <[email-masked]>
To: <[email-masked]>

I did a quick search for "OC-3c" in GR-253 and couldn't find any
reference to it. Is it possible there is a typo in the following lines
in Section 2.1, point 3 about inheritable attributes:

SNIPPET BEGIN
"If an OC-192 link is 1+1 protected (a duplicate OC-192 exists for
protection), then an OC-3c within that OC-192 (a higher layer) would
inherit the same protection property."
SNIPPET END

Maybe it was supposed to read "STS3c" and not "OC-3c".

On the same note, consider a STS3c LSP that traverses one "Enhanced"
OC48 Link and one "Dedicated 1+1" OC48 Link. If this STS3c LSP is
considered as a FA and a TE-Link in turn, what would be the protection
property of this TE-Link?

Would it be "Lowest Common Protection Type" ?

Thanks

Vik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 7:39 AM
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-08.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		: Routing Extensions in Support of Generalized
          		  Multi-Protocol Label Switching
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-gmpls-routing-08.txt
	Pages		: 27
	Date		: 2003-10-8
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-08.tx
t

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

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-routing-08.txt".

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

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

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

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

Delivery-date: Wed, 08 Oct 2003 14:43:34 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-11.txt
Date: Wed, 08 Oct 2003 10:35:19 -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		: OSPF Extensions in Support of Generalized 
			  Multi-Protocol Label Switching
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-11.txt
	Pages		: 14
	Date		: 2003-10-8
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ospf-gmpls-extensions-11.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-ospf-gmpls-extensions-11.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-ospf-gmpls-extensions-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-ospf-gmpls-extensions-11.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, 08 Oct 2003 14:43:04 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-08.txt
Date: Wed, 08 Oct 2003 10:38: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		: Routing Extensions in Support of Generalized
          		  Multi-Protocol Label Switching
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-gmpls-routing-08.txt
	Pages		: 27
	Date		: 2003-10-8
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-routing-08.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-routing-08.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, 08 Oct 2003 14:41:59 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-03.txt
Date: Wed, 08 Oct 2003 10:36:18 -0400

--NextPart

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

	Title		: Requirements for Generalized MPLS (GMPLS) Signaling 
			  Usage and Extensions for Automatically Switched 
			  Optical Network (ASON)
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-ason-reqts-03.txt
	Pages		: 14
	Date		: 2003-10-8
	
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-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-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-ason-reqts-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-ason-reqts-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-reqts-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: Wed, 08 Oct 2003 01:18:32 +0000
Date: Tue, 7 Oct 2003 18:10:58 -0700
From: Alex Zinin <[email-masked]>
Reply-To: [email-masked], [email-masked]
To: [email-masked]
Subject: Changes in CCAMP WG management

Folks-

 We would like to thank Ron Bonica for his contribution to the CCAMP
 WG and his help with the progress within the WG. Ron will be spending
 more time on the L3VPN WG.

 Adrian Farrel, long involved with MPLS and GMPLS activities, has
 agreed to help Kireeti with the WG and is stepping up as a CCAMP
 co-chair replacing Ron effective immediately.

 Please thank Ron and welcome Adrian.

Bert and Alex
IETF Sub-IP Area Co-Directors

Delivery-date: Tue, 07 Oct 2003 19:44:15 +0000
Date: Tue, 7 Oct 2003 12:37:50 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Updated CCAMP charter (fwd)

Hi Dimitri,

On Mon, 22 Sep 2003 [email-masked] wrote:

> thanks for taking care of this; some specific comments concerning
> this revisited charter:
>
> - there is no proposed deadline for the finalization of the lmp
> base specification (acceptance of the iesg review) while we need
> to address the mib for nov'03, is there an expected deadline for
> this important effort produced by the wg ?

It's in the IESG's hands.  That's where milestones end.

> - the deadlines for the ason delta reqs has been proposed resp.
> for signaling and routing, however there is no specific deadline
> proposed for the "delta mechanisms" submission to the iesg, does
> it mean that the proposed deadlines include them ?

No, the proposed deadlines are for requirements only.

> - i would suggest to include an item in the revisited charter
> explicitly stating "refine the signaling and routing mechanisms
> to make possible the creation of paths in multi-layer switching
> networks" since intimately - but not restricted in its applica
> bility scope - to the multi-layer path p&r item

Once the requirements are done, we will re-evaluate, and if the
decision is that more work in signaling and routing is needed (such as
the multi-layer work), then we will recharter.  Note that rechartering
is in the charter :-) and it's set for Mar '04.

Thanks for your comments.
Kireeti.

Delivery-date: Tue, 07 Oct 2003 14:38:52 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Jonathan Lang <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>, "Steve Bellovin (E-mail)" <[email-masked]>
Subject: RE: FW: draft-ietf-ccamp-lmp
Date: Tue, 7 Oct 2003 16:32:09 +0200 

Did (rev 10 I suppose) get posted?
I do not see it!

Thanks,
Bert 

> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: dinsdag 30 september 2003 19:35
> To: [email-masked]; Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail); Steve Bellovin (E-mail)
> Subject: RE: FW: draft-ietf-ccamp-lmp
> 
> 
> Dimitri, Bert, Steve,
>   The LMP version on the IETF website isn't up-to-date with 
> the Security
> Considerations changes because we were waiting for Steve's 
> last comment
> on the selector issue.  We ran the other changes by him back in August
> and I believe they were addressed to his satisfaction.  I'll post the
> latest version of LMP tonight/tomorrow with his new comments in mind.
> 
> Thanks,
> Jonathan
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] 
> > Sent: Tuesday, September 30, 2003 4:18 AM
> > To: Wijnen, Bert (Bert)
> > Cc: Ccamp-wg (E-mail); Jonathan Lang; Steve Bellovin (E-mail)
> > Subject: Re: FW: draft-ietf-ccamp-lmp
> > 
> > 
> > bert, what we've addressed what was on the tracker webpage
> > i think this address what steve was referring here below
> > but now you're right that additional text migth be needed
> > if we further nail down flexibility, we'll come back with 
> > structured text proposal - also i've rephrased one of the 
> > comment made below - hope this will help jonathan -
> > 
> >  >>4.
> >  >>
> >  >>   >     IKE is listed as a SHOULD, not a MUST, but the 
> > requirements
> >  >>   >     mandate replay detection. You can't do that with
> >  >>manual keying.
> >  >>   >     (The requirements also mandate support for 
> manual keying.)
> >  >>   >     If replay protection is needed, either IKE must 
> > be required,
> >  >>   >     or an application-specific replay protection 
> > mechanism must
> >  >>   >     be defined.
> >  >>   >
> >  >>   > 16.1 now speaks of automatic key management, but it says
> >  >>"should" (not
> >  >>   > SHOULD), when it needs to say MUST, and point 2 of 16.2
> >  >>still mandates
> >  >>   > manual keying.  That has to be deleted.
> > 
> > Section 16.1:
> > - "Security mechanism should provide for well defined key
> >    management schemes."
> > 
> > to be replaced by:
> > - "Security mechanism MUST provide for well defined key
> >    management schemes."
> > 
> > and
> > 
> > Section 16.2:
> > - "Implementations of LMP over IPsec protocol MUST support manual
> >    keying mode and dynamic key exchange protocol using IKE."
> > 
> > to be replaced by:
> > - "Implementations of LMP over IPsec protocol MUST support
> >    dynamic key exchange protocol using IKE."
> > 
> > ---
> > 
> > Wijnen, Bert (Bert) wrote:
> > > [ I have cc:-ed the ccamp WG list again, we MUST keep the WG
> > >   involved in this. Or at least allow any WG memebr to jump in
> > >   if they have opinions or contributions]
> > > 
> > > Thanks Dimitri.
> > > I am not sure though that you have answered:
> > > 
> > > 
> > >>   The document does not spell out the foundation for 
> > trust, and this
> > >>   makes it difficult to understand what problem is being 
> > solved.  Why
> > >>   does one need authentication of the IP address?  Why 
> > would one use
> > >>   identity protection in this scenario?  And why not 
> > simply use one IKE
> > >>   pathway as a MUST and be done with it (e.g. aggressive 
> > mode digital
> > >>   signature)?  IKE's flexibility is there to support 
> various usage
> > >>   scenarios, and this seems like an ideal situation to 
> > say, "we know the
> > >>   scenario and we don't need flexibility."  Nail it down.
> > > 
> > > 
> > > Can you rty to compose an answer to that.
> > > Possibly some text to address these questions needs to go in the
> > > document itself as well.
> > > 
> > > Thanks,
> > > Bert
> > > 
> > > 
> > >>-----Original Message-----
> > >>From: [email-masked] 
> > >>[mailto:[email-masked]]
> > >>Sent: dinsdag 30 september 2003 12:33
> > >>To: Wijnen, Bert (Bert)
> > >>Cc: Jonathan Lang; Steve Bellovin (E-mail)
> > >>Subject: Re: FW: draft-ietf-ccamp-lmp
> > >>
> > >>
> > >>hi bert, to address these i would propose the following 
> (i've work 
> > >>this out with o.paridaens) - note we did this some time ago and 
> > >>propose this in order to move this forward, jonathan is 
> > free to take 
> > >>these into consideration or leave them:
> > >>
> > >>1.  > SMB:
> > >>   > Most of my comments have not been addressed.  I said the
> > >>following
> > >>   > about 16.2:
> > >>   >
> > >>   >     The IPsec selectors are all SHOULDs -- what are 
> the MUSTs?
> > >>   >     Setting the port number to 0 means that all UDP 
> > >>traffic between
> > >>   >     those nodes is protected -- is that right? I though the
> > >>   >     document spoke of an LMP port.
> > >>
> > >>Section 16.2:
> > >>- "2. IKE [RFC2409] SHOULD be used as the key exchange mechanism."
> > >>
> > >>to be replaced by:
> > >>- "2. IKE [RFC2409] MUST be used as the key exchange mechanism."
> > >>
> > >>
> > >>2.  > Point 2 still has SHOULD instead of MUST, and still
> > >>says UDP port 0.
> > >>
> > >>note: i don't know about steve's views here but it seems to 
> > accept the 
> > >>previous version of it
> > >>
> > >>Section 16.2:
> > >>- "The identities SHOULD be of type IP addresses
> > >>     and the value of the identities SHOULD be the IP 
> > addresses of the
> > >>     communicating peers. The protocol field SHOULD be IP 
> > protocol UDP
> > >>     (17). The port field SHOULD be set to zero to indicate
> > >>port fields
> > >>     should be ignored."
> > >>
> > >>to be replaced by:
> > >>- "The identities MUST be of type IP addresses
> > >>     and the value of the identities MUST be the IP 
> addresses of the
> > >>     communicating peers. The protocol field MUST be IP 
> protocol UDP
> > >>     (17). The port field SHOULD be set to the LMP UDP port
> > >>as assigned
> > >>     by IANA."
> > >>
> > >>   >     The channel identifer is part of the payload, not 
> > >>the IP or UDP
> > >>   >     headers, and thus can't be a selector.
> > >>   >
> > >>   > There is still text about the channel identifier, in a
> > >>context that
> > >>   > makes it appear like part of the selector.
> > >>
> > >>3. Section 16.2:
> > >>
> > >>- "In LMP exchanges, the channel identifier user by the 
> peer is not
> > >>     known beforehand, and hence cannot be used in the SA."
> > >>
> > >>is suggested to be to be removed.
> > >>
> > >>4.
> > >>
> > >>   >     IKE is listed as a SHOULD, not a MUST, but the 
> requirements
> > >>   >     mandate replay detection. You can't do that with 
> > >>manual keying.
> > >>   >     (The requirements also mandate support for 
> manual keying.)
> > >>   >     If replay protection is needed, either IKE must be 
> > required,
> > >>   >     or an application-specific replay protection 
> mechanism must
> > >>   >     be defined.
> > >>   >
> > >>   > 16.1 now speaks of automatic key management, but it says
> > >>"should" (not
> > >>   > SHOULD), when it needs to say MUST, and point 2 of 16.2 
> > >>still mandates
> > >>   > manual keying.  That has to be deleted.
> > >>
> > >>Section 16.1:
> > >>- "Security mechanism should provide for well defined key
> > >>management schemes."
> > >>
> > >>to be replaced by:
> > >>- "Security mechanism MUST provide for well defined key
> > >>management schemes."
> > >>
> > >>and
> > >>
> > >>Section 16.2:
> > >>- "Implementations of LMP over IPsec protocol MUST support manual
> > >>     keying mode and dynamic key exchange protocol using IKE."
> > >>
> > >>to be replaced by:
> > >>- "Implementations of LMP over IPsec protocol MUST support manual
> > >>     dynamic key exchange protocol using IKE."
> > >>
> > >>5. IPSEC Tunnels
> > >>
> > >> >       All LMP messages are expected to be sent over the
> > >>IPsec tunnel.
> > >> >       However, all LMP messages should be sent through the
> > >>IPsec tunnel,
> > >> >       which will have been established earlier or on an
> > >>as-needed basis.
> > >>
> > >>proposal to rephrase but might need to be discussed in case 
> > of change 
> > >>of semantic:
> > >>
> > >>"All LMP messages should be sent through the IPsec tunnel, 
> > which will 
> > >>have been established earlier or on an as-needed basis."
> > >>
> > >>---
> > >>
> > >>Wijnen, Bert (Bert) wrote:
> > >>
> > >>
> > >>>I think it is important that the whole ccamp list sees 
> > this. If there 
> > >>>are people who want to help Jonathan formulating an answer and 
> > >>>possible updates to the draft, please do so!
> > >>>
> > >>>Thanks,
> > >>>Bert
> > >>>
> > >>>-----Original Message-----
> > >>>From: Steven M. Bellovin [mailto:[email-masked]]
> > >>>Sent: maandag 29 september 2003 20:26
> > >>>To: Wijnen, Bert (Bert)
> > >>>Cc: 'Jonathan Lang'
> > >>>Subject: Re: draft-ietf-ccamp-lmp
> > >>>
> > >>>
> > >>>In message
> > >>
> > 
> >><[email-masked]
> > >>
> > >>>om>, "Wijnen, Bert (Bert)" writes:
> > >>>
> > >>>
> > >>>>>>Steve, to be fair to Jonathan and the WG, I do think 
> > that this is 
> > >>>>>>taking too long now. PLEASE ?
> > >>>>>>
> > >>>>>
> > >>>>>Sorry, I'd meant to send you this on Friday.
> > >>>>>
> > >>>>>I've been unable to get much input from the security
> > >>
> > >>directorate on my
> > >>
> > >>>>>main complaint, but that's a problem I'll have to deal
> > >>
> > >>with. I did get
> > >>
> > >>>>>a few comparatively minor issues, which I'll write up and
> > >>
> > >>forward to
> > >>
> > >>>>>you in the next day or two.  They'll likely require a 
> new I-D to
> > >>>>>clarify a few points, but (I believe) nothing substantive; 
> > >>
> > >>it's just
> > >>
> > >>>>>that there are too many to make an RFC Editor's note practical.
> > >>>>>
> > >>>>
> > >>>>Steve, pls make sure your comment are against the latest 
> > revision, 
> > >>>>draft-ietf-ccamp-lmp-09.txt
> > >>>
> > >>>
> > >>>
> > >>>After checking the comments I received against the latest
> > >>
> > >>version, I'm
> > >>
> > >>>more confused than ever, since some of them don't seem to
> > >>
> > >>apply to any
> > >>
> > >>>version of the document...  That said, there are two
> > >>
> > >>comments that do
> > >>
> > >>>seem to apply:
> > >>>
> > >>>   The document does not spell out the foundation for
> > >>
> > >>trust, and this
> > >>
> > >>>   makes it difficult to understand what problem is being
> > >>
> > >>solved.  Why
> > >>
> > >>>   does one need authentication of the IP address?  Why
> > >>
> > >>would one use
> > >>
> > >>>   identity protection in this scenario?  And why not
> > >>
> > >>simply use one IKE
> > >>
> > >>>   pathway as a MUST and be done with it (e.g. aggressive
> > >>
> > >>mode digital
> > >>
> > >>>   signature)?  IKE's flexibility is there to support 
> various usage
> > >>>   scenarios, and this seems like an ideal situation to
> > >>
> > >>say, "we know the
> > >>
> > >>>   scenario and we don't need flexibility."  Nail it down.
> > >>>
> > >>>and
> > >>>
> > >>>   I admit the following completely defeats me:
> > >>>   
> > >>>      All LMP messages are expected to be sent over the
> > >>
> > >>IPsec tunnel.
> > >>
> > >>>      However, all LMP messages should be sent through the
> > >>
> > >>IPsec tunnel,
> > >>
> > >>>      which will have been established earlier or on an
> > >>
> > >>as-needed basis.
> > >>
> > >>>   
> > >>>   "over" vs. "through"?  "However" as opposed to what?
> > >>>
> > >>>I'm still unhappy about using port number zero, but I'll
> > >>
> > >>let that pass.
> > >>
> > >>>
> > >>>		--Steve Bellovin, http://www.research.att.com/~smb
> > >>>
> > >>>
> > >>
> > >>--
> > >>Papadimitriou Dimitri
> > >>E-mail : [email-masked]
> > >>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > >>E-mail : [email-masked]
> > >>Public : http://psg.com/~dpapadimitriou/
> > >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > >>Phone  : +32 3 240-8491
> > >>
> > >>
> > 
> > -- 
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : +32 3 240-8491
> > 
> > 
> 

Delivery-date: Mon, 06 Oct 2003 15:07:28 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-10.txt
Date: Mon, 06 Oct 2003 11:01:37 -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		: OSPF Extensions in Support of Generalized 
			  Multi-Protocol Label Switching
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-10.txt
	Pages		: 12
	Date		: 2003-10-6
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ospf-gmpls-extensions-10.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-ospf-gmpls-extensions-10.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-ospf-gmpls-extensions-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-ospf-gmpls-extensions-10.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, 03 Oct 2003 20:28:16 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-07.txt
Date: Fri, 03 Oct 2003 16:24:26 -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		: Routing Extensions in Support of Generalized          
			  Multi-Protocol Label Switching
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-gmpls-routing-07.txt
	Pages		: 26
	Date		: 2003-10-3
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-routing-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-routing-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-routing-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-routing-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: Fri, 03 Oct 2003 14:10:10 +0000
Date: Fri, 3 Oct 2003 07:08:28 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Stephen J Trowbridge <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>, "" <[email-masked]>, Ronald Bonica <[email-masked]>, "" <[email-masked]>
Subject: Re: WG Review: Recharter of Common Control and Measurement Plane  (ccamp)

Hi Steve,

On Tue, 30 Sep 2003, Stephen J Trowbridge wrote:

> I think the remark you point out is a good "catch-all" for these
> types of things and should remain, but I suggested the rewording
> for a couple of reasons:
> - The original sentence wording is clumsy and could be misunderstood:
> "Identify requirements for signaling and routing for ASON not currently met ..."
> When I see a statement like "Identify requirements for ...", I tend
> to think of identifying new requirements, and if it is a new requirement,
> of course it is not currently met, but when I get to the end of the
> sentence, I understand that what must have really been meant by the
> beginning of the sentence must have been:
> "Identify WHICH requirements for signaling and routing for ASON ARE not
> currently met". I think the addition of the words WHICH and ARE are
> the minimum to make sure that the sentence is well constructed and not
> misunderstood.

The ASON Routing Requirements Design Team charter explicitly states
what this means.  Isn't that, plus the 'catch-all' good enough?

I will add WHICH and ARE -- they do make it clearer.

> The reason I thought that mention of ITU-T explicitly in this bullet point
> is that ASON requirements come from ITU-T - after all, we are talking
> about (not necessarily IP) transport networks, and by making sure that
> any such work is always joint with ITU-T, we can avoid the famous
> question "What does this have to do with IP?"

That's altogether different.  I don't think we can (or should) avoid
the question, "What does this have to do with IP?" -- that is
fundamental to any IETF work.

"any such work is always joint with ITU-T" -- it's clear from the DT
charter that ASON work will be done jointly with the ITU-T.  It's not
the case that *any* work on transport networks will be done jointly
with the ITU-T, although it would be beneficial to both the ITU-T and
the IETF that each keep the other up-to-date with new developments.

Kireeti.

Delivery-date: Fri, 03 Oct 2003 13:59:56 +0000
From: James Kistruck <[email-masked]>
To: 'ramasamy ramanathan' <[email-masked]>
Cc: [email-masked]
Subject: RE: doubts
Date: Fri, 3 Oct 2003 14:55:39 +0100 
Deferred-Delivery: Fri, 3 Oct 2003 14:56:00 +0100

Rams,

Inline below - look for [JWK]

Regards,

James.

> -----Original Message-----
> From: ramasamy ramanathan [mailto:[email-masked]]
> Sent: 28 September 2003 01:55
> To: [email-masked]
> Subject: doubts
> 
> 
> Hi all,
> 
> I have few doubts, could u please explain me?
> 
> For Contrl Channel Separation in GMPLS, IF_ID_RSVP_HOP object 
> is used to
> control the particlar data channel.
> 
> In case of unnumbered data links, we have unnumbered interface id
> object[RFC3477] to specify the explicit path.  so when we form the
> IF_ID_RSVP_HOP object we can take the router id and interface id from
> unnumbered interface id subobject  of explcit route obect.

[JWK]  The links specified in the IF_ID RSVP_HOP object are specified "from
the viewpoint of the sender of the Path message" - see section 8.1.2 in
rfc3473.

The links specified in the Unnumbered Interface ID subobject may be
specified in terms of either end of the link, provided that for a strict
ERO, each node is mentioned at least once in the ERO - see section 4.2 of
rfc 3477.

+-----+            +-----+               +-----+
|  A  |            |  B  |               |  C  |
|     1------------4     1---------------4     |
|     2------------5     2---------------5     |
|     3------------6     3---------------6     |
|     |            |     |               |     |
+-----+            +-----+               +-----+

In the diagram above, the following are all valid strict EROs

 [A, B, C]
 [A.1, B.1, C]
 [A, B.4, C.4]
 [A.1, B.4, B.1, C.4]

Therefore a node may need to do some translation between remote and local
numbering when building the IF_ID RSVP_HOP object.  LMP provides one way to
discover this mapping between local and remote numbering.
[/JWK]

> 
> In case of numbered data links,  In explicit route object we 
> don't have any
> subobject to mention the data channel's interface address. 

[JWK]  Actually, numbered data links can be put in the ERO, and the
corresponding IPv4 or IPv6 TLVs are placed in the IF_ID RSVP_HOP object (see
9.1.1 in rfc3471).

> Whatever present
> in ERO object gives the control channel's interface address 
> right? 

[JWK]  No.  The ERO specifies the TE links and nodes to be used by the data
path.  There is no requirement for addresses in the ERO to be for signaling
capable links.

> so when
> we form the IF_ID_RSVP_HOP object, from where do we get the 
> actual data
> channel address along which the label has to be allocated? 
> how to carry the
> explcit route( RouterID and Data channel's address) computed 
> by CSPF along
> the PATH.
> 

[JWK]  As above, the ERO can carry all the data link addresses calculated by
CSPF.  How the corresponding signaling addresses are determined is a local
matter.  LMP's control channel support provides one method for doing this,
although it is common for data links to be unnumbered, and for the router ID
to be a routeable, signaling-capable IPv4 address.  In this case the
conversion from remote data link identifier to remote signaling address is
trivial.

> If my assumptions are wrong please correct me.
> 
> thanks
> rams.
> 
> 
> 

Delivery-date: Fri, 03 Oct 2003 12:59:32 +0000
Date: Fri, 3 Oct 2003 05:55:24 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: Jonathan Sadler <[email-masked]>, "" <[email-masked]>
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS to Proposed Standard

On Tue, 23 Sep 2003 [email-masked] wrote:

> hi kireeti, fine with me (i'm okay with the proposed text),
> imho, the document can be sent to the iesg.

The Last Call has ended.  The changes suggested by Jonathan and
Dimitri have been incorporated.

Also, the references in this doc and in the GMPLS OSPF doc have been
updated.  The new docs are draft-ietf-ccamp-gmpls-routing-07.txt and
draft-ietf-ccamp-ospf-gmpls-extensions-10.txt .  These will both be
sent to the IESG for publication.

Thanks all for your input,
Kireeti.

Delivery-date: Thu, 02 Oct 2003 21:56:17 +0000
Date: Thu, 2 Oct 2003 14:51:25 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: ASON routing reqts design team

Hi All,

A new Design Team in the CCAMP WG has been formed.  The team members
and charter follow.

Please send comments to the CCAMP list.  The DT has an aggressive
schedule, so constructive comments will be greatly appreciated.

Thanks to all the DT members for accepting this responsibility!

Kireeti.
--------

 ASON Routing Requirements Design Team
 -------------------------------------

 Members:

     Wesam Alanqar                   <[email-masked]>
     Deborah Brungard [design team leader]       <[email-masked]>
     Dave Meyer                                      <[email-masked]>
     Lyndon Ong                                    <[email-masked]>
     Dimitri Papadimitriou        <[email-masked]>
     Jonathan Sadler                   <[email-masked]>
     Stephen Shew                        <[email-masked]>

 Charter:

     To understand the requirements for ASON routing so as to capture
     what's missing from current CCAMP work in a "GMPLS ASON Routing
     Requirements" document.  The ground rules are the same as for
     ASON signaling requirements: no requirement will be considered in
     this document that is not an ASON routing requirement (as decided
     by those working on Questions 12 and 14 of Study Group 15).

     Requirements should be justified briefly and prioritized.  If
     needed, a section on terminology should be included.  No attempt
     should be made in this document to do protocol design or suggest
     protocol extensions.

     Finally, this design team is responsible for drafting Liaison
     statements from the CCAMP WG to the ITU regarding GMPLS ASON
     routing requirements, as well as for drafting replies to Liaisons
     received from the ITU.  Note that no Liaisons drafted by the design
     team will be sent or replied to without rough consensus of the
     CCAMP WG and approval from the WG chairs and ADs.

     Standard design team disclaimer: this design team has no special
     status in the CCAMP WG.  Any documents they produce are subject
     to the usual WG procedures.  Individuals are encouraged to
     interact with the design team, to offer suggestions and, if they
     feel so inclined, to submit their own drafts.

 Milestones (all on the 15th of the month):

 Oct '03: send Liaison to SG 15 stating creation of DT and charter
 Oct '03: first draft of ASON routing requirements document
 Nov '03: first CCAMP WG document of ASON routing requirements
 Nov '03: Liaison to SG 15 soliciting input on above WG document
 Dec '03: CCAMP WG Last Call
 Jan '04: hand off doc to IESG

Delivery-date: Thu, 02 Oct 2003 14:54:02 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-07.txt
Date: Thu, 02 Oct 2003 10:49:44 -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		: Link Management Protocol Management Information Base
	Author(s)	: M. Dubuc et al.
	Filename	: draft-ietf-ccamp-lmp-mib-07.txt
	Pages		: 80
	Date		: 2003-10-2
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for modeling the Link
Management Protocol (LMP).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lmp-mib-07.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-mib-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: Thu, 02 Oct 2003 01:34:26 +0000
From: "Martin Dubuc" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>
Cc: "Ccamp-wg \(E-mail\)" <[email-masked]>
Subject: Re: LMP MIB revision 6
Date: Wed, 1 Oct 2003 21:16:03 -0400

Bert,

I have submitted a new version of LMP MIB. See in-line to understand how I
addressed your concerns.

Martin

----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Sent: Monday, September 01, 2003 4:42 PM
Subject: RE: LMP MIB revision 6

> Well well...
>
> SMICng says:
>    W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
>       "lmpDataLinkPropertyMismatch" is an index for a table
>    W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
>       "lmpTeLinkDegraded" is an index for a table
>    W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
>       "lmpTeLinkNotDegraded" is an index for a table
>    W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
>       "lmpDataLinkVerificationFailure" is an index for a table
>    W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
>       specified for "lmpCcOperStatus"
>    W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
>       specified for "lmpTeLinkOperStatus"
>    W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
>       specified for "lmpDataLinkActiveOperStatus"
>    W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
>       specified for "lmpDataLinkPassiveOperStatus"
>

Fixed. There were several issues with the conformance section. I have
fixed them.

> smilint says:
>    .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
>      `InetAddress' object should have an accompanied preceding
>      `InetAdressType' object
>    .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
>      `InetAddress' object should have an accompanied preceding
>      `InetAdressType' object
>    .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
>      `InetAddress' objectshould have an accompanied preceding
>      `InetAdressType' object
>

Fixed.

> Some details:
> 1. lmpNbrNodeId OBJECT-TYPE
>       SYNTAX        InetAddress (SIZE(4))
>       MAX-ACCESS    not-accessible
>       STATUS        current
>       DESCRIPTION
>        "This is a unique index for an entry in the LmpNbrTable.
>         This value represents the remote Node ID. The Node ID
>         address type must be IPv4."
>       ::= { lmpNbrEntry 1 }
>    You do know that MIB modules need to be IPv6 friendly, no?
>    Is LMP itself such that it only works with IPv4? I doubt that
>    IESG will approve new protocols that do not support IPv6.

As mentioned in a previous message, I have created a textual convention
defined as a 4 octet octetstring. I have also added a reference to LMP
draft.

> 2. For these 2 objects:
>      lmpNbrRetransmitInterval  LmpRetransmitInterval,
>      lmpNbrRetryLimit          Unsigned32,
>    You may want to add some text as to howyou intend to deal with
>    congestion (RFC 2914). This over UDP if I remember well?
>    I think it would be good to point explicitly to the text in lmp
>    document (sect 10).

I have added some text and a reference to section 10 of LMP
document for both objects.

> 3. lmpNbrRowStatus 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. All read-create objects
>         can only be changed when lmpNbrRowStatus is active."
>    That sounds strange. The notInService status was specifically
>    created to allow changes for cases where changes were not allowed
>    while row was active. Here you say it MUST be active in order
>    to make changes? Or did you mean "can not be changed"?
>    This occurs in more (maybe all) RowStatus objects in this doc.

You are correct, it is the other way around (row must not be active
for change to be allowed). Fixed all RowStatus objects in MIB.

> 4. You have some objedts that are not part of a table, yet are
>    read-write. For example
>        lmpAdminStatus
>        lmpCcHelloIntervalDefault
>        lmpCcHelloIntervalDefaultMin
>        ... and more ...
>    What is the persistency behaviour of these objects?
>    In other words: is the value preserved over a reboot?

Have added text to state that these objects should be
persistent in all read-write objects.

> 5. Is lmpCcIsIf not redundant? The way I read it, then if the
>    lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
>    an interface, no?

Not redundant, as discussed in an earlier message. Have
added text to clarify.

> 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
>    In the telink MIB you have done things correctly and as presscribe
>    by RFC3291. Here you have not. Why ?
>    Even in this doc you have done it correctly in some places.

I have changed object to follow what was done in TE link MIB.

> 7. Mmmmmm??? 52 counters to "measure the performance" of the LMP channels?
>    Sounds overwhelming to me.

There are a lot of counters. In the beginning, I had just a few, but then,
I was asked by WG to add more. It is very difficult to just pick
and choose. There are several functional blocks for which counters
are interesting. I would rather see them all in the MIB. But if WG feels
different I can cut down (but I will need direction).

> 8. Formally, every Counterxx object needs to include in its descritpion
>    clause which object indicates a potential discontinuity. I understand
>    that they all are covered by lmpCcCounterDiscontinuityTime in the
>    same row. Maybe write something about that in the ...Entry description
>    clause as well if you do not want to add text to every Counter

I have added a sentence to this effect to the Entry description of
both tables.

> 9. lmpTeLinkTable
>    DESCRIPTION
>        "This table contains a collection of TE link."
>    Means what??

I have clarified.

> 10. lmpLinkVerificationInterval
>     What does a value of zero mean?
>     Any comments regarding possible congestiuon if the value is set to
>     a very small number of msecs?

Value 0 means no verification. I have added a sentence on consequence of
choosing a value too small.

> 11. lmpLinkVerificationTable
>     Or is it better namep lmpTeLinkLinkVerificationTable
>     and then rename objects as well? If is correct name,
>     Then maybe rename
>        lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
>        lmpTeLinkWavelength     to lmpLinkVerificationTeLinkWavelength

I have changed the object name to better reflect the purpose of these
objects.

> 12. lmpVerifyTransportMechanism
>     There are a few TBDs in there. Better decide before you submit to AD

I updated the list to the latest draft which had the effect of resolving the
issue with TBD entries.

> 13. lmpTeLinkBitRate
>      DESCRIPTION
>        "This is the bit rate at which the Test messages will be
>         transmitted and is expressed in bytes per second."
>     A BIT rate that gest expressed in BYTES per second?
>     Possible of course but strange, no? Why not call it ByteRate?

This object is now lmpTeLinkTransmissionRate and is expressed
in bytes per second.

> 14. Another 40 or so counters for lmpTeLinkPerfTable ???

Same as previous count table. Difficult to decide which to support
or not support since we are covered several functional areas.

> 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>        OBJECTS       { ifIndex,
>                        lmpDataLinkRemoteIfId }
>     The second object already (implicitly) also contains the value
>     of the first object (it is the index part of the OID).

It is not so straightforward, because the ifIndex present in
lmpDataLinkRemoteIfId is the ifIndex on the other side
of the link. I still need the local ifIndex. I have used an
arbitrary object to recover this ifIndex. I hate to do this,
but if it is forbidden to use a not-accessible index,
then I have no choice. I have also done something similar
with lmpTeLinkDegraded, lmpTeLinkNotDegraded and
 lmpDataLinkVerificationFailure notification.

> 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
>     them. But when they are enabled, what kind of rates per second
>     should we fear for in a worst case conidition?
>     Pls think about both an agent (i.e. an LMP node) generating
>     them, but also think about a SNMP management station receiving
>     them from potentially 100s or 1000s of LMP nodes.

I have added a paragraph in the MIB at start of notification block to
discuss this issue. I have also added a lmpNotificationMaxRate object
that can be used to implement a throttling mechanism.

> 17. On page 7 I see:
>       lmpDataLinkAddressType          = unnumbered(1),
>     Mm... that is not a valid value for an InetAddressType
>

Right. Fixed.

> 18. Security COnsiderations
>     You are not following the guidelines to describe first the
>     SET (read-write, read-create) issues/concerns/vulnerabilities
>     and then the read-only sensistivities. So I would not be
>     surprised to see push back from the Security front.
>

I have added the read-only object discussion.

> I have done a pretty serious review... but not exhaustive.
>

Will you need to review further before we can submit it to IESG?

> Thanks,
>
> Bert
> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: maandag 1 september 2003 20:14
> To: 'Martin Dubuc'; Wijnen, Bert (Bert)
> Subject: RE: LMP MIB
>
>
> I have it on my todo-list. I am currently checking te-link mib.
>
>
> Thanks,
> Bert
> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: maandag 1 september 2003 19:55
> To: Bert Wijnen
> Subject: LMP MIB
>
>
> Bert,
>
> I know you have been quite busy with all the MPLS drafts. I just wanted to
know if you had time review the LMP MIB draft and if not, when you think
you'll get around reviewing it.
>
> Regards,
>
> Martin

Delivery-date: Wed, 01 Oct 2003 21:03:37 +0000
Reply-To: <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>, "'Wijnen, Bert \(Bert\)'" <[email-masked]>
Cc: "'Ccamp-wg \(E-mail\)'" <[email-masked]>
Subject: RE: LMP MIB revision 6
Date: Wed, 1 Oct 2003 16:59:21 -0400
Organization: Cisco Systems, inc.

>Bert,
>
>I am almost done updating the LMP MIB to address your 
>comments. However, I
>am stuck on comment 16 (notifications). You would like to know 
>what rate per
>second we should fear in the worst conditions. It is very difficult to
>answer this one. I have thought a lot about this, and I don't 
>think I can
>come up with a number. The notification rate distribution 
>depends too much
>on the type of network, the size of network, the network 
>configuration, the
>type of the links, the reliability of the network, etc.
>
>I can add some text in some of the notifications to explain some of the
>expected limits (for instance, there are some notifications 
>that can only
>happen once per link verification interval), but to give one 
>number for the
>worst case is next to impossible.

	Right, this is why I think adding an object that is
similar to the ones added to the LSR/TE MIBs that lets
the manager configure the desired rate limit is appropriate.

>In general, I think the LMP MIB is not resource hungry when it comes to
>notifications because all of the transitions are state driven 
>(meaning the
>notification are only sent when the system changes state), 
>cover some very
>specific error conditions (like configuration errors) and are mainly
>associated with entities that are limited in numbers (TE links 
>and control
>channels). The only notifications that might have caused a 
>problem are the
>ones associated with data links (because of the potential high 
>number of
>data links) but since the data links can happen only once per 
>data link per
>link verification interval, the notification rate should be 
>sustainable if
>one chooses an appropriate link verification interval and engineers the
>network properly. For instance, a network of 100 nodes with 5 
>links of 128
>wavelengths each and a link verification of 1 minute with say 
>10% of the
>links failed at any given time would have 1 notification per 
>second sent
>from each node (100 notifications per second for the whole 
>network). The rest of the notifications are negligeable compared to
this number.

	Even still, if the implementation supports rate limiting,
and the manager can configure the number, that seems
like a reasonable thing to do.  Anything more seems like
we will go down a rat hole.

	--Tom

>
>Martin
>
>----- Original Message -----
>From: "Wijnen, Bert (Bert)" <[email-masked]>
>To: "'Martin Dubuc'" <[email-masked]>
>Cc: "Ccamp-wg (E-mail)" <[email-masked]>
>Sent: Monday, September 01, 2003 4:42 PM
>Subject: RE: LMP MIB revision 6
>
>
>> Well well...
>>
>> SMICng says:
>>    W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
>>       "lmpDataLinkPropertyMismatch" is an index for a table
>>    W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
>>       "lmpTeLinkDegraded" is an index for a table
>>    W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
>>       "lmpTeLinkNotDegraded" is an index for a table
>>    W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
>>       "lmpDataLinkVerificationFailure" is an index for a table
>>    W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
>>       specified for "lmpCcOperStatus"
>>    W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
>>       specified for "lmpTeLinkOperStatus"
>>    W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
>>       specified for "lmpDataLinkActiveOperStatus"
>>    W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
>>       specified for "lmpDataLinkPassiveOperStatus"
>>
>> smilint says:
>>    .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
>>      `degraded(4)' illegal in sub-type
>>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>>      `up(1)' illegal in sub-type
>>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>>      `down(2)' illegal in sub-type
>>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>>      `degraded(4)' illegal in sub-type
>>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>>      `up(1)' illegal in sub-type
>>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>>      `down(2)' illegal in sub-type
>>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>>      `degraded(4)' illegal in sub-type
>>    .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
>>      `degraded(4)' illegal in sub-type
>>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>>      `up(1)' illegal in sub-type
>>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>>      `down(2)' illegal in sub-type
>>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>>      `degraded(4)' illegal in sub-type
>>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>>      `up(1)' illegal in sub-type
>>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>>      `down(2)' illegal in sub-type
>>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>>      `degraded(4)' illegal in sub-type
>>    .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
>>      `InetAddress' object should have an accompanied preceding
>>      `InetAdressType' object
>>    .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
>>      `InetAddress' object should have an accompanied preceding
>>      `InetAdressType' object
>>    .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
>>      `InetAddress' objectshould have an accompanied preceding
>>      `InetAdressType' object
>>
>> Some details:
>> 1. lmpNbrNodeId OBJECT-TYPE
>>       SYNTAX        InetAddress (SIZE(4))
>>       MAX-ACCESS    not-accessible
>>       STATUS        current
>>       DESCRIPTION
>>        "This is a unique index for an entry in the LmpNbrTable.
>>         This value represents the remote Node ID. The Node ID
>>         address type must be IPv4."
>>       ::= { lmpNbrEntry 1 }
>>    You do know that MIB modules need to be IPv6 friendly, no?
>>    Is LMP itself such that it only works with IPv4? I doubt that
>>    IESG will approve new protocols that do not support IPv6.
>> 2. For these 2 objects:
>>      lmpNbrRetransmitInterval  LmpRetransmitInterval,
>>      lmpNbrRetryLimit          Unsigned32,
>>    You may want to add some text as to howyou intend to deal with
>>    congestion (RFC 2914). This over UDP if I remember well?
>>    I think it would be good to point explicitly to the text in lmp
>>    document (sect 10).
>> 3. lmpNbrRowStatus 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. All read-create objects
>>         can only be changed when lmpNbrRowStatus is active."
>>    That sounds strange. The notInService status was specifically
>>    created to allow changes for cases where changes were not allowed
>>    while row was active. Here you say it MUST be active in order
>>    to make changes? Or did you mean "can not be changed"?
>>    This occurs in more (maybe all) RowStatus objects in this doc.
>> 4. You have some objedts that are not part of a table, yet are
>>    read-write. For example
>>        lmpAdminStatus
>>        lmpCcHelloIntervalDefault
>>        lmpCcHelloIntervalDefaultMin
>>        ... and more ...
>>    What is the persistency behaviour of these objects?
>>    In other words: is the value preserved over a reboot?
>> 5. Is lmpCcIsIf not redundant? The way I read it, then if the
>>    lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
>>    an interface, no?
>> 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
>>    In the telink MIB you have done things correctly and as presscribe
>>    by RFC3291. Here you have not. Why ?
>>    Even in this doc you have done it correctly in some places.
>> 7. Mmmmmm??? 52 counters to "measure the performance" of the 
>LMP channels?
>>    Sounds overwhelming to me.
>> 8. Formally, every Counterxx object needs to include in its 
>descritpion
>>    clause which object indicates a potential discontinuity. 
>I understand
>>    that they all are covered by lmpCcCounterDiscontinuityTime in the
>>    same row. Maybe write something about that in the 
>...Entry description
>>    clause as well if you do not want to add text to every Counter
>> 9. lmpTeLinkTable
>>    DESCRIPTION
>>        "This table contains a collection of TE link."
>>    Means what??
>> 10. lmpLinkVerificationInterval
>>     What does a value of zero mean?
>>     Any comments regarding possible congestiuon if the value 
>is set to
>>     a very small number of msecs?
>> 11. lmpLinkVerificationTable
>>     Or is it better namep lmpTeLinkLinkVerificationTable
>>     and then rename objects as well? If is correct name,
>>     Then maybe rename
>>        lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
>>        lmpTeLinkWavelength     to lmpLinkVerificationTeLinkWavelength
>> 12. lmpVerifyTransportMechanism
>>     There are a few TBDs in there. Better decide before you 
>submit to AD
>> 13. lmpTeLinkBitRate
>>      DESCRIPTION
>>        "This is the bit rate at which the Test messages will be
>>         transmitted and is expressed in bytes per second."
>>     A BIT rate that gest expressed in BYTES per second?
>>     Possible of course but strange, no? Why not call it ByteRate?
>> 14. Another 40 or so counters for lmpTeLinkPerfTable ???
>> 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>>        OBJECTS       { ifIndex,
>>                        lmpDataLinkRemoteIfId }
>>     The second object already (implicitly) also contains the value
>>     of the first object (it is the index part of the OID).
>> 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
>>     them. But when they are enabled, what kind of rates per second
>>     should we fear for in a worst case conidition?
>>     Pls think about both an agent (i.e. an LMP node) generating
>>     them, but also think about a SNMP management station receiving
>>     them from potentially 100s or 1000s of LMP nodes.
>> 17. On page 7 I see:
>>       lmpDataLinkAddressType          = unnumbered(1),
>>     Mm... that is not a valid value for an InetAddressType
>>
>> 18. Security COnsiderations
>>     You are not following the guidelines to describe first the
>>     SET (read-write, read-create) issues/concerns/vulnerabilities
>>     and then the read-only sensistivities. So I would not be
>>     surprised to see push back from the Security front.
>>
>> I have done a pretty serious review... but not exhaustive.
>>
>> Thanks,
>>
>> Bert
>> -----Original Message-----
>> From: Wijnen, Bert (Bert)
>> Sent: maandag 1 september 2003 20:14
>> To: 'Martin Dubuc'; Wijnen, Bert (Bert)
>> Subject: RE: LMP MIB
>>
>>
>> I have it on my todo-list. I am currently checking te-link mib.
>>
>>
>> Thanks,
>> Bert
>> -----Original Message-----
>> From: Martin Dubuc [mailto:[email-masked]]
>> Sent: maandag 1 september 2003 19:55
>> To: Bert Wijnen
>> Subject: LMP MIB
>>
>>
>> Bert,
>>
>> I know you have been quite busy with all the MPLS drafts. I 
>just wanted to
>know if you had time review the LMP MIB draft and if not, when 
>you think
>you'll get around reviewing it.
>>
>> Regards,
>>
>> Martin
>
>

Delivery-date: Wed, 01 Oct 2003 20:19:54 +0000
From: "Martin Dubuc" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>
Cc: "Ccamp-wg \(E-mail\)" <[email-masked]>
Subject: Re: LMP MIB revision 6
Date: Sat, 27 Sep 2003 10:50:03 -0400

Thanks Bert.

See in-line.

Martin

----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Sent: Wednesday, September 24, 2003 9:34 AM
Subject: RE: LMP MIB revision 6

> Inline
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Martin Dubuc [mailto:[email-masked]]
> > Sent: woensdag 24 september 2003 13:56
> > To: Wijnen, Bert (Bert)
> > Cc: Ccamp-wg (E-mail)
> > Subject: Re: LMP MIB revision 6
> >
> >
> > Bert,
> >
> > After working on the document yesterday, I have some comments on your
> > original message.
> >
> > First, with regards to the Node ID, LMP defines Node ID as a 4 octet
field.
> > It usually maps to a 4-bytes IP address and is usually more of an
internal
> > network address. I am not sure it makes sense to support IPv6 for this
> > field. I haven't heard that there was any proposal to change the Node ID
to
> > support IPv6 format.
> >
> If you are sure it is gonna be just an IPv4 address, then the proper
> SYNTAX would be InetAddressIPv4 instead of InetAddress.
> But it seems it (at least theoretically) it can also be some random
> 32 bit number (Node_Id). Maybe the proper syntax is OCTET STRING SIZE (4)
> and then specify that it is the Node_Id in network byte order?
>
> In any event, you CANNOT use InetAddres without also having a
> InetAddressType for it.
>
> And also you better add a REFERENCE clause that explains where
> Node ID is defined.
> So add a reference to the terminology section of the base
> LMP document where Node_Id is defined.
>

I like your suggestion of defining Node ID as a 4 octet octetstring. Since
Node ID
is used in two different places, I have created a textual convention for
Node ID.
I have also added the reference as per your suggestion.

>
> > lmpCcIsIf is not redundant. In some implementations, control channel
will be
> > mapped to interfaces, in other implementations, they will not. This
object
> > is used as such indicator. In cases where the control channel is not
mapped
> > as interface, it is true that the value of lmpCcUnderlyingIfIndex will
be 0.
> > But in cases where control channels are mapped to interfaces,
> > lmpCcUnderlyingIfIndex could be set to 0 to indicate that the control
> > channels are not yet assigned/configured/discovered. So a  value of 0
for
> > lmpCcUnderlyingIfIndex does not necessarily mean that control channel is
not
> > an interface.
> >
> So that is/was not so clear from the DESCRIPTION clauses. Maybe you can
clarify
> that a bit.
>

I have clarified this in the MIB.

> > Concerning lmpCcRemoteAddressType and lmpCcRemoteCcAddr, I am not sure
what
> > it is from TE link MIB that you like that you would like to see here as
> > well.
> >
>
> It MUST explain WHICH object of syntax InetAddressType specifies the
format
> of these objects. You did it correctly for example in:
> lmpDataLinkIpAddr OBJECT-TYPE
>    SYNTAX        InetAddress
>    MAX-ACCESS    read-create
>    STATUS        current
>    DESCRIPTION
>        "The local Internet address for numbered links. The type
>         of this address is determined by the value of
>         lmpDataLinkAddressType object.
>

I have added explicit reference to lmpCcRemoteAddressType in
lmpCcRemoteIpAddr description.

>         ... more stuff ...
>
> > Regards,
> >
> > Martin
> >
> Hope this helps,
> Bert
>
> > ----- Original Message -----
> > From: "Wijnen, Bert (Bert)" <[email-masked]>
> > To: "'Martin Dubuc'" <[email-masked]>
> > Cc: "Ccamp-wg (E-mail)" <[email-masked]>
> > Sent: Monday, September 01, 2003 4:42 PM
> > Subject: RE: LMP MIB revision 6
> >
> >
> > > Well well...
> > >
> > > SMICng says:
> > >    W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
> > >       "lmpDataLinkPropertyMismatch" is an index for a table
> > >    W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
> > >       "lmpTeLinkDegraded" is an index for a table
> > >    W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
> > >       "lmpTeLinkNotDegraded" is an index for a table
> > >    W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
> > >       "lmpDataLinkVerificationFailure" is an index for a table
> > >    W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
> > >       specified for "lmpCcOperStatus"
> > >    W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
> > >       specified for "lmpTeLinkOperStatus"
> > >    W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
> > >       specified for "lmpDataLinkActiveOperStatus"
> > >    W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
> > >       specified for "lmpDataLinkPassiveOperStatus"
> > >
> > > smilint says:
> > >    .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > >      `up(1)' illegal in sub-type
> > >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > >      `down(2)' illegal in sub-type
> > >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > >      `up(1)' illegal in sub-type
> > >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > >      `down(2)' illegal in sub-type
> > >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > >      `up(1)' illegal in sub-type
> > >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > >      `down(2)' illegal in sub-type
> > >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > >      `up(1)' illegal in sub-type
> > >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > >      `down(2)' illegal in sub-type
> > >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
> > >      `InetAddress' object should have an accompanied preceding
> > >      `InetAdressType' object
> > >    .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
> > >      `InetAddress' object should have an accompanied preceding
> > >      `InetAdressType' object
> > >    .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
> > >      `InetAddress' objectshould have an accompanied preceding
> > >      `InetAdressType' object
> > >
> > > Some details:
> > > 1. lmpNbrNodeId OBJECT-TYPE
> > >       SYNTAX        InetAddress (SIZE(4))
> > >       MAX-ACCESS    not-accessible
> > >       STATUS        current
> > >       DESCRIPTION
> > >        "This is a unique index for an entry in the LmpNbrTable.
> > >         This value represents the remote Node ID. The Node ID
> > >         address type must be IPv4."
> > >       ::= { lmpNbrEntry 1 }
> > >    You do know that MIB modules need to be IPv6 friendly, no?
> > >    Is LMP itself such that it only works with IPv4? I doubt that
> > >    IESG will approve new protocols that do not support IPv6.
> > > 2. For these 2 objects:
> > >      lmpNbrRetransmitInterval  LmpRetransmitInterval,
> > >      lmpNbrRetryLimit          Unsigned32,
> > >    You may want to add some text as to howyou intend to deal with
> > >    congestion (RFC 2914). This over UDP if I remember well?
> > >    I think it would be good to point explicitly to the text in lmp
> > >    document (sect 10).
> > > 3. lmpNbrRowStatus 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. All read-create objects
> > >         can only be changed when lmpNbrRowStatus is active."
> > >    That sounds strange. The notInService status was specifically
> > >    created to allow changes for cases where changes were not allowed
> > >    while row was active. Here you say it MUST be active in order
> > >    to make changes? Or did you mean "can not be changed"?
> > >    This occurs in more (maybe all) RowStatus objects in this doc.
> > > 4. You have some objedts that are not part of a table, yet are
> > >    read-write. For example
> > >        lmpAdminStatus
> > >        lmpCcHelloIntervalDefault
> > >        lmpCcHelloIntervalDefaultMin
> > >        ... and more ...
> > >    What is the persistency behaviour of these objects?
> > >    In other words: is the value preserved over a reboot?
> > > 5. Is lmpCcIsIf not redundant? The way I read it, then if the
> > >    lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
> > >    an interface, no?
> > > 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
> > >    In the telink MIB you have done things correctly and as
> > presscribe
> > >    by RFC3291. Here you have not. Why ?
> > >    Even in this doc you have done it correctly in some places.
> > > 7. Mmmmmm??? 52 counters to "measure the performance" of
> > the LMP channels?
> > >    Sounds overwhelming to me.
> > > 8. Formally, every Counterxx object needs to include in its
> > descritpion
> > >    clause which object indicates a potential discontinuity.
> > I understand
> > >    that they all are covered by lmpCcCounterDiscontinuityTime in the
> > >    same row. Maybe write something about that in the
> > ...Entry description
> > >    clause as well if you do not want to add text to every Counter
> > > 9. lmpTeLinkTable
> > >    DESCRIPTION
> > >        "This table contains a collection of TE link."
> > >    Means what??
> > > 10. lmpLinkVerificationInterval
> > >     What does a value of zero mean?
> > >     Any comments regarding possible congestiuon if the
> > value is set to
> > >     a very small number of msecs?
> > > 11. lmpLinkVerificationTable
> > >     Or is it better namep lmpTeLinkLinkVerificationTable
> > >     and then rename objects as well? If is correct name,
> > >     Then maybe rename
> > >        lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
> > >        lmpTeLinkWavelength     to
> > lmpLinkVerificationTeLinkWavelength
> > > 12. lmpVerifyTransportMechanism
> > >     There are a few TBDs in there. Better decide before you
> > submit to AD
> > > 13. lmpTeLinkBitRate
> > >      DESCRIPTION
> > >        "This is the bit rate at which the Test messages will be
> > >         transmitted and is expressed in bytes per second."
> > >     A BIT rate that gest expressed in BYTES per second?
> > >     Possible of course but strange, no? Why not call it ByteRate?
> > > 14. Another 40 or so counters for lmpTeLinkPerfTable ???
> > > 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> > >        OBJECTS       { ifIndex,
> > >                        lmpDataLinkRemoteIfId }
> > >     The second object already (implicitly) also contains the value
> > >     of the first object (it is the index part of the OID).
> > > 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
> > >     them. But when they are enabled, what kind of rates per second
> > >     should we fear for in a worst case conidition?
> > >     Pls think about both an agent (i.e. an LMP node) generating
> > >     them, but also think about a SNMP management station receiving
> > >     them from potentially 100s or 1000s of LMP nodes.
> > > 17. On page 7 I see:
> > >       lmpDataLinkAddressType          = unnumbered(1),
> > >     Mm... that is not a valid value for an InetAddressType
> > >
> > > 18. Security COnsiderations
> > >     You are not following the guidelines to describe first the
> > >     SET (read-write, read-create) issues/concerns/vulnerabilities
> > >     and then the read-only sensistivities. So I would not be
> > >     surprised to see push back from the Security front.
> > >
> > > I have done a pretty serious review... but not exhaustive.
> > >
> > > Thanks,
> > >
> > > Bert
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert)
> > > Sent: maandag 1 september 2003 20:14
> > > To: 'Martin Dubuc'; Wijnen, Bert (Bert)
> > > Subject: RE: LMP MIB
> > >
> > >
> > > I have it on my todo-list. I am currently checking te-link mib.
> > >
> > >
> > > Thanks,
> > > Bert
> > > -----Original Message-----
> > > From: Martin Dubuc [mailto:[email-masked]]
> > > Sent: maandag 1 september 2003 19:55
> > > To: Bert Wijnen
> > > Subject: LMP MIB
> > >
> > >
> > > Bert,
> > >
> > > I know you have been quite busy with all the MPLS drafts. I
> > just wanted to
> > know if you had time review the LMP MIB draft and if not,
> > when you think
> > you'll get around reviewing it.
> > >
> > > Regards,
> > >
> > > Martin
> >

Delivery-date: Wed, 01 Oct 2003 20:19:24 +0000
From: "Martin Dubuc" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>
Cc: "Ccamp-wg \(E-mail\)" <[email-masked]>
Subject: Re: LMP MIB revision 6
Date: Mon, 29 Sep 2003 19:24:54 -0400

I have added a max throttling rate object.

Martin

----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>; "Wijnen, Bert (Bert)"
<[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Sent: Sunday, September 28, 2003 5:01 AM
Subject: RE: LMP MIB revision 6

> So below you give me a lot of explanation what kind of
> notifications can get generated and how many would be generated
> under which conditions. I think that is exactly the type of
> information that we would like to see somewhere (best uis probably
> in DESCRITPION clauses so that it stays with the MIB module when
> it gets extracted). You might also add some warnings that people
> should be carefull NOT to configure too short verification times
> and at least take the potential notification rate into consideration
> when doing so.
>
> The question then becomes: should there be an object to throttle
> the max rate?
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Martin Dubuc [mailto:[email-masked]]
> > Sent: zondag 28 september 2003 3:31
> > To: Wijnen, Bert (Bert)
> > Cc: Ccamp-wg (E-mail)
> > Subject: Re: LMP MIB revision 6
> >
> >
> > Bert,
> >
> > I am almost done updating the LMP MIB to address your
> > comments. However, I
> > am stuck on comment 16 (notifications). You would like to
> > know what rate per
> > second we should fear in the worst conditions. It is very difficult to
> > answer this one. I have thought a lot about this, and I don't
> > think I can
> > come up with a number. The notification rate distribution
> > depends too much
> > on the type of network, the size of network, the network
> > configuration, the
> > type of the links, the reliability of the network, etc.
> >
> > I can add some text in some of the notifications to explain
> > some of the
> > expected limits (for instance, there are some notifications
> > that can only
> > happen once per link verification interval), but to give one
> > number for the
> > worst case is next to impossible.
> >
> > In general, I think the LMP MIB is not resource hungry when
> > it comes to
> > notifications because all of the transitions are state driven
> > (meaning the
> > notification are only sent when the system changes state),
> > cover some very
> > specific error conditions (like configuration errors) and are mainly
> > associated with entities that are limited in numbers (TE
> > links and control
> > channels). The only notifications that might have caused a
> > problem are the
> > ones associated with data links (because of the potential
> > high number of
> > data links) but since the data links can happen only once per
> > data link per
> > link verification interval, the notification rate should be
> > sustainable if
> > one chooses an appropriate link verification interval and
> > engineers the
> > network properly. For instance, a network of 100 nodes with 5
> > links of 128
> > wavelengths each and a link verification of 1 minute with say
> > 10% of the
> > links failed at any given time would have 1 notification per
> > second sent
> > from each node (100 notifications per second for the whole
> > network). The
> > rest of the notifications are negligeable compared to this number.
> >
> > Martin
> >
> > ----- Original Message -----
> > From: "Wijnen, Bert (Bert)" <[email-masked]>
> > To: "'Martin Dubuc'" <[email-masked]>
> > Cc: "Ccamp-wg (E-mail)" <[email-masked]>
> > Sent: Monday, September 01, 2003 4:42 PM
> > Subject: RE: LMP MIB revision 6
> >
> >
> > > Well well...
> > >
> > > SMICng says:
> > >    W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
> > >       "lmpDataLinkPropertyMismatch" is an index for a table
> > >    W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
> > >       "lmpTeLinkDegraded" is an index for a table
> > >    W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
> > >       "lmpTeLinkNotDegraded" is an index for a table
> > >    W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
> > >       "lmpDataLinkVerificationFailure" is an index for a table
> > >    W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
> > >       specified for "lmpCcOperStatus"
> > >    W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
> > >       specified for "lmpTeLinkOperStatus"
> > >    W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
> > >       specified for "lmpDataLinkActiveOperStatus"
> > >    W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
> > >       specified for "lmpDataLinkPassiveOperStatus"
> > >
> > > smilint says:
> > >    .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > >      `up(1)' illegal in sub-type
> > >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > >      `down(2)' illegal in sub-type
> > >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > >      `up(1)' illegal in sub-type
> > >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > >      `down(2)' illegal in sub-type
> > >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > >      `up(1)' illegal in sub-type
> > >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > >      `down(2)' illegal in sub-type
> > >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > >      `up(1)' illegal in sub-type
> > >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > >      `down(2)' illegal in sub-type
> > >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > >      `degraded(4)' illegal in sub-type
> > >    .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
> > >      `InetAddress' object should have an accompanied preceding
> > >      `InetAdressType' object
> > >    .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
> > >      `InetAddress' object should have an accompanied preceding
> > >      `InetAdressType' object
> > >    .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
> > >      `InetAddress' objectshould have an accompanied preceding
> > >      `InetAdressType' object
> > >
> > > Some details:
> > > 1. lmpNbrNodeId OBJECT-TYPE
> > >       SYNTAX        InetAddress (SIZE(4))
> > >       MAX-ACCESS    not-accessible
> > >       STATUS        current
> > >       DESCRIPTION
> > >        "This is a unique index for an entry in the LmpNbrTable.
> > >         This value represents the remote Node ID. The Node ID
> > >         address type must be IPv4."
> > >       ::= { lmpNbrEntry 1 }
> > >    You do know that MIB modules need to be IPv6 friendly, no?
> > >    Is LMP itself such that it only works with IPv4? I doubt that
> > >    IESG will approve new protocols that do not support IPv6.
> > > 2. For these 2 objects:
> > >      lmpNbrRetransmitInterval  LmpRetransmitInterval,
> > >      lmpNbrRetryLimit          Unsigned32,
> > >    You may want to add some text as to howyou intend to deal with
> > >    congestion (RFC 2914). This over UDP if I remember well?
> > >    I think it would be good to point explicitly to the text in lmp
> > >    document (sect 10).
> > > 3. lmpNbrRowStatus 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. All read-create objects
> > >         can only be changed when lmpNbrRowStatus is active."
> > >    That sounds strange. The notInService status was specifically
> > >    created to allow changes for cases where changes were not allowed
> > >    while row was active. Here you say it MUST be active in order
> > >    to make changes? Or did you mean "can not be changed"?
> > >    This occurs in more (maybe all) RowStatus objects in this doc.
> > > 4. You have some objedts that are not part of a table, yet are
> > >    read-write. For example
> > >        lmpAdminStatus
> > >        lmpCcHelloIntervalDefault
> > >        lmpCcHelloIntervalDefaultMin
> > >        ... and more ...
> > >    What is the persistency behaviour of these objects?
> > >    In other words: is the value preserved over a reboot?
> > > 5. Is lmpCcIsIf not redundant? The way I read it, then if the
> > >    lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
> > >    an interface, no?
> > > 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
> > >    In the telink MIB you have done things correctly and as
> > presscribe
> > >    by RFC3291. Here you have not. Why ?
> > >    Even in this doc you have done it correctly in some places.
> > > 7. Mmmmmm??? 52 counters to "measure the performance" of
> > the LMP channels?
> > >    Sounds overwhelming to me.
> > > 8. Formally, every Counterxx object needs to include in its
> > descritpion
> > >    clause which object indicates a potential discontinuity.
> > I understand
> > >    that they all are covered by lmpCcCounterDiscontinuityTime in the
> > >    same row. Maybe write something about that in the
> > ...Entry description
> > >    clause as well if you do not want to add text to every Counter
> > > 9. lmpTeLinkTable
> > >    DESCRIPTION
> > >        "This table contains a collection of TE link."
> > >    Means what??
> > > 10. lmpLinkVerificationInterval
> > >     What does a value of zero mean?
> > >     Any comments regarding possible congestiuon if the
> > value is set to
> > >     a very small number of msecs?
> > > 11. lmpLinkVerificationTable
> > >     Or is it better namep lmpTeLinkLinkVerificationTable
> > >     and then rename objects as well? If is correct name,
> > >     Then maybe rename
> > >        lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
> > >        lmpTeLinkWavelength     to
> > lmpLinkVerificationTeLinkWavelength
> > > 12. lmpVerifyTransportMechanism
> > >     There are a few TBDs in there. Better decide before you
> > submit to AD
> > > 13. lmpTeLinkBitRate
> > >      DESCRIPTION
> > >        "This is the bit rate at which the Test messages will be
> > >         transmitted and is expressed in bytes per second."
> > >     A BIT rate that gest expressed in BYTES per second?
> > >     Possible of course but strange, no? Why not call it ByteRate?
> > > 14. Another 40 or so counters for lmpTeLinkPerfTable ???
> > > 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> > >        OBJECTS       { ifIndex,
> > >                        lmpDataLinkRemoteIfId }
> > >     The second object already (implicitly) also contains the value
> > >     of the first object (it is the index part of the OID).
> > > 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
> > >     them. But when they are enabled, what kind of rates per second
> > >     should we fear for in a worst case conidition?
> > >     Pls think about both an agent (i.e. an LMP node) generating
> > >     them, but also think about a SNMP management station receiving
> > >     them from potentially 100s or 1000s of LMP nodes.
> > > 17. On page 7 I see:
> > >       lmpDataLinkAddressType          = unnumbered(1),
> > >     Mm... that is not a valid value for an InetAddressType
> > >
> > > 18. Security COnsiderations
> > >     You are not following the guidelines to describe first the
> > >     SET (read-write, read-create) issues/concerns/vulnerabilities
> > >     and then the read-only sensistivities. So I would not be
> > >     surprised to see push back from the Security front.
> > >
> > > I have done a pretty serious review... but not exhaustive.
> > >
> > > Thanks,
> > >
> > > Bert
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert)
> > > Sent: maandag 1 september 2003 20:14
> > > To: 'Martin Dubuc'; Wijnen, Bert (Bert)
> > > Subject: RE: LMP MIB
> > >
> > >
> > > I have it on my todo-list. I am currently checking te-link mib.
> > >
> > >
> > > Thanks,
> > > Bert
> > > -----Original Message-----
> > > From: Martin Dubuc [mailto:[email-masked]]
> > > Sent: maandag 1 september 2003 19:55
> > > To: Bert Wijnen
> > > Subject: LMP MIB
> > >
> > >
> > > Bert,
> > >
> > > I know you have been quite busy with all the MPLS drafts. I
> > just wanted to
> > know if you had time review the LMP MIB draft and if not,
> > when you think
> > you'll get around reviewing it.
> > >
> > > Regards,
> > >
> > > Martin
> >

Delivery-date: Wed, 01 Oct 2003 20:18:55 +0000
From: "Martin Dubuc" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>
Cc: "Ccamp-wg \(E-mail\)" <[email-masked]>
Subject: Re: LMP MIB revision 6
Date: Sat, 27 Sep 2003 21:31:16 -0400

Bert,

I am almost done updating the LMP MIB to address your comments. However, I
am stuck on comment 16 (notifications). You would like to know what rate per
second we should fear in the worst conditions. It is very difficult to
answer this one. I have thought a lot about this, and I don't think I can
come up with a number. The notification rate distribution depends too much
on the type of network, the size of network, the network configuration, the
type of the links, the reliability of the network, etc.

I can add some text in some of the notifications to explain some of the
expected limits (for instance, there are some notifications that can only
happen once per link verification interval), but to give one number for the
worst case is next to impossible.

In general, I think the LMP MIB is not resource hungry when it comes to
notifications because all of the transitions are state driven (meaning the
notification are only sent when the system changes state), cover some very
specific error conditions (like configuration errors) and are mainly
associated with entities that are limited in numbers (TE links and control
channels). The only notifications that might have caused a problem are the
ones associated with data links (because of the potential high number of
data links) but since the data links can happen only once per data link per
link verification interval, the notification rate should be sustainable if
one chooses an appropriate link verification interval and engineers the
network properly. For instance, a network of 100 nodes with 5 links of 128
wavelengths each and a link verification of 1 minute with say 10% of the
links failed at any given time would have 1 notification per second sent
from each node (100 notifications per second for the whole network). The
rest of the notifications are negligeable compared to this number.

Martin

----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Sent: Monday, September 01, 2003 4:42 PM
Subject: RE: LMP MIB revision 6

> Well well...
>
> SMICng says:
>    W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
>       "lmpDataLinkPropertyMismatch" is an index for a table
>    W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
>       "lmpTeLinkDegraded" is an index for a table
>    W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
>       "lmpTeLinkNotDegraded" is an index for a table
>    W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
>       "lmpDataLinkVerificationFailure" is an index for a table
>    W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
>       specified for "lmpCcOperStatus"
>    W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
>       specified for "lmpTeLinkOperStatus"
>    W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
>       specified for "lmpDataLinkActiveOperStatus"
>    W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
>       specified for "lmpDataLinkPassiveOperStatus"
>
> smilint says:
>    .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
>      `InetAddress' object should have an accompanied preceding
>      `InetAdressType' object
>    .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
>      `InetAddress' object should have an accompanied preceding
>      `InetAdressType' object
>    .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
>      `InetAddress' objectshould have an accompanied preceding
>      `InetAdressType' object
>
> Some details:
> 1. lmpNbrNodeId OBJECT-TYPE
>       SYNTAX        InetAddress (SIZE(4))
>       MAX-ACCESS    not-accessible
>       STATUS        current
>       DESCRIPTION
>        "This is a unique index for an entry in the LmpNbrTable.
>         This value represents the remote Node ID. The Node ID
>         address type must be IPv4."
>       ::= { lmpNbrEntry 1 }
>    You do know that MIB modules need to be IPv6 friendly, no?
>    Is LMP itself such that it only works with IPv4? I doubt that
>    IESG will approve new protocols that do not support IPv6.
> 2. For these 2 objects:
>      lmpNbrRetransmitInterval  LmpRetransmitInterval,
>      lmpNbrRetryLimit          Unsigned32,
>    You may want to add some text as to howyou intend to deal with
>    congestion (RFC 2914). This over UDP if I remember well?
>    I think it would be good to point explicitly to the text in lmp
>    document (sect 10).
> 3. lmpNbrRowStatus 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. All read-create objects
>         can only be changed when lmpNbrRowStatus is active."
>    That sounds strange. The notInService status was specifically
>    created to allow changes for cases where changes were not allowed
>    while row was active. Here you say it MUST be active in order
>    to make changes? Or did you mean "can not be changed"?
>    This occurs in more (maybe all) RowStatus objects in this doc.
> 4. You have some objedts that are not part of a table, yet are
>    read-write. For example
>        lmpAdminStatus
>        lmpCcHelloIntervalDefault
>        lmpCcHelloIntervalDefaultMin
>        ... and more ...
>    What is the persistency behaviour of these objects?
>    In other words: is the value preserved over a reboot?
> 5. Is lmpCcIsIf not redundant? The way I read it, then if the
>    lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
>    an interface, no?
> 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
>    In the telink MIB you have done things correctly and as presscribe
>    by RFC3291. Here you have not. Why ?
>    Even in this doc you have done it correctly in some places.
> 7. Mmmmmm??? 52 counters to "measure the performance" of the LMP channels?
>    Sounds overwhelming to me.
> 8. Formally, every Counterxx object needs to include in its descritpion
>    clause which object indicates a potential discontinuity. I understand
>    that they all are covered by lmpCcCounterDiscontinuityTime in the
>    same row. Maybe write something about that in the ...Entry description
>    clause as well if you do not want to add text to every Counter
> 9. lmpTeLinkTable
>    DESCRIPTION
>        "This table contains a collection of TE link."
>    Means what??
> 10. lmpLinkVerificationInterval
>     What does a value of zero mean?
>     Any comments regarding possible congestiuon if the value is set to
>     a very small number of msecs?
> 11. lmpLinkVerificationTable
>     Or is it better namep lmpTeLinkLinkVerificationTable
>     and then rename objects as well? If is correct name,
>     Then maybe rename
>        lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
>        lmpTeLinkWavelength     to lmpLinkVerificationTeLinkWavelength
> 12. lmpVerifyTransportMechanism
>     There are a few TBDs in there. Better decide before you submit to AD
> 13. lmpTeLinkBitRate
>      DESCRIPTION
>        "This is the bit rate at which the Test messages will be
>         transmitted and is expressed in bytes per second."
>     A BIT rate that gest expressed in BYTES per second?
>     Possible of course but strange, no? Why not call it ByteRate?
> 14. Another 40 or so counters for lmpTeLinkPerfTable ???
> 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>        OBJECTS       { ifIndex,
>                        lmpDataLinkRemoteIfId }
>     The second object already (implicitly) also contains the value
>     of the first object (it is the index part of the OID).
> 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
>     them. But when they are enabled, what kind of rates per second
>     should we fear for in a worst case conidition?
>     Pls think about both an agent (i.e. an LMP node) generating
>     them, but also think about a SNMP management station receiving
>     them from potentially 100s or 1000s of LMP nodes.
> 17. On page 7 I see:
>       lmpDataLinkAddressType          = unnumbered(1),
>     Mm... that is not a valid value for an InetAddressType
>
> 18. Security COnsiderations
>     You are not following the guidelines to describe first the
>     SET (read-write, read-create) issues/concerns/vulnerabilities
>     and then the read-only sensistivities. So I would not be
>     surprised to see push back from the Security front.
>
> I have done a pretty serious review... but not exhaustive.
>
> Thanks,
>
> Bert
> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: maandag 1 september 2003 20:14
> To: 'Martin Dubuc'; Wijnen, Bert (Bert)
> Subject: RE: LMP MIB
>
>
> I have it on my todo-list. I am currently checking te-link mib.
>
>
> Thanks,
> Bert
> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: maandag 1 september 2003 19:55
> To: Bert Wijnen
> Subject: LMP MIB
>
>
> Bert,
>
> I know you have been quite busy with all the MPLS drafts. I just wanted to
know if you had time review the LMP MIB draft and if not, when you think
you'll get around reviewing it.
>
> Regards,
>
> Martin

Delivery-date: Wed, 01 Oct 2003 20:06:50 +0000
From: "Martin Dubuc" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>
Cc: "Ccamp-wg \(E-mail\)" <[email-masked]>
Subject: Re: LMP MIB revision 6
Date: Wed, 24 Sep 2003 07:56:07 -0400

Bert,

After working on the document yesterday, I have some comments on your
original message.

First, with regards to the Node ID, LMP defines Node ID as a 4 octet field.
It usually maps to a 4-bytes IP address and is usually more of an internal
network address. I am not sure it makes sense to support IPv6 for this
field. I haven't heard that there was any proposal to change the Node ID to
support IPv6 format.

lmpCcIsIf is not redundant. In some implementations, control channel will be
mapped to interfaces, in other implementations, they will not. This object
is used as such indicator. In cases where the control channel is not mapped
as interface, it is true that the value of lmpCcUnderlyingIfIndex will be 0.
But in cases where control channels are mapped to interfaces,
lmpCcUnderlyingIfIndex could be set to 0 to indicate that the control
channels are not yet assigned/configured/discovered. So a value of 0 for
lmpCcUnderlyingIfIndex does not necessarily mean that control channel is not
an interface.

Concerning lmpCcRemoteAddressType and lmpCcRemoteCcAddr, I am not sure what
it is from TE link MIB that you like that you would like to see here as
well.

Regards,

Martin

----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Sent: Monday, September 01, 2003 4:42 PM
Subject: RE: LMP MIB revision 6

> Well well...
>
> SMICng says:
>    W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
>       "lmpDataLinkPropertyMismatch" is an index for a table
>    W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
>       "lmpTeLinkDegraded" is an index for a table
>    W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
>       "lmpTeLinkNotDegraded" is an index for a table
>    W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
>       "lmpDataLinkVerificationFailure" is an index for a table
>    W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
>       specified for "lmpCcOperStatus"
>    W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
>       specified for "lmpTeLinkOperStatus"
>    W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
>       specified for "lmpDataLinkActiveOperStatus"
>    W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
>       specified for "lmpDataLinkPassiveOperStatus"
>
> smilint says:
>    .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>      `up(1)' illegal in sub-type
>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>      `down(2)' illegal in sub-type
>    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>      `degraded(4)' illegal in sub-type
>    .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
>      `InetAddress' object should have an accompanied preceding
>      `InetAdressType' object
>    .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
>      `InetAddress' object should have an accompanied preceding
>      `InetAdressType' object
>    .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
>      `InetAddress' objectshould have an accompanied preceding
>      `InetAdressType' object
>
> Some details:
> 1. lmpNbrNodeId OBJECT-TYPE
>       SYNTAX        InetAddress (SIZE(4))
>       MAX-ACCESS    not-accessible
>       STATUS        current
>       DESCRIPTION
>        "This is a unique index for an entry in the LmpNbrTable.
>         This value represents the remote Node ID. The Node ID
>         address type must be IPv4."
>       ::= { lmpNbrEntry 1 }
>    You do know that MIB modules need to be IPv6 friendly, no?
>    Is LMP itself such that it only works with IPv4? I doubt that
>    IESG will approve new protocols that do not support IPv6.
> 2. For these 2 objects:
>      lmpNbrRetransmitInterval  LmpRetransmitInterval,
>      lmpNbrRetryLimit          Unsigned32,
>    You may want to add some text as to howyou intend to deal with
>    congestion (RFC 2914). This over UDP if I remember well?
>    I think it would be good to point explicitly to the text in lmp
>    document (sect 10).
> 3. lmpNbrRowStatus 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. All read-create objects
>         can only be changed when lmpNbrRowStatus is active."
>    That sounds strange. The notInService status was specifically
>    created to allow changes for cases where changes were not allowed
>    while row was active. Here you say it MUST be active in order
>    to make changes? Or did you mean "can not be changed"?
>    This occurs in more (maybe all) RowStatus objects in this doc.
> 4. You have some objedts that are not part of a table, yet are
>    read-write. For example
>        lmpAdminStatus
>        lmpCcHelloIntervalDefault
>        lmpCcHelloIntervalDefaultMin
>        ... and more ...
>    What is the persistency behaviour of these objects?
>    In other words: is the value preserved over a reboot?
> 5. Is lmpCcIsIf not redundant? The way I read it, then if the
>    lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
>    an interface, no?
> 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
>    In the telink MIB you have done things correctly and as presscribe
>    by RFC3291. Here you have not. Why ?
>    Even in this doc you have done it correctly in some places.
> 7. Mmmmmm??? 52 counters to "measure the performance" of the LMP channels?
>    Sounds overwhelming to me.
> 8. Formally, every Counterxx object needs to include in its descritpion
>    clause which object indicates a potential discontinuity. I understand
>    that they all are covered by lmpCcCounterDiscontinuityTime in the
>    same row. Maybe write something about that in the ...Entry description
>    clause as well if you do not want to add text to every Counter
> 9. lmpTeLinkTable
>    DESCRIPTION
>        "This table contains a collection of TE link."
>    Means what??
> 10. lmpLinkVerificationInterval
>     What does a value of zero mean?
>     Any comments regarding possible congestiuon if the value is set to
>     a very small number of msecs?
> 11. lmpLinkVerificationTable
>     Or is it better namep lmpTeLinkLinkVerificationTable
>     and then rename objects as well? If is correct name,
>     Then maybe rename
>        lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
>        lmpTeLinkWavelength     to lmpLinkVerificationTeLinkWavelength
> 12. lmpVerifyTransportMechanism
>     There are a few TBDs in there. Better decide before you submit to AD
> 13. lmpTeLinkBitRate
>      DESCRIPTION
>        "This is the bit rate at which the Test messages will be
>         transmitted and is expressed in bytes per second."
>     A BIT rate that gest expressed in BYTES per second?
>     Possible of course but strange, no? Why not call it ByteRate?
> 14. Another 40 or so counters for lmpTeLinkPerfTable ???
> 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>        OBJECTS       { ifIndex,
>                        lmpDataLinkRemoteIfId }
>     The second object already (implicitly) also contains the value
>     of the first object (it is the index part of the OID).
> 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
>     them. But when they are enabled, what kind of rates per second
>     should we fear for in a worst case conidition?
>     Pls think about both an agent (i.e. an LMP node) generating
>     them, but also think about a SNMP management station receiving
>     them from potentially 100s or 1000s of LMP nodes.
> 17. On page 7 I see:
>       lmpDataLinkAddressType          = unnumbered(1),
>     Mm... that is not a valid value for an InetAddressType
>
> 18. Security COnsiderations
>     You are not following the guidelines to describe first the
>     SET (read-write, read-create) issues/concerns/vulnerabilities
>     and then the read-only sensistivities. So I would not be
>     surprised to see push back from the Security front.
>
> I have done a pretty serious review... but not exhaustive.
>
> Thanks,
>
> Bert
> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: maandag 1 september 2003 20:14
> To: 'Martin Dubuc'; Wijnen, Bert (Bert)
> Subject: RE: LMP MIB
>
>
> I have it on my todo-list. I am currently checking te-link mib.
>
>
> Thanks,
> Bert
> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: maandag 1 september 2003 19:55
> To: Bert Wijnen
> Subject: LMP MIB
>
>
> Bert,
>
> I know you have been quite busy with all the MPLS drafts. I just wanted to
know if you had time review the LMP MIB draft and if not, when you think
you'll get around reviewing it.
>
> Regards,
>
> Martin

Delivery-date: Wed, 01 Oct 2003 19:24:33 +0000
Date: Wed, 17 Sep 2003 01:00:04 -0500 (CDT)
From: Andrea Fumagalli <[email-masked]>
To: Andrea Fumagalli <[email-masked]>
Subject: IEEE HPSR2004 - call for papers

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---559023410-1804928587-1063776519=:13441
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

Please, accept our apologies if multiple copies are received.

Andrea Fumagalli
Publicity Chair
IEEE HPSR2004

***********************************************************************
                           CALL FOR PAPERS

IEEE HPSR2004: Workshop on High Performance Switching and Routing
April 18-21, 2004, Phoenix, Arizona
http://hpsr2004.asu.edu
(or see pdf attached)

IMPORTANT DATES:
Full paper submissions due on ****** OCTOBER 15, 2003 ******
Notifications of acceptance distributed by January 15, 2004.
Camera-ready papers and registrations due on February 15, 2004.
***********************************************************************
---559023410-1804928587-1063776519=:13441
Content-Type: APPLICATION/PDF; NAME="HPSR2004CFP.pdf"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="HPSR2004CFP.pdf"

---559023410-1804928587-1063776519=:13441--