Detection and Recovery Time

Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Oct 2002 08:44:08 -0800 Message-Id: <4.3.2.7.2.20021031113310.01b9bbb8@pilgrim.cisco.com> Date: Thu, 31 Oct 2002 11:37:18 -0500 To: ccamp@ops.ietf.org From: "Bradford, Richard" Subject: draft-rbradfor-ccamp-lmp-lol-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_13699639==_.ALT" --=====================_13699639==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Sorry if this is a duplicate. I hadn't seen it go out on the ccamp list and the November meeting is drawing near. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LMP Extensions for Link discovery Using Loss of Light Author(s) : R. Bradford, D. Papadimitriou, D. Tappan Filename : draft-rbradfor-ccamp-lmp-lol-00.txt Pages : 15 Date : 2002-10-22 This document proposes an enhanced mechanism for LMP link verification that is independent of the data encoding type. The general proposal is to use the transmission of light by the sender and recognition of the presence or absence of light by the receiver to identify port mapping. The proposal includes minor extensions to the existing messages to implement this extension to the link verification procedure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-lol-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rbradfor-ccamp-lmp-lol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rbradfor-ccamp-lmp-lol-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. --=====================_13699639==_.ALT Content-Type: text/html; charset="us-ascii" Sorry if this is a duplicate. I hadn't seen it go out on the ccamp list and the November meeting is drawing near.

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

        Title           : LMP Extensions for Link discovery Using Loss of Light
        Author(s)       : R. Bradford, D. Papadimitriou, D. Tappan
        Filename        : draft-rbradfor-ccamp-lmp-lol-00.txt
        Pages           : 15
        Date            : 2002-10-22

This document proposes an enhanced mechanism for LMP link
verification that is independent of the data encoding
type. The general proposal is to use the transmission of
light by the sender and recognition of the presence or
absence of light by the receiver to identify port
mapping. The proposal includes minor extensions to the
existing messages to implement this extension to the link
verification procedure.

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

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

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

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

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

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-rbradfor-ccamp-lmp-lol-00.txt".

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

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

<ftp://ftp.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-lol-00.txt>

