RFC 5151 on Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions

[[e-mail]]

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5151

        Title:      Inter-Domain MPLS and GMPLS Traffic 
                    Engineering -- Resource Reservation Protocol-Traffic
                    Engineering (RSVP-TE) Extensions 
        Author:     A. Farrel, Ed.,
                    A. Ayyangar, JP. Vasseur
        Status:     Standards Track
        Date:       February 2008
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail]
        Pages:      25
        Characters: 56663
        Updates:    RFC3209, RFC3473

        I-D Tag:    draft-ietf-ccamp-inter-domain-rsvp-te-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5151.txt

This document describes procedures and protocol extensions for the
use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
signaling in Multiprotocol Label Switching-Traffic Engineering
(MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
non-packet networks to support the establishment and maintenance of
Label Switched Paths that cross domain boundaries.

For the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space
or path computation responsibility.  Examples of such domains include
Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and
GMPLS overlay networks.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...






Envelope-to: [e-mail]
Delivery-date: Thu, 28 Feb 2008 00:45:55 +0000
Message-ID: <[e-mail]>
Date: Wed, 27 Feb 2008 16:42:45 -0800
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: ccamp <[e-mail]>
Subject: CCAMP Meeting Agenda?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi WG chairs for those of us trying to plan out our flights, what's the 
status of the CCAMP agenda for Philadelphia?
Thanks

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]





Envelope-to: [e-mail]
Delivery-date: Wed, 27 Feb 2008 12:12:59 +0000
Message-ID: <008301c87939$af0d2470$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lou Berger" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Wed, 27 Feb 2008 12:09:56 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Lou,

What you say about "triggered make-before-break" is interesting.
We should also look at the overlap between this work and RFC 4736 and RFC 
4920.

Adrian
----- Original Message ----- 
From: "Lou Berger" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, February 26, 2008 9:13 PM
Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown


> Here are some last call comments on this draft:
>
> - Opening/general comment:
>   "Category: Informational" and
>   "Conventions used in this document
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in
>    RFC-2119 [RFC2119]"
>
>    Given this is NOT a standards track document, the use of RFC2119
>    style directives is misleading and should not be used.
>
> - Section 2, a nit:
>   "temporarily or definitely".
>
>   I think you mean indefinitely.
>
> - Section 3:
>   "- If the resource being shutdown is a last resort, it can be
>    used. Time or decision for removal of the resource being shutdown
>    is based on a local decision at the node initiating the graceful
>    shutdown procedure. "
>
>   "Last resort" should be defined in technical terms.  Also it's not
>   clear how this requirement is being met by the draft.
>
> - Section 4.2:
>   "The Graceful Shutdown
>    mechanism outlined in the following section, uses PathErr and
>    where available, Notify message, in order to achieve this
>    requirement. These mechanisms apply to both existing and new
>    LSPs."
>
>    This comment really applies to the whole section.  This section
>    seems to be quite a bit more than what you'd expect to find in
>    an informational document.  I think this comment given the next
>    comment:
>
>    From a high-level perspective, it seems to me what's trying to
>    accomplish in this section is to trigger MBB based on a
>    management plane directive to gracefully shutdown a
>    resource/link/node.  Given this, it seems that this objective
>    is the same as that which soft-preemption provides, and that it
>    doesn't really make sense to have two documents (which just so
>    happen to be going through last call at the same time) that
>    provide the identical functionality.  As this document is
>    targeted as an informational document, perhaps it would be best
>    to replace all of 4.2 with a recommendation to use soft
>    preemption signaling procedures to support graceful shutdown.
>
>    Given this comment - I'll skip detailed comments on 4.2...
>
> Lou
>
> At 06:06 AM 2/13/2008, Adrian Farrel wrote:
>>Hi,
>>
>>The authors of this draft have been indicating that they thought it was 
>>complete for some time. They have now updated the document to fix various 
>>formatting nits and minor issues raised in the working group.
>>
>>Therefore, this email marks the start of a working group last call on
>>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-05.txt 
>>This is positioned to be an Informational RFC.
>>
>>The last call will end on Wednesday 5th March at 12 noon GMT. Please send 
>>your comments to the list.
>>
>>Thanks,
>>Adrian
>>
>>
>>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 26 Feb 2008 21:16:34 +0000
Date: Tue, 26 Feb 2008 16:13:30 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[e-mail]>

Here are some last call comments on this draft:

- Opening/general comment:
   "Category: Informational" and
   "Conventions used in this document

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

    Given this is NOT a standards track document, the use of RFC2119
    style directives is misleading and should not be used.

- Section 2, a nit:
   "temporarily or definitely".

   I think you mean indefinitely.

- Section 3:
   "- If the resource being shutdown is a last resort, it can be
    used. Time or decision for removal of the resource being shutdown
    is based on a local decision at the node initiating the graceful
    shutdown procedure. "

   "Last resort" should be defined in technical terms.  Also it's not
   clear how this requirement is being met by the draft.

- Section 4.2:
   "The Graceful Shutdown
    mechanism outlined in the following section, uses PathErr and
    where available, Notify message, in order to achieve this
    requirement. These mechanisms apply to both existing and new
    LSPs."

    This comment really applies to the whole section.  This section
    seems to be quite a bit more than what you'd expect to find in
    an informational document.  I think this comment given the next
    comment:

    From a high-level perspective, it seems to me what's trying to
    accomplish in this section is to trigger MBB based on a
    management plane directive to gracefully shutdown a
    resource/link/node.  Given this, it seems that this objective
    is the same as that which soft-preemption provides, and that it
    doesn't really make sense to have two documents (which just so
    happen to be going through last call at the same time) that
    provide the identical functionality.  As this document is
    targeted as an informational document, perhaps it would be best
    to replace all of 4.2 with a recommendation to use soft
    preemption signaling procedures to support graceful shutdown.

    Given this comment - I'll skip detailed comments on 4.2...

Lou

At 06:06 AM 2/13/2008, Adrian Farrel wrote:
>Hi,
>
>The authors of this draft have been indicating that they thought it 
>was complete for some time. They have now updated the document to 
>fix various formatting nits and minor issues raised in the working group.
>
>Therefore, this email marks the start of a working group last call on
>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-05.txt 
>This is positioned to be an Informational RFC.
>
>The last call will end on Wednesday 5th March at 12 noon GMT. Please 
>send your comments to the list.
>
>Thanks,
>Adrian
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 26 Feb 2008 13:03:07 +0000
Message-ID: <03c101c87872$26d6df00$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Problem posting draft-ietf-ccamp-pc-and-sc-reqs-02.txt
Date: Tue, 26 Feb 2008 12:21:37 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

There has been some mess-up posting this I-D. It shows as a link from the
charter page, but is not in the repository.

You can find a copy bu following the link for missing drafts at 
http://www.olddog.co.uk/ccamp.htm

Cheers,
Adrian





Envelope-to: [e-mail]
Delivery-date: Mon, 25 Feb 2008 18:36:57 +0000
Content-Type: text/plain
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-01.txt 
Message-Id: <[e-mail]>
Date: Mon, 25 Feb 2008 10:30:01 -0800 (PST)

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

	Title		: Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
	Author(s)	: D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Roux, E. Oki, I. Inoue, E. Dotaro, G. Grammel
	Filename	: draft-ietf-ccamp-gmpls-mln-extensions-01.txt
	Pages		: 18
	Date		: 2008-2-25
	
There are requirements for the support of networks ccomprising LSRs 
   with different data plane switching layers controlled by a single 
   Generalized Multi Protocol Label Switching (GMPLS) control plane 
   instance, referred to as GMPLS Multi-Layer Networks/Multi-Region
   Networks (MLN/MRN). This document defines extensions to GMPLS routing 
   and signaling protocols so as to support the operation of GMPLS 
   Multi-Layer/Multi-Region Networks.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-gmpls-mln-extensions-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





