Adrian Farrel | 2 Jul 18:27 2004
Picon

Submission deadlines

Please be aware of the following submission deadlines for San Diego.

July 12, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET
July 19, Monday - Internet Draft final submission cut-off at 09:00 ET

Please try to get your submissions in as early as possible so that people have a good
chance of reading and discussing drafts before the meeting.

Thanks,
Adrian

Adrian Farrel | 6 Jul 22:57 2004
Picon

Publishing drafts

Please be aware that draft publications are being refused unless you precisely meet the
requirements expressed in
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg00244.html

In order not to miss the publication deadlines for San Diego, you will want to get your
drafts right first time.

Adrian

Adrian Farrel | 6 Jul 23:55 2004
Picon

CCAMP Agenda Planning

Hi,

We received several comments after the Seoul IETF about the format and quality of the
CCAMP meeting. The essence was that there were too many drafts and not enough time for
discussion.

In order to ensure that we meet the needs of the working group and, in particular, advance
our charter items and milestones, we will be focussing the San Diego meeting by topic
rather than by I-D. This may mean we miss out on a lot of drafts that may be of interest
to the WG, but since these drafts have not received a high level of debate on the mailing
list over the last two months there is no reason to assume that this is an urgent problem.
This approach will, however, buy us valuable discussion time for some important work.

As an early outline, the agenda will be something like the following (with some scope for
fine tuning as we go along). Please bring drafts that you feel are pertinent to the
attention of Kireeti and me (whether or not you are an author). Note, however, that drafts
need to be published in good time and should receive discussion on the mailing list.

Normal admin and WG status  [15 minutes]
ASON [20 minutes]
Protection and recovery [20 minutes]
Hello extensions [20 minutes]
Inter-area/AS TE [75 minutes]

Thanks,
Adrian

Arthi Ayyangar | 8 Jul 21:15 2004
Picon

Re: RE : RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

Hi JL,

Sorry for the delay in replying. Please see my answer below.

> And what about FRR: if I want FRR protection of ABRs with no impact on
> backup length and recovery delay, I definitely need contiguous LSPs.
> This is actually the only signaling mode allowing this service. Thus I
> prefer to signal directly the signaling mode "Contiguous LSP", rather
> than the required service, in order to avoid any misinterpretation of
> this service ...
----> I understand that you may want some control on the backup
path length. Even for intra-domain TE LSPs today, (which are contiguous),
depending on topology or constraints you may end up computing longer
paths than desired. So, in order to provide control on backup hops, one
probably specifies a constraint in backup path computation. Won't
specifying a similar constraint for inter-domain backup paths suffice ?
Ofcourse, the constraint may need to take into account forwarding hops
instead of control plane hops (aka RRO).

Also, I agree that with non-contiguous LSPs, you cannot merge back at
intermediate nodes between the FA-LSP or LSP segment end-points, that may
increase the number of forwarding nexthops for the backup. But, that is a
direct consequence of what any hierarchy does...information hiding.
However, even with contiguous LSPs, say for an inter-provider TE LSP
case, if the hops with the provider domain are not exposed via RRO (for
confidentiality reasons), you would still have the same issue. i.e.
you may need to merge back at the boundary node.

So, what I am trying to suggest is that these issues are not entirely tied
to a signaling method, (although there may be some which may be blatant with
(Continue reading)

Internet-Drafts | 9 Jul 21:23 2004
Picon

I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-02.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		: Exclude Routes - Extension to RSVP-TE
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-rsvp-te-exclude-route-02.txt
	Pages		: 23
	Date		: 2004-7-9
	
The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for
   LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
   Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
   abstract nodes and resources to be explicitly included in a path
   setup, but not to be explicitly excluded.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

A list of Internet-Drafts directories can be found in
(Continue reading)

Kireeti Kompella | 12 Jul 02:28 2004
Picon

New member of the ASON Routing Design Team

Hi All,

Just a heads up: John Drake will be joining the ASON Routing Design
Team.  His knowledge of GMPLS routing as well as his expertise in
hierarchical routing (from his PNNI days) should enhance the skill set
already present in this DT.

John, welcome aboard!

Kireeti.
-------

Jean Philippe Vasseur | 13 Jul 16:17 2004
Picon

Re: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt

Hi Adrian,

At 04:42 PM 4/21/2004 +0100, Adrian Farrel wrote:
>Hi JP,
>Please find attached a version of your draft with a bunch of comments, 
>nits and questions.
>Cheers,
>Adrian
>PS Please see RFC3667 for new copyright and IPR boilerplate (or use one of 
>the IETF
>editing tools)

Thanks a lot for your comments, they have been incorporated in 
draft-vasseur-ccamp-loose-path-reopt-02.txt.

Cheers.

JP.

>----- Original Message -----
>From: "Jean Philippe Vasseur" <jvasseur <at> cisco.com>
>To: <ccamp <at> ops.ietf.org>
>Sent: Tuesday, April 20, 2004 4:08 AM
>Subject: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt
>
>>Hi,
>>Just to mention that we posted a new revision of
>>draft-vasseur-ccamp-loose-path-reopt-01.txt that proposes some mechanisms
>>for the reoptimization of loosely routed TE LSP (intra-area, inter-area and
>>Inter-AS). Thanks for the various comments and support that we got on this
(Continue reading)

Tomonori TAKEDA | 14 Jul 06:42 2004
Picon

Re: CCAMP Agenda Planning

Hi,

In the last IETF meeting and following mailing list discussion, there is 
considerable level of interest in L1VPNs. Would it be possible to have some 
time to discuss L1VPNs in the CCAMP meeting, if time allows ?

Related documents :
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt 
(revision planned)
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-00.txt

Also :
http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt

At 22:55 04/07/06 +0100, Adrian Farrel wrote:
>Hi,
>
>We received several comments after the Seoul IETF about the format and 
>quality of the
>CCAMP meeting. The essence was that there were too many drafts and not 
>enough time for
>discussion.
>
>In order to ensure that we meet the needs of the working group and, in 
>particular, advance
>our charter items and milestones, we will be focussing the San Diego 
>meeting by topic
>rather than by I-D. This may mean we miss out on a lot of drafts that may 
>be of interest
(Continue reading)

Richard Rabbat | 14 Jul 20:43 2004

Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies

Dear all,
 
Please take a look at our new draft:
Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies available at:
This draft presents the results of a survey about carrier interest in shared mesh restoration, their requirements and their concerns. We have tried to be as encompassing as possible going to carriers in Europe, Asia and North America.
We are hoping to include input from more carriers and would like to ask the community in general and the carriers in particular to let us know what new information they would like to see surveyed in the next update.
 
Basically, we have the following questions:
- Are you interested in GMPLS-based solutions to the requirements?
- Can you suggest additional contacts to enable us to reach more carriers and get their feedback?
- Have we overlooked any aspect of restoration for shared mesh?
- What additional questions would you like to see?

Some of the surveyed carriers have already provided inputs on this and we'd like to ask others to give us their comments as well. 

Thanks,

Richard.

 
Internet-Drafts | 15 Jul 21:21 2004
Picon

I-D ACTION:draft-ietf-ccamp-sdhsonet-control-03.txt

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

	Title		: Framework for GMPLS-based Control of SDH/SONET Networks
	Author(s)	: G. Bernstein, et al.
	Filename	: draft-ietf-ccamp-sdhsonet-control-03.txt
	Pages		: 30
	Date		: 2004-7-15
	
The suite of protocols that defines Multi-Protocol Label Switching 
(MPLS) is in the process of enhancement to generalize its 
applicability to the control of non-packet based switching, that is, 
optical switching.  One area of prime consideration is to use these 
generalized MPLS (GMPLS) protocols in upgrading the control plane of 
optical transport networks.  This document illustrates this process 
by describing those extensions to MPLS protocols that are directed 
towards controlling SONET/SDH networks.  SONET/SDH networks make 
very good examples of this process since they possess a rich 
multiplex structure, a variety of protection/restoration options, 
are well defined, and are widely deployed. The document discusses 
extensions to MPLS routing protocols to disseminate information 
needed in transport path computation and network operations, 
together with the extensions to MPLS label distribution protocols 
needed for the provisioning of transport circuits. New capabilities 
that an MPLS control plane would bring to SONET/SDH networks, such 
as new restoration methods and multi-layer circuit establishment, 
are also discussed.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-sdhsonet-control-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:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-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.
Attachment: message/external-body, 146 bytes

Gmane