--=====================_13699639==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Oct 2002 03:24:13 -0800 Message-Id: <200210301118.GAA08926@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-liu-gmpls-ospf-restoration-00.txt Date: Wed, 30 Oct 2002 06:18:38 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF-TE Extensions in Support of Shared Mesh Restoration Author(s) : H. Liu et al. Filename : draft-liu-gmpls-ospf-restoration-00.txt Pages : 13 Date : 2002-10-29 This document describes extensions to the OSPF-TE routing protocol in support of path computation for shared mesh restoration. New optional sub-TLVs are added to the link TLV of the Traffic Engineering (TE) LSA so that the sharing information of the restoration resource on the TE link reserved for shared mesh restoration is disseminated. The extensions supports both SRLG-disjoint and node-disjoint paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liu-gmpls-ospf-restoration-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-liu-gmpls-ospf-restoration-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-liu-gmpls-ospf-restoration-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-29130200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-liu-gmpls-ospf-restoration-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-liu-gmpls-ospf-restoration-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-29130200.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Oct 2002 03:23:42 -0800 Message-Id: <200210301117.GAA08736@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt Date: Wed, 30 Oct 2002 06:17:46 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generalized MPLS Architecture for Multi-Region Networks Author(s) : D. Papadimitriou, M. Vigoureux et al. Filename : draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt Pages : 27 Date : 2002-10-29 Most of the efforts on Generalized MPLS were dedicated to environments including single switching capability devices, as such, the complexity raised by such control planes were equivalent to the one expected in classical IP/MPLS networks. The fundamental reason being that the definition of the control plane IP based protocol suite for Label Switch Routers (LSR) or Optical Cross-Connects (OXC) has exactly the same level complexity. The present document analyses the various GMPLS aspects when considering envinronments including combined LSR û OXC devices. The latter covers opaque, service transparent and fully transparent (i.e. photonic) data planes. The intent of the first release of this memo is to demonstrate that these aspects may not be as straightforward as they may appear in first approach. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vigoureux-shiomoto-ccamp-gmpls-mrn-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-29130014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-vigoureux-shiomoto-ccamp-gmpls-mrn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-29130014.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Oct 2002 03:32:39 -0800 Message-Id: <200210281128.GAA03367@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org, te-wg@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-seno-path-quality-verification-00.txt Date: Mon, 28 Oct 2002 06:28:20 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Quality Verification over an All-Optical Network Author(s) : S. Seno, Y. Konishi Filename : draft-seno-path-quality-verification-00.txt Pages : 8 Date : 2002-10-25 This draft proposes a framework for path quality verification over an all-optical network. Because it will be difficult to ensure quality of a dynamically established path over an all-optical network, it may be useful for network providers to have means to verify quality of a path before it is served to the subscribers. This draft proposes a framework for such means, including requirements behind them and a path continuity check mechanism to verify optical-level path quality upon a path's establishment by the GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-seno-path-quality-verification-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-seno-path-quality-verification-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-seno-path-quality-verification-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-25110434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-seno-path-quality-verification-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-seno-path-quality-verification-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-25110434.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Oct 2002 15:47:09 -0700 Message-ID: <3DB5B4F6.9060409@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 22 Oct 2002 16:28:38 -0400 From: Acee Lindem To: Mailing List , IETF CCAMP WG Subject: Re: Comments on draft-katz-yeung-traffic-08.txt [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Kireeti, Can we close on the remaining issues? 1. With respect to the Remote Interface IP Addres TLV, is there really any reason to include it with a value of 0.0.0.0 for a multi-access link? I can't see how there could be a compatibility issue since the rough count on the list revealed more implementations that omitted the TLV altogether. 2. With respect to more than two routers on a multi-access network, it seems there is considerable support for allowing this even though it is not fully specified. Could you add something along these lines to the second paragraph of the limitations section: "Operation over multiaccess links with more than two devices is not specifically prohibited. TE operation and the use of reservation state is a matter for further study". Thanks, Acee Kireeti Kompella wrote: > Hi Acee, > > On Thu, 17 Oct 2002, Acee Lindem wrote: > > >>Comments: >> >> - The LSA Header Diagram in section 2.3.1 does not reflect >> the fact that the instance has been extended to 24 bits. >> > > Thanks. Someone else also pointed this out. > > >> - Section 2.4.1 - Replace "but for obvious reasons this..." >> with "but this nomenclature is avoid here since the >> OSPF router ID is not necessarily a routable address." >> > > Any objections? If not, I will make this change. > > >> - Section 2.5.4 - Why 0.0.0.0 for the remote address for >> multiaccess links? It seems the TLV should either be >> omitted or set to the single neighbor address (since >> section 1.2 limits traffic engineering to multiaccess >> networks with 2 devices). >> > > While this document doesn't work ideally for multipoint links with > more that 2 devices, it is used. Also, this has been implemented > and is running code, so changing the spec to omitting this TLV at > this point would cause more problems than it would solve. > > >>Suggestion: >> >> - Include "Implications on Graceful Restart" section >> similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. >> Explicitly state that the goal is to maintain >> existing traffic engineered paths while discouraging >> any new ones until reservation state is obtained. >> > > Instead, how about specifying explicitly in the ospf gmpls draft > that the text there applies to the base TE doc as well as the GMPLS > extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need > the graceful restart doc as a normative reference. Note that the > TE doc has been around for many years, with interoperable > implementations etc., while graceful restart for OSPF much more recent. > > BTW, can we start to progress the graceful restart (aka hitless > restart) document? There are interoperable implementations now, and > while this doc is not as mature as TE, it certainly seems ready .... > > Kireeti. > > -- Acee Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Oct 2002 04:43:34 -0700 Message-Id: <200210221138.HAA11784@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-02.txt Date: Tue, 22 Oct 2002 07:38:59 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-g709-02.txt Pages : 21 Date : 2002-10-21 This document is a companion to the Generalized MPLS (GMPLS) signalling documents. It describes the technology specific information needed to extend GMPLS signalling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-g709-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-21143008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-g709-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-21143008.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Oct 2002 04:43:04 -0700 Message-Id: <200210221139.HAA11800@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-07.txt Date: Tue, 22 Oct 2002 07:39:04 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-sonet-sdh-07.txt Pages : 23 Date : 2002-10-21 This document is a companion to the Generalized Multiprotocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-sonet-sdh-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-21143019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-sonet-sdh-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-21143019.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Oct 2002 12:20:30 -0700 Message-Id: <200210211916.PAA11645@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ccamp@ops.ietf.org From: The IESG Subject: Protocol Action: Generalized MPLS - Signaling Functional Description to Proposed Standard Date: Mon, 21 Oct 2002 15:16:09 -0400 The IESG has approved publication of the following Internet-Drafts as Proposed Standards: o Generalized MPLS - Signaling Functional Description o Generalized MPLS Signaling - CR-LDP Extensions' o Generalized MPLS Signaling - RSVP-TE Extensions This document is the product of the Common Control and Measurement Plane (ccamp) Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. Technical Summary Document 'Generalized MPLS - Signaling Functional Description' describes extensions to MPLS signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g. SONET/SDH ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. Document 'Generalized MPLS Signaling - CR-LDP Extensions' describes extensions to CR-LDP signaling required to support Generalized MPLS. Document 'Generalized MPLS Signaling - RSVP-TE Extensions' describes extensions to RSVP-TE signaling required to support Generalized MPLS. Working Group Summary These documents originated in the MPLS WG. They were transfered to the CCAMP WG in early 2001. WG Last Call was posted to both WGs to ensure all involved people would review. Quite a number of itterations were needed before the WG could reach consensus on all the details. Finaly the WG reached (rough) consensus on these documents and no issues were raised during IETF Last Call. Protocol Quality The documents have been reviewed for the IESG by Alex Zinin and Bert Wijnen. Various implementations have been reported as documented in the survey document: draft-ietf-ccamp-gmpls-signaling-survey-02.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Oct 2002 05:12:31 -0700 Message-Id: <200210211205.IAA24381@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mpls@uu.net, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ash-e2e-crtp-hdr-compress-00.txt Date: Mon, 21 Oct 2002 08:05:31 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : End-to-End VoIP Header Compression Using cRTP Author(s) : J. Ash, B. Goode, J. Hand Filename : draft-ash-e2e-crtp-hdr-compress-00.txt Pages : 9 Date : 2002-10-18 VoIP typically uses the encapsulation voice/RTP/UDP/IP, wherein the packet header is at least 40 bytes, while the voice payload is typically no more than 30 bytes. VoIP header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). In this draft we propose to re-use the methods in cRTP to determine the header compression context and to use the cRTP session context ID to route a compressed packet between the ingress and egress routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ash-e2e-crtp-hdr-compress-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ash-e2e-crtp-hdr-compress-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-18132118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ash-e2e-crtp-hdr-compress-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-18132118.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Oct 2002 11:59:43 -0700 Message-ID: From: "Wijnen, Bert (Bert)" To: ccamp@ops.ietf.org Subject: GMPLS docuements approved by IESG Date: Thu, 17 Oct 2002 20:54:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The IESG today approved as Proposed Standards: o Generalized MPLS - Signaling Functional Description Generalized MPLS Signaling - RSVP-TE Extensions Generalized MPLS Signaling - CR-LDP Extensions thanks to the WG and specifically the authors/editors. The formal announcement will be posted by the IESG secertary in the next few days. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Oct 2002 23:37:43 -0700 Subject: Re: Comment on draft-ietf-mpls-generalized-rsvp-te-09 To: "Lou Berger Cc: " From: "Diego Caviglia" Date: Thu, 17 Oct 2002 08:32:19 +0200 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Lou, for me it is ok. Moreover I don't think that such a change will need a rev of the doc. Diego. Lou Berger on 16/10/2002 18.10.56 To: "Diego Caviglia" cc: Subject: Re: Comment on draft-ietf-mpls-generalized-rsvp-te-09 Diego, As you point out [RFC2961], aka, refresh reduction, allows for what your are asking for. So the current draft does as well. I see no reason for a text change. (At most I'd replace the text "refresh reduction" with [RFC2961], I have no problem doing this iff there is another rev of the document.) Lou At 10:57 AM 10/15/2002, Diego Caviglia wrote: >Hi all, > a comment on the draft-ietf-mpls-generalized-rsvp-te-09. > >On page 13 last sentence of Section 4.3.1 is stated that the MESSAGE_ID and >related objects are defined in [RFC2961] and are used when refresh >reductions is supported. > >What about the case I want to use MessageId and MessageId Ack just in order >to improve the reliability of the G.RSVP-TE message transmission? > >Moreover RFC2961 page 5 last sentence of Section 2 states: >"Note, a node that supports reliable RSVP message delivery (Section 4)but >not Bundle and Srefresh messages, will not set the >Refresh-Reduction-Capable bit." that in my understanding means that I can >use MessageID and MessageID Ack without implementing refresh reduction. Is >it correct? If yes can you please correct the Section 4.3.1 sentence? > >Best Regards > > Diego > > > >---------------------------------------------------------------- >Diego Caviglia >Optical Network - ASON strategy >E-mail: diego.caviglia@marconi.com >Tel: +39 0 10 6003 808 >Via A. Negrone 1A 16153 Genoa (Italy) >---------------------------------------------------------------- >Fatti non foste a viver come bruti >ma per seguir virtute e canoscenza > >Dante Alighieri Inferno Canto XXVI > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Oct 2002 14:05:57 -0700 Message-Id: <4.3.2.7.2.20021016164406.0381bf08@toque.cisco.com> Date: Wed, 16 Oct 2002 17:00:31 -0400 To: Lou Berger From: Anca Zamfir Subject: Re: Reposting on ccamp: Clarification on RSVP Restart Procedure Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Lou, At 12:28 PM 10/16/2002 -0400, Lou Berger wrote: >At 08:46 AM 10/16/2002, Anca Zamfir wrote: > > > >> >Hi, >> >I have a couple of questions regarding the RSVP restart procedure: >> > >> >In draft-ietf-mpls-generalized-rsvp-te-07.txt, section 9.5.2. "Procedures >> >for the Restarting node", one of its paragraph reads: >> >"In the special case where a restarting node also has a resta(r)ting >> >downstream neighbor, a Recovery_Label object should be used instead of a >> >Suggested_Label object." >> > >> >This implies that the restarting node - N1 is able to detect that its >> >downstream neighbor - > >correct. > >> N2 has also restarted, that is N1, N2 is the >> >restarting order. >> > >> >For the LSPs established from N2 to N1, > > > >>since N2 cannot detect that N1 has >> >restarted, N2 will send Path messages using the Suggested Label. > >This statement is incorrect. Please reread section 9.5.2 second paragraph. I reread the paragraph you mention from section 9.5.2 (Procedures for the Restarting node): "If the forwarding state was preserved, then the node initiates the state recovery process. The period during which a node is prepared to support the recovery process is referred to as the Recovery Period. The total duration of the Recovery Period is advertised by the recovering node in the Recovery Time parameter of the Restart_Cap object. The Recovery Time MUST be set to the duration of the Recovery Period in all Hello messages sent during the Recovery Period. State that is not resynchronized during the Recovery Period SHOULD be removed at the end of the Period." Could you please clarify why my statement is incorrect? If N1, N2 is the restarting order and if N2 cannot detect that N1 has restarted then N2 will send Path with Suggested Label to N1 according to 8-th paragraph in the same section. Do you say that there is a way for N2 to know that N1 has restarted? >> >In this case N1 will not be able to differentiate the case where this >> >message is a new Path message sent with Suggested Label or a Path message >> >for an old LSP for which recovery happens. Is N1 expected to handle the >> >two cases in the same way? If yes, why was the Recovery Label "invented" >> >and why wasn't the Suggested Label considered good for the RSVP restart >> >procedure? >> > > >Please refer to section 9.5.2. It clearly states what N1 is to do in this >case. It is clear what to do for the LSP established from N1 to N2 but not for the LSPs established from N2 to N1. Again, I may be missing something, any clarification would be appreciated. Thanks, Anca >Lou > >> >Thanks, >> >Anca > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Oct 2002 09:30:09 -0700 Message-Id: <4.3.2.7.2.20021016121135.030464a8@mo-ex1> Date: Wed, 16 Oct 2002 12:28:50 -0400 To: "Anca Zamfir" From: Lou Berger Subject: Re: Reposting on ccamp: Clarification on RSVP Restart Procedure Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:46 AM 10/16/2002, Anca Zamfir wrote: > >Hi, > >I have a couple of questions regarding the RSVP restart procedure: > > > >In draft-ietf-mpls-generalized-rsvp-te-07.txt, section 9.5.2. "Procedures > >for the Restarting node", one of its paragraph reads: > >"In the special case where a restarting node also has a resta(r)ting > >downstream neighbor, a Recovery_Label object should be used instead of a > >Suggested_Label object." > > > >This implies that the restarting node - N1 is able to detect that its > >downstream neighbor - correct. > N2 has also restarted, that is N1, N2 is the > >restarting order. > > > >For the LSPs established from N2 to N1, >since N2 cannot detect that N1 has > >restarted, N2 will send Path messages using the Suggested Label. This statement is incorrect. Please reread section 9.5.2 second paragraph. > > >In this case N1 will not be able to differentiate the case where this > >message is a new Path message sent with Suggested Label or a Path message > >for an old LSP for which recovery happens. Is N1 expected to handle the > >two cases in the same way? If yes, why was the Recovery Label "invented" > >and why wasn't the Suggested Label considered good for the RSVP restart > >procedure? > > Please refer to section 9.5.2. It clearly states what N1 is to do in this case. Lou > >Thanks, > >Anca Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Oct 2002 09:25:14 -0700 Message-ID: <3DAD92EE.E6534422@alcatel.be> Date: Wed, 16 Oct 2002 18:25:18 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: Blatt Marcelo CC: "'ccamp@ops.ietf.org'" Subject: Re: Detection and Recovery Time Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi, gmpls or more generally the control plane is not strictly speaking involved in the fault detection this is left to the data plane (thus if the detection time takes for instance, 1 ms when gmpls is not available it will take 1 ms when it is) the main improvment from the control plane viewpoint (and vertical information exchange b/w the data and the control plane) is to decrease the time needed to make this information available at the control plane level (i guess this is what you mean by the triggering ?) in the shared (path) protection case you've mentioned here gmpls does not require to replicate the in-band signalling when the data plane delivers but is to be used for syncing actions b/w edge points for instance, but also control further reversion actions (ie normalization), re-provisioning, etc. when used the expected time performance are on the order of 100ms since recovery path are fully provisioned (also keep in mind the numerous dimensions on which this process relies) hope this clarifies a bit, additional information can be found in the following i-d's they were discussed over past meetings and are to be considered (as usual) as ongoing efforts: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-00.txt http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-recovery-analysis-02.txt http://www.ietf.org/internet-drafts/draft-bala-gmpls-recovery-functional-00.txt feedback is always welcome, - dimitri. > Blatt Marcelo wrote: > > Hi, > > I would like to know your opinion regarding GMPLS fault detection and > recovery time. Ideally, one would like to get SDH times (i.e. 60 ms, > 10 ms for detection and 50 ms for switchover) but this seems to be > achievable only in the case of dedicated 1+1 (SNCp) path protection. > In the Shared Protection case, where signaling is involved, this seems > to be a very hard to be achieved. What should be a realistic switching > time? (in what scale 100 ms, 100's ms or seconds). > > I am also wondering regarding the triggering, what should be a > reasonable integration time? > > Thank you in advance, > > Marcelo Blatt -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Oct 2002 09:12:59 -0700 Message-Id: <4.3.2.7.2.20021016120724.02406678@mo-ex1> Date: Wed, 16 Oct 2002 12:10:56 -0400 To: "Diego Caviglia" From: Lou Berger Subject: Re: Comment on draft-ietf-mpls-generalized-rsvp-te-09 Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Diego, As you point out [RFC2961], aka, refresh reduction, allows for what your are asking for. So the current draft does as well. I see no reason for a text change. (At most I'd replace the text "refresh reduction" with [RFC2961], I have no problem doing this iff there is another rev of the document.) Lou At 10:57 AM 10/15/2002, Diego Caviglia wrote: >Hi all, > a comment on the draft-ietf-mpls-generalized-rsvp-te-09. > >On page 13 last sentence of Section 4.3.1 is stated that the MESSAGE_ID and >related objects are defined in [RFC2961] and are used when refresh >reductions is supported. > >What about the case I want to use MessageId and MessageId Ack just in order >to improve the reliability of the G.RSVP-TE message transmission? > >Moreover RFC2961 page 5 last sentence of Section 2 states: >"Note, a node that supports reliable RSVP message delivery (Section 4)but >not Bundle and Srefresh messages, will not set the >Refresh-Reduction-Capable bit." that in my understanding means that I can >use MessageID and MessageID Ack without implementing refresh reduction. Is >it correct? If yes can you please correct the Section 4.3.1 sentence? > >Best Regards > > Diego > > > >---------------------------------------------------------------- >Diego Caviglia >Optical Network - ASON strategy >E-mail: diego.caviglia@marconi.com >Tel: +39 0 10 6003 808 >Via A. Negrone 1A 16153 Genoa (Italy) >---------------------------------------------------------------- >Fatti non foste a viver come bruti >ma per seguir virtute e canoscenza > >Dante Alighieri Inferno Canto XXVI > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Oct 2002 06:27:53 -0700 Message-ID: <3DAD66C0.202B5267@alcatel.be> Date: Wed, 16 Oct 2002 15:16:48 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: Ron Bonica CC: ccamp@ops.ietf.org Subject: Re: IETF 55: Atlanta Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi ron, i would like to know if a specific timeslot will be allocated for discussions concerning the potential items to be proposed during the wg re-chartering ? as listed in the minutes several items are already over the boilerplate on the other side we will be over the upcoming months more than certainly looking for experimental, implementations results concerning the efforts the wg has accomplished over two years this said during the previous meeting i have asked the question related to the vertical integration wrt to the horizontal one that constitutes typically an item such as multi-area, the issue is mainly to ask here if a re-consideration of the tewg outcomes can be safely considered and if yes under which conditions and/or expectations thanks in advance, - dimitri. Ron Bonica wrote: > > All, > > It is time to start setting the agenda for the Atlanta meeting. > If you want to discuss issues with drafts at the Atlanta meeting > please request a slot to do so, by sending mail to the wg chairs. > > As always the slots will be allocated for discussions according > to what is outlined below. > > Ron and Kireeti > > ---------------------------------------------------------------- > > It is not the purpose of a WG session to have > presentation of the content of a document. It > is assumed that all attendees will have read the > drafts in advance of the meeting. > > For documents that are work-in-progress, the > presentation should cover issues resolved since > the last draft followed by open issues and > controversial topics with the intent to reach a > resolution of said issues and topics. > > For new work items, the presentation should focus on > what the problem is and why it is necessary for the > work group to address it. Further it should be either > shown how it falls within the existing charter or why > and how the charter should be extended to encompass it. > The solution should only be sketched. > > The appropriate way of bringing new work to the working > group is to send a draft to the mailing list and promoting > discussion on the list. Slots on the agenda should be used > to discuss outstanding topics that has not be solved on the > mailing list. > > For new proposals addressing issues where > work-in-progess the presentation should focus > on the (perceived) short-fallings of the existing > work and why those issues need to be addressed > both in terms of why they are required and why they > cannot be addressed in the existing work. > the new work must be related to existing work (i.e. > compatible, mutually exclusive, outright replacement). > Finally, the new solution should be sketched, > explaining how the solution overcomes those issues. > The primary purpose of this last part is to allow commentary > from the floor, it should not be orientated toward selling > the idea. > > In all cases only a limited number of slides should be used. > Speakers should budget their at least 25% of their time to > allow for questions. > > Individual contributors: When requesting time on the agenda, > please indicate how your contribution supports the WG charter. > > (Thanks to Loa Anderson for articulating the ground rules.) > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "We are not on Earth to guard a museum, but > to cultivate a flourishing garden of life." > -- Angelo Giuseppe Roncalli -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Oct 2002 05:51:55 -0700 Message-Id: <4.3.2.7.2.20021016084351.037a62b0@toque.cisco.com> Date: Wed, 16 Oct 2002 08:46:08 -0400 To: ccamp@ops.ietf.org From: Anca Zamfir Subject: Reposting on ccamp: Clarification on RSVP Restart Procedure Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Hi, >I have a couple of questions regarding the RSVP restart procedure: > >In draft-ietf-mpls-generalized-rsvp-te-07.txt, section 9.5.2. "Procedures >for the Restarting node", one of its paragraph reads: >"In the special case where a restarting node also has a resta(r)ting >downstream neighbor, a Recovery_Label object should be used instead of a >Suggested_Label object." > >This implies that the restarting node - N1 is able to detect that its >downstream neighbor - N2 has also restarted, that is N1, N2 is the >restarting order. > >For the LSPs established from N2 to N1, since N2 cannot detect that N1 has >restarted, N2 will send Path messages using the Suggested Label. >In this case N1 will not be able to differentiate the case where this >message is a new Path message sent with Suggested Label or a Path message >for an old LSP for which recovery happens. Is N1 expected to handle the >two cases in the same way? If yes, why was the Recovery Label "invented" >and why wasn't the Suggested Label considered good for the RSVP restart >procedure? > >Thanks, >Anca Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Oct 2002 17:05:27 -0700 Date: Tue, 15 Oct 2002 19:40:56 -0400 From: Ron Bonica Subject: IETF 55: Atlanta To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit All, It is time to start setting the agenda for the Atlanta meeting. If you want to discuss issues with drafts at the Atlanta meeting please request a slot to do so, by sending mail to the wg chairs. As always the slots will be allocated for discussions according to what is outlined below. Ron and Kireeti ---------------------------------------------------------------- It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it should be either shown how it falls within the existing charter or why and how the charter should be extended to encompass it. The solution should only be sketched. The appropriate way of bringing new work to the working group is to send a draft to the mailing list and promoting discussion on the list. Slots on the agenda should be used to discuss outstanding topics that has not be solved on the mailing list. For new proposals addressing issues where work-in-progess the presentation should focus on the (perceived) short-fallings of the existing work and why those issues need to be addressed both in terms of why they are required and why they cannot be addressed in the existing work. the new work must be related to existing work (i.e. compatible, mutually exclusive, outright replacement). Finally, the new solution should be sketched, explaining how the solution overcomes those issues. The primary purpose of this last part is to allow commentary from the floor, it should not be orientated toward selling the idea. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for questions. Individual contributors: When requesting time on the agenda, please indicate how your contribution supports the WG charter. (Thanks to Loa Anderson for articulating the ground rules.) =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "We are not on Earth to guard a museum, but to cultivate a flourishing garden of life." -- Angelo Giuseppe Roncalli Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Oct 2002 09:27:44 -0700 Subject: Comment on draft-ietf-mpls-generalized-rsvp-te-09 To: ccamp@ops.ietf.org From: "Diego Caviglia" Date: Tue, 15 Oct 2002 16:57:19 +0200 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi all, a comment on the draft-ietf-mpls-generalized-rsvp-te-09. On page 13 last sentence of Section 4.3.1 is stated that the MESSAGE_ID and related objects are defined in [RFC2961] and are used when refresh reductions is supported. What about the case I want to use MessageId and MessageId Ack just in order to improve the reliability of the G.RSVP-TE message transmission? Moreover RFC2961 page 5 last sentence of Section 2 states: "Note, a node that supports reliable RSVP message delivery (Section 4)but not Bundle and Srefresh messages, will not set the Refresh-Reduction-Capable bit." that in my understanding means that I can use MessageID and MessageID Ack without implementing refresh reduction. Is it correct? If yes can you please correct the Section 4.3.1 sentence? Best Regards Diego ---------------------------------------------------------------- Diego Caviglia Optical Network - ASON strategy E-mail: diego.caviglia@marconi.com Tel: +39 0 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) ---------------------------------------------------------------- Fatti non foste a viver come bruti ma per seguir virtute e canoscenza Dante Alighieri Inferno Canto XXVI Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Oct 2002 08:56:31 -0700 Message-ID: From: "Michael I Mandelberg(Isaac)" To: ccamp@ops.ietf.org Subject: RE: G.RSVP-TE in OTN - Refresh mechanism Date: Tue, 15 Oct 2002 11:48:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" In particular, GMPLS w/LMP does not specify what to do with path state when the TE Link is in the 'degraded' state as determined by LMP. Michael Mandelberg FirstWave Intelligent Optical Networks, Inc. 11800 Sunrise Valley Drive, 15th floor Reston, Virginia 20191 (703) 390 - 9401, x 1008 mmandelberg@fwion.com > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Tuesday, October 15, 2002 11:39 AM > To: ccamp@ops.ietf.org > Subject: G.RSVP-TE in OTN - Refresh mechanism > > > Hi all, > some times ago I posted the e-mail in > attachment but so far I > haven't received any response. > > As it is now, you might for example delete an LSP in a > Transport Network > just because, the DCN failed the delivery of some Refresh messages. > > On the other hand, one of the major Carrier requirements is > that a control > channel failure must not affect data plane. > > May be that is a silly question but it seems to me that the two above > statements are in contradiction. > > Regards, > Diego > > > ---------------------- Forwarded by Diego Caviglia/MAIN/MC1 > on 15/10/2002 > 17.27 --------------------------- > > "Diego Caviglia" @ops.ietf.org on > 10/09/2002 > 10.52.22 > > Sent by: owner-ccamp@ops.ietf.org > > > To: ccamp@ops.ietf.org > cc: > > Subject: G.RSVP-TE in OTN - Refresh mechanism > > > Hi all, > some time ago there was an argument, on the ML (see > http://ops.ietf.org/lists/ccamp/ccamp.2001/msg00374.html) > about whether it > was feasible to retain the possibilty to set the refresh > timer to infinite, > a proposed alternative was to ignore the elapsing of the > refresh timer. > > I feel these capacities are very useful especially in a > Transport Network > enviroment. > > What is the consensus on the possibility to eliminate the > need of refresh > message in G.RSVP-TE? > > Best Regards, > Diego. > > > > > > > ---------------------------------------------------------------- > Diego Caviglia > Optical Network - ASON strategy > E-mail: diego.caviglia@marconi.com > Tel: +39 0 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > ---------------------------------------------------------------- > Fatti non foste a viver come bruti > ma per seguir virtute e canoscenza > > Dante Alighieri Inferno Canto XXVI > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Oct 2002 08:45:58 -0700 Subject: G.RSVP-TE in OTN - Refresh mechanism To: ccamp@ops.ietf.org From: "Diego Caviglia" Date: Tue, 15 Oct 2002 17:38:48 +0200 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi all, some times ago I posted the e-mail in attachment but so far I haven't received any response. As it is now, you might for example delete an LSP in a Transport Network just because, the DCN failed the delivery of some Refresh messages. On the other hand, one of the major Carrier requirements is that a control channel failure must not affect data plane. May be that is a silly question but it seems to me that the two above statements are in contradiction. Regards, Diego ---------------------- Forwarded by Diego Caviglia/MAIN/MC1 on 15/10/2002 17.27 --------------------------- "Diego Caviglia" @ops.ietf.org on 10/09/2002 10.52.22 Sent by: owner-ccamp@ops.ietf.org To: ccamp@ops.ietf.org cc: Subject: G.RSVP-TE in OTN - Refresh mechanism Hi all, some time ago there was an argument, on the ML (see http://ops.ietf.org/lists/ccamp/ccamp.2001/msg00374.html) about whether it was feasible to retain the possibilty to set the refresh timer to infinite, a proposed alternative was to ignore the elapsing of the refresh timer. I feel these capacities are very useful especially in a Transport Network enviroment. What is the consensus on the possibility to eliminate the need of refresh message in G.RSVP-TE? Best Regards, Diego. ---------------------------------------------------------------- Diego Caviglia Optical Network - ASON strategy E-mail: diego.caviglia@marconi.com Tel: +39 0 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) ---------------------------------------------------------------- Fatti non foste a viver come bruti ma per seguir virtute e canoscenza Dante Alighieri Inferno Canto XXVI Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Oct 2002 05:35:11 -0700 Message-ID: From: Blatt Marcelo To: "'ccamp@ops.ietf.org'" Subject: Detection and Recovery Time Date: Tue, 15 Oct 2002 14:31:12 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2743E.5D831020" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2743E.5D831020 Content-Type: text/plain; charset="windows-1255" Hi, > I would like to know your opinion regarding GMPLS fault detection and > recovery time. Ideally, one would like to get SDH times (i.e. 60 ms, 10 ms > for detection and 50 ms for switchover) but this seems to be achievable > only in the case of dedicated 1+1 (SNCp) path protection. In the Shared > Protection case, where signaling is involved, this seems to be a very hard > to be achieved. What should be a realistic switching time? (in what scale > 100 ms, 100's ms or seconds). > I am also wondering regarding the triggering, what should be a reasonable > integration time? > > Thank you in advance, > Marcelo Blatt ------_=_NextPart_001_01C2743E.5D831020 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Detection and Recovery Time