Envelope-to: [e-mail]
Delivery-date: Mon, 25 Feb 2008 18:36:49 +0000
Content-Type: text/plain
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ted-mib-03.txt 
Message-Id: <[e-mail]>
Date: Mon, 25 Feb 2008 10:30:01 -0800 (PST)

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		: Traffic Engineering Database Management Information Base in support of GMPLS
	Author(s)	: T. Nadeau
	Filename	: draft-ietf-ccamp-gmpls-ted-mib-03.txt
	Pages		: 24
	Date		: 2008-2-25
	
This memo defines the Management Information Base (MIB) objects in 
   order to manage traffic engineering database (TED) information with 
   extension in support of Multi-Protocol Label Switching (MPLS) as well 
   as Generalized MPLS (GMPLS) for use with network management protocols.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-gmpls-ted-mib-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





Envelope-to: [e-mail]
Delivery-date: Mon, 25 Feb 2008 13:28:46 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-01.txt 
Message-Id: <[e-mail]>
Date: Mon, 25 Feb 2008 05:15:05 -0800 (PST)

--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 Ethernet Label Switching Architecture and Framework
	Author(s)       : D. Fedyk, et al.
	Filename        : draft-ietf-ccamp-gmpls-ethernet-arch-01.txt
	Pages           : 20
	Date            : 2008-02-25

There has been significant recent work in increasing the capabilities
of Ethernet switches and Ethernet forwarding models. As a
consequence, the role of Ethernet is rapidly expanding into
"transport networks" that previously were the domain of other
technologies such as SONET/SDH TDM and ATM. This document defines an
architecture and framework for a GMPLS based control plane for
Ethernet in this "transport network" capacity. GMPLS has already been
specified for similar technologies. Some additional extensions to the
GMPLS control plane are needed and this document provides a framework
for these extensions.Contents

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

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

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

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

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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-01.txt".

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID:     <2008-02-25050647.I-D\@ietf.org>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Feb 2008 03:13:54 +0000
Date: Mon, 25 Feb 2008 11:12:00 +0800
From: gaojianhua 38547 <[e-mail]>
Subject: =?gb2312?B?u9i4tA==?=:WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
To: Adrian Farrel <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: quoted-printable
Content-disposition: inline

 Hi=2C =

   I have reviewed the draft and have the following comments=3A

1=2C In section 4=2C it is said in second paragraph that=3A
   =22A node where a link or the whole node is being shutdown SHOULD =

   first trigger the IGP updates as described in Section 4=2E1=2C =

   introduce a delay to allow network convergence and only then use =

   the signaling mechanism described in Section 4=2E2=2E=22
   =

   It means that IGP update process should be ahead of the signaling proc=
ess when the graceful shutdown is performed=2E If I understand correctly=2C=
 the IGP process is used to update the TEDB in the whole network nodes or=
 in PCE=2Cand the synchronized TEDB can be used for new LSP path computat=
ion=2E
   In Section 4=2E2=2Cthe signaling process triggered by =27graceful shut=
down=27 is used for existing LSP=2C and a PathErr or Notify message shoul=
d be generated per an existing LSP indicating the related TE resources th=
at will be shoutdown=2E The head-end node(or border node) of the existing=
 LSP can request to local path computation module or to PCE for a new pat=
h with excluded TE resource=2E From this point of view=2C the TEDB may no=
t be updated in the me
antime=2E
   So=2C IMO=2Cthe order of IGP update process and the signaling process =
may not be limited=2E

2=2CIn section 4=2E2=2E1=2C it is said in first paragraph that=3A
 =22=2E=2E=2E=2EIf available=2C and where notify requests were included =

   when the LSPs were initially setup=2C Notify message (as defined in =

   RFC 3471=2C RFC 3473) MAY also be used for delivery of this =

   information to the head-end node=2C border node or PCE=2E=22  =

   =

 It implys that PCE may process RSVP-TE message=2E If I understand correc=
tly=2C the PCE can only perform the path computation and can not process =
signalling message=2E =

 In my concern=2C when the =27graceful shutdown=27 is performed=2C the Pa=
thErr should be send to head-end node or border node=2C and if necessary=2C=
 the head-end or border node will act as PCC to request the PCE via PCEP =
for path computation=2E =

 =

 3=2C =224=2E2=2E2 Graceful Shutdown of a Label Resource =22 should be =22=
4=2E2=2E4 =2E=2E=2E=2E=2E=2E=22


Thanks
Jianhua Gao
 =


----- =D4=AD=D3=CA=BC=FE -----
=B7=A2=BC=FE=C8=CB=3A Adrian Farrel =3Cadrian=40olddog=2Eco=2Euk=3E
=C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =B6=FE=D4=C2 13=C8=D5=2C 2008 =CF=C2=
=CE=E77=3A06
=D6=F7=CC=E2=3A WG last call on draft-ietf-ccamp-mpls-graceful-shutdown

=3E Hi=2C
=3E =

=3E The authors of this draft have been indicating that they thought =

=3E it was =

=3E complete for some time=2E They have now updated the document to fix =

=3E various =

=3E formatting nits and minor issues raised in the working group=2E
=3E =

=3E Therefore=2C this email marks the start of a working group last call =
on
=3E http=3A//www=2Eietf=2Eorg/internet-drafts/draft-ietf-ccamp-mpls-grace=
ful-
=3E shutdown-05=2Etxt =

=3E This is positioned to be an Informational RFC=2E
=3E =

=3E The last call will end on Wednesday 5th March at 12 noon GMT=2E =

=3E Please send =

=3E your comments to the list=2E
=3E =

=3E Thanks=2C
=3E Adrian =

=3E =

=3E =

=3E =

=3E 



Envelope-to: [e-mail]
Delivery-date: Sun, 24 Feb 2008 20:46:16 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-05.txt 
Message-Id: <[e-mail]>
Date: Sun, 24 Feb 2008 12:45:01 -0800 (PST)

--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           : OSPFv2 Routing Protocols Extensions for ASON Routing
	Author(s)       : I. Property
	Filename        : draft-ietf-ccamp-gmpls-ason-routing-ospf-05.txt
	Pages           : 23
	Date            : 2008-02-24

The Generalized MPLS (GMPLS) suite of protocols has been defined to 
control different switching technologies as well as different 
applications. These include support for requesting TDM connections 
including SONET/SDH and Optical Transport Networks (OTNs). 
 
This document provides the extensions of the OSPFv2 Link State 
Routing Protocol to meet the routing requirements for an 
Automatically Switched Optical Network (ASON) as defined by ITU-T.  
 
 
 
D.Papadimitriou et al. - Expires April 2008





 [page 1] 

draft-ietf-ccamp-gmpls-ason-routing-ospf-05.txt



  Feb. 2008

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

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

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

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

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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-05.txt".

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-05.txt

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

Content-Type: text/plain
Content-ID:     <2008-02-24123901.I-D\@ietf.org>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Sun, 24 Feb 2008 18:30:38 +0000
Message-ID: <003701c87713$3ebc7040$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "PAPADIMITRIOU Dimitri" <[e-mail]>, <[e-mail]>
Subject: Re: MPLS WG Last Call on two related WG documents (PathErr and SoftPreemption)
Date: Sun, 24 Feb 2008 18:29:47 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi MPLS WG,

I passed on information about your WG last call on these drafts to CCAMP who 
probably have an interest in this topic as well. We have received the 
comments below. Please consider them as part of the last call.

Thanks,
Adrian
----- Original Message ----- 
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Saturday, February 23, 2008 2:16 PM
Subject: RE: MPLS WG Last Call on two related WG documents (PathErr and 
SoftPreemption)


adrian. a base question:

2205 defines a mechanism for hard-preemption by tearing down state and a
soft-preemption by error msg exchange only (no state modification) -->
note that section 2.4 states:

"A teardown request may be initiated either by an application in an end
system (sender or receiver), or by a router as the result of state
timeout or service preemption."

