From routing-discussion-bounces@ietf.org Wed Oct 6 09:47:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25992 for ; Wed, 6 Oct 2004 09:47:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFC4n-0000R8-41; Wed, 06 Oct 2004 09:43:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBzr-00089z-U8 for routing-discussion@megatron.ietf.org; Wed, 06 Oct 2004 09:38:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25339 for ; Wed, 6 Oct 2004 09:38:21 -0400 (EDT) Received: from [202.54.124.145] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFC9A-0002q3-N3 for routing-discussion@ietf.org; Wed, 06 Oct 2004 09:48:12 -0400 Received: (qmail 16551 invoked by uid 510); 6 Oct 2004 13:37:21 -0000 Date: 6 Oct 2004 13:37:21 -0000 Message-ID: <20041006133721.16550.qmail@webmail30.rediffmail.com> Received: from unknown (203.200.200.162) by rediffmail.com via HTTP; 06 oct 2004 13:37:21 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" To: routing-discussion@ietf.org X-Spam-Score: 1.8 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: Regarding OSPFv2 Graceful Restart X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Karthikeyan Subramaniam List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0953080686==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org This is a multipart mime message --===============0953080686== Content-type: multipart/alternative; boundary="Next_1097069841---0-202.54.124.145-16548" This is a multipart mime message --Next_1097069841---0-202.54.124.145-16548 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A  Hello,
=0A
=0AAccording to the RFC 3623, Grace LSA is li= nk local opaque LSA.
=0A
=0ACosider the below scenario in which all = routers are configured in same area,
=0A
=0AR1----------R2-----------= ---------R3
=0A
=0AR3 is going for graceful restart and R2 is in help= er mode. Let us assume all routers have R3 LSA with age 3500 (3600 being th= e MaxAge). Now R3 is undergoing graceful restart for a Grace Period of 200s= . Meanwhile R3 LSA in R1 would have been purged. In such a case packet dest= ined for networks reachable via R3 will be dropped at R1..
=0A
=0AHow= RFC 3623 provides solution for this??
=0A
=0ATIA
=0AKarthik
= =0A=0A

=0A=0A=0A
=0A