Hi,

I would like to know your opinion = regarding GMPLS fault detection and recovery time. Ideally, one would = like to get SDH times (i.e. 60 ms, 10 ms for detection and 50 ms for = switchover) but this seems to be achievable only in the case of = dedicated 1+1 (SNCp) path protection. In the Shared Protection case, = where signaling is involved, this seems to be a very hard to be = achieved. What should be a realistic switching time? (in what scale 100 = ms, 100's ms or seconds).

I am also wondering regarding the = triggering, what should be a reasonable integration time?

Thank you in advance,

Marcelo Blatt

------_=_NextPart_001_01C2743E.5D831020-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Oct 2002 12:19:04 -0700 Message-ID: <39469E08BD83D411A3D900204840EC557633DF@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Satish Jamadagni'" , ccamp@ops.ietf.org Subject: RE: CSPF related.... Date: Mon, 14 Oct 2002 15:16:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Satish, -> I was curious to find out if any work has been done towards -> standardizing CSPF (Constrained Shortest Path First) related -> issues. At least a framework on what a typical CSPF module -> should expect from say OSPF-TE, REVP-TE or may be even RSVP-TE -> or OSPF modules taking CSPF algorithms or algorithm classes -> (in the literature) into account. You may want to look at RFC 2386. -> I am aware of a draft on the nature of constraints by Kompella et al, -> Any thing else apart from that??? There is a very good experimental RFC 2676 w.r.t CSPF, including pseudo code. Remember, the details in above RFCs are not directly applicable to (G)MPLS environments but *most* of the logic can be correlated very easily. -- Venkata. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Oct 2002 11:17:58 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C273A6.04768F64" Message-ID: <8CDD92FF12940B41B5053950398AC6E0026731@bvtn-email.qoptics.com> Thread-Topic: CSPF related.... Thread-Index: AcJzoYd8KYsuFjl+QhyY+rzEoXRUKwAAxumw Subject: RE: CSPF related.... Date: Mon, 14 Oct 2002 10:20:39 -0700 From: "Vikram Anantha" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C273A6.04768F64 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] IMHO, simple constraints like availability (Simple boolean constraints) are easy to manage across a network in a link state routing protocol. More complex accumulative constraints like (Max allowable delay) are harder to manage across a network for use in a link state routing protocol. Complex accumulative type of constraints seem to lend themselves better to explicit source routing scenarios. Explicit source routing (as mentioned in many drafts) does not need to be standardised. =20 Curious to hear other opinions. =20 Vik -----Original Message----- From: Vishal Sharma [mailto:v.sharma@ieee.org]=20 Sent: Monday, October 14, 2002 9:32 AM To: Satish Jamadagni; ccamp@ops.ietf.org Subject: RE: CSPF related.... =09 =09 Satish, =20 The CSPF is one of the few things that distinguishes different system vendor or network planning tool vendor offerings from one another. As such, it is unlikely that there would be a move to standardize it. The CSPF (especially an off-line version) could, for example, use information beyond what is provided by either RSVP-TE or OSPF-TE. =20 The basic idea of what a CSPF module/process should expect from OSPF-TE and RSVP-TE is clear (the bandwidth parameters and, of course, topology, from OSPF-TE, and from RSVP-TE those=20 reserved resources that alter the bandwidth parameters of links), but I am not aware of any _draft or standards work_ that delves into details of these. =20 If there is some such work, I'd be interested in knowing about it too. =20 -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Satish Jamadagni Sent: Saturday, October 12, 2002 6:11 AM To: ccamp@ops.ietf.org Subject: CSPF related.... =09 =09 Hi All, I was curious to find out if any work has been done towards standardizing CSPF (Constrained Shortest Path First) related issues. At least a framework on what a typical CSPF module should expect from say OSPF-TE, REVP-TE or may be even RSVP-TE or OSPF modules taking CSPF algorithms or algorithm classes (in the literature) into account. What will CSPF do (or may not do) to LMP and vice versa etc?? =20 I am aware of a draft on the nature of constraints by Kompella et al, Any thing else apart from that??? =20 Thanks a lot =20 Regards, Satish Jamadagni. =20 =20 ------_=_NextPart_001_01C273A6.04768F64 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

IMHO,=20 simple constraints like availability (Simple boolean constraints) are = easy to=20 manage across a network in a link state routing protocol. More complex=20 accumulative constraints like (Max allowable delay) are harder to manage = across=20 a network for use in a link state routing protocol. Complex accumulative = type of=20 constraints seem to lend themselves better to explicit source routing = scenarios.=20 Explicit source routing (as mentioned in many drafts) does not need to = be=20 standardised.

Curious to hear other = opinions.

Vik

-----Original Message-----
From: = Vishal Sharma=20 [mailto:v.sharma@ieee.org]
Sent: Monday, October 14, 2002 = 9:32=20 AM
To: Satish Jamadagni; = ccamp@ops.ietf.org
Subject: RE:=20 CSPF related....

Satish,

The=20 CSPF is one of the few things that distinguishes different system = vendor or=20 network planning tool

vendor offerings from one another. As such, it is unlikely = that there=20 would be a move to standardize it.

The=20 CSPF (especially an off-line version) could, for example, use = information=20 beyond what is provided

by=20 either RSVP-TE or OSPF-TE.

The=20 basic idea of what a CSPF module/process should expect from OSPF-TE = and=20 RSVP-TE is

clear (the bandwidth parameters and, of course, = topology, from=20 OSPF-TE, and from RSVP-TE those=20

reserved resources that alter the=20 bandwidth parameters of links), but I am not aware of any _draft or = standards=20 work_

that=20 delves into details of these.

If=20 there is some such work, I'd be interested in knowing about it=20 too.

-Vishal

-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Satish=20 Jamadagni
Sent: Saturday, October 12, 2002 6:11 = AM
To:=20 ccamp@ops.ietf.org
Subject: CSPF = related....

Hi All,

I was curious to find out if any = work has been=20 done towards standardizing CSPF (Constrained Shortest Path=20 First) related issues. At least a framework on what a typical = CSPF=20 module should expect from say OSPF-TE, REVP-TE or may be even = RSVP-TE or=20 OSPF modules taking CSPF algorithms or algorithm classes (in the = literature)=20 into account. What will CSPF do (or may not do) to LMP and vice = versa=20 etc??

I am aware of a draft on the nature = of=20 constraints by Kompella et al, Any thing else apart from=20 that???

Thanks a lot

Regards,
Satish = Jamadagni.

=00 ------_=_NextPart_001_01C273A6.04768F64-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Oct 2002 09:37:29 -0700 Reply-To: From: "Vishal Sharma" To: "Satish Jamadagni" , Subject: RE: CSPF related.... Date: Mon, 14 Oct 2002 12:32:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C2737D.B3CC1D80" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C2737D.B3CC1D80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Satish, The CSPF is one of the few things that distinguishes different system vendor or network planning tool vendor offerings from one another. As such, it is unlikely that there would be a move to standardize it. The CSPF (especially an off-line version) could, for example, use information beyond what is provided by either RSVP-TE or OSPF-TE. The basic idea of what a CSPF module/process should expect from OSPF-TE and RSVP-TE is clear (the bandwidth parameters and, of course, topology, from OSPF-TE, and from RSVP-TE those reserved resources that alter the bandwidth parameters of links), but I am not aware of any _draft or standards work_ that delves into details of these. If there is some such work, I'd be interested in knowing about it too. -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Satish Jamadagni Sent: Saturday, October 12, 2002 6:11 AM To: ccamp@ops.ietf.org Subject: CSPF related.... Hi All, I was curious to find out if any work has been done towards standardizing CSPF (Constrained Shortest Path First) related issues. At least a framework on what a typical CSPF module should expect from say OSPF-TE, REVP-TE or may be even RSVP-TE or OSPF modules taking CSPF algorithms or algorithm classes (in the literature) into account. What will CSPF do (or may not do) to LMP and vice versa etc?? I am aware of a draft on the nature of constraints by Kompella et al, Any thing else apart from that??? Thanks a lot Regards, Satish Jamadagni. ------=_NextPart_000_0013_01C2737D.B3CC1D80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Satish,

The=20 CSPF is one of the few things that distinguishes different system vendor = or=20 network planning tool

vendor=20 offerings from one another. As such, it is unlikely that there would be = a move=20 to standardize it.

The=20 CSPF (especially an off-line version) could, for example, use = information beyond=20 what is provided

by=20 either RSVP-TE or OSPF-TE.

The=20 basic idea of what a CSPF module/process should expect from OSPF-TE and = RSVP-TE=20 is

clear=20 (the bandwidth parameters and, of course, topology, from OSPF-TE,=20 and from RSVP-TE those=20

reserved = resources that = alter the=20 bandwidth parameters of links), but I am not aware of any _draft or = standards=20 work_

that=20 delves into details of these.

If=20 there is some such work, I'd be interested in knowing about it=20 too.

-Vishal

-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Satish=20 Jamadagni
Sent: Saturday, October 12, 2002 6:11 = AM
To:=20 ccamp@ops.ietf.org
Subject: CSPF = related....

Hi All,

I was curious to find out if any work = has been=20 done towards standardizing CSPF (Constrained Shortest Path = First) related=20 issues. At least a framework on what a typical CSPF module should = expect from=20 say OSPF-TE, REVP-TE or may be even RSVP-TE or OSPF modules taking = CSPF=20 algorithms or algorithm classes (in the literature) into account. What = will=20 CSPF do (or may not do) to LMP and vice versa etc??

I am aware of a draft on the nature = of=20 constraints by Kompella et al, Any thing else apart from = that???

Thanks a lot

Regards,
Satish = Jamadagni.

------=_NextPart_000_0013_01C2737D.B3CC1D80-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 12 Oct 2002 03:08:41 -0700 Message-ID: <001e01c271d7$a654d540$9224010a@SATISHJ> From: "Satish Jamadagni" To: Subject: CSPF related.... Date: Sat, 12 Oct 2002 15:40:54 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C27205.BFFDCF00" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C27205.BFFDCF00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, I was curious to find out if any work has been done towards = standardizing CSPF (Constrained Shortest Path First) related issues. At = least a framework on what a typical CSPF module should expect from say = OSPF-TE, REVP-TE or may be even RSVP-TE or OSPF modules taking CSPF = algorithms or algorithm classes (in the literature) into account. What = will CSPF do (or may not do) to LMP and vice versa etc?? I am aware of a draft on the nature of constraints by Kompella et al, = Any thing else apart from that??? Thanks a lot Regards, Satish Jamadagni. =20 ------=_NextPart_000_001B_01C27205.BFFDCF00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi All,

I was curious to find out if any work = has been done=20 towards standardizing CSPF (Constrained Shortest Path = First) related=20 issues. At least a framework on what a typical CSPF module should expect = from=20 say OSPF-TE, REVP-TE or may be even RSVP-TE or OSPF modules taking CSPF=20 algorithms or algorithm classes (in the literature) into account. What = will CSPF=20 do (or may not do) to LMP and vice versa etc??

I am aware of a draft on the nature of = constraints=20 by Kompella et al, Any thing else apart from that???

Thanks a lot

Regards,
Satish = Jamadagni.

------=_NextPart_000_001B_01C27205.BFFDCF00-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Oct 2002 04:24:23 -0700 Message-Id: <200210101117.HAA28261@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-09.txt Date: Thu, 10 Oct 2002 07:17:24 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Signaling - RSVP-TE Extensions Author(s) : L. Berger Filename : draft-ietf-mpls-generalized-rsvp-te-09.txt Pages : 42 Date : 2002-10-9 This document describes extensions to MPLS (Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time- division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-rsvp-te-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-9144455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-rsvp-te-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-9144455.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Oct 2002 03:14:03 -0700 Date: Wed, 09 Oct 2002 12:07:47 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "'ccamp@ops.ietf.org'" Subject: I-D ACTION:draft-brunner-mpls-cops-pcs-00.txt (fwd) Message-ID: <1761963.1034165267@[192.168.102.190]> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========01778822==========" --==========01778822========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline FYI. ---------- Forwarded Message ---------- Date: Freitag, 6. September 2002 07:42 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-brunner-mpls-cops-pcs-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : COPS usage for Path Computation Servers (COPS-PCS) > Author(s) : M. Brunner > Filename : draft-brunner-mpls-cops-pcs-00.txt > Pages : 7 > Date : 2002-9-5 > > This memo proposes to use COPS for the communication between a Label > Switching Router (LSR) and a Path Computation Server (PCS). Path > computation is in much regard a complex function and might be out- > sourced. For this reason a protocol between an LSR and a Path > Computation Server is needed. This memo proposes to use COPS as a > base protocol for that task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brunner-mpls-cops-pcs-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After logging > in, type "cd internet-drafts" and then > "get draft-brunner-mpls-cops-pcs-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-brunner-mpls-cops-pcs-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. ---------- End Forwarded Message ---------- -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus --==========01778822========== Content-Type: multipart/mixed; boundary="==========01767743==========" --==========01767743========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : COPS usage for Path Computation Servers (COPS-PCS) Author(s) : M. Brunner Filename : draft-brunner-mpls-cops-pcs-00.txt Pages : 7 Date : 2002-9-5 This memo proposes to use COPS for the communication between a Label Switching Router (LSR) and a Path Computation Server (PCS). Path computation is in much regard a complex function and might be out- sourced. For this reason a protocol between an LSR and a Path Computation Server is needed. This memo proposes to use COPS as a base protocol for that task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-mpls-cops-pcs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brunner-mpls-cops-pcs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-brunner-mpls-cops-pcs-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. --==========01767743========== Content-Type: multipart/alternative; boundary="==========01772099==========" --==========01772099========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-9-5121834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-mpls-cops-pcs-00.txt --==========01772099========== Content-Type: message/external-body; name="draft-brunner-mpls-cops-pcs-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-9-5121834.I-D@ietf.org> --==========01772099==========-- --==========01767743==========-- --==========01778822==========-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Oct 2002 14:43:53 -0700 Message-Id: <4.3.2.7.2.20021008172858.02f17120@mo-ex1> Date: Tue, 08 Oct 2002 17:38:18 -0400 To: ccamp@ops.ietf.org From: Lou Berger Subject: Fwd: Updated draft (draft-ietf-mpls-generalized-rsvp-te-09.txt) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The security section (sec. 12) of the gmpls-rsvp-te document has been updated per feedback from the IESG. There are no technical changes (just details added). With this change, there should be no issues remaining with the GMPLS signaling documents. Lou >Date: Tue, 08 Oct 2002 17:28:32 -0400 >To: internet-drafts@ietf.org >From: Lou Berger >Subject: Updated draft (draft-ietf-mpls-generalized-rsvp-te-09.txt) >Cc: gmpls@labn.net, bwijnen@lucent.com > >Hi, > Can you please publish the updated version of > draft-ietf-mpls-generalized-rsvp-te-09.txt? It can be found at: > http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-09.txt > >Please let me know if there are any problems retrieving the draft. > >Much thanks, >Lou (and co-authors) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Oct 2002 19:08:30 -0700 Message-ID: <01C2697E.6B54CAB0.ramsrm@tdd.sj.nec.com> From: ramanathan rams Reply-To: "ramsrm@tdd.sj.nec.com" To: "'ccamp@ops.ietf.org'" Subject: ISIS-GMPLS extension doubts. Date: Tue, 1 Oct 2002 19:11:58 -0700 Organization: NEC hi all, I have the following doubts, could u please explain me? If I am wrong with my assumptions please correct me. Assumptions : * In optical domain - control channel and data channel are separate. ISIS will be running in the control channel and advertise thecontrol channel connectivity. For GMPLS/TE purpose we r adding the data channel properties along with control channel properties in ISIS LSPs and flooding it. so i assume that we need not establish data channel adjacency in each and every data channel using hellos. Hellos will be exchanged only in control channel and control channel adjacency will be established. In LSPs along with control channel link state, data channel properties will be advertised. * we can have multiple data channels between two systems ( many point to point links ). for each link local end will assign local link identifer and remote end will assign remote link identifier. Doubts : >From ISIS GMPLS extension : * Section 6.5 says Link's local and remote identifers are exchanged using 3 way PP handshake. using 3 way PP Handshake, we can exchange local and remote identifiers. In this case it is done for the link where data and control channel are not separate. In optical domain since we exchange hellos only in control channel, how do we exchange link identifiers for so many data channels that are running between two machines. * SRLG option is unique for local and remote link identifier combination right?, if that is the case anyway we r advertising the local and remote idenitfier in IS extended reachability field as a sub TLV, so we can add SRLG as a sub TLV of IS extended reachability right? why do we need a separate TLV?( assumption : if we have n data links between two machines A and B, in A's LSP IS extended reachability for neighbour B, will appear n times for n different links ) thanks rams. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Oct 2002 07:22:03 -0700 Date: Tue, 01 Oct 2002 10:03:18 -0400 From: Ron Bonica Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-06 To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, This message ends the last call. Authors, Please spin a final version of the draft tht encorporates final comments. Ron > -----Original Message----- > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com] > Sent: Thursday, September 19, 2002 9:34 AM > To: ccamp@ops.ietf.org > Subject: WG Last Call: draft-ietf-ccamp-lmp-06 > > > Folks, > > This message begins a WG last call for draft-ietf-ccamp-lmp-06. > Last call will end one week from today, at midnight EDT on > Spetember 26, 2002. > > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "We are not on Earth to guard a museum, but > to cultivate a flourishing garden of life." > -- Angelo Giuseppe Roncalli