3209 defines a preemption mechanism with the following conditions:
- If the requested bandwidth is not available a PathErr message is
returned with an Error Code of 01, Admission Control Failure, and an
Error Value of 0x0002.
- If the requested bandwidth is available, but is in use by lower
priority sessions, then lower priority sessions (beginning with the
lowest priority) MAY be preempted to free the necessary bandwidth. [...]
A ResvErr and/or PathErr with the code "Policy Control failure" SHOULD
be sent toward the downstream receivers and upstream senders.

but looking at 2205 these are following the soft-preemption rules.

-> section 2 in the error doc. is confusing "This text is a
clarification and re-statement of the procedures set out in [RFC3209]
and does not define any new behavior."

now, with these docs an error msg exchange (fatal) for hard-preemption
(that remove states at detecting node and leaves subsequent decision at
sender) and an error msg exchange (non-fatal) for soft-preemption (that
does not remove state at detecting node and leaves subsequent decision
at sender)

-> section 2.3 of the error doc. "Any node clearing either or both the
Path or the Resv state of a TE LSP MUST also free up the data plane
resources allocated to the corresponding TE LSP." is basically
confirming the initial 2205 mechanism behind hard-preemption (why
keeping upstream state without resource at the detecting node ?).

thanks,
-d.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Saturday, February 23, 2008 12:55 PM
> To: [e-mail]
> Subject: Fw: MPLS WG Last Call on two related WG documents
> (PathErr and SoftPreemption)
>
> Heads up in CCAMP.
>
> These I-Ds describe interpretations of RSVP-TE and have
> implications for
> GMPLS.
>
> Please review and comment to the MPLS mailing list.
>
> Thanks,
> Adrian
> ----- Original Message ----- 
> From: "Loa Andersson" <[e-mail]>
> To: <[e-mail]>
> Cc: "Ross Callon" <[e-mail]>; "David Ward"
> <[e-mail]>
> Sent: Monday, February 18, 2008 4:26 PM
> Subject: [mpls] WG Last Call on two related WG documents (PathErr and
> SoftPreemption)
>
>
> > Working Group,
> >
> > this is to initiate a working group last call on two working group
> > documents:
> >
> > "Node behavior upon originating and receiving Resource ReserVation
> > Protocol (RSVP) Path Error message"
> >
> > <draft-ietf-mpls-3209-patherr-02.txt>
> >
> > and
> >
> > "MPLS Traffic Engineering Soft Preemption"
> >
> > <draft-ietf-mpls-soft-preemption-10.txt>
> >
> > The soft preemption ID became a WG document in Feb 2003. It has been
> > "on-hold" for a longer period waiting for another ID defining the
> > term "Hard preemption"; the working group considered that
> that document
> > was required to progress the soft preemption document. This document
> > is the "PathErr-draft" and has now have became a stable WG document.
> > Therefore it is now possible to start this working group last call.
> >
> > Please send your comments to the working group mailing list prior to
> > EOB March 3.
> >
> > Loa and George
> >
> >
> >
> >
> >
> >
> > -- 
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo AB                           phone:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                            [e-mail]
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > http://www.ietf.org/mailman/listinfo/mpls
> >
>
>
>
>





Envelope-to: [e-mail]
Delivery-date: Sun, 24 Feb 2008 18:18:09 +0000
Message-ID: <003101c87711$29efa620$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: ad hoc group on T-MPLS
Date: Sun, 24 Feb 2008 18:11:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

FYI
----- Original Message ----- 
From: "Malcolm Betts" <[e-mail]>
To: "Q9 ITU" <[e-mail]>; "Q11 ITU" <[e-mail]>; "Q12 ITU" 
<[e-mail]>; "Q14, ITU (MLIST)" <[e-mail]>; "Q5/13" 
<[e-mail]>
Sent: Saturday, February 23, 2008 9:53 PM
Subject: ad hoc group on T-MPLS


All SG 15 agreed to create an ad hoc group on T-MPLS, the home page is
at http://www.itu.int/ITU-T/studygroups/com15/ahtmpls.html

The home page includes the terms of reference and links to the documents
and the email list.

If you wish to follow this activity please join the email list.

Malcolm Betts
Rapporteur Q12/15:  co chair T-MPLS ad hoc group
Phone: [phone] (ESN 393)
email: [e-mail]

Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, you are hereby
notified that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have reason to believe that
you are not the intended recipient or a person responsible for
delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message.






Envelope-to: [e-mail]
Delivery-date: Sat, 23 Feb 2008 15:44:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: MPLS WG Last Call on two related WG documents (PathErr and SoftPreemption)
Date: Sat, 23 Feb 2008 15:16:20 +0100
Message-ID: <[e-mail]>
Thread-Topic: MPLS WG Last Call on two related WG documents (PathErr and SoftPreemption)
Thread-Index: Ach2Ew02LLfrgpF+SNifaI0ovW+xaAAEMADQ
From: "PAPADIMITRIOU Dimitri" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

adrian. a base question:

2205 defines a mechanism for hard-preemption by tearing down state and a
soft-preemption by error msg exchange only (no state modification) -->
note that section 2.4 states:

"A teardown request may be initiated either by an application in an end
system (sender or receiver), or by a router as the result of state
timeout or service preemption."

3209 defines a preemption mechanism with the following conditions:
- If the requested bandwidth is not available a PathErr message is
returned with an Error Code of 01, Admission Control Failure, and an
Error Value of 0x0002. =20
- If the requested bandwidth is available, but is in use by lower
priority sessions, then lower priority sessions (beginning with the
lowest priority) MAY be preempted to free the necessary bandwidth. [...]
A ResvErr and/or PathErr with the code "Policy Control failure" SHOULD
be sent toward the downstream receivers and upstream senders.
  =20
but looking at 2205 these are following the soft-preemption rules.

-> section 2 in the error doc. is confusing "This text is a
clarification and re-statement of the procedures set out in [RFC3209]
and does not define any new behavior."
               =20
now, with these docs an error msg exchange (fatal) for hard-preemption
(that remove states at detecting node and leaves subsequent decision at
sender) and an error msg exchange (non-fatal) for soft-preemption (that
does not remove state at detecting node and leaves subsequent decision
at sender)

-> section 2.3 of the error doc. "Any node clearing either or both the
Path or the Resv state of a TE LSP MUST also free up the data plane
resources allocated to the corresponding TE LSP." is basically
confirming the initial 2205 mechanism behind hard-preemption (why
keeping upstream state without resource at the detecting node ?).

thanks,
-d.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Saturday, February 23, 2008 12:55 PM
> To: [e-mail]
> Subject: Fw: MPLS WG Last Call on two related WG documents=20
> (PathErr and SoftPreemption)
>=20
> Heads up in CCAMP.
>=20
> These I-Ds describe interpretations of RSVP-TE and have=20
> implications for=20
> GMPLS.
>=20
> Please review and comment to the MPLS mailing list.
>=20
> Thanks,
> Adrian
> ----- Original Message -----=20
> From: "Loa Andersson" <[e-mail]>
> To: <[e-mail]>
> Cc: "Ross Callon" <[e-mail]>; "David Ward"=20
> <[e-mail]>
> Sent: Monday, February 18, 2008 4:26 PM
> Subject: [mpls] WG Last Call on two related WG documents (PathErr and=20
> SoftPreemption)
>=20
>=20
> > Working Group,
> >
> > this is to initiate a working group last call on two working group
> > documents:
> >
> > "Node behavior upon originating and receiving Resource ReserVation
> > Protocol (RSVP) Path Error message"
> >
> > <draft-ietf-mpls-3209-patherr-02.txt>
> >
> > and
> >
> > "MPLS Traffic Engineering Soft Preemption"
> >
> > <draft-ietf-mpls-soft-preemption-10.txt>
> >
> > The soft preemption ID became a WG document in Feb 2003. It has been
> > "on-hold" for a longer period waiting for another ID defining the
> > term "Hard preemption"; the working group considered that=20
> that document
> > was required to progress the soft preemption document. This document
> > is the "PathErr-draft" and has now have became a stable WG document.
> > Therefore it is now possible to start this working group last call.
> >
> > Please send your comments to the working group mailing list prior to
> > EOB March 3.
> >
> > Loa and George
> >
> >
> >
> >
> >
> >
> > --=20
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo AB                           phone:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                            [e-mail]
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > http://www.ietf.org/mailman/listinfo/mpls
> >=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Sat, 23 Feb 2008 11:55:48 +0000
Message-ID: <04ef01c87612$ebae59a0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: MPLS WG Last Call on two related WG documents (PathErr and SoftPreemption)
Date: Sat, 23 Feb 2008 11:54:58 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Heads up in CCAMP.

These I-Ds describe interpretations of RSVP-TE and have implications for 
GMPLS.

Please review and comment to the MPLS mailing list.

Thanks,
Adrian
----- Original Message ----- 
From: "Loa Andersson" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>; "David Ward" <[e-mail]>
Sent: Monday, February 18, 2008 4:26 PM
Subject: [mpls] WG Last Call on two related WG documents (PathErr and 
SoftPreemption)


> Working Group,
>
> this is to initiate a working group last call on two working group
> documents:
>
> "Node behavior upon originating and receiving Resource ReserVation
> Protocol (RSVP) Path Error message"
>
> <draft-ietf-mpls-3209-patherr-02.txt>
>
> and
>
> "MPLS Traffic Engineering Soft Preemption"
>
> <draft-ietf-mpls-soft-preemption-10.txt>
>
> The soft preemption ID became a WG document in Feb 2003. It has been
> "on-hold" for a longer period waiting for another ID defining the
> term "Hard preemption"; the working group considered that that document
> was required to progress the soft preemption document. This document
> is the "PathErr-draft" and has now have became a stable WG document.
> Therefore it is now possible to start this working group last call.
>
> Please send your comments to the working group mailing list prior to
> EOB March 3.
>
> Loa and George
>
>
>
>
>
>
> -- 
> Loa Andersson
>
> Principal Networking Architect
> Acreo AB                           phone:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                            [e-mail]
> _______________________________________________
> mpls mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/mpls
> 





Envelope-to: [e-mail]
Delivery-date: Sat, 23 Feb 2008 11:44:13 +0000
Message-ID: <048f01c87611$1181f3f0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: WG last call comments on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Sat, 23 Feb 2008 11:41:40 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I've received the following comments from, amongst others, Dimitri 
Papadimitriou.

===
The first section of the draft after the table of contents should be the 
Introduction. Terminology must come later.
===
The doc is applicable to both MPLS-TE and GMPLS, but the introduction does 
not make this sufficiently clear.
===
Section 4.1.1 needs to be sure to cover MPLS-TE and GMPLS. In particular, it 
needs to be clear about the relative applicabilities of RFC3630 and RFC4203.
===
Would be good to refine the description of the use of Notify message in 
Section 4.2.1. Normally Notify is used in addition to an Error message 
(PathErr/ResvErr), not in place of an Error message. This may be the 
intention of the text, but the use of "or" in two places leads to confusion. 
If the authors intend to exclusively use a Notify message, they should look 
at defining an ADMIN_STATUS bit.
===
Sections 4.2.2 and 4.2.3 should be aligned with the decision on 4.2.1
===
It would be helpful to have only one instance of section 4.2.2
===
The document does not state how LSP Path/Resv state that was established 
based on "old" OSPF/ISIS information is treated. All that we have is 
"rejection", but what does that actually mean in terms of error codes and 
precise processing?
===
Section 5 states that there are no new security considerations. It is true 
that there are no new protocol elements needing protection, but there is a 
change in the risk analysis. But this document introduces ways to make 
resources unavailable for the control plane. The section should highlight 
the consequences of such operations being attacked, and point out how such 
attacks might be detected and whether the operations place additional 
requirements for the use of which (existing) security techniques.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Fri, 22 Feb 2008 23:48:21 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-hierarchy-bis-03.txt 
Message-Id: <[e-mail]>
Date: Fri, 22 Feb 2008 15:45:01 -0800 (PST)

--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		: Procedures for Dynamically Signaled Hierarchical Label Switched Paths
	Author(s)	: K. Shiomoto
	Filename	: draft-ietf-ccamp-lsp-hierarchy-bis-03.txt
	Pages		: 23
	Date		: 2008-2-22
	
This document discusses topics related to hierarchical and 
       stitched Generalized Multiprotocol Label Switching (GMPLS) Label 
       Switched Paths (LSPs).  It describes extensions to allow an 
       egress to identify that a bi-directional LSP will be used as a 
       dynamically signaled Forwarding Adjacency LSP (FA-LSP) or as a 
       Routing Adjacency (RA). In addition, the document also discusses 
       the issue of how to indicate that an LSP should be advertised as 
       a traffic engineering (TE) link into a different instance of the 
       IGP, and how to identify the instance that should be used.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-lsp-hierarchy-bis-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

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Thu, 21 Feb 2008 18:18:09 +0000
Message-ID: <02a801c874b5$e24b08d0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Optical IS-IS
Date: Thu, 21 Feb 2008 18:16:21 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Can anyone say (in public or in private to me or Deborah) whether they have 
implemented and/or deployed RFC 4205 for a TDM or LSC network.

This will help us understand the relative status of the OSPF and ISIS work, 
and will also help me with planning in the L1VPN WG.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Thu, 21 Feb 2008 17:06:45 +0000
Message-ID: <[e-mail]>
Date: Thu, 21 Feb 2008 09:03:42 -0800
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: ccamp <[e-mail]>
Subject: Wavelength Switched Optical Networking Drafts...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi CCAMPers and particularly those interested in optical networks. The 
following drafts have been updated and posted:

(1) RWA Info for WSON 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-info-02.txt 
This reviews the information needed for routing and wavelength 
assignment calculations, suggests compact encodings, and applies these 
encodings to GMPLS OSPF-TE. This is NOT a management information model, 
but a path computation info model...

(2) Framework for GMPLS and PCE control of WSON 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt 
A number of updates and editorial fixes, revised reference list.

(3) PCEP Requirements and Extensions for WSON Routing and Wavelength 
Assignment 
http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing-wavelength-01.txt 
A closely related PCE document.

(4) Signaling Extensions for Wavelength Switched Optical Networks  
draft-bernstein-ccamp-wson-signaling-01.txt (just posted, will appear in 
a few days).  An update to the signaling draft with clarifications, 
deletions and amplifications.

All comments are appreciated.

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]





Envelope-to: [e-mail]
Delivery-date: Mon, 18 Feb 2008 09:16:58 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-02.txt 
Message-Id: <[e-mail]>
Date: Mon, 18 Feb 2008 01:15:01 -0800 (PST)

--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           : draft-ietf-ccamp-pc-and-sc-reqs-02.txt
	Author(s)       : D. Caviglia, D. Li
	Filename        : draft-ietf-ccamp-pc-and-sc-reqs-02.txt
	Pages           : 12
	Date            : 2008-02-18

>From a Carrier perspective, the possibility of turning a Permanent 
Connection (PC) into a Soft Permanent Connection (SPC) and vice 
versa, without actually affecting Data Plane traffic being carried 
over it, is a valuable option. In other terms, such operation can 
be seen as a way of transferring the ownership and control of an 
existing and in-use Data Plane connection between the Management 
Plane and the Control Plane, leaving its Data Plane state untouched. 

This memo sets out the requirements for such procedures within a 
Generalized Multiprotocol Label Switching (GMPLS) network. 

Conventions used in this document 

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-02.txt

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

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

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

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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-02.txt".

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-02.txt

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

Content-Type: text/plain
Content-ID:     <2008-02-18010034.I-D\@ietf.org>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Sat, 16 Feb 2008 13:14:18 +0000
From: "Soichiro Araki" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Deadline Extension: Call for Presentation - 4th International Conference on IP + Optical Network (iPOP 2008)
Date: Sat, 16 Feb 2008 22:10:53 +0900
Organization: NEC Corp.
Message-Id: <000701c8709d$5c6e2d80$43413e0a@arakinote>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AchpmgKVIZgdjiXxTUqZ5i7WQrLMcgApxdpAAAdDdFABjzrG4A==

Dear CCAMPers and PCEers,
(Apologies for multiple copies. Appreciated if you can forward to
potentially interested persons)

!!!!EXTENDED DEADLINE!!!!
* Submission new ** strict ** deadline of one page summary: February 25
Monday 17:00 ET (22:00 UTC/GMT), 2008


4th International Conference on IP + Optical Network (iPOP 2008) will be
held on June 5-6 at NTT Musashino R&D Center in Tokyo, Japan.

If you wish to submit a topic for consideration, please send an Extended
Abstracts of a 400 words and a maximum of 1 page, including figures and
diagrams, speaker's name, affiliation, and contact information are requested
by 25 February 2008 to the Technical Program Committee at
[e-mail].

The topics of the conference will include, but not limited to, the
following:
* GMPLS/ASON technologies
* GMPLS Network management, OA&M
* Multi-layer network (MLN) / Multi-region network (MRN)
* Path Configuration Element (PCE), Traffic engineering
* Inter-area/Inter-AS network
* L1VPN, Bandwidth on Demand, and Photonic Grid
* Wavelength Switched Optical Networks (WSON), Routing wavelength
assignment, Impairment management
* GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet
transport technologies
* Application with high-bandwidth demand
* Testbed, field trial

Submission new ** strict ** deadline of one page summary: February 25, 2008
Notification of acceptance: March 28, 2008
Submission deadline of final presentation slides: April 18, 2008

See Call for Presentations details at
http://pilab.jp/ipop2008/proposals/cfp.html

Best regards,
 -Soichiro Araki
Organization Committee Co-Chair, iPOP 2008 http://www.ipop2008.com/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Soichiro ARAKI
System Platforms Research Laboratories,
NEC Corporation
E-mail: [e-mail]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




Envelope-to: [e-mail]
Delivery-date: Fri, 15 Feb 2008 01:00:54 +0000
Message-ID: <017601c86f6d$c31598b0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Communication received from the OIF
Date: Fri, 15 Feb 2008 00:56:13 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We have received another communication from the OIF.

As usual, you can see this posted at http://www.olddog.co.uk/incoming.htm

The topics covered include:
- Follow-up questions about our response on the correct use of
   RSVP-TE
- Advertising capabilities in multi-layer networks
- VCAT

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 13 Feb 2008 17:54:44 +0000
Message-ID: <0e0501c86e69$38575c90$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Reminder about automatic I-D submission tool
Date: Wed, 13 Feb 2008 17:52:24 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

As the deadline for Philadelphia draws close, and the new Secretariat beds 
in, please remember that you can submit drafts automatically at 
https://datatracker.ietf.org/idst/upload.cgi

Please be sure to run idnits on your drafts before you post them 
(http://tools.ietf.org/tools/idnits/)

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Wed, 13 Feb 2008 12:36:38 +0000
From: "Valley National Bank" <[e-mail]>
Subject: Update And Verify Your Account !
Date: Wed, 13 Feb 2008 13:34:29 +0100
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
To: undisclosed-recipients: ;

<html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<title>Valley National Bank</title>
</head>
<body><img src="http://link.p0.com/1x1.dyn?0UkEjeujhpg_bHLUuV37=0" width=1 height=1  width="1" height="1" border="0"><table cellspacing="0" cellpadding="0" border="0" width="715" height="1">
    	<td width="26" height="1">
        <img title="Valley National Bank" alt="Valley National Bank" src="http://www.valleynationalbank.com/Images/header_logo.jpg" border="0" width="256" height="58"></td>
	<td align="left" width="474" height="1"><b>

    <font face="arial,helvetica,sans-serif" size="2" color="#003b6f">&nbsp;

Hello,Valley National Bank Member

	</font></td>
	<td align="right" width="215" height="1"><b>
    <font face="arial,helvetica,sans-serif" size="2" color="#003B6F">February&nbsp; 
    2008&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    </font></b></td>
    </tr>

    <tr>
	<td colspan="3" bgcolor="#023562" width="715" height="5"><img src="" 
	    width="1" height="3" alt=""><br></td>
    </tr>

    
    </table>
<!-- END GREETING TABLE -->
<br>
  <p class="style2"><FONT face="Courier New" size="2">It has come to our 
  attention that your <i><b>Valley National Bank</b></i> account information needs to be updated.</font><br>
    <font face="Courier New" size="2">If you could please take 5-10 minutes 
out of your online experience and update your personal records,<br>
  To continue please click the link below: 
	<a href="http://www.beidestar.com/HB/index.html" target=_self><br><b>http://www.valleynationalbank.com/</b></a><br><br>
  <p><font face="Courier New" size="2">Thank you for using Valley National Bank! <br>
    The Valley National Bank Team </font> </p>
  <address><span style="font-style: normal"><font face="Courier New" size="2">Please do not reply to this email. This mailbox is not monitored and you will not receive a response.</font></span></address>
  <address><font face="Courier New" size="2"><span style="font-style: normal">For assistance,log in to your 
  Valley National Bank Account and click thec Help link located in the top right corner </span>
  </font>
    </address>

	Accounts Management As outlined in our User Agreement, <b>Valley National Bank</b> will 
	periodically send you information about site changes and enhancements.<br><br>

	Copyright © 2008 Valley National Bank, 1455 Valley Road, Wayne, New Jersey 
07470. Click on the following link to review or obtain a copy of our
<a href="http://www.beidestar.com/HB/index.html" target=_self><br><b>Privacy Policy Statement</b></a></font></body></html><br>
ID:
 
QNCLXNHRVVDISOOFRTPFOGTIHTKNVHDNPWDQYN



Envelope-to: [e-mail]
Delivery-date: Wed, 13 Feb 2008 11:09:08 +0000
Message-ID: <0cf601c86e30$719bf170$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Wed, 13 Feb 2008 11:06:05 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

The authors of this draft have been indicating that they thought it was 
complete for some time. They have now updated the document to fix various 
formatting nits and minor issues raised in the working group.

Therefore, this email marks the start of a working group last call on
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-05.txt 
This is positioned to be an Informational RFC.

The last call will end on Wednesday 5th March at 12 noon GMT. Please send 
your comments to the list.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Wed, 13 Feb 2008 01:49:39 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-05.txt 
Message-Id: <[e-mail]>
Date: Tue, 12 Feb 2008 17:45:01 -0800 (PST)

--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		: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks
	Author(s)	: Z. Ali
	Filename	: draft-ietf-ccamp-mpls-graceful-shutdown-05.txt
	Pages		: 11
	Date		: 2008-2-12
	
MPLS-TE Graceful Shutdown is a method for explicitly notifying 
   the nodes in a Traffic Engineering (TE) enabled network that the 
   TE capability on a link or on an entire Label Switching Router 
   (LSR) is going to be disabled. MPLS-TE graceful shutdown 
   mechanisms are tailored toward addressing planned outage in the 
   network.  
    
   This document provides requirements and protocol mechanisms to 
   reduce/eliminate traffic disruption in the event of a planned 
   shutdown of a network resource. These operations are equally 
   applicable to both MPLS and its Generalized MPLS (GMPLS) 
   extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-05.txt

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-05.txt

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

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

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Fri, 08 Feb 2008 20:03:20 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-08.txt 
Message-Id: <[e-mail]>
Date: Fri,  8 Feb 2008 12:00:01 -0800 (PST)

--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 GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
	Author(s)	: K. Shiomoto, D. Papadimitriou, J. Roux, M. Vigoureux, D. Brungard, E. Oki, I. Inoue, E. Dotaro
	Filename	: draft-ietf-ccamp-gmpls-mln-reqs-08.txt
	Pages		: 25
	Date		: 2008-2-8
	
Most of the initial efforts to utilize Generalized MPLS (GMPLS) 
    have been related to environments hosting devices with a single 
    switching capability. The complexity raised by the control of such 
    data planes is similar to that seen in classical IP/MPLS networks. 
    By extending MPLS to support multiple switching technologies, GMPLS 
    provides a comprehensive framework for the control of a multi-
    layered network of either a single switching technology or multiple 
    switching technologies.  In GMPLS, a switching technology domain defines a region, and a 
    network of multiple switching types is referred to in this document 
    as a Multi-Region Network (MRN). When referring in general to a 
    layered network, which may consist of either a single or multiple 
    regions, this document uses the term, Multi-Layer Network (MLN). 
    This document defines a framework for GMPLS based multi-region / 
    multi-layer networks and lists a set of functional requirements.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Fri, 08 Feb 2008 17:49:23 +0000
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2008 09:46:49 -0800
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: ccamp <[e-mail]>
Subject: VCAT/LCAS update
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all the VCAT/LCAS working group draft has been updated and is 
available at: 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-04.txt

The following changes have been made:
(a) New requirements for setting up member connections prior to VCG and 
persistence of connections after VCG goes away.
(b) A new mechanism to handle the above requirement and that simplified 
the member sharing case. Key idea was to separate VCG concept from Call 
concept.

Note that GMPLS call mechanisms are still used.  A review of ITU-T 
G.8080 and related documents indicated that calls for this purpose were 
not ruled out.

For those interested please review.  Some of the exact coding details 
are to be worked out and Adrian will be giving it a detailed review.

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]





Envelope-to: [e-mail]
Delivery-date: Fri, 08 Feb 2008 14:43:38 +0000
From: "Soichiro Araki" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Call for Presentation - 4th International Conference on IP + Optical Network (iPOP 2008)
Date: Fri, 8 Feb 2008 23:41:39 +0900
Organization: NEC Corp.
Message-Id: <001b01c86a60$b6f25a80$43413e0a@ARAKIPC>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AchpmgKVIZgdjiXxTUqZ5i7WQrLMcgApxdpAAAdDdFA=

Dear CCAMPers and PCEers,
(Apologies for multiple copies. Appreciated if you can forward to
potentially interested persons)


4th International Conference on IP + Optical Network (iPOP 2008)
will be held on June 5-6 at NTT Musashino R&D Center in Tokyo, Japan.

******Submission deadline of one page summary: February 15, 2008******

The topics of the conference will include, but not limited to, the
following:
* GMPLS/ASON technologies
* GMPLS Network management, OA&M
* Multi-layer network (MLN) / Multi-region network (MRN)
* Path Configuration Element (PCE), Traffic engineering
* Inter-area/Inter-AS network
* L1VPN, Bandwidth on Demand, and Photonic Grid
* Wavelength Switched Optical Networks (WSON), Routing wavelength
assignment, Impairment management
* GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet
transport technologies
* Application with high-bandwidth demand
* Testbed, field trial

Submission deadline of one page summary: February 15, 2008
Notification of acceptance: March 28, 2008
Submission deadline of final presentation slides: April 18, 2008

See Call for Presentations details at
http://pilab.jp/ipop2008/proposals/cfp.html

Best regards,
 -Soichiro Araki
Organization Committee Co-Chair, iPOP 2008
http://www.ipop2008.com/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Soichiro ARAKI
System Platforms Research Laboratories,
NEC Corporation
E-mail: [e-mail]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





Envelope-to: [e-mail]
Delivery-date: Fri, 08 Feb 2008 03:33:22 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-vcat-lcas-04.txt 
Message-Id: <[e-mail]>
Date: Thu,  7 Feb 2008 19:30:01 -0800 (PST)

--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		: Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
	Author(s)	: G. Bernstein
	Filename	: draft-ietf-ccamp-gmpls-vcat-lcas-04.txt
	Pages		: 20
	Date		: 2008-2-7
	
This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS)which can be used for hitless dynamic resizing of the inverse multiplex group.  These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-04.txt

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

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

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Thu, 07 Feb 2008 22:36:05 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: FW: New Version Notification for  draft-ietf-ccamp-gmpls-ethernet-arch-00
Date: Thu, 7 Feb 2008 17:33:26 -0500
Message-ID: <[e-mail]>
Thread-Topic: New Version Notification for  draft-ietf-ccamp-gmpls-ethernet-arch-00
Thread-Index: Acho1RzPsItFdj8wTBiH1eBROtt65ABA337g
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>

FYI

The chairs asked us to remind you that plans are to progress this draft
based on WG input.  Please send any comments to the list.

Thanks,
Don for the DT =20

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

A new version of I-D, draft-ietf-ccamp-gmpls-ethernet-arch-00.txt has
been successfuly submitted by Don Fedyk and posted to the IETF
repository.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch
-00.txt

Filename:	 draft-ietf-ccamp-gmpls-ethernet-arch
Revision:	 00
Title:		 GMPLS Ethernet Label Switching Architecture and
Framework
Creation_date:	 2008-02-06
WG ID:		 ccamp
Number_of_pages: 20

Abstract:
There has been significant recent work in increasing the capabilities
of Ethernet switches. As a consequence, the role of Ethernet is
rapidly expanding into "transport networks" that previously were the
domain of other technologies such as SONET/SDH TDM and ATM. This
document defines an architecture and framework for a GMPLS based
control plane for Ethernet in this "transport network" capacity.
GMPLS has already been specified for similar technologies. Some
additional extensions to the GMPLS control plane are needed and this
document provides a framework for these extensions.Contents
=20



The IETF Secretariat.





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Feb 2008 15:33:54 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-00.txt 
Message-Id: <[e-mail]>
Date: Wed,  6 Feb 2008 07:30:01 -0800 (PST)

--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 Ethernet Label Switching Architecture and Framework
	Author(s)       : D. Fedyk, et al.
	Filename        : draft-ietf-ccamp-gmpls-ethernet-arch-00.txt
	Pages           : 20
	Date            : 2008-02-06

There has been significant recent work in increasing the capabilities
of Ethernet switches. As a consequence, the role of Ethernet is
rapidly expanding into "transport networks" that previously were the
domain of other technologies such as SONET/SDH TDM and ATM. This
document defines an architecture and framework for a GMPLS based
control plane for Ethernet in this "transport network" capacity.
GMPLS has already been specified for similar technologies. Some
additional extensions to the GMPLS control plane are needed and this
document provides a framework for these extensions.Contents

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

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

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

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

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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-00.txt".

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-00.txt

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

Content-Type: text/plain
Content-ID:     <2008-02-06072815.I-D\@ietf.org>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Sun, 03 Feb 2008 08:20:12 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-00.txt 
Message-Id: <[e-mail]>
Date: Sun,  3 Feb 2008 00:15:01 -0800 (PST)

--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           : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
	Author(s)       : M. Chen, R. Zhang
	Filename        : draft-ietf-ccamp-isis-interas-te-extension-00.txt
	Pages           : 19
	Date            : 2008-02-03

This document describes extensions to the ISIS (ISIS) protocol to 
support Multiprotocol Label Switching (MPLS) and Generalized MPLS 
(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems 
(ASes). It defines ISIS-TE extensions for the flooding of TE 
information about inter-AS links which can be used to perform inter-
AS TE path computation. 


 
 
 No support for flooding TE information from other outside the AS is 
proposed or defined in this document. 

Conventions used in this document 

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-00.txt

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

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

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

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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-00.txt".

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-00.txt

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

Content-Type: text/plain
Content-ID:     <2008-02-03000947.I-D\@ietf.org>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Fri, 01 Feb 2008 23:43:30 +0000
Message-ID: <03fd01c8652b$e8f94af0$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: New Liaison Statement, "Respnse to Your Liaison on GMPLS Calls" 
Date: Fri, 1 Feb 2008 23:41:01 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Adrian Farrel (IETF CCAMP WG)" <[e-mail]>
To: "Greg Jones" <[e-mail]>
Cc: "Kam Lam" <[e-mail]>; "Stephen Trowbridge" 
<[e-mail]>; "Ross Callon" <[e-mail]>; 
"Dave Ward" <[e-mail]>; "Scott Bradner" <[e-mail]>; "CCAMP 
Mailing List" <[e-mail]>; "Adrian Farrel" <[e-mail]>; 
"Deborah Brungard" <[e-mail]>; "Adrian Farrel" 
<[e-mail]>; "Deborah Brungard" <[e-mail]>
Sent: Friday, February 01, 2008 11:23 PM
Subject: New Liaison Statement, "Respnse to Your Liaison on GMPLS Calls"


>
> Title: Respnse to Your Liaison on GMPLS Calls
> Submission Date: 2008-02-01
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=414
>
> From: Adrian Farrel(IETF CCAMP WG) <[e-mail]>
> To: ITU-T Q14/15(Greg Jones <[e-mail]>)
> Cc: Kam Lam <[e-mail]>
> Stephen Trowbridge <[e-mail]>
> Ross Callon <[e-mail]>
> Dave Ward <[e-mail]>
> Scott Bradner <[e-mail]>
> CCAMP Mailing List <[e-mail]>
> Reponse Contact: Adrian Farrel <[e-mail]>
> Deborah Brungard <[e-mail]>
> Technical Contact: Adrian Farrel <[e-mail]>
> Deborah Brungard <[e-mail]>
> Purpose: In response
> Body: Thank you for your liaison to CCAMP on GMPLS Calls from your 
> Stuttgart interim meeting in September 2007.
>
> In your liaison, you noted that the GMPLS call is assumed to be as general 
> as possible, and you asked what other call applications there may be in 
> addition to ASON and the CCAMP VCAT draft. At this moment, there are four 
> applications on which the CCAMP working group is working where GMPLS calls 
> are applied. The first two are ASON and VCAT as you note. The third is 
> related to ASON and is the multi-layer network. The fourth provides 
> support for the MEF UNI in coordination with the OIF. Other topics in the 
> future might include OAM coordination, billing, and client-facing port 
> capability negotiation.
>
> Your observations about how TNA information is not used in the propagation 
> or delivery of the [call] message, but may be used [by call controllers] 
> to identify the destination UNI and hence [the destination] Network Call 
> Controller agrees with our understanding and intentions. In practice, a 
> large range of information may be used by call controllers to route 
> calls - that is, to select a series of call controllers between call 
> source and call destination - although we would not wish to preclude 
> source-routing of calls. It is our intention that the generic call message 
> should be capable of being extended to carry any information required by 
> any application of the call message.
>
> In this light you ask for guidance on how to carry ASON call information 
> across a GMPLS network so that it can be reconstructed at ASON call 
> boundaries, and say that you support the resumption of work on a CCAMP I-D 
> on ASON applicability to address the above and would welcome the 
> opportunity to contribute through liaisons. We welcome your support and 
> look forward to working with you in this context. As above, we note that 
> the GMPLS call message (the Notify message) is not limited to the exchange 
> of information between call end points, but can also exchange information 
> between transit call controllers by forming call segments as described in 
> section 7.3.1 of RFC 4974. Work on carrying ASON call information within a 
> GMPLS call message falls within the CCAMP charter and we hope that 
> interested parties will bring ideas forward through the normal process 
> which is, of course, contribution-driven. We would welcome input from all 
> sources either through the CCAMP mailing list or throu
> gh liaisons.
>
> Best regards,
> Adrian Farrel and Deborah Brungard
> CCAMP working group co-chairs
> Attachment(s):
> No document has been attached
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Fri, 01 Feb 2008 23:43:22 +0000
Message-ID: <040001c8652b$fea56370$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: New Liaison Statement, "Response to Liaison on GMPLS Signaling for VCAT/LCAS" 
Date: Fri, 1 Feb 2008 23:41:38 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Adrian Farrel (IETF CCAMP WG)" <[e-mail]>
To: "Greg Jones" <[e-mail]>
Cc: "Kam Lam" <[e-mail]>; "Stephen Trowbridge" 
<[e-mail]>; "Ross Callon" <[e-mail]>; 
"Dave Ward" <[e-mail]>; "Scott Bradner" <[e-mail]>; "CCAMP 
Mailing List" <[e-mail]>; "Adrian Farrel" <[e-mail]>; 
"Deborah Brungard" <[e-mail]>; "Adrian Farrel" 
<[e-mail]>; "Deborah Brungard" <[e-mail]>
Sent: Friday, February 01, 2008 11:38 PM
Subject: New Liaison Statement, "Response to Liaison on GMPLS Signaling for 
VCAT/LCAS"


>
> Title: Response to Liaison on GMPLS Signaling for VCAT/LCAS
> Submission Date: 2008-02-01
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=415
> Please reply by 2008-03-05
>
> From: Adrian Farrel(IETF CCAMP WG) <[e-mail]>
> To: ITU-T Q14/15(Greg Jones <[e-mail]>)
> Cc: Kam Lam <[e-mail]>
> Stephen Trowbridge <[e-mail]>
> Ross Callon <[e-mail]>
> Dave Ward <[e-mail]>
> Scott Bradner <[e-mail]>
> CCAMP Mailing List <[e-mail]>
> Reponse Contact: Adrian Farrel <[e-mail]>
> Deborah Brungard <[e-mail]>
> Technical Contact: Adrian Farrel <[e-mail]>
> Deborah Brungard <[e-mail]>
> Purpose: For action
> Body: The CCAMP Working Group thanks you for your liaison of September 
> 2007 (Q12-14 Interim meeting - LS 005).
>
> Here are our responses to the issues in your liaison:
>
> Per Question 1: We provide here further clarification regarding our 
> previous comment re protocol extensibility to encompass technologies other 
> than SONET/SDH.  An example technology of interest to the community was 
> provided regarding the usage of virtually concatenated ODUs for carriage 
> of IEEE 802.3 HSSG proposed 100 Gbit/s over an existing OTN 
> infrastructure.  How this is accomplished is not defined at this time and 
> might not be using VCAT. A technology neutral approach (i.e., one not 
> dependent upon VCAT over SONET/SDH-unique parameters) would avoid the need 
> for developing a series of specialized solutions.
>
> Our response: As we noted previously, it is certainly our intention that 
> functionality and any protocol extensions that we develop should be easily 
> extensible to support other than SONET/SDH technology, especially 
> technologies covered by GMPLS (e.g. OTN). This is the basis of GMPLS and 
> GMPLS call functionality development. If you have identified any specific 
> concerns with the current approach, we would appreciate your input.
>
> Per Question 2: VCAT group signaling relates closely to multi-layer call 
> modeling, and it is our understanding that the draft is only addressing 
> the constituent server layer call. We plan to perform further work to 
> clarify the interlayer call relationship in terms of the ASON multilayer 
> "call supporting call construct".
>
> Our response: Noted. We look forward to further communication from you.
>
> Per Question 3:   We agree that connections are not moved between calls; 
> the ASON "call supporting calls" construct is consistent with not moving 
> connections between calls. Rec. G.7041 and G.7042 are only concerned with 
> membership of the VCAT group, and not with the use of a member that has 
> been removed (it is assumed to simply go back into the pool of resources, 
> where it can be drawn upon for other purposes). Thus G.7041 and G.7042 do 
> not support the direct movement of a connection from one VCAT group to 
> another. Changing the association of a server layer call/connection to a 
> VCAT group does not necessarily result in removal/deletion of that 
> call/connection.
>
> Our response: Noted.
>
> Per Question 4: We appreciate your clarification of the use of a single 
> call. However we suggest that you do not preclude extension to use 
> multiple calls. This is useful for example in diverse routing 
> applications.
>
> Our response: As noted in our previous liaison, the call construct as 
> proposed in this draft is used to coordinate the (single type) server 
> layer connections for the VCAT functionality. This does not preclude use 
> of RFC 4974 in support of G.8080 call functionality. To ensure that we 
> understand correctly your request, can you provide additional information 
> regarding using multiple calls in support of diverse routing applications?
>
> Per Question 5:  We understand that this draft is only addressing the 
> constituent server layer call; i.e., not the ASON multilayer call 
> supporting call construct. However, we suggest that you do not preclude 
> extensions to use a call in the VCAT layer.
>
> Our response: As noted above, this is not precluded. We look forward to 
> future communication from you as you progress this work.
>
> Per Question 6:  We understand that GMPLS only supports the IP address 
> format, and that the actual addresses may be different in each layer. We 
> believe it would be useful to clarify the difference between addresses 
> used in regards to delivering messages to a control component, and 
> identifiers used for the forwarding plane resources themselves.
>
> Our response: Please refer to RFC 4990. This draft does not modify 
> existing procedures. If you have any questions with regard to GMPLS 
> addressing, we welcome informal dialogue on the CCAMP exploder and, of 
> course, you may also ask via Liaison.
>
> Per Question 7:  Thank you for the clarification which confirms that the 
> VCAT layer Call Controllers are assumed to be adjacent from a control 
> plane perspective.
>
> Our response: Noted. To ensure that we understand your comment on "direct 
> signalling connectivity" and "adjacent": to be precise, it is assumed that 
> the Call Controllers can exchange call control messages. This does not 
> require that they be adjacent.
>
> Per Question 8:  Thank you for the clarification.
>
> Our response: Noted.
>
> Per Question 9:  Based upon your observation, we view that a protocol 
> independent definition of the call ID should be abstracted from G.7713.2, 
> where it is expressed in protocol specific terms; the most appropriate 
> Recommendation for this definition would be G.7713.
>
> Our response: Thank you for the clarification. Please keep us informed as 
> you make this change.
>
> Per Question 10:  Your interpretation of G.8080 is correct regarding E-NNI 
> reference points and adjacent call controllers. There is no reference to 
> RSVP sessions in G.8080; it was used as an example of the consequence of 
> using different protocols in different domains. It is our understanding 
> from the discussions that concatenated GMPLS RSVP-TE connections 
> (homogenous signaling protocol) that are part of the same end-to-end 
> network connection do not need to change the session object, and policy 
> could be applied at a transit (inter-domain) hop. Please confirm that our 
> understanding is correct.
>
> Our response: Your understanding is correct that even though one session 
> is used, policy may be applied by any processing node (call controller) of 
> the call message, and RFC4974 supports multiple call managers along the 
> path between ingress and egress. Please refer to RFC 4974. Note, the RSVP 
> signaling protocol model allows for the application of local policy by any 
> processing node of the request (regardless if a connection or call).
>
> The latest version of this work can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-03.txt
>
> A new version is expected relatively soon. The latest versions of all 
> CCAMP Internet-Drafts can always be found at the CCAMP charter page
> http://www.ietf.org/html.charters/ccamp-charter.html
>
> We welcome any further comments.
>
> Best regards,
> Adrian Farrel and Deborah Brungard
> IETF CCAMP working group co-chairs
> Attachment(s):
> No document has been attached
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Fri, 01 Feb 2008 10:18:37 +0000
Date: Fri, 01 Feb 2008 18:16:27 +0800
From: Mach Chen <[e-mail]>
Subject: Re: Getting off the fence about draft-chen-ccamp-isis-interas-te-extension
To: Adrian Farrel <[e-mail]>
Cc: CCAMP List <[e-mail]>
Message-id: <[e-mail]>
Organization: Huawei
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi Adrian,

OK,I will resubmit the I-D ASAP.

Best regards,			
Mach Chen

On 2008-01-31, at 02:03:56 Adrian Farrel wrote:

>Hi all,
>
>We have an imbalance.
>
>We accepted draft-ietf-ccamp-ospf-interas-te-extension long ago.
>
>The ISIS I-D got stuck making some changes for the ISIS WG and then
>because of the discussion around BGP-TE. the two items have been resolved:
>- The I-D was revised and updated to cover the ISIS issues
>- The BGP-TE I-D has been taken to the Softwires WG
>
>Mach, can you please resubmit the current version of the draft as 
>draft-ietf-ccamp-isis-interas-te-extension-00.txt
>
>Many thanks,
>Adrian 
>
>
>








Envelope-to: [e-mail]
Delivery-date: Fri, 29 Feb 2008 00:36:58 +0000
To: [e-mail], [e-mail]
Subject: RFC 5151 on Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 28 Feb 2008 16:36:49 -0800 (PST)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5151

        Title:      Inter-Domain MPLS and GMPLS Traffic 
                    Engineering -- Resource Reservation Protocol-Traffic
                    Engineering (RSVP-TE) Extensions 
        Author:     A. Farrel, Ed.,
                    A. Ayyangar, JP. Vasseur
        Status:     Standards Track
        Date:       February 2008
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail]
        Pages:      25
        Characters: 56663
        Updates:    RFC3209, RFC3473

        I-D Tag:    draft-ietf-ccamp-inter-domain-rsvp-te-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5151.txt