=0A=0A --Next_1097069841---0-202.54.124.145-16548 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0Hello,=0A=0AAccording to the RFC 3623, Grace LSA is link local opaque L= SA. =0A=0ACosider the below scenario in which all routers are configured in= same area,=0A=0AR1----------R2--------------------R3=0A=0AR3 is going for = graceful restart and R2 is in helper mode. Let us assume all routers have R= 3 LSA with age 3500 (3600 being the MaxAge). Now R3 is undergoing graceful = restart for a Grace Period of 200s. Meanwhile R3 LSA in R1 would have been = purged. In such a case packet destined for networks reachable via R3 will b= e dropped at R1..=0A=0AHow RFC 3623 provides solution for this??=0A=0ATIA= =0AKarthik=0A=0A=0A=0A --Next_1097069841---0-202.54.124.145-16548-- --===============0953080686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion --===============0953080686==-- From routing-discussion-bounces@ietf.org Wed Oct 13 19:18:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24274 for ; Wed, 13 Oct 2004 19:18:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHsHi-0001Uy-OW; Wed, 13 Oct 2004 19:11:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHs6b-00071H-Vq for routing-discussion@megatron.ietf.org; Wed, 13 Oct 2004 19:00:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22859 for ; Wed, 13 Oct 2004 19:00:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHsHc-0002ar-Nn for routing-discussion@ietf.org; Wed, 13 Oct 2004 19:11:51 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHs6Y-0008Jv-9l for routing-discussion@ietf.org; Wed, 13 Oct 2004 23:00:22 +0000 Date: Wed, 13 Oct 2004 16:00:21 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1496451534.20041013160021@psg.com> To: routing-discussion@ietf.org In-Reply-To: <200410122005.QAA27436@ietf.org> References: <200410122005.QAA27436@ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------8C10A441BDCF029" X-Spam-Score: 0.8 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: Ops and management section in RTG Area drafts X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org ------------8C10A441BDCF029 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Folks- The idea of an ops-n-management section in RTG documents has been floating around for a while. This should provide considerations on this matter. Please review and post comments to this list. Thanks. -- Alex http://www.psg.com/~zinin This is a forwarded message From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: Date: Tuesday, October 12, 2004, 1:05:06 PM Subject: I-D ACTION:draft-farrel-rtg-manageability-requirements-00.txt ===8<==============Original message text=============== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Manageability Sections in Routing Area Drafts Author(s) : A. Farrel, et al. Filename : draft-farrel-rtg-manageability-requirements-00.txt Pages : 6 Date : 2004-10-12 It has often been the case that manageability considerations have been retrofitted to protocols. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the requirement for all new Routing Area Internet-Drafts to include an "Manageability Considerations" section, and gives guidance on what that section should contain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farrel-rtg-manageability-requirements-00.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-farrel-rtg-manageability-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-farrel-rtg-manageability-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ===8<===========End of original message text=========== ------------8C10A441BDCF029 Content-Type: MESSAGE/EXTERNAL-BODY; name="1.msg" Content-Disposition: attachment; filename="1.msg" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2004-10-12160456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-farrel-rtg-manageability-requirements-00.txt ------------8C10A441BDCF029 Content-Type: MESSAGE/EXTERNAL-BODY; name="draft-farrel-rtg-manageability-requirements-00.txt" Content-Disposition: attachment; filename="draft-farrel-rtg-manageability-requirements-00.txt" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2004-10-12160456.I-D@ietf.org> ------------8C10A441BDCF029 Content-Type: TEXT/PLAIN; name="Part.txt" Content-Disposition: attachment; filename="Part.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------------8C10A441BDCF029 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ------------8C10A441BDCF029-- From routing-discussion-bounces@ietf.org Mon Oct 18 08:30:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11322 for ; Mon, 18 Oct 2004 08:30:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWWe-0000pP-ST; Mon, 18 Oct 2004 08:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTvn-0007vi-Td; Tue, 12 Oct 2004 17:11:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11040; Tue, 12 Oct 2004 17:11:38 -0400 (EDT) Received: from sa.infonet.com ([192.157.130.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHU6M-0002NG-KI; Tue, 12 Oct 2004 17:22:50 -0400 Received: from zhangr2.sa.infonet.com (sfjl161.us.info.net [204.79.139.161] (may be forged)) by sa.infonet.com with ESMTP id i9CLBKOA023203; Tue, 12 Oct 2004 21:11:20 GMT Message-Id: <6.0.3.0.2.20041012135124.03d399c8@sa.infonet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 12 Oct 2004 14:10:02 -0700 To: Adrian Farrel , , From: raymond zhang In-Reply-To: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> References: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Mon, 18 Oct 2004 08:22:07 -0400 Cc: ccamp@ops.ietf.org, mpls@ietf.org, pce@ietf.org Subject: Re: [mpls] Mailing List for Path Computation Element (PCE) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Hi Adrian, JP, Jerry, I've gone through the I-D "draft-ash-pce-architecture-00.txt" and I think this document has very well stated the architectural objectives and need for a separate WG for this area. Also please find some minor comments below: - section 3. Definitions " Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. The PCE entity can be located within an application" (RZ: I'd suggest some rewording here: The PCE entity is an application process that can be located on a network node or component, on an out-of- network server, etc.) - Page 4, first paragraph: 1) Path computation is applicable in both intra-domain, inter-domain, and inter-layer contexts. Inter-domain path computation may involve the correlation of topology and routing information between domains. Overlapping domains are not within the scope of this document. In the inter-domain case, the domains may belong to a single or multiple (RZ:"inter-layer contexts" is mentioned at the beginning of this paragraph so it would be good to explain this a bit as did for inter-domain) - Page 4. 3) "Centralized computation model" ... There would (RZ: add "be")... - Page 6, 2nd paragraph: (RZ: From SP's perspective, it is not a difficult thing to migrate a legacy IGP plane, e.g. ISIS with narrow metrics to a new ISIS plane supporting TE ext. So I dont seem to see a strong case for this...) - Page 6, section 4.4. (RZ: there maybe some inconsistence here to say on one hand this scenario does not relay on loose hops, yet on the other hand PCE based solution provides loose hops in the computed paths ?) - Page 7, section 5.1. 5.1. Composite PCE "Figure 1 below shows the components of a typical composite PCE node (that is, a router that also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the TED is constructed. Service requests are received by the node and converted into signaling requests" (RZ:it would be good to clarify between service requests to the PCE or inter- PCE requests and service requests to signal a TE-LSP request) ... - Page 12, first paragraph (RZ: It would be probably more appropriate to rename to this section to "Service Request/Response Synchronization" vs. "TED Sync" in a subsequent section. It may be more productive here in describing service request/reponse sync of PCC-PCE and PCE-PCE as part of the architectural discussion, rather than illustrating more detailed procedures since these procedures could be discussed in a detailed spec document in which it may transform to something different.) - page 13, 2nd paragrah: "No assumption is made at this stage about whether the PCC-PCE and PCE-PCE communication protocols are identical." (RZ: but I think it would be architectrually more scalable if they are same, so are such comments are warranted here (same protocols for both PCC-PCE/PCE-PCE...) in an arch doc ? - Section 6.8: (RZ: since this is an arch doc, does it imply that implementation of either scheme would meet the arch framework established here ?) - A general comment: there are a lot of very good, analytical discussions in the document presenting different cases. It would be good I think if the authors could provide some guidance in drawing up some architecture recommendations after comparing/analyzing some of these cases or simply say all cases presented in some of these sections are considered valid architectural options ? Regards, Raymond _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Fri Oct 22 19:23:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12884 for ; Fri, 22 Oct 2004 19:23:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8XR-0006IY-Sn; Fri, 22 Oct 2004 19:09:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8J1-0003aw-Ot for routing-discussion@megatron.ietf.org; Fri, 22 Oct 2004 18:54:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07963 for ; Fri, 22 Oct 2004 18:54:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8Vw-0007PX-Jn for routing-discussion@ietf.org; Fri, 22 Oct 2004 19:08:04 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL8J0-0006dX-Kz; Fri, 22 Oct 2004 22:54:42 +0000 Date: Fri, 22 Oct 2004 15:54:41 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1159144918.20041022155441@psg.com> To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , Loa Andersson Subject: RTGAREA meeting in DC X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Content-Transfer-Encoding: 7bit Folks- We will have the usual RTG Area meeting in DC. At this point, we have the following two items on the agenda: 1. Ops and management section in RTG Area drafts 2. (G)MPLS change process procedures If you would like to present something else, please send me an e-mail. -- Alex http://www.psg.com/~zinin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion