From owner-ccamp@ops.ietf.org Mon Mar 06 12:40:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJgu-0004qE-8C for ccamp-archive@ietf.org; Mon, 06 Mar 2006 12:40:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGJgr-0002wk-Rm for ccamp-archive@ietf.org; Mon, 06 Mar 2006 12:40:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGJYq-0002k7-Ti for ccamp-data@psg.com; Mon, 06 Mar 2006 17:31:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.64] (helo=smtpauth04.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGJYq-0002jo-5e; Mon, 06 Mar 2006 17:31:56 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AogsDXZKbC6bz1nfKP6L53bG2iGz+UATU6EpW7N1rWUoyTNlVG210N1GUSepHlWw; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.238.240] (helo=jlucianilaptop) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FGJYo-0003mk-Nb; Mon, 06 Mar 2006 12:31:55 -0500 Message-ID: <027601c64143$af8e7140$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , Cc: "Wijnen, Bert (Bert)" , "Thomas D. Nadeau" , , "Bill Fenner" References: <075e01c63eee$eca67bb0$10849ed9@Puppy> Subject: Re: New revision of GMPLS TE MIB Date: Mon, 6 Mar 2006 12:30:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654edbe6f01eee9db0b9cc75455d263a9ee189477d7828d6397350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.238.240 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Thanks Adrian and Tom! Will take a look at all 3 of the MIBs and give update by end of this week. Thanks, Joan ----- Original Message ----- From: Adrian Farrel To: Cc: Joan Cucchiara ; Wijnen, Bert (Bert) ; Thomas D. Nadeau ; ; Bill Fenner Sent: Friday, March 03, 2006 1:17 PM Subject: New revision of GMPLS TE MIB > Hi, > > I have just submitted a new revision of the GMPLS TE MIB > (draft-ietf-ccamp-gmpls-te-mib-13.txt) which should be posted soon. > > The changes are to complete the markups from MIB Doctor review and > comprise changes to the conformance and compliance sections of the MIB > module as requested. > > I have also made the following changes: > - added comments to IANAGmplsGeneralizedPid to highlight the lacunae. > - updated references to RFC 4328 > - correct possible settings of mplsTunnelIsIf which is TruthValue > - retire gmplsTunnelIsNotIntfcGroup which had become empty > - correct the example to use gmplsTunnelSendPathNotifyRecipientType > and gmplsTunnelSendPathNotifyRecipient > - correct the hex value of an IP address in the example > > We will show this to the MIB Doctors to check that they are happy with all > of our changes, and then get the IESG process into motion. > > Adrian > > > From owner-ccamp@ops.ietf.org Mon Mar 06 16:24:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMjS-0007u1-F4 for ccamp-archive@ietf.org; Mon, 06 Mar 2006 15:55:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMjP-0003F2-Cx for ccamp-archive@ietf.org; Mon, 06 Mar 2006 15:55:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGMea-000EhK-Tn for ccamp-data@psg.com; Mon, 06 Mar 2006 20:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGMea-000Egc-81 for ccamp@ops.ietf.org; Mon, 06 Mar 2006 20:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k26Ko3vP010477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMeZ-00059t-0k; Mon, 06 Mar 2006 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-03.txt Message-Id: Date: Mon, 06 Mar 2006 15:50:03 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --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 : Label Switched Path Stitching with Generalized MPLS Traffic Engineering Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ietf-ccamp-lsp-stitching-03.txt Pages : 20 Date : 2005-9-23 In certain scenarios, there may be a need to combine together different Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that in the data plane, a single end-to- end (e2e) LSP is realized and all traffic from one LSP is switched onto the other LSP. We will refer to this as "LSP stitching". This document covers cases where: a) the node performing the stitching does not require configuration of every LSP pair to be stitched together b) the node performing the stitching is not the egress of any of the LSPs c) LSP stitching not only results in an end-to-end LSP in the data plane, but there is also a corresponding end-to-end LSP (RSVP session) in the control plane. 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, 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-lsp-stitching-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-6134231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-stitching-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6134231.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Mar 06 16:40:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMjQ-0008IP-Fd for ccamp-archive@ietf.org; Mon, 06 Mar 2006 15:55:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMjP-0003Ey-CL for ccamp-archive@ietf.org; Mon, 06 Mar 2006 15:55:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGMeb-000Ehi-PR for ccamp-data@psg.com; Mon, 06 Mar 2006 20:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGMeb-000Egv-1q for ccamp@ops.ietf.org; Mon, 06 Mar 2006 20:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k26Ko3BX024413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMeZ-00059y-1R; Mon, 06 Mar 2006 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-03.txt Message-Id: Date: Mon, 06 Mar 2006 15:50:03 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --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 : Inter domain GMPLS Traffic Engineering - RSVP-TE extensions Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ietf-ccamp-inter-domain-rsvp-te-03.txt Pages : 24 Date : 2006-3-6 This document describes extensions to Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support mechanisms for the establishment and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs), both packet and non-packet, that traverse multiple domains. 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, IGP areas and GMPLS overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-rsvp-te-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-6134446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-rsvp-te-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6134446.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Mar 07 14:36:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhzG-000849-Hq for ccamp-archive@ietf.org; Tue, 07 Mar 2006 14:36:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGhzE-0008Ty-55 for ccamp-archive@ietf.org; Tue, 07 Mar 2006 14:36:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGhrK-0005Y8-3t for ccamp-data@psg.com; Tue, 07 Mar 2006 19:28:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGhrG-0005Xo-UR for ccamp@ops.ietf.org; Tue, 07 Mar 2006 19:28:35 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k27JSVBX006103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Mar 2006 19:28:31 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGhrD-0000oP-D8; Tue, 07 Mar 2006 14:28:31 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Protocol Action: 'Node ID based RSVP Hello: A Clarification Statement' to Proposed Standard Message-Id: Date: Tue, 07 Mar 2006 14:28:31 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c The IESG has approved the following document: - 'Node ID based RSVP Hello: A Clarification Statement ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Technical Summary Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. Working Group Summary The WG had consensus on progressing this document. Protocol Quality The document has been reviewed for the IESG by Alex Zinin. Note to RFC Editor Abstract Delete "as a best current practice (BCP)" as follows... OLD Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. NEW Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. From owner-ccamp@ops.ietf.org Wed Mar 08 03:04:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtez-0002DS-W8 for ccamp-archive@ietf.org; Wed, 08 Mar 2006 03:04:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGtex-0004mk-Ic for ccamp-archive@ietf.org; Wed, 08 Mar 2006 03:04:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGtQr-0003M5-N1 for ccamp-data@psg.com; Wed, 08 Mar 2006 07:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGtQq-0003LH-Ov for ccamp@ops.ietf.org; Wed, 08 Mar 2006 07:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k287o10e031167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 07:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGtQn-0001c8-OZ; Wed, 08 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt Message-Id: Date: Wed, 08 Mar 2006 02:50:01 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Node ID based RSVP Hello: A Clarification Statement Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt Pages : 7 Date : 2006-3-7 Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, and when TE links are unnumbered. Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. When link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). The use of Node-ID based Hello session is optimal in the sense that as long as there is IP reachability to the nieghbor (node-id), the signalling adjacency will remain up. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-7203101.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7203101.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Mar 09 06:17:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJ9H-00024P-4E for ccamp-archive@ietf.org; Thu, 09 Mar 2006 06:17:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHJ9E-0006CL-Hj for ccamp-archive@ietf.org; Thu, 09 Mar 2006 06:17:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHIzT-0001Om-Sm for ccamp-data@psg.com; Thu, 09 Mar 2006 11:07:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHIzS-0001OV-Sr for ccamp@ops.ietf.org; Thu, 09 Mar 2006 11:07:31 +0000 Message-ID: <44100C71.8080706@psg.com> Date: Thu, 09 Mar 2006 12:07:29 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ccamp@ops.ietf.org" Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 hi all, some comments on the problem statement of this doc: "(2) How to identify the routing instance in which such an advertisement should happen." but by definition it is the same instance when speaking about an FA (or are we not speaking about FA's only (?) the previous paragraph seems to indicate this is not the case "In order for the egress of an LSP to be able to advertise the LSP as a TE link it needs to know that such an advertisement is desirable, " ok this is a trigger issue "and it also needs to know the TE Router ID of the ingress LSR. (Please recall that the Router ID of the other end of the link is set in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA [RFC3630].)" don't understand this; the Router ID is known and the TE router ID is known as well (part of the TEDB) ... what's the purpose of this new requirement (as there is no TE router ID part of the corr. link TLV) clarifications appreciated, in general, if a clearer procedure for numbered FA signaling could be devised that would be a good achievement, this said, i am for inst. unclear about these R and F bits ... where does numbered FA only adv. per RFC4206 is reproduced here ? what "adv. an FA in an IP network" means ? why restrict adv. to MPLS-TE and IP networks only ? etc. imho, the issue of the trigger is part of a larger discussion around FA policing ... in brief, providing a cleaner procedure for numbered FA's is advisable but complexifying procedures by incorporating policing related actions is not advisable thanks, - dimitri. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Advertisement of hierarchical and stitchable Label Switched Paths as Traffic Engineering Links > Author(s) : K. Shiomoto, et al. > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > Pages : 17 > Date : 2006-3-7 > > This document addresses 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 Routing Adjacency (RA). In > addition, the document also addresses 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-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From owner-ccamp@ops.ietf.org Thu Mar 09 07:22:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHK9f-0002X6-EH for ccamp-archive@ietf.org; Thu, 09 Mar 2006 07:22:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHK9d-0008JI-SZ for ccamp-archive@ietf.org; Thu, 09 Mar 2006 07:22:07 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHK1n-0005vt-RU for ccamp-data@psg.com; Thu, 09 Mar 2006 12:13:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.235.18.10] (helo=anyida.tts.lth.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHK1m-0005va-F8 for ccamp@ops.ietf.org; Thu, 09 Mar 2006 12:13:58 +0000 Received: from [127.0.0.1] (lina75.tts.lth.se [130.235.18.175]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id NAA05381 for ; Thu, 9 Mar 2006 13:13:49 +0100 (MET) Message-ID: <44101BE6.9000606@telecom.lth.se> Date: Thu, 09 Mar 2006 13:13:26 +0100 From: Faisal Aslam User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Inter-Domain Topology Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Hi, I am working on simulation study of inter-domain path computation algorithms. I need a big inter-domain topology, that has more than 10 domains and each domain has many nodes. It will be great to have some real world or logical topology. I will appreciate any help in this regard. Thank you, Faisal Aslam From owner-ccamp@ops.ietf.org Thu Mar 09 09:42:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMLC-0005KU-O5 for ccamp-archive@ietf.org; Thu, 09 Mar 2006 09:42:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHMLC-0004Af-8H for ccamp-archive@ietf.org; Thu, 09 Mar 2006 09:42:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHMFh-000Fug-M1 for ccamp-data@psg.com; Thu, 09 Mar 2006 14:36:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHMFg-000FuU-Fi for ccamp@ops.ietf.org; Thu, 09 Mar 2006 14:36:28 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 Mar 2006 06:36:21 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,178,1139212800"; d="scan'208"; a="23275322:sNHT25916892" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k29EaKVU022956; Thu, 9 Mar 2006 09:36:20 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 09:36:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Date: Thu, 9 Mar 2006 09:36:18 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Thread-Index: AcZDahNxIIo0+la1T/qetumiZyqnswAGwirg From: "Zafar Ali \(zali\)" To: , , X-OriginalArrivalTime: 09 Mar 2006 14:36:20.0484 (UTC) FILETIME=[D4FFA440:01C64386] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Hi Dimitri,=20 Please see reply in-lined.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of dimitri papadimitriou > Sent: Thursday, March 09, 2006 6:07 AM > To: ccamp@ops.ietf.org > Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >=20 > hi all, some comments on the problem statement of this doc: >=20 > "(2) How to identify the routing instance in which such an=20 > advertisement should happen." >=20 > but by definition it is the same instance when speaking about=20 > an FA (or are we not speaking about FA's only (?) Correct, both FA and RA (Routing Adj).=20 > the=20 > previous paragraph seems to indicate this is not the case >=20 > "In order for the egress of an LSP to be able to advertise=20 > the LSP as a TE link it needs to know that such an=20 > advertisement is desirable, " >=20 > ok this is a trigger issue Correct, to adv or not to adv.=20 >=20 > "and it also needs to know the TE Router ID of the ingress LSR. > (Please recall that the Router ID of the other end of the=20 > link is set in the Link-ID sub-TLV of the Link TLV of the TE=20 > Opaque-LSA [RFC3630].)" >=20 > don't understand this; the Router ID is known and the TE=20 > router ID is known as well (part of the TEDB) ... what's the=20 > purpose of this new requirement (as there is no TE router ID=20 > part of the corr. link TLV) >=20 > clarifications appreciated, In the current signaling message, for numbered TE link it is NOT clear where the Ingress/ Egress router-id-es are placed. Some implementation use extended tunnel-id field for this but again this is not a must. So please read the above as...=20 "and (when LSP is signaled, Ingress/ Egress nodes ) also needs to know the TE Router ID of the ingress LSR."=20 Please also see related text in the ID related to how this help in flooding. =20 >=20 > in general, if a clearer procedure for numbered FA signaling=20 > could be devised that would be a good achievement, this said,=20 > i am for inst.=20 > unclear about these R and F bits ... where does numbered FA only adv. A bi-directional LSP can be adv as an FA (only in MPLS TE topology) or an RA (IP network) or both. These bits tells the Egress node on what treatment is expected by the Ingress node.=20 =20 > per RFC4206 is reproduced here ?=20 No,=20 > what "adv. an FA in an IP network"=20 > means ?=20 The GMPLS bidirectional LSP is visible to IP topology for inclusion in IP SPF.=20 > why restrict adv. to MPLS-TE and IP networks only ? etc. Can you please elaborate on this?=20 >=20 > imho, the issue of the trigger is part of a larger discussion=20 > around FA policing ... in brief, providing a cleaner=20 > procedure for numbered FA's is advisable but complexifying=20 > procedures by incorporating policing related actions is not advisable >=20 > thanks, > - dimitri. >=20 > Internet-Drafts@ietf.org wrote: >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > >=20 > >=20 > > Title : Advertisement of hierarchical and=20 > stitchable Label Switched Paths as Traffic Engineering Links > > Author(s) : K. Shiomoto, et al. > > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > Pages : 17 > > Date : 2006-3-7 > > =09 > > This document addresses topics related to hierarchical and stitched=20 > > Generalized Multiprotocol Label Switching (GMPLS) Label=20 > Switched Paths=20 > > (LSPs). It describes extensions to allow an egress to=20 > identify that a=20 > > bi-directional LSP will be used as a dynamically signaled=20 > Forwarding=20 > > Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In addition, the=20 > > document also addresses the issue of how to indicate that an LSP=20 > > should be advertised as a traffic engineering (TE) link into a=20 > > different instance of the IGP and how to identify the instance that=20 > > should be used. > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy > > -bis-01.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > >=20 > > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt". > >=20 > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html=20 > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE=20 > /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt". > > =09 > > 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=20 > 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. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce >=20 From owner-ccamp@ops.ietf.org Thu Mar 09 10:30:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHN5W-0000X1-Ba for ccamp-archive@ietf.org; Thu, 09 Mar 2006 10:30:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHN5V-0005c5-Rm for ccamp-archive@ietf.org; Thu, 09 Mar 2006 10:30:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHMvQ-000JJG-EG for ccamp-data@psg.com; Thu, 09 Mar 2006 15:19:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHMvP-000JIw-1K; Thu, 09 Mar 2006 15:19:35 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k29FJU3N017438; Thu, 9 Mar 2006 16:19:30 +0100 In-Reply-To: To: "Zafar Ali \(zali\)" Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 9 Mar 2006 16:19:26 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 03/09/2006 16:19:30, Serialize complete at 03/09/2006 16:19:30 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 hi see my detailed comments in-line, the bottom line for me is that this document tries to solve four problems at the same time while each of them needs separate actions: - the document tries to clarify the numbered FA LSP signaling (= RFC 4206 bis) - the document tries to extend mechanisms for stitchable LSP and hierarchical LSP - the document tries to define policing and utilisation rules for these type of LSPs - the document tries to extend the inheritance process not only to G/MPLS-TE control plane instance(s) but to IP networks see in-line "Zafar Ali \(zali\)" Sent by: owner-ccamp@ops.ietf.org 09/03/2006 15:36 To: , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, cc: Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Hi Dimitri, Please see reply in-lined. Thanks Regards... Zafar > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of dimitri papadimitriou > Sent: Thursday, March 09, 2006 6:07 AM > To: ccamp@ops.ietf.org > Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > hi all, some comments on the problem statement of this doc: > > "(2) How to identify the routing instance in which such an > advertisement should happen." > > but by definition it is the same instance when speaking about > an FA (or are we not speaking about FA's only (?) Correct, both FA and RA (Routing Adj). [dp] the document should clarify "RA signaling" need and issue this tries to solve, i think it means an LSP used for carrying both data and control traffic (in part. routing) but the question is what is expected from this indication > the previous paragraph seems to indicate this is not the case > > "In order for the egress of an LSP to be able to advertise > the LSP as a TE link it needs to know that such an > advertisement is desirable, " > > ok this is a trigger issue Correct, to adv or not to adv. [dp] yes, the question is what's the default behaviour when signaling an FA (since the doc clarifies when an LSP is an FA the point is what's a non advertized FA) > "and it also needs to know the TE Router ID of the ingress LSR. > (Please recall that the Router ID of the other end of the > link is set in the Link-ID sub-TLV of the Link TLV of the TE > Opaque-LSA [RFC3630].)" > > don't understand this; the Router ID is known and the TE > router ID is known as well (part of the TEDB) ... what's the > purpose of this new requirement (as there is no TE router ID > part of the corr. link TLV) > > clarifications appreciated, In the current signaling message, for numbered TE link it is NOT clear where the Ingress/ Egress router-id-es are placed. Some implementation use extended tunnel-id field for this but again this is not a must. So please read the above as... => question is WHY is there something specific here for FAs (since the TE router ID is not part of the info in the link TLV) "and (when LSP is signaled, Ingress/ Egress nodes ) also needs to know the TE Router ID of the ingress LSR." Please also see related text in the ID related to how this help in flooding. => and the question is WHY - link TLV does not need such information > in general, if a clearer procedure for numbered FA signaling > could be devised that would be a good achievement, this said, > i am for inst. > unclear about these R and F bits ... where does numbered FA only adv. A bi-directional LSP can be adv as an FA (only in MPLS TE topology) or an RA (IP network) or both. These bits tells the Egress node on what treatment is expected by the Ingress node. => why only in MPLS-TE topology (meaning why not TDM, LSC, etc.) ? => the major question is that FAs where not meant to trigger any routing adjacency in IP networks, this document does introduce this now the main discussion point is not the bit in the TLV but that the inheritance mechanism is extended to IP network topology > per RFC4206 is reproduced here ? No, > what "adv. an FA in an IP network" means ? The GMPLS bidirectional LSP is visible to IP topology for inclusion in IP SPF. > why restrict adv. to MPLS-TE and IP networks only ? etc. Can you please elaborate on this? => this is a pure policing issue which is orthogonal to the signaling and adv. mechanisms > imho, the issue of the trigger is part of a larger discussion > around FA policing ... in brief, providing a cleaner > procedure for numbered FA's is advisable but complexifying > procedures by incorporating policing related actions is not advisable > > thanks, > - dimitri. > > Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : Advertisement of hierarchical and > stitchable Label Switched Paths as Traffic Engineering Links > > Author(s) : K. Shiomoto, et al. > > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > Pages : 17 > > Date : 2006-3-7 > > > > This document addresses 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 Routing Adjacency (RA). In addition, the > > document also addresses 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-shiomoto-ccamp-lsp-hierarchy > > -bis-01.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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. > > > > > > > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > From owner-ccamp@ops.ietf.org Thu Mar 09 10:31:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHN6i-0003cf-C2 for ccamp-archive@ietf.org; Thu, 09 Mar 2006 10:31:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHN6h-0005f9-LW for ccamp-archive@ietf.org; Thu, 09 Mar 2006 10:31:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHN0C-000JgC-9z for ccamp-data@psg.com; Thu, 09 Mar 2006 15:24:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,HTML_10_20,HTML_MESSAGE autolearn=no version=3.1.0 Received: from [209.191.85.57] (helo=web36806.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHN0B-000Jfw-Az for ccamp@ops.ietf.org; Thu, 09 Mar 2006 15:24:31 +0000 Received: (qmail 70251 invoked by uid 60001); 9 Mar 2006 15:24:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NnMtZswuxOAeH/JWK+h+VONHW76XDFAkYDOy8NkaXhmQTFxCQQZjORN5Tq8OjXAGOwux/eaei7NnDLLKp//AIYtifUl8m5HUdSTTHocuA9gPhY5iP4/SORjnSs/U7JQFIIaf5WNjZlHH5hMukgkXF7GicDvO0X/bELqaLBCxykw= ; Message-ID: <20060309152430.70249.qmail@web36806.mail.mud.yahoo.com> Received: from [67.102.145.11] by web36806.mail.mud.yahoo.com via HTTP; Thu, 09 Mar 2006 07:24:30 PST Date: Thu, 9 Mar 2006 07:24:30 -0800 (PST) From: Igor Bryskin Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt To: "ccamp@ops.ietf.org" In-Reply-To: <44100C71.8080706@psg.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2005292156-1141917870=:60822" Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --0-2005292156-1141917870=:60822 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I think this is a useful document. I've also noticed quite a significant effort to improve the solution compared to the previous revision. I believe there is one aspect (which is not covered yet) that would make the document even stronger. So far we do not have a way to bundle dynamic parallel H-LSPs and advertise them as a single TE link. Note that bundling could be different depending on routing instance the TE link is advertised in. For instance, it is possible to advertise parallel H-LSPs into one routing instance as separate TE links, into another as a single TE link and into the third as several TE links (with each of them bundling two or more H-LSPs). The simple solution would be to allow assigning the same link IDs (numbered or unnumbered) by H-LSP ingresses to H-LSPs that need to be bundled before advertising into particular routing instance. If you agree with such approach, it would be good to have an abstract describing the H-LSP bundling. Thanks, Igor > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Advertisement of hierarchical and stitchable Label Switched Paths as Traffic Engineering Links > Author(s) : K. Shiomoto, et al. > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > Pages : 17 > Date : 2006-3-7 > > This document addresses 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 Routing Adjacency (RA). In > addition, the document also addresses 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-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --------------------------------- Brings words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail. --0-2005292156-1141917870=:60822 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
 
I think this is a useful document. I've also noticed quite a significant effort to improve the solution compared to the previous revision.
 
I believe there is one aspect (which is not covered yet) that would make the document even stronger. So far we do not have a way to bundle dynamic parallel H-LSPs and advertise them as a single TE link. Note that bundling could be different depending on routing instance the TE link is advertised in. For instance, it is possible to advertise parallel H-LSPs into one routing instance as separate TE links, into another as a single TE link and into the third as several TE links (with each of them bundling two or more H-LSPs).
 
The simple solution would be to allow assigning the same link IDs (numbered or unnumbered) by H-LSP ingresses to H-LSPs that need to be bundled before advertising into particular routing instance.
 
If you agree with such approach, it would be good to have an abstract describing the H-LSP bundling.
 
Thanks,
Igor
 

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Advertisement of hierarchical and stitchable Label Switched Paths as Traffic Engineering Links
> Author(s) : K. Shiomoto, et al.
> Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt
> Pages : 17
> Date : 2006-3-7
>
> This document addresses 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 Routing Adjacency (RA). In
> addition, the document also addresses 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-shiomoto-ccamp-lsp-hierarchy-bis-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce


Brings words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail. --0-2005292156-1141917870=:60822-- From owner-ccamp@ops.ietf.org Thu Mar 09 11:51:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOMT-0002Kr-5J for ccamp-archive@ietf.org; Thu, 09 Mar 2006 11:51:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHOMS-0008HH-FZ for ccamp-archive@ietf.org; Thu, 09 Mar 2006 11:51:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHOGO-00002t-Ik for ccamp-data@psg.com; Thu, 09 Mar 2006 16:45:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHOGN-00002Q-6g for ccamp@ops.ietf.org; Thu, 09 Mar 2006 16:45:19 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2006 08:45:10 -0800 X-IronPort-AV: i="4.02,179,1139212800"; d="scan'208"; a="312970229:sNHT36221452" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k29Gj8w1016212; Thu, 9 Mar 2006 08:45:08 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 11:45:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Date: Thu, 9 Mar 2006 11:45:06 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Thread-Index: AcZDjOQ/MQsjDsSjTfunuJrw8wjqNQAAqY6Q From: "Zafar Ali \(zali\)" To: Cc: , X-OriginalArrivalTime: 09 Mar 2006 16:45:08.0447 (UTC) FILETIME=[D33936F0:01C64398] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Hi Dimitri,=20 Please see reply in-line.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Sent: Thursday, March 09, 2006 10:19 AM > To: Zafar Ali (zali) > Cc: ccamp@ops.ietf.org; dpapadimitriou@psg.com > Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >=20 > hi >=20 > see my detailed comments in-line, the bottom line for me is=20 > that this document tries to solve four problems at the same=20 > time while each of them needs separate actions: >=20 > - the document tries to clarify the numbered FA LSP signaling=20 > (=3D RFC 4206 > bis) >=20 > - the document tries to extend mechanisms for stitchable LSP=20 > and hierarchical LSP >=20 > - the document tries to define policing and utilisation rules=20 > for these type of LSPs >=20 What you are referring as "policy" is the Ingress node's intended treatment of the bi-directional LSP. Noticed that the assumption is that the LSP-es are dynamically signaled and flooded to either IP, MPLS or both networks. Since these LSP-es are dynamically signaled, we cannot apply a config at the Egress node. We do all that today- but with configuration knobs at the Egress node.=20 > - the document tries to extend the inheritance process not=20 > only to G/MPLS-TE control plane instance(s) but to IP networks >=20 I am not sure how you deduced that.=20 > see in-line=20 >=20 >=20 >=20 >=20 >=20 > "Zafar Ali \(zali\)" > Sent by: owner-ccamp@ops.ietf.org > 09/03/2006 15:36 > =20 > To: , Dimitri=20 > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, > cc:=20 > Subject: RE: I-D=20 > ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >=20 >=20 > Hi Dimitri,=20 >=20 > Please see reply in-lined.=20 >=20 > Thanks >=20 > Regards... Zafar=20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of dimitri papadimitriou > > Sent: Thursday, March 09, 2006 6:07 AM > > To: ccamp@ops.ietf.org > > Subject: Re: I-D=20 > ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > >=20 > > hi all, some comments on the problem statement of this doc: > >=20 > > "(2) How to identify the routing instance in which such an=20 > > advertisement should happen." > >=20 > > but by definition it is the same instance when speaking about an FA=20 > > (or are we not speaking about FA's only (?) >=20 > Correct, both FA and RA (Routing Adj).=20 >=20 > [dp] the document should clarify "RA signaling" need and=20 > issue this tries to solve, i think it means an LSP used for=20 > carrying both data and control traffic (in part. routing) but=20 > the question is what is expected from this indication >=20 We can clearify this in the next revision. But in summary, when an LSP is signalled as an RA, the Ingress and Egress nodes brings up IGP Adjacency on top of it and flood it to the IP network. The same LSP can independently be also flooded into MPLS network (if FA bit is set).=20 > > the previous paragraph seems to indicate this is not the case > >=20 > > "In order for the egress of an LSP to be able to advertise=20 > the LSP as=20 > > a TE link it needs to know that such an advertisement is=20 > desirable, " > >=20 > > ok this is a trigger issue >=20 > Correct, to adv or not to adv.=20 >=20 > [dp] yes, the question is what's the default behaviour when=20 > signaling an FA (since the doc clarifies when an LSP is an FA=20 > the point is what's a non advertized FA) > =20 Often LSP-es are created for providing a short-cut for IP traffic between the Ingress and Egress nodes. These LSP-es are NOT advertsied to the network (I.e., are NOT FA-es, and of course not RA-es). When neither FA nor RA bits are set, the LSP is NOT flooded at all. This is a non-FA case.=20 If the proposed extensions are NOT used, the default is "TO FLOOD" any signaled LSP, as FA-LSP. This applies to both uni and bi-directional LSP (but there is no issue when LSP is uni-directional, as Egress may still decide NOT to flood it).=20 > > "and it also needs to know the TE Router ID of the ingress LSR. > > (Please recall that the Router ID of the other end of the=20 > link is set=20 > > in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA=20 > > [RFC3630].)" > >=20 > > don't understand this; the Router ID is known and the TE=20 > router ID is=20 > > known as well (part of the TEDB) ... what's the purpose of this new=20 > > requirement (as there is no TE router ID part of the corr. link TLV) > >=20 > > clarifications appreciated, >=20 > In the current signaling message, for numbered TE link it is=20 > NOT clear where the Ingress/ Egress router-id-es are placed.=20 > Some implementation use extended tunnel-id field for this but=20 > again this is not a must. So please read the above as...=20 >=20 > =3D> question is WHY is there something specific here for FAs=20 > (since the TE router ID is not part of the info in the link TLV) >=20 > "and (when LSP is signaled, Ingress/ Egress nodes ) also=20 > needs to know the TE Router ID of the ingress LSR."=20 >=20 > Please also see related text in the ID related to how this=20 > help in flooding.=20 >=20 > =3D> and the question is WHY - link TLV does not need such information > =20 > > in general, if a clearer procedure for numbered FA=20 > signaling could be=20 > > devised that would be a good achievement, this said, i am for inst. > > unclear about these R and F bits ... where does numbered FA=20 > only adv. >=20 > A bi-directional LSP can be adv as an FA (only in MPLS TE=20 > topology) or an RA (IP network) or both. These bits tells the=20 > Egress node on what treatment is expected by the Ingress node.=20 >=20 > =3D> why only in MPLS-TE topology (meaning why not TDM, LSC, etc.) ?=20 >=20 > =3D> the major question is that FAs where not meant to trigger=20 > any routing adjacency in IP networks, this document does=20 > introduce this now the main discussion point is not the bit=20 > in the TLV but that the inheritance mechanism is extended to=20 > IP network topology > =20 BTW there are deployments where uni-directional packet LSP-es are advertised into IP topology (without establishing IGP adj over unidirectional LSP-es, of course). So I am not sure what is new here?=20 > > per RFC4206 is reproduced here ?=20 >=20 > No,=20 >=20 > > what "adv. an FA in an IP network" means ?=20 >=20 > The GMPLS bidirectional LSP is visible to IP topology for=20 > inclusion in IP SPF.=20 >=20 > > why restrict adv. to MPLS-TE and IP networks only ? etc. >=20 > Can you please elaborate on this?=20 >=20 > =3D> this is a pure policing issue which is orthogonal to the=20 > signaling and adv. Mechanisms Please see my earlier comment about policy.=20 >=20 > > imho, the issue of the trigger is part of a larger=20 > discussion around=20 > > FA policing ... in brief, providing a cleaner procedure for=20 > numbered=20 > > FA's is advisable but complexifying procedures by incorporating=20 > > policing related actions is not advisable > >=20 > > thanks, > > - dimitri. > >=20 > > Internet-Drafts@ietf.org wrote: > >=20 > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > >=20 > > >=20 > > > Title : Advertisement of=20 > hierarchical and=20 > > stitchable Label Switched Paths as Traffic Engineering Links > > > Author(s) : K. Shiomoto, et al. > > > Filename :=20 > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > > Pages : 17 > > > Date : 2006-3-7 > > >=20 > > > This document addresses topics related to hierarchical=20 > and stitched=20 > > > 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 Routing Adjacency (RA). In=20 > addition, the=20 > > > document also addresses the issue of how to indicate that an LSP=20 > > > should be advertised as a traffic engineering (TE) link into a=20 > > > different instance of the IGP and how to identify the=20 > instance that=20 > > > should be used. > > >=20 > > > A URL for this Internet-Draft is: > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy > > > -bis-01.txt > > >=20 > > > To remove yourself from the I-D Announcement list, send a > > message to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of the message. > > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > >=20 > > >=20 > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > > "anonymous" and a password of your e-mail address. After=20 > logging in,=20 > > > type "cd internet-drafts" and then > > > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt". > > >=20 > > > A list of Internet-Drafts directories can be found in=20 > > > http://www.ietf.org/shadow.html or=20 > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >=20 > > >=20 > > > Internet-Drafts can also be obtained by e-mail. > > >=20 > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > > /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt". > > >=20 > > > NOTE: The mail server at ietf.org can return the=20 > document in > > > MIME-encoded form by using the "mpack"=20 > utility. To use > this > > > feature, insert the command "ENCODING mime"=20 > before the > "FILE" > > > command. To decode the response(s), you will need > "munpack" or > > > a MIME-compliant mail reader. Different=20 > MIME-compliant > > mail readers > > > exhibit different behavior, especially when=20 > dealing with > > > "multipart" MIME messages (i.e. documents which have=20 > > > been > split > > > up into multiple messages), so check your local > documentation on > > > how to manipulate these messages. > > >=20 > > >=20 > > > Below is the data which will enable a MIME compliant mail reader=20 > > > implementation to automatically retrieve the ASCII version of the=20 > > > Internet-Draft. > > >=20 > > >=20 > > >=20 > > -------------------------------------------------------------- > > ---------- > > >=20 > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Mar 09 12:47:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPEi-00020B-6j for ccamp-archive@ietf.org; Thu, 09 Mar 2006 12:47:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHPEh-0001Zk-I6 for ccamp-archive@ietf.org; Thu, 09 Mar 2006 12:47:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHP8E-0004Zq-0X for ccamp-data@psg.com; Thu, 09 Mar 2006 17:40:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHP8C-0004ZD-NS; Thu, 09 Mar 2006 17:40:57 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k29HerDK027712; Thu, 9 Mar 2006 18:40:53 +0100 In-Reply-To: To: "Zafar Ali \(zali\)" Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 9 Mar 2006 18:40:49 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 03/09/2006 18:40:52, Serialize complete at 03/09/2006 18:40:52 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 hi zafar Hi Dimitri, Please see reply in-line. Thanks Regards... Zafar > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, March 09, 2006 10:19 AM > To: Zafar Ali (zali) > Cc: ccamp@ops.ietf.org; dpapadimitriou@psg.com > Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > hi > > see my detailed comments in-line, the bottom line for me is > that this document tries to solve four problems at the same > time while each of them needs separate actions: > > - the document tries to clarify the numbered FA LSP signaling > (= RFC 4206 > bis) > > - the document tries to extend mechanisms for stitchable LSP > and hierarchical LSP > > - the document tries to define policing and utilisation rules > for these type of LSPs What you are referring as "policy" is the Ingress node's intended treatment of the bi-directional LSP. Noticed that the assumption is that the LSP-es are dynamically signaled and flooded to either IP, MPLS or both networks. Since these LSP-es are dynamically signaled, we cannot apply a config at the Egress node. We do all that today- but with configuration knobs at the Egress node. => but this part of a larger discussion than just processing of the signaling for numbered FAs, as an example why not signal the metric for the the FA link (instead of using the default rule ?), etc. this needs to be boiled down to the needs in terms of FA operations > - the document tries to extend the inheritance process not > only to G/MPLS-TE control plane instance(s) but to IP networks I am not sure how you deduced that. => you state it in the above reply "flooded to either IP, MPLS or both networks" ... so not difficult to deduce ;-) => what's more important to me is your problem statement is initially to improve signaling of numbered FA LSPs as indicated in the backward compatibility section "Indeed it was the attempt to implement numbered FAs that gave rise to the work on this document." => i am not saying that the other points should not be discussed but they should be done in a much structured way (do things right) ... provide a document that solves one issue but introduces others does not fall in this category => see in-line > > hi all, some comments on the problem statement of this doc: > > > > "(2) How to identify the routing instance in which such an > > advertisement should happen." > > > > but by definition it is the same instance when speaking about an FA > > (or are we not speaking about FA's only (?) > > Correct, both FA and RA (Routing Adj). > > [dp] the document should clarify "RA signaling" need and > issue this tries to solve, i think it means an LSP used for > carrying both data and control traffic (in part. routing) but > the question is what is expected from this indication > We can clearify this in the next revision. But in summary, when an LSP is signalled as an RA, the Ingress and Egress nodes brings up IGP Adjacency on top of it and flood it to the IP network. The same LSP can independently be also flooded into MPLS network (if FA bit is set). => "flooded to the IP network" what do you mean in the control plane topology ? > > the previous paragraph seems to indicate this is not the case > > > > "In order for the egress of an LSP to be able to advertise > the LSP as > > a TE link it needs to know that such an advertisement is > desirable, " > > > > ok this is a trigger issue > > Correct, to adv or not to adv. > > [dp] yes, the question is what's the default behaviour when > signaling an FA (since the doc clarifies when an LSP is an FA > the point is what's a non advertized FA) > Often LSP-es are created for providing a short-cut for IP traffic between the Ingress and Egress nodes. These LSP-es are NOT advertsied to the network (I.e., are NOT FA-es, and of course not RA-es). When neither FA nor RA bits are set, the LSP is NOT flooded at all. This is a non-FA case. => and so why does it has to be considered in this document ? If the proposed extensions are NOT used, the default is "TO FLOOD" any signaled LSP, as FA-LSP. This applies to both uni and bi-directional LSP (but there is no issue when LSP is uni-directional, as Egress may still decide NOT to flood it). => nope, for unnumbered FA (bi-dir) LSP this is not the case > > "and it also needs to know the TE Router ID of the ingress LSR. > > (Please recall that the Router ID of the other end of the > link is set > > in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA > > [RFC3630].)" > > > > don't understand this; the Router ID is known and the TE > router ID is > > known as well (part of the TEDB) ... what's the purpose of this new > > requirement (as there is no TE router ID part of the corr. link TLV) > > > > clarifications appreciated, > > In the current signaling message, for numbered TE link it is > NOT clear where the Ingress/ Egress router-id-es are placed. > Some implementation use extended tunnel-id field for this but > again this is not a must. So please read the above as... > > => question is WHY is there something specific here for FAs > (since the TE router ID is not part of the info in the link TLV) > > "and (when LSP is signaled, Ingress/ Egress nodes ) also > needs to know the TE Router ID of the ingress LSR." > > Please also see related text in the ID related to how this > help in flooding. > > => and the question is WHY - link TLV does not need such information > > > in general, if a clearer procedure for numbered FA > signaling could be > > devised that would be a good achievement, this said, i am for inst. > > unclear about these R and F bits ... where does numbered FA > only adv. > > A bi-directional LSP can be adv as an FA (only in MPLS TE > topology) or an RA (IP network) or both. These bits tells the > Egress node on what treatment is expected by the Ingress node. > > => why only in MPLS-TE topology (meaning why not TDM, LSC, etc.) ? > > => the major question is that FAs where not meant to trigger > any routing adjacency in IP networks, this document does > introduce this now the main discussion point is not the bit > in the TLV but that the inheritance mechanism is extended to > IP network topology > BTW there are deployments where uni-directional packet LSP-es are advertised into IP topology (without establishing IGP adj over unidirectional LSP-es, of course). So I am not sure what is new here? => you are not specific enough in what you mean by the "IP topology" within the GMPLS context for me to comment on your statement => but more generally one way around either nothing is needed because once setup IP adj. are brought up (nothing new here, and nothing specific to be signaled) or you want to link the signaling operation such that the IGP instance triggers the adjacency ... my point is that you should first describe what the purpose of this instead of discussing the extension and then see what to do with it > > per RFC4206 is reproduced here ? > > No, > > > what "adv. an FA in an IP network" means ? > > The GMPLS bidirectional LSP is visible to IP topology for > inclusion in IP SPF. > > > why restrict adv. to MPLS-TE and IP networks only ? etc. > > Can you please elaborate on this? > > => this is a pure policing issue which is orthogonal to the > signaling and adv. Mechanisms Please see my earlier comment about policy. > > > imho, the issue of the trigger is part of a larger > discussion around > > FA policing ... in brief, providing a cleaner procedure for > numbered > > FA's is advisable but complexifying procedures by incorporating > > policing related actions is not advisable > > > > thanks, > > - dimitri. > > > > Internet-Drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > > > > Title : Advertisement of > hierarchical and > > stitchable Label Switched Paths as Traffic Engineering Links > > > Author(s) : K. Shiomoto, et al. > > > Filename : > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > > Pages : 17 > > > Date : 2006-3-7 > > > > > > This document addresses 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 Routing Adjacency (RA). In > addition, the > > > document also addresses 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-shiomoto-ccamp-lsp-hierarchy > > > -bis-01.txt > > > > > > To remove yourself from the I-D Announcement list, send a > > message to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of the message. > > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > > "anonymous" and a password of your e-mail address. After > logging in, > > > type "cd internet-drafts" and then > > > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > > /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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. > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > From owner-ccamp@ops.ietf.org Thu Mar 09 14:36:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQvv-00059x-TI for ccamp-archive@ietf.org; Thu, 09 Mar 2006 14:36:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQvv-00054M-9X for ccamp-archive@ietf.org; Thu, 09 Mar 2006 14:36:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHQqT-000Cr3-2z for ccamp-data@psg.com; Thu, 09 Mar 2006 19:30:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHQqQ-000Cqi-Rr for ccamp@ops.ietf.org; Thu, 09 Mar 2006 19:30:44 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 Mar 2006 11:30:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,179,1139212800"; d="scan'208"; a="23296528:sNHT27594768" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k29JUfVU014361; Thu, 9 Mar 2006 14:30:41 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 14:30:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Date: Thu, 9 Mar 2006 14:30:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Thread-Index: AcZDoKHWNRdaZ4L8R2uGobriQMg3tAAAikEw From: "Zafar Ali \(zali\)" To: Cc: , X-OriginalArrivalTime: 09 Mar 2006 19:30:41.0122 (UTC) FILETIME=[F38F2420:01C643AF] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Hi Dimitri,=20 Please see comments in-line.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Sent: Thursday, March 09, 2006 12:41 PM > To: Zafar Ali (zali) > Cc: ccamp@ops.ietf.org; dpapadimitriou@psg.com > Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >=20 > hi zafar >=20 >=20 > Hi Dimitri,=20 >=20 > Please see reply in-line.=20 >=20 > Thanks >=20 > Regards... Zafar=20 >=20 > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be=20 > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Thursday, March 09, 2006 10:19 AM > > To: Zafar Ali (zali) > > Cc: ccamp@ops.ietf.org; dpapadimitriou@psg.com > > Subject: RE: I-D=20 > ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > >=20 > > hi > >=20 > > see my detailed comments in-line, the bottom line for me is=20 > that this=20 > > document tries to solve four problems at the same time=20 > while each of=20 > > them needs separate actions: > >=20 > > - the document tries to clarify the numbered FA LSP=20 > signaling (=3D RFC=20 > > 4206 > > bis) > >=20 > > - the document tries to extend mechanisms for stitchable LSP and=20 > > hierarchical LSP > >=20 > > - the document tries to define policing and utilisation rules for=20 > > these type of LSPs >=20 > What you are referring as "policy" is the Ingress node's=20 > intended treatment of the bi-directional LSP. Noticed that=20 > the assumption is that the LSP-es are dynamically signaled=20 > and flooded to either IP, MPLS or both networks. Since these=20 > LSP-es are dynamically signaled, we cannot apply a config at=20 > the Egress node. We do all that today- but with configuration=20 > knobs at the Egress node.=20 >=20 > =3D> but this part of a larger discussion than just processing=20 > of the signaling for numbered FAs, as an example why not=20 > signal the metric for the the FA link (instead of using the=20 > default rule ?), etc. this needs to be boiled down to the=20 > needs in terms of FA operations=20 >=20 I agree with you.=20 > > - the document tries to extend the inheritance process not only to=20 > > G/MPLS-TE control plane instance(s) but to IP networks >=20 > I am not sure how you deduced that.=20 >=20 > =3D> you state it in the above reply "flooded to either IP,=20 > MPLS or both networks" ... so not difficult to deduce ;-) >=20 Like I mentioned before, there are current deployments where uni-directional LSP-es are advertised into IP topology (as p2p IP links). This is, of course, done without establishing IGP adj over them. > =3D> what's more important to me is your problem statement is=20 > initially to improve signaling of numbered FA LSPs as=20 > indicated in the backward compatibility section "Indeed it=20 > was the attempt to implement numbered FAs that gave rise to=20 > the work on this document."=20 >=20 We can fix that.=20 > =3D> i am not saying that the other points should not be=20 > discussed but they should be done in a much structured way=20 > (do things right) ... provide a document that solves one=20 > issue but introduces others does not fall in this category >=20 Personally, I am open to that. =20 > =3D> see in-line >=20 > > > hi all, some comments on the problem statement of this doc: > > >=20 > > > "(2) How to identify the routing instance in which such an=20 > > > advertisement should happen." > > >=20 > > > but by definition it is the same instance when speaking=20 > about an FA=20 > > > (or are we not speaking about FA's only (?) > >=20 > > Correct, both FA and RA (Routing Adj).=20 > >=20 > > [dp] the document should clarify "RA signaling" need and issue this=20 > > tries to solve, i think it means an LSP used for carrying both data=20 > > and control traffic (in part. routing) but the question is what is=20 > > expected from this indication > >=20 >=20 > We can clearify this in the next revision. But in summary,=20 > when an LSP is signalled as an RA, the Ingress and Egress=20 > nodes brings up IGP Adjacency on top of it and flood it to=20 > the IP network. The same LSP can independently be also=20 > flooded into MPLS network (if FA bit is set).=20 >=20 > =3D> "flooded to the IP network" what do you mean in the=20 > control plane topology ? >=20 Please note that there is also pure IP data traffic, which may follow a topology different than MPLS topology (e.g., not all links are MPLS enabled, not all MPLS LSP-es are flooded to IP). If the IP network for control and data are not separated, then the answer is "yes". But in general that depends on how this GMPLS LPS is used and what IGP instance is using it.=20 > > > the previous paragraph seems to indicate this is not the case > > >=20 > > > "In order for the egress of an LSP to be able to advertise > > the LSP as > > > a TE link it needs to know that such an advertisement is > > desirable, " > > >=20 > > > ok this is a trigger issue > >=20 > > Correct, to adv or not to adv.=20 > >=20 > > [dp] yes, the question is what's the default behaviour when=20 > signaling=20 > > an FA (since the doc clarifies when an LSP is an FA the point is=20 > > what's a non advertized FA) > >=20 >=20 > Often LSP-es are created for providing a short-cut for IP=20 > traffic between the Ingress and Egress nodes. These LSP-es=20 > are NOT advertsied to the network (I.e., are NOT FA-es, and=20 > of course not RA-es). When neither FA nor RA bits are set,=20 > the LSP is NOT flooded at all. This is a non-FA case.=20 >=20 > =3D> and so why does it has to be considered in this document ? >=20 To trigger flooding or not to trigger aspect needs to addressed.=20 > If the proposed extensions are NOT used, the default is "TO=20 > FLOOD" any signaled LSP, as FA-LSP. This applies to both uni=20 > and bi-directional LSP (but there is no issue when LSP is=20 > uni-directional, as Egress may still decide NOT to flood it).=20 >=20 > =3D> nope, for unnumbered FA (bi-dir) LSP this is not the case >=20 Can you point me to the text in lsp hierarchy RFC that states that same? > > > "and it also needs to know the TE Router ID of the ingress LSR. > > > (Please recall that the Router ID of the other end of the > > link is set > > > in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA=20 > > > [RFC3630].)" > > >=20 > > > don't understand this; the Router ID is known and the TE > > router ID is > > > known as well (part of the TEDB) ... what's the purpose=20 > of this new=20 > > > requirement (as there is no TE router ID part of the=20 > corr. link TLV) > > >=20 > > > clarifications appreciated, > >=20 > > In the current signaling message, for numbered TE link it=20 > is NOT clear=20 > > where the Ingress/ Egress router-id-es are placed. > > Some implementation use extended tunnel-id field for this but again=20 > > this is not a must. So please read the above as... > >=20 > > =3D> question is WHY is there something specific here for FAs=20 > (since the=20 > > TE router ID is not part of the info in the link TLV) > >=20 > > "and (when LSP is signaled, Ingress/ Egress nodes ) also=20 > needs to know=20 > > the TE Router ID of the ingress LSR." > >=20 > > Please also see related text in the ID related to how this help in=20 > > flooding. > >=20 > > =3D> and the question is WHY - link TLV does not need such = information > >=20 > > > in general, if a clearer procedure for numbered FA > > signaling could be > > > devised that would be a good achievement, this said, i am=20 > for inst. > > > unclear about these R and F bits ... where does numbered FA > > only adv. > >=20 > > A bi-directional LSP can be adv as an FA (only in MPLS TE > > topology) or an RA (IP network) or both. These bits tells=20 > the Egress=20 > > node on what treatment is expected by the Ingress node. > >=20 > > =3D> why only in MPLS-TE topology (meaning why not TDM, LSC, etc.) ? = > >=20 > > =3D> the major question is that FAs where not meant to trigger any=20 > > routing adjacency in IP networks, this document does introduce this=20 > > now the main discussion point is not the bit in the TLV but=20 > that the=20 > > inheritance mechanism is extended to IP network topology > >=20 >=20 > BTW there are deployments where uni-directional packet LSP-es=20 > are advertised into IP topology (without establishing IGP adj=20 > over unidirectional LSP-es, of course). So I am not sure what=20 > is new here?=20 >=20 > =3D> you are not specific enough in what you mean by the "IP topology" = > within the GMPLS context for me to comment on your statement >=20 Please see my earlier comment on IP topology.=20 > =3D> but more generally one way around either nothing is needed=20 > because once setup IP adj. are brought up=20 I think you missed the point that how does Egress node know what treatment to offer to the bidirection LSP? This is not an issue for unidirectional LSP-es, hence was never an issue in earlier deployments.=20 > (nothing new here,=20 > and nothing specific to be > signaled) or you want to link the signaling operation such=20 > that the IGP instance triggers the adjacency ... my point is=20 > that you should first describe what the purpose of this=20 > instead of discussing the extension and then see what to do with it >=20 We can discuss this with you more in Dallas and provide necessary clearifications. =20 Thanks Regards... Zafar=20 From asd@yahoo.co.jp Fri Mar 10 12:56:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHlrD-0006r7-CE for ccamp-archive@ietf.org; Fri, 10 Mar 2006 12:56:55 -0500 Received: from [218.24.126.41] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHlrB-0006p7-I5 for ccamp-archive@ietf.org; Fri, 10 Mar 2006 12:56:55 -0500 To: From: =?iso-2022-jp?B?QVNE?= Subject: =?iso-2022-jp?B?QU5OQU5OLxskQj1VJE49UDJxJCQlNSVdITwlSBsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.7 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea $B%^%I%b%"%<%k%"%s%"%s(B http://mister-crazy.com/shalala/ $BLd!K(B fafafa163com@163.com From owner-ccamp@ops.ietf.org Sun Mar 12 07:03:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIPIi-0003Iv-SU for ccamp-archive@ietf.org; Sun, 12 Mar 2006 07:03:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIPIg-0001IC-5S for ccamp-archive@ietf.org; Sun, 12 Mar 2006 07:03:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIPAy-000FOU-Qs for ccamp-data@psg.com; Sun, 12 Mar 2006 11:55:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIPAv-000FOA-Na for ccamp@ops.ietf.org; Sun, 12 Mar 2006 11:55:53 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FIPB4-000373-00 for ccamp@ops.ietf.org; Sun, 12 Mar 2006 11:56:02 +0000 Received: from Puppy ([217.158.132.171] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Mar 2006 11:56:16 +0000 Message-ID: <02aa01c645cc$83d09e10$57849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft agenda Date: Sun, 12 Mar 2006 11:52:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 12 Mar 2006 11:56:17.0000 (UTC) FILETIME=[F81D8680:01C645CB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi, A draft agenda is published at http://www3.ietf.org/proceedings/06mar/agenda/ccamp.html As usual, I expect that a few of you will be disappointed not to be on the agenda. We must, however, try to focus on our immediate charter items. What time remains is given over to areas of greatest discussion on the mailing list and where there is most value from handling the discussion in the face-to-face meeting. We will upload slides from the speakers as soon as we have them. I would appreciate receiving the slides no later than Tuesday 21st. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Mar 14 11:05:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJC16-000448-1M for ccamp-archive@ietf.org; Tue, 14 Mar 2006 11:05:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJC15-0005kf-Gx for ccamp-archive@ietf.org; Tue, 14 Mar 2006 11:05:00 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJBpJ-000PKR-JJ for ccamp-data@psg.com; Tue, 14 Mar 2006 15:52:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.68] (helo=smtpauth08.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJBpI-000PKG-Hf; Tue, 14 Mar 2006 15:52:48 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GCSN8EQkwzt+9VQAM0BCJpDnaecHhX47G+i+vPJC7i3N1DYvjb9pDgKHOtIh9cMY; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.238.108] (helo=jlucianilaptop) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FJBpB-0004xM-8k; Tue, 14 Mar 2006 10:52:41 -0500 Message-ID: <011601c6477f$4768b160$0500a8c0@jlucianilaptop> From: To: Cc: "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" , "Tom Nadeau (E-mail)" References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Tue, 14 Mar 2006 10:52:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26542e0f3c0eb285b3a7c34229f7af83e184547562a158a8cca8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.238.108 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Tom and Adrian, Let me apologize for my tardiness in posting the review comments. A great deal of work went into this latest draft. Thank you. Compile issues are listed first, and are followed by review comments in order of the document. Will have the other reviews out by tomorrow. Thanks, Joan Compile Issues: =============== 1) smilint and smicngPRO complained due to REFERENCE clause for gmplsTunnelARHopTable needing an end quote: gmplsTunnelARHopTable OBJECT-TYPE ... REFERENCE "1. Extensions to RSVP for LSP Tunnels, RFC 3209. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812. ^ need end quote ::= { gmplsTeObjects 3 } 2) smicngPRO E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf" is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in module "GMPLS-TE-STD-MIB" MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup, gmplsTunnelIsIntfcGroup <-- please add this gmplsTunnelUnnumIf <--- please remove this } Also, please update the read-only conformance for gmplsTunnelUnnumIf. OBJECT gmplsTunnelUnnumIf MIN-ACCESS read-only DESCRIPTION "Write access is not required." 3) This is listed under compile issues because it might be an issue depending on what is really intended. RFC4181 "Guidelines for MIB Documents", Section 4.8. Compliance Statements, recommends using SYNTAX clauses to denote a subset of values for an object. If you don't intend to have a subset for these then please remove the SYNTAX clause. Please review all of these Compliance Statements with SYNTAX, only a couple are listed here: OBJECT gmplsTunnelLSPEncoding SYNTAX IANAGmplsLSPEncodingType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelSwitchingType SYNTAX IANAGmplsSwitchingType MIN-ACCESS read-only DESCRIPTION "Write access is not required." SYNTAX clauses such as InetAddressType and InetAddress don't specify a subset, so need to ask if you intend to have a subset for these such as: SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } SYNTAX InetAddress (SIZE(0|4|16)) 4) Again, wrt Section 4.8 from RFC4181, it is recommended that if MIB authors intend to have Optional Groups that these be noted. This was done for the Read-only compliance but not the Full-compliance, so would ask that all Optional Groups be specified as recommended by Section 4.8. Reviewing these Compliances statements is difficult without this information. Comments: ----------- 1) Table of Contents: 3. The SNMP Management Framework .......................... 4 Should be: 3. The Internet-Standard Management Framework In other words, please change the title for section 3. 2) 5.7 Use of 32-bit and 64-bit Counters Shouldn't the quote from RFC2863 be in quotes""? 3) 6. Cross-referencing to the gmplsLabelTable 2nd paragraph which begins: The hop tables in this document (gmplsHopTable, gmplsCHopTable and gmplsARHopTable) and the segment tables in the [RFC3813] There is no gmplsHopTable, is this supposed to be: gmplsTunnelHopTable? Similar comment with gmplsCHopTable and gmplsARHopTable. 4) gmplsTunnelPathComp If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls' does this object have meaning? 5) gmplsTunnelErrorTable, would expect to see these objects contained in an MPLS group in Compliance/Conformance Statements. 6) gmplsTunnelErrorTLVs OBJECT-TYPE When the string size is 0 this could indicate that no TLVs are present, right? That would be slightly more efficient than having to look at the first octet. If you agree, please modify the DESCRIPTION to reflect this. Conformace/Compliance: --------------------- 7) Please move some of the following comment to the gmplsTeModuleReadOnlyCompliance DESCRIPTION -- The mandatory group has to be implemented by all LSRs that -- originate, terminate or act as transit for TE-LSPs/tunnels. -- In addition, depending on the type of tunnels supported, other -- groups become mandatory as explained below. 8) Already mentioned this but was expecting to see MPLS objects called out in a separate GROUP (e.g. objects which are valid when gmplsTunnelLSPEncoding has a value of 'tunnelLspNotGmpls', and other objects also). For folks that want to support these MPLS related objects prior to supporting GMPLS, this would be important to understand, so the more clearly noted by the MIB the better. 9) NIT: In the read-only conformance there is a comment: -- All scalars have max access read-only which appears in front of a bunch of objects that are part of a table. Please remove this comment since it doesn't apply. 10) NIT: --glmpsTunnelCHopTable ^^ typo 11) Security Section NIT: the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the gmplsTunnelTable, gmplsTunnelHopTable, gmplsTunnelARHopTable, gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, gmplsTunnelErrorTable collectively show the tunnel network Should have an "and" o the gmplsTunnelTable, gmplsTunnelHopTable, gmplsTunnelARHopTable, gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and ^^^ gmplsTunnelErrorTable collectively show the tunnel network 12) Normative References: [RFC4328] Papadimitriou, D., Ed., "Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control", draft-ietf-ccamp-gmpls-g709, work in progress. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please update. --end of comments-- From owner-ccamp@ops.ietf.org Tue Mar 14 12:21:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDDT-0000NN-Bf for ccamp-archive@ietf.org; Tue, 14 Mar 2006 12:21:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDDS-00087i-Ph for ccamp-archive@ietf.org; Tue, 14 Mar 2006 12:21:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJD5R-0005Cv-23 for ccamp-data@psg.com; Tue, 14 Mar 2006 17:13:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJD5P-0005CZ-VM for ccamp@ops.ietf.org; Tue, 14 Mar 2006 17:13:32 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2006 12:13:22 -0500 X-IronPort-AV: i="4.02,191,1139202000"; d="scan'208"; a="84093799:sNHT37306440" Received: from [161.44.71.158] ([161.44.71.158]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2EHDLWc001995; Tue, 14 Mar 2006 12:13:21 -0500 (EST) In-Reply-To: <011601c6477f$4768b160$0500a8c0@jlucianilaptop> References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> <011601c6477f$4768b160$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1691170D-2DD2-42A7-9246-2DA6D75EF2BA@cisco.com> Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Tue, 14 Mar 2006 12:13:13 -0500 To: X-Mailer: Apple Mail (2.746.3) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 I will update this shortly and send you the updated version ASAP. I will send it to you directly, as the ID gate is closed right now. Also apologies for lack of compilation. I don't have SmicNG Pro working here, so all I could use was SmiLint (its a long story). --Tom > Tom and Adrian, > > Let me apologize for my tardiness in posting the > review comments. > > A great deal of work went into this latest draft. Thank you. > Compile issues are listed first, and are followed by > review comments in order of the document. > > Will have the other reviews out by tomorrow. > > Thanks, Joan > > > > Compile Issues: > =============== > > > 1) smilint and smicngPRO complained > due to REFERENCE clause for gmplsTunnelARHopTable > needing an end quote: > > gmplsTunnelARHopTable OBJECT-TYPE > ... > REFERENCE > "1. Extensions to RSVP for LSP Tunnels, RFC 3209. > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. > 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) > Management Information Base (MIB), RFC 3812. > > ^ need end quote > > ::= { gmplsTeObjects 3 } > > > 2) smicngPRO > E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf" > is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in > module "GMPLS-TE-STD-MIB" > > > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelIsIntfcGroup <-- please add this > gmplsTunnelUnnumIf <--- please remove this > } > > > Also, please update the read-only conformance for gmplsTunnelUnnumIf. > > OBJECT gmplsTunnelUnnumIf > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > 3) This is listed under compile issues because it might be > an issue depending on what is really intended. > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX clause. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsTunnelLSPEncoding > SYNTAX IANAGmplsLSPEncodingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsTunnelSwitchingType > SYNTAX IANAGmplsSwitchingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > > > SYNTAX clauses such as InetAddressType and InetAddress don't > specify a subset, so need to ask if you intend > to have a subset for these such as: > > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > > SYNTAX InetAddress (SIZE(0|4|16)) > > > 4) Again, wrt Section 4.8 from RFC4181, it is recommended > that if MIB authors intend to have Optional Groups that these > be noted. This was done for the Read-only compliance but not > the Full-compliance, so would ask that all Optional Groups be > specified as recommended by Section 4.8. Reviewing these > Compliances statements is difficult without this information. > > > > Comments: > ----------- > > 1) Table of Contents: > > 3. The SNMP Management Framework .......................... 4 > > Should be: > 3. The Internet-Standard Management Framework > In other words, please change the title for section 3. > > > 2) 5.7 Use of 32-bit and 64-bit Counters > > Shouldn't the quote from RFC2863 be in quotes""? > > 3) 6. Cross-referencing to the gmplsLabelTable > > 2nd paragraph which begins: > The hop tables in this document (gmplsHopTable, gmplsCHopTable and > gmplsARHopTable) and the segment tables in the [RFC3813] > > There is no gmplsHopTable, is this supposed to be: > gmplsTunnelHopTable? > Similar comment with gmplsCHopTable and gmplsARHopTable. > > > 4) gmplsTunnelPathComp > > If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls' > does this object have meaning? > > 5) gmplsTunnelErrorTable, would expect to see these objects > contained in an MPLS group in Compliance/Conformance Statements. > > > 6) gmplsTunnelErrorTLVs OBJECT-TYPE > > When the string size is 0 this could indicate that > no TLVs are present, right? > That would be slightly more efficient than > having to look at the first octet. > If you agree, please modify the > DESCRIPTION to reflect this. > > > Conformace/Compliance: > --------------------- > 7) Please move some of the following comment to the > gmplsTeModuleReadOnlyCompliance DESCRIPTION > -- The mandatory group has to be implemented by all LSRs that > -- originate, terminate or act as transit for TE-LSPs/tunnels. > -- In addition, depending on the type of tunnels supported, other > -- groups become mandatory as explained below. > > > 8) Already mentioned this but was expecting to see MPLS objects > called out in a separate GROUP (e.g. objects which are valid when > gmplsTunnelLSPEncoding > has a value of 'tunnelLspNotGmpls', and other objects also). > For folks that want to support these MPLS related objects > prior to supporting GMPLS, this would be > important to understand, so the more clearly noted by the MIB the > better. > > > > 9) NIT: In the read-only conformance there is a comment: > > -- All scalars have max access read-only > > which appears in front of a bunch of objects that are > part of a table. Please remove this comment since it > doesn't apply. > > 10) NIT: > > --glmpsTunnelCHopTable > > ^^ typo > > > 11) Security Section > > NIT: the network via SNMP. These are the tables and objects and > their > sensitivity/vulnerability: > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, > gmplsTunnelErrorTable collectively show the tunnel network > > > Should have an "and" > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and > > ^^^ > > gmplsTunnelErrorTable collectively show the tunnel network > > > > 12) Normative References: > [RFC4328] Papadimitriou, D., Ed., "Generalized MPLS Signalling > Extensions for G.709 Optical Transport Networks > Control", draft-ietf-ccamp-gmpls-g709, work in > progress. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please update. > > --end of comments-- From owner-ccamp@ops.ietf.org Wed Mar 15 00:39:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOj3-0003e4-DS for ccamp-archive@ietf.org; Wed, 15 Mar 2006 00:39:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJOj2-0003K2-TG for ccamp-archive@ietf.org; Wed, 15 Mar 2006 00:39:13 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJOc7-000O8Z-5a for ccamp-data@psg.com; Wed, 15 Mar 2006 05:32:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.68] (helo=smtpauth08.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJOc6-000O88-B1; Wed, 15 Mar 2006 05:32:02 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GMXfjcaZEk7xLLfMIgFHWXvB9hDIfnzR17GUEb88mKXx+OcVfJvRiAKjgTnHGWxn; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.238.108] (helo=jlucianilaptop) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FJOc2-0000Gf-I2; Wed, 15 Mar 2006 00:31:59 -0500 Message-ID: <019c01c647f1$a0fa81a0$0500a8c0@jlucianilaptop> From: To: Cc: "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" , "Tom Nadeau (E-mail)" References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> <011601c6477f$4768b160$0500a8c0@jlucianilaptop> Subject: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt Date: Wed, 15 Mar 2006 00:30:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654ab3f3391fbf2807413b647b5a65c589f2601a10902912494350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.238.108 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Hi Tom and Adrian, Thank you for all the great updates to this draft. Compile issues listed first, followed by review comments. Thanks, Joan Compile Issues ================ GMPLS-LSR-STD-MIB ==================== 1) smicngPRO W: f(GMPLS-LSR-STD-MIB), (391,18) For "gmplsOutSegmentTTLDecrement", syntax is identical W: f(GMPLS-LSR-STD-MIB), (397,18) For "gmplsInSegmentExtraParamsPtr", syntax is identical W: f(GMPLS-LSR-STD-MIB), (404,18) For "gmplsOutSegmentExtraParamsPtr", syntax is identical W: f(GMPLS-LSR-STD-MIB), (447,14) For "gmplsInterfaceSignalingCaps", syntax is identical W: f(GMPLS-LSR-STD-MIB), (460,18) For "gmplsInterfaceRsvpHelloPeriod", syntax is identical W: f(GMPLS-LSR-STD-MIB), (474,18) For "gmplsInSegmentExtraParamsPtr", syntax is identical W: f(GMPLS-LSR-STD-MIB), (488,18) For "gmplsOutSegmentTTLDecrement", syntax is identical W: f(GMPLS-LSR-STD-MIB), (494,18) For " gmplsOutSegmentExtraParamsPtr", syntax is identical RFC4181 "Guidelines for MIB Documents", Section 4.8. Compliance Statements, recommends using SYNTAX clauses to denote a subset of values for an object. If you don't intend to have a subset for these then please remove the SYNTAX. Please review all of these Compliance Statements with SYNTAX, only a couple are listed here: OBJECT gmplsInterfaceRsvpHelloPeriod SYNTAX Unsigned32 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirectionTC MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." OBJECT gmplsInSegmentExtraParamsPtr SYNTAX RowPointer MIN-ACCESS read-only DESCRIPTION "Write access is not required." GMPLS-LABEL-STD-MIB =================== 1) smicngPRO and smiLint flagged line 622 E: f(GMPLS-LABEL-STD-MIB), (622,6) syntax error E: f(GMPLS-LABEL-STD-MIB), (622,6) Syntax for OBJECT clause is "OBJECT" E: f(GMPLS-LABEL-STD-MIB), (518,12) Group "gmplsLabelTableGroup" is both a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB" OBJECT gmplsLabelRowStatus MIN-ACCESS read-only --> SYNTAX RowStatus { active(1) } DESCRIPTION "Support for notInService, createAndWait and notReady is not required." Need to put SYNTAX clause before MIN-ACCESS clause. 2) E: f(GMPLS-LABEL-STD-MIB), (518,12) Group "gmplsLabelTableGroup" is both a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB" The above is flagged as an error but is actually more pervasive than just this one error: both the FullCompliance and the Read-only Compliance statements have Groups listed as Mandatory but then appear as Optional. This needs to be clarified per RFC4181 "Guidelines for MIB Documents", Section 4.8. Compliance Statements. Related to this, the following groups are currently listed as Mandatory under Full compliance, but would think that these only apply if the device has certain interfaces (e.g. gmplsLabelSonetSdhGroup if Sonet interfaces are on the device), is this an Optional Group? What about these other groups? gmplsLabelPacketGroup, gmplsLabelPortWavelengthGroup, gmplsLabelFreeformGroup, gmplsLabelSonetSdhGroup, gmplsLabelWavebandGroup 3) Same comment as with the GMPLS-TE-STD-MIB wrt having an MPLS GROUP in the compliances statements. Would be most helpful to know what objects apply to MPLS. Comments in order of document. ============================== 1) Table of Contents 3. The SNMP Management Framework .................... 4 Please rename to: The Internet-Standard Management Framework 2) 1.1. Migration Strategy, 5th paragraph: the various label pointer objects in the MPLS-STD-LSR-MIB module ^^^^ Please fix: MPLS-STD-LSR-MIB to MPLS-LSR-STD-MIB 3) Please remove "and OBJECT-IDENTIFIERS" in the last paragraph Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] and [GMPLSTCMIB] ... 4) gmplsLsrModuleFullCompliance MODULE-COMPLIANCE 2 issues: a) The following 2 objects could have an MIN-ACCESS of read-only since the DEFVAL is forward. b) the DESCRIPTION is a little awkward, could this be reworded: "The only valid value for unidirectional LSPs is forward(1)." This would need to be updated in the read-only section also. (Similar comments for gmplsOutSegmentDirection). OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirectionTC MIN-ACCESS read-write DESCRIPTION "Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." OBJECT gmplsOutSegmentDirection SYNTAX GmplsSegmentDirectionTC MIN-ACCESS read-write DESCRIPTION "Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." GMPLS-LABEL-STD-MIB ======================== 5) gmplsLabelInterface and gmplsLabelIndex I had a question regarding these 2 indices: if there is a per-platform label, MUST both of these values be zero? Is there any other circumstance in which both would or could be zero? I was a little confused on the use of "could" and "may result" and was wondering if this should be made a little more forceful. 6) As previously mentioned could MPLS objects be denoted in a separate GROUP (e.g., gmplsLabelMplsLabel and possibly other objects). 7) Please put the comment in the DESCRIPTION clause of the gmplsLabelModuleFullCompliance. -- The mandatory groups have to be implemented by GMPLS LSRs -- claiming support for this MIB module. This MIB module is, -- however, not mandatory for a working implementation of a GMPLS -- LSR with full MIB support if the GMPLS labels in use can be -- represented within a 32 bit quantity. --end of comments -- From owner-ccamp@ops.ietf.org Wed Mar 15 00:39:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOj6-0003fk-3o for ccamp-archive@ietf.org; Wed, 15 Mar 2006 00:39:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJOj4-0003K5-Rk for ccamp-archive@ietf.org; Wed, 15 Mar 2006 00:39:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJOde-000OFS-IV for ccamp-data@psg.com; Wed, 15 Mar 2006 05:33:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.68] (helo=smtpauth08.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJOde-000OF2-5t; Wed, 15 Mar 2006 05:33:38 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Y1tfrQh9kgs7kPtKcJLOPOy8rPw1yI856UDmBNF8WkIKVL7q3luFnIndS8KwtX1Z; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.238.108] (helo=jlucianilaptop) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FJOdd-00018h-Jc; Wed, 15 Mar 2006 00:33:37 -0500 Message-ID: <01a001c647f1$dbceee60$0500a8c0@jlucianilaptop> From: To: Cc: "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" , "Tom Nadeau (E-mail)" References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> <011601c6477f$4768b160$0500a8c0@jlucianilaptop> Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Wed, 15 Mar 2006 00:32:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654ab3f3391fbf28074834beb628481e0b8387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.238.108 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi Tom and Adrian, Due to the updates to the 2 other GMPLS MIB documents wanted to re-review this document. I did have one minor comment which was the naming convention used, specifically the use of the TC on the end of the names of these Textual Conventions. GmplsFreeformLabelTC GmplsLabelTypeTC GmplsSegmentDirectionTC Could this "TC" be removed? Sorry to not catch this earlier. The reason is that this is not consistent with other Textual Conventions. Thanks, Joan From owner-ccamp@ops.ietf.org Wed Mar 15 11:26:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJYp2-0000eq-L7 for ccamp-archive@ietf.org; Wed, 15 Mar 2006 11:26:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJYp1-000701-Cb for ccamp-archive@ietf.org; Wed, 15 Mar 2006 11:26:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJYgP-000LNi-Ro for ccamp-data@psg.com; Wed, 15 Mar 2006 16:17:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJYgP-000LNW-C6 for ccamp@ops.ietf.org; Wed, 15 Mar 2006 16:17:09 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2006 08:16:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,195,1139212800"; d="scan'208"; a="23654002:sNHT23722536" Received: from [10.83.15.54] (rtp-tnadeau-vpn5.cisco.com [10.83.15.54]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k2FGGwWd019747; Wed, 15 Mar 2006 11:16:58 -0500 (EST) In-Reply-To: <01a001c647f1$dbceee60$0500a8c0@jlucianilaptop> References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> <011601c6477f$4768b160$0500a8c0@jlucianilaptop> <01a001c647f1$dbceee60$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Wed, 15 Mar 2006 11:16:53 -0500 To: X-Mailer: Apple Mail (2.746.3) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Mar 15, 2006, at 12:32 AM, wrote: > > Hi Tom and Adrian, > > Due to the updates to the 2 other GMPLS MIB documents > wanted to re-review this document. > > I did have one minor comment which was > the naming convention used, specifically > the use of the TC on the end of the names of these > Textual Conventions. > > GmplsFreeformLabelTC > GmplsLabelTypeTC > GmplsSegmentDirectionTC > > Could this "TC" be removed? Sorry to not catch this > earlier. The "TC" was appended to remove the ambiguity between the variable and TC names. This is actually a warning from SmiLint too. Something like "Warning: object and TC differ only in case". > The reason is that this is not consistent with > other Textual Conventions. I tried to make all TCs end in "TC" for the reason stated above. I will go back and 2x check the others and make things consistent. --Tom > > Thanks, > Joan > From asd@yahoo.co.jp Thu Mar 16 12:13:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJw2A-0007zB-M4 for ccamp-archive@ietf.org; Thu, 16 Mar 2006 12:13:10 -0500 Received: from [218.24.126.142] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJw29-00015b-Mi for ccamp-archive@ietf.org; Thu, 16 Mar 2006 12:13:10 -0500 To: From: =?iso-2022-jp?B?QVNE?= Subject: =?iso-2022-jp?B?GyRCIXklOSU/ITxDQkA4SGtPQyF5GyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed $B@.6b=w@-$N<;EJ$,;:$s$@!V;d$@$1$N%9%?!) id 1FKG0c-00084e-86 for ccamp-data@psg.com; Fri, 17 Mar 2006 14:32:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKG0b-00084L-BI; Fri, 17 Mar 2006 14:32:53 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2HEWZOk023424; Fri, 17 Mar 2006 08:32:36 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Mar 2006 15:32:33 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E1EEA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, "Alex Zinin (E-mail)" Cc: ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Tom Nadeau (E-mail)" Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Fri, 17 Mar 2006 15:32:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Thanks for this great review Joan. Seemsthat a new revision is warranted, and so I will record these MIB doctor review comments in the ID tracker and I suggest to Alex to mark the document as revised ID needed. Bert > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Tuesday, March 14, 2006 16:52 > To: ccamp@ops.ietf.org > Cc: Wijnen, Bert (Bert); Dan Romascanu (E-mail); Adrian > Farrel (E-mail); > Bill Fenner (E-mail); Alex Zinin (E-mail); Tom Nadeau (E-mail) > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt > > > Tom and Adrian, > > Let me apologize for my tardiness in posting the > review comments. > > A great deal of work went into this latest draft. Thank you. > Compile issues are listed first, and are followed by > review comments in order of the document. > > Will have the other reviews out by tomorrow. > > Thanks, Joan > > > > Compile Issues: > =============== > > > 1) smilint and smicngPRO complained > due to REFERENCE clause for gmplsTunnelARHopTable > needing an end quote: > > gmplsTunnelARHopTable OBJECT-TYPE > ... > REFERENCE > "1. Extensions to RSVP for LSP Tunnels, RFC 3209. > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. > 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) > Management Information Base (MIB), RFC 3812. > > ^ need end quote > > ::= { gmplsTeObjects 3 } > > > 2) smicngPRO > E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf" > is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in > module "GMPLS-TE-STD-MIB" > > > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelIsIntfcGroup <-- please add this > gmplsTunnelUnnumIf <--- please remove this > } > > > Also, please update the read-only conformance for gmplsTunnelUnnumIf. > > OBJECT gmplsTunnelUnnumIf > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > 3) This is listed under compile issues because it might be > an issue depending on what is really intended. > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX clause. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsTunnelLSPEncoding > SYNTAX IANAGmplsLSPEncodingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsTunnelSwitchingType > SYNTAX IANAGmplsSwitchingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > > > SYNTAX clauses such as InetAddressType and InetAddress don't > specify a subset, so need to ask if you intend > to have a subset for these such as: > > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > > SYNTAX InetAddress (SIZE(0|4|16)) > > > 4) Again, wrt Section 4.8 from RFC4181, it is recommended > that if MIB authors intend to have Optional Groups that these > be noted. This was done for the Read-only compliance but not > the Full-compliance, so would ask that all Optional Groups be > specified as recommended by Section 4.8. Reviewing these > Compliances statements is difficult without this information. > > > > Comments: > ----------- > > 1) Table of Contents: > > 3. The SNMP Management Framework .......................... 4 > > Should be: > 3. The Internet-Standard Management Framework > In other words, please change the title for section 3. > > > 2) 5.7 Use of 32-bit and 64-bit Counters > > Shouldn't the quote from RFC2863 be in quotes""? > > 3) 6. Cross-referencing to the gmplsLabelTable > > 2nd paragraph which begins: > The hop tables in this document (gmplsHopTable, gmplsCHopTable and > gmplsARHopTable) and the segment tables in the [RFC3813] > > There is no gmplsHopTable, is this supposed to be: > gmplsTunnelHopTable? > Similar comment with gmplsCHopTable and gmplsARHopTable. > > > 4) gmplsTunnelPathComp > > If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls' > does this object have meaning? > > 5) gmplsTunnelErrorTable, would expect to see these objects > contained in an MPLS group in Compliance/Conformance Statements. > > > 6) gmplsTunnelErrorTLVs OBJECT-TYPE > > When the string size is 0 this could indicate that > no TLVs are present, right? > That would be slightly more efficient than > having to look at the first octet. > If you agree, please modify the > DESCRIPTION to reflect this. > > > Conformace/Compliance: > --------------------- > 7) Please move some of the following comment to the > gmplsTeModuleReadOnlyCompliance DESCRIPTION > -- The mandatory group has to be implemented by all LSRs that > -- originate, terminate or act as transit for TE-LSPs/tunnels. > -- In addition, depending on the type of tunnels supported, other > -- groups become mandatory as explained below. > > > 8) Already mentioned this but was expecting to see MPLS objects > called out in a separate GROUP (e.g. objects which are valid when > gmplsTunnelLSPEncoding > has a value of 'tunnelLspNotGmpls', and other objects also). > For folks that want to support these MPLS related objects > prior to supporting GMPLS, this would be > important to understand, so the more clearly noted by the MIB the > better. > > > > 9) NIT: In the read-only conformance there is a comment: > > -- All scalars have max access read-only > > which appears in front of a bunch of objects that are > part of a table. Please remove this comment since it > doesn't apply. > > 10) NIT: > > --glmpsTunnelCHopTable > > ^^ typo > > > 11) Security Section > > NIT: the network via SNMP. These are the tables and > objects and their > sensitivity/vulnerability: > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, > gmplsTunnelErrorTable collectively show the tunnel network > > > Should have an "and" > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and > > ^^^ > > gmplsTunnelErrorTable collectively show the tunnel network > > > > 12) Normative References: > [RFC4328] Papadimitriou, D., Ed., "Generalized MPLS Signalling > Extensions for G.709 Optical Transport Networks > Control", draft-ietf-ccamp-gmpls-g709, work > in progress. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please update. > > --end of comments-- > From owner-ccamp@ops.ietf.org Fri Mar 17 09:39:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKG7R-0002XM-AO for ccamp-archive@ietf.org; Fri, 17 Mar 2006 09:39:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKG7Q-0000jV-13 for ccamp-archive@ietf.org; Fri, 17 Mar 2006 09:39:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKG0U-00083p-Vc for ccamp-data@psg.com; Fri, 17 Mar 2006 14:32:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKG0U-00083X-93; Fri, 17 Mar 2006 14:32:46 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2HEWcnj023507; Fri, 17 Mar 2006 08:32:40 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Mar 2006 15:32:36 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E1EE9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , jcucchiara@mindspring.com Cc: ccamp@ops.ietf.org, "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Fri, 17 Mar 2006 15:32:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Inline > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, March 15, 2006 17:17 > To: jcucchiara@mindspring.com > Cc: ccamp@ops.ietf.org; Wijnen, Bert (Bert); Dan Romascanu (E-mail); > Adrian Farrel (E-mail); Bill Fenner (E-mail); Alex Zinin (E-mail) > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt > > > > On Mar 15, 2006, at 12:32 AM, wrote: > > > > > Hi Tom and Adrian, > > > > Due to the updates to the 2 other GMPLS MIB documents > > wanted to re-review this document. > > > > I did have one minor comment which was > > the naming convention used, specifically > > the use of the TC on the end of the names of these > > Textual Conventions. > > > > GmplsFreeformLabelTC > > GmplsLabelTypeTC > > GmplsSegmentDirectionTC > > > > Could this "TC" be removed? Sorry to not catch this > > earlier. > > The "TC" was appended to remove the ambiguity > between the variable and TC names. This is actually a > warning from SmiLint too. Something like "Warning: object and > TC differ only in case". > Note that it is a warning. So it is not mandatory to change. I agree with the warning in that it is better to not have exactly the same names for TCs and for and object descriptors (variable names). Not sure that adding TC at the end of the TC descriptor is the best solution, but it is one way to do things. > > The reason is that this is not consistent with > > other Textual Conventions. > > I tried to make all TCs end in "TC" for > the reason stated above. I will go back and 2x check > the others and make things consistent. > Consistency is also a good thing as I have always been saying (I think). So do I take from this we should expect a new rev? Bert > --Tom > > > > > > Thanks, > > Joan > > > From owner-ccamp@ops.ietf.org Fri Mar 17 09:41:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKG93-0002f1-Le for ccamp-archive@ietf.org; Fri, 17 Mar 2006 09:41:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKG93-0000lv-72 for ccamp-archive@ietf.org; Fri, 17 Mar 2006 09:41:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKG0R-00083L-St for ccamp-data@psg.com; Fri, 17 Mar 2006 14:32:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKG0Q-000831-Qh; Fri, 17 Mar 2006 14:32:42 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2HEWYdx023420; Fri, 17 Mar 2006 08:32:35 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Mar 2006 15:32:33 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E1EE8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, "Alex Zinin (E-mail)" Cc: "Dan Romascanu (E-mail)" , ccamp@ops.ietf.org, "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Tom Nadeau (E-mail)" Subject: RE: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt Date: Fri, 17 Mar 2006 15:32:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Thanks Joan for anotehr great review. From what I read here, it seems we need yet another revision. So I am recording these MIB doctor comments in the ID tracker and I sugegst to ALEX to mark the document as revised ID needed. Bert > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Wednesday, March 15, 2006 06:31 > To: ccamp@ops.ietf.org > Cc: Wijnen, Bert (Bert); Dan Romascanu (E-mail); Adrian > Farrel (E-mail); > Bill Fenner (E-mail); Alex Zinin (E-mail); Tom Nadeau (E-mail) > Subject: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt > > > Hi Tom and Adrian, > > Thank you for all the great updates > to this draft. Compile issues listed > first, followed by review comments. > > Thanks, > Joan > > Compile Issues > ================ > > GMPLS-LSR-STD-MIB > ==================== > 1) smicngPRO > W: f(GMPLS-LSR-STD-MIB), (391,18) For > "gmplsOutSegmentTTLDecrement", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (397,18) For > "gmplsInSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (404,18) For > "gmplsOutSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (447,14) For > "gmplsInterfaceSignalingCaps", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (460,18) For > "gmplsInterfaceRsvpHelloPeriod", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (474,18) For > "gmplsInSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (488,18) For > "gmplsOutSegmentTTLDecrement", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (494,18) For " > gmplsOutSegmentExtraParamsPtr", syntax is identical > > > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsInterfaceRsvpHelloPeriod > SYNTAX Unsigned32 > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. Only forward(1) needs to be > supported by implementations that only support unidirectional > LSPs." > > OBJECT gmplsInSegmentExtraParamsPtr > SYNTAX RowPointer > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > > > > > > GMPLS-LABEL-STD-MIB > =================== > > 1) smicngPRO and smiLint flagged line 622 > > E: f(GMPLS-LABEL-STD-MIB), (622,6) syntax error > E: f(GMPLS-LABEL-STD-MIB), (622,6) Syntax for OBJECT clause is > "OBJECT" > E: f(GMPLS-LABEL-STD-MIB), (518,12) Group "gmplsLabelTableGroup" is > both a MANDATORY and conditional group for module > "GMPLS-LABEL-STD-MIB" > > OBJECT gmplsLabelRowStatus > MIN-ACCESS read-only > --> SYNTAX RowStatus { active(1) } > DESCRIPTION > "Support for notInService, createAndWait and notReady is not > required." > > Need to put SYNTAX clause before MIN-ACCESS clause. > > 2) E: f(GMPLS-LABEL-STD-MIB), (518,12) > Group "gmplsLabelTableGroup" is both a MANDATORY and > conditional group for module "GMPLS-LABEL-STD-MIB" > > The above is flagged as an error but is actually more > pervasive than just this one error: both the > FullCompliance and the Read-only Compliance statements have > Groups listed as Mandatory but then appear as Optional. > This needs to be clarified per RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements. > > Related to this, the following groups are currently listed as > Mandatory under Full compliance, but would think > that these only apply if the device has certain > interfaces (e.g. gmplsLabelSonetSdhGroup if Sonet > interfaces are on the device), is this > an Optional Group? What about these other groups? > > gmplsLabelPacketGroup, > gmplsLabelPortWavelengthGroup, > gmplsLabelFreeformGroup, > gmplsLabelSonetSdhGroup, > gmplsLabelWavebandGroup > > > 3) Same comment as with the GMPLS-TE-STD-MIB wrt having > an MPLS GROUP in the compliances statements. Would be > most helpful to know what objects apply to MPLS. > > > > Comments in order of document. > ============================== > 1) Table of Contents > > 3. The SNMP Management Framework .................... 4 > Please rename to: > > The Internet-Standard Management Framework > > 2) 1.1. Migration Strategy, 5th paragraph: > > the various label pointer objects in the MPLS-STD-LSR-MIB module > ^^^^ > Please fix: MPLS-STD-LSR-MIB to MPLS-LSR-STD-MIB > > 3) Please remove "and OBJECT-IDENTIFIERS" in the last paragraph > > Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] > and [GMPLSTCMIB] ... > > > 4) gmplsLsrModuleFullCompliance MODULE-COMPLIANCE > > 2 issues: > a) The following 2 objects could have an MIN-ACCESS of > read-only since the DEFVAL is forward. > > b) the DESCRIPTION is a little awkward, could this be reworded: > "The only valid value for unidirectional LSPs is forward(1)." > > This would need to be updated in the read-only section also. > (Similar comments for gmplsOutSegmentDirection). > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-write > DESCRIPTION > "Only forward(1) needs to be supported by implementations that > only support unidirectional LSPs." > > OBJECT gmplsOutSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-write > DESCRIPTION > "Only forward(1) needs to be supported by implementations that > only support unidirectional LSPs." > > GMPLS-LABEL-STD-MIB > ======================== > 5) gmplsLabelInterface and gmplsLabelIndex > > I had a question regarding these 2 indices: if there is a > per-platform > label, MUST both of these values be zero? Is there any other > circumstance > in which both would or could be zero? > > I was a little confused on the use of "could" and "may result" and was > wondering if this should be made a little more forceful. > > > 6) As previously mentioned could MPLS objects be denoted > in a separate GROUP (e.g., gmplsLabelMplsLabel and possibly other > objects). > > 7) Please put the comment in the DESCRIPTION clause of > the gmplsLabelModuleFullCompliance. > -- The mandatory groups have to be implemented by GMPLS LSRs > -- claiming support for this MIB module. This MIB module is, > -- however, not mandatory for a working implementation of a GMPLS > -- LSR with full MIB support if the GMPLS labels in use can be > -- represented within a 32 bit quantity. > > > --end of comments -- > > From owner-ccamp@ops.ietf.org Fri Mar 17 18:14:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKO91-0002gF-H7 for ccamp-archive@ietf.org; Fri, 17 Mar 2006 18:14:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKO90-0000kT-7Q for ccamp-archive@ietf.org; Fri, 17 Mar 2006 18:14:07 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKO2w-000MG5-43 for ccamp-data@psg.com; Fri, 17 Mar 2006 23:07:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKO2v-000MFr-Hv for ccamp@ops.ietf.org; Fri, 17 Mar 2006 23:07:49 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 17 Mar 2006 15:07:49 -0800 X-IronPort-AV: i="4.03,106,1141632000"; d="scan'208"; a="315645730:sNHT27578844" Received: from [204.96.114.236] (sjc-vpn5-330.cisco.com [10.21.89.74]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2HN7k7T023516; Fri, 17 Mar 2006 15:07:47 -0800 (PST) In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155098E1EE9@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B155098E1EE9@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: jcucchiara@mindspring.com, ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Fri, 17 Mar 2006 17:07:42 -0600 To: "Wijnen, Bert (Bert)" X-Mailer: Apple Mail (2.746.3) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 On Mar 17, 2006, at 8:32 AM, Wijnen, Bert (Bert) wrote: > Inline > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: Wednesday, March 15, 2006 17:17 >> To: jcucchiara@mindspring.com >> Cc: ccamp@ops.ietf.org; Wijnen, Bert (Bert); Dan Romascanu (E-mail); >> Adrian Farrel (E-mail); Bill Fenner (E-mail); Alex Zinin (E-mail) >> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt >> >> >> >> On Mar 15, 2006, at 12:32 AM, wrote: >> >>> >>> Hi Tom and Adrian, >>> >>> Due to the updates to the 2 other GMPLS MIB documents >>> wanted to re-review this document. >>> >>> I did have one minor comment which was >>> the naming convention used, specifically >>> the use of the TC on the end of the names of these >>> Textual Conventions. >>> >>> GmplsFreeformLabelTC >>> GmplsLabelTypeTC >>> GmplsSegmentDirectionTC >>> >>> Could this "TC" be removed? Sorry to not catch this >>> earlier. >> >> The "TC" was appended to remove the ambiguity >> between the variable and TC names. This is actually a >> warning from SmiLint too. Something like "Warning: object and >> TC differ only in case". >> > > Note that it is a warning. So it is not mandatory to change. > I agree with the warning in that it is better to not have exactly the > same names for TCs and for and object descriptors (variable names). > Not sure that adding TC at the end of the TC descriptor is the > best solution, but it is one way to do things. > >>> The reason is that this is not consistent with >>> other Textual Conventions. >> >> I tried to make all TCs end in "TC" for >> the reason stated above. I will go back and 2x check >> the others and make things consistent. >> > Consistency is also a good thing as I have always been saying (I > think). > > So do I take from this we should expect a new rev? Hi Bert, Yes. I spoke with Joan offline yesterday and am working on incorporating all of her changes. I should have something on Monday and will email to her directly to review my fixes/changes. I will post an update as soon as the ID gate opens. --Tom > > Bert >> --Tom >> >> >>> >>> Thanks, >>> Joan >>> >> From asd@yahoo.co.jp Sun Mar 19 01:16:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKrD3-0000Mp-JV for ccamp-archive@ietf.org; Sun, 19 Mar 2006 01:16:13 -0500 Received: from [218.24.126.2] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKrCz-0008WF-Tn for ccamp-archive@ietf.org; Sun, 19 Mar 2006 01:16:12 -0500 To: From: =?iso-2022-jp?B?QVNE?= Subject: =?iso-2022-jp?B?GyRCTEBGfCROJTklPyE8JE83LyRAISobKEI=?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de $B=w@-%9%]%s%5!<$N?4>p$r$7$C$+$jDO$s$G$/$@$5$$!#(B http://live-doll.com/live/ $B$=$&$9$l$P7/$b!"L@F|$+$i%9%?!<$@!#(B http://live-doll.com/live/ $BLd!K(B fafafa163com@163.com From owner-ccamp@ops.ietf.org Mon Mar 20 02:30:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEqQ-0000Cj-3A for ccamp-archive@ietf.org; Mon, 20 Mar 2006 02:30:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLElZ-0006KI-VP for ccamp-archive@ietf.org; Mon, 20 Mar 2006 02:25:29 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLEeW-0004ny-Ny for ccamp-data@psg.com; Mon, 20 Mar 2006 07:18:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLEeV-0004nm-R4 for ccamp@ops.ietf.org; Mon, 20 Mar 2006 07:18:07 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FLEea-0001bm-00 for ccamp@ops.ietf.org; Mon, 20 Mar 2006 07:18:12 +0000 Received: from Puppy ([65.74.232.49] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 07:18:33 +0000 Message-ID: <04c401c64bef$0c630240$e2808182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Reminder - slides on Tuesday at the latest Date: Mon, 20 Mar 2006 07:19:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 20 Mar 2006 07:18:33.0687 (UTC) FILETIME=[7F4FBE70:01C64BEE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Thanks! From owner-ccamp@ops.ietf.org Mon Mar 20 15:34:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLR4t-0005iN-Pi for ccamp-archive@ietf.org; Mon, 20 Mar 2006 15:34:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLR4t-00024h-JH for ccamp-archive@ietf.org; Mon, 20 Mar 2006 15:34:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLQzW-0008Ov-Hf for ccamp-data@psg.com; Mon, 20 Mar 2006 20:28:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLQzN-0008OK-Uq; Mon, 20 Mar 2006 20:28:30 +0000 Message-ID: <441F106C.2070808@psg.com> Date: Mon, 20 Mar 2006 21:28:28 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Reminder - slides on Tuesday at the latest References: <04c401c64bef$0c630240$e2808182@Puppy> In-Reply-To: <04c401c64bef$0c630240$e2808182@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de adrian - didn't recall having seen a minder ;-) Adrian Farrel wrote: > Thanks! > > > . > From owner-ccamp@ops.ietf.org Tue Mar 21 15:43:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnhC-00020h-GG for ccamp-archive@ietf.org; Tue, 21 Mar 2006 15:43:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnhB-00086C-7x for ccamp-archive@ietf.org; Tue, 21 Mar 2006 15:43:14 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLnb5-0005lb-1n for ccamp-data@psg.com; Tue, 21 Mar 2006 20:36:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLnb4-0005lG-Hk for ccamp@ops.ietf.org; Tue, 21 Mar 2006 20:36:54 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 Mar 2006 15:36:44 -0500 X-IronPort-AV: i="4.03,116,1141621200"; d="scan'208"; a="84648635:sNHT31354488" Received: from [130.129.129.132] (rtp-vpn4-351.cisco.com [10.82.209.95]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2LKagVV023800; Tue, 21 Mar 2006 15:36:43 -0500 (EST) In-Reply-To: <01a001c647f1$dbceee60$0500a8c0@jlucianilaptop> References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> <011601c6477f$4768b160$0500a8c0@jlucianilaptop> <01a001c647f1$dbceee60$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <38C461EB-7062-4582-99D7-1B85E6DA4956@cisco.com> Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Tue, 21 Mar 2006 14:19:22 -0600 To: "" X-Mailer: Apple Mail (2.746.3) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 As per Bert's reply to this, I have made all of the TCs in the CCAMP/GMPLS TC and LSR MIBs to have "TC" at the end of their names to keep them consistent. --Tom > > Hi Tom and Adrian, > > Due to the updates to the 2 other GMPLS MIB documents > wanted to re-review this document. > > I did have one minor comment which was > the naming convention used, specifically > the use of the TC on the end of the names of these > Textual Conventions. > > GmplsFreeformLabelTC > GmplsLabelTypeTC > GmplsSegmentDirectionTC > > Could this "TC" be removed? Sorry to not catch this > earlier. > > The reason is that this is not consistent with > other Textual Conventions. > > Thanks, > Joan > From owner-ccamp@ops.ietf.org Wed Mar 22 10:46:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5Xv-0003Uy-CI for ccamp-archive@ietf.org; Wed, 22 Mar 2006 10:46:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5Xv-0004Nx-0W for ccamp-archive@ietf.org; Wed, 22 Mar 2006 10:46:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM5OX-0007mP-BI for ccamp-data@psg.com; Wed, 22 Mar 2006 15:37:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM5OW-0007mB-Qi for ccamp@ops.ietf.org; Wed, 22 Mar 2006 15:37:08 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2006 07:37:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="24192091:sNHT24823920" Received: from [204.96.114.236] (rtp-vpn3-247.cisco.com [10.82.216.247]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2MFaxVU006778; Wed, 22 Mar 2006 10:36:59 -0500 (EST) In-Reply-To: <007f01c64dc2$6e8a7640$0500a8c0@jlucianilaptop> References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> <011601c6477f$4768b160$0500a8c0@jlucianilaptop> <01a001c647f1$dbceee60$0500a8c0@jlucianilaptop> <38C461EB-7062-4582-99D7-1B85E6DA4956@cisco.com> <007f01c64dc2$6e8a7640$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DA9D182-1B80-4254-9143-6A989851269F@cisco.com> Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Wed, 22 Mar 2006 09:36:53 -0600 To: X-Mailer: Apple Mail (2.746.3) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 On Mar 22, 2006, at 9:08 AM, wrote: > > Hi Tom, > > I think we have a disconnect somewhere...when I said > that the use of the "TC" was not consistent, I meant with > TCs in general (not just in GMPLS MIBs), so would prefer > to see this removed. > > I looked at the use of the Textual Conventions in the > GMPLS MIBs and saw that one still is the same as > an Object (except in case) which was gmplsLabelType. > (I do think there was more overlap originally but names have > changed since then). There was, and I am fixing that now. Almost done with the TE module and I will send them all over for your review. I updated the others yesterday. > My suggestion would be to remove the "TC" suffix from the > TCs and change the name of the overlapping gmplsLabelType object > to something else (gmplsTypeOfLabel). > > I do realize this is a style issue, so not a show stopper, only a > humble > suggestion. I understand your point and I respectfully declined to change them, but agreed (based on Bert's post) to make them consistent throughout the modules. --Tom > > Thanks, > Joan > > > > ----- Original Message ----- > From: Thomas D. Nadeau > To: > Cc: ; Wijnen, Bert (Bert) ; > Dan > Romascanu (E-mail) ; Adrian Farrel (E-mail) > ; Bill Fenner (E-mail) > ; Alex > Zinin (E-mail) > Sent: Tuesday, March 21, 2006 3:19 PM > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt > > >> >> As per Bert's reply to this, I have made >> all of the TCs in the CCAMP/GMPLS TC and LSR MIBs to have >> "TC" at the end of their names to keep them consistent. >> >> --Tom >> >> >>> >>> Hi Tom and Adrian, >>> >>> Due to the updates to the 2 other GMPLS MIB documents >>> wanted to re-review this document. >>> >>> I did have one minor comment which was >>> the naming convention used, specifically >>> the use of the TC on the end of the names of these >>> Textual Conventions. >>> >>> GmplsFreeformLabelTC >>> GmplsLabelTypeTC >>> GmplsSegmentDirectionTC >>> >>> Could this "TC" be removed? Sorry to not catch this >>> earlier. >>> >>> The reason is that this is not consistent with >>> other Textual Conventions. >>> >>> Thanks, >>> Joan >>> >> From owner-ccamp@ops.ietf.org Wed Mar 22 11:18:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM62S-0004D1-OH for ccamp-archive@ietf.org; Wed, 22 Mar 2006 11:18:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM62R-0005rw-BW for ccamp-archive@ietf.org; Wed, 22 Mar 2006 11:18:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM5sa-0009ob-Gk for ccamp-data@psg.com; Wed, 22 Mar 2006 16:08:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM5sZ-0009oK-H1 for ccamp@ops.ietf.org; Wed, 22 Mar 2006 16:08:11 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FM5sV-0000y9-00 for ccamp@ops.ietf.org; Wed, 22 Mar 2006 16:08:07 +0000 Received: from Puppy ([130.129.128.226] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 16:08:37 +0000 Message-ID: <006d01c64dcb$6e31dfe0$e2808182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaisons received from ITU-T Study Group 15 Date: Wed, 22 Mar 2006 16:10:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Mar 2006 16:08:38.0125 (UTC) FILETIME=[E10F59D0:01C64DCA] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi, We received the following liaisons from the latest SG15 meeting in February. ITU-T Study Group 15 OTNT Standardization Work Plan https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=199 We are invited to comment. Recent ASON Recommendations https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=200 This is for our information as the Recommendations have already been approved and we are not invited to comment. Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Mar 22 11:52:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6Zi-0003l3-Qv for ccamp-archive@ietf.org; Wed, 22 Mar 2006 11:52:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6Zi-0007lF-CD for ccamp-archive@ietf.org; Wed, 22 Mar 2006 11:52:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM6SI-000CGa-5k for ccamp-data@psg.com; Wed, 22 Mar 2006 16:45:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM6SH-000CFy-9D for ccamp@ops.ietf.org; Wed, 22 Mar 2006 16:45:05 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2006 08:44:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="24198507:sNHT26536084" Received: from [204.96.114.236] (rtp-vpn3-247.cisco.com [10.82.216.247]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2MGiqVU021043; Wed, 22 Mar 2006 11:44:53 -0500 (EST) In-Reply-To: <019c01c647f1$a0fa81a0$0500a8c0@jlucianilaptop> References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> <011601c6477f$4768b160$0500a8c0@jlucianilaptop> <019c01c647f1$a0fa81a0$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <052317DF-DA29-4D6F-A00D-99FA520C4F42@cisco.com> Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt Date: Wed, 22 Mar 2006 10:44:47 -0600 To: "" X-Mailer: Apple Mail (2.746.3) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee On Mar 14, 2006, at 11:30 PM, wrote: > Hi Tom and Adrian, > > Thank you for all the great updates > to this draft. Compile issues listed > first, followed by review comments. > > Thanks, > Joan > > Compile Issues > ================ > > GMPLS-LSR-STD-MIB > ==================== > 1) smicngPRO > W: f(GMPLS-LSR-STD-MIB), (391,18) For > "gmplsOutSegmentTTLDecrement", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (397,18) For > "gmplsInSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (404,18) For > "gmplsOutSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (447,14) For > "gmplsInterfaceSignalingCaps", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (460,18) For > "gmplsInterfaceRsvpHelloPeriod", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (474,18) For > "gmplsInSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (488,18) For > "gmplsOutSegmentTTLDecrement", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (494,18) For " > gmplsOutSegmentExtraParamsPtr", syntax is identical > > > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsInterfaceRsvpHelloPeriod > SYNTAX Unsigned32 > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. Only forward(1) needs to be > supported by implementations that only support unidirectional > LSPs." > > OBJECT gmplsInSegmentExtraParamsPtr > SYNTAX RowPointer > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." Fixed these. > > > > > > > GMPLS-LABEL-STD-MIB > =================== > > 1) smicngPRO and smiLint flagged line 622 > > E: f(GMPLS-LABEL-STD-MIB), (622,6) syntax error > E: f(GMPLS-LABEL-STD-MIB), (622,6) Syntax for OBJECT clause is > "OBJECT" > E: f(GMPLS-LABEL-STD-MIB), (518,12) Group "gmplsLabelTableGroup" is > both a MANDATORY and conditional group for module "GMPLS-LABEL- > STD-MIB" > > OBJECT gmplsLabelRowStatus > MIN-ACCESS read-only > --> SYNTAX RowStatus { active(1) } > DESCRIPTION > "Support for notInService, createAndWait and notReady is not > required." > > Need to put SYNTAX clause before MIN-ACCESS clause. > > 2) E: f(GMPLS-LABEL-STD-MIB), (518,12) > Group "gmplsLabelTableGroup" is both a MANDATORY and > conditional group for module "GMPLS-LABEL-STD-MIB" > > The above is flagged as an error but is actually more > pervasive than just this one error: both the > FullCompliance and the Read-only Compliance statements have > Groups listed as Mandatory but then appear as Optional. > This needs to be clarified per RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements. > > Related to this, the following groups are currently listed as > Mandatory under Full compliance, but would think > that these only apply if the device has certain > interfaces (e.g. gmplsLabelSonetSdhGroup if Sonet > interfaces are on the device), is this > an Optional Group? What about these other groups? > > gmplsLabelPacketGroup, > gmplsLabelPortWavelengthGroup, > gmplsLabelFreeformGroup, > gmplsLabelSonetSdhGroup, > gmplsLabelWavebandGroup > Fixed all of the above. > > 3) Same comment as with the GMPLS-TE-STD-MIB wrt having > an MPLS GROUP in the compliances statements. Would be > most helpful to know what objects apply to MPLS. Can we talk about this one in more detail? I am confused about what you are asking for specifically here. > Comments in order of document. > ============================== > 1) Table of Contents > > 3. The SNMP Management Framework .................... 4 > Please rename to: > > The Internet-Standard Management Framework > > 2) 1.1. Migration Strategy, 5th paragraph: > > the various label pointer objects in the MPLS-STD-LSR-MIB module > ^^^^ > Please fix: MPLS-STD-LSR-MIB to MPLS-LSR-STD-MIB > > 3) Please remove "and OBJECT-IDENTIFIERS" in the last paragraph > > Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] > and [GMPLSTCMIB] ... > > > 4) gmplsLsrModuleFullCompliance MODULE-COMPLIANCE > > 2 issues: > a) The following 2 objects could have an MIN-ACCESS of > read-only since the DEFVAL is forward. > > b) the DESCRIPTION is a little awkward, could this be reworded: > "The only valid value for unidirectional LSPs is forward(1)." > > This would need to be updated in the read-only section also. > (Similar comments for gmplsOutSegmentDirection). > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-write > DESCRIPTION > "Only forward(1) needs to be supported by implementations that > only support unidirectional LSPs." > > OBJECT gmplsOutSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-write > DESCRIPTION > "Only forward(1) needs to be supported by implementations that > only support unidirectional LSPs." > > GMPLS-LABEL-STD-MIB > ======================== > 5) gmplsLabelInterface and gmplsLabelIndex > > I had a question regarding these 2 indices: if there is a per- > platform > label, MUST both of these values be zero? Is there any other > circumstance > in which both would or could be zero? OK, I updated the text a bit. please look at it. > > I was a little confused on the use of "could" and "may result" and was > wondering if this should be made a little more forceful. Yes, I think we should change this to SHOULD. > 6) As previously mentioned could MPLS objects be denoted > in a separate GROUP (e.g., gmplsLabelMplsLabel and possibly other > objects). Can you please explain why we would do this instead of or in addition to what we are doing now? I am confused since we are already requiring the objects from the MPLS RFCs in the mandatory MODULE statements. > 7) Please put the comment in the DESCRIPTION clause of > the gmplsLabelModuleFullCompliance. > -- The mandatory groups have to be implemented by GMPLS LSRs > -- claiming support for this MIB module. This MIB module is, > -- however, not mandatory for a working implementation of a GMPLS > -- LSR with full MIB support if the GMPLS labels in use can be > -- represented within a 32 bit quantity. OK. --Tom > > > --end of comments -- From owner-ccamp@ops.ietf.org Wed Mar 22 12:13:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6tP-0004Zm-1D for ccamp-archive@ietf.org; Wed, 22 Mar 2006 12:13:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6tO-0000Fm-JX for ccamp-archive@ietf.org; Wed, 22 Mar 2006 12:13:07 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM6n6-000DlY-UU for ccamp-data@psg.com; Wed, 22 Mar 2006 17:06:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM6n4-000DlC-OQ for ccamp@ops.ietf.org; Wed, 22 Mar 2006 17:06:35 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FM6nK-0008Vy-00 for ccamp@ops.ietf.org; Wed, 22 Mar 2006 17:06:50 +0000 Received: from Puppy ([130.129.128.226] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 17:07:01 +0000 Message-ID: <00c601c64dd3$96bd89c0$e2808182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Subject: Fw: Liaison on issues related to T-MPLS (G.8110.1 and G.8112) Date: Wed, 22 Mar 2006 17:10:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Mar 2006 17:07:01.0281 (UTC) FILETIME=[091A8910:01C64DD3] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 FYI, Here is a liaison sent by your ADs and the chairs of MPLS and CCAMP to the ITU-T in an attempt to get review input to T-MPLS. Thanks for the discussion in MPLS (and thanks for only shooting me a little). Adrian ----- Original Message ----- From: "Adrian Farrel" To: ; Cc: "Scott Bradner" ; "Adrian Farrel" ; "Stephen Trowbridge" ; "Ross Callon" ; "Bill Fenner" ; "'Kireeti Kompella'" ; "Loa Andersson" ; "George Swallow" ; "Scott W Brim" Sent: Wednesday, March 22, 2006 5:01 PM Subject: Liaison on issues related to T-MPLS (G.8110.1 and G.8112) > From: The IETF Routing Area, and the MPLS and CCAMP working groups > To: ITU-T SG-15 (Yoichi Maeda) > Cc: ITU-T WP 3 (Stephen Trowbridge) > Scott Bradner (IETF-ITU liaison manager) > Scott Brim (IETF-ITU NGN liaison manager) > Title: Liaison on issues related to T-MPLS (G.8110.1 and G.8112) > Response contact: Loa Andersson > Technical contact: Loa Andersson > Purpose: For action > Deadline 29th March 2006 > > Dear Mr. Maeda, > > At the MPLS working group meeting in Dallas on March 20th there was a > brief discussion on the Transport MPLS (T-MPLS) work taking place in SG 13 > and 15 of the ITU-T. > > The IETF and the MPLS and the CCAMP working groups have not had an > opportunity to comment on the documents so far. We also learned that there > is only a short time left before the Recommendations are scheduled to be > completed through AAP. > > We would like to ask that the ITU-T SGs liaise the draft recommendations > to the IETF, and in particular to the MPLS and CCAMP working groups, and > at the same time give us enough time to comment on the documents. We > appreciate that this may require a delay in the normal document process in > the ITU-T, but we feel that this would be desirable in the interest > of cooperation between our organisations and for the wider benefit of the > industry. A process to change and extend the MPLS and CCAMP specifications > will be found in draft-andersson-rtg-gmpls-change-02. This process is > being developed in cooperation with ITU-T, and we are working to > incorporate the comments received based on this information exchange. > > We believe that there may be some issues and concerns with the T-MPLS > work, but we have not yet been able to review it and the time frame for > the AAP will not allow a detailed coordinated response to this work. > > If this it is not possible to give us time comment on these documents, we > are concerned that any Recommendations related to T-MPLS may be > incompatible with current and/or future work on MPLS. > > > MPLS working group co-chairs > Loa Andersson and George Swallow > > CCAMP working group co-chairs > Adrian Farrel and Kireeti Kompella > > IETF Routing Area Directors > Bill Fenner and Ross Callon > From owner-ccamp@ops.ietf.org Wed Mar 22 12:35:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7Ex-00037x-4A for ccamp-archive@ietf.org; Wed, 22 Mar 2006 12:35:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7Ew-0000vQ-LD for ccamp-archive@ietf.org; Wed, 22 Mar 2006 12:35:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM79J-000FNc-V5 for ccamp-data@psg.com; Wed, 22 Mar 2006 17:29:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM79J-000FNO-1X for ccamp@ops.ietf.org; Wed, 22 Mar 2006 17:29:33 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2006 12:28:58 -0500 X-IronPort-AV: i="4.03,119,1141621200"; d="scan'208"; a="84726688:sNHT69223668362" Received: from [204.96.114.236] (rtp-vpn3-247.cisco.com [10.82.216.247]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2MHStVU000228; Wed, 22 Mar 2006 12:28:56 -0500 (EST) In-Reply-To: <011601c6477f$4768b160$0500a8c0@jlucianilaptop> References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> <011601c6477f$4768b160$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Wed, 22 Mar 2006 11:28:44 -0600 To: "" X-Mailer: Apple Mail (2.746.3) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b > Tom and Adrian, > > Let me apologize for my tardiness in posting the > review comments. Let me apologize for my tardiness in replying to you. *) > A great deal of work went into this latest draft. Thank you. > Compile issues are listed first, and are followed by > review comments in order of the document. > > Will have the other reviews out by tomorrow. > > Thanks, Joan > > > > Compile Issues: > =============== > > > 1) smilint and smicngPRO complained > due to REFERENCE clause for gmplsTunnelARHopTable > needing an end quote: > > gmplsTunnelARHopTable OBJECT-TYPE > ... > REFERENCE > "1. Extensions to RSVP for LSP Tunnels, RFC 3209. > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. > 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) > Management Information Base (MIB), RFC 3812. > > ^ need end quote > > ::= { gmplsTeObjects 3 } > > > 2) smicngPRO > E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf" > is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in > module "GMPLS-TE-STD-MIB" > > > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelIsIntfcGroup <-- please add this > gmplsTunnelUnnumIf <--- please remove this > } Done. > Also, please update the read-only conformance for gmplsTunnelUnnumIf. > > OBJECT gmplsTunnelUnnumIf > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > 3) This is listed under compile issues because it might be > an issue depending on what is really intended. > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX clause. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsTunnelLSPEncoding > SYNTAX IANAGmplsLSPEncodingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsTunnelSwitchingType > SYNTAX IANAGmplsSwitchingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." done. > SYNTAX clauses such as InetAddressType and InetAddress don't > specify a subset, so need to ask if you intend > to have a subset for these such as: > > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > > SYNTAX InetAddress (SIZE(0|4|16)) I found about 6 more, and fixed them. > > > 4) Again, wrt Section 4.8 from RFC4181, it is recommended > that if MIB authors intend to have Optional Groups that these > be noted. This was done for the Read-only compliance but not > the Full-compliance, so would ask that all Optional Groups be > specified as recommended by Section 4.8. Reviewing these > Compliances statements is difficult without this information. I don't understand. There are 5 groups, two of which are specified as Mandatory, and the other three are explained to be optional and why below that. > Comments: > ----------- > > 1) Table of Contents: > > 3. The SNMP Management Framework .......................... 4 > > Should be: > 3. The Internet-Standard Management Framework > In other words, please change the title for section 3. > > > 2) 5.7 Use of 32-bit and 64-bit Counters > > Shouldn't the quote from RFC2863 be in quotes""? Perhaps, but we were just following what was approved in section 6 of RFC3813: 6. Use of 32-bit and 64-bit Counters 64-bit counters are provided in this MIB module for high speed interfaces where the use of 32-bit counters might be impractical. The requirements on the use of 32-bit and 64-bit counters (copied verbatim from [RFC2863]) are as follows. For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported. > > 3) 6. Cross-referencing to the gmplsLabelTable > > 2nd paragraph which begins: > The hop tables in this document (gmplsHopTable, gmplsCHopTable and > gmplsARHopTable) and the segment tables in the [RFC3813] > > There is no gmplsHopTable, is this supposed to be: > gmplsTunnelHopTable? > Similar comment with gmplsCHopTable and gmplsARHopTable. > > > 4) gmplsTunnelPathComp > > If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls' > does this object have meaning? > > 5) gmplsTunnelErrorTable, would expect to see these objects > contained in an MPLS group in Compliance/Conformance Statements. Can you explain what "an MPLS group" would be specifically? > > > 6) gmplsTunnelErrorTLVs OBJECT-TYPE > > When the string size is 0 this could indicate that > no TLVs are present, right? > That would be slightly more efficient than > having to look at the first octet. > If you agree, please modify the > DESCRIPTION to reflect this. "The sequence of interface identifier TLVs reported with the error by the protocol code. The interpretation of the TLVs and the encoding within the protocol are described in the references. A value of zero in the first octet indicates that no TLVs are present." > > > Conformace/Compliance: > --------------------- > 7) Please move some of the following comment to the > gmplsTeModuleReadOnlyCompliance DESCRIPTION > -- The mandatory group has to be implemented by all LSRs that > -- originate, terminate or act as transit for TE-LSPs/tunnels. > -- In addition, depending on the type of tunnels supported, other > -- groups become mandatory as explained below. > > > 8) Already mentioned this but was expecting to see MPLS objects > called out in a separate GROUP (e.g. objects which are valid when > gmplsTunnelLSPEncoding > has a value of 'tunnelLspNotGmpls', and other objects also). > For folks that want to support these MPLS related objects > prior to supporting GMPLS, this would be > important to understand, so the more clearly noted by the MIB the > better. > > > > 9) NIT: In the read-only conformance there is a comment: > > -- All scalars have max access read-only > > which appears in front of a bunch of objects that are > part of a table. Please remove this comment since it > doesn't apply. > > 10) NIT: > > --glmpsTunnelCHopTable > > ^^ typo > > > 11) Security Section > > NIT: the network via SNMP. These are the tables and objects and > their > sensitivity/vulnerability: > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, > gmplsTunnelErrorTable collectively show the tunnel network > > > Should have an "and" > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and > > ^^^ > > gmplsTunnelErrorTable collectively show the tunnel network > > > > 12) Normative References: > [RFC4328] Papadimitriou, D., Ed., "Generalized MPLS Signalling > Extensions for G.709 Optical Transport Networks > Control", draft-ietf-ccamp-gmpls-g709, work in > progress. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please update. > > --end of comments-- From owner-ccamp@ops.ietf.org Wed Mar 22 13:32:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM88g-0000Pc-U2 for ccamp-archive@ietf.org; Wed, 22 Mar 2006 13:32:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM88g-0004G0-I6 for ccamp-archive@ietf.org; Wed, 22 Mar 2006 13:32:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM82I-000IUU-DI for ccamp-data@psg.com; Wed, 22 Mar 2006 18:26:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM82H-000IU9-Gm; Wed, 22 Mar 2006 18:26:21 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2MIPv6E010874; Wed, 22 Mar 2006 12:25:57 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Mar 2006 19:25:56 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509988BB1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , "" Cc: ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Wed, 22 Mar 2006 19:25:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Tom, > > > > 4) Again, wrt Section 4.8 from RFC4181, it is recommended > > that if MIB authors intend to have Optional Groups that these > > be noted. This was done for the Read-only compliance but not > > the Full-compliance, so would ask that all Optional Groups be > > specified as recommended by Section 4.8. Reviewing these > > Compliances statements is difficult without this information. > > I don't understand. There are 5 groups, two of which > are specified as Mandatory, and the other three are explained > to be optional and why below that. > It seems pretty clear that Joan tries to explain to you that the proper way to define those optional groups (in BOTH MODULE-COMPLIANCE statemnts( is to add the optional groups. You do it correctly for the read-only compliance, but not for the fullCOmpliance. So I think the fix is something like: OLD: gmplsTeModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for GMPLS-TE-STD-MIB. Such devices can then be monitored and also be configured using this MIB module. The mandatory group has to be implemented by all LSRs that originate, terminate or act as transit for TE-LSPs/tunnels. Nadeau and Farrel (Editors) [Page 40] ^L Internet Draft draft-ietf-ccamp-gmpls-te-mib-13.txt March 2006 In addition, depending on the type of tunnels supported, other groups become mandatory as explained below." MODULE -- this module MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup, gmplsTunnelSignaledGroup } ::= { gmplsTeCompliances 1 } NEW: gmplsTeModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for GMPLS-TE-STD-MIB. Such devices can then be monitored and also be configured using this MIB module." MODULE -- this module MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup, gmplsTunnelSignaledGroup } GROUP gmplsTunnelSignaledGroup DESCRIPTION "This group is mandatory for devices which support signaled tunnel set up, in addition to gmplsTunnelGroup. The following constraints apply: mplsTunnelSignallingProto should be at least read-only returning a value of ldp(2), or rsvp(3)." GROUP gmplsTunnelIsIntfcGroup DESCRIPTION "This group is mandatory for devices which support tunnels that are interfaces, in addition to gmplsTunnelGroup." GROUP gmplsTunnelOptionalGroup DESCRIPTION "Objects in this group are optional." GROUP gmplsTeNotificationGroup DESCRIPTION "This group is mandatory for those implementations which can implement the notifications contained in this group." ::= { gmplsTeCompliances 1 } Bert From owner-ccamp@ops.ietf.org Wed Mar 22 13:37:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8Cl-0004YF-Bm for ccamp-archive@ietf.org; Wed, 22 Mar 2006 13:37:11 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5hO-0004fF-Ot for ccamp-archive@ietf.org; Wed, 22 Mar 2006 10:56:38 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FM5V7-0003bP-Qv for ccamp-archive@ietf.org; Wed, 22 Mar 2006 10:43:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM5Il-0007SO-7x for ccamp-data@psg.com; Wed, 22 Mar 2006 15:31:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.69] (helo=elasmtp-mealy.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM5Ii-0007S1-Ls; Wed, 22 Mar 2006 15:31:08 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QhZ9Yu6FNU5XQjS8UdsWyyo3NAreKw2PRSFISnofSUuV0yaarJNqyfvFsmFrX6XO; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [72.244.190.13] (helo=jlucianilaptop) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FM5Ig-0005Md-Pv; Wed, 22 Mar 2006 10:31:07 -0500 Message-ID: <007f01c64dc2$6e8a7640$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" References: <7D5D48D2CAA3D84C813F5B154F43B155097B9257@nl0006exch001u.nl.lucent.com> <011601c6477f$4768b160$0500a8c0@jlucianilaptop> <01a001c647f1$dbceee60$0500a8c0@jlucianilaptop> <38C461EB-7062-4582-99D7-1B85E6DA4956@cisco.com> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Wed, 22 Mar 2006 10:08:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26547a29a641c5a137cb66818d558045ce5d07c87288fcf778e7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.244.190.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.1 (-) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Hi Tom, I think we have a disconnect somewhere...when I said that the use of the "TC" was not consistent, I meant with TCs in general (not just in GMPLS MIBs), so would prefer to see this removed. I looked at the use of the Textual Conventions in the GMPLS MIBs and saw that one still is the same as an Object (except in case) which was gmplsLabelType. (I do think there was more overlap originally but names have changed since then). My suggestion would be to remove the "TC" suffix from the TCs and change the name of the overlapping gmplsLabelType object to something else (gmplsTypeOfLabel). I do realize this is a style issue, so not a show stopper, only a humble suggestion. Thanks, Joan ----- Original Message ----- From: Thomas D. Nadeau To: Cc: ; Wijnen, Bert (Bert) ; Dan Romascanu (E-mail) ; Adrian Farrel (E-mail) ; Bill Fenner (E-mail) ; Alex Zinin (E-mail) Sent: Tuesday, March 21, 2006 3:19 PM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt > > As per Bert's reply to this, I have made > all of the TCs in the CCAMP/GMPLS TC and LSR MIBs to have > "TC" at the end of their names to keep them consistent. > > --Tom > > > > > > Hi Tom and Adrian, > > > > Due to the updates to the 2 other GMPLS MIB documents > > wanted to re-review this document. > > > > I did have one minor comment which was > > the naming convention used, specifically > > the use of the TC on the end of the names of these > > Textual Conventions. > > > > GmplsFreeformLabelTC > > GmplsLabelTypeTC > > GmplsSegmentDirectionTC > > > > Could this "TC" be removed? Sorry to not catch this > > earlier. > > > > The reason is that this is not consistent with > > other Textual Conventions. > > > > Thanks, > > Joan > > > From owner-ccamp@ops.ietf.org Wed Mar 22 15:02:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9X4-0002ZH-5e for ccamp-archive@ietf.org; Wed, 22 Mar 2006 15:02:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9X3-0007wh-Q0 for ccamp-archive@ietf.org; Wed, 22 Mar 2006 15:02:14 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM9Qe-000Oev-0c for ccamp-data@psg.com; Wed, 22 Mar 2006 19:55:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM9Qd-000Oek-DA for ccamp@ops.ietf.org; Wed, 22 Mar 2006 19:55:35 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2006 11:55:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="24217836:sNHT24475016" Received: from [204.96.114.236] (rtp-vpn2-242.cisco.com [10.82.240.242]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2MJtPWc015911; Wed, 22 Mar 2006 14:55:26 -0500 (EST) In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15509988BB1@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15509988BB1@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89018543-1D0B-4CD3-A3B1-348287C1CAAF@cisco.com> Cc: "" , ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Wed, 22 Mar 2006 13:55:19 -0600 To: "Wijnen, Bert (Bert)" X-Mailer: Apple Mail (2.746.3) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Thanks Bert. I updated accordingly. --Tom On Mar 22, 2006, at 12:25 PM, Wijnen, Bert (Bert) wrote: > Tom, >>> >>> 4) Again, wrt Section 4.8 from RFC4181, it is recommended >>> that if MIB authors intend to have Optional Groups that these >>> be noted. This was done for the Read-only compliance but not >>> the Full-compliance, so would ask that all Optional Groups be >>> specified as recommended by Section 4.8. Reviewing these >>> Compliances statements is difficult without this information. >> >> I don't understand. There are 5 groups, two of which >> are specified as Mandatory, and the other three are explained >> to be optional and why below that. >> > > It seems pretty clear that Joan tries to explain to you that the > proper way to define those optional groups (in BOTH MODULE-COMPLIANCE > statemnts( is to add the optional groups. You do it correctly > for the read-only compliance, but not for the fullCOmpliance. > > So I think the fix is something like: > > OLD: > gmplsTeModuleFullCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Compliance statement for agents that provide full support for > GMPLS-TE-STD-MIB. Such devices can then be monitored and also > be configured using this MIB module. > > The mandatory group has to be implemented by all LSRs that > originate, terminate or act as transit for TE-LSPs/tunnels. > > > Nadeau and Farrel (Editors) > [Page 40] > ^L > Internet Draft draft-ietf-ccamp-gmpls-te-mib-13.txt March > 2006 > > In addition, depending on the type of tunnels supported, > other > groups become mandatory as explained below." > > MODULE -- this module > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelSignaledGroup > } > ::= { gmplsTeCompliances 1 } > > NEW: > > gmplsTeModuleFullCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Compliance statement for agents that provide full support for > GMPLS-TE-STD-MIB. Such devices can then be monitored and also > be configured using this MIB module." > > MODULE -- this module > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelSignaledGroup > } > > GROUP gmplsTunnelSignaledGroup > DESCRIPTION > "This group is mandatory for devices which support signaled > tunnel set up, in addition to gmplsTunnelGroup. The following > constraints apply: > mplsTunnelSignallingProto should be at least read-only > returning a value of ldp(2), or rsvp(3)." > > GROUP gmplsTunnelIsIntfcGroup > DESCRIPTION > "This group is mandatory for devices which support tunnels that > are interfaces, in addition to gmplsTunnelGroup." > > GROUP gmplsTunnelOptionalGroup > DESCRIPTION > "Objects in this group are optional." > > GROUP gmplsTeNotificationGroup > DESCRIPTION > "This group is mandatory for those implementations which can > implement the notifications contained in this group." > > ::= { gmplsTeCompliances 1 } > > Bert From owner-ccamp@ops.ietf.org Wed Mar 22 15:02:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9XD-0002rA-QA for ccamp-archive@ietf.org; Wed, 22 Mar 2006 15:02:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9XD-0007yu-E2 for ccamp-archive@ietf.org; Wed, 22 Mar 2006 15:02:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM9TG-000Oqi-HA for ccamp-data@psg.com; Wed, 22 Mar 2006 19:58:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM9TF-000OqP-QG for ccamp@ops.ietf.org; Wed, 22 Mar 2006 19:58:18 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2006 14:58:08 -0500 X-IronPort-AV: i="4.03,119,1141621200"; d="scan'208"; a="84742266:sNHT39608596" Received: from [204.96.114.236] (rtp-vpn2-242.cisco.com [10.82.240.242]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2MJw5Wc016604; Wed, 22 Mar 2006 14:58:05 -0500 (EST) In-Reply-To: <89018543-1D0B-4CD3-A3B1-348287C1CAAF@cisco.com> References: <7D5D48D2CAA3D84C813F5B154F43B15509988BB1@nl0006exch001u.nl.lucent.com> <89018543-1D0B-4CD3-A3B1-348287C1CAAF@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Wijnen Bert , Cucchiara Joan , ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" , Ross Callon Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Wed, 22 Mar 2006 13:57:58 -0600 To: "Thomas D. Nadeau" X-Mailer: Apple Mail (2.746.3) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Also, we should start CC:ing Ross, who is taking over for Alex as AD. --Tom > > Thanks Bert. I updated accordingly. > > --Tom > > On Mar 22, 2006, at 12:25 PM, Wijnen, Bert (Bert) wrote: > >> Tom, >>>> >>>> 4) Again, wrt Section 4.8 from RFC4181, it is recommended >>>> that if MIB authors intend to have Optional Groups that these >>>> be noted. This was done for the Read-only compliance but not >>>> the Full-compliance, so would ask that all Optional Groups be >>>> specified as recommended by Section 4.8. Reviewing these >>>> Compliances statements is difficult without this information. >>> >>> I don't understand. There are 5 groups, two of which >>> are specified as Mandatory, and the other three are explained >>> to be optional and why below that. >>> >> >> It seems pretty clear that Joan tries to explain to you that the >> proper way to define those optional groups (in BOTH MODULE-COMPLIANCE >> statemnts( is to add the optional groups. You do it correctly >> for the read-only compliance, but not for the fullCOmpliance. >> >> So I think the fix is something like: >> >> OLD: >> gmplsTeModuleFullCompliance MODULE-COMPLIANCE >> STATUS current >> DESCRIPTION >> "Compliance statement for agents that provide full support >> for >> GMPLS-TE-STD-MIB. Such devices can then be monitored and >> also >> be configured using this MIB module. >> >> The mandatory group has to be implemented by all LSRs that >> originate, terminate or act as transit for TE-LSPs/tunnels. >> >> >> Nadeau and Farrel (Editors) >> [Page 40] >> ^L >> Internet Draft draft-ietf-ccamp-gmpls-te-mib-13.txt >> March 2006 >> >> In addition, depending on the type of tunnels supported, >> other >> groups become mandatory as explained below." >> >> MODULE -- this module >> MANDATORY-GROUPS { >> gmplsTunnelGroup, >> gmplsTunnelScalarGroup, >> gmplsTunnelSignaledGroup >> } >> ::= { gmplsTeCompliances 1 } >> >> NEW: >> >> gmplsTeModuleFullCompliance MODULE-COMPLIANCE >> STATUS current >> DESCRIPTION >> "Compliance statement for agents that provide full support >> for >> GMPLS-TE-STD-MIB. Such devices can then be monitored and >> also >> be configured using this MIB module." >> >> MODULE -- this module >> MANDATORY-GROUPS { >> gmplsTunnelGroup, >> gmplsTunnelScalarGroup, >> gmplsTunnelSignaledGroup >> } >> >> GROUP gmplsTunnelSignaledGroup >> DESCRIPTION >> "This group is mandatory for devices which support signaled >> tunnel set up, in addition to gmplsTunnelGroup. The following >> constraints apply: >> mplsTunnelSignallingProto should be at least read-only >> returning a value of ldp(2), or rsvp(3)." >> >> GROUP gmplsTunnelIsIntfcGroup >> DESCRIPTION >> "This group is mandatory for devices which support tunnels >> that >> are interfaces, in addition to gmplsTunnelGroup." >> >> GROUP gmplsTunnelOptionalGroup >> DESCRIPTION >> "Objects in this group are optional." >> >> GROUP gmplsTeNotificationGroup >> DESCRIPTION >> "This group is mandatory for those implementations which can >> implement the notifications contained in this group." >> >> ::= { gmplsTeCompliances 1 } >> >> Bert From owner-ccamp@ops.ietf.org Thu Mar 23 03:40:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMLMo-00019i-3m for ccamp-archive@ietf.org; Thu, 23 Mar 2006 03:40:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMLMj-00075B-J5 for ccamp-archive@ietf.org; Thu, 23 Mar 2006 03:40:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMLCo-0002jz-Hs for ccamp-data@psg.com; Thu, 23 Mar 2006 08:30:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMLCn-0002jQ-J2 for ccamp@ops.ietf.org; Thu, 23 Mar 2006 08:30:05 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FMLCs-0000i2-00 for ccamp@ops.ietf.org; Thu, 23 Mar 2006 08:30:10 +0000 Received: from Puppy ([206.59.254.42] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 08:30:29 +0000 Message-ID: <020c01c64e53$fb2ab510$e2808182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Most slides uploaded Date: Thu, 23 Mar 2006 08:29:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Mar 2006 08:30:29.0765 (UTC) FILETIME=[0B223B50:01C64E54] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 See http://www3.ietf.org/proceedings/06mar/agenda/ccamp.html Adrian From das@yahoo.co.jp Sat Mar 25 10:06:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNALB-0008KE-MF for ccamp-archive@ietf.org; Sat, 25 Mar 2006 10:06:09 -0500 Received: from [218.24.127.214] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FNAL9-00034J-TB for ccamp-archive@ietf.org; Sat, 25 Mar 2006 10:06:09 -0500 To: From: =?iso-2022-jp?B?QVNE?= Subject: =?iso-2022-jp?B?GyRCIXkbKEJaWlpQUFBBQUEbJEIlOiVRISoheRsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea $B%(%m%M%C%H?M:J>pJs:G?79f!Z(BZPA$B![(B http://home.graffiti.net/idtyoshi/ $BLd!K(B xin0@walla.com From owner-ccamp@ops.ietf.org Mon Mar 27 12:28:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNvVq-0000or-Ji for ccamp-archive@ietf.org; Mon, 27 Mar 2006 12:28:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNvVp-0000BM-9K for ccamp-archive@ietf.org; Mon, 27 Mar 2006 12:28:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNvNb-000DbP-Gv for ccamp-data@psg.com; Mon, 27 Mar 2006 17:19:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNvNa-000DbD-N7 for ccamp@ops.ietf.org; Mon, 27 Mar 2006 17:19:46 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2RHJk1Z094772 for ; Mon, 27 Mar 2006 09:19:46 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2RHJk592779 for ; Mon, 27 Mar 2006 09:19:46 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id k2RHJj7v013303 for ; Mon, 27 Mar 2006 09:19:45 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id k2RHJjBi013300 for ; Mon, 27 Mar 2006 09:19:45 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 27 Mar 2006 09:19:45 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Stepping down Message-ID: <20060327091057.U78594@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi All, For those who weren't able to attend the CCAMP WG meeting at IETF 65, I will be stepping down as CCAMP chair as soon as a replacement chair is appointed. Hopefully, this will be in place before the next IETF. Yes, I will remain engaged in GMPLS and CCAMP work, and will contribute as much as I can. Yes, I will be at the next IETF, and future ones as well. It's been a great ride, and it's good to see the resurgent interest in the technology we all helped shape. Thank you all, Kireeti. ------- From owner-ccamp@ops.ietf.org Wed Mar 29 08:37:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOas3-0006Qs-2s for ccamp-archive@ietf.org; Wed, 29 Mar 2006 08:37:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOas2-0004k5-Ip for ccamp-archive@ietf.org; Wed, 29 Mar 2006 08:37:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOaiI-000HtP-Bi for ccamp-data@psg.com; Wed, 29 Mar 2006 13:27:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,FORGED_RCVD_HELO autolearn=no version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOaiG-000HtB-Tk for ccamp@ops.ietf.org; Wed, 29 Mar 2006 13:27:53 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FOaiC-0004gU-00 for ccamp@ops.ietf.org; Wed, 29 Mar 2006 14:27:48 +0100 Received: from Puppy ([217.158.132.128] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 14:28:16 +0100 Message-ID: <014001c65334$94f903b0$6400a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: ERO implementation survey Date: Tue, 28 Mar 2006 20:12:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 29 Mar 2006 13:28:17.0609 (UTC) FILETIME=[A3AD5B90:01C65334] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we determined that implementations must support any form of ERO that is legitimately sent by any other implementation. At the same time there is a desire to reduce the number of options if this is possible. Lastly, there was some confusion about what the RFCs actually allow you to do, and rather than debate this as though we were lawyers, it may be more profitable to look at what current implementations do. Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 go to Draft Standard. To move things forward, I would like to do an informal and *confidential* survey of current implementations. Please respond to each question below with, Yes / No / NA NA would largely apply where the implementation is found on a NE where the technology makes the ERO option inappropriate. Send your responses to me and not to the mailing lists (unless you fancy the publicity). Thanks, Adrian 1. EROs built for use on Path messages For each hop in the path, which of the following options does your implementation utilise? This question applies to EROs that your implementations construct, NOT to EROs that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects 2. EROs received from the previous hop on Path messages Which *top* subobjects in the ERO does your implementation support receiving? This question applies to ERO subobjects that your implementations must handle, NOT to ERO subobjects that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects From owner-ccamp@ops.ietf.org Wed Mar 29 09:36:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObmc-00024M-OX for ccamp-archive@ietf.org; Wed, 29 Mar 2006 09:36:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FObmc-0007Jb-6n for ccamp-archive@ietf.org; Wed, 29 Mar 2006 09:36:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FObdk-000LLT-6b for ccamp-data@psg.com; Wed, 29 Mar 2006 14:27:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FObdi-000LLI-Rv for ccamp@ops.ietf.org; Wed, 29 Mar 2006 14:27:15 +0000 Received: from ib (vpn10.atlanta.movaz.com [172.18.0.10]) by jera.movaz.com (Postfix) with SMTP id 7411D1B510; Wed, 29 Mar 2006 09:24:46 -0500 (EST) Message-ID: <002101c6533c$e03d6160$0900a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , References: <014001c65334$94f903b0$6400a8c0@Puppy> Subject: Re: ERO implementation survey Date: Wed, 29 Mar 2006 09:27:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c See my rsponses below. Igor ----- Original Message ----- From: "Adrian Farrel" To: Sent: Tuesday, March 28, 2006 2:12 PM Subject: ERO implementation survey > In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we > determined that implementations must support any form of ERO that is > legitimately sent by any other implementation. At the same time there is a > desire to reduce the number of options if this is possible. Lastly, there > was some confusion about what the RFCs actually allow you to do, and > rather than debate this as though we were lawyers, it may be more > profitable to look at what current implementations do. > > Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 > go to Draft Standard. > > To move things forward, I would like to do an informal and *confidential* > survey of current implementations. > > Please respond to each question below with, Yes / No / NA > NA would largely apply where the implementation is found on a NE where the > technology makes the ERO option inappropriate. > > Send your responses to me and not to the mailing lists (unless you fancy > the publicity). > > Thanks, > Adrian > > 1. EROs built for use on Path messages > For each hop in the path, which of the following options does your > implementation utilise? > This question applies to EROs that your implementations construct, NOT to > EROs that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes No > > b. AS number No > > c. TE Router ID Yes > > d. Incoming TE link ID No, with the exception of the LSP destination, that is, our implementation has an option to include in the ERO an incoming Te link ID on the destination. > > e. Outgoing TE link ID Yes > > f. Outgoing TE link ID followed by one or two Label subobjects Yes > > g. Outgoing TE link ID followed by Component Interface ID subobject Yes > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects Yes > > i. TE Router ID and Outgoing TE link ID Yes > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects Yes > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject Yes > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects Yes > > m. Incoming TE link ID and Outgoing TE link ID No > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects No > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject No > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects No > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID No > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects No > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject No > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects No > > 2. EROs received from the previous hop on Path messages > Which *top* subobjects in the ERO does your implementation support > receiving? > This question applies to ERO subobjects that your implementations must > handle, NOT to ERO subobjects that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes No (I wonder what does this mean in the TE context? I thought we have agreed that IP Address in the ERO does not necessarily mean routable address, rather, numbered TE links. So, what does it mean numbered TE link Id with non-full prefix length? ) > > b. AS number Yes > > c. TE Router ID Yes > > d. Incoming TE link ID Yes > > e. Outgoing TE link ID Yes > > f. Outgoing TE link ID followed by one or two Label subobjects Yes > > g. Outgoing TE link ID followed by Component Interface ID subobject Yes > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects Yes > > i. TE Router ID and Outgoing TE link ID Yes > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects Yes > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject Yes > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects Yes > > m. Incoming TE link ID and Outgoing TE link ID Yes > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects Yes > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject Yes > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects Yes > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID Yes > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects Yes > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject Yes > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects Yes > > From owner-ccamp@ops.ietf.org Thu Mar 30 02:42:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOrng-0007Ox-Ds for ccamp-archive@ietf.org; Thu, 30 Mar 2006 02:42:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOrnc-0004wE-Rx for ccamp-archive@ietf.org; Thu, 30 Mar 2006 02:42:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOrfg-000PrH-Af for ccamp-data@psg.com; Thu, 30 Mar 2006 07:34:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOrfb-000Pqv-Ck for ccamp@ops.ietf.org; Thu, 30 Mar 2006 07:34:15 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11/8.12.11) with ESMTP id k2U7XmAu026511; Thu, 30 Mar 2006 08:34:11 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: Re: ERO implementation survey To: "Adrian Farrel" Cc: " X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Thu, 30 Mar 2006 09:34:00 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 30/03/2006 08:34:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Hi Adrian, just a clarification, TE Router ID and Outgoing TE link ID means that the TE Link is unnumbered? Regards Diego "Adrian Farrel" @ops.ietf.org on 28/03/2006 21.12.04 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: ERO implementation survey In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we determined that implementations must support any form of ERO that is legitimately sent by any other implementation. At the same time there is a desire to reduce the number of options if this is possible. Lastly, there was some confusion about what the RFCs actually allow you to do, and rather than debate this as though we were lawyers, it may be more profitable to look at what current implementations do. Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 go to Draft Standard. To move things forward, I would like to do an informal and *confidential* survey of current implementations. Please respond to each question below with, Yes / No / NA NA would largely apply where the implementation is found on a NE where the technology makes the ERO option inappropriate. Send your responses to me and not to the mailing lists (unless you fancy the publicity). Thanks, Adrian 1. EROs built for use on Path messages For each hop in the path, which of the following options does your implementation utilise? This question applies to EROs that your implementations construct, NOT to EROs that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects 2. EROs received from the previous hop on Path messages Which *top* subobjects in the ERO does your implementation support receiving? This question applies to ERO subobjects that your implementations must handle, NOT to ERO subobjects that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects From owner-ccamp@ops.ietf.org Thu Mar 30 04:25:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtPO-0002NS-6y for ccamp-archive@ietf.org; Thu, 30 Mar 2006 04:25:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtPN-0001bq-Fu for ccamp-archive@ietf.org; Thu, 30 Mar 2006 04:25:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOtJ9-0006Xa-VN for ccamp-data@psg.com; Thu, 30 Mar 2006 09:19:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOtJ8-0006XG-5U for ccamp@ops.ietf.org; Thu, 30 Mar 2006 09:19:10 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FOtJ4-0000CM-00 for ccamp@ops.ietf.org; Thu, 30 Mar 2006 10:19:06 +0100 Received: from Puppy ([217.158.132.204] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 10:19:34 +0100 Message-ID: <01d701c653db$00ea34d0$6400a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" Cc: " References: Subject: Re: ERO implementation survey Date: Thu, 30 Mar 2006 10:18:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 30 Mar 2006 09:19:34.0968 (UTC) FILETIME=[0F80CB80:01C653DB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Diego, Not my intention to imply this. TE link ID (incoming or outgoing) means the identifier (numbered or unnumbered) of the TE link. TE Router ID means the identifier of the node. Thanks, Adrian ----- Original Message ----- From: "Diego Caviglia" To: "Adrian Farrel" Cc: " Sent: Thursday, March 30, 2006 8:34 AM Subject: Re: ERO implementation survey > > Hi Adrian, > just a clarification, TE Router ID and Outgoing TE link ID means > that the TE Link is unnumbered? > > Regards > > Diego > > > > "Adrian Farrel" @ops.ietf.org on 28/03/2006 21.12.04 > > Please respond to "Adrian Farrel" > > Sent by: owner-ccamp@ops.ietf.org > > > To: > cc: > > Subject: ERO implementation survey > > In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we > determined that implementations must support any form of ERO that is > legitimately sent by any other implementation. At the same time there is a > desire to reduce the number of options if this is possible. Lastly, there > was some confusion about what the RFCs actually allow you to do, and > rather than debate this as though we were lawyers, it may be more > profitable to look at what current implementations do. > > Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 > go to Draft Standard. > > To move things forward, I would like to do an informal and *confidential* > survey of current implementations. > > Please respond to each question below with, Yes / No / NA > NA would largely apply where the implementation is found on a NE where the > technology makes the ERO option inappropriate. > > Send your responses to me and not to the mailing lists (unless you fancy > the publicity). > > Thanks, > Adrian > > 1. EROs built for use on Path messages > For each hop in the path, which of the following options does your > implementation utilise? > This question applies to EROs that your implementations construct, NOT to > EROs that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes > > b. AS number > > c. TE Router ID > > d. Incoming TE link ID > > e. Outgoing TE link ID > > f. Outgoing TE link ID followed by one or two Label subobjects > > g. Outgoing TE link ID followed by Component Interface ID subobject > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects > > i. TE Router ID and Outgoing TE link ID > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > m. Incoming TE link ID and Outgoing TE link ID > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects > > 2. EROs received from the previous hop on Path messages > Which *top* subobjects in the ERO does your implementation support > receiving? > This question applies to ERO subobjects that your implementations must > handle, NOT to ERO subobjects that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes > > b. AS number > > c. TE Router ID > > d. Incoming TE link ID > > e. Outgoing TE link ID > > f. Outgoing TE link ID followed by one or two Label subobjects > > g. Outgoing TE link ID followed by Component Interface ID subobject > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects > > i. TE Router ID and Outgoing TE link ID > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > m. Incoming TE link ID and Outgoing TE link ID > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects > > > > > > > > > From das@yahoo.co.jp Fri Mar 31 02:23:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPDyn-0003wE-Fv for ccamp-archive@ietf.org; Fri, 31 Mar 2006 02:23:33 -0500 Received: from [218.24.126.156] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FPDqi-0000hh-1x for ccamp-archive@ietf.org; Fri, 31 Mar 2006 02:15:16 -0500 To: From: =?iso-2022-jp?B?QVNE?= Subject: =?iso-2022-jp?B?KC9sbGxsbGwbJEIhLSImGyhCKRskQiQzJHMkSyRBJE8bKEIoL2xsbGxsbBskQiEtIiYbKEIp?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea $B:y$N2V$HNx$N3+2V>pJs(B http://zailing.com/too/ $BLd!K(B fafafa163com@163.com From owner-ccamp@ops.ietf.org Fri Mar 31 13:05:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPNzl-0007c9-NM for ccamp-archive@ietf.org; Fri, 31 Mar 2006 13:05:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPNzk-0006c4-FZ for ccamp-archive@ietf.org; Fri, 31 Mar 2006 13:05:13 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPNtD-000GBR-Bq for ccamp-data@psg.com; Fri, 31 Mar 2006 17:58:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPNtC-000GBG-PR for ccamp@ops.ietf.org; Fri, 31 Mar 2006 17:58:26 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2VHwQ1Z049052 for ; Fri, 31 Mar 2006 09:58:26 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2VHwQ585951 for ; Fri, 31 Mar 2006 09:58:26 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id k2VHwP7v031742 for ; Fri, 31 Mar 2006 09:58:25 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id k2VHwPUm031739 for ; Fri, 31 Mar 2006 09:58:25 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 31 Mar 2006 09:58:25 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: hierarchy bis Message-ID: <20060331095306.T31698@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hi All, There was excellent support at the last IETF for the hierarchy bis document going to WG doc. In order to better capture the intent of this document, the authors and chairs have settled on "Procedures for Dynamically Signaled Hierarchical Label Switched Paths" as the new title. Editors: please republish draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt as a WG doc with the new title. Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Mar 31 13:17:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOBv-0005Gg-O5 for ccamp-archive@ietf.org; Fri, 31 Mar 2006 13:17:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPOBu-0007dt-Fy for ccamp-archive@ietf.org; Fri, 31 Mar 2006 13:17:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPO6r-000H77-7E for ccamp-data@psg.com; Fri, 31 Mar 2006 18:12:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPO6q-000H6s-P3 for ccamp@ops.ietf.org; Fri, 31 Mar 2006 18:12:32 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2VICW1Z049124 for ; Fri, 31 Mar 2006 10:12:32 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2VICW588753 for ; Fri, 31 Mar 2006 10:12:32 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id k2VICW7v031924 for ; Fri, 31 Mar 2006 10:12:32 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id k2VICVfs031921 for ; Fri, 31 Mar 2006 10:12:31 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 31 Mar 2006 10:12:31 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Progressing docs Message-ID: <20060331100203.G31807@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi All, This is to double-check support *on the list* for the following I-Ds to go to WG docs: a) MPLS-GMPLS interworking draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt b) "hierarchy bis" draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt c) Call Support draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt d) Ethernet TSpec draft-dimitri-mef-ethernet-traffic-parameters-00.txt e) OSPF-TE MIB draft-otani-ccamp-gmpls-ospf-mib-02.txt Please say for each if you think it should/should not become a WG doc. My previous email was in error: the "excellent" support was for the migration doc. Just to be clear, we'll double-check all these docs. Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Mar 31 14:08:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOz7-0006QN-EM for ccamp-archive@ietf.org; Fri, 31 Mar 2006 14:08:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPOz3-0000B6-4E for ccamp-archive@ietf.org; Fri, 31 Mar 2006 14:08:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPOui-000Jxt-Vo for ccamp-data@psg.com; Fri, 31 Mar 2006 19:04:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPOug-000Jxe-99 for ccamp@ops.ietf.org; Fri, 31 Mar 2006 19:04:02 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA09466; Fri, 31 Mar 2006 13:04:01 -0600 (CST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2VJ40T24109; Fri, 31 Mar 2006 11:04:00 -0800 (PST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 31 Mar 2006 11:03:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Progressing docs Date: Fri, 31 Mar 2006 11:03:18 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2D849@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing docs Thread-Index: AcZU9HDJja4HL3eITFiMFmmdYwSd/AAASynA From: "Drake, John E" To: "Kireeti Kompella" , X-OriginalArrivalTime: 31 Mar 2006 19:03:18.0670 (UTC) FILETIME=[C5AB5AE0:01C654F5] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, March 31, 2006 10:13 AM > To: ccamp@ops.ietf.org > Subject: Progressing docs >=20 > Hi All, >=20 > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: >=20 > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt Yes > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt No > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt Yes > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt Yes, but turf it to L1VPN > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt Yes >=20 > Please say for each if you think it should/should not become a WG doc. >=20 > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. >=20 > Kireeti. > ------- From owner-ccamp@ops.ietf.org Fri Mar 31 17:04:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRiv-00086b-Hr for ccamp-archive@ietf.org; Fri, 31 Mar 2006 17:04:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRiu-0000Ob-8y for ccamp-archive@ietf.org; Fri, 31 Mar 2006 17:04:05 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPRTq-0003WB-9r for ccamp-data@psg.com; Fri, 31 Mar 2006 21:48:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [216.82.250.99] (helo=mail126.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPRTp-0003Vz-AK for ccamp@ops.ietf.org; Fri, 31 Mar 2006 21:48:29 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-8.tower-126.messagelabs.com!1143841707!10680481!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 32093 invoked from network); 31 Mar 2006 21:48:27 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-126.messagelabs.com with SMTP; 31 Mar 2006 21:48:27 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE000DC558; Fri, 31 Mar 2006 16:48:26 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Progressing docs Date: Fri, 31 Mar 2006 15:47:33 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0BD3EC0C@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <20060331100203.G31807@kummer.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing docs Thread-Index: AcZU7srP7AXMBIK0RI2AyHtK90auYgAHTvsg From: "Brungard, Deborah A, ALABS" To: "Kireeti Kompella" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d (below)=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella Sent: Friday, March 31, 2006 1:13 PM To: ccamp@ops.ietf.org Subject: Progressing docs Hi All, This is to double-check support *on the list* for the following I-Ds=20 to go to WG docs: a) MPLS-GMPLS interworking draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt Yes b) "hierarchy bis" draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Abstain c) Call Support draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt Yes d) Ethernet TSpec draft-dimitri-mef-ethernet-traffic-parameters-00.txt Yes e) OSPF-TE MIB draft-otani-ccamp-gmpls-ospf-mib-02.txt Abstain Please say for each if you think it should/should not become a WG doc. My previous email was in error: the "excellent" support was for the=20 migration doc. Just to be clear, we'll double-check all these docs. Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Mar 31 19:33:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPU37-0006gG-32 for ccamp-archive@ietf.org; Fri, 31 Mar 2006 19:33:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPU35-0000c3-Px for ccamp-archive@ietf.org; Fri, 31 Mar 2006 19:33:05 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPTyD-0009q9-FV for ccamp-data@psg.com; Sat, 01 Apr 2006 00:28:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-16.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, USER_IN_DEF_WHITELIST autolearn=no version=3.1.1 Received: from [128.9.160.116] (helo=nit.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPTyD-0009px-0o for ccamp@ops.ietf.org; Sat, 01 Apr 2006 00:28:01 +0000 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k310RwHo030637; Fri, 31 Mar 2006 16:27:58 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k310Rw5b030636; Fri, 31 Mar 2006 16:27:58 -0800 Date: Fri, 31 Mar 2006 16:27:58 -0800 Message-Id: <200604010027.k310Rw5b030636@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4427 on Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 A new Request for Comments is now available in online RFC libraries. RFC 4427 Title: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Author: E. Mannie, Ed., D. Papadimitriou, Ed. Status: Informational Date: March 2006 Mailbox: eric.mannie@perceval.net, dimitri.papadimitriou@alcatel.be Pages: 22 Characters: 43842 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-recovery-terminology-06.txt URL: http://www.rfc-editor.org/rfc/rfc4427.txt This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG 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 RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... From owner-ccamp@ops.ietf.org Fri Mar 31 19:33:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPU38-0006gm-UY for ccamp-archive@ietf.org; Fri, 31 Mar 2006 19:33:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPU38-0000cE-LW for ccamp-archive@ietf.org; Fri, 31 Mar 2006 19:33:06 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPTyT-0009r4-Py for ccamp-data@psg.com; Sat, 01 Apr 2006 00:28:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-16.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, USER_IN_DEF_WHITELIST autolearn=no version=3.1.1 Received: from [128.9.160.116] (helo=nit.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPTyT-0009qs-Ay for ccamp@ops.ietf.org; Sat, 01 Apr 2006 00:28:17 +0000 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k310SFf0030642; Fri, 31 Mar 2006 16:28:15 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k310SFsc030641; Fri, 31 Mar 2006 16:28:15 -0800 Date: Fri, 31 Mar 2006 16:28:15 -0800 Message-Id: <200604010028.k310SFsc030641@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4428 on Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 A new Request for Comments is now available in online RFC libraries. RFC 4428 Title: Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Author: D. Papadimitriou, Ed., E. Mannie, Ed. Status: Informational Date: March 2006 Mailbox: dimitri.papadimitriou@alcatel.be, eric.mannie@perceval.net Pages: 47 Characters: 118749 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-recovery-analysis-05.txt URL: http://www.rfc-editor.org/rfc/rfc4428.txt This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. This memo provides information for the Internet community. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG 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 RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... From owner-ccamp@ops.ietf.org Fri Mar 31 19:33:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPU3B-0006jQ-OZ for ccamp-archive@ietf.org; Fri, 31 Mar 2006 19:33:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPU3B-0000cI-FM for ccamp-archive@ietf.org; Fri, 31 Mar 2006 19:33:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPTy1-0009p9-1p for ccamp-data@psg.com; Sat, 01 Apr 2006 00:27:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-16.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, USER_IN_DEF_WHITELIST autolearn=no version=3.1.1 Received: from [128.9.160.116] (helo=nit.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPTy0-0009oi-Hu for ccamp@ops.ietf.org; Sat, 01 Apr 2006 00:27:48 +0000 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k310RkB7030631; Fri, 31 Mar 2006 16:27:46 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k310RkPL030630; Fri, 31 Mar 2006 16:27:46 -0800 Date: Fri, 31 Mar 2006 16:27:46 -0800 Message-Id: <200604010027.k310RkPL030630@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4426 on Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d A new Request for Comments is now available in online RFC libraries. RFC 4426 Title: Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Author: J. Lang, Ed., B. Rajagopalan, Ed., D. Papadimitriou, Ed. Status: Standards Track Date: March 2006 Mailbox: jplang@ieee.org, balar@microsoft.com, dimitri.papadimitriou@alcatel.be Pages: 23 Characters: 55820 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-recovery-functional-04.txt URL: http://www.rfc-editor.org/rfc/rfc4426.txt This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [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 IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG 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 RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... From owner-ccamp@ops.ietf.org Fri Mar 31 22:06:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWR8-0003B8-BF for ccamp-archive@ietf.org; Fri, 31 Mar 2006 22:06:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPWR6-0006jf-Pw for ccamp-archive@ietf.org; Fri, 31 Mar 2006 22:06:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPWI0-000IdP-J3 for ccamp-data@psg.com; Sat, 01 Apr 2006 02:56:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPWHz-000IdE-Sj for ccamp@ops.ietf.org; Sat, 01 Apr 2006 02:56:35 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.6/8.13.6) with ESMTP id k312uWd1005732; Fri, 31 Mar 2006 18:56:32 -0800 (PST) Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu0.fujitsu.com (8.13.6/8.13.6) with ESMTP id k312uWGO005729; Fri, 31 Mar 2006 18:56:32 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.5/8.13.5) with ESMTP id k312uWdn027391; Fri, 31 Mar 2006 18:56:32 -0800 (PST) Received: from [133.164.16.21] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k312uVO09106; Fri, 31 Mar 2006 18:56:31 -0800 (PST) Message-ID: <442DEBE3.5010207@us.fujitsu.com> Date: Fri, 31 Mar 2006 21:56:35 -0500 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Progressing docs References: <20060331100203.G31807@kummer.juniper.net> In-Reply-To: <20060331100203.G31807@kummer.juniper.net> Content-Type: multipart/mixed; boundary="------------040706060407060407040909" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. --------------040706060407060407040909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kireeti, yes to all Kireeti Kompella wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > --------------040706060407060407040909 Content-Type: text/x-vcard; charset=utf-8; name="richard.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="richard.vcf" begin:vcard fn:Richard Rabbat n:Rabbat;Richard org:Fujitsu adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA email;internet:richard@us.fujitsu.com title:Senior Project Manager tel;work:1-408-530-4537 tel;fax:1-408-530-4515 tel;cell:1-650-714-7618 x-mozilla-html:TRUE version:2.1 end:vcard --------------040706060407060407040909-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Mar 2006 21:49:45 +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: Progressing docs Date: Fri, 31 Mar 2006 15:47:33 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0BD3EC0C@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Progressing docs Thread-Index: AcZU7srP7AXMBIK0RI2AyHtK90auYgAHTvsg From: "Brungard, Deborah A, ALABS" To: "Kireeti Kompella" , (below)=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella Sent: Friday, March 31, 2006 1:13 PM To: ccamp@ops.ietf.org Subject: Progressing docs Hi All, This is to double-check support *on the list* for the following I-Ds=20 to go to WG docs: a) MPLS-GMPLS interworking draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt Yes b) "hierarchy bis" draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Abstain c) Call Support draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt Yes d) Ethernet TSpec draft-dimitri-mef-ethernet-traffic-parameters-00.txt Yes e) OSPF-TE MIB draft-otani-ccamp-gmpls-ospf-mib-02.txt Abstain Please say for each if you think it should/should not become a WG doc. My previous email was in error: the "excellent" support was for the=20 migration doc. Just to be clear, we'll double-check all these docs. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Mar 2006 19:04:53 +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: Progressing docs Date: Fri, 31 Mar 2006 11:03:18 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2D849@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Progressing docs Thread-Index: AcZU9HDJja4HL3eITFiMFmmdYwSd/AAASynA From: "Drake, John E" To: "Kireeti Kompella" , > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, March 31, 2006 10:13 AM > To: ccamp@ops.ietf.org > Subject: Progressing docs >=20 > Hi All, >=20 > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: >=20 > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt Yes > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt No > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt Yes > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt Yes, but turf it to L1VPN > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt Yes >=20 > Please say for each if you think it should/should not become a WG doc. >=20 > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. >=20 > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Mar 2006 18:13:02 +0000 Date: Fri, 31 Mar 2006 10:12:31 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Progressing docs Message-ID: <20060331100203.G31807@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi All, This is to double-check support *on the list* for the following I-Ds to go to WG docs: a) MPLS-GMPLS interworking draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt b) "hierarchy bis" draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt c) Call Support draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt d) Ethernet TSpec draft-dimitri-mef-ethernet-traffic-parameters-00.txt e) OSPF-TE MIB draft-otani-ccamp-gmpls-ospf-mib-02.txt Please say for each if you think it should/should not become a WG doc. My previous email was in error: the "excellent" support was for the migration doc. Just to be clear, we'll double-check all these docs. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Mar 2006 18:00:31 +0000 Date: Fri, 31 Mar 2006 09:58:25 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: hierarchy bis Message-ID: <20060331095306.T31698@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi All, There was excellent support at the last IETF for the hierarchy bis document going to WG doc. In order to better capture the intent of this document, the authors and chairs have settled on "Procedures for Dynamically Signaled Hierarchical Label Switched Paths" as the new title. Editors: please republish draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt as a WG doc with the new title. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 Mar 2006 09:19:48 +0000 Message-ID: <01d701c653db$00ea34d0$6400a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" Cc: " Subject: Re: ERO implementation survey Date: Thu, 30 Mar 2006 10:18:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Diego, Not my intention to imply this. TE link ID (incoming or outgoing) means the identifier (numbered or unnumbered) of the TE link. TE Router ID means the identifier of the node. Thanks, Adrian ----- Original Message ----- From: "Diego Caviglia" To: "Adrian Farrel" Cc: " Sent: Thursday, March 30, 2006 8:34 AM Subject: Re: ERO implementation survey > > Hi Adrian, > just a clarification, TE Router ID and Outgoing TE link ID means > that the TE Link is unnumbered? > > Regards > > Diego > > > > "Adrian Farrel" @ops.ietf.org on 28/03/2006 21.12.04 > > Please respond to "Adrian Farrel" > > Sent by: owner-ccamp@ops.ietf.org > > > To: > cc: > > Subject: ERO implementation survey > > In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we > determined that implementations must support any form of ERO that is > legitimately sent by any other implementation. At the same time there is a > desire to reduce the number of options if this is possible. Lastly, there > was some confusion about what the RFCs actually allow you to do, and > rather than debate this as though we were lawyers, it may be more > profitable to look at what current implementations do. > > Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 > go to Draft Standard. > > To move things forward, I would like to do an informal and *confidential* > survey of current implementations. > > Please respond to each question below with, Yes / No / NA > NA would largely apply where the implementation is found on a NE where the > technology makes the ERO option inappropriate. > > Send your responses to me and not to the mailing lists (unless you fancy > the publicity). > > Thanks, > Adrian > > 1. EROs built for use on Path messages > For each hop in the path, which of the following options does your > implementation utilise? > This question applies to EROs that your implementations construct, NOT to > EROs that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes > > b. AS number > > c. TE Router ID > > d. Incoming TE link ID > > e. Outgoing TE link ID > > f. Outgoing TE link ID followed by one or two Label subobjects > > g. Outgoing TE link ID followed by Component Interface ID subobject > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects > > i. TE Router ID and Outgoing TE link ID > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > m. Incoming TE link ID and Outgoing TE link ID > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects > > 2. EROs received from the previous hop on Path messages > Which *top* subobjects in the ERO does your implementation support > receiving? > This question applies to ERO subobjects that your implementations must > handle, NOT to ERO subobjects that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes > > b. AS number > > c. TE Router ID > > d. Incoming TE link ID > > e. Outgoing TE link ID > > f. Outgoing TE link ID followed by one or two Label subobjects > > g. Outgoing TE link ID followed by Component Interface ID subobject > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects > > i. TE Router ID and Outgoing TE link ID > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > m. Incoming TE link ID and Outgoing TE link ID > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 Mar 2006 07:35:46 +0000 Sensitivity: Subject: Re: ERO implementation survey To: "Adrian Farrel" Cc: " Message-ID: From: "Diego Caviglia" Date: Thu, 30 Mar 2006 09:34:00 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Adrian, just a clarification, TE Router ID and Outgoing TE link ID means that the TE Link is unnumbered? Regards Diego "Adrian Farrel" @ops.ietf.org on 28/03/2006 21.12.04 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: ERO implementation survey In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we determined that implementations must support any form of ERO that is legitimately sent by any other implementation. At the same time there is a desire to reduce the number of options if this is possible. Lastly, there was some confusion about what the RFCs actually allow you to do, and rather than debate this as though we were lawyers, it may be more profitable to look at what current implementations do. Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 go to Draft Standard. To move things forward, I would like to do an informal and *confidential* survey of current implementations. Please respond to each question below with, Yes / No / NA NA would largely apply where the implementation is found on a NE where the technology makes the ERO option inappropriate. Send your responses to me and not to the mailing lists (unless you fancy the publicity). Thanks, Adrian 1. EROs built for use on Path messages For each hop in the path, which of the following options does your implementation utilise? This question applies to EROs that your implementations construct, NOT to EROs that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects 2. EROs received from the previous hop on Path messages Which *top* subobjects in the ERO does your implementation support receiving? This question applies to ERO subobjects that your implementations must handle, NOT to ERO subobjects that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Mar 2006 14:27:40 +0000 Message-ID: <002101c6533c$e03d6160$0900a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , Subject: Re: ERO implementation survey Date: Wed, 29 Mar 2006 09:27:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See my rsponses below. Igor ----- Original Message ----- From: "Adrian Farrel" To: Sent: Tuesday, March 28, 2006 2:12 PM Subject: ERO implementation survey > In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we > determined that implementations must support any form of ERO that is > legitimately sent by any other implementation. At the same time there is a > desire to reduce the number of options if this is possible. Lastly, there > was some confusion about what the RFCs actually allow you to do, and > rather than debate this as though we were lawyers, it may be more > profitable to look at what current implementations do. > > Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 > go to Draft Standard. > > To move things forward, I would like to do an informal and *confidential* > survey of current implementations. > > Please respond to each question below with, Yes / No / NA > NA would largely apply where the implementation is found on a NE where the > technology makes the ERO option inappropriate. > > Send your responses to me and not to the mailing lists (unless you fancy > the publicity). > > Thanks, > Adrian > > 1. EROs built for use on Path messages > For each hop in the path, which of the following options does your > implementation utilise? > This question applies to EROs that your implementations construct, NOT to > EROs that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes No > > b. AS number No > > c. TE Router ID Yes > > d. Incoming TE link ID No, with the exception of the LSP destination, that is, our implementation has an option to include in the ERO an incoming Te link ID on the destination. > > e. Outgoing TE link ID Yes > > f. Outgoing TE link ID followed by one or two Label subobjects Yes > > g. Outgoing TE link ID followed by Component Interface ID subobject Yes > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects Yes > > i. TE Router ID and Outgoing TE link ID Yes > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects Yes > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject Yes > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects Yes > > m. Incoming TE link ID and Outgoing TE link ID No > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects No > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject No > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects No > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID No > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects No > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject No > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects No > > 2. EROs received from the previous hop on Path messages > Which *top* subobjects in the ERO does your implementation support > receiving? > This question applies to ERO subobjects that your implementations must > handle, NOT to ERO subobjects that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes No (I wonder what does this mean in the TE context? I thought we have agreed that IP Address in the ERO does not necessarily mean routable address, rather, numbered TE links. So, what does it mean numbered TE link Id with non-full prefix length? ) > > b. AS number Yes > > c. TE Router ID Yes > > d. Incoming TE link ID Yes > > e. Outgoing TE link ID Yes > > f. Outgoing TE link ID followed by one or two Label subobjects Yes > > g. Outgoing TE link ID followed by Component Interface ID subobject Yes > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects Yes > > i. TE Router ID and Outgoing TE link ID Yes > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects Yes > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject Yes > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects Yes > > m. Incoming TE link ID and Outgoing TE link ID Yes > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects Yes > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject Yes > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects Yes > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID Yes > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects Yes > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject Yes > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects Yes > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Mar 2006 13:29:45 +0000 Message-ID: <014001c65334$94f903b0$6400a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: ERO implementation survey Date: Tue, 28 Mar 2006 20:12:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we determined that implementations must support any form of ERO that is legitimately sent by any other implementation. At the same time there is a desire to reduce the number of options if this is possible. Lastly, there was some confusion about what the RFCs actually allow you to do, and rather than debate this as though we were lawyers, it may be more profitable to look at what current implementations do. Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 go to Draft Standard. To move things forward, I would like to do an informal and *confidential* survey of current implementations. Please respond to each question below with, Yes / No / NA NA would largely apply where the implementation is found on a NE where the technology makes the ERO option inappropriate. Send your responses to me and not to the mailing lists (unless you fancy the publicity). Thanks, Adrian 1. EROs built for use on Path messages For each hop in the path, which of the following options does your implementation utilise? This question applies to EROs that your implementations construct, NOT to EROs that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects 2. EROs received from the previous hop on Path messages Which *top* subobjects in the ERO does your implementation support receiving? This question applies to ERO subobjects that your implementations must handle, NOT to ERO subobjects that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Mar 2006 17:22:24 +0000 Date: Mon, 27 Mar 2006 09:19:45 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Stepping down Message-ID: <20060327091057.U78594@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi All, For those who weren't able to attend the CCAMP WG meeting at IETF 65, I will be stepping down as CCAMP chair as soon as a replacement chair is appointed. Hopefully, this will be in place before the next IETF. Yes, I will remain engaged in GMPLS and CCAMP work, and will contribute as much as I can. Yes, I will be at the next IETF, and future ones as well. It's been a great ride, and it's good to see the resurgent interest in the technology we all helped shape. Thank you all, Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Mar 2006 08:32:18 +0000 Message-ID: <020c01c64e53$fb2ab510$e2808182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Most slides uploaded Date: Thu, 23 Mar 2006 08:29:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See http://www3.ietf.org/proceedings/06mar/agenda/ccamp.html Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Mar 2006 19:58:22 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Wijnen Bert , Cucchiara Joan , ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" , Ross Callon Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Wed, 22 Mar 2006 13:57:58 -0600 To: "Thomas D. Nadeau" Also, we should start CC:ing Ross, who is taking over for Alex as AD. --Tom > > Thanks Bert. I updated accordingly. > > --Tom > > On Mar 22, 2006, at 12:25 PM, Wijnen, Bert (Bert) wrote: > >> Tom, >>>> >>>> 4) Again, wrt Section 4.8 from RFC4181, it is recommended >>>> that if MIB authors intend to have Optional Groups that these >>>> be noted. This was done for the Read-only compliance but not >>>> the Full-compliance, so would ask that all Optional Groups be >>>> specified as recommended by Section 4.8. Reviewing these >>>> Compliances statements is difficult without this information. >>> >>> I don't understand. There are 5 groups, two of which >>> are specified as Mandatory, and the other three are explained >>> to be optional and why below that. >>> >> >> It seems pretty clear that Joan tries to explain to you that the >> proper way to define those optional groups (in BOTH MODULE-COMPLIANCE >> statemnts( is to add the optional groups. You do it correctly >> for the read-only compliance, but not for the fullCOmpliance. >> >> So I think the fix is something like: >> >> OLD: >> gmplsTeModuleFullCompliance MODULE-COMPLIANCE >> STATUS current >> DESCRIPTION >> "Compliance statement for agents that provide full support >> for >> GMPLS-TE-STD-MIB. Such devices can then be monitored and >> also >> be configured using this MIB module. >> >> The mandatory group has to be implemented by all LSRs that >> originate, terminate or act as transit for TE-LSPs/tunnels. >> >> >> Nadeau and Farrel (Editors) >> [Page 40] >> ^L >> Internet Draft draft-ietf-ccamp-gmpls-te-mib-13.txt >> March 2006 >> >> In addition, depending on the type of tunnels supported, >> other >> groups become mandatory as explained below." >> >> MODULE -- this module >> MANDATORY-GROUPS { >> gmplsTunnelGroup, >> gmplsTunnelScalarGroup, >> gmplsTunnelSignaledGroup >> } >> ::= { gmplsTeCompliances 1 } >> >> NEW: >> >> gmplsTeModuleFullCompliance MODULE-COMPLIANCE >> STATUS current >> DESCRIPTION >> "Compliance statement for agents that provide full support >> for >> GMPLS-TE-STD-MIB. Such devices can then be monitored and >> also >> be configured using this MIB module." >> >> MODULE -- this module >> MANDATORY-GROUPS { >> gmplsTunnelGroup, >> gmplsTunnelScalarGroup, >> gmplsTunnelSignaledGroup >> } >> >> GROUP gmplsTunnelSignaledGroup >> DESCRIPTION >> "This group is mandatory for devices which support signaled >> tunnel set up, in addition to gmplsTunnelGroup. The following >> constraints apply: >> mplsTunnelSignallingProto should be at least read-only >> returning a value of ldp(2), or rsvp(3)." >> >> GROUP gmplsTunnelIsIntfcGroup >> DESCRIPTION >> "This group is mandatory for devices which support tunnels >> that >> are interfaces, in addition to gmplsTunnelGroup." >> >> GROUP gmplsTunnelOptionalGroup >> DESCRIPTION >> "Objects in this group are optional." >> >> GROUP gmplsTeNotificationGroup >> DESCRIPTION >> "This group is mandatory for those implementations which can >> implement the notifications contained in this group." >> >> ::= { gmplsTeCompliances 1 } >> >> Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Mar 2006 19:56:29 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89018543-1D0B-4CD3-A3B1-348287C1CAAF@cisco.com> Cc: "" , ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Wed, 22 Mar 2006 13:55:19 -0600 To: "Wijnen, Bert (Bert)" Thanks Bert. I updated accordingly. --Tom On Mar 22, 2006, at 12:25 PM, Wijnen, Bert (Bert) wrote: > Tom, >>> >>> 4) Again, wrt Section 4.8 from RFC4181, it is recommended >>> that if MIB authors intend to have Optional Groups that these >>> be noted. This was done for the Read-only compliance but not >>> the Full-compliance, so would ask that all Optional Groups be >>> specified as recommended by Section 4.8. Reviewing these >>> Compliances statements is difficult without this information. >> >> I don't understand. There are 5 groups, two of which >> are specified as Mandatory, and the other three are explained >> to be optional and why below that. >> > > It seems pretty clear that Joan tries to explain to you that the > proper way to define those optional groups (in BOTH MODULE-COMPLIANCE > statemnts( is to add the optional groups. You do it correctly > for the read-only compliance, but not for the fullCOmpliance. > > So I think the fix is something like: > > OLD: > gmplsTeModuleFullCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Compliance statement for agents that provide full support for > GMPLS-TE-STD-MIB. Such devices can then be monitored and also > be configured using this MIB module. > > The mandatory group has to be implemented by all LSRs that > originate, terminate or act as transit for TE-LSPs/tunnels. > > > Nadeau and Farrel (Editors) > [Page 40] > ^L > Internet Draft draft-ietf-ccamp-gmpls-te-mib-13.txt March > 2006 > > In addition, depending on the type of tunnels supported, > other > groups become mandatory as explained below." > > MODULE -- this module > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelSignaledGroup > } > ::= { gmplsTeCompliances 1 } > > NEW: > > gmplsTeModuleFullCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Compliance statement for agents that provide full support for > GMPLS-TE-STD-MIB. Such devices can then be monitored and also > be configured using this MIB module." > > MODULE -- this module > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelSignaledGroup > } > > GROUP gmplsTunnelSignaledGroup > DESCRIPTION > "This group is mandatory for devices which support signaled > tunnel set up, in addition to gmplsTunnelGroup. The following > constraints apply: > mplsTunnelSignallingProto should be at least read-only > returning a value of ldp(2), or rsvp(3)." > > GROUP gmplsTunnelIsIntfcGroup > DESCRIPTION > "This group is mandatory for devices which support tunnels that > are interfaces, in addition to gmplsTunnelGroup." > > GROUP gmplsTunnelOptionalGroup > DESCRIPTION > "Objects in this group are optional." > > GROUP gmplsTeNotificationGroup > DESCRIPTION > "This group is mandatory for those implementations which can > implement the notifications contained in this group." > > ::= { gmplsTeCompliances 1 } > > Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Mar 2006 18:27:11 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509988BB1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , "" Cc: ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Wed, 22 Mar 2006 19:25:53 +0100 MIME-Version: 1.0 Content-Type: text/plain Tom, > > > > 4) Again, wrt Section 4.8 from RFC4181, it is recommended > > that if MIB authors intend to have Optional Groups that these > > be noted. This was done for the Read-only compliance but not > > the Full-compliance, so would ask that all Optional Groups be > > specified as recommended by Section 4.8. Reviewing these > > Compliances statements is difficult without this information. > > I don't understand. There are 5 groups, two of which > are specified as Mandatory, and the other three are explained > to be optional and why below that. > It seems pretty clear that Joan tries to explain to you that the proper way to define those optional groups (in BOTH MODULE-COMPLIANCE statemnts( is to add the optional groups. You do it correctly for the read-only compliance, but not for the fullCOmpliance. So I think the fix is something like: OLD: gmplsTeModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for GMPLS-TE-STD-MIB. Such devices can then be monitored and also be configured using this MIB module. The mandatory group has to be implemented by all LSRs that originate, terminate or act as transit for TE-LSPs/tunnels. Nadeau and Farrel (Editors) [Page 40] ^L Internet Draft draft-ietf-ccamp-gmpls-te-mib-13.txt March 2006 In addition, depending on the type of tunnels supported, other groups become mandatory as explained below." MODULE -- this module MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup, gmplsTunnelSignaledGroup } ::= { gmplsTeCompliances 1 } NEW: gmplsTeModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for GMPLS-TE-STD-MIB. Such devices can then be monitored and also be configured using this MIB module." MODULE -- this module MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup, gmplsTunnelSignaledGroup } GROUP gmplsTunnelSignaledGroup DESCRIPTION "This group is mandatory for devices which support signaled tunnel set up, in addition to gmplsTunnelGroup. The following constraints apply: mplsTunnelSignallingProto should be at least read-only returning a value of ldp(2), or rsvp(3)." GROUP gmplsTunnelIsIntfcGroup DESCRIPTION "This group is mandatory for devices which support tunnels that are interfaces, in addition to gmplsTunnelGroup." GROUP gmplsTunnelOptionalGroup DESCRIPTION "Objects in this group are optional." GROUP gmplsTeNotificationGroup DESCRIPTION "This group is mandatory for those implementations which can implement the notifications contained in this group." ::= { gmplsTeCompliances 1 } Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Mar 2006 17:30:03 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Wed, 22 Mar 2006 11:28:44 -0600 To: "" > Tom and Adrian, > > Let me apologize for my tardiness in posting the > review comments. Let me apologize for my tardiness in replying to you. *) > A great deal of work went into this latest draft. Thank you. > Compile issues are listed first, and are followed by > review comments in order of the document. > > Will have the other reviews out by tomorrow. > > Thanks, Joan > > > > Compile Issues: > =============== > > > 1) smilint and smicngPRO complained > due to REFERENCE clause for gmplsTunnelARHopTable > needing an end quote: > > gmplsTunnelARHopTable OBJECT-TYPE > ... > REFERENCE > "1. Extensions to RSVP for LSP Tunnels, RFC 3209. > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. > 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) > Management Information Base (MIB), RFC 3812. > > ^ need end quote > > ::= { gmplsTeObjects 3 } > > > 2) smicngPRO > E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf" > is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in > module "GMPLS-TE-STD-MIB" > > > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelIsIntfcGroup <-- please add this > gmplsTunnelUnnumIf <--- please remove this > } Done. > Also, please update the read-only conformance for gmplsTunnelUnnumIf. > > OBJECT gmplsTunnelUnnumIf > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > 3) This is listed under compile issues because it might be > an issue depending on what is really intended. > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX clause. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsTunnelLSPEncoding > SYNTAX IANAGmplsLSPEncodingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsTunnelSwitchingType > SYNTAX IANAGmplsSwitchingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." done. > SYNTAX clauses such as InetAddressType and InetAddress don't > specify a subset, so need to ask if you intend > to have a subset for these such as: > > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > > SYNTAX InetAddress (SIZE(0|4|16)) I found about 6 more, and fixed them. > > > 4) Again, wrt Section 4.8 from RFC4181, it is recommended > that if MIB authors intend to have Optional Groups that these > be noted. This was done for the Read-only compliance but not > the Full-compliance, so would ask that all Optional Groups be > specified as recommended by Section 4.8. Reviewing these > Compliances statements is difficult without this information. I don't understand. There are 5 groups, two of which are specified as Mandatory, and the other three are explained to be optional and why below that. > Comments: > ----------- > > 1) Table of Contents: > > 3. The SNMP Management Framework .......................... 4 > > Should be: > 3. The Internet-Standard Management Framework > In other words, please change the title for section 3. > > > 2) 5.7 Use of 32-bit and 64-bit Counters > > Shouldn't the quote from RFC2863 be in quotes""? Perhaps, but we were just following what was approved in section 6 of RFC3813: 6. Use of 32-bit and 64-bit Counters 64-bit counters are provided in this MIB module for high speed interfaces where the use of 32-bit counters might be impractical. The requirements on the use of 32-bit and 64-bit counters (copied verbatim from [RFC2863]) are as follows. For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported. > > 3) 6. Cross-referencing to the gmplsLabelTable > > 2nd paragraph which begins: > The hop tables in this document (gmplsHopTable, gmplsCHopTable and > gmplsARHopTable) and the segment tables in the [RFC3813] > > There is no gmplsHopTable, is this supposed to be: > gmplsTunnelHopTable? > Similar comment with gmplsCHopTable and gmplsARHopTable. > > > 4) gmplsTunnelPathComp > > If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls' > does this object have meaning? > > 5) gmplsTunnelErrorTable, would expect to see these objects > contained in an MPLS group in Compliance/Conformance Statements. Can you explain what "an MPLS group" would be specifically? > > > 6) gmplsTunnelErrorTLVs OBJECT-TYPE > > When the string size is 0 this could indicate that > no TLVs are present, right? > That would be slightly more efficient than > having to look at the first octet. > If you agree, please modify the > DESCRIPTION to reflect this. "The sequence of interface identifier TLVs reported with the error by the protocol code. The interpretation of the TLVs and the encoding within the protocol are described in the references. A value of zero in the first octet indicates that no TLVs are present." > > > Conformace/Compliance: > --------------------- > 7) Please move some of the following comment to the > gmplsTeModuleReadOnlyCompliance DESCRIPTION > -- The mandatory group has to be implemented by all LSRs that > -- originate, terminate or act as transit for TE-LSPs/tunnels. > -- In addition, depending on the type of tunnels supported, other > -- groups become mandatory as explained below. > > > 8) Already mentioned this but was expecting to see MPLS objects > called out in a separate GROUP (e.g. objects which are valid when > gmplsTunnelLSPEncoding > has a value of 'tunnelLspNotGmpls', and other objects also). > For folks that want to support these MPLS related objects > prior to supporting GMPLS, this would be > important to understand, so the more clearly noted by the MIB the > better. > > > > 9) NIT: In the read-only conformance there is a comment: > > -- All scalars have max access read-only > > which appears in front of a bunch of objects that are > part of a table. Please remove this comment since it > doesn't apply. > > 10) NIT: > > --glmpsTunnelCHopTable > > ^^ typo > > > 11) Security Section > > NIT: the network via SNMP. These are the tables and objects and > their > sensitivity/vulnerability: > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, > gmplsTunnelErrorTable collectively show the tunnel network > > > Should have an "and" > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and > > ^^^ > > gmplsTunnelErrorTable collectively show the tunnel network > > > > 12) Normative References: > [RFC4328] Papadimitriou, D., Ed., "Generalized MPLS Signalling > Extensions for G.709 Optical Transport Networks > Control", draft-ietf-ccamp-gmpls-g709, work in > progress. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please update. > > --end of comments-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Mar 2006 17:07:09 +0000 Message-ID: <00c601c64dd3$96bd89c0$e2808182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Subject: Fw: Liaison on issues related to T-MPLS (G.8110.1 and G.8112) Date: Wed, 22 Mar 2006 17:10:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI, Here is a liaison sent by your ADs and the chairs of MPLS and CCAMP to the ITU-T in an attempt to get review input to T-MPLS. Thanks for the discussion in MPLS (and thanks for only shooting me a little). Adrian ----- Original Message ----- From: "Adrian Farrel" To: ; Cc: "Scott Bradner" ; "Adrian Farrel" ; "Stephen Trowbridge" ; "Ross Callon" ; "Bill Fenner" ; "'Kireeti Kompella'" ; "Loa Andersson" ; "George Swallow" ; "Scott W Brim" Sent: Wednesday, March 22, 2006 5:01 PM Subject: Liaison on issues related to T-MPLS (G.8110.1 and G.8112) > From: The IETF Routing Area, and the MPLS and CCAMP working groups > To: ITU-T SG-15 (Yoichi Maeda) > Cc: ITU-T WP 3 (Stephen Trowbridge) > Scott Bradner (IETF-ITU liaison manager) > Scott Brim (IETF-ITU NGN liaison manager) > Title: Liaison on issues related to T-MPLS (G.8110.1 and G.8112) > Response contact: Loa Andersson > Technical contact: Loa Andersson > Purpose: For action > Deadline 29th March 2006 > > Dear Mr. Maeda, > > At the MPLS working group meeting in Dallas on March 20th there was a > brief discussion on the Transport MPLS (T-MPLS) work taking place in SG 13 > and 15 of the ITU-T. > > The IETF and the MPLS and the CCAMP working groups have not had an > opportunity to comment on the documents so far. We also learned that there > is only a short time left before the Recommendations are scheduled to be > completed through AAP. > > We would like to ask that the ITU-T SGs liaise the draft recommendations > to the IETF, and in particular to the MPLS and CCAMP working groups, and > at the same time give us enough time to comment on the documents. We > appreciate that this may require a delay in the normal document process in > the ITU-T, but we feel that this would be desirable in the interest > of cooperation between our organisations and for the wider benefit of the > industry. A process to change and extend the MPLS and CCAMP specifications > will be found in draft-andersson-rtg-gmpls-change-02. This process is > being developed in cooperation with ITU-T, and we are working to > incorporate the comments received based on this information exchange. > > We believe that there may be some issues and concerns with the T-MPLS > work, but we have not yet been able to review it and the time frame for > the AAP will not allow a detailed coordinated response to this work. > > If this it is not possible to give us time comment on these documents, we > are concerned that any Recommendations related to T-MPLS may be > incompatible with current and/or future work on MPLS. > > > MPLS working group co-chairs > Loa Andersson and George Swallow > > CCAMP working group co-chairs > Adrian Farrel and Kireeti Kompella > > IETF Routing Area Directors > Bill Fenner and Ross Callon > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Mar 2006 16:45:52 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <052317DF-DA29-4D6F-A00D-99FA520C4F42@cisco.com> Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt Date: Wed, 22 Mar 2006 10:44:47 -0600 To: "" On Mar 14, 2006, at 11:30 PM, wrote: > Hi Tom and Adrian, > > Thank you for all the great updates > to this draft. Compile issues listed > first, followed by review comments. > > Thanks, > Joan > > Compile Issues > ================ > > GMPLS-LSR-STD-MIB > ==================== > 1) smicngPRO > W: f(GMPLS-LSR-STD-MIB), (391,18) For > "gmplsOutSegmentTTLDecrement", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (397,18) For > "gmplsInSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (404,18) For > "gmplsOutSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (447,14) For > "gmplsInterfaceSignalingCaps", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (460,18) For > "gmplsInterfaceRsvpHelloPeriod", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (474,18) For > "gmplsInSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (488,18) For > "gmplsOutSegmentTTLDecrement", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (494,18) For " > gmplsOutSegmentExtraParamsPtr", syntax is identical > > > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsInterfaceRsvpHelloPeriod > SYNTAX Unsigned32 > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. Only forward(1) needs to be > supported by implementations that only support unidirectional > LSPs." > > OBJECT gmplsInSegmentExtraParamsPtr > SYNTAX RowPointer > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." Fixed these. > > > > > > > GMPLS-LABEL-STD-MIB > =================== > > 1) smicngPRO and smiLint flagged line 622 > > E: f(GMPLS-LABEL-STD-MIB), (622,6) syntax error > E: f(GMPLS-LABEL-STD-MIB), (622,6) Syntax for OBJECT clause is > "OBJECT" > E: f(GMPLS-LABEL-STD-MIB), (518,12) Group "gmplsLabelTableGroup" is > both a MANDATORY and conditional group for module "GMPLS-LABEL- > STD-MIB" > > OBJECT gmplsLabelRowStatus > MIN-ACCESS read-only > --> SYNTAX RowStatus { active(1) } > DESCRIPTION > "Support for notInService, createAndWait and notReady is not > required." > > Need to put SYNTAX clause before MIN-ACCESS clause. > > 2) E: f(GMPLS-LABEL-STD-MIB), (518,12) > Group "gmplsLabelTableGroup" is both a MANDATORY and > conditional group for module "GMPLS-LABEL-STD-MIB" > > The above is flagged as an error but is actually more > pervasive than just this one error: both the > FullCompliance and the Read-only Compliance statements have > Groups listed as Mandatory but then appear as Optional. > This needs to be clarified per RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements. > > Related to this, the following groups are currently listed as > Mandatory under Full compliance, but would think > that these only apply if the device has certain > interfaces (e.g. gmplsLabelSonetSdhGroup if Sonet > interfaces are on the device), is this > an Optional Group? What about these other groups? > > gmplsLabelPacketGroup, > gmplsLabelPortWavelengthGroup, > gmplsLabelFreeformGroup, > gmplsLabelSonetSdhGroup, > gmplsLabelWavebandGroup > Fixed all of the above. > > 3) Same comment as with the GMPLS-TE-STD-MIB wrt having > an MPLS GROUP in the compliances statements. Would be > most helpful to know what objects apply to MPLS. Can we talk about this one in more detail? I am confused about what you are asking for specifically here. > Comments in order of document. > ============================== > 1) Table of Contents > > 3. The SNMP Management Framework .................... 4 > Please rename to: > > The Internet-Standard Management Framework > > 2) 1.1. Migration Strategy, 5th paragraph: > > the various label pointer objects in the MPLS-STD-LSR-MIB module > ^^^^ > Please fix: MPLS-STD-LSR-MIB to MPLS-LSR-STD-MIB > > 3) Please remove "and OBJECT-IDENTIFIERS" in the last paragraph > > Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] > and [GMPLSTCMIB] ... > > > 4) gmplsLsrModuleFullCompliance MODULE-COMPLIANCE > > 2 issues: > a) The following 2 objects could have an MIN-ACCESS of > read-only since the DEFVAL is forward. > > b) the DESCRIPTION is a little awkward, could this be reworded: > "The only valid value for unidirectional LSPs is forward(1)." > > This would need to be updated in the read-only section also. > (Similar comments for gmplsOutSegmentDirection). > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-write > DESCRIPTION > "Only forward(1) needs to be supported by implementations that > only support unidirectional LSPs." > > OBJECT gmplsOutSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-write > DESCRIPTION > "Only forward(1) needs to be supported by implementations that > only support unidirectional LSPs." > > GMPLS-LABEL-STD-MIB > ======================== > 5) gmplsLabelInterface and gmplsLabelIndex > > I had a question regarding these 2 indices: if there is a per- > platform > label, MUST both of these values be zero? Is there any other > circumstance > in which both would or could be zero? OK, I updated the text a bit. please look at it. > > I was a little confused on the use of "could" and "may result" and was > wondering if this should be made a little more forceful. Yes, I think we should change this to SHOULD. > 6) As previously mentioned could MPLS objects be denoted > in a separate GROUP (e.g., gmplsLabelMplsLabel and possibly other > objects). Can you please explain why we would do this instead of or in addition to what we are doing now? I am confused since we are already requiring the objects from the MPLS RFCs in the mandatory MODULE statements. > 7) Please put the comment in the DESCRIPTION clause of > the gmplsLabelModuleFullCompliance. > -- The mandatory groups have to be implemented by GMPLS LSRs > -- claiming support for this MIB module. This MIB module is, > -- however, not mandatory for a working implementation of a GMPLS > -- LSR with full MIB support if the GMPLS labels in use can be > -- represented within a 32 bit quantity. OK. --Tom > > > --end of comments -- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Mar 2006 16:08:53 +0000 Message-ID: <006d01c64dcb$6e31dfe0$e2808182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaisons received from ITU-T Study Group 15 Date: Wed, 22 Mar 2006 16:10:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We received the following liaisons from the latest SG15 meeting in February. ITU-T Study Group 15 OTNT Standardization Work Plan https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=199 We are invited to comment. Recent ASON Recommendations https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=200 This is for our information as the Recommendations have already been approved and we are not invited to comment. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Mar 2006 15:37:14 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DA9D182-1B80-4254-9143-6A989851269F@cisco.com> Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Wed, 22 Mar 2006 09:36:53 -0600 To: On Mar 22, 2006, at 9:08 AM, wrote: > > Hi Tom, > > I think we have a disconnect somewhere...when I said > that the use of the "TC" was not consistent, I meant with > TCs in general (not just in GMPLS MIBs), so would prefer > to see this removed. > > I looked at the use of the Textual Conventions in the > GMPLS MIBs and saw that one still is the same as > an Object (except in case) which was gmplsLabelType. > (I do think there was more overlap originally but names have > changed since then). There was, and I am fixing that now. Almost done with the TE module and I will send them all over for your review. I updated the others yesterday. > My suggestion would be to remove the "TC" suffix from the > TCs and change the name of the overlapping gmplsLabelType object > to something else (gmplsTypeOfLabel). > > I do realize this is a style issue, so not a show stopper, only a > humble > suggestion. I understand your point and I respectfully declined to change them, but agreed (based on Bert's post) to make them consistent throughout the modules. --Tom > > Thanks, > Joan > > > > ----- Original Message ----- > From: Thomas D. Nadeau > To: > Cc: ; Wijnen, Bert (Bert) ; > Dan > Romascanu (E-mail) ; Adrian Farrel (E-mail) > ; Bill Fenner (E-mail) > ; Alex > Zinin (E-mail) > Sent: Tuesday, March 21, 2006 3:19 PM > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt > > >> >> As per Bert's reply to this, I have made >> all of the TCs in the CCAMP/GMPLS TC and LSR MIBs to have >> "TC" at the end of their names to keep them consistent. >> >> --Tom >> >> >>> >>> Hi Tom and Adrian, >>> >>> Due to the updates to the 2 other GMPLS MIB documents >>> wanted to re-review this document. >>> >>> I did have one minor comment which was >>> the naming convention used, specifically >>> the use of the TC on the end of the names of these >>> Textual Conventions. >>> >>> GmplsFreeformLabelTC >>> GmplsLabelTypeTC >>> GmplsSegmentDirectionTC >>> >>> Could this "TC" be removed? Sorry to not catch this >>> earlier. >>> >>> The reason is that this is not consistent with >>> other Textual Conventions. >>> >>> Thanks, >>> Joan >>> >> Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Mar 2006 15:32:48 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QhZ9Yu6FNU5XQjS8UdsWyyo3NAreKw2PRSFISnofSUuV0yaarJNqyfvFsmFrX6XO; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <007f01c64dc2$6e8a7640$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Wed, 22 Mar 2006 10:08:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom, I think we have a disconnect somewhere...when I said that the use of the "TC" was not consistent, I meant with TCs in general (not just in GMPLS MIBs), so would prefer to see this removed. I looked at the use of the Textual Conventions in the GMPLS MIBs and saw that one still is the same as an Object (except in case) which was gmplsLabelType. (I do think there was more overlap originally but names have changed since then). My suggestion would be to remove the "TC" suffix from the TCs and change the name of the overlapping gmplsLabelType object to something else (gmplsTypeOfLabel). I do realize this is a style issue, so not a show stopper, only a humble suggestion. Thanks, Joan ----- Original Message ----- From: Thomas D. Nadeau To: Cc: ; Wijnen, Bert (Bert) ; Dan Romascanu (E-mail) ; Adrian Farrel (E-mail) ; Bill Fenner (E-mail) ; Alex Zinin (E-mail) Sent: Tuesday, March 21, 2006 3:19 PM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt > > As per Bert's reply to this, I have made > all of the TCs in the CCAMP/GMPLS TC and LSR MIBs to have > "TC" at the end of their names to keep them consistent. > > --Tom > > > > > > Hi Tom and Adrian, > > > > Due to the updates to the 2 other GMPLS MIB documents > > wanted to re-review this document. > > > > I did have one minor comment which was > > the naming convention used, specifically > > the use of the TC on the end of the names of these > > Textual Conventions. > > > > GmplsFreeformLabelTC > > GmplsLabelTypeTC > > GmplsSegmentDirectionTC > > > > Could this "TC" be removed? Sorry to not catch this > > earlier. > > > > The reason is that this is not consistent with > > other Textual Conventions. > > > > Thanks, > > Joan > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 21 Mar 2006 20:38:24 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <38C461EB-7062-4582-99D7-1B85E6DA4956@cisco.com> Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Tue, 21 Mar 2006 14:19:22 -0600 To: "" As per Bert's reply to this, I have made all of the TCs in the CCAMP/GMPLS TC and LSR MIBs to have "TC" at the end of their names to keep them consistent. --Tom > > Hi Tom and Adrian, > > Due to the updates to the 2 other GMPLS MIB documents > wanted to re-review this document. > > I did have one minor comment which was > the naming convention used, specifically > the use of the TC on the end of the names of these > Textual Conventions. > > GmplsFreeformLabelTC > GmplsLabelTypeTC > GmplsSegmentDirectionTC > > Could this "TC" be removed? Sorry to not catch this > earlier. > > The reason is that this is not consistent with > other Textual Conventions. > > Thanks, > Joan > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 20 Mar 2006 20:30:21 +0000 Message-ID: <441F106C.2070808@psg.com> Date: Mon, 20 Mar 2006 21:28:28 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Reminder - slides on Tuesday at the latest Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit adrian - didn't recall having seen a minder ;-) Adrian Farrel wrote: > Thanks! > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 20 Mar 2006 07:20:34 +0000 Message-ID: <04c401c64bef$0c630240$e2808182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Reminder - slides on Tuesday at the latest Date: Mon, 20 Mar 2006 07:19:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks! Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 17 Mar 2006 23:09:29 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: jcucchiara@mindspring.com, ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Fri, 17 Mar 2006 17:07:42 -0600 To: "Wijnen, Bert (Bert)" On Mar 17, 2006, at 8:32 AM, Wijnen, Bert (Bert) wrote: > Inline > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: Wednesday, March 15, 2006 17:17 >> To: jcucchiara@mindspring.com >> Cc: ccamp@ops.ietf.org; Wijnen, Bert (Bert); Dan Romascanu (E-mail); >> Adrian Farrel (E-mail); Bill Fenner (E-mail); Alex Zinin (E-mail) >> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt >> >> >> >> On Mar 15, 2006, at 12:32 AM, wrote: >> >>> >>> Hi Tom and Adrian, >>> >>> Due to the updates to the 2 other GMPLS MIB documents >>> wanted to re-review this document. >>> >>> I did have one minor comment which was >>> the naming convention used, specifically >>> the use of the TC on the end of the names of these >>> Textual Conventions. >>> >>> GmplsFreeformLabelTC >>> GmplsLabelTypeTC >>> GmplsSegmentDirectionTC >>> >>> Could this "TC" be removed? Sorry to not catch this >>> earlier. >> >> The "TC" was appended to remove the ambiguity >> between the variable and TC names. This is actually a >> warning from SmiLint too. Something like "Warning: object and >> TC differ only in case". >> > > Note that it is a warning. So it is not mandatory to change. > I agree with the warning in that it is better to not have exactly the > same names for TCs and for and object descriptors (variable names). > Not sure that adding TC at the end of the TC descriptor is the > best solution, but it is one way to do things. > >>> The reason is that this is not consistent with >>> other Textual Conventions. >> >> I tried to make all TCs end in "TC" for >> the reason stated above. I will go back and 2x check >> the others and make things consistent. >> > Consistency is also a good thing as I have always been saying (I > think). > > So do I take from this we should expect a new rev? Hi Bert, Yes. I spoke with Joan offline yesterday and am working on incorporating all of her changes. I should have something on Monday and will email to her directly to review my fixes/changes. I will post an update as soon as the ID gate opens. --Tom > > Bert >> --Tom >> >> >>> >>> Thanks, >>> Joan >>> >> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 17 Mar 2006 14:35:07 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E1EE8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, "Alex Zinin (E-mail)" Cc: "Dan Romascanu (E-mail)" , ccamp@ops.ietf.org, "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Tom Nadeau (E-mail)" Subject: RE: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt Date: Fri, 17 Mar 2006 15:32:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks Joan for anotehr great review. >From what I read here, it seems we need yet another revision. So I am recording these MIB doctor comments in the ID tracker and I sugegst to ALEX to mark the document as revised ID needed. Bert > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Wednesday, March 15, 2006 06:31 > To: ccamp@ops.ietf.org > Cc: Wijnen, Bert (Bert); Dan Romascanu (E-mail); Adrian > Farrel (E-mail); > Bill Fenner (E-mail); Alex Zinin (E-mail); Tom Nadeau (E-mail) > Subject: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt > > > Hi Tom and Adrian, > > Thank you for all the great updates > to this draft. Compile issues listed > first, followed by review comments. > > Thanks, > Joan > > Compile Issues > ================ > > GMPLS-LSR-STD-MIB > ==================== > 1) smicngPRO > W: f(GMPLS-LSR-STD-MIB), (391,18) For > "gmplsOutSegmentTTLDecrement", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (397,18) For > "gmplsInSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (404,18) For > "gmplsOutSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (447,14) For > "gmplsInterfaceSignalingCaps", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (460,18) For > "gmplsInterfaceRsvpHelloPeriod", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (474,18) For > "gmplsInSegmentExtraParamsPtr", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (488,18) For > "gmplsOutSegmentTTLDecrement", syntax is identical > W: f(GMPLS-LSR-STD-MIB), (494,18) For " > gmplsOutSegmentExtraParamsPtr", syntax is identical > > > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsInterfaceRsvpHelloPeriod > SYNTAX Unsigned32 > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. Only forward(1) needs to be > supported by implementations that only support unidirectional > LSPs." > > OBJECT gmplsInSegmentExtraParamsPtr > SYNTAX RowPointer > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > > > > > > GMPLS-LABEL-STD-MIB > =================== > > 1) smicngPRO and smiLint flagged line 622 > > E: f(GMPLS-LABEL-STD-MIB), (622,6) syntax error > E: f(GMPLS-LABEL-STD-MIB), (622,6) Syntax for OBJECT clause is > "OBJECT" > E: f(GMPLS-LABEL-STD-MIB), (518,12) Group "gmplsLabelTableGroup" is > both a MANDATORY and conditional group for module > "GMPLS-LABEL-STD-MIB" > > OBJECT gmplsLabelRowStatus > MIN-ACCESS read-only > --> SYNTAX RowStatus { active(1) } > DESCRIPTION > "Support for notInService, createAndWait and notReady is not > required." > > Need to put SYNTAX clause before MIN-ACCESS clause. > > 2) E: f(GMPLS-LABEL-STD-MIB), (518,12) > Group "gmplsLabelTableGroup" is both a MANDATORY and > conditional group for module "GMPLS-LABEL-STD-MIB" > > The above is flagged as an error but is actually more > pervasive than just this one error: both the > FullCompliance and the Read-only Compliance statements have > Groups listed as Mandatory but then appear as Optional. > This needs to be clarified per RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements. > > Related to this, the following groups are currently listed as > Mandatory under Full compliance, but would think > that these only apply if the device has certain > interfaces (e.g. gmplsLabelSonetSdhGroup if Sonet > interfaces are on the device), is this > an Optional Group? What about these other groups? > > gmplsLabelPacketGroup, > gmplsLabelPortWavelengthGroup, > gmplsLabelFreeformGroup, > gmplsLabelSonetSdhGroup, > gmplsLabelWavebandGroup > > > 3) Same comment as with the GMPLS-TE-STD-MIB wrt having > an MPLS GROUP in the compliances statements. Would be > most helpful to know what objects apply to MPLS. > > > > Comments in order of document. > ============================== > 1) Table of Contents > > 3. The SNMP Management Framework .................... 4 > Please rename to: > > The Internet-Standard Management Framework > > 2) 1.1. Migration Strategy, 5th paragraph: > > the various label pointer objects in the MPLS-STD-LSR-MIB module > ^^^^ > Please fix: MPLS-STD-LSR-MIB to MPLS-LSR-STD-MIB > > 3) Please remove "and OBJECT-IDENTIFIERS" in the last paragraph > > Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] > and [GMPLSTCMIB] ... > > > 4) gmplsLsrModuleFullCompliance MODULE-COMPLIANCE > > 2 issues: > a) The following 2 objects could have an MIN-ACCESS of > read-only since the DEFVAL is forward. > > b) the DESCRIPTION is a little awkward, could this be reworded: > "The only valid value for unidirectional LSPs is forward(1)." > > This would need to be updated in the read-only section also. > (Similar comments for gmplsOutSegmentDirection). > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-write > DESCRIPTION > "Only forward(1) needs to be supported by implementations that > only support unidirectional LSPs." > > OBJECT gmplsOutSegmentDirection > SYNTAX GmplsSegmentDirectionTC > MIN-ACCESS read-write > DESCRIPTION > "Only forward(1) needs to be supported by implementations that > only support unidirectional LSPs." > > GMPLS-LABEL-STD-MIB > ======================== > 5) gmplsLabelInterface and gmplsLabelIndex > > I had a question regarding these 2 indices: if there is a > per-platform > label, MUST both of these values be zero? Is there any other > circumstance > in which both would or could be zero? > > I was a little confused on the use of "could" and "may result" and was > wondering if this should be made a little more forceful. > > > 6) As previously mentioned could MPLS objects be denoted > in a separate GROUP (e.g., gmplsLabelMplsLabel and possibly other > objects). > > 7) Please put the comment in the DESCRIPTION clause of > the gmplsLabelModuleFullCompliance. > -- The mandatory groups have to be implemented by GMPLS LSRs > -- claiming support for this MIB module. This MIB module is, > -- however, not mandatory for a working implementation of a GMPLS > -- LSR with full MIB support if the GMPLS labels in use can be > -- represented within a 32 bit quantity. > > > --end of comments -- > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 17 Mar 2006 14:34:59 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E1EEA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, "Alex Zinin (E-mail)" Cc: ccamp@ops.ietf.org, "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Tom Nadeau (E-mail)" Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Fri, 17 Mar 2006 15:32:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks for this great review Joan. Seemsthat a new revision is warranted, and so I will record these MIB doctor review comments in the ID tracker and I suggest to Alex to mark the document as revised ID needed. Bert > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Tuesday, March 14, 2006 16:52 > To: ccamp@ops.ietf.org > Cc: Wijnen, Bert (Bert); Dan Romascanu (E-mail); Adrian > Farrel (E-mail); > Bill Fenner (E-mail); Alex Zinin (E-mail); Tom Nadeau (E-mail) > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt > > > Tom and Adrian, > > Let me apologize for my tardiness in posting the > review comments. > > A great deal of work went into this latest draft. Thank you. > Compile issues are listed first, and are followed by > review comments in order of the document. > > Will have the other reviews out by tomorrow. > > Thanks, Joan > > > > Compile Issues: > =============== > > > 1) smilint and smicngPRO complained > due to REFERENCE clause for gmplsTunnelARHopTable > needing an end quote: > > gmplsTunnelARHopTable OBJECT-TYPE > ... > REFERENCE > "1. Extensions to RSVP for LSP Tunnels, RFC 3209. > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. > 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) > Management Information Base (MIB), RFC 3812. > > ^ need end quote > > ::= { gmplsTeObjects 3 } > > > 2) smicngPRO > E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf" > is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in > module "GMPLS-TE-STD-MIB" > > > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelIsIntfcGroup <-- please add this > gmplsTunnelUnnumIf <--- please remove this > } > > > Also, please update the read-only conformance for gmplsTunnelUnnumIf. > > OBJECT gmplsTunnelUnnumIf > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > 3) This is listed under compile issues because it might be > an issue depending on what is really intended. > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX clause. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsTunnelLSPEncoding > SYNTAX IANAGmplsLSPEncodingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsTunnelSwitchingType > SYNTAX IANAGmplsSwitchingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > > > SYNTAX clauses such as InetAddressType and InetAddress don't > specify a subset, so need to ask if you intend > to have a subset for these such as: > > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > > SYNTAX InetAddress (SIZE(0|4|16)) > > > 4) Again, wrt Section 4.8 from RFC4181, it is recommended > that if MIB authors intend to have Optional Groups that these > be noted. This was done for the Read-only compliance but not > the Full-compliance, so would ask that all Optional Groups be > specified as recommended by Section 4.8. Reviewing these > Compliances statements is difficult without this information. > > > > Comments: > ----------- > > 1) Table of Contents: > > 3. The SNMP Management Framework .......................... 4 > > Should be: > 3. The Internet-Standard Management Framework > In other words, please change the title for section 3. > > > 2) 5.7 Use of 32-bit and 64-bit Counters > > Shouldn't the quote from RFC2863 be in quotes""? > > 3) 6. Cross-referencing to the gmplsLabelTable > > 2nd paragraph which begins: > The hop tables in this document (gmplsHopTable, gmplsCHopTable and > gmplsARHopTable) and the segment tables in the [RFC3813] > > There is no gmplsHopTable, is this supposed to be: > gmplsTunnelHopTable? > Similar comment with gmplsCHopTable and gmplsARHopTable. > > > 4) gmplsTunnelPathComp > > If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls' > does this object have meaning? > > 5) gmplsTunnelErrorTable, would expect to see these objects > contained in an MPLS group in Compliance/Conformance Statements. > > > 6) gmplsTunnelErrorTLVs OBJECT-TYPE > > When the string size is 0 this could indicate that > no TLVs are present, right? > That would be slightly more efficient than > having to look at the first octet. > If you agree, please modify the > DESCRIPTION to reflect this. > > > Conformace/Compliance: > --------------------- > 7) Please move some of the following comment to the > gmplsTeModuleReadOnlyCompliance DESCRIPTION > -- The mandatory group has to be implemented by all LSRs that > -- originate, terminate or act as transit for TE-LSPs/tunnels. > -- In addition, depending on the type of tunnels supported, other > -- groups become mandatory as explained below. > > > 8) Already mentioned this but was expecting to see MPLS objects > called out in a separate GROUP (e.g. objects which are valid when > gmplsTunnelLSPEncoding > has a value of 'tunnelLspNotGmpls', and other objects also). > For folks that want to support these MPLS related objects > prior to supporting GMPLS, this would be > important to understand, so the more clearly noted by the MIB the > better. > > > > 9) NIT: In the read-only conformance there is a comment: > > -- All scalars have max access read-only > > which appears in front of a bunch of objects that are > part of a table. Please remove this comment since it > doesn't apply. > > 10) NIT: > > --glmpsTunnelCHopTable > > ^^ typo > > > 11) Security Section > > NIT: the network via SNMP. These are the tables and > objects and their > sensitivity/vulnerability: > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, > gmplsTunnelErrorTable collectively show the tunnel network > > > Should have an "and" > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and > > ^^^ > > gmplsTunnelErrorTable collectively show the tunnel network > > > > 12) Normative References: > [RFC4328] Papadimitriou, D., Ed., "Generalized MPLS Signalling > Extensions for G.709 Optical Transport Networks > Control", draft-ietf-ccamp-gmpls-g709, work > in progress. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please update. > > --end of comments-- > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 17 Mar 2006 14:34:51 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E1EE9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , jcucchiara@mindspring.com Cc: ccamp@ops.ietf.org, "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Fri, 17 Mar 2006 15:32:23 +0100 MIME-Version: 1.0 Content-Type: text/plain Inline > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, March 15, 2006 17:17 > To: jcucchiara@mindspring.com > Cc: ccamp@ops.ietf.org; Wijnen, Bert (Bert); Dan Romascanu (E-mail); > Adrian Farrel (E-mail); Bill Fenner (E-mail); Alex Zinin (E-mail) > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt > > > > On Mar 15, 2006, at 12:32 AM, wrote: > > > > > Hi Tom and Adrian, > > > > Due to the updates to the 2 other GMPLS MIB documents > > wanted to re-review this document. > > > > I did have one minor comment which was > > the naming convention used, specifically > > the use of the TC on the end of the names of these > > Textual Conventions. > > > > GmplsFreeformLabelTC > > GmplsLabelTypeTC > > GmplsSegmentDirectionTC > > > > Could this "TC" be removed? Sorry to not catch this > > earlier. > > The "TC" was appended to remove the ambiguity > between the variable and TC names. This is actually a > warning from SmiLint too. Something like "Warning: object and > TC differ only in case". > Note that it is a warning. So it is not mandatory to change. I agree with the warning in that it is better to not have exactly the same names for TCs and for and object descriptors (variable names). Not sure that adding TC at the end of the TC descriptor is the best solution, but it is one way to do things. > > The reason is that this is not consistent with > > other Textual Conventions. > > I tried to make all TCs end in "TC" for > the reason stated above. I will go back and 2x check > the others and make things consistent. > Consistency is also a good thing as I have always been saying (I think). So do I take from this we should expect a new rev? Bert > --Tom > > > > > > Thanks, > > Joan > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Mar 2006 16:18:32 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Wed, 15 Mar 2006 11:16:53 -0500 To: On Mar 15, 2006, at 12:32 AM, wrote: > > Hi Tom and Adrian, > > Due to the updates to the 2 other GMPLS MIB documents > wanted to re-review this document. > > I did have one minor comment which was > the naming convention used, specifically > the use of the TC on the end of the names of these > Textual Conventions. > > GmplsFreeformLabelTC > GmplsLabelTypeTC > GmplsSegmentDirectionTC > > Could this "TC" be removed? Sorry to not catch this > earlier. The "TC" was appended to remove the ambiguity between the variable and TC names. This is actually a warning from SmiLint too. Something like "Warning: object and TC differ only in case". > The reason is that this is not consistent with > other Textual Conventions. I tried to make all TCs end in "TC" for the reason stated above. I will go back and 2x check the others and make things consistent. --Tom > > Thanks, > Joan > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Mar 2006 05:34:01 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GMXfjcaZEk7xLLfMIgFHWXvB9hDIfnzR17GUEb88mKXx+OcVfJvRiAKjgTnHGWxn; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <019c01c647f1$a0fa81a0$0500a8c0@jlucianilaptop> From: To: Cc: "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" , "Tom Nadeau (E-mail)" Subject: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt Date: Wed, 15 Mar 2006 00:30:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom and Adrian, Thank you for all the great updates to this draft. Compile issues listed first, followed by review comments. Thanks, Joan Compile Issues ================ GMPLS-LSR-STD-MIB ==================== 1) smicngPRO W: f(GMPLS-LSR-STD-MIB), (391,18) For "gmplsOutSegmentTTLDecrement", syntax is identical W: f(GMPLS-LSR-STD-MIB), (397,18) For "gmplsInSegmentExtraParamsPtr", syntax is identical W: f(GMPLS-LSR-STD-MIB), (404,18) For "gmplsOutSegmentExtraParamsPtr", syntax is identical W: f(GMPLS-LSR-STD-MIB), (447,14) For "gmplsInterfaceSignalingCaps", syntax is identical W: f(GMPLS-LSR-STD-MIB), (460,18) For "gmplsInterfaceRsvpHelloPeriod", syntax is identical W: f(GMPLS-LSR-STD-MIB), (474,18) For "gmplsInSegmentExtraParamsPtr", syntax is identical W: f(GMPLS-LSR-STD-MIB), (488,18) For "gmplsOutSegmentTTLDecrement", syntax is identical W: f(GMPLS-LSR-STD-MIB), (494,18) For " gmplsOutSegmentExtraParamsPtr", syntax is identical RFC4181 "Guidelines for MIB Documents", Section 4.8. Compliance Statements, recommends using SYNTAX clauses to denote a subset of values for an object. If you don't intend to have a subset for these then please remove the SYNTAX. Please review all of these Compliance Statements with SYNTAX, only a couple are listed here: OBJECT gmplsInterfaceRsvpHelloPeriod SYNTAX Unsigned32 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirectionTC MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." OBJECT gmplsInSegmentExtraParamsPtr SYNTAX RowPointer MIN-ACCESS read-only DESCRIPTION "Write access is not required." GMPLS-LABEL-STD-MIB =================== 1) smicngPRO and smiLint flagged line 622 E: f(GMPLS-LABEL-STD-MIB), (622,6) syntax error E: f(GMPLS-LABEL-STD-MIB), (622,6) Syntax for OBJECT clause is "OBJECT" E: f(GMPLS-LABEL-STD-MIB), (518,12) Group "gmplsLabelTableGroup" is both a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB" OBJECT gmplsLabelRowStatus MIN-ACCESS read-only --> SYNTAX RowStatus { active(1) } DESCRIPTION "Support for notInService, createAndWait and notReady is not required." Need to put SYNTAX clause before MIN-ACCESS clause. 2) E: f(GMPLS-LABEL-STD-MIB), (518,12) Group "gmplsLabelTableGroup" is both a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB" The above is flagged as an error but is actually more pervasive than just this one error: both the FullCompliance and the Read-only Compliance statements have Groups listed as Mandatory but then appear as Optional. This needs to be clarified per RFC4181 "Guidelines for MIB Documents", Section 4.8. Compliance Statements. Related to this, the following groups are currently listed as Mandatory under Full compliance, but would think that these only apply if the device has certain interfaces (e.g. gmplsLabelSonetSdhGroup if Sonet interfaces are on the device), is this an Optional Group? What about these other groups? gmplsLabelPacketGroup, gmplsLabelPortWavelengthGroup, gmplsLabelFreeformGroup, gmplsLabelSonetSdhGroup, gmplsLabelWavebandGroup 3) Same comment as with the GMPLS-TE-STD-MIB wrt having an MPLS GROUP in the compliances statements. Would be most helpful to know what objects apply to MPLS. Comments in order of document. ============================== 1) Table of Contents 3. The SNMP Management Framework .................... 4 Please rename to: The Internet-Standard Management Framework 2) 1.1. Migration Strategy, 5th paragraph: the various label pointer objects in the MPLS-STD-LSR-MIB module ^^^^ Please fix: MPLS-STD-LSR-MIB to MPLS-LSR-STD-MIB 3) Please remove "and OBJECT-IDENTIFIERS" in the last paragraph Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] and [GMPLSTCMIB] ... 4) gmplsLsrModuleFullCompliance MODULE-COMPLIANCE 2 issues: a) The following 2 objects could have an MIN-ACCESS of read-only since the DEFVAL is forward. b) the DESCRIPTION is a little awkward, could this be reworded: "The only valid value for unidirectional LSPs is forward(1)." This would need to be updated in the read-only section also. (Similar comments for gmplsOutSegmentDirection). OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirectionTC MIN-ACCESS read-write DESCRIPTION "Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." OBJECT gmplsOutSegmentDirection SYNTAX GmplsSegmentDirectionTC MIN-ACCESS read-write DESCRIPTION "Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." GMPLS-LABEL-STD-MIB ======================== 5) gmplsLabelInterface and gmplsLabelIndex I had a question regarding these 2 indices: if there is a per-platform label, MUST both of these values be zero? Is there any other circumstance in which both would or could be zero? I was a little confused on the use of "could" and "may result" and was wondering if this should be made a little more forceful. 6) As previously mentioned could MPLS objects be denoted in a separate GROUP (e.g., gmplsLabelMplsLabel and possibly other objects). 7) Please put the comment in the DESCRIPTION clause of the gmplsLabelModuleFullCompliance. -- The mandatory groups have to be implemented by GMPLS LSRs -- claiming support for this MIB module. This MIB module is, -- however, not mandatory for a working implementation of a GMPLS -- LSR with full MIB support if the GMPLS labels in use can be -- represented within a 32 bit quantity. --end of comments -- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Mar 2006 05:33:53 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Y1tfrQh9kgs7kPtKcJLOPOy8rPw1yI856UDmBNF8WkIKVL7q3luFnIndS8KwtX1Z; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <01a001c647f1$dbceee60$0500a8c0@jlucianilaptop> From: To: Cc: "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" , "Tom Nadeau (E-mail)" Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-09.txt Date: Wed, 15 Mar 2006 00:32:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom and Adrian, Due to the updates to the 2 other GMPLS MIB documents wanted to re-review this document. I did have one minor comment which was the naming convention used, specifically the use of the TC on the end of the names of these Textual Conventions. GmplsFreeformLabelTC GmplsLabelTypeTC GmplsSegmentDirectionTC Could this "TC" be removed? Sorry to not catch this earlier. The reason is that this is not consistent with other Textual Conventions. Thanks, Joan Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 14 Mar 2006 17:14:22 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1691170D-2DD2-42A7-9246-2DA6D75EF2BA@cisco.com> Cc: , "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Tue, 14 Mar 2006 12:13:13 -0500 To: I will update this shortly and send you the updated version ASAP. I will send it to you directly, as the ID gate is closed right now. Also apologies for lack of compilation. I don't have SmicNG Pro working here, so all I could use was SmiLint (its a long story). --Tom > Tom and Adrian, > > Let me apologize for my tardiness in posting the > review comments. > > A great deal of work went into this latest draft. Thank you. > Compile issues are listed first, and are followed by > review comments in order of the document. > > Will have the other reviews out by tomorrow. > > Thanks, Joan > > > > Compile Issues: > =============== > > > 1) smilint and smicngPRO complained > due to REFERENCE clause for gmplsTunnelARHopTable > needing an end quote: > > gmplsTunnelARHopTable OBJECT-TYPE > ... > REFERENCE > "1. Extensions to RSVP for LSP Tunnels, RFC 3209. > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. > 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) > Management Information Base (MIB), RFC 3812. > > ^ need end quote > > ::= { gmplsTeObjects 3 } > > > 2) smicngPRO > E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf" > is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in > module "GMPLS-TE-STD-MIB" > > > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelIsIntfcGroup <-- please add this > gmplsTunnelUnnumIf <--- please remove this > } > > > Also, please update the read-only conformance for gmplsTunnelUnnumIf. > > OBJECT gmplsTunnelUnnumIf > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > 3) This is listed under compile issues because it might be > an issue depending on what is really intended. > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX clause. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsTunnelLSPEncoding > SYNTAX IANAGmplsLSPEncodingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsTunnelSwitchingType > SYNTAX IANAGmplsSwitchingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > > > SYNTAX clauses such as InetAddressType and InetAddress don't > specify a subset, so need to ask if you intend > to have a subset for these such as: > > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > > SYNTAX InetAddress (SIZE(0|4|16)) > > > 4) Again, wrt Section 4.8 from RFC4181, it is recommended > that if MIB authors intend to have Optional Groups that these > be noted. This was done for the Read-only compliance but not > the Full-compliance, so would ask that all Optional Groups be > specified as recommended by Section 4.8. Reviewing these > Compliances statements is difficult without this information. > > > > Comments: > ----------- > > 1) Table of Contents: > > 3. The SNMP Management Framework .......................... 4 > > Should be: > 3. The Internet-Standard Management Framework > In other words, please change the title for section 3. > > > 2) 5.7 Use of 32-bit and 64-bit Counters > > Shouldn't the quote from RFC2863 be in quotes""? > > 3) 6. Cross-referencing to the gmplsLabelTable > > 2nd paragraph which begins: > The hop tables in this document (gmplsHopTable, gmplsCHopTable and > gmplsARHopTable) and the segment tables in the [RFC3813] > > There is no gmplsHopTable, is this supposed to be: > gmplsTunnelHopTable? > Similar comment with gmplsCHopTable and gmplsARHopTable. > > > 4) gmplsTunnelPathComp > > If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls' > does this object have meaning? > > 5) gmplsTunnelErrorTable, would expect to see these objects > contained in an MPLS group in Compliance/Conformance Statements. > > > 6) gmplsTunnelErrorTLVs OBJECT-TYPE > > When the string size is 0 this could indicate that > no TLVs are present, right? > That would be slightly more efficient than > having to look at the first octet. > If you agree, please modify the > DESCRIPTION to reflect this. > > > Conformace/Compliance: > --------------------- > 7) Please move some of the following comment to the > gmplsTeModuleReadOnlyCompliance DESCRIPTION > -- The mandatory group has to be implemented by all LSRs that > -- originate, terminate or act as transit for TE-LSPs/tunnels. > -- In addition, depending on the type of tunnels supported, other > -- groups become mandatory as explained below. > > > 8) Already mentioned this but was expecting to see MPLS objects > called out in a separate GROUP (e.g. objects which are valid when > gmplsTunnelLSPEncoding > has a value of 'tunnelLspNotGmpls', and other objects also). > For folks that want to support these MPLS related objects > prior to supporting GMPLS, this would be > important to understand, so the more clearly noted by the MIB the > better. > > > > 9) NIT: In the read-only conformance there is a comment: > > -- All scalars have max access read-only > > which appears in front of a bunch of objects that are > part of a table. Please remove this comment since it > doesn't apply. > > 10) NIT: > > --glmpsTunnelCHopTable > > ^^ typo > > > 11) Security Section > > NIT: the network via SNMP. These are the tables and objects and > their > sensitivity/vulnerability: > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, > gmplsTunnelErrorTable collectively show the tunnel network > > > Should have an "and" > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and > > ^^^ > > gmplsTunnelErrorTable collectively show the tunnel network > > > > 12) Normative References: > [RFC4328] Papadimitriou, D., Ed., "Generalized MPLS Signalling > Extensions for G.709 Optical Transport Networks > Control", draft-ietf-ccamp-gmpls-g709, work in > progress. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please update. > > --end of comments-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 14 Mar 2006 15:54:40 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GCSN8EQkwzt+9VQAM0BCJpDnaecHhX47G+i+vPJC7i3N1DYvjb9pDgKHOtIh9cMY; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <011601c6477f$4768b160$0500a8c0@jlucianilaptop> From: To: Cc: "Wijnen, Bert (Bert)" , "Dan Romascanu (E-mail)" , "Adrian Farrel (E-mail)" , "Bill Fenner (E-mail)" , "Alex Zinin (E-mail)" , "Tom Nadeau (E-mail)" Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt Date: Tue, 14 Mar 2006 10:52:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Tom and Adrian, Let me apologize for my tardiness in posting the review comments. A great deal of work went into this latest draft. Thank you. Compile issues are listed first, and are followed by review comments in order of the document. Will have the other reviews out by tomorrow. Thanks, Joan Compile Issues: =============== 1) smilint and smicngPRO complained due to REFERENCE clause for gmplsTunnelARHopTable needing an end quote: gmplsTunnelARHopTable OBJECT-TYPE ... REFERENCE "1. Extensions to RSVP for LSP Tunnels, RFC 3209. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812. ^ need end quote ::= { gmplsTeObjects 3 } 2) smicngPRO E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf" is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in module "GMPLS-TE-STD-MIB" MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup, gmplsTunnelIsIntfcGroup <-- please add this gmplsTunnelUnnumIf <--- please remove this } Also, please update the read-only conformance for gmplsTunnelUnnumIf. OBJECT gmplsTunnelUnnumIf MIN-ACCESS read-only DESCRIPTION "Write access is not required." 3) This is listed under compile issues because it might be an issue depending on what is really intended. RFC4181 "Guidelines for MIB Documents", Section 4.8. Compliance Statements, recommends using SYNTAX clauses to denote a subset of values for an object. If you don't intend to have a subset for these then please remove the SYNTAX clause. Please review all of these Compliance Statements with SYNTAX, only a couple are listed here: OBJECT gmplsTunnelLSPEncoding SYNTAX IANAGmplsLSPEncodingType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelSwitchingType SYNTAX IANAGmplsSwitchingType MIN-ACCESS read-only DESCRIPTION "Write access is not required." SYNTAX clauses such as InetAddressType and InetAddress don't specify a subset, so need to ask if you intend to have a subset for these such as: SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } SYNTAX InetAddress (SIZE(0|4|16)) 4) Again, wrt Section 4.8 from RFC4181, it is recommended that if MIB authors intend to have Optional Groups that these be noted. This was done for the Read-only compliance but not the Full-compliance, so would ask that all Optional Groups be specified as recommended by Section 4.8. Reviewing these Compliances statements is difficult without this information. Comments: ----------- 1) Table of Contents: 3. The SNMP Management Framework .......................... 4 Should be: 3. The Internet-Standard Management Framework In other words, please change the title for section 3. 2) 5.7 Use of 32-bit and 64-bit Counters Shouldn't the quote from RFC2863 be in quotes""? 3) 6. Cross-referencing to the gmplsLabelTable 2nd paragraph which begins: The hop tables in this document (gmplsHopTable, gmplsCHopTable and gmplsARHopTable) and the segment tables in the [RFC3813] There is no gmplsHopTable, is this supposed to be: gmplsTunnelHopTable? Similar comment with gmplsCHopTable and gmplsARHopTable. 4) gmplsTunnelPathComp If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls' does this object have meaning? 5) gmplsTunnelErrorTable, would expect to see these objects contained in an MPLS group in Compliance/Conformance Statements. 6) gmplsTunnelErrorTLVs OBJECT-TYPE When the string size is 0 this could indicate that no TLVs are present, right? That would be slightly more efficient than having to look at the first octet. If you agree, please modify the DESCRIPTION to reflect this. Conformace/Compliance: --------------------- 7) Please move some of the following comment to the gmplsTeModuleReadOnlyCompliance DESCRIPTION -- The mandatory group has to be implemented by all LSRs that -- originate, terminate or act as transit for TE-LSPs/tunnels. -- In addition, depending on the type of tunnels supported, other -- groups become mandatory as explained below. 8) Already mentioned this but was expecting to see MPLS objects called out in a separate GROUP (e.g. objects which are valid when gmplsTunnelLSPEncoding has a value of 'tunnelLspNotGmpls', and other objects also). For folks that want to support these MPLS related objects prior to supporting GMPLS, this would be important to understand, so the more clearly noted by the MIB the better. 9) NIT: In the read-only conformance there is a comment: -- All scalars have max access read-only which appears in front of a bunch of objects that are part of a table. Please remove this comment since it doesn't apply. 10) NIT: --glmpsTunnelCHopTable ^^ typo 11) Security Section NIT: the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the gmplsTunnelTable, gmplsTunnelHopTable, gmplsTunnelARHopTable, gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, gmplsTunnelErrorTable collectively show the tunnel network Should have an "and" o the gmplsTunnelTable, gmplsTunnelHopTable, gmplsTunnelARHopTable, gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and ^^^ gmplsTunnelErrorTable collectively show the tunnel network 12) Normative References: [RFC4328] Papadimitriou, D., Ed., "Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control", draft-ietf-ccamp-gmpls-g709, work in progress. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please update. --end of comments-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 12 Mar 2006 11:58:11 +0000 Message-ID: <02aa01c645cc$83d09e10$57849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft agenda Date: Sun, 12 Mar 2006 11:52:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, A draft agenda is published at http://www3.ietf.org/proceedings/06mar/agenda/ccamp.html As usual, I expect that a few of you will be disappointed not to be on the agenda. We must, however, try to focus on our immediate charter items. What time remains is given over to areas of greatest discussion on the mailing list and where there is most value from handling the discussion in the face-to-face meeting. We will upload slides from the speakers as soon as we have them. I would appreciate receiving the slides no later than Tuesday 21st. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Mar 2006 19:31:36 +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: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Date: Thu, 9 Mar 2006 14:30:39 -0500 Message-ID: Thread-Topic: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Thread-Index: AcZDoKHWNRdaZ4L8R2uGobriQMg3tAAAikEw From: "Zafar Ali \(zali\)" To: Cc: , Hi Dimitri,=20 Please see comments in-line.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Sent: Thursday, March 09, 2006 12:41 PM > To: Zafar Ali (zali) > Cc: ccamp@ops.ietf.org; dpapadimitriou@psg.com > Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >=20 > hi zafar >=20 >=20 > Hi Dimitri,=20 >=20 > Please see reply in-line.=20 >=20 > Thanks >=20 > Regards... Zafar=20 >=20 > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be=20 > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Thursday, March 09, 2006 10:19 AM > > To: Zafar Ali (zali) > > Cc: ccamp@ops.ietf.org; dpapadimitriou@psg.com > > Subject: RE: I-D=20 > ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > >=20 > > hi > >=20 > > see my detailed comments in-line, the bottom line for me is=20 > that this=20 > > document tries to solve four problems at the same time=20 > while each of=20 > > them needs separate actions: > >=20 > > - the document tries to clarify the numbered FA LSP=20 > signaling (=3D RFC=20 > > 4206 > > bis) > >=20 > > - the document tries to extend mechanisms for stitchable LSP and=20 > > hierarchical LSP > >=20 > > - the document tries to define policing and utilisation rules for=20 > > these type of LSPs >=20 > What you are referring as "policy" is the Ingress node's=20 > intended treatment of the bi-directional LSP. Noticed that=20 > the assumption is that the LSP-es are dynamically signaled=20 > and flooded to either IP, MPLS or both networks. Since these=20 > LSP-es are dynamically signaled, we cannot apply a config at=20 > the Egress node. We do all that today- but with configuration=20 > knobs at the Egress node.=20 >=20 > =3D> but this part of a larger discussion than just processing=20 > of the signaling for numbered FAs, as an example why not=20 > signal the metric for the the FA link (instead of using the=20 > default rule ?), etc. this needs to be boiled down to the=20 > needs in terms of FA operations=20 >=20 I agree with you.=20 > > - the document tries to extend the inheritance process not only to=20 > > G/MPLS-TE control plane instance(s) but to IP networks >=20 > I am not sure how you deduced that.=20 >=20 > =3D> you state it in the above reply "flooded to either IP,=20 > MPLS or both networks" ... so not difficult to deduce ;-) >=20 Like I mentioned before, there are current deployments where uni-directional LSP-es are advertised into IP topology (as p2p IP links). This is, of course, done without establishing IGP adj over them. > =3D> what's more important to me is your problem statement is=20 > initially to improve signaling of numbered FA LSPs as=20 > indicated in the backward compatibility section "Indeed it=20 > was the attempt to implement numbered FAs that gave rise to=20 > the work on this document."=20 >=20 We can fix that.=20 > =3D> i am not saying that the other points should not be=20 > discussed but they should be done in a much structured way=20 > (do things right) ... provide a document that solves one=20 > issue but introduces others does not fall in this category >=20 Personally, I am open to that. =20 > =3D> see in-line >=20 > > > hi all, some comments on the problem statement of this doc: > > >=20 > > > "(2) How to identify the routing instance in which such an=20 > > > advertisement should happen." > > >=20 > > > but by definition it is the same instance when speaking=20 > about an FA=20 > > > (or are we not speaking about FA's only (?) > >=20 > > Correct, both FA and RA (Routing Adj).=20 > >=20 > > [dp] the document should clarify "RA signaling" need and issue this=20 > > tries to solve, i think it means an LSP used for carrying both data=20 > > and control traffic (in part. routing) but the question is what is=20 > > expected from this indication > >=20 >=20 > We can clearify this in the next revision. But in summary,=20 > when an LSP is signalled as an RA, the Ingress and Egress=20 > nodes brings up IGP Adjacency on top of it and flood it to=20 > the IP network. The same LSP can independently be also=20 > flooded into MPLS network (if FA bit is set).=20 >=20 > =3D> "flooded to the IP network" what do you mean in the=20 > control plane topology ? >=20 Please note that there is also pure IP data traffic, which may follow a topology different than MPLS topology (e.g., not all links are MPLS enabled, not all MPLS LSP-es are flooded to IP). If the IP network for control and data are not separated, then the answer is "yes". But in general that depends on how this GMPLS LPS is used and what IGP instance is using it.=20 > > > the previous paragraph seems to indicate this is not the case > > >=20 > > > "In order for the egress of an LSP to be able to advertise > > the LSP as > > > a TE link it needs to know that such an advertisement is > > desirable, " > > >=20 > > > ok this is a trigger issue > >=20 > > Correct, to adv or not to adv.=20 > >=20 > > [dp] yes, the question is what's the default behaviour when=20 > signaling=20 > > an FA (since the doc clarifies when an LSP is an FA the point is=20 > > what's a non advertized FA) > >=20 >=20 > Often LSP-es are created for providing a short-cut for IP=20 > traffic between the Ingress and Egress nodes. These LSP-es=20 > are NOT advertsied to the network (I.e., are NOT FA-es, and=20 > of course not RA-es). When neither FA nor RA bits are set,=20 > the LSP is NOT flooded at all. This is a non-FA case.=20 >=20 > =3D> and so why does it has to be considered in this document ? >=20 To trigger flooding or not to trigger aspect needs to addressed.=20 > If the proposed extensions are NOT used, the default is "TO=20 > FLOOD" any signaled LSP, as FA-LSP. This applies to both uni=20 > and bi-directional LSP (but there is no issue when LSP is=20 > uni-directional, as Egress may still decide NOT to flood it).=20 >=20 > =3D> nope, for unnumbered FA (bi-dir) LSP this is not the case >=20 Can you point me to the text in lsp hierarchy RFC that states that same? > > > "and it also needs to know the TE Router ID of the ingress LSR. > > > (Please recall that the Router ID of the other end of the > > link is set > > > in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA=20 > > > [RFC3630].)" > > >=20 > > > don't understand this; the Router ID is known and the TE > > router ID is > > > known as well (part of the TEDB) ... what's the purpose=20 > of this new=20 > > > requirement (as there is no TE router ID part of the=20 > corr. link TLV) > > >=20 > > > clarifications appreciated, > >=20 > > In the current signaling message, for numbered TE link it=20 > is NOT clear=20 > > where the Ingress/ Egress router-id-es are placed. > > Some implementation use extended tunnel-id field for this but again=20 > > this is not a must. So please read the above as... > >=20 > > =3D> question is WHY is there something specific here for FAs=20 > (since the=20 > > TE router ID is not part of the info in the link TLV) > >=20 > > "and (when LSP is signaled, Ingress/ Egress nodes ) also=20 > needs to know=20 > > the TE Router ID of the ingress LSR." > >=20 > > Please also see related text in the ID related to how this help in=20 > > flooding. > >=20 > > =3D> and the question is WHY - link TLV does not need such = information > >=20 > > > in general, if a clearer procedure for numbered FA > > signaling could be > > > devised that would be a good achievement, this said, i am=20 > for inst. > > > unclear about these R and F bits ... where does numbered FA > > only adv. > >=20 > > A bi-directional LSP can be adv as an FA (only in MPLS TE > > topology) or an RA (IP network) or both. These bits tells=20 > the Egress=20 > > node on what treatment is expected by the Ingress node. > >=20 > > =3D> why only in MPLS-TE topology (meaning why not TDM, LSC, etc.) ? = > >=20 > > =3D> the major question is that FAs where not meant to trigger any=20 > > routing adjacency in IP networks, this document does introduce this=20 > > now the main discussion point is not the bit in the TLV but=20 > that the=20 > > inheritance mechanism is extended to IP network topology > >=20 >=20 > BTW there are deployments where uni-directional packet LSP-es=20 > are advertised into IP topology (without establishing IGP adj=20 > over unidirectional LSP-es, of course). So I am not sure what=20 > is new here?=20 >=20 > =3D> you are not specific enough in what you mean by the "IP topology" = > within the GMPLS context for me to comment on your statement >=20 Please see my earlier comment on IP topology.=20 > =3D> but more generally one way around either nothing is needed=20 > because once setup IP adj. are brought up=20 I think you missed the point that how does Egress node know what treatment to offer to the bidirection LSP? This is not an issue for unidirectional LSP-es, hence was never an issue in earlier deployments.=20 > (nothing new here,=20 > and nothing specific to be > signaled) or you want to link the signaling operation such=20 > that the IGP instance triggers the adjacency ... my point is=20 > that you should first describe what the purpose of this=20 > instead of discussing the extension and then see what to do with it >=20 We can discuss this with you more in Dallas and provide necessary clearifications. =20 Thanks Regards... Zafar=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Mar 2006 17:41:24 +0000 To: "Zafar Ali \(zali\)" Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 9 Mar 2006 18:40:49 +0100 Content-Type: text/plain; charset="US-ASCII" hi zafar Hi Dimitri, Please see reply in-line. Thanks Regards... Zafar > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, March 09, 2006 10:19 AM > To: Zafar Ali (zali) > Cc: ccamp@ops.ietf.org; dpapadimitriou@psg.com > Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > hi > > see my detailed comments in-line, the bottom line for me is > that this document tries to solve four problems at the same > time while each of them needs separate actions: > > - the document tries to clarify the numbered FA LSP signaling > (= RFC 4206 > bis) > > - the document tries to extend mechanisms for stitchable LSP > and hierarchical LSP > > - the document tries to define policing and utilisation rules > for these type of LSPs What you are referring as "policy" is the Ingress node's intended treatment of the bi-directional LSP. Noticed that the assumption is that the LSP-es are dynamically signaled and flooded to either IP, MPLS or both networks. Since these LSP-es are dynamically signaled, we cannot apply a config at the Egress node. We do all that today- but with configuration knobs at the Egress node. => but this part of a larger discussion than just processing of the signaling for numbered FAs, as an example why not signal the metric for the the FA link (instead of using the default rule ?), etc. this needs to be boiled down to the needs in terms of FA operations > - the document tries to extend the inheritance process not > only to G/MPLS-TE control plane instance(s) but to IP networks I am not sure how you deduced that. => you state it in the above reply "flooded to either IP, MPLS or both networks" ... so not difficult to deduce ;-) => what's more important to me is your problem statement is initially to improve signaling of numbered FA LSPs as indicated in the backward compatibility section "Indeed it was the attempt to implement numbered FAs that gave rise to the work on this document." => i am not saying that the other points should not be discussed but they should be done in a much structured way (do things right) ... provide a document that solves one issue but introduces others does not fall in this category => see in-line > > hi all, some comments on the problem statement of this doc: > > > > "(2) How to identify the routing instance in which such an > > advertisement should happen." > > > > but by definition it is the same instance when speaking about an FA > > (or are we not speaking about FA's only (?) > > Correct, both FA and RA (Routing Adj). > > [dp] the document should clarify "RA signaling" need and > issue this tries to solve, i think it means an LSP used for > carrying both data and control traffic (in part. routing) but > the question is what is expected from this indication > We can clearify this in the next revision. But in summary, when an LSP is signalled as an RA, the Ingress and Egress nodes brings up IGP Adjacency on top of it and flood it to the IP network. The same LSP can independently be also flooded into MPLS network (if FA bit is set). => "flooded to the IP network" what do you mean in the control plane topology ? > > the previous paragraph seems to indicate this is not the case > > > > "In order for the egress of an LSP to be able to advertise > the LSP as > > a TE link it needs to know that such an advertisement is > desirable, " > > > > ok this is a trigger issue > > Correct, to adv or not to adv. > > [dp] yes, the question is what's the default behaviour when > signaling an FA (since the doc clarifies when an LSP is an FA > the point is what's a non advertized FA) > Often LSP-es are created for providing a short-cut for IP traffic between the Ingress and Egress nodes. These LSP-es are NOT advertsied to the network (I.e., are NOT FA-es, and of course not RA-es). When neither FA nor RA bits are set, the LSP is NOT flooded at all. This is a non-FA case. => and so why does it has to be considered in this document ? If the proposed extensions are NOT used, the default is "TO FLOOD" any signaled LSP, as FA-LSP. This applies to both uni and bi-directional LSP (but there is no issue when LSP is uni-directional, as Egress may still decide NOT to flood it). => nope, for unnumbered FA (bi-dir) LSP this is not the case > > "and it also needs to know the TE Router ID of the ingress LSR. > > (Please recall that the Router ID of the other end of the > link is set > > in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA > > [RFC3630].)" > > > > don't understand this; the Router ID is known and the TE > router ID is > > known as well (part of the TEDB) ... what's the purpose of this new > > requirement (as there is no TE router ID part of the corr. link TLV) > > > > clarifications appreciated, > > In the current signaling message, for numbered TE link it is > NOT clear where the Ingress/ Egress router-id-es are placed. > Some implementation use extended tunnel-id field for this but > again this is not a must. So please read the above as... > > => question is WHY is there something specific here for FAs > (since the TE router ID is not part of the info in the link TLV) > > "and (when LSP is signaled, Ingress/ Egress nodes ) also > needs to know the TE Router ID of the ingress LSR." > > Please also see related text in the ID related to how this > help in flooding. > > => and the question is WHY - link TLV does not need such information > > > in general, if a clearer procedure for numbered FA > signaling could be > > devised that would be a good achievement, this said, i am for inst. > > unclear about these R and F bits ... where does numbered FA > only adv. > > A bi-directional LSP can be adv as an FA (only in MPLS TE > topology) or an RA (IP network) or both. These bits tells the > Egress node on what treatment is expected by the Ingress node. > > => why only in MPLS-TE topology (meaning why not TDM, LSC, etc.) ? > > => the major question is that FAs where not meant to trigger > any routing adjacency in IP networks, this document does > introduce this now the main discussion point is not the bit > in the TLV but that the inheritance mechanism is extended to > IP network topology > BTW there are deployments where uni-directional packet LSP-es are advertised into IP topology (without establishing IGP adj over unidirectional LSP-es, of course). So I am not sure what is new here? => you are not specific enough in what you mean by the "IP topology" within the GMPLS context for me to comment on your statement => but more generally one way around either nothing is needed because once setup IP adj. are brought up (nothing new here, and nothing specific to be signaled) or you want to link the signaling operation such that the IGP instance triggers the adjacency ... my point is that you should first describe what the purpose of this instead of discussing the extension and then see what to do with it > > per RFC4206 is reproduced here ? > > No, > > > what "adv. an FA in an IP network" means ? > > The GMPLS bidirectional LSP is visible to IP topology for > inclusion in IP SPF. > > > why restrict adv. to MPLS-TE and IP networks only ? etc. > > Can you please elaborate on this? > > => this is a pure policing issue which is orthogonal to the > signaling and adv. Mechanisms Please see my earlier comment about policy. > > > imho, the issue of the trigger is part of a larger > discussion around > > FA policing ... in brief, providing a cleaner procedure for > numbered > > FA's is advisable but complexifying procedures by incorporating > > policing related actions is not advisable > > > > thanks, > > - dimitri. > > > > Internet-Drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > > > > Title : Advertisement of > hierarchical and > > stitchable Label Switched Paths as Traffic Engineering Links > > > Author(s) : K. Shiomoto, et al. > > > Filename : > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > > Pages : 17 > > > Date : 2006-3-7 > > > > > > This document addresses 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 Routing Adjacency (RA). In > addition, the > > > document also addresses 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-shiomoto-ccamp-lsp-hierarchy > > > -bis-01.txt > > > > > > To remove yourself from the I-D Announcement list, send a > > message to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of the message. > > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > > "anonymous" and a password of your e-mail address. After > logging in, > > > type "cd internet-drafts" and then > > > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > > /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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. > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Mar 2006 16:46: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: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Date: Thu, 9 Mar 2006 11:45:06 -0500 Message-ID: Thread-Topic: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Thread-Index: AcZDjOQ/MQsjDsSjTfunuJrw8wjqNQAAqY6Q From: "Zafar Ali \(zali\)" To: Cc: , Hi Dimitri,=20 Please see reply in-line.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Sent: Thursday, March 09, 2006 10:19 AM > To: Zafar Ali (zali) > Cc: ccamp@ops.ietf.org; dpapadimitriou@psg.com > Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >=20 > hi >=20 > see my detailed comments in-line, the bottom line for me is=20 > that this document tries to solve four problems at the same=20 > time while each of them needs separate actions: >=20 > - the document tries to clarify the numbered FA LSP signaling=20 > (=3D RFC 4206 > bis) >=20 > - the document tries to extend mechanisms for stitchable LSP=20 > and hierarchical LSP >=20 > - the document tries to define policing and utilisation rules=20 > for these type of LSPs >=20 What you are referring as "policy" is the Ingress node's intended treatment of the bi-directional LSP. Noticed that the assumption is that the LSP-es are dynamically signaled and flooded to either IP, MPLS or both networks. Since these LSP-es are dynamically signaled, we cannot apply a config at the Egress node. We do all that today- but with configuration knobs at the Egress node.=20 > - the document tries to extend the inheritance process not=20 > only to G/MPLS-TE control plane instance(s) but to IP networks >=20 I am not sure how you deduced that.=20 > see in-line=20 >=20 >=20 >=20 >=20 >=20 > "Zafar Ali \(zali\)" > Sent by: owner-ccamp@ops.ietf.org > 09/03/2006 15:36 > =20 > To: , Dimitri=20 > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, > cc:=20 > Subject: RE: I-D=20 > ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >=20 >=20 > Hi Dimitri,=20 >=20 > Please see reply in-lined.=20 >=20 > Thanks >=20 > Regards... Zafar=20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of dimitri papadimitriou > > Sent: Thursday, March 09, 2006 6:07 AM > > To: ccamp@ops.ietf.org > > Subject: Re: I-D=20 > ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > >=20 > > hi all, some comments on the problem statement of this doc: > >=20 > > "(2) How to identify the routing instance in which such an=20 > > advertisement should happen." > >=20 > > but by definition it is the same instance when speaking about an FA=20 > > (or are we not speaking about FA's only (?) >=20 > Correct, both FA and RA (Routing Adj).=20 >=20 > [dp] the document should clarify "RA signaling" need and=20 > issue this tries to solve, i think it means an LSP used for=20 > carrying both data and control traffic (in part. routing) but=20 > the question is what is expected from this indication >=20 We can clearify this in the next revision. But in summary, when an LSP is signalled as an RA, the Ingress and Egress nodes brings up IGP Adjacency on top of it and flood it to the IP network. The same LSP can independently be also flooded into MPLS network (if FA bit is set).=20 > > the previous paragraph seems to indicate this is not the case > >=20 > > "In order for the egress of an LSP to be able to advertise=20 > the LSP as=20 > > a TE link it needs to know that such an advertisement is=20 > desirable, " > >=20 > > ok this is a trigger issue >=20 > Correct, to adv or not to adv.=20 >=20 > [dp] yes, the question is what's the default behaviour when=20 > signaling an FA (since the doc clarifies when an LSP is an FA=20 > the point is what's a non advertized FA) > =20 Often LSP-es are created for providing a short-cut for IP traffic between the Ingress and Egress nodes. These LSP-es are NOT advertsied to the network (I.e., are NOT FA-es, and of course not RA-es). When neither FA nor RA bits are set, the LSP is NOT flooded at all. This is a non-FA case.=20 If the proposed extensions are NOT used, the default is "TO FLOOD" any signaled LSP, as FA-LSP. This applies to both uni and bi-directional LSP (but there is no issue when LSP is uni-directional, as Egress may still decide NOT to flood it).=20 > > "and it also needs to know the TE Router ID of the ingress LSR. > > (Please recall that the Router ID of the other end of the=20 > link is set=20 > > in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA=20 > > [RFC3630].)" > >=20 > > don't understand this; the Router ID is known and the TE=20 > router ID is=20 > > known as well (part of the TEDB) ... what's the purpose of this new=20 > > requirement (as there is no TE router ID part of the corr. link TLV) > >=20 > > clarifications appreciated, >=20 > In the current signaling message, for numbered TE link it is=20 > NOT clear where the Ingress/ Egress router-id-es are placed.=20 > Some implementation use extended tunnel-id field for this but=20 > again this is not a must. So please read the above as...=20 >=20 > =3D> question is WHY is there something specific here for FAs=20 > (since the TE router ID is not part of the info in the link TLV) >=20 > "and (when LSP is signaled, Ingress/ Egress nodes ) also=20 > needs to know the TE Router ID of the ingress LSR."=20 >=20 > Please also see related text in the ID related to how this=20 > help in flooding.=20 >=20 > =3D> and the question is WHY - link TLV does not need such information > =20 > > in general, if a clearer procedure for numbered FA=20 > signaling could be=20 > > devised that would be a good achievement, this said, i am for inst. > > unclear about these R and F bits ... where does numbered FA=20 > only adv. >=20 > A bi-directional LSP can be adv as an FA (only in MPLS TE=20 > topology) or an RA (IP network) or both. These bits tells the=20 > Egress node on what treatment is expected by the Ingress node.=20 >=20 > =3D> why only in MPLS-TE topology (meaning why not TDM, LSC, etc.) ?=20 >=20 > =3D> the major question is that FAs where not meant to trigger=20 > any routing adjacency in IP networks, this document does=20 > introduce this now the main discussion point is not the bit=20 > in the TLV but that the inheritance mechanism is extended to=20 > IP network topology > =20 BTW there are deployments where uni-directional packet LSP-es are advertised into IP topology (without establishing IGP adj over unidirectional LSP-es, of course). So I am not sure what is new here?=20 > > per RFC4206 is reproduced here ?=20 >=20 > No,=20 >=20 > > what "adv. an FA in an IP network" means ?=20 >=20 > The GMPLS bidirectional LSP is visible to IP topology for=20 > inclusion in IP SPF.=20 >=20 > > why restrict adv. to MPLS-TE and IP networks only ? etc. >=20 > Can you please elaborate on this?=20 >=20 > =3D> this is a pure policing issue which is orthogonal to the=20 > signaling and adv. Mechanisms Please see my earlier comment about policy.=20 >=20 > > imho, the issue of the trigger is part of a larger=20 > discussion around=20 > > FA policing ... in brief, providing a cleaner procedure for=20 > numbered=20 > > FA's is advisable but complexifying procedures by incorporating=20 > > policing related actions is not advisable > >=20 > > thanks, > > - dimitri. > >=20 > > Internet-Drafts@ietf.org wrote: > >=20 > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > >=20 > > >=20 > > > Title : Advertisement of=20 > hierarchical and=20 > > stitchable Label Switched Paths as Traffic Engineering Links > > > Author(s) : K. Shiomoto, et al. > > > Filename :=20 > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > > Pages : 17 > > > Date : 2006-3-7 > > >=20 > > > This document addresses topics related to hierarchical=20 > and stitched=20 > > > 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 Routing Adjacency (RA). In=20 > addition, the=20 > > > document also addresses the issue of how to indicate that an LSP=20 > > > should be advertised as a traffic engineering (TE) link into a=20 > > > different instance of the IGP and how to identify the=20 > instance that=20 > > > should be used. > > >=20 > > > A URL for this Internet-Draft is: > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy > > > -bis-01.txt > > >=20 > > > To remove yourself from the I-D Announcement list, send a > > message to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of the message. > > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > >=20 > > >=20 > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > > "anonymous" and a password of your e-mail address. After=20 > logging in,=20 > > > type "cd internet-drafts" and then > > > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt". > > >=20 > > > A list of Internet-Drafts directories can be found in=20 > > > http://www.ietf.org/shadow.html or=20 > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >=20 > > >=20 > > > Internet-Drafts can also be obtained by e-mail. > > >=20 > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > > /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt". > > >=20 > > > NOTE: The mail server at ietf.org can return the=20 > document in > > > MIME-encoded form by using the "mpack"=20 > utility. To use > this > > > feature, insert the command "ENCODING mime"=20 > before the > "FILE" > > > command. To decode the response(s), you will need > "munpack" or > > > a MIME-compliant mail reader. Different=20 > MIME-compliant > > mail readers > > > exhibit different behavior, especially when=20 > dealing with > > > "multipart" MIME messages (i.e. documents which have=20 > > > been > split > > > up into multiple messages), so check your local > documentation on > > > how to manipulate these messages. > > >=20 > > >=20 > > > Below is the data which will enable a MIME compliant mail reader=20 > > > implementation to automatically retrieve the ASCII version of the=20 > > > Internet-Draft. > > >=20 > > >=20 > > >=20 > > -------------------------------------------------------------- > > ---------- > > >=20 > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Mar 2006 15:24:36 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NnMtZswuxOAeH/JWK+h+VONHW76XDFAkYDOy8NkaXhmQTFxCQQZjORN5Tq8OjXAGOwux/eaei7NnDLLKp//AIYtifUl8m5HUdSTTHocuA9gPhY5iP4/SORjnSs/U7JQFIIaf5WNjZlHH5hMukgkXF7GicDvO0X/bELqaLBCxykw= ; Message-ID: <20060309152430.70249.qmail@web36806.mail.mud.yahoo.com> Date: Thu, 9 Mar 2006 07:24:30 -0800 (PST) From: Igor Bryskin Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt To: "ccamp@ops.ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2005292156-1141917870=:60822" Content-Transfer-Encoding: 8bit --0-2005292156-1141917870=:60822 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I think this is a useful document. I've also noticed quite a significant effort to improve the solution compared to the previous revision. I believe there is one aspect (which is not covered yet) that would make the document even stronger. So far we do not have a way to bundle dynamic parallel H-LSPs and advertise them as a single TE link. Note that bundling could be different depending on routing instance the TE link is advertised in. For instance, it is possible to advertise parallel H-LSPs into one routing instance as separate TE links, into another as a single TE link and into the third as several TE links (with each of them bundling two or more H-LSPs). The simple solution would be to allow assigning the same link IDs (numbered or unnumbered) by H-LSP ingresses to H-LSPs that need to be bundled before advertising into particular routing instance. If you agree with such approach, it would be good to have an abstract describing the H-LSP bundling. Thanks, Igor > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Advertisement of hierarchical and stitchable Label Switched Paths as Traffic Engineering Links > Author(s) : K. Shiomoto, et al. > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > Pages : 17 > Date : 2006-3-7 > > This document addresses 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 Routing Adjacency (RA). In > addition, the document also addresses 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-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --------------------------------- Brings words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail. --0-2005292156-1141917870=:60822 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
 
I think this is a useful document. I've also noticed quite a significant effort to improve the solution compared to the previous revision.
 
I believe there is one aspect (which is not covered yet) that would make the document even stronger. So far we do not have a way to bundle dynamic parallel H-LSPs and advertise them as a single TE link. Note that bundling could be different depending on routing instance the TE link is advertised in. For instance, it is possible to advertise parallel H-LSPs into one routing instance as separate TE links, into another as a single TE link and into the third as several TE links (with each of them bundling two or more H-LSPs).
 
The simple solution would be to allow assigning the same link IDs (numbered or unnumbered) by H-LSP ingresses to H-LSPs that need to be bundled before advertising into particular routing instance.
 
If you agree with such approach, it would be good to have an abstract describing the H-LSP bundling.
 
Thanks,
Igor
 

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Advertisement of hierarchical and stitchable Label Switched Paths as Traffic Engineering Links
> Author(s) : K. Shiomoto, et al.
> Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt
> Pages : 17
> Date : 2006-3-7
>
> This document addresses 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 Routing Adjacency (RA). In
> addition, the document also addresses 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-shiomoto-ccamp-lsp-hierarchy-bis-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce


Brings words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail. --0-2005292156-1141917870=:60822-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Mar 2006 15:20:08 +0000 To: "Zafar Ali \(zali\)" Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 9 Mar 2006 16:19:26 +0100 Content-Type: text/plain; charset="US-ASCII" hi see my detailed comments in-line, the bottom line for me is that this document tries to solve four problems at the same time while each of them needs separate actions: - the document tries to clarify the numbered FA LSP signaling (= RFC 4206 bis) - the document tries to extend mechanisms for stitchable LSP and hierarchical LSP - the document tries to define policing and utilisation rules for these type of LSPs - the document tries to extend the inheritance process not only to G/MPLS-TE control plane instance(s) but to IP networks see in-line "Zafar Ali \(zali\)" Sent by: owner-ccamp@ops.ietf.org 09/03/2006 15:36 To: , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, cc: Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Hi Dimitri, Please see reply in-lined. Thanks Regards... Zafar > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of dimitri papadimitriou > Sent: Thursday, March 09, 2006 6:07 AM > To: ccamp@ops.ietf.org > Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > hi all, some comments on the problem statement of this doc: > > "(2) How to identify the routing instance in which such an > advertisement should happen." > > but by definition it is the same instance when speaking about > an FA (or are we not speaking about FA's only (?) Correct, both FA and RA (Routing Adj). [dp] the document should clarify "RA signaling" need and issue this tries to solve, i think it means an LSP used for carrying both data and control traffic (in part. routing) but the question is what is expected from this indication > the previous paragraph seems to indicate this is not the case > > "In order for the egress of an LSP to be able to advertise > the LSP as a TE link it needs to know that such an > advertisement is desirable, " > > ok this is a trigger issue Correct, to adv or not to adv. [dp] yes, the question is what's the default behaviour when signaling an FA (since the doc clarifies when an LSP is an FA the point is what's a non advertized FA) > "and it also needs to know the TE Router ID of the ingress LSR. > (Please recall that the Router ID of the other end of the > link is set in the Link-ID sub-TLV of the Link TLV of the TE > Opaque-LSA [RFC3630].)" > > don't understand this; the Router ID is known and the TE > router ID is known as well (part of the TEDB) ... what's the > purpose of this new requirement (as there is no TE router ID > part of the corr. link TLV) > > clarifications appreciated, In the current signaling message, for numbered TE link it is NOT clear where the Ingress/ Egress router-id-es are placed. Some implementation use extended tunnel-id field for this but again this is not a must. So please read the above as... => question is WHY is there something specific here for FAs (since the TE router ID is not part of the info in the link TLV) "and (when LSP is signaled, Ingress/ Egress nodes ) also needs to know the TE Router ID of the ingress LSR." Please also see related text in the ID related to how this help in flooding. => and the question is WHY - link TLV does not need such information > in general, if a clearer procedure for numbered FA signaling > could be devised that would be a good achievement, this said, > i am for inst. > unclear about these R and F bits ... where does numbered FA only adv. A bi-directional LSP can be adv as an FA (only in MPLS TE topology) or an RA (IP network) or both. These bits tells the Egress node on what treatment is expected by the Ingress node. => why only in MPLS-TE topology (meaning why not TDM, LSC, etc.) ? => the major question is that FAs where not meant to trigger any routing adjacency in IP networks, this document does introduce this now the main discussion point is not the bit in the TLV but that the inheritance mechanism is extended to IP network topology > per RFC4206 is reproduced here ? No, > what "adv. an FA in an IP network" means ? The GMPLS bidirectional LSP is visible to IP topology for inclusion in IP SPF. > why restrict adv. to MPLS-TE and IP networks only ? etc. Can you please elaborate on this? => this is a pure policing issue which is orthogonal to the signaling and adv. mechanisms > imho, the issue of the trigger is part of a larger discussion > around FA policing ... in brief, providing a cleaner > procedure for numbered FA's is advisable but complexifying > procedures by incorporating policing related actions is not advisable > > thanks, > - dimitri. > > Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : Advertisement of hierarchical and > stitchable Label Switched Paths as Traffic Engineering Links > > Author(s) : K. Shiomoto, et al. > > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > Pages : 17 > > Date : 2006-3-7 > > > > This document addresses 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 Routing Adjacency (RA). In addition, the > > document also addresses 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-shiomoto-ccamp-lsp-hierarchy > > -bis-01.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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. > > > > > > > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Mar 2006 14:37:30 +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: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Date: Thu, 9 Mar 2006 09:36:18 -0500 Message-ID: Thread-Topic: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Thread-Index: AcZDahNxIIo0+la1T/qetumiZyqnswAGwirg From: "Zafar Ali \(zali\)" To: , , Hi Dimitri,=20 Please see reply in-lined.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of dimitri papadimitriou > Sent: Thursday, March 09, 2006 6:07 AM > To: ccamp@ops.ietf.org > Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >=20 > hi all, some comments on the problem statement of this doc: >=20 > "(2) How to identify the routing instance in which such an=20 > advertisement should happen." >=20 > but by definition it is the same instance when speaking about=20 > an FA (or are we not speaking about FA's only (?) Correct, both FA and RA (Routing Adj).=20 > the=20 > previous paragraph seems to indicate this is not the case >=20 > "In order for the egress of an LSP to be able to advertise=20 > the LSP as a TE link it needs to know that such an=20 > advertisement is desirable, " >=20 > ok this is a trigger issue Correct, to adv or not to adv.=20 >=20 > "and it also needs to know the TE Router ID of the ingress LSR. > (Please recall that the Router ID of the other end of the=20 > link is set in the Link-ID sub-TLV of the Link TLV of the TE=20 > Opaque-LSA [RFC3630].)" >=20 > don't understand this; the Router ID is known and the TE=20 > router ID is known as well (part of the TEDB) ... what's the=20 > purpose of this new requirement (as there is no TE router ID=20 > part of the corr. link TLV) >=20 > clarifications appreciated, In the current signaling message, for numbered TE link it is NOT clear where the Ingress/ Egress router-id-es are placed. Some implementation use extended tunnel-id field for this but again this is not a must. So please read the above as...=20 "and (when LSP is signaled, Ingress/ Egress nodes ) also needs to know the TE Router ID of the ingress LSR."=20 Please also see related text in the ID related to how this help in flooding. =20 >=20 > in general, if a clearer procedure for numbered FA signaling=20 > could be devised that would be a good achievement, this said,=20 > i am for inst.=20 > unclear about these R and F bits ... where does numbered FA only adv. A bi-directional LSP can be adv as an FA (only in MPLS TE topology) or an RA (IP network) or both. These bits tells the Egress node on what treatment is expected by the Ingress node.=20 =20 > per RFC4206 is reproduced here ?=20 No,=20 > what "adv. an FA in an IP network"=20 > means ?=20 The GMPLS bidirectional LSP is visible to IP topology for inclusion in IP SPF.=20 > why restrict adv. to MPLS-TE and IP networks only ? etc. Can you please elaborate on this?=20 >=20 > imho, the issue of the trigger is part of a larger discussion=20 > around FA policing ... in brief, providing a cleaner=20 > procedure for numbered FA's is advisable but complexifying=20 > procedures by incorporating policing related actions is not advisable >=20 > thanks, > - dimitri. >=20 > Internet-Drafts@ietf.org wrote: >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > >=20 > >=20 > > Title : Advertisement of hierarchical and=20 > stitchable Label Switched Paths as Traffic Engineering Links > > Author(s) : K. Shiomoto, et al. > > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > Pages : 17 > > Date : 2006-3-7 > > =09 > > This document addresses topics related to hierarchical and stitched=20 > > Generalized Multiprotocol Label Switching (GMPLS) Label=20 > Switched Paths=20 > > (LSPs). It describes extensions to allow an egress to=20 > identify that a=20 > > bi-directional LSP will be used as a dynamically signaled=20 > Forwarding=20 > > Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In addition, the=20 > > document also addresses the issue of how to indicate that an LSP=20 > > should be advertised as a traffic engineering (TE) link into a=20 > > different instance of the IGP and how to identify the instance that=20 > > should be used. > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy > > -bis-01.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > >=20 > > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt". > >=20 > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html=20 > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE=20 > /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt". > > =09 > > 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=20 > 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. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Mar 2006 12:14:22 +0000 Message-ID: <44101BE6.9000606@telecom.lth.se> Date: Thu, 09 Mar 2006 13:13:26 +0100 From: Faisal Aslam User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Inter-Domain Topology Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I am working on simulation study of inter-domain path computation algorithms. I need a big inter-domain topology, that has more than 10 domains and each domain has many nodes. It will be great to have some real world or logical topology. I will appreciate any help in this regard. Thank you, Faisal Aslam Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Mar 2006 11:09:40 +0000 Message-ID: <44100C71.8080706@psg.com> Date: Thu, 09 Mar 2006 12:07:29 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: "ccamp@ops.ietf.org" Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi all, some comments on the problem statement of this doc: "(2) How to identify the routing instance in which such an advertisement should happen." but by definition it is the same instance when speaking about an FA (or are we not speaking about FA's only (?) the previous paragraph seems to indicate this is not the case "In order for the egress of an LSP to be able to advertise the LSP as a TE link it needs to know that such an advertisement is desirable, " ok this is a trigger issue "and it also needs to know the TE Router ID of the ingress LSR. (Please recall that the Router ID of the other end of the link is set in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA [RFC3630].)" don't understand this; the Router ID is known and the TE router ID is known as well (part of the TEDB) ... what's the purpose of this new requirement (as there is no TE router ID part of the corr. link TLV) clarifications appreciated, in general, if a clearer procedure for numbered FA signaling could be devised that would be a good achievement, this said, i am for inst. unclear about these R and F bits ... where does numbered FA only adv. per RFC4206 is reproduced here ? what "adv. an FA in an IP network" means ? why restrict adv. to MPLS-TE and IP networks only ? etc. imho, the issue of the trigger is part of a larger discussion around FA policing ... in brief, providing a cleaner procedure for numbered FA's is advisable but complexifying procedures by incorporating policing related actions is not advisable thanks, - dimitri. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Advertisement of hierarchical and stitchable Label Switched Paths as Traffic Engineering Links > Author(s) : K. Shiomoto, et al. > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > Pages : 17 > Date : 2006-3-7 > > This document addresses 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 Routing Adjacency (RA). In > addition, the document also addresses 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-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-shiomoto-ccamp-lsp-hierarchy-bis-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: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 Mar 2006 07:51:20 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt Message-Id: Date: Wed, 08 Mar 2006 02:50:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Node ID based RSVP Hello: A Clarification Statement Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt Pages : 7 Date : 2006-3-7 Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, and when TE links are unnumbered. Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. When link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). The use of Node-ID based Hello session is optimal in the sense that as long as there is IP reachability to the nieghbor (node-id), the signalling adjacency will remain up. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-7203101.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7203101.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 Mar 2006 19:30:32 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Protocol Action: 'Node ID based RSVP Hello: A Clarification Statement' to Proposed Standard Message-Id: Date: Tue, 07 Mar 2006 14:28:31 -0500 The IESG has approved the following document: - 'Node ID based RSVP Hello: A Clarification Statement ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Technical Summary Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. Working Group Summary The WG had consensus on progressing this document. Protocol Quality The document has been reviewed for the IESG by Alex Zinin. Note to RFC Editor Abstract Delete "as a best current practice (BCP)" as follows... OLD Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. NEW Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Mar 2006 20:51:11 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-03.txt Message-Id: Date: Mon, 06 Mar 2006 15:50:03 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Inter domain GMPLS Traffic Engineering - RSVP-TE extensions Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ietf-ccamp-inter-domain-rsvp-te-03.txt Pages : 24 Date : 2006-3-6 This document describes extensions to Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support mechanisms for the establishment and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs), both packet and non-packet, that traverse multiple domains. 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, IGP areas and GMPLS overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-rsvp-te-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-6134446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-rsvp-te-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6134446.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Mar 2006 20:51:04 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-03.txt Message-Id: Date: Mon, 06 Mar 2006 15:50:03 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Label Switched Path Stitching with Generalized MPLS Traffic Engineering Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ietf-ccamp-lsp-stitching-03.txt Pages : 20 Date : 2005-9-23 In certain scenarios, there may be a need to combine together different Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that in the data plane, a single end-to- end (e2e) LSP is realized and all traffic from one LSP is switched onto the other LSP. We will refer to this as "LSP stitching". This document covers cases where: a) the node performing the stitching does not require configuration of every LSP pair to be stitched together b) the node performing the stitching is not the egress of any of the LSPs c) LSP stitching not only results in an end-to-end LSP in the data plane, but there is also a corresponding end-to-end LSP (RSVP session) in the control plane. 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, 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-lsp-stitching-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-6134231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-stitching-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6134231.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Mar 2006 17:34:30 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AogsDXZKbC6bz1nfKP6L53bG2iGz+UATU6EpW7N1rWUoyTNlVG210N1GUSepHlWw; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <027601c64143$af8e7140$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , Cc: "Wijnen, Bert (Bert)" , "Thomas D. Nadeau" , , "Bill Fenner" Subject: Re: New revision of GMPLS TE MIB Date: Mon, 6 Mar 2006 12:30:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Adrian and Tom! Will take a look at all 3 of the MIBs and give update by end of this week. Thanks, Joan ----- Original Message ----- From: Adrian Farrel To: Cc: Joan Cucchiara ; Wijnen, Bert (Bert) ; Thomas D. Nadeau ; ; Bill Fenner Sent: Friday, March 03, 2006 1:17 PM Subject: New revision of GMPLS TE MIB > Hi, > > I have just submitted a new revision of the GMPLS TE MIB > (draft-ietf-ccamp-gmpls-te-mib-13.txt) which should be posted soon. > > The changes are to complete the markups from MIB Doctor review and > comprise changes to the conformance and compliance sections of the MIB > module as requested. > > I have also made the following changes: > - added comments to IANAGmplsGeneralizedPid to highlight the lacunae. > - updated references to RFC 4328 > - correct possible settings of mplsTunnelIsIf which is TruthValue > - retire gmplsTunnelIsNotIntfcGroup which had become empty > - correct the example to use gmplsTunnelSendPathNotifyRecipientType > and gmplsTunnelSendPathNotifyRecipient > - correct the hex value of an IP address in the example > > We will show this to the MIB Doctors to check that they are happy with all > of our changes, and then get the IESG process into motion. > > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Mar 2006 07:50:53 +0000 To: "Zafar Ali \(zali\)" Cc: "Adrian Farrel" , "Anca Zamfir \(ancaz\)" , ccamp@ops.ietf.org, dpapadimitriou@psg.com, "Jean Philippe Vasseur \(jvasseur\)" , "Kireeti Kompella" , owner-ccamp@ops.ietf.org, "Zafar Ali \(zali\)" Subject: RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 6 Mar 2006 08:48:11 +0100 Content-Type: text/plain; charset="US-ASCII" hi zafar planned restart and shutdown may indeed involve non fully overlapping operations but there is nothing that mandates from this that the IGP should make use of different procedures from preventing other nodes to use the links that will become unusable (shutting down TE links is a subset of the implied operations of a planned restart ... this said, section 3 of your document also mentions shutdown of an entire node) your section should be adapted such as to detail when this new procedure would be advisable leaving the existing procedures unaffected and applicable much thanks, - dimitri. "Zafar Ali \(zali\)" Sent by: owner-ccamp@ops.ietf.org 06/03/2006 05:36 To: "Zafar Ali \(zali\)" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Adrian Farrel" , "Anca Zamfir \(ancaz\)" , , , "Jean Philippe Vasseur \(jvasseur\)" , "Kireeti Kompella" , Subject: RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) < Attachment draft-ali-ccamp-mpls-graceful-shutdown-03.txt removed > Dimitri, We are planning to sending the enclosed version before the flood gate closes. The use of link attribute subTLV is stated as completely optional. Please find the following text in enclosed updated version. "to deal with nodes not compliant with this document (i.e., does not implement link attribute sub-TLV based solution), the node initiating graceful shutdown MAY originate the TE LSA/LSP containing Link TLV with 0 unreserved bandwidth, Traffic Engineering metric set to 0xffffffff, and if the Link is non-PSC then also with 0 as Max LSP Bandwidth." Thanks Regards... Zafar > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) > Sent: Sunday, March 05, 2006 1:02 PM > To: Dimitri.Papadimitriou@alcatel.be > Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org; > dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur); > Kireeti Kompella; owner-ccamp@ops.ietf.org > Subject: RE: Need to close on signaling solution for graceful > shutdown (Follow-up on our Action Item) > > Hi Dimitri, > > There is a difference between expected operations in graceful > restart and graceful shutdown; hence my previous email. The > draft already lists Max Metric as a possible solution with > motivation for selecting link attribute based solution. If > the WG agrees that use of Max Metric suffices, we can fall > back to the use of the Max Metric/ zero bw. We will be > posting an updated version later tonight. > > Thanks > > Regards... Zafar > > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Friday, March 03, 2006 6:46 PM > > To: Zafar Ali (zali) > > Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org; > > dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur); Kireeti > > Kompella; owner-ccamp@ops.ietf.org > > Subject: RE: Need to close on signaling solution for > graceful shutdown > > (Follow-up on our Action Item) > > > > hi zafar > > > > then i will express my concern in the other way around > concerning the > > "routing" part of this document: we have clean procedures > for planned > > node restart in RFC4203; hence, the reason for having a "cleaner" > > procedure is totally unclear to me both in terms of motivation and > > applicability > > > > much thanks, > > - dimitri. > > > > > > > > > > > > > > > > > > "Zafar Ali \(zali\)" > > Sent by: owner-ccamp@ops.ietf.org > > 02/03/2006 07:06 > > > > To: , Dimitri > > PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: , "Adrian Farrel" > > , "Anca Zamfir \(ancaz\)" > > , "Jean Philippe Vasseur \(jvasseur\)" > > , "Kireeti Kompella" > > > > Subject: RE: Need to close on signaling solution for > > graceful shutdown (Follow-up on our Action Item) > > > > > > Hi Dimitri, > > > > Sorry for the delay in replying. Please see reply in-line. > > > > All, > > > > I am assuming the WG is ok with the signaling part of the > solution. If > > you have any comments, please reply to my original email. > We plan to > > refresh the ID before the flood gate closes. > > > > Thanks > > > > Regards... Zafar > > > > > -----Original Message----- > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > Sent: Monday, February 20, 2006 2:01 AM > > > To: Zafar Ali (zali) > > > Cc: ccamp@ops.ietf.org; Adrian Farrel; Anca Zamfir (ancaz); Jean > > > Philippe Vasseur (jvasseur); Kireeti Kompella > > > Subject: Re: Need to close on signaling solution for graceful > > > shutdown (Follow-up on our Action Item) > > > > > > > > > zafar - thanks for the summary ... but i don't understand the > > > following sentence > > > > > > "The IGP based solution is also based on an existing framework." > > > > > > to which framework are you referring to ? > > > > > > i am more concerned with section 4.2, for three reasons > > > > > > o) the document seems to say that such links could be > used as last > > > resort link for zero bandwidth LSP - note that this > applies only to > > > PSC links because non-PSC would not make use of such > links - let's > > > assume this may be the case, as you are dealing with a "planned > > > outage" i am not sure you are going to make a lot of > operations such > > > as new path computations during such event (and risk further > > > degradation) > > > > > > > A link may end-up with max metric for multiple reasons and > without the > > link attribute there is no way a node can tell what the reason is, > > e.g. > > a restarting node may advertises the max matrices. > Furthermore, if the > > resource under graceful deletion is the last resort then the node > > hosting the graceful deletion resource will not receive new > signaling > > messages. Also, graceful deletion is not the main > motivation for the > > introduction of the link attribute sub-TLV; we are just overloading > > the use of link attribute to provide a cleaner > specification. Hence, I > > mention "existing framework". We can enhance the text in > the ID to be > > more specific in this notification. > > > > > o) the document makes use of a link attribute (but where is this > > > attribute defined ?) > > > > > > > The link attribute ID-es needs to be refreshed. > > > > > o) this section forces to have to have two different > procedures (as > > > planned restarting nodes advertise their link with these > attributes > > > making them unusable before the restart occurs, section 2 of > > > RFC4203) > > > > > > > See my comment above. > > > > > thanks, > > > - dimitri. > > > > > > > > > Zafar Ali (zali) wrote: > > > > > > > Dear Ccampers: > > > > > > > > > > > > > > > > This is a follow-up on our action item from the last IETF > > > meeting to > > > > send an email to close the signaling solution for > > graceful shutdown > > > > procedure proposed in > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > > > do > > > > wn-02.txt > > > > > > > > > > > > > td > > > > own-02.txt> . > > > > > > > > > > > > > > > > During the meeting it was clear that we have an > agreement on the > > > > requirement front. We also have an agreement that we need > > > both routing > > > > and signaling based solutions. This is because an IGP > only based > > > > solution is not applicable when dealing with Inter-area and > > > Inter-AS > > > > traffic engineering, as LSA or LSP flooding is > restricted to IGP > > > > areas/levels. Consequently, RSVP based mechanisms are > > > required to cope > > > > with TE LSPs spanning multiple domains. The draft presents > > > > complementary mechanisms for RSVP-TE and IGP for Graceful > > Shutdown. > > > > The IGP based solution is also based on an existing > > framework. Our > > > > action item is to close on the signaling based counterpart. > > > > > > > > > > > > > > > > Before we compare the candidate solution, let's discuss and > > > agree on > > > > general requirement for a signaling based graceful shutdown > > > mechanism. > > > > In graceful shutdown procedure, as the Ingress LSR is > expected to > > > > perform make-before-break for the LSP (using the > resource that is > > > > being shutdown), we should be able to specify the TE > > > resource (link/ > > > > node) under graceful shutdown. Furthermore, conveying > signaling > > > > message to the Ingress LSR suffices. I.e., we can make use > > > of the Notify Message. > > > > > > > > > > > > > > > > One of the solutions proposed during these discussions is > > > to make use > > > > of the admin status object. However, admin status > cannot contain > > > > information about TE resource under Graceful Shutdown. > > > Hence, we did > > > > not consider use of admin status object as a possible solution. > > > > > > > > > > > > > > > > Another alternate that was put forward is the use ALARM_ > > > SPEC Objects. > > > > While ALARM_ SPEC Objects has ability to Signal Info about > > > TE resource > > > > under Graceful shutdown, use of this object in the notify > > > message is > > > > not defined. We also feel use of the ALARM_ SPEC Objects is > > > heavy duty > > > > for signaling simple Graceful Shutdown condition. > > > > > > > > > > > > > > > > We propose to overload "TE link maintenance required" > > > sub-code of the > > > > Notify Error Code (24) of the ERROR_SPEC. We believe > this is the > > > > simplest solution with existing/ well used way to signal > > > information > > > > about TE resource under Graceful Shutdown. Furthermore, the > > > ERROR_SPEC > > > > with code 24/ sub-code TBD can then be carried in either > > PathErr or > > > > Notify message to signal graceful condition. > > > > > > > > > > > > > > > > Can you please send your comments to this by the end of > > > this week so > > > > we can update the ID, if needed? > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Regards... Zafar > > > > > > > > This is a follow-up on our action item from the last IETF > > > meeting to > > > > send an email to close the signaling solution for > > graceful shutdown > > > > procedure proposed in > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > > > do > > > > wn-02.txt. > > > > > > > > > > > > > > > > During the meeting it was clear that we have an > agreement on the > > > > requirement front. We also have an agreement that we need > > > both routing > > > > and signaling based solutions. This is because an IGP > only based > > > > solution is not applicable when dealing with Inter-area and > > > Inter-AS > > > > traffic engineering, as LSA or LSP flooding is > restricted to IGP > > > > areas/levels. Consequently, RSVP based mechanisms are > > > required to cope > > > > with TE LSPs spanning multiple domains. The draft presents > > > > complementary mechanisms for RSVP-TE and IGP for Graceful > > Shutdown. > > > > The IGP based solution is also based on an existing > > framework. Our > > > > action item is to close on the signaling based counterpart. > > > > > > > > > > > > > > > > Before we compare the candidate solution, let's discuss and > > > agree on > > > > general requirement for a signaling based graceful shutdown > > > mechanism. > > > > In graceful shutdown procedure, as the Ingress LSR is > expected to > > > > perform make-before-break for the LSP (using the > resource that is > > > > being shutdown), we should be able to specify the TE > > > resource (link/ > > > > node) under graceful shutdown. Furthermore, conveying > signaling > > > > message to the Ingress LSR suffices. I.e., we can make use > > > of the Notify Message. > > > > > > > > > > > > > > > > One of the solutions proposed during these discussions is > > > to make use > > > > of the admin status object. However, admin status > cannot contain > > > > information about TE resource under Graceful Shutdown. > > > Hence, we did > > > > not consider use of admin status object as a possible solution. > > > > > > > > > > > > > > > > Another alternate that was put forward is the use ALARM_ > > > SPEC Objects. > > > > While ALARM_ SPEC Objects has ability to Signal Info about > > > TE resource > > > > under Graceful shutdown, use of this object in the notify > > > message is > > > > not defined. We also feel use of the ALARM_ SPEC Objects is > > > heavy duty > > > > for signaling simple Graceful Shutdown condition. > > > > > > > > > > > > > > > > We propose to overload "TE link maintenance required" > > > sub-code of the > > > > Notify Error Code (24) of the ERROR_SPEC. We believe > this is the > > > > simplest solution with existing/ well used way to signal > > > information > > > > about TE resource under Graceful Shutdown. Furthermore, the > > > ERROR_SPEC > > > > with code 24/ sub-code TBD can then be carried in either > > PathErr or > > > > Notify message to signal graceful condition. > > > > > > > > > > > > > > > > Can you please send your comments to this by the end of > > > this week so > > > > we can update the ID, if needed? > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Regards... Zafar > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Mar 2006 04:37:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C640D7.79CEB815" Subject: RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) Date: Sun, 5 Mar 2006 23:36:03 -0500 Message-ID: Thread-Topic: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) Thread-Index: AcY/HKmSPjLGK8drTVqiRXGv4DsJhwBTEnJQAAdnWCA= From: "Zafar Ali \(zali\)" To: "Zafar Ali \(zali\)" , Cc: "Adrian Farrel" , "Anca Zamfir \(ancaz\)" , , , "Jean Philippe Vasseur \(jvasseur\)" , "Kireeti Kompella" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C640D7.79CEB815 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dimitri,=20 We are planning to sending the enclosed version before the flood gate closes. The use of link attribute subTLV is stated as completely optional. Please find the following text in enclosed updated version.=20 "to deal with nodes not compliant with this document (i.e., does not implement link attribute sub-TLV based solution), the node initiating graceful shutdown MAY originate the TE LSA/LSP containing Link TLV with 0 unreserved bandwidth, Traffic Engineering metric set to 0xffffffff, and if the Link is non-PSC then also with 0 as Max LSP Bandwidth." =20 Thanks Regards... Zafar=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) > Sent: Sunday, March 05, 2006 1:02 PM > To: Dimitri.Papadimitriou@alcatel.be > Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org;=20 > dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur);=20 > Kireeti Kompella; owner-ccamp@ops.ietf.org > Subject: RE: Need to close on signaling solution for graceful=20 > shutdown (Follow-up on our Action Item) >=20 > Hi Dimitri,=20 >=20 > There is a difference between expected operations in graceful=20 > restart and graceful shutdown; hence my previous email. The=20 > draft already lists Max Metric as a possible solution with=20 > motivation for selecting link attribute based solution. If=20 > the WG agrees that use of Max Metric suffices, we can fall=20 > back to the use of the Max Metric/ zero bw. We will be=20 > posting an updated version later tonight.=20 >=20 > Thanks >=20 > Regards... Zafar =20 >=20 > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be=20 > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Friday, March 03, 2006 6:46 PM > > To: Zafar Ali (zali) > > Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org;=20 > > dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur); Kireeti=20 > > Kompella; owner-ccamp@ops.ietf.org > > Subject: RE: Need to close on signaling solution for=20 > graceful shutdown=20 > > (Follow-up on our Action Item) > >=20 > > hi zafar > >=20 > > then i will express my concern in the other way around=20 > concerning the=20 > > "routing" part of this document: we have clean procedures=20 > for planned=20 > > node restart in RFC4203; hence, the reason for having a "cleaner"=20 > > procedure is totally unclear to me both in terms of motivation and=20 > > applicability > >=20 > > much thanks, > > - dimitri. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > "Zafar Ali \(zali\)" > > Sent by: owner-ccamp@ops.ietf.org > > 02/03/2006 07:06 > > =20 > > To: , Dimitri=20 > > PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: , "Adrian Farrel"=20 > > , "Anca Zamfir \(ancaz\)"=20 > > , "Jean Philippe Vasseur \(jvasseur\)"=20 > > , "Kireeti Kompella"=20 > > > > Subject: RE: Need to close on signaling solution for=20 > > graceful shutdown (Follow-up on our Action Item) > >=20 > >=20 > > Hi Dimitri, > >=20 > > Sorry for the delay in replying. Please see reply in-line.=20 > >=20 > > All, > >=20 > > I am assuming the WG is ok with the signaling part of the=20 > solution. If=20 > > you have any comments, please reply to my original email.=20 > We plan to=20 > > refresh the ID before the flood gate closes. > >=20 > > Thanks > >=20 > > Regards... Zafar > >=20 > > > -----Original Message----- > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > Sent: Monday, February 20, 2006 2:01 AM > > > To: Zafar Ali (zali) > > > Cc: ccamp@ops.ietf.org; Adrian Farrel; Anca Zamfir (ancaz); Jean=20 > > > Philippe Vasseur (jvasseur); Kireeti Kompella > > > Subject: Re: Need to close on signaling solution for graceful=20 > > > shutdown (Follow-up on our Action Item) > > >=20 > > >=20 > > > zafar - thanks for the summary ... but i don't understand the=20 > > > following sentence > > >=20 > > > "The IGP based solution is also based on an existing framework." > > >=20 > > > to which framework are you referring to ? > > >=20 > > > i am more concerned with section 4.2, for three reasons > > >=20 > > > o) the document seems to say that such links could be=20 > used as last=20 > > > resort link for zero bandwidth LSP - note that this=20 > applies only to=20 > > > PSC links because non-PSC would not make use of such=20 > links - let's=20 > > > assume this may be the case, as you are dealing with a "planned=20 > > > outage" i am not sure you are going to make a lot of=20 > operations such=20 > > > as new path computations during such event (and risk further=20 > > > degradation) > > >=20 > >=20 > > A link may end-up with max metric for multiple reasons and=20 > without the=20 > > link attribute there is no way a node can tell what the reason is,=20 > > e.g. > > a restarting node may advertises the max matrices.=20 > Furthermore, if the=20 > > resource under graceful deletion is the last resort then the node=20 > > hosting the graceful deletion resource will not receive new=20 > signaling=20 > > messages. Also, graceful deletion is not the main=20 > motivation for the=20 > > introduction of the link attribute sub-TLV; we are just overloading=20 > > the use of link attribute to provide a cleaner=20 > specification. Hence, I=20 > > mention "existing framework". We can enhance the text in=20 > the ID to be=20 > > more specific in this notification. > >=20 > > > o) the document makes use of a link attribute (but where is this=20 > > > attribute defined ?) > > >=20 > >=20 > > The link attribute ID-es needs to be refreshed.=20 > >=20 > > > o) this section forces to have to have two different=20 > procedures (as=20 > > > planned restarting nodes advertise their link with these=20 > attributes=20 > > > making them unusable before the restart occurs, section 2 of=20 > > > RFC4203) > > >=20 > >=20 > > See my comment above.=20 > >=20 > > > thanks, > > > - dimitri. > > >=20 > > >=20 > > > Zafar Ali (zali) wrote: > > >=20 > > > > Dear Ccampers: > > > >=20 > > > >=20 > > > >=20 > > > > This is a follow-up on our action item from the last IETF > > > meeting to > > > > send an email to close the signaling solution for > > graceful shutdown > > > > procedure proposed in > > > >=20 > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > > > do > > > > wn-02.txt > > > >=20 > > >=20 > >=20 > > > > td > > > > own-02.txt> .=20 > > > >=20 > > > >=20 > > > >=20 > > > > During the meeting it was clear that we have an=20 > agreement on the=20 > > > > requirement front. We also have an agreement that we need > > > both routing > > > > and signaling based solutions. This is because an IGP=20 > only based=20 > > > > solution is not applicable when dealing with Inter-area and > > > Inter-AS > > > > traffic engineering, as LSA or LSP flooding is=20 > restricted to IGP=20 > > > > areas/levels. Consequently, RSVP based mechanisms are > > > required to cope > > > > with TE LSPs spanning multiple domains. The draft presents=20 > > > > complementary mechanisms for RSVP-TE and IGP for Graceful > > Shutdown.=20 > > > > The IGP based solution is also based on an existing > > framework. Our > > > > action item is to close on the signaling based counterpart. > > > >=20 > > > >=20 > > > >=20 > > > > Before we compare the candidate solution, let's discuss and > > > agree on > > > > general requirement for a signaling based graceful shutdown > > > mechanism. > > > > In graceful shutdown procedure, as the Ingress LSR is=20 > expected to=20 > > > > perform make-before-break for the LSP (using the=20 > resource that is=20 > > > > being shutdown), we should be able to specify the TE > > > resource (link/ > > > > node) under graceful shutdown. Furthermore, conveying=20 > signaling=20 > > > > message to the Ingress LSR suffices. I.e., we can make use > > > of the Notify Message. > > > >=20 > > > >=20 > > > >=20 > > > > One of the solutions proposed during these discussions is > > > to make use > > > > of the admin status object. However, admin status=20 > cannot contain=20 > > > > information about TE resource under Graceful Shutdown. > > > Hence, we did > > > > not consider use of admin status object as a possible solution. > > > >=20 > > > >=20 > > > >=20 > > > > Another alternate that was put forward is the use ALARM_ > > > SPEC Objects. > > > > While ALARM_ SPEC Objects has ability to Signal Info about > > > TE resource > > > > under Graceful shutdown, use of this object in the notify > > > message is > > > > not defined. We also feel use of the ALARM_ SPEC Objects is > > > heavy duty > > > > for signaling simple Graceful Shutdown condition. > > > >=20 > > > >=20 > > > >=20 > > > > We propose to overload "TE link maintenance required"=20 > > > sub-code of the > > > > Notify Error Code (24) of the ERROR_SPEC. We believe=20 > this is the=20 > > > > simplest solution with existing/ well used way to signal > > > information > > > > about TE resource under Graceful Shutdown. Furthermore, the > > > ERROR_SPEC > > > > with code 24/ sub-code TBD can then be carried in either > > PathErr or > > > > Notify message to signal graceful condition. > > > >=20 > > > >=20 > > > >=20 > > > > Can you please send your comments to this by the end of > > > this week so > > > > we can update the ID, if needed? > > > >=20 > > > >=20 > > > >=20 > > > > Thanks > > > >=20 > > > >=20 > > > >=20 > > > > Regards... Zafar > > > >=20 > > > > This is a follow-up on our action item from the last IETF > > > meeting to > > > > send an email to close the signaling solution for > > graceful shutdown > > > > procedure proposed in > > > >=20 > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > > > do > > > > wn-02.txt.=20 > > > >=20 > > > >=20 > > > >=20 > > > > During the meeting it was clear that we have an=20 > agreement on the=20 > > > > requirement front. We also have an agreement that we need > > > both routing > > > > and signaling based solutions. This is because an IGP=20 > only based=20 > > > > solution is not applicable when dealing with Inter-area and > > > Inter-AS > > > > traffic engineering, as LSA or LSP flooding is=20 > restricted to IGP=20 > > > > areas/levels. Consequently, RSVP based mechanisms are > > > required to cope > > > > with TE LSPs spanning multiple domains. The draft presents=20 > > > > complementary mechanisms for RSVP-TE and IGP for Graceful > > Shutdown.=20 > > > > The IGP based solution is also based on an existing > > framework. Our > > > > action item is to close on the signaling based counterpart. > > > >=20 > > > >=20 > > > >=20 > > > > Before we compare the candidate solution, let's discuss and > > > agree on > > > > general requirement for a signaling based graceful shutdown > > > mechanism. > > > > In graceful shutdown procedure, as the Ingress LSR is=20 > expected to=20 > > > > perform make-before-break for the LSP (using the=20 > resource that is=20 > > > > being shutdown), we should be able to specify the TE > > > resource (link/ > > > > node) under graceful shutdown. Furthermore, conveying=20 > signaling=20 > > > > message to the Ingress LSR suffices. I.e., we can make use > > > of the Notify Message. > > > >=20 > > > >=20 > > > >=20 > > > > One of the solutions proposed during these discussions is > > > to make use > > > > of the admin status object. However, admin status=20 > cannot contain=20 > > > > information about TE resource under Graceful Shutdown. > > > Hence, we did > > > > not consider use of admin status object as a possible solution. > > > >=20 > > > >=20 > > > >=20 > > > > Another alternate that was put forward is the use ALARM_ > > > SPEC Objects. > > > > While ALARM_ SPEC Objects has ability to Signal Info about > > > TE resource > > > > under Graceful shutdown, use of this object in the notify > > > message is > > > > not defined. We also feel use of the ALARM_ SPEC Objects is > > > heavy duty > > > > for signaling simple Graceful Shutdown condition. > > > >=20 > > > >=20 > > > >=20 > > > > We propose to overload "TE link maintenance required"=20 > > > sub-code of the > > > > Notify Error Code (24) of the ERROR_SPEC. We believe=20 > this is the=20 > > > > simplest solution with existing/ well used way to signal > > > information > > > > about TE resource under Graceful Shutdown. Furthermore, the > > > ERROR_SPEC > > > > with code 24/ sub-code TBD can then be carried in either > > PathErr or > > > > Notify message to signal graceful condition. > > > >=20 > > > >=20 > > > >=20 > > > > Can you please send your comments to this by the end of > > > this week so > > > > we can update the ID, if needed? > > > >=20 > > > >=20 > > > >=20 > > > > Thanks > > > >=20 > > > >=20 > > > >=20 > > > > Regards... Zafar > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 >=20 ------_=_NextPart_001_01C640D7.79CEB815 Content-Type: text/plain; name="draft-ali-ccamp-mpls-graceful-shutdown-03.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ali-ccamp-mpls-graceful-shutdown-03.txt Content-Disposition: attachment; filename="draft-ali-ccamp-mpls-graceful-shutdown-03.txt" IA0KICAgDQogDQpDQ0FNUCBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBaYWZhciBBbGkgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBKZWFuIFBoaWxpcHBlIFZhc3NldXIgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5j YSBaYW1maXIgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIENpc2NvIFN5c3RlbXMsIEluYy4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpJRVRGIEludGVy bmV0IERyYWZ0IA0KQ2F0ZWdvcnk6IFN0YW5kYXJkIHRyYWNrIA0KRXhwaXJlczogU2VwdGVtYmVy IDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTWFyY2ggMjAwNiANCiANCiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICBkcmFmdC1hbGktY2NhbXAtbXBscy1ncmFjZWZ1bC1zaHV0ZG93bi0w My50eHQgDQogDQogDQogICAgICAgIEdyYWNlZnVsIFNodXRkb3duIGluIEdNUExTIFRyYWZmaWMg RW5naW5lZXJpbmcgTmV0d29ya3MgDQogDQogDQpTdGF0dXMgb2YgdGhpcyBNZW1vIA0KICAgIA0K ICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNl bnRzIHRoYXQgYW55IA0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBv ZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUgDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNj bG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMgDQogICBhd2FyZSB3aWxs IGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuIA0K ICAgIA0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50 ZXJuZXQgRW5naW5lZXJpbmcgDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQg aXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgb3RoZXIgDQogICBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuIA0KICAgIA0K ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11 bSBvZiBzaXggbW9udGhzIA0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgDQogICB0aW1lLiAgSXQgaXMgaW5hcHBy b3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSANCiAgIG1hdGVyaWFs IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgDQogICAg DQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQg YXQgDQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuIA0KICAg IA0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBi ZSBhY2Nlc3NlZCBhdCANCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDFdICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCgwgDQogICANCiANCiANCiAg IEFic3RyYWN0IA0KIA0KICAgR01QTFMtVEUgR3JhY2VmdWwgc2h1dGRvd24gaXMgYSBtZXRob2Qg Zm9yIGV4cGxpY2l0bHkgbm90aWZ5aW5nIHRoZSANCiAgIG5vZGVzIGluIGEgVEUgbmV0d29yayB0 aGF0IHRoZSBURSBwcm90b2NvbCBvbiBhIGxpbmsgb3Igb24gYW4gZW50aXJlIA0KICAgVEUgbm9k ZSBpcyBnb2luZyB0byBiZSBkaXNhYmxlZC4gR01QTFMtVEUgZ3JhY2VmdWwgc2h1dGRvd24gDQog ICBtZWNoYW5pc21zIGFyZSB0YWlsb3JlZCB0b3dhcmRzIGFkZHJlc3NpbmcgdGhlIHBsYW5uZWQg b3V0YWdlIGluIHRoZSANCiAgIG5ldHdvcmsuICANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgcHJv dmlkZXMgcmVxdWlyZW1lbnRzIGFuZCBwcm90b2NvbCBtZWNoYW5pc21zIHNvIGFzIHRvIA0KICAg cmVkdWNlL2VsaW1pbmF0ZSB0cmFmZmljIGRpc3J1cHRpb24gaW4gdGhlIGV2ZW50IG9mIGEgcGxh bm5lZCANCiAgIHNodXRkb3duIG9mIGEgbmV0d29yayByZXNvdXJjZS4gVGhlc2Ugb3BlcmF0aW9u cyBhcmUgZXF1YWxseSANCiAgIGFwcGxpY2FibGUgZm9yIGJvdGggY2xhc3NpY2FsIE1QTFMgYW5k IGl0cyBHTVBMUyBleHRlbnNpb25zLiAgDQogDQpDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9j dW1lbnQgDQogDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVE IiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsIA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJF Q09NTUVOREVEIiwgICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICAgZG9jdW1lbnQg YXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMtMjExOSBbaV0uIA0KIA0K VGFibGUgb2YgQ29udGVudHMgDQogDQoxLiBUZXJtaW5vbG9neS4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMiANCjIuIEludHJvZHVjdGlvbi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zIA0K My4gUmVxdWlyZW1lbnRzIGZvciBHcmFjZWZ1bCBTaHV0ZG93bi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjMgDQo0LiBNZWNoYW5pc21zIGZvciBHcmFjZWZ1bCBTaHV0ZG93bi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNCANCiA0LjEgUlNWUC1URSBTaWduYWxpbmcg TWVjaGFuaXNtIGZvciBncmFjZWZ1bCBzaHV0ZG93bi4uLi4uLi4uLi4uLi4uLjQgDQogNC4xLjEg R3JhY2VmdWwgU2h1dGRvd24gb2YgVEUgbGluayhzKS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi40IA0KIDQuMS4yIEdyYWNlZnVsIFNodXRkb3duIG9mIENvbXBvbmVudCBMaW5rKHMpIGlu IGEgQnVuZGxlZCBURSBMaW5rLi4uNSANCiA0LjEuMyBHcmFjZWZ1bCBTaHV0ZG93biBvZiBURSBO b2RlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogNC4yIE9TUEYvIElTSVMg TWVjaGFuaXNtcyBmb3IgZ3JhY2VmdWwgc2h1dGRvd24uLi4uLi4uLi4uLi4uLi4uLi4uLi41IA0K IDQuMi4xIEdyYWNlZnVsIFNodXRkb3duIG9mIFRFIGxpbmsocykuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNiANCiA0LjIuMiBHcmFjZWZ1bCBTaHV0ZG93biBvZiBDb21wb25lbnQgTGlu ayhzKSBpbiBhIEJ1bmRsZWQgVEUgTGluay4uLjYgDQogNC4yLjMgR3JhY2VmdWwgU2h1dGRvd24g b2YgVEUgTm9kZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KNS4gU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjcgDQo2LiBJQU5BIENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCjcuIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBDb25zaWRl cmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43IA0KOC4gRnVsbCBDb3B5cmln aHQgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcg DQo5LiBBY2tub3dsZWRnbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uNyANCjEwLiBSZWZlcmVuY2UuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44IA0KIDEwLjEgTm9ybWF0aXZlIFJlZmVy ZW5jZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAxMC4y IEluZm9ybWF0aXZlIFJlZmVyZW5jZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjggDQogDQoxLiANICBUZXJtaW5vbG9neSANCiAgDQogICBOb2RlIC0gTGFiZWwgU3dp dGNoaW5nIERldmljZS4gIA0KICAgIA0KICAgTFNQIC0gQW4gTVBMUyBMYWJlbCBTd2l0Y2hlZCBQ YXRoIA0KICAgIA0KICAgSGVhZC1lbmQgb3IgSW5ncmVzcyBub2RlOiBJbiB0aGUgZHJhZnQgdGVy bSBoZWFkLWVuZCBub2RlIGVxdWFsbHkgDQogICBhcHBsaWVzIHRvIHRoZSBJbmdyZXNzIG5vZGUg dGhhdCBpbml0aWF0ZWQgc2lnbmFsaW5nIGZvciB0aGUgUGF0aCwgb3IgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQoMIA0KICAgDQogDQogDQogICBhbiBpbnRlcm1l ZGlhdGUgbm9kZSAoaW4gdGhlIGNhc2Ugb2YgbG9vc2UgaG9wcyBwYXRoIGNvbXB1dGF0aW9uKSBv ciANCiAgIGEgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IChQQ0UpIHRoYXQgY29tcHV0ZXMgdGhl IHJvdXRlcyBvbiBiZWhhbGYgDQogICBvZiBpdHMgY2xpZW50cyAoUENDKS4gDQogICAgDQogICBH TVBMUyAtDSAgICAgICAgIC0gVGhlIHRlcm0gR01QTFMgaXMgdXNlZCBpbiB0aGlzIGRvY3VtZW50 IHRvIHJlZmVyIHRvIGJvdGggDQogICBjbGFzc2ljIE1QTFMsIGFzIHdlbGwgYXMgdGhlIEdNUExT IGV4dGVuc2lvbnMgdG8gTVBMUy4gIA0KICAgIA0KICAgVEUgTGluayAtDSAgICAgICAgICAgLSBU aGUgdGVybSBURSBsaW5rIHJlZmVycyB0byBhIHBoeXNpY2FsIGxpbmsgb3IgYW4gRkEtTFNQLCBv biANCiAgIHdoaWNoIHRyYWZmaWMgZW5naW5lZXJpbmcgaXMgZW5hYmxlZC4gQSBURSBsaW5rIGNh biBiZSBidW5kbGVkIG9yIA0KICAgdW5idW5kbGVkLiAgDQogDQoyLiANICBJbnRyb2R1Y3Rpb24g DQogDQogICBXaGVuIG91dGFnZXMgaW4gYSBuZXR3b3JrIGFyZSBwbGFubmVkLCBzb21lIG1lY2hh bmlzbXMgY2FuIGJlIHVzZWQgdG8gDQogICBhdm9pZCB0cmFmZmljIGRpc3J1cHRpb24uIFRoaXMg aXMgaW4gY29udHJhc3Qgd2l0aCB1bnBsYW5uZWQgbmV0d29yayANCiAgIGVsZW1lbnQgZmFpbHVy ZSwgd2hlcmUgdHJhZmZpYyBkaXNydXB0aW9uIGNhbiBiZSByZWR1Y2VkIGJ1dCBtYXkgbm90IA0K ICAgYXZvaWRlZC4gSGVuY2UsIGEgU2VydmljZSBQcm92aWRlciBtYXkgZGVzaXJlIHRvIGdyYWNl ZnVsbHkgDQogICAodGVtcG9yYXJpbHkgb3IgZGVmaW5pdGVseSkgZGlzYWJsZSBUcmFmZmljIEVu Z2luZWVyaW5nIG9uIGEgVEUgTGluaywgDQogICBhIGdyb3VwIG9mIFRFIExpbmtzIG9yIGFuIGVu dGlyZSBub2RlIGZvciBhZG1pbmlzdHJhdGl2ZSByZWFzb25zIHN1Y2ggDQogICBhcyBsaW5rIG1h aW50ZW5hbmNlLCBzb2Z0d2FyZS9oYXJkd2FyZSB1cGdyYWRlIGF0IGEgbm9kZSBvciANCiAgIHNp Z25pZmljYW50IFRFIGNvbmZpZ3VyYXRpb24gY2hhbmdlcy4gSW4gYWxsIHRoZXNlIGNhc2VzLCB0 aGUgZ29hbCBpcyANCiAgIHRvIG1pbmltaXplIGltcGFjdCBvbiB0aGUgR01QTFMgVHJhZmZpYyBF bmdpbmVlcmVkIGZsb3dzIGluIHRoZSANCiAgIG5ldHdvcmsgYnkgYnJpbmdpbmcgZG93biB0aGUg cHJvdG9jb2wgYmVmb3JlIHRoZSBhZG1pbmlzdHJhdGl2ZSANCiAgIHByb2NlZHVyZXMgYXJlIHN0 YXJ0ZWQuICANCiAgICANCiAgIEdyYWNlZnVsIHNodXRkb3duIG9mIGEgcmVzb3VyY2UgbWF5IHJl cXVpcmUgc2V2ZXJhbCBzdGVwcy4gVGhlc2UgDQogICBzdGVwcyBjYW4gYmUgYnJvYWRseSBkaXZp ZGVkIGludG8gdHdvIHNldHM6IGRpc2FibGluZyB0aGUgcmVzb3VyY2UgaW4gDQogICB0aGUgY29u dHJvbCBwbGFuZSBhbmQgcmVtb3ZpbmcgdGhlIHJlc291cmNlIGZvciBmb3J3YXJkaW5nLiBUaGUg bm9kZSANCiAgIGluaXRpYXRpbmcgdGhlIGdyYWNlZnVsIHNodXRkb3duIGNvbmRpdGlvbiBTSE9V TEQgZGVsYXkgdGhlIHJlbW92YWwgDQogICBvZiB0aGUgcmVzb3VyY2VzIGZvciBmb3J3YXJkaW5n LCBmb3Igc29tZSBwZXJpb2QgZGV0ZXJtaW5lZCBieSBsb2NhbCANCiAgIHBvbGljeS4gVGhpcyBp cyB0byBhbGxvdyBjb250cm9sIHBsYW5lIHRvIGdyYWNlZnVsbHkgZGl2ZXJ0IHRoZSANCiAgIHRy YWZmaWMgYXdheSBmcm9tIHRoZSByZXNvdXJjZSBiZWluZyBncmFjZWZ1bGx5IHNodXRkb3duLiAg DQogICAgDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgbWVjaGFuaXNtcyB0aGF0IGNh biBiZSB1c2VkIHRvIGdyYWNlZnVsbHkgDQogICBzaHV0ZG93biBHTVBMUyBUcmFmZmljIEVuZ2lu ZWVyaW5nIG9uIGEgcmVzb3VyY2UuIEFzIG1lbnRpb25lZCANCiAgIGVhcmxpZXIsIHRoZSBncmFj ZWZ1bCBzaHV0ZG93biBvZiBUcmFmZmljIEVuZ2luZWVyaW5nIGNvdWxkIGJlIA0KICAgaW5jb3Jw b3JhdGVkIGluIHRoZSB0cmFkaXRpb25hbCBzaHV0ZG93biBvcGVyYXRpb24gb2YgYW4gaW50ZXJm YWNlLCANCiAgIGJ1dCBpdCBpcyBhIHNlcGFyYXRlIHN0ZXAgdGhhdCBpcyB0YWtlbiBiZWZvcmUg dGhlIElHUCBvbiB0aGUgbGluayBpcyANCiAgIGJyb3VnaHQgZG93biBhbmQgYmVmb3JlIHRoZSBp bnRlcmZhY2UgaXMgYnJvdWdodCBkb3duIGF0IGRpZmZlcmVudCANCiAgIGxheWVycy4gVGhpcyBk b2N1bWVudCBvbmx5IHRhbGtzIGFwcGxpY2FibGUgZm9yIFRFIG5vZGUgYW5kIFRFIA0KICAgcmVz b3VyY2VzLiAgDQogDQozLiANICBSZXF1aXJlbWVudHMgZm9yIEdyYWNlZnVsIFNodXRkb3duIA0K IA0KVGhpcyBzZWN0aW9uIGxpc3RzIHRoZSByZXF1aXJlbWVudHMgZm9yIGdyYWNlZnVsIHNodXRk b3duIGluIHRoZSANCmNvbnRleHQgb2YgR01QTFMgVHJhZmZpYyBFbmdpbmVlcmluZy4gDQogDQog ICAtIEdyYWNlZnVsIHNodXRkb3duIG11c3QgYWRkcmVzcyBncmFjZWZ1bCByZW1vdmFsIG9mIG9u ZSBURSBsaW5rLCBvbmUgDQogICBjb21wb25lbnQgbGluayB3aXRoaW4gYSBidW5kbGVkIFRFIGxp bmssIGEgc2V0IG9mIFRFIGxpbmtzLCBhIHNldCBvZiANCiAgIGNvbXBvbmVudCBsaW5rcyBvciBh biBlbnRpcmUgbm9kZS4gIA0KICAgIA0KDCAgIC0gSXQgaXMgcmVxdWlyZWQgdG8gcHJldmVudCBv dGhlciBuZXR3b3JrIG5vZGVzIHRvIHVzZSB0aGUgbmV0d29yayANCiAgIHJlc291cmNlcyB0aGF0 IGFyZSBhYm91dCB0byBiZSBzaHV0ZG93biwgc2hvdWxkIG5ldyBURSBMU1AgYmUgc2V0IHVwLiAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXSANCgwgDQogICANCiANCiAN CiAgIFNpbWlsYXJseSBpdCBpcyByZXF1aXJlZCB0byByZWR1Y2UvZWxpbWluYXRlIHRyYWZmaWMg ZGlzcnVwdGlvbiBvbiANCiAgIHRoZSBMU1AtcyB1c2luZyB0aGUgbmV0d29yayByZXNvdXJjZXMg d2hpY2ggYXJlIGFib3V0IHRvIGJlIHNodXRkb3duLiAgDQogICAgDQogICAtIFRyaWdnZXIgZm9y IHRoZSBncmFjZWZ1bCBzaHV0ZG93biBldmVudCBpcyBhIGxvY2FsIG1hdHRlciBhdCB0aGUgDQog ICBub2RlIGluaXRpYXRpbmcgdGhlIGdyYWNlZnVsIHNodXRkb3duLiBUeXBpY2FsbHksIGdyYWNl ZnVsIHNodXRkb3duIA0KICAgaXMgdHJpZ2dlcmVkIGZvciBhZG1pbmlzdHJhdGl2ZSByZWFzb25z LCBzdWNoIGFzIGxpbmsgbWFpbnRlbmFuY2Ugb3IgDQogICBzb2Z0d2FyZS9oYXJkd2FyZSB1cGdy YWRlIGF0IGEgbm9kZS4gIA0KIA0KICAgLSBHcmFjZWZ1bCBzaHV0ZG93biBtZWNoYW5pc21zIGFy ZSByZXF1aXJlZCB0byBhZGRyZXNzIFRFIExTUHMgDQogICBzcGFubmluZyBtdWx0aXBsZSBkb21h aW5zLCBhcyB3ZWxsIGFzIGludHJhIGRvbWFpbiBURSBMU1BzLiBIZXJlLCBhIA0KICAgZG9tYWlu IGlzIGRlZmluZWQgYXMgZWl0aGVyIGFuIElHUCBhcmVhIG9yIGFuIEF1dG9ub21vdXMgU3lzdGVt IA0KICAgW0lOVEVSLUFSRUEtQVNdLiANCiAgICANCiAgIC0gR3JhY2VmdWwgc2h1dGRvd24gaXMg ZXF1YWxseSBhcHBsaWNhYmxlIHRvIEdNUExTLVRFLCBhcyB3ZWxsIGFzIA0KICAgY2xhc3NpY2Fs IE1QTFMtVEUgTFNQcy4gDQogICAgDQogICAtIEluIG9yZGVyIHRvIG1ha2UgcmVyb3V0aW5nIGVm ZmVjdGl2ZSwgaXQgaXMgcmVxdWlyZWQgdG8gY29tbXVuaWNhdGUgDQogICBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgVEUgcmVzb3VyY2UgdW5kZXIgZ3JhY2VmdWwgc2h1dGRvd24uICANCiANCiANCjQu IA0gIE1lY2hhbmlzbXMgZm9yIEdyYWNlZnVsIFNodXRkb3duIA0KIA0KICAgQW4gSUdQIG9ubHkg YmFzZWQgc29sdXRpb24gaXMgbm90IGFwcGxpY2FibGUgd2hlbiBkZWFsaW5nIHdpdGggSW50ZXIt DQogICBhcmVhIGFuZCBJbnRlci1BUyB0cmFmZmljIGVuZ2luZWVyaW5nLCBhcyBMU0Egb3IgTFNQ IGZsb29kaW5nIGlzIA0KICAgcmVzdHJpY3RlZCB0byBJR1AgYXJlYXMvbGV2ZWxzLiBDb25zZXF1 ZW50bHksIFJTVlAgYmFzZWQgbWVjaGFuaXNtcyANCiAgIGFyZSByZXF1aXJlZCB0byBjb3BlIHdp dGggVEUgTFNQcyBzcGFubmluZyBtdWx0aXBsZSBkb21haW5zLiBBdCB0aGUgDQogICBzYW1lIHRp bWUsIGFzIFJTVlAgbWVjaGFuaXNtcyBvbmx5IGNvbnZleSB0aGUgaW5mb3JtYXRpb24gZm9yIHRo ZSANCiAgIHRyYW5zaXRpbmcgTFNQcyB0byB0aGUgcm91dGVyIGFsb25nIHRoZSB1cHN0cmVhbSBQ YXRoIGFuZCBub3QgdG8gYWxsIA0KICAgbm9kZXMgaW4gdGhlIG5ldHdvcmssIGluZGljYXRpb24g b2YgZ3JhY2VmdWwgc2h1dGRvd24gdmlhIElHUCANCiAgIGZsb29kaW5nIGlzIHJlcXVpcmVkIHRv IGRpc2NvdXJhZ2UgYSBub2RlIGZyb20gZXN0YWJsaXNoaW5nIG5ldyBMU1BzIA0KICAgdGhyb3Vn aCB0aGUgcmVzb3VyY2VzIGJlaW5nIHNodXQtZG93bi4gSW4gdGhlIGZvbGxvd2luZyBzZWN0aW9u cyB0aGUgDQogICBjb21wbGVtZW50YXJ5IG1lY2hhbmlzbXMgZm9yIFJTVlAtVEUgYW5kIElHUCBm b3IgR3JhY2VmdWwgU2h1dGRvd24gDQogICBhcmUgZGVzY3JpYmVkLiAgDQogDQo0LjEgDSAgIFJT VlAtVEUgU2lnbmFsaW5nIE1lY2hhbmlzbSBmb3IgZ3JhY2VmdWwgc2h1dGRvd24gDQogDQogICBB cyBkaXNjdXNzZWQgaW4gU2VjdGlvbiAzLCBvbmUgb2YgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhl IHNpZ25hbGluZyANCiAgIG1lY2hhbmlzbSBmb3IgZ3JhY2VmdWwgc2h1dGRvd24gaXMgdG8gY2Fy cnkgaW5mb3JtYXRpb24gYWJvdXQgdGhlIA0KICAgcmVzb3VyY2UgdW5kZXIgZ3JhY2VmdWwgc2h1 dGRvd24uIFRoZXJlZm9yZSwgdGhlIEdyYWNlZnVsIFNodXRkb3duIA0KICAgbWVjaGFuaXNtIG91 dGxpbmVkIGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbiwgdXNlcyBQYXRoIEVycm9yIGFuZCANCiAg IHdoZXJlIGF2YWlsYWJsZSwgTm90aWZ5IG1lc3NhZ2UsIGluIG9yZGVyIHRvIGFjaGlldmUgdGhp cyANCiAgIHJlcXVpcmVtZW50LiBUaGVzZSBtZWNoYW5pc21zIGFyZSBhcHBsaWNhYmxlIHRvIHRo ZSBleGlzdGluZyBMU1BzLiANCiAgIFNldHVwIHJlcXVlc3QgZm9yIG5ldyBMU1BzIG92ZXIgdGhl IFRFIHJlc291cmNlIGJlaW5nIGdyYWNlZnVsbHkgDQogICBzaHV0ZG93biBTSE9VTEQgYmUgcmVq ZWN0ZWQgdXNpbmcgdGhlIGV4aXN0aW5nIG1lY2hhbmlzbXMgdGhhdCBhcmUgDQogICBhcHBsaWVk IHdoZW4gdGhlIFRFIHJlc291cmNlIGlzIG5vdCBhdmFpbGFibGUuICANCiANCjQuMS4xIEdyYWNl ZnVsIFNodXRkb3duIG9mIFRFIGxpbmsocykgDQogDQogICBUaGUgbm9kZSB3aGVyZSBncmFjZWZ1 bC1zaHV0ZG93biBvZiBhIGxpbmsgb3IgYSBzZXQgb2YgbGlua3MgaXMgDQogICBkZXNpcmVkIE1V U1QgdHJpZ2dlciBhIFBhdGggRXJyb3IgbWVzc2FnZSB3aXRoIJGRbG9jYWwgbGluayANCiAgIG1h aW50ZW5hbmNlIHJlcXVpcmVkkpIgc3ViLWNvZGUgZm9yIGFsbCBhZmZlY3RlZCBMU1BzLiBUaGUg kZFsb2NhbCBURSANCiAgIGxpbmsgbWFpbnRlbmFuY2UgcmVxdWlyZWSSkiBlcnJvciBjb2RlIGFz IGRlZmluZWQgaW4gW1BBVEgtUkVPUFRdLiBJZiANCiAgIGF2YWlsYWJsZSwgYW5kIHdoZXJlIG5v dGlmeSByZXF1ZXN0cyB3ZXJlIGluY2x1ZGVkIHdoZW4gdGhlIExTUHMgd2VyZSANCgwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQoMIA0KICAgDQogDQogDQogICBpbml0 aWFsbHkgc2V0dXAsIE5vdGlmeSBtZXNzYWdlIE1BWSBhbHNvIGJlIHVzZWQgZm9yIGZhc3QgZGVs aXZlcnkgb2YgDQogICB0aGlzIGluZm9ybWF0aW9uIHRvIHRoZSBoZWFkLWVuZCBub2Rlcy4gDQog DQogICBXaGVuIGEgaGVhZC1lbmQgbm9kZSByZWNlaXZlcyBQYXRoIEVycm9yIChvciBOb3RpZnkg bWVzc2FnZSkgbWVzc2FnZSANCiAgIHdpdGggc3ViLWNvZGUgIkxvY2FsIE1haW50ZW5hbmNlIG9u IFRFIExpbmsgcmVxdWlyZWQgRmxhZyIsIGl0IFNIT1VMRCANCiAgIGltbWVkaWF0ZWx5IHRyaWdn ZXIgYSBtYWtlLWJlZm9yZS1icmVhayBwcm9jZWR1cmUuIElmIHRoZSBMU1AgaXMgDQogICBwcm90 ZWN0ZWQsIHN3aXRjaG92ZXIgcHJvY2VkdXJlIG1heSBiZSB0cmlnZ2VyZWQuIEEgaGVhZC1lbmQg bm9kZSANCiAgIFNIT1VMRCBhdm9pZCB0aGUgSVAgYWRkcmVzcyBjb250YWluZWQgaW4gdGhlIFBh dGhFcnIgKG9yIE5vdGlmeSANCiAgIG1lc3NhZ2UpIHdoZW4gcGVyZm9ybWluZyBwYXRoIGNvbXB1 dGF0aW9uIGZvciB0aGUgbmV3IExTUC4gICANCiANCjQuMS4yIEdyYWNlZnVsIFNodXRkb3duIG9m IENvbXBvbmVudCBMaW5rKHMpIGluIGEgQnVuZGxlZCBURSBMaW5rIA0KIA0KICAgTVBMUyBURSBM aW5rIEJ1bmRsaW5nIGRyYWZ0IFtCVU5ETEVdIHJlcXVpcmVzIHRoYXQgYW4gTFNQIGlzIHBpbm5l ZCANCiAgIGRvd24gdG8gY29tcG9uZW50IGxpbmsocykuIEhlbmNlLCB3aGVuIGEgY29tcG9uZW50 IGxpbmsgaXMgc2h1dC1kb3duLCANCiAgIHRoZSBMU1BzIGFmZmVjdGVkIGJ5IHN1Y2ggbWFpbnRl bmFuY2UgYWN0aW9uIG5lZWRzIHRvIGJlIHJlLXNpZ25hbGVkLiAgDQogICAgDQogICBHcmFjZWZ1 bCBzaHV0ZG93biBvZiBhIGNvbXBvbmVudCBsaW5rIGluIGEgYnVuZGxlZCBURSBsaW5rIGRpZmZl cnMgDQogICBmcm9tIGdyYWNlZnVsIHNodXRkb3duIG9mIHVuYnVuZGxlZCBURSBsaW5rIG9yIGVu dGlyZSBidW5kbGVkIFRFIA0KICAgbGluay4gU3BlY2lmaWNhbGx5LCBpbiB0aGUgZm9ybWVyIGNh c2UsIHdoZW4gb25seSBhIHN1YnNldCBvZiANCiAgIGNvbXBvbmVudCBsaW5rcyBhbmQgbm90IHRo ZSBlbnRpcmUgVEUgYnVuZGxlZCBsaW5rIGlzIGJlaW5nIHNodXRkb3duLCANCiAgIHRoZSByZW1h aW5pbmcgY29tcG9uZW50IGxpbmtzIG9mIHRoZSBURSBsaW5rcyBtYXkgc3RpbGwgYmUgYWJsZSB0 byANCiAgIGFkbWl0IG5ldyBMU1BzLiBDb25zZXF1ZW50bHkgYSBuZXcgZXJyb3Igc3ViLWNvZGUg Zm9yIFBhdGhFcnJvciBvciANCiAgIE5vdGlmeSBtZXNzYWdlIGlzIG5lZWRlZDogDQogICAgIA0K ICAgICAgICAgOSAoVEJBKSAgICAgIExvY2FsIGNvbXBvbmVudCBsaW5rIG1haW50ZW5hbmNlIHJl cXVpcmVkIA0KICAgIA0KICAgRXJyb3IgU3ViLWNvZGUgZm9yIJGRTG9jYWwgY29tcG9uZW50IGxp bmsgbWFpbnRlbmFuY2UgcmVxdWlyZWSSkiBpcyB0byANCiAgIGJlIGFzc2lnbmVkIGJ5IElBTkEu ICANCiAgICANCiAgIElmIHRoZSBsYXN0IGNvbXBvbmVudCBsaW5rIGlzIGJlaW5nIHNodXQtZG93 biwgdGhlIHByb2NlZHVyZSBvdXRsaW5lZCANCiAgIGluIFNlY3Rpb24gNS4xIGlzIHVzZWQuIA0K ICAgIA0KICAgV2hlbiBhIGhlYWQtZW5kIG5vZGUgcmVjZWl2ZXMgYW4gUlNWUCBQYXRoRXJyb3Ig b3IgTm90aWZ5IG1lc3NhZ2UgDQogICB3aXRoIHN1Yi1jb2RlICJsb2NhbCBjb21wb25lbnQgbGlu ayBtYWludGVuYW5jZSByZXF1aXJlZJKSIEZsYWcgc2V0LCANCiAgIGl0IFNIT1VMRCBpbW1lZGlh dGVseSBwZXJmb3JtIGEgbWFrZS1iZWZvcmUtYnJlYWsgdG8gYXZvaWQgdHJhZmZpYyANCiAgIGxv c3MuIFRoZSBoZWFkLWVuZCBub2RlIE1BWSBzdGlsbCB1c2UgdGhlIElQIGFkZHJlc3MgY29udGFp bmVkIGluIHRoZSANCiAgIFBhdGhFcnIgb3IgTm90aWZ5IG1lc3NhZ2UgaW4gcGVyZm9ybWluZyBw YXRoIGNvbXB1dGF0aW9uIGZvciANCiAgIHJlcm91dGluZyB0aGUgTFNQLiBUaGlzIGlzIGJlY2F1 c2UsIHRoaXMgYWRkcmVzcyBpcyBhbiBJUCBhZGRyZXNzIG9mIA0KICAgdGhlIGNvbXBvbmVudCBs aW5rIGFuZCB0aGUgZmxhZyBpcyBhbiBpbXBsaWNpdCBpbmRpY2F0aW9uIHRoYXQgdGhlIFRFIA0K ICAgbGluayBtYXkgc3RpbGwgaGF2ZSBjYXBhY2l0eSB0byBhZG1pdCBuZXcgTFNQcy4gSG93ZXZl ciwgaWYgdGhlIEVSTyANCiAgIGlzIGNvbXB1dGVkIHN1Y2ggdGhhdCBpdCBhbHNvIHByb3ZpZGVz IGRldGFpbHMgb2YgdGhlIGNvbXBvbmVudCBsaW5rIA0KICAgc2VsZWN0aW9uKHMpIGFsb25nIHRo ZSBQYXRoLCB0aGUgY29tcG9uZW50IGxpbmsgc2VsZWN0aW9uIHdpdGggSVAgDQogICBhZGRyZXNz IGNvbnRhaW5lZCBpbiB0aGUgUGF0aEVyciBvciBOb3RpZnkgbWVzc2FnZSBTSE9VTEQgYmUgYXZv aWRlZC4gIA0KIA0KNC4xLjMgR3JhY2VmdWwgU2h1dGRvd24gb2YgVEUgTm9kZSANCiANCiAgIFdo ZW4gZ3JhY2VmdWwgc2h1dGRvd24gYXQgbm9kZSBsZXZlbCBpcyBkZXNpcmVkLCB0aGUgbm9kZSBp biBxdWVzdGlvbiANCiAgIGZvbGxvd3MgdGhlIHByb2NlZHVyZSBzcGVjaWZpZWQgaW4gdGhlIHBy ZXZpb3VzIHNlY3Rpb24gZm9yIGFsbCBURSANCiAgIExpbmtzLiAgDQogDQo0LjIgDSAgIE9TUEYv IElTSVMgTWVjaGFuaXNtcyBmb3IgZ3JhY2VmdWwgc2h1dGRvd24gDQogDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XSANCgwgDQogICANCiANCiANCiAgIFRoZSBwcm9j ZWR1cmVzIHByb3ZpZGVkIGluIHRoaXMgc2VjdGlvbiBhcmUgZXF1YWxseSBhcHBsaWNhYmxlIHRv IA0KICAgT1NQRiBhbmQgSVNJUy4gIA0KIA0KNC4yLjEgR3JhY2VmdWwgU2h1dGRvd24gb2YgVEUg bGluayhzKSANCiANCiAgIFRoZSBub2RlIHdoZXJlIGdyYWNlZnVsLXNodXRkb3duIG9mIGEgbGlu ayBpcyBkZXNpcmVkIE1VU1Qgb3JpZ2luYXRlIA0KICAgdGhlIFRFIExTQS9MU1AgY29udGFpbmlu ZyBsaW5rLWF0dHJpYnV0ZSBzdWItVExWIHdpdGggkZFsb2NhbCANCiAgIG1haW50ZW5hbmNlIHJl cXVpcmVkkpIgYml0IHNldC4gVGhlIGxpbmstYXR0cmlidXRlIHN1Yi1UTFYgZGVmaW5lZCBpbiAN CiAgIFtPU1BGLUxJTkstQVRUUkldIGFuZCBbSVNJUy1MSU5LLUFUVFJJXS4gICANCiAgICANCiAg IEV4dGVuc2lvbiB0byBsaW5rIGF0dHJpYnV0ZSBzdWItVExWIGlzIHByZWZlcnJlZCBvdmVyIHRo ZSB1c2Ugb2YgDQogICAoTUFYLU1FVFJJQywgemVybyBCYW5kd2lkdGgpIGJhc2VkIHNvbHV0aW9u LiBUaGlzIGlzIGJlY2F1c2UgYSBsaW5rIA0KICAgbWF5IGVuZC11cCB3aXRoIG1heCBtZXRyaWMg Zm9yIG11bHRpcGxlIHJlYXNvbnMgYW5kIHdpdGhvdXQgdGhlIGxpbmsgDQogICBhdHRyaWJ1dGUg dGhlcmUgaXMgbm8gd2F5IGEgbm9kZSBjYW4gdGVsbCB3aGF0IHRoZSByZWFzb24gaXMsIGUuZy4g YSANCiAgIHJlc3RhcnRpbmcgbm9kZSBtYXkgYWR2ZXJ0aXNlcyB0aGUgbWF4IG1hdHJpY2VzLiBG dXJ0aGVybW9yZSwgaWYgdGhlIA0KICAgcmVzb3VyY2UgdW5kZXIgZ3JhY2VmdWwgZGVsZXRpb24g aXMgdGhlIGxhc3QgcmVzb3J0IHRoZW4gdGhlIG5vZGUgDQogICBob3N0aW5nIHRoZSBncmFjZWZ1 bCBkZWxldGlvbiByZXNvdXJjZSB3aWxsIG5vdCByZWNlaXZlIG5ldyBzaWduYWxpbmcgDQogICBt ZXNzYWdlcy4gTm9uZXRoZWxlc3MsIHRvIGRlYWwgd2l0aCBub2RlcyBub3QgY29tcGxpYW50IHdp dGggdGhpcyANCiAgIGRvY3VtZW50IChpLmUuLCBkb2VzIG5vdCBpbXBsZW1lbnQgbGluayBhdHRy aWJ1dGUgc3ViLVRMViBiYXNlZCANCiAgIHNvbHV0aW9uKSwgdGhlIG5vZGUgaW5pdGlhdGluZyBn cmFjZWZ1bCBzaHV0ZG93biBNQVkgb3JpZ2luYXRlIHRoZSBURSANCiAgIExTQS9MU1AgY29udGFp bmluZyBMaW5rIFRMViB3aXRoIDAgdW5yZXNlcnZlZCBiYW5kd2lkdGgsIFRyYWZmaWMgDQogICBF bmdpbmVlcmluZyBtZXRyaWMgc2V0IHRvIDB4ZmZmZmZmZmYsIGFuZCBpZiB0aGUgTGluayBpcyBu b24tUFNDIHRoZW4gDQogICBhbHNvIHdpdGggMCBhcyBNYXggTFNQIEJhbmR3aWR0aC4gIA0KICAg IA0KICAgTmVpZ2hib3JzIG9mIHRoZSBub2RlIHdoZXJlIGdyYWNlZnVsIHNodXRkb3duIHByb2Nl ZHVyZSBpcyBpbiANCiAgIHByb2dyZXNzIFNIT1VMRCBjb250aW51ZSB0byBhZHZlcnRpc2UgdGhl IGFjdHVhbCB1bnJlc2VydmVkIGJhbmR3aWR0aCANCiAgIG9mIHRoZSBURSBsaW5rcyBmcm9tIHRo ZSBuZWlnaGJvcnMgdG8gdGhhdCBub2RlLCB3aXRob3V0IGFueSByb3V0aW5nIA0KICAgYWRqYWNl bmN5IGNoYW5nZS4gIA0KICAgIA0KICAgVGhlIG5vZGVzIHJlY2VpdmluZyBsaW5rLWF0dHJpYnV0 ZSBzdWItVExWIHdpdGggZ3JhY2VmdWwgc2h1dGRvd24gDQogICBpbmRpY2F0aW9uIFNIT1VMRCBt YXJrIHRoZSBsaW5rIGFzIHVudXNhYmxlIGZvciBmdXJ0aGVyIHBhdGggDQogICBjb21wdXRhdGlv biBpbiBib3RoIGRpcmVjdGlvbnMuICAgDQogDQo0LjIuMiBHcmFjZWZ1bCBTaHV0ZG93biBvZiBD b21wb25lbnQgTGluayhzKSBpbiBhIEJ1bmRsZWQgVEUgTGluayANCiANCiAgIElmIGdyYWNlZnVs IHNodXRkb3duIHByb2NlZHVyZSBpcyBwZXJmb3JtZWQgZm9yIGEgY29tcG9uZW50IGxpbmsgDQog ICB3aXRoaW4gYSBURSBMaW5rIGJ1bmRsZSBhbmQgaXQgaXMgbm90IHRoZSBsYXN0IGNvbXBvbmVu dCBsaW5rIA0KICAgYXZhaWxhYmxlIHdpdGhpbiB0aGUgVEUgbGluaywgdGhlIGxpbmsgYXR0cmli dXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlIA0KICAgVEUgbGluayBhcmUgcmVjb21wdXRlZC4gSWYg dGhlIHJlbW92YWwgb2YgdGhlIGNvbXBvbmVudCBsaW5rIHJlc3VsdHMgDQogICBpbiBhIHNpZ25p ZmljYW50IGNoYW5nZSBldmVudCwgdGhlIFRFIGxpbmsgaXMgcmUtZmxvb2RlZCB3aXRoIHRoZSBu ZXcgDQogICB0cmFmZmljIHBhcmFtZXRlcnMuIElmIHRoZSBsYXN0IGNvbXBvbmVudCBsaW5rIGlz IGJlaW5nIHNodXQtZG93biwgDQogICB0aGUgcm91dGluZyBwcm9jZWR1cmUgb3V0bGluZWQgaW4g U2VjdGlvbiA0LjIuMSBpcyB1c2VkLiANCiANCjQuMi4zIEdyYWNlZnVsIFNodXRkb3duIG9mIFRF IE5vZGUgDQogDQogICBXaGVuIGdyYWNlZnVsIHNodXRkb3duIGF0IG5vZGUgbGV2ZWwgaXMgZGVz aXJlZCwgdGhlIG5vZGUgaW4gcXVlc3Rpb24gDQogICBmb2xsb3dzIHRoZSBwcm9jZWR1cmUgc3Bl Y2lmaWVkIGluIHRoZSBwcmV2aW91cyBzZWN0aW9uIGZvciBhbGwgVEUgDQogICBMaW5rcy4gIA0K IA0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQoMIA0K ICAgDQogDQogDQo1LiANICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCiANCiAgIFRoaXMgZG9j dW1lbnQgZG9lcyBub3QgaW50cm9kdWNlIG5ldyBzZWN1cml0eSBpc3N1ZXMuIFRoZSBzZWN1cml0 eSANCiAgIGNvbnNpZGVyYXRpb25zIHBlcnRhaW5pbmcgdG8gdGhlIG9yaWdpbmFsIFJTVlAgcHJv dG9jb2wgW1JTVlBdIHJlbWFpbiANCiAgIHJlbGV2YW50LiANCiANCjYuIA0gIElBTkEgQ29uc2lk ZXJhdGlvbnMgDQogICAgDQogICBBIG5ldyBlcnJvciBzdWItY29kZSBmb3IgUGF0aCBFcnJvciBh bmQgTm90aWZ5IG1lc3NhZ2UgaXMgbmVlZGVkIGZvciAgIA0KICAgkZFMb2NhbCBjb21wb25lbnQg bGluayBtYWludGVuYW5jZSByZXF1aXJlZJKSIGZsYWcuICANCiANCiAgICANCjcuIA0gIEludGVs bGVjdHVhbCBQcm9wZXJ0eSBDb25zaWRlcmF0aW9ucyANCiAgICANCiAgIFRoZSBJRVRGIHRha2Vz IG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55IA0KICAg SW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBi ZSBjbGFpbWVkIHRvIA0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9m IHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbiANCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4 dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyANCiAgIG1pZ2h0IG9y IG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhh cyANCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCBy aWdodHMuIEluZm9ybWF0aW9uIA0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRv IHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZSANCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQg QkNQIDc5LiANCiAgICANCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUg SUVURiBTZWNyZXRhcmlhdCBhbmQgYW55IA0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBi ZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiANCiAgIGF0dGVtcHQgbWFkZSB0 byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZiAN CiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0 aGlzIA0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1s aW5lIElQUiByZXBvc2l0b3J5IGF0IA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuIA0KICAg IA0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBp dHMgYXR0ZW50aW9uIGFueSANCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxp Y2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkgDQogICByaWdodHMgdGhhdCBtYXkgY292ZXIg dGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQgDQogICB0aGlzIHN0 YW5kYXJkLiBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQgaWV0 Zi0gICANCiAgIGlwckBpZXRmLm9yZy4gDQogDQo4LiANICBGdWxsIENvcHlyaWdodCBTdGF0ZW1l bnQgDQogICAgDQpDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2KS4gVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIA0KdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3Ry aWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4IGFuZCBleGNlcHQgYXMgDQpzZXQgZm9ydGggdGhl cmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMuIA0KIA0KVGhpcyBkb2N1 bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9u IGFuIA0KIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9O IEhFL1NIRSBSRVBSRVNFTlRTIE9SIA0KSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5U RVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIA0KRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBE SVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiANCklNUExJRUQsSU5DTFVESU5HIEJV VCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSANCklORk9S TUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVE IA0KV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UuIA0KIA0KOS4gDQoMICBBY2tub3dsZWRnbWVudHMgDQogDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3XSANCgwgDQogICANCiANCiANClRoZSBhdXRo b3JzIHdvdWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgdXNlZnVsIGNvbW1lbnRzIGZyb20gRGF2aWQg V2FyZCwgDQpTYW1pIEJvdXRyb3MsIEFkcmlhbiBGYXJyZWwgYW5kIERpbWl0cmkgUGFwYWRpbWl0 cmlvdS4gIA0KIA0KMTAuIA0gICBSZWZlcmVuY2UgDQogDQoxMC4xIA0gICAgIE5vcm1hdGl2ZSBS ZWZlcmVuY2UgDQogDQogICBbUlNWUF0gQnJhZGVuLCBldCBhbCwgIlJlc291cmNlIFJlU2VyVmF0 aW9uIFByb3RvY29sIChSU1ZQKSAtIFZlcnNpb24gDQogICAxLCBGdW5jdGlvbmFsIFNwZWNpZmlj YXRpb24iLCBSRkMgMjIwNSwgU2VwdGVtYmVyIDE5OTcuIA0KICAgIA0KICAgW1JTVlAtVEVdIEF3 ZHVjaGUsIGV0IGFsLCAiRXh0ZW5zaW9ucyB0byBSU1ZQIGZvciBMU1AgVHVubmVscyIsIFJGQyAN CiAgIDMyMDksIERlY2VtYmVyIDIwMDEuIA0KICAgIA0KICAgW1JGQzM0NzFdIEdlbmVyYWxpemVk IE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIA0KICAgU2lnbmFsaW5nIEZ1 bmN0aW9uYWwgRGVzY3JpcHRpb24sIFJGQyAzNDcxLCBMLiBCZXJnZXIsIGV0IGFsLCBKYW51YXJ5 IA0KICAgMjAwMy4gDQogICAgDQogICBbUkZDMzQ3M10gTC4gQmVyZ2VyLCBldCBhbCwgIkdlbmVy YWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIA0KICAgU3dpdGNoaW5nIChHTVBMUykgU2lnbmFs aW5nIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29sLVRyYWZmaWMgDQogICBFbmdpbmVlcmlu ZyAoUlNWUC1URSkgRXh0ZW5zaW9ucyIsIFJGQyAzNDczLiAgDQogICAgDQogICBbUkZDNDIwM10g Sy4gS29tcGVsbGEsIFkuIFJla2h0ZXIsIGV0IGFsLCCRkU9TUEYgRXh0ZW5zaW9ucyBpbiBTdXBw b3J0IA0KICAgb2YgR2VuZXJhbGl6ZWQgTVBMU5KSLCBkcmFmdC1pZXRmLWNjYW1wLW9zcGYtZ21w bHMtZXh0ZW5zaW9ucy0xMi50eHQuIA0KICAgIA0KICAgW1JGQzQyMDVdIEsuIEtvbXBlbGxhLCBZ LiBSZWtodGVyLCBldCBhbCwgkZFJUy1JUyBFeHRlbnNpb25zIGluIA0KICAgU3VwcG9ydCBvZiBH ZW5lcmFsaXplZCBNUExTkpIsIGRyYWZ0LWlldGYtaXNpcy1nbXBscy1leHRlbnNpb25zLQ0KICAg MTkudHh0LiANCiANCiAgIFtJU0lTLUNBUF0gSmVhbi1QaGlsaXBwZSBWYXNzZXVyLCBTLiBQcmV2 aWRpLCBKLiBNYWJleSwgYW5kIEplYW4tDQogICBMb3VpcyBMZSBSb3V4LCCRkUlTLUlTIE1QTFMg VHJhZmZpYyBFbmdpbmVlcmluZyBjYXBhYmlsaXRpZXOSkiwgZHJhZnQtDQogICB2YXNzZXVyLWNj YW1wLWlzaXMtdGUtY2Fwcy0wMC50eHQuIA0KICAgIA0KICAgW09TUEYtTElOSy1BVFRSSV0gd29y ayBpbiBwcm9ncmVzcy4gIA0KICAgIA0KICAgW0lTSVMtTElOS19BVFRSSV0gSmVhbi1QaGlsaXBw ZSBWYXNzZXVyLCBTLiBQcmV2aWRpLCCRkURlZmluaXRpb24gb2YgDQogICBhbiBJUy1JUyBMaW5r IEF0dHJpYnV0ZSBzdWItVExWkpIsIGRyYWZ0LXZhc3NldXItaXNpcy1saW5rLWF0dHItDQogICAw MC50eHQuIA0KICAgIA0KICAgW1BBVEgtUkVPUFRdIEplYW4tUGhpbGlwcGUgVmFzc2V1ciwgYW5k IFkuIElrZWppcmksIJGRUmVvcHRpbWl6YXRpb24gDQogICBvZiBNUExTIFRyYWZmaWMgRW5naW5l ZXJpbmcgbG9vc2VseSByb3V0ZWQgTFNQIHBhdGhzkpIsIGRyYWZ0LWlldGYtDQogICBjY2FtcC1s b29zZS1wYXRoLXJlb3B0LTAxLnR4dC4gIA0KIA0KMTAuMiANICAgICBJbmZvcm1hdGl2ZSBSZWZl cmVuY2UgDQogDQogICBbSU5URVItQVJFQS1BU10gQWRyaWFuIEZhcnJlbCwgSmVhbi1QaGlsaXBw ZSBWYXNzZXVyLCBBcnRoaSBBeXlhbmdhciwgDQogICCRkUEgRnJhbWV3b3JrIGZvciBJbnRlci1E b21haW4gTVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nkpIsIGRyYWZ0LWlldGYtDQogICBjY2FtcC1p bnRlci1kb21haW4tZnJhbWV3b3JrLTA0LnR4dC4gDQogDQogICBbQlVORExFXSBLb21wZWxsYSwg Sy4sIFJla2h0ZXIsIFkuLCBCZXJnZXIsIEwuLCAiTGluayBCdW5kbGluZyBpbiAgIA0KICAgTVBM UyBUcmFmZmljIEVuZ2luZWVyaW5nIiwgZHJhZnQtaWV0Zi1tcGxzLWJ1bmxlLTA0LnR4dCAod29y ayBpbiAgIA0KICAgcHJvZ3Jlc3MpIA0KIA0KDCANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA4XSANCgwgDQogICANCiANCiANCkF1dGhvcnMnIEFkZHJlc3M6IA0KIA0KWmFm YXIgQWxpIA0KQ2lzY28gc3lzdGVtcywgSW5jLiwgDQoyMDAwIElubm92YXRpb24gRHJpdmUgICAg ICAgICANCkthbmF0YSwgT250YXJpbywgSzJLIDNFOCANCkNhbmFkYS4gIA0KRW1haWw6IHphbGlA Y2lzY28uY29tIA0KIA0KSmVhbiBQaGlsaXBwZSBWYXNzZXVyIA0KQ2lzY28gU3lzdGVtcywgSW5j LiANCjMwMCBCZWF2ZXIgQnJvb2sgUm9hZCANCkJveGJvcm91Z2ggLCBNQSAtIDAxNzE5IA0KVVNB IA0KRW1haWw6IGpwdkBjaXNjby5jb20gDQogDQpBbmNhIFphbWZpciANCkNpc2NvIFN5c3RlbXMs IEluYy4gIA0KMjAwMCBJbm5vdmF0aW9uIERyaXZlICANCkthbmF0YSwgT250YXJpbywgSzJLIDNF OCAgDQpDYW5hZGEgDQpFbWFpbDogYW5jYXpAY2lzY28uY29tICANCiAgDQogICAgICAgICAgICAg ICAgICAgICANCiANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDldIA0KDA== ------_=_NextPart_001_01C640D7.79CEB815-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Mar 2006 00:45:57 +0000 Thread-Topic: Draft on 1+1.. thread-index: AcZAt3o3eIoFOjcsR1+osoJHRp5NOQ== Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: "Suresh Katukam \(skatukam\)" , Content-Transfer-Encoding: 7bit Cc: Bcc: Subject: RE: Draft on 1+1.. Date: Mon, 6 Mar 2006 09:47:00 +0900 Comment: GQ19@|@ZEk=E?,18?x, ASON1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_150E_01C64102.EA2178C0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_150E_01C64102.EA2178C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ------=_NextPart_000_150E_01C64102.EA2178C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SGksPC9ESVY+DQo8RElWPklmIG15IHVuZGVy c3RhbmRpbmcgaXMgY29ycmVjdCw8L0RJVj4NCjxESVY+eW91IGNhbiBmaW5kIG91dCB0aGUgbWVj aGFuaXNtIGluJm5ic3A7dGhlIHNlY3Rpb24gNy4xLjE5IGFuZCBBcHBlbmRpeCBJViBvZiBHLjc3 MTIgd29ya2VkIG91dCBJVFUtVC48L0RJVj4NCjxESVY+PEJSPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPEJSPjxCPiZndDtGcm9tOjwvQj4gIlN1cmVzaCBLYXR1a2FtIChza2F0dWthbSkiICZs dDtza2F0dWthbUBjaXNjby5jb20mZ3Q7PEJSPjxCPiZndDtGcm9tIERhdGU6PC9CPiAyMDA2LTAz LTA0Jm5ic3A7QU0gMTo0NDozMTxCUj48Qj4mZ3Q7VG86PC9CPiAiY2NhbXBAb3BzLmlldGYub3Jn IiAmbHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OzxCUj48Qj4mZ3Q7Q2M6PC9CPiA8QlI+PEI+Jmd0 O1N1YmplY3Q6PC9CPiBEcmFmdCBvbiAxKzEuLjxCUj48L0RJVj4NCjxESVY+PFNUUk9ORz4mZ3Q7 PC9TVFJPTkc+PEJSPg0KPFA+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+Jmd0OzwvU1RST05HPkhpLDxC Uj48U1RST05HPiZndDs8L1NUUk9ORz48QlI+PFNUUk9ORz4mZ3Q7PC9TVFJPTkc+VGhlcmUgd2Fz IGEgcHJvcG9zYWwgYnkgTHVjZW50IChJIGJlbGlldmUpPEJSPjxTVFJPTkc+Jmd0OzwvU1RST05H PmFib3V0IHVzaW5nIDErMSBtZWNoYW5pc20gaW4gZGF0YSBuZXR3b3Jrcy48QlI+PFNUUk9ORz4m Z3Q7PC9TVFJPTkc+PEJSPjxTVFJPTkc+Jmd0OzwvU1RST05HPkkgYmVsaWV2ZSB0aGV5IHByb3Bv c2VkIHRoYXQgc291cmNlIGFuZDxCUj48U1RST05HPiZndDs8L1NUUk9ORz5kZXN0aW5hdGlvbiBz ZXQgdXAgdHdvIHR1bm5lbHMsIGFuZCBhZGQgc2VxIzxCUj48U1RST05HPiZndDs8L1NUUk9ORz50 byBlYWNoIHBhY2tldCBpbiB0aGUgdHVubmVsIGFuZCBsZXQgdGhlPEJSPjxTVFJPTkc+Jmd0Ozwv U1RST05HPmRlc3RpbmF0aW9uIGRlY2lkZSB3aGljaCBzdHJlYW0gdG8gdXNlLjxCUj48U1RST05H PiZndDs8L1NUUk9ORz48QlI+PFNUUk9ORz4mZ3Q7PC9TVFJPTkc+SSBoYXZlIGJlZW4gc2VhcmNo aW5nIGZvciB0aGF0IGRyYWZ0IGFuZDxCUj48U1RST05HPiZndDs8L1NUUk9ORz5jb3VsZCBub3Qg ZmluZC48QlI+PFNUUk9ORz4mZ3Q7PC9TVFJPTkc+PEJSPjxTVFJPTkc+Jmd0OzwvU1RST05HPkNh biB5b3UgcGxlYXNlIGxldCBtZSBrbm93IHdoZXJlIGNhbjxCUj48U1RST05HPiZndDs8L1NUUk9O Rz5JIGZpbmQgaXQuPEJSPjxCUj5UaGFua3MsPEJSPlN1cmVzaDxCUj48QlI+PC9GT05UPjwvUD48 L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3Jj PSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1j Y2FtcEBvcHMuaWV0Zi5vcmc= ------=_NextPart_000_150E_01C64102.EA2178C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 05 Mar 2006 18:05:27 +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: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) Date: Sun, 5 Mar 2006 13:02:28 -0500 Message-ID: Thread-Topic: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) Thread-Index: AcY/HKmSPjLGK8drTVqiRXGv4DsJhwBTEnJQ From: "Zafar Ali \(zali\)" To: Cc: "Adrian Farrel" , "Anca Zamfir \(ancaz\)" , , , "Jean Philippe Vasseur \(jvasseur\)" , "Kireeti Kompella" , Hi Dimitri,=20 There is a difference between expected operations in graceful restart and graceful shutdown; hence my previous email. The draft already lists Max Metric as a possible solution with motivation for selecting link attribute based solution. If the WG agrees that use of Max Metric suffices, we can fall back to the use of the Max Metric/ zero bw. We will be posting an updated version later tonight.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Sent: Friday, March 03, 2006 6:46 PM > To: Zafar Ali (zali) > Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org;=20 > dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur);=20 > Kireeti Kompella; owner-ccamp@ops.ietf.org > Subject: RE: Need to close on signaling solution for graceful=20 > shutdown (Follow-up on our Action Item) >=20 > hi zafar >=20 > then i will express my concern in the other way around=20 > concerning the "routing" part of this document: we have clean=20 > procedures for planned node restart in RFC4203; hence, the=20 > reason for having a "cleaner" procedure is totally unclear to=20 > me both in terms of motivation and applicability >=20 > much thanks, > - dimitri. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > "Zafar Ali \(zali\)" > Sent by: owner-ccamp@ops.ietf.org > 02/03/2006 07:06 > =20 > To: , Dimitri=20 > PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: , "Adrian Farrel"=20 > , "Anca Zamfir \(ancaz\)"=20 > , "Jean Philippe Vasseur \(jvasseur\)"=20 > , "Kireeti Kompella"=20 > > Subject: RE: Need to close on signaling solution for=20 > graceful shutdown (Follow-up on our Action Item) >=20 >=20 > Hi Dimitri,=20 >=20 > Sorry for the delay in replying. Please see reply in-line.=20 >=20 > All,=20 >=20 > I am assuming the WG is ok with the signaling part of the solution. If > you have any comments, please reply to my original email. We plan to > refresh the ID before the flood gate closes.=20 >=20 > Thanks >=20 > Regards... Zafar=20 >=20 > > -----Original Message----- > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > > Sent: Monday, February 20, 2006 2:01 AM > > To: Zafar Ali (zali) > > Cc: ccamp@ops.ietf.org; Adrian Farrel; Anca Zamfir (ancaz);=20 > > Jean Philippe Vasseur (jvasseur); Kireeti Kompella > > Subject: Re: Need to close on signaling solution for graceful=20 > > shutdown (Follow-up on our Action Item) > >=20 > >=20 > > zafar - thanks for the summary ... but i don't understand the=20 > > following sentence > >=20 > > "The IGP based solution is also based on an existing framework." > >=20 > > to which framework are you referring to ? > >=20 > > i am more concerned with section 4.2, for three reasons > >=20 > > o) the document seems to say that such links could be used as=20 > > last resort link for zero bandwidth LSP - note that this=20 > > applies only to PSC links because non-PSC would not make use=20 > > of such links - let's assume this may be the case, as you are=20 > > dealing with a "planned outage" i am not sure you are going=20 > > to make a lot of operations such as new path computations=20 > > during such event (and risk further degradation) > >=20 >=20 > A link may end-up with max metric for multiple reasons and without the > link attribute there is no way a node can tell what the=20 > reason is, e.g. > a restarting node may advertises the max matrices. Furthermore, if the > resource under graceful deletion is the last resort then the node > hosting the graceful deletion resource will not receive new signaling > messages. Also, graceful deletion is not the main motivation for the > introduction of the link attribute sub-TLV; we are just=20 > overloading the > use of link attribute to provide a cleaner specification. Hence, I > mention "existing framework". We can enhance the text in the ID to be > more specific in this notification.=20 >=20 > > o) the document makes use of a link attribute (but where is=20 > > this attribute defined ?) > >=20 >=20 > The link attribute ID-es needs to be refreshed.=20 >=20 > > o) this section forces to have to have two different=20 > > procedures (as planned restarting nodes advertise their link=20 > > with these attributes making them unusable before the restart=20 > > occurs, section 2 of RFC4203) > >=20 >=20 > See my comment above.=20 >=20 > > thanks, > > - dimitri. > >=20 > >=20 > > Zafar Ali (zali) wrote: > >=20 > > > Dear Ccampers: > > >=20 > > >=20 > > >=20 > > > This is a follow-up on our action item from the last IETF=20 > > meeting to=20 > > > send an email to close the signaling solution for=20 > graceful shutdown=20 > > > procedure proposed in=20 > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > > do > > > wn-02.txt > > >=20 > >=20 > > > td > > > own-02.txt> .=20 > > >=20 > > >=20 > > >=20 > > > During the meeting it was clear that we have an agreement on the=20 > > > requirement front. We also have an agreement that we need=20 > > both routing=20 > > > and signaling based solutions. This is because an IGP only based=20 > > > solution is not applicable when dealing with Inter-area and=20 > > Inter-AS=20 > > > traffic engineering, as LSA or LSP flooding is restricted to IGP=20 > > > areas/levels. Consequently, RSVP based mechanisms are=20 > > required to cope=20 > > > with TE LSPs spanning multiple domains. The draft presents=20 > > > complementary mechanisms for RSVP-TE and IGP for Graceful=20 > Shutdown.=20 > > > The IGP based solution is also based on an existing=20 > framework. Our=20 > > > action item is to close on the signaling based counterpart. > > >=20 > > >=20 > > >=20 > > > Before we compare the candidate solution, let's discuss and=20 > > agree on=20 > > > general requirement for a signaling based graceful shutdown=20 > > mechanism. > > > In graceful shutdown procedure, as the Ingress LSR is expected to=20 > > > perform make-before-break for the LSP (using the resource that is=20 > > > being shutdown), we should be able to specify the TE=20 > > resource (link/=20 > > > node) under graceful shutdown. Furthermore, conveying signaling=20 > > > message to the Ingress LSR suffices. I.e., we can make use=20 > > of the Notify Message. > > >=20 > > >=20 > > >=20 > > > One of the solutions proposed during these discussions is=20 > > to make use=20 > > > of the admin status object. However, admin status cannot contain=20 > > > information about TE resource under Graceful Shutdown.=20 > > Hence, we did=20 > > > not consider use of admin status object as a possible solution. > > >=20 > > >=20 > > >=20 > > > Another alternate that was put forward is the use ALARM_=20 > > SPEC Objects. > > > While ALARM_ SPEC Objects has ability to Signal Info about=20 > > TE resource=20 > > > under Graceful shutdown, use of this object in the notify=20 > > message is=20 > > > not defined. We also feel use of the ALARM_ SPEC Objects is=20 > > heavy duty=20 > > > for signaling simple Graceful Shutdown condition. > > >=20 > > >=20 > > >=20 > > > We propose to overload "TE link maintenance required"=20 > > sub-code of the=20 > > > Notify Error Code (24) of the ERROR_SPEC. We believe this is the=20 > > > simplest solution with existing/ well used way to signal=20 > > information=20 > > > about TE resource under Graceful Shutdown. Furthermore, the=20 > > ERROR_SPEC=20 > > > with code 24/ sub-code TBD can then be carried in either=20 > PathErr or=20 > > > Notify message to signal graceful condition. > > >=20 > > >=20 > > >=20 > > > Can you please send your comments to this by the end of=20 > > this week so=20 > > > we can update the ID, if needed? > > >=20 > > >=20 > > >=20 > > > Thanks > > >=20 > > >=20 > > >=20 > > > Regards... Zafar > > >=20 > > > This is a follow-up on our action item from the last IETF=20 > > meeting to=20 > > > send an email to close the signaling solution for=20 > graceful shutdown=20 > > > procedure proposed in=20 > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > > do > > > wn-02.txt.=20 > > >=20 > > >=20 > > >=20 > > > During the meeting it was clear that we have an agreement on the=20 > > > requirement front. We also have an agreement that we need=20 > > both routing=20 > > > and signaling based solutions. This is because an IGP only based=20 > > > solution is not applicable when dealing with Inter-area and=20 > > Inter-AS=20 > > > traffic engineering, as LSA or LSP flooding is restricted to IGP=20 > > > areas/levels. Consequently, RSVP based mechanisms are=20 > > required to cope=20 > > > with TE LSPs spanning multiple domains. The draft presents=20 > > > complementary mechanisms for RSVP-TE and IGP for Graceful=20 > Shutdown.=20 > > > The IGP based solution is also based on an existing=20 > framework. Our=20 > > > action item is to close on the signaling based counterpart. > > >=20 > > >=20 > > >=20 > > > Before we compare the candidate solution, let's discuss and=20 > > agree on=20 > > > general requirement for a signaling based graceful shutdown=20 > > mechanism. > > > In graceful shutdown procedure, as the Ingress LSR is expected to=20 > > > perform make-before-break for the LSP (using the resource that is=20 > > > being shutdown), we should be able to specify the TE=20 > > resource (link/=20 > > > node) under graceful shutdown. Furthermore, conveying signaling=20 > > > message to the Ingress LSR suffices. I.e., we can make use=20 > > of the Notify Message. > > >=20 > > >=20 > > >=20 > > > One of the solutions proposed during these discussions is=20 > > to make use=20 > > > of the admin status object. However, admin status cannot contain=20 > > > information about TE resource under Graceful Shutdown.=20 > > Hence, we did=20 > > > not consider use of admin status object as a possible solution. > > >=20 > > >=20 > > >=20 > > > Another alternate that was put forward is the use ALARM_=20 > > SPEC Objects. > > > While ALARM_ SPEC Objects has ability to Signal Info about=20 > > TE resource=20 > > > under Graceful shutdown, use of this object in the notify=20 > > message is=20 > > > not defined. We also feel use of the ALARM_ SPEC Objects is=20 > > heavy duty=20 > > > for signaling simple Graceful Shutdown condition. > > >=20 > > >=20 > > >=20 > > > We propose to overload "TE link maintenance required"=20 > > sub-code of the=20 > > > Notify Error Code (24) of the ERROR_SPEC. We believe this is the=20 > > > simplest solution with existing/ well used way to signal=20 > > information=20 > > > about TE resource under Graceful Shutdown. Furthermore, the=20 > > ERROR_SPEC=20 > > > with code 24/ sub-code TBD can then be carried in either=20 > PathErr or=20 > > > Notify message to signal graceful condition. > > >=20 > > >=20 > > >=20 > > > Can you please send your comments to this by the end of=20 > > this week so=20 > > > we can update the ID, if needed? > > >=20 > > >=20 > > >=20 > > > Thanks > > >=20 > > >=20 > > >=20 > > > Regards... Zafar > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 Mar 2006 23:50:29 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-13.txt Message-Id: Date: Fri, 03 Mar 2006 18:50:02 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-te-mib-13.txt Pages : 60 Date : 2006-3-3 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-te-mib-13.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-te-mib-13.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: <2006-3-3153647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-3153647.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 Mar 2006 23:50:21 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-11.txt Message-Id: Date: Fri, 03 Mar 2006 18:50:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-lsr-mib-11.txt Pages : 42 Date : 2006-3-3 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-lsr-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-3151450.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-3151450.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 Mar 2006 23:47:20 +0000 To: "Zafar Ali \(zali\)" Cc: "Adrian Farrel" , "Anca Zamfir \(ancaz\)" , ccamp@ops.ietf.org, dpapadimitriou@psg.com, "Jean Philippe Vasseur \(jvasseur\)" , "Kireeti Kompella" , owner-ccamp@ops.ietf.org Subject: RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sat, 4 Mar 2006 00:45:59 +0100 Content-Type: text/plain; charset="US-ASCII" hi zafar then i will express my concern in the other way around concerning the "routing" part of this document: we have clean procedures for planned node restart in RFC4203; hence, the reason for having a "cleaner" procedure is totally unclear to me both in terms of motivation and applicability much thanks, - dimitri. "Zafar Ali \(zali\)" Sent by: owner-ccamp@ops.ietf.org 02/03/2006 07:06 To: , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: , "Adrian Farrel" , "Anca Zamfir \(ancaz\)" , "Jean Philippe Vasseur \(jvasseur\)" , "Kireeti Kompella" Subject: RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) Hi Dimitri, Sorry for the delay in replying. Please see reply in-line. All, I am assuming the WG is ok with the signaling part of the solution. If you have any comments, please reply to my original email. We plan to refresh the ID before the flood gate closes. Thanks Regards... Zafar > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Sent: Monday, February 20, 2006 2:01 AM > To: Zafar Ali (zali) > Cc: ccamp@ops.ietf.org; Adrian Farrel; Anca Zamfir (ancaz); > Jean Philippe Vasseur (jvasseur); Kireeti Kompella > Subject: Re: Need to close on signaling solution for graceful > shutdown (Follow-up on our Action Item) > > > zafar - thanks for the summary ... but i don't understand the > following sentence > > "The IGP based solution is also based on an existing framework." > > to which framework are you referring to ? > > i am more concerned with section 4.2, for three reasons > > o) the document seems to say that such links could be used as > last resort link for zero bandwidth LSP - note that this > applies only to PSC links because non-PSC would not make use > of such links - let's assume this may be the case, as you are > dealing with a "planned outage" i am not sure you are going > to make a lot of operations such as new path computations > during such event (and risk further degradation) > A link may end-up with max metric for multiple reasons and without the link attribute there is no way a node can tell what the reason is, e.g. a restarting node may advertises the max matrices. Furthermore, if the resource under graceful deletion is the last resort then the node hosting the graceful deletion resource will not receive new signaling messages. Also, graceful deletion is not the main motivation for the introduction of the link attribute sub-TLV; we are just overloading the use of link attribute to provide a cleaner specification. Hence, I mention "existing framework". We can enhance the text in the ID to be more specific in this notification. > o) the document makes use of a link attribute (but where is > this attribute defined ?) > The link attribute ID-es needs to be refreshed. > o) this section forces to have to have two different > procedures (as planned restarting nodes advertise their link > with these attributes making them unusable before the restart > occurs, section 2 of RFC4203) > See my comment above. > thanks, > - dimitri. > > > Zafar Ali (zali) wrote: > > > Dear Ccampers: > > > > > > > > This is a follow-up on our action item from the last IETF > meeting to > > send an email to close the signaling solution for graceful shutdown > > procedure proposed in > > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > do > > wn-02.txt > > > > td > > own-02.txt> . > > > > > > > > During the meeting it was clear that we have an agreement on the > > requirement front. We also have an agreement that we need > both routing > > and signaling based solutions. This is because an IGP only based > > solution is not applicable when dealing with Inter-area and > Inter-AS > > traffic engineering, as LSA or LSP flooding is restricted to IGP > > areas/levels. Consequently, RSVP based mechanisms are > required to cope > > with TE LSPs spanning multiple domains. The draft presents > > complementary mechanisms for RSVP-TE and IGP for Graceful Shutdown. > > The IGP based solution is also based on an existing framework. Our > > action item is to close on the signaling based counterpart. > > > > > > > > Before we compare the candidate solution, let's discuss and > agree on > > general requirement for a signaling based graceful shutdown > mechanism. > > In graceful shutdown procedure, as the Ingress LSR is expected to > > perform make-before-break for the LSP (using the resource that is > > being shutdown), we should be able to specify the TE > resource (link/ > > node) under graceful shutdown. Furthermore, conveying signaling > > message to the Ingress LSR suffices. I.e., we can make use > of the Notify Message. > > > > > > > > One of the solutions proposed during these discussions is > to make use > > of the admin status object. However, admin status cannot contain > > information about TE resource under Graceful Shutdown. > Hence, we did > > not consider use of admin status object as a possible solution. > > > > > > > > Another alternate that was put forward is the use ALARM_ > SPEC Objects. > > While ALARM_ SPEC Objects has ability to Signal Info about > TE resource > > under Graceful shutdown, use of this object in the notify > message is > > not defined. We also feel use of the ALARM_ SPEC Objects is > heavy duty > > for signaling simple Graceful Shutdown condition. > > > > > > > > We propose to overload "TE link maintenance required" > sub-code of the > > Notify Error Code (24) of the ERROR_SPEC. We believe this is the > > simplest solution with existing/ well used way to signal > information > > about TE resource under Graceful Shutdown. Furthermore, the > ERROR_SPEC > > with code 24/ sub-code TBD can then be carried in either PathErr or > > Notify message to signal graceful condition. > > > > > > > > Can you please send your comments to this by the end of > this week so > > we can update the ID, if needed? > > > > > > > > Thanks > > > > > > > > Regards... Zafar > > > > This is a follow-up on our action item from the last IETF > meeting to > > send an email to close the signaling solution for graceful shutdown > > procedure proposed in > > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > do > > wn-02.txt. > > > > > > > > During the meeting it was clear that we have an agreement on the > > requirement front. We also have an agreement that we need > both routing > > and signaling based solutions. This is because an IGP only based > > solution is not applicable when dealing with Inter-area and > Inter-AS > > traffic engineering, as LSA or LSP flooding is restricted to IGP > > areas/levels. Consequently, RSVP based mechanisms are > required to cope > > with TE LSPs spanning multiple domains. The draft presents > > complementary mechanisms for RSVP-TE and IGP for Graceful Shutdown. > > The IGP based solution is also based on an existing framework. Our > > action item is to close on the signaling based counterpart. > > > > > > > > Before we compare the candidate solution, let's discuss and > agree on > > general requirement for a signaling based graceful shutdown > mechanism. > > In graceful shutdown procedure, as the Ingress LSR is expected to > > perform make-before-break for the LSP (using the resource that is > > being shutdown), we should be able to specify the TE > resource (link/ > > node) under graceful shutdown. Furthermore, conveying signaling > > message to the Ingress LSR suffices. I.e., we can make use > of the Notify Message. > > > > > > > > One of the solutions proposed during these discussions is > to make use > > of the admin status object. However, admin status cannot contain > > information about TE resource under Graceful Shutdown. > Hence, we did > > not consider use of admin status object as a possible solution. > > > > > > > > Another alternate that was put forward is the use ALARM_ > SPEC Objects. > > While ALARM_ SPEC Objects has ability to Signal Info about > TE resource > > under Graceful shutdown, use of this object in the notify > message is > > not defined. We also feel use of the ALARM_ SPEC Objects is > heavy duty > > for signaling simple Graceful Shutdown condition. > > > > > > > > We propose to overload "TE link maintenance required" > sub-code of the > > Notify Error Code (24) of the ERROR_SPEC. We believe this is the > > simplest solution with existing/ well used way to signal > information > > about TE resource under Graceful Shutdown. Furthermore, the > ERROR_SPEC > > with code 24/ sub-code TBD can then be carried in either PathErr or > > Notify message to signal graceful condition. > > > > > > > > Can you please send your comments to this by the end of > this week so > > we can update the ID, if needed? > > > > > > > > Thanks > > > > > > > > Regards... Zafar > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 Mar 2006 18:15:50 +0000 Message-ID: <075e01c63eee$eca67bb0$10849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Joan Cucchiara" , "Wijnen, Bert \(Bert\)" , "Thomas D. Nadeau" , , "Bill Fenner" Subject: New revision of GMPLS TE MIB Date: Fri, 3 Mar 2006 18:17:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have just submitted a new revision of the GMPLS TE MIB (draft-ietf-ccamp-gmpls-te-mib-13.txt) which should be posted soon. The changes are to complete the markups from MIB Doctor review and comprise changes to the conformance and compliance sections of the MIB module as requested. I have also made the following changes: - added comments to IANAGmplsGeneralizedPid to highlight the lacunae. - updated references to RFC 4328 - correct possible settings of mplsTunnelIsIf which is TruthValue - retire gmplsTunnelIsNotIntfcGroup which had become empty - correct the example to use gmplsTunnelSendPathNotifyRecipientType and gmplsTunnelSendPathNotifyRecipient - correct the hex value of an IP address in the example We will show this to the MIB Doctors to check that they are happy with all of our changes, and then get the IESG process into motion. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 Mar 2006 16:45:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Draft on 1+1.. Date: Fri, 3 Mar 2006 08:44:31 -0800 Message-ID: Thread-Topic: Draft on 1+1.. Thread-Index: AcY+4b66bFNzgOjlSsWkbze1HTNgNQ== From: "Suresh Katukam \(skatukam\)" To: Hi, There was a proposal by Lucent (I believe) about using 1+1 mechanism in data networks. I believe they proposed that source and destination set up two tunnels, and add seq# to each packet in the tunnel and let the destination decide which stream to use. I have been searching for that draft and could not find. Can you please let me know where can I find it. Thanks, Suresh Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 Mar 2006 15:59:03 +0000 Message-ID: <070701c63edb$bdf04d40$10849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Joan Cucchiara" , "Wijnen, Bert \(Bert\)" , "Thomas D. Nadeau" , , "Bill Fenner" Subject: New version of GMPLS LSR MIB Date: Fri, 3 Mar 2006 15:58:50 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have just submitted a new revision of the GMPLS LSR MIB (draft-ietf-ccamp-gmpls-lsr-mib-11.txt) which should be posted soon. The changes are to complete the markups from MIB Doctor review and comprise changes to the conformance and compliance sections of the MIB module as requested. We will show this to the MIB Doctors to check that they are happy with all of our changes, and then get the IESG process into motion. Adrian PS. No changes to the TC MIB. PPS. Changes to the TE MIB to be submitted soon. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 Mar 2006 06:09:50 +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: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) Date: Thu, 2 Mar 2006 01:06:40 -0500 Message-ID: Thread-Topic: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item) Thread-Index: AcY161v77cM87dtLQnqQTOffRmxjagH0WKXg From: "Zafar Ali \(zali\)" To: , Cc: , "Adrian Farrel" , "Anca Zamfir \(ancaz\)" , "Jean Philippe Vasseur \(jvasseur\)" , "Kireeti Kompella" Hi Dimitri,=20 Sorry for the delay in replying. Please see reply in-line.=20 All,=20 I am assuming the WG is ok with the signaling part of the solution. If you have any comments, please reply to my original email. We plan to refresh the ID before the flood gate closes.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Sent: Monday, February 20, 2006 2:01 AM > To: Zafar Ali (zali) > Cc: ccamp@ops.ietf.org; Adrian Farrel; Anca Zamfir (ancaz);=20 > Jean Philippe Vasseur (jvasseur); Kireeti Kompella > Subject: Re: Need to close on signaling solution for graceful=20 > shutdown (Follow-up on our Action Item) >=20 >=20 > zafar - thanks for the summary ... but i don't understand the=20 > following sentence >=20 > "The IGP based solution is also based on an existing framework." >=20 > to which framework are you referring to ? >=20 > i am more concerned with section 4.2, for three reasons >=20 > o) the document seems to say that such links could be used as=20 > last resort link for zero bandwidth LSP - note that this=20 > applies only to PSC links because non-PSC would not make use=20 > of such links - let's assume this may be the case, as you are=20 > dealing with a "planned outage" i am not sure you are going=20 > to make a lot of operations such as new path computations=20 > during such event (and risk further degradation) >=20 A link may end-up with max metric for multiple reasons and without the link attribute there is no way a node can tell what the reason is, e.g. a restarting node may advertises the max matrices. Furthermore, if the resource under graceful deletion is the last resort then the node hosting the graceful deletion resource will not receive new signaling messages. Also, graceful deletion is not the main motivation for the introduction of the link attribute sub-TLV; we are just overloading the use of link attribute to provide a cleaner specification. Hence, I mention "existing framework". We can enhance the text in the ID to be more specific in this notification.=20 > o) the document makes use of a link attribute (but where is=20 > this attribute defined ?) >=20 The link attribute ID-es needs to be refreshed.=20 > o) this section forces to have to have two different=20 > procedures (as planned restarting nodes advertise their link=20 > with these attributes making them unusable before the restart=20 > occurs, section 2 of RFC4203) >=20 See my comment above.=20 > thanks, > - dimitri. >=20 >=20 > Zafar Ali (zali) wrote: >=20 > > Dear Ccampers: > >=20 > > =20 > >=20 > > This is a follow-up on our action item from the last IETF=20 > meeting to=20 > > send an email to close the signaling solution for graceful shutdown=20 > > procedure proposed in=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > do > > wn-02.txt > >=20 > > td > > own-02.txt> .=20 > >=20 > > =20 > >=20 > > During the meeting it was clear that we have an agreement on the=20 > > requirement front. We also have an agreement that we need=20 > both routing=20 > > and signaling based solutions. This is because an IGP only based=20 > > solution is not applicable when dealing with Inter-area and=20 > Inter-AS=20 > > traffic engineering, as LSA or LSP flooding is restricted to IGP=20 > > areas/levels. Consequently, RSVP based mechanisms are=20 > required to cope=20 > > with TE LSPs spanning multiple domains. The draft presents=20 > > complementary mechanisms for RSVP-TE and IGP for Graceful Shutdown.=20 > > The IGP based solution is also based on an existing framework. Our=20 > > action item is to close on the signaling based counterpart. > >=20 > > =20 > >=20 > > Before we compare the candidate solution, let's discuss and=20 > agree on=20 > > general requirement for a signaling based graceful shutdown=20 > mechanism. > > In graceful shutdown procedure, as the Ingress LSR is expected to=20 > > perform make-before-break for the LSP (using the resource that is=20 > > being shutdown), we should be able to specify the TE=20 > resource (link/=20 > > node) under graceful shutdown. Furthermore, conveying signaling=20 > > message to the Ingress LSR suffices. I.e., we can make use=20 > of the Notify Message. > >=20 > > =20 > >=20 > > One of the solutions proposed during these discussions is=20 > to make use=20 > > of the admin status object. However, admin status cannot contain=20 > > information about TE resource under Graceful Shutdown.=20 > Hence, we did=20 > > not consider use of admin status object as a possible solution. > >=20 > > =20 > >=20 > > Another alternate that was put forward is the use ALARM_=20 > SPEC Objects. > > While ALARM_ SPEC Objects has ability to Signal Info about=20 > TE resource=20 > > under Graceful shutdown, use of this object in the notify=20 > message is=20 > > not defined. We also feel use of the ALARM_ SPEC Objects is=20 > heavy duty=20 > > for signaling simple Graceful Shutdown condition. > >=20 > > =20 > >=20 > > We propose to overload "TE link maintenance required"=20 > sub-code of the=20 > > Notify Error Code (24) of the ERROR_SPEC. We believe this is the=20 > > simplest solution with existing/ well used way to signal=20 > information=20 > > about TE resource under Graceful Shutdown. Furthermore, the=20 > ERROR_SPEC=20 > > with code 24/ sub-code TBD can then be carried in either PathErr or=20 > > Notify message to signal graceful condition. > >=20 > > =20 > >=20 > > Can you please send your comments to this by the end of=20 > this week so=20 > > we can update the ID, if needed? > >=20 > > =20 > >=20 > > Thanks > >=20 > > =20 > >=20 > > Regards... Zafar > >=20 > > This is a follow-up on our action item from the last IETF=20 > meeting to=20 > > send an email to close the signaling solution for graceful shutdown=20 > > procedure proposed in=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut > > do > > wn-02.txt.=20 > >=20 > > =20 > >=20 > > During the meeting it was clear that we have an agreement on the=20 > > requirement front. We also have an agreement that we need=20 > both routing=20 > > and signaling based solutions. This is because an IGP only based=20 > > solution is not applicable when dealing with Inter-area and=20 > Inter-AS=20 > > traffic engineering, as LSA or LSP flooding is restricted to IGP=20 > > areas/levels. Consequently, RSVP based mechanisms are=20 > required to cope=20 > > with TE LSPs spanning multiple domains. The draft presents=20 > > complementary mechanisms for RSVP-TE and IGP for Graceful Shutdown.=20 > > The IGP based solution is also based on an existing framework. Our=20 > > action item is to close on the signaling based counterpart. > >=20 > > =20 > >=20 > > Before we compare the candidate solution, let's discuss and=20 > agree on=20 > > general requirement for a signaling based graceful shutdown=20 > mechanism. > > In graceful shutdown procedure, as the Ingress LSR is expected to=20 > > perform make-before-break for the LSP (using the resource that is=20 > > being shutdown), we should be able to specify the TE=20 > resource (link/=20 > > node) under graceful shutdown. Furthermore, conveying signaling=20 > > message to the Ingress LSR suffices. I.e., we can make use=20 > of the Notify Message. > >=20 > > =20 > >=20 > > One of the solutions proposed during these discussions is=20 > to make use=20 > > of the admin status object. However, admin status cannot contain=20 > > information about TE resource under Graceful Shutdown.=20 > Hence, we did=20 > > not consider use of admin status object as a possible solution. > >=20 > > =20 > >=20 > > Another alternate that was put forward is the use ALARM_=20 > SPEC Objects. > > While ALARM_ SPEC Objects has ability to Signal Info about=20 > TE resource=20 > > under Graceful shutdown, use of this object in the notify=20 > message is=20 > > not defined. We also feel use of the ALARM_ SPEC Objects is=20 > heavy duty=20 > > for signaling simple Graceful Shutdown condition. > >=20 > > =20 > >=20 > > We propose to overload "TE link maintenance required"=20 > sub-code of the=20 > > Notify Error Code (24) of the ERROR_SPEC. We believe this is the=20 > > simplest solution with existing/ well used way to signal=20 > information=20 > > about TE resource under Graceful Shutdown. Furthermore, the=20 > ERROR_SPEC=20 > > with code 24/ sub-code TBD can then be carried in either PathErr or=20 > > Notify message to signal graceful condition. > >=20 > > =20 > >=20 > > Can you please send your comments to this by the end of=20 > this week so=20 > > we can update the ID, if needed? > >=20 > > =20 > >=20 > > Thanks > >=20 > > =20 > >=20 > > Regards... Zafar > >=20 > > =20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Mar 2006 12:53:49 +0000 Content-Class: urn:content-classes:message Message-ID: <434F1CE611459F45BBC351FEB5A83F435715B2@kavithai.ctd.hcltech.com> From: "Vijayanand C - CTD, Chennai." Content-Transfer-Encoding: quoted-printable To: "Arthi Ayyangar" , Subject: RE: Inter-domain FRR Facility backup - discussion Date: Wed, 1 Mar 2006 18:21:50 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Can the ASBR help out here: - Can it advertise a route with itself as the next hop for the PLR into = the MPs domain whenever it sees a bypass tunnels path msg going through it ? First of all, how is the bypass itself signalled without any issues ? = The PLR wont know the topology of the other domain to route the path msg to = the MP in a node disjoint way. Regards, Vijay > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Arthi Ayyangar > Sent: Tuesday, February 28, 2006 1:25 PM > To: ccamp@ops.ietf.org > Subject: Inter-domain FRR Facility backup - discussion >=20 >=20 > Hi, >=20 > Currently the merging of Backup Paths using the Sender=20 > Template-specific=20 > method relies on a different src address, but same LSP ID in the=20 > SENDER_TEMPLATE for the backup LSP compared to that of the=20 > protected LSP.=20 > (6.1.1 of rfc 4090). After a failure, during local repair,=20 > backup LSP Path=20 > msgs are "tunneled" over the bypass directly to the MP and=20 > the Resv from=20 > MP is IP routed back to the address set in the RSVP_HOP=20 > (6.4.3) of the=20 > backup LSP. >=20 > As per the spec, the src address used for backup LSP has to be some=20 > address on the PLR. I am not sure what the usual practice is,=20 > but from=20 > what I understand, it would be okay currently, to put any=20 > local interface=20 > address on the PLR in the RSVP_HOP as per the spec. >=20 > However, when the bypass LSP traverses different domains, and=20 > the PLR and=20 > MP are internal nodes in different domains, the MP is=20 > unlikely to have a=20 > route back to the interface address set in the RSVP_HOP for=20 > the backup=20 > LSP. So it will be unable to route back the Resv to the PLR.=20 > This will=20 > prevent the backup LSP from coming up. >=20 > So the issue is finding a way to route back the Resv from MP to PLR. >=20 > We could say that in case of inter-domain LSPs, the address=20 > that the PLR=20 > chooses should be the router-id of the PLR. But this has the=20 > following=20 > issues:- > i) If we wan't specific behavior recommendation for inter-domain LSPs, > then we need to specify conditions to define an LSP as an=20 > inter-domain > LSP at an LSR. > ii) Using router id could increase the chances of this sender template > (src addr + lsp id) being confused with that of some=20 > other LSP being > originated from this router and terminating on the MP. > ii) For inter-AS LSPs, it may not be common for nodes inside one AS to > have routes to router-ids (or loopbacks) of "internal nodes" in > another AS. >=20 > Do you see this as an issue worthy of discussion ? > Any ideas / suggestions / recommendations ? >=20 > thanks, > -arthi >=20 DISCLAIMER=20 This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies=20 and its customers. Contents may be privileged or otherwise protected by = law. The information is solely intended for the=20 individual or the entity it is addressed to. If you are not the intended = recipient of this message, you are not authorized to=20 read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error,=20 please notify the sender immediately by return e-mail and delete it from = your computer Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Mar 2006 06:34:47 +0000 Date: Tue, 28 Feb 2006 22:32:08 -0800 (PST) From: Arthi Ayyangar To: ccamp@ops.ietf.org Subject: Recording AS Hops in RRO - discussion Message-ID: <20060228223048.A14076@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Re-sending. Didn't see this appear on the list. -arthi ---------- Forwarded message ---------- Date: Tue, 28 Feb 2006 00:11:11 -0800 (PST) From: Arthi Ayyangar To: ccamp@ops.ietf.org Subject: Recording AS Hops in RRO - discussion Hi, As per RFC 3209, there exists a provision to add AS number hops in ERO as sub-objects. This definitely has usage in inter-AS LSPs, so a user may configure AS hops to direct an LSP through a specific AS path. However, from what I have checked, currently there is no provision to record AS numbers in the RRO. If this provision already exists and I missed it, do point me to it. Else, do you think this would be useful to have ? We say that it would be useful to aggregate /modify RROs sent out of an AS for confidentiality. Would adding AS number sub-oject to RRO help ? Would it also help in identifying loops involving LSPs traversing same AS more than once ? thanks, -arthi