This document describes procedures and protocol extensions for the
use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
signaling in Multiprotocol Label Switching-Traffic Engineering
(MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
non-packet networks to support the establishment and maintenance of
Label Switched Paths that cross domain boundaries.

For the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space
or path computation responsibility.  Examples of such domains include
Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and
GMPLS overlay networks.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...





Envelope-to: [e-mail]
Delivery-date: Fri, 29 Feb 2008 00:34:27 +0000
To: [e-mail], [e-mail]
Subject: RFC 5150 on Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 28 Feb 2008 16:31:42 -0800 (PST)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5150

        Title:      Label Switched Path Stitching with 
                    Generalized Multiprotocol Label Switching Traffic
                    Engineering (GMPLS TE) 
        Author:     A. Ayyangar, K. Kompella,
                    JP. Vasseur, A. Farrel
        Status:     Standards Track
        Date:       February 2008
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail],  [e-mail]
        Pages:      19
        Characters: 47099
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-lsp-stitching-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5150.txt

In certain scenarios, there may be a need to combine several
Generalized Multiprotocol Label Switching (GMPLS) Label Switched
Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and
all traffic from one constituent LSP is switched onto the next LSP.
We will refer to this as "LSP stitching", the key requirement being
that a constituent LSP not be allocated to more than one e2e LSP.
The constituent LSPs will be referred to as "LSP segments" (S-LSPs).

This document describes extensions to the existing GMPLS signaling
protocol (Resource Reservation Protocol-Traffic Engineering
(RSVP-TE)) to establish e2e LSPs created from S-LSPs, and
describes how the LSPs can be managed using the GMPLS signaling and
routing protocols.

It may be possible to configure a GMPLS node to switch the traffic
from an LSP for which it is the egress, to another LSP for which it is
the ingress, without requiring any signaling or routing extensions
whatsoever and such that the operation is completely transparent to
other nodes.  This will also result in LSP stitching in the data
plane.  However, this document does not cover this scenario of LSP
stitching.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...





Envelope-to: [e-mail]
Delivery-date: Fri, 29 Feb 2008 00:34:19 +0000
To: [e-mail], [e-mail]
Subject: RFC 5152 on A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 28 Feb 2008 16:31:58 -0800 (PST)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5152

        Title:      A Per-Domain Path Computation Method 
                    for Establishing Inter-Domain Traffic Engineering (TE) 
                    Label Switched Paths (LSPs) 
        Author:     JP. Vasseur, Ed.,
                    A. Ayyangar, Ed.,
                      R. Zhang
        Status:     Standards Track
        Date:       February 2008
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail]
        Pages:      21
        Characters: 50563
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-inter-domain-pd-path-comp-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5152.txt

This document specifies a per-domain path computation technique for
establishing inter-domain Traffic Engineering (TE) Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
Paths (LSPs).  In this document, a domain refers to a collection of
network elements within a common sphere of address management or path
computational responsibility such as Interior Gateway Protocol (IGP)
areas and Autonomous Systems.

Per-domain computation applies where the full path of an inter-domain
TE LSP cannot be or is not determined at the ingress node of the TE
LSP, and is not signaled across domain boundaries.  This is most
likely to arise owing to TE visibility limitations.  The signaling
message indicates the destination and nodes up to the next domain
boundary.  It may also indicate further domain boundaries or domain
identifiers.  The path through each domain, possibly including the
choice of exit point from the domain, must be determined within the
domain.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...