From curtis@occnc.com Mon Apr 4 13:31:35 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0A928C0E5 for ; Mon, 4 Apr 2011 13:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=-2.413, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF6WPA3npbYg for ; Mon, 4 Apr 2011 13:31:32 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 27C5428C0E2 for ; Mon, 4 Apr 2011 13:31:31 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p34KXDqG024310; Mon, 4 Apr 2011 16:33:13 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104042033.p34KXDqG024310@harbor.orleans.occnc.com> To: ospf@ietf.org From: Curtis Villamizar Date: Mon, 04 Apr 2011 16:33:13 -0400 Sender: curtis@occnc.com Subject: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:31:36 -0000 Has anyone measured the per hop flooding delay that is incurred in modern routers? If this is small compared to geographic delay (speed of light delay) then there is no need for this work. Many routers forward packets directly to a line card CPU and coordinate flooding among line card CPU processors, a bit like flooding inside the chassis. Worst case for a high priority process is about two interrupt times. Interrupt times on a modern CPU is about 100 usec. If there are a lot of LSA being flooded, then many LSA can be picked up in one system call if driver code is written to allow this. Even where this goes to the CPU, modern code is smart enough to have the SPF run in a different thread or process, so as not to hold up any further flooding. There was a presentation in NANOG on this topic about 5 years ago or more but I don't have a pointer to the URL at the moment. The assertion in the abstract that "The delay due to the involvement of the control-plane adversely affects OSPF convergence" is not supported in the draft and certainly not in my experience. The SPF time is typically long compared to the sum of per hop flooding delays due to hitting a CPU. Curtis From vishwas.ietf@gmail.com Mon Apr 4 13:34:30 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C49C3A67D3 for ; Mon, 4 Apr 2011 13:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Zs9sTmN7XXs for ; Mon, 4 Apr 2011 13:34:29 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 6D1B23A67D2 for ; Mon, 4 Apr 2011 13:34:29 -0700 (PDT) Received: by pvh1 with SMTP id 1so982355pvh.31 for ; Mon, 04 Apr 2011 13:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HUd7SmulLe6dJSk51McbIGAdOEiNnHh8EC6U2W27euc=; b=gNZKCfWQk3mA2qfRMUeN+2DohAjBpLwpD6hlHp1A1IwtOECMXy2zXyJn6HzCa7bJ3m RFfRKGQSFFpsaRhM/MTuHLN1+MpwGByQW8DCEZtZkitPUTM5mAx3r0DLhKESRoysGApf AZJMSh5ky4l2RL8LTGCoLRy8l8DoJvjmxlTZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e+Eo0X5w3Fd7E/vXYVxLbSbU8Z/yOOo5q39C2BRJvim4EvZtc0a8ORgBF9wvsR6jlX vDGrv2BfrNuEC/zWnW8uhmgUhTBDiMTsWNpHfBPiIKBBlzVbjYKLAsIwPWcwsjDfERcz BbcvjroTlvsbhErPMWnaj3axwigqr6IWHg8T4= MIME-Version: 1.0 Received: by 10.143.85.1 with SMTP id n1mr6773256wfl.349.1301949371905; Mon, 04 Apr 2011 13:36:11 -0700 (PDT) Received: by 10.68.43.71 with HTTP; Mon, 4 Apr 2011 13:36:11 -0700 (PDT) In-Reply-To: <201104042033.p34KXDqG024310@harbor.orleans.occnc.com> References: <201104042033.p34KXDqG024310@harbor.orleans.occnc.com> Date: Mon, 4 Apr 2011 13:36:11 -0700 Message-ID: From: Vishwas Manral To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Cc: ospf@ietf.org Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:34:30 -0000 On Mon, Apr 4, 2011 at 1:33 PM, Curtis Villamizar wrote: Hi Curtis, > Has anyone measured the per hop flooding delay that is incurred in > modern routers? >From the few we have worked, it works from 10's of nanoseconds to microseconds. You may see some work on http://tools.ietf.org/html/draft-manral-ospf-te-delay-00. We need to actually add per device delay to make the solution generic, which is what we are trying to work on. Thanks, Vishwas From sriganeshkini@gmail.com Mon Apr 4 14:34:10 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E629D3A677C for ; Mon, 4 Apr 2011 14:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di5Edd4xq4e5 for ; Mon, 4 Apr 2011 14:34:09 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id F36F23A66B4 for ; Mon, 4 Apr 2011 14:34:08 -0700 (PDT) Received: by qwc23 with SMTP id 23so738234qwc.31 for ; Mon, 04 Apr 2011 14:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=aoI4mSUvVNuNQiJm5guRFdAewgedp+dB1BCHoVyLHnw=; b=XoERQLHxGRimQJwfTqcrLtwH6jdbDLnwoTvaP4nSQz3T6btmx9myisGgX07YrLM4jb t/AABoRMM4QvALp2Zo9Z5ALtpIsVs+e48YYcHsq6cnltXU+OyYxusWw1fzl+5N1Q64Zv G+rS54PVLrGvrSosYawlxTBHx+OV+DFv/TAY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=id3wFBc8au3DHhLJqpQsKYD5xZnXfXWvS2jjdaA7LQSgqp1cAK/l6hC35U+BqACR93 n6zm1j96oh+eZPChGBwjcedAclYubon4+JLsTkMQvVoJCEM2OBkRYQvwMa2tGUSlvQ9J zSBn/9/+ElQtowW/D+ojUVduxNfD+SQcAo7u4= Received: by 10.229.102.73 with SMTP id f9mr5969328qco.168.1301952951258; Mon, 04 Apr 2011 14:35:51 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.231.143 with HTTP; Mon, 4 Apr 2011 14:35:21 -0700 (PDT) In-Reply-To: References: <201104042033.p34KXDqG024310@harbor.orleans.occnc.com> From: Sriganesh Kini Date: Mon, 4 Apr 2011 14:35:21 -0700 X-Google-Sender-Auth: 1jm9mh0CUpbZP_zpb84zJWO6Ijo Message-ID: To: Vishwas Manral Content-Type: text/plain; charset=ISO-8859-1 Cc: ospf@ietf.org Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 21:34:11 -0000 Vishwas, Your draft seems to be referring to the end-to-end delay of a packet forwarded entirely by data-plane. So those results would be applicable to the OSPF fast-notification. It would not be applicable to end-to-end delay of OSPF LSA flooding since the LSAs are processed at each hop by the control-plane. Curtis, The control-plane delays you haven't listed include sending LSUpdate from data-plane to control-plane and its processing such as authenticating, comparing against LSDB, sending LSAck (with potential re-transmission), queueing for further flooding (including re-transmit if timer expires), re-adding interface specific auth params etc. All of these need to be done at each intermediate hop as the LSA gets flooded and hence the delay is cumulative. These delays may not seem like much but it does add to the overall delay in convergence. The SPF by itself does not take that much time in modern CPUs but the download of routes certainly increases with number of downloads. However, modern forwarding architectures are such that in many failure conditions many downloads are not needed. A single download can change the nexthop of a large number of routes. In such conditions the hop-by-hop control-plane flooding does not remain an insignificant component of convergence. There will of course be networks where geographic delay itself may be large enough to dwarf all other numbers, but there are a lot of networks where that is not true. We will be updating the draft to support the assertions. Thanks On Mon, Apr 4, 2011 at 1:36 PM, Vishwas Manral wrote: > On Mon, Apr 4, 2011 at 1:33 PM, Curtis Villamizar wrote: > Hi Curtis, > >> Has anyone measured the per hop flooding delay that is incurred in >> modern routers? > > From the few we have worked, it works from 10's of nanoseconds to microseconds. > > You may see some work on > http://tools.ietf.org/html/draft-manral-ospf-te-delay-00. We need to > actually add per device delay to make the solution generic, which is > what we are trying to work on. > > Thanks, > Vishwas > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > -- - Sri From manav.bhatia@alcatel-lucent.com Mon Apr 4 16:57:36 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B5F3A6823 for ; Mon, 4 Apr 2011 16:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.704 X-Spam-Level: X-Spam-Status: No, score=-6.704 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkSqyqSFmTR7 for ; Mon, 4 Apr 2011 16:57:35 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C01063A6821 for ; Mon, 4 Apr 2011 16:57:35 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p34NxBf7003466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2011 18:59:13 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p34NxA4R010936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Apr 2011 05:29:10 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 5 Apr 2011 05:29:10 +0530 From: "Bhatia, Manav (Manav)" To: Sriganesh Kini , Vishwas Manral Date: Tue, 5 Apr 2011 05:29:16 +0530 Thread-Topic: [OSPF] draft-kini-ospf-fast-notification-01 Thread-Index: AcvzEEm7tDC0xH81R+aioTQK78xmlQAEfPjw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF67253@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <201104042033.p34KXDqG024310@harbor.orleans.occnc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 23:57:37 -0000 =20 > The control-plane delays you haven't listed include sending LSUpdate > from data-plane to control-plane and its processing such as > authenticating, comparing against LSDB, sending LSAck (with potential > re-transmission), queueing for further flooding (including re-transmit > if timer expires), re-adding interface specific auth params etc. All You will have more delays even before this. The LSAs need to be picked up f= rom the HW to the CPU and based on your queue scheduling algorithm there co= uld be some delays there. Typically if its strict scheduling then you would= drain all the BFDs, EFMs, LACPs, OSPF HELLOs, etc before you get to the LS= Updates. Once you have drained all such packets from the HW they will only = be processed once your OSPF task gets a CPU slice. It will then take some t= ime in processing the LSUpdates as it may have Hellos queued up ahead (base= d on the architecture). Similarly, at the egress there could again be some = delays. If there is a central task that's responsible for sending out the p= ackets then it could also be maintaining priority queues and LSUpdates will= certainly not get into the highest. While I understand that all these dela= ys are very small, they do start adding up as the LSAs travel hop-by-hop. I= t also starts getting significant as your router starts becoming busy and t= he processes have to contend for the CPU cycles. If the router software is = not entirely lockless then you would also see processes stalled because som= e other task has acquired a lock that they're waiting on. So, forwarding th= em in the HW seems like a good idea provided we can make it work without ma= king the solution too convoluted and complex. Cheers, Manav > of these need to be done at each intermediate hop as the LSA gets > flooded and hence the delay is cumulative. These delays may not seem > like much but it does add to the overall delay in convergence. The SPF > by itself does not take that much time in modern CPUs but the download > of routes certainly increases with number of downloads. However, > modern forwarding architectures are such that in many failure > conditions many downloads are not needed. A single download can change > the nexthop of a large number of routes. In such conditions the > hop-by-hop control-plane flooding does not remain an insignificant > component of convergence. There will of course be networks where > geographic delay itself may be large enough to dwarf all other > numbers, but there are a lot of networks where that is not true. >=20 > We will be updating the draft to support the assertions. >=20 > Thanks From curtis@occnc.com Mon Apr 4 19:00:43 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59203A6840 for ; Mon, 4 Apr 2011 19:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1aLGwdrYtD5 for ; Mon, 4 Apr 2011 19:00:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 7C9B73A6821 for ; Mon, 4 Apr 2011 19:00:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3522K7P028995; Mon, 4 Apr 2011 22:02:20 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104050202.p3522K7P028995@harbor.orleans.occnc.com> To: Vishwas Manral From: Curtis Villamizar In-reply-to: Your message of "Mon, 04 Apr 2011 13:36:11 PDT." Date: Mon, 04 Apr 2011 22:02:20 -0400 Sender: curtis@occnc.com Cc: ospf@ietf.org Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 02:00:43 -0000 In message Vishwas Manral writes: > > On Mon, Apr 4, 2011 at 1:33 PM, Curtis Villamizar wrote: > Hi Curtis, > > > Has anyone measured the per hop flooding delay that is incurred in > > modern routers? > > From the few we have worked, it works from 10's of nanoseconds to > microseconds. > > You may see some work on > http://tools.ietf.org/html/draft-manral-ospf-te-delay-00. We need to > actually add per device delay to make the solution generic, which is > what we are trying to work on. > > Thanks, > Vishwas I'm not talking about forwarding latency, but IGP flooding latency. In flooding you are not supposed to reflood something back to an LSR that already knows about it so a CPU is involved unless someone has put the flooding into an FPGA (these days who knows). Curtis From curtis@occnc.com Mon Apr 4 19:13:17 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7293A6843 for ; Mon, 4 Apr 2011 19:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRhZhc7h9z6R for ; Mon, 4 Apr 2011 19:13:16 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 6CC2D3A6821 for ; Mon, 4 Apr 2011 19:13:16 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p352Erew029116; Mon, 4 Apr 2011 22:14:53 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104050214.p352Erew029116@harbor.orleans.occnc.com> To: Sriganesh Kini From: Curtis Villamizar In-reply-to: Your message of "Mon, 04 Apr 2011 14:35:21 PDT." Date: Mon, 04 Apr 2011 22:14:53 -0400 Sender: curtis@occnc.com Cc: ospf@ietf.org Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 02:13:17 -0000 Sri, I spoke to a few people at IETF who have implemented OSPF and I have deployed OSPF. Flooding was not considered an issue. A notfification would normally go out when a LSA is modified to withdraw an adjacency. Even a software SHA-256 is not that long a time in software. The question was whether anyone running a real network had measuered flooding delay and found it to be a problem. Also keep in mind that *modern* IGP implementations reflood first and then SPF and download routes later. You might want to look through the archives of presentations at NANOG related to convergence. Packet designs and Qwest did some work on this about 5 years ago or more. You may be tackling a non-problem. Curtis In message Sriganesh Kini writes: > > Vishwas, > > Your draft seems to be referring to the end-to-end delay of a packet > forwarded entirely by data-plane. So those results would be applicable > to the OSPF fast-notification. It would not be applicable to > end-to-end delay of OSPF LSA flooding since the LSAs are processed at > each hop by the control-plane. > > Curtis, > > The control-plane delays you haven't listed include sending LSUpdate > from data-plane to control-plane and its processing such as > authenticating, comparing against LSDB, sending LSAck (with potential > re-transmission), queueing for further flooding (including re-transmit > if timer expires), re-adding interface specific auth params etc. All > of these need to be done at each intermediate hop as the LSA gets > flooded and hence the delay is cumulative. These delays may not seem > like much but it does add to the overall delay in convergence. The SPF > by itself does not take that much time in modern CPUs but the download > of routes certainly increases with number of downloads. However, > modern forwarding architectures are such that in many failure > conditions many downloads are not needed. A single download can change > the nexthop of a large number of routes. In such conditions the > hop-by-hop control-plane flooding does not remain an insignificant > component of convergence. There will of course be networks where > geographic delay itself may be large enough to dwarf all other > numbers, but there are a lot of networks where that is not true. > > We will be updating the draft to support the assertions. > > Thanks > > On Mon, Apr 4, 2011 at 1:36 PM, Vishwas Manral wrote: > > On Mon, Apr 4, 2011 at 1:33 PM, Curtis Villamizar wrote: > > Hi Curtis, > > > >> Has anyone measured the per hop flooding delay that is incurred in > >> modern routers? > > > > From the few we have worked, it works from 10's of nanoseconds to microseconds. > > > > You may see some work on > > http://tools.ietf.org/html/draft-manral-ospf-te-delay-00. We need to > > actually add per device delay to make the solution generic, which is > > what we are trying to work on. > > > > Thanks, > > Vishwas > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > > > > -- > - Sri From curtis@occnc.com Mon Apr 4 19:24:02 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145AD3A6840 for ; Mon, 4 Apr 2011 19:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WahIwcpZFMAn for ; Mon, 4 Apr 2011 19:24:00 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 648BE3A682E for ; Mon, 4 Apr 2011 19:24:00 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p352PaCS029256; Mon, 4 Apr 2011 22:25:37 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104050225.p352PaCS029256@harbor.orleans.occnc.com> To: "Bhatia, Manav (Manav)" From: Curtis Villamizar In-reply-to: Your message of "Tue, 05 Apr 2011 05:29:16 +0530." <7C362EEF9C7896468B36C9B79200D8350CFCF67253@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 04 Apr 2011 22:25:36 -0400 Sender: curtis@occnc.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 02:24:02 -0000 In message <7C362EEF9C7896468B36C9B79200D8350CFCF67253@INBANSXCHMBSA1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > > > The control-plane delays you haven't listed include sending LSUpdate > > from data-plane to control-plane and its processing such as > > authenticating, comparing against LSDB, sending LSAck (with potential > > re-transmission), queueing for further flooding (including re-transmit > > if timer expires), re-adding interface specific auth params etc. All > > You will have more delays even before this. The LSAs need to be picked > up from the HW to the CPU and based on your queue scheduling algorithm > there could be some delays there. Typically if its strict scheduling > then you would drain all the BFDs, EFMs, LACPs, OSPF HELLOs, etc > before you get to the LSUpdates. Once you have drained all such > packets from the HW they will only be processed once your OSPF task > gets a CPU slice. It will then take some time in processing the > LSUpdates as it may have Hellos queued up ahead (based on the > architecture). Similarly, at the egress there could again be some > delays. If there is a central task that's responsible for sending out > the packets then it could also be maintaining priority queues and > LSUpdates will certainly not get into the highest. While I understand > that all these delays are very small, they do start adding up as the > LSAs travel hop-by-hop. It also starts getting significant as your > router starts becoming busy and the processes have to contend for the > CPU cycles. If the router software is not entirely lockless then you > would also see processes stalled because some other task has acquired > a lock that they're waiting on. So, forwarding them in the HW seems > like a good idea provided we can make it work without making the > solution too convoluted and complex. > > Cheers, Manav Manav, There is no question that you *can* design and/or code things badly. There was work done by Packet Designs and Qwest a while back and reported in NANOG. After this work, a major router vendor's implementation was optimized and a lot of delays were removed. A big mistake they were making is SPF and route install first and then reflood. It is better to get the word out that there is a problem. After this the two leading core router vendors both had fast reflood times. At Avici, the minor core router vendor in its time, the CPU on the line card (which had no long treads and low interrupt latency) handled OSPF Hello and LSUpdate processing and only passed changes to the router processor. I just want to be sure that we aren't adding (more) baggage to fix a non-problem or to fix someone's bad software implementation. Curtis > > of these need to be done at each intermediate hop as the LSA gets > > flooded and hence the delay is cumulative. These delays may not seem > > like much but it does add to the overall delay in convergence. The SPF > > by itself does not take that much time in modern CPUs but the download > > of routes certainly increases with number of downloads. However, > > modern forwarding architectures are such that in many failure > > conditions many downloads are not needed. A single download can change > > the nexthop of a large number of routes. In such conditions the > > hop-by-hop control-plane flooding does not remain an insignificant > > component of convergence. There will of course be networks where > > geographic delay itself may be large enough to dwarf all other > > numbers, but there are a lot of networks where that is not true. > > > > We will be updating the draft to support the assertions. > > > > Thanks > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Mon Apr 4 21:25:43 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847993A6878 for ; Mon, 4 Apr 2011 21:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.703 X-Spam-Level: X-Spam-Status: No, score=-6.703 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtXzaFWZLIMd for ; Mon, 4 Apr 2011 21:25:43 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D3CD83A6877 for ; Mon, 4 Apr 2011 21:25:42 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p354RLZR013855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2011 23:27:24 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p354RKXq005367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Apr 2011 09:57:20 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 5 Apr 2011 09:57:20 +0530 From: "Bhatia, Manav (Manav)" To: "curtis@occnc.com" Date: Tue, 5 Apr 2011 09:57:18 +0530 Thread-Topic: [OSPF] draft-kini-ospf-fast-notification-01 Thread-Index: AcvzOMWKeSZDVLdCRrGNCXiliv07mAADWi0g Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF67274@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of "Tue, 05 Apr 2011 05:29:16 +0530." <7C362EEF9C7896468B36C9B79200D8350CFCF67253@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104050225.p352PaCS029256@harbor.orleans.occnc.com> In-Reply-To: <201104050225.p352PaCS029256@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 04:25:43 -0000 > There is no question that you *can* design and/or code things badly. > There was work done by Packet Designs and Qwest a while back and > reported in NANOG. After this work, a major router vendor's > implementation was optimized and a lot of delays were removed. A big > mistake they were making is SPF and route install first and then > reflood. It is better to get the word out that there is a problem. I believe RFC 2328 is quite clear that LSAs should be flooded before "recal= culating the routing table structure", so I am quite surprised that there w= ere implementations that were doing otherwise. Thus I don't think anybody o= n this list seriously believes that this is an issue that folks are trying = to solve. I believe the idea is quite simple - Flooding a changed LSA in HW= (data plane) is faster than doing it in SW (not matter how optimized the l= atter is) or your control plane. Lets at least look at the proposed solution and see if its worth considerin= g. Who knows the discussion might lead us to something better that we may w= ant to use.=20 Also note that I am not the author or in any way related to the draft! :)=20 Cheers, Manav= From Andras.Csaszar@ericsson.com Tue Apr 5 06:07:13 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73C928C102 for ; Tue, 5 Apr 2011 06:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.527 X-Spam-Level: X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqUdnMRzfCWO for ; Tue, 5 Apr 2011 06:07:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 127BF28C101 for ; Tue, 5 Apr 2011 06:07:12 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-d8-4d9b14670e88 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CA.CB.09202.7641B9D4; Tue, 5 Apr 2011 15:08:55 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.133]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 5 Apr 2011 15:08:55 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: "Bhatia, Manav (Manav)" , "curtis@occnc.com" Date: Tue, 5 Apr 2011 15:08:53 +0200 Thread-Topic: [OSPF] draft-kini-ospf-fast-notification-01 Thread-Index: AcvzOMWKeSZDVLdCRrGNCXiliv07mAADWi0gABK94eA= Message-ID: <8DCD771BDA4A394E9BCBA8932E83929720E74AF217@ESESSCMS0363.eemea.ericsson.se> References: Your message of "Tue, 05 Apr 2011 05:29:16 +0530." <7C362EEF9C7896468B36C9B79200D8350CFCF67253@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104050225.p352PaCS029256@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFCF67274@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF67274@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 13:07:13 -0000 > I believe the idea is quite simple -=20 > Flooding a changed LSA in HW (data plane) is faster than=20 > doing it in SW (not matter how optimized the latter is) or=20 > your control plane. That's the main purpose, yes. You could combine this with something else: OSPF could pre-calc/pre-downloa= d potential new LSAs to the dataplane anticipating local failures.=20 Whenever a local failure really happens, dataplane notices it by LoS or BFD= , then can immediately disseminate the changed LSA using FN. So, in additio= n to the per-hop CP processing of LSAs, you could also spare some time with= originating an LSA: - failure trigger reaching/processed by CP - OSPF originating a new LSA - OSPF sending the LSU packet down to DP Cheers, Andr=E1s= From jdrake@juniper.net Tue Apr 5 07:04:15 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20AA28C11D for ; Tue, 5 Apr 2011 07:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSU9Vxu4ovtu for ; Tue, 5 Apr 2011 07:04:09 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id CB9B13A6939 for ; Tue, 5 Apr 2011 07:04:08 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTZshtwOFBLaBCMNxs0aUxTIU2N81DBrH@postini.com; Tue, 05 Apr 2011 07:05:52 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 5 Apr 2011 07:02:24 -0700 From: John E Drake To: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= , "Bhatia, Manav (Manav)" , "curtis@occnc.com" Date: Tue, 5 Apr 2011 07:04:02 -0700 Thread-Topic: [OSPF] draft-kini-ospf-fast-notification-01 Thread-Index: AcvzOMWKeSZDVLdCRrGNCXiliv07mAADWi0gABK94eAAAhzQQA== Message-ID: <5E893DB832F57341992548CDBB33316399F2BD0510@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 05 Apr 2011 05:29:16 +0530." <7C362EEF9C7896468B36C9B79200D8350CFCF67253@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104050225.p352PaCS029256@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFCF67274@INBANSXCHMBSA1.in.alcatel-lucent.com> <8DCD771BDA4A394E9BCBA8932E83929720E74AF217@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E83929720E74AF217@ESESSCMS0363.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:04:16 -0000 We actually implemented this in IBM's Nways products in the early/mid ninet= ies and found it wasn't worth the trouble. It had no measurable effect on = network performance and the protocols necessary to terminate the broadcast = were messy and error prone. Sent from my iPhone > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Andr=E1s Cs=E1sz=E1r > Sent: Tuesday, April 05, 2011 6:09 AM > To: Bhatia, Manav (Manav); curtis@occnc.com > Cc: ospf@ietf.org > Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 >=20 > > I believe the idea is quite simple - > > Flooding a changed LSA in HW (data plane) is faster than > > doing it in SW (not matter how optimized the latter is) or > > your control plane. >=20 > That's the main purpose, yes. >=20 > You could combine this with something else: OSPF could pre-calc/pre- > download potential new LSAs to the dataplane anticipating local > failures. >=20 > Whenever a local failure really happens, dataplane notices it by LoS or > BFD, then can immediately disseminate the changed LSA using FN. So, in > addition to the per-hop CP processing of LSAs, you could also spare > some time with originating an LSA: > - failure trigger reaching/processed by CP > - OSPF originating a new LSA > - OSPF sending the LSU packet down to DP >=20 > Cheers, > Andr=E1s > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From jdrake@juniper.net Tue Apr 5 07:49:04 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350BE28C0DE for ; Tue, 5 Apr 2011 07:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehDsyuoK-aB0 for ; Tue, 5 Apr 2011 07:48:57 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id D85C828C15A for ; Tue, 5 Apr 2011 07:48:56 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTZssPSj8knZwxhTSLckrG3u1W8V00gFd@postini.com; Tue, 05 Apr 2011 07:50:40 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 5 Apr 2011 07:47:23 -0700 From: John E Drake To: "curtis@occnc.com" , Sriganesh Kini Date: Tue, 5 Apr 2011 07:49:02 -0700 Thread-Topic: [OSPF] draft-kini-ospf-fast-notification-01 Thread-Index: AcvzNwzSK8xOZAReTIOWlb3yK+F4yQAaPASQ Message-ID: <5E893DB832F57341992548CDBB33316399F2BD0587@EMBX01-HQ.jnpr.net> References: Your message of "Mon, 04 Apr 2011 14:35:21 PDT." <201104050214.p352Erew029116@harbor.orleans.occnc.com> In-Reply-To: <201104050214.p352Erew029116@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:49:04 -0000 I am aware of at least one implementation from the 2002/2004 time frame wit= h a per node OSPF flooding transit time of O(10 uSecs); this implementatio= n was a port of a commercially available OSPF stack rather than a custom im= plementation.=20 Sent from my iPhone > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Monday, April 04, 2011 7:15 PM > To: Sriganesh Kini > Cc: ospf@ietf.org > Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 >=20 >=20 > Sri, >=20 > I spoke to a few people at IETF who have implemented OSPF and I have > deployed OSPF. Flooding was not considered an issue. >=20 > A notfification would normally go out when a LSA is modified to > withdraw an adjacency. Even a software SHA-256 is not that long a > time in software. >=20 > The question was whether anyone running a real network had measuered > flooding delay and found it to be a problem. >=20 > Also keep in mind that *modern* IGP implementations reflood first and > then SPF and download routes later. You might want to look through > the archives of presentations at NANOG related to convergence. Packet > designs and Qwest did some work on this about 5 years ago or more. > You may be tackling a non-problem. >=20 > Curtis >=20 >=20 > In message > > Sriganesh Kini writes: > > > > Vishwas, > > > > Your draft seems to be referring to the end-to-end delay of a packet > > forwarded entirely by data-plane. So those results would be > applicable > > to the OSPF fast-notification. It would not be applicable to > > end-to-end delay of OSPF LSA flooding since the LSAs are processed at > > each hop by the control-plane. > > > > Curtis, > > > > The control-plane delays you haven't listed include sending LSUpdate > > from data-plane to control-plane and its processing such as > > authenticating, comparing against LSDB, sending LSAck (with potential > > re-transmission), queueing for further flooding (including re- > transmit > > if timer expires), re-adding interface specific auth params etc. All > > of these need to be done at each intermediate hop as the LSA gets > > flooded and hence the delay is cumulative. These delays may not seem > > like much but it does add to the overall delay in convergence. The > SPF > > by itself does not take that much time in modern CPUs but the > download > > of routes certainly increases with number of downloads. However, > > modern forwarding architectures are such that in many failure > > conditions many downloads are not needed. A single download can > change > > the nexthop of a large number of routes. In such conditions the > > hop-by-hop control-plane flooding does not remain an insignificant > > component of convergence. There will of course be networks where > > geographic delay itself may be large enough to dwarf all other > > numbers, but there are a lot of networks where that is not true. > > > > We will be updating the draft to support the assertions. > > > > Thanks > > > > On Mon, Apr 4, 2011 at 1:36 PM, Vishwas Manral > wrote: > > > On Mon, Apr 4, 2011 at 1:33 PM, Curtis Villamizar > wrote: > > > Hi Curtis, > > > > > >> Has anyone measured the per hop flooding delay that is incurred in > > >> modern routers? > > > > > > From the few we have worked, it works from 10's of nanoseconds to > microseconds. > > > > > > You may see some work on > > > http://tools.ietf.org/html/draft-manral-ospf-te-delay-00. We need > to > > > actually add per device delay to make the solution generic, which > is > > > what we are trying to work on. > > > > > > Thanks, > > > Vishwas > > > _______________________________________________ > > > OSPF mailing list > > > OSPF@ietf.org > > > https://www.ietf.org/mailman/listinfo/ospf > > > > > > > > > > > -- > > - Sri >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From jdrake@juniper.net Tue Apr 5 09:15:31 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131133A694C for ; Tue, 5 Apr 2011 09:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COPohmGPnST2 for ; Tue, 5 Apr 2011 09:15:30 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 137013A67B0 for ; Tue, 5 Apr 2011 09:15:30 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTZtAgIwBrlXLshHFDVYcyl+nFpDQZeyk@postini.com; Tue, 05 Apr 2011 09:17:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 5 Apr 2011 09:12:38 -0700 From: John E Drake To: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= , "Bhatia, Manav (Manav)" , "curtis@occnc.com" Date: Tue, 5 Apr 2011 09:14:18 -0700 Thread-Topic: [OSPF] draft-kini-ospf-fast-notification-01 Thread-Index: AcvzOMWKeSZDVLdCRrGNCXiliv07mAADWi0gABK94eAABsDbUA== Message-ID: <5E893DB832F57341992548CDBB33316399F2BD0718@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 05 Apr 2011 05:29:16 +0530." <7C362EEF9C7896468B36C9B79200D8350CFCF67253@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104050225.p352PaCS029256@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFCF67274@INBANSXCHMBSA1.in.alcatel-lucent.com> <8DCD771BDA4A394E9BCBA8932E83929720E74AF217@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E83929720E74AF217@ESESSCMS0363.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:15:31 -0000 Also, what you describe in your second and third paragraphs is an implement= ation choice - no protocol changes are required. Sent from my iPhone > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Andr=E1s Cs=E1sz=E1r > Sent: Tuesday, April 05, 2011 6:09 AM > To: Bhatia, Manav (Manav); curtis@occnc.com > Cc: ospf@ietf.org > Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 >=20 > > I believe the idea is quite simple - > > Flooding a changed LSA in HW (data plane) is faster than > > doing it in SW (not matter how optimized the latter is) or > > your control plane. >=20 > That's the main purpose, yes. >=20 > You could combine this with something else: OSPF could pre-calc/pre- > download potential new LSAs to the dataplane anticipating local > failures. >=20 > Whenever a local failure really happens, dataplane notices it by LoS or > BFD, then can immediately disseminate the changed LSA using FN. So, in > addition to the per-hop CP processing of LSAs, you could also spare > some time with originating an LSA: > - failure trigger reaching/processed by CP > - OSPF originating a new LSA > - OSPF sending the LSU packet down to DP >=20 > Cheers, > Andr=E1s > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From curtis@occnc.com Tue Apr 5 13:13:30 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA3C28C13A for ; Tue, 5 Apr 2011 13:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plyp3KQvUv9p for ; Tue, 5 Apr 2011 13:13:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id C996728C12B for ; Tue, 5 Apr 2011 13:13:29 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p35KF9RH060596; Tue, 5 Apr 2011 16:15:10 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104052015.p35KF9RH060596@harbor.orleans.occnc.com> To: "Bhatia, Manav (Manav)" From: Curtis Villamizar In-reply-to: Your message of "Tue, 05 Apr 2011 09:57:18 +0530." <7C362EEF9C7896468B36C9B79200D8350CFCF67274@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 05 Apr 2011 16:15:09 -0400 Sender: curtis@occnc.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 20:13:30 -0000 In message <7C362EEF9C7896468B36C9B79200D8350CFCF67274@INBANSXCHMBSA1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > > > There is no question that you *can* design and/or code things badly. > > There was work done by Packet Designs and Qwest a while back and > > reported in NANOG. After this work, a major router vendor's > > implementation was optimized and a lot of delays were removed. A big > > mistake they were making is SPF and route install first and then > > reflood. It is better to get the word out that there is a problem. > > I believe RFC 2328 is quite clear that LSAs should be flooded before > "recalculating the routing table structure", so I am quite surprised > that there were implementations that were doing otherwise. Thus I > don't think anybody on this list seriously believes that this is an > issue that folks are trying to solve. I believe the idea is quite > simple - Flooding a changed LSA in HW (data plane) is faster than > doing it in SW (not matter how optimized the latter is) or your > control plane. > > Lets at least look at the proposed solution and see if its worth > considering. Who knows the discussion might lead us to something > better that we may want to use. > > Also note that I am not the author or in any way related to the draft! > :) > > Cheers, Manav We have plenty of junk internet-drafts in IETF. One or two less would be better. If it is not solving a real world problem then we should get rid of it. First we have to agree that there is a requirement. draft-kini-ospf-fast-notification-01.txt calls for multicast, and cites draft-lu-fast-notification-framework-00.txt for "transporting the message encoding", but the latter makes no mention of multicast. If multicast is used, a multicast routing protocol is needed. A multicast tree can have transient loops. The last thing we need to add to OSPF is a new control plane transient loop creation capability. At least flooding is guarenteed to never loop. When a fault occurs in a multicast tree, the tree must converge before any other fault is reliably reported using multicast. Multiple faults are common. Most are covered in protocols such as RSVP-TE that support SRLG (but many are not even covered by SRLG). This work is half thought out and it doesn't address a real problem so I support telling the authors that it has no place in the OSPF WG. Curtis From russ@cisco.com Tue Apr 5 14:59:44 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1163A67EE for ; Tue, 5 Apr 2011 14:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJnaiaGmAA+F for ; Tue, 5 Apr 2011 14:59:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6EE4B3A67EB for ; Tue, 5 Apr 2011 14:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1760; q=dns/txt; s=iport; t=1302040887; x=1303250487; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Wpu5tyDnvK0/A9x0DCQSP3ayzL4GR/zo4r6EwfKJVxI=; b=TsSIS0+TZPXIpblCmNVXW2/SguJqKBQ1lQFQqe/Jsgwp6QZr437SxC+K udNzCx+2CrAeqm+e+fCUr8xyKxi6lAX3+6Fun1NrCosFYUL41nV8cwNZv 8e7oYOebiV0uf++DGoFqJZMyxhX/2/+GSKMuP0JCKxHV8bkiPMKUwD2qH g=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.63,307,1299456000"; d="asc'?scan'208";a="676270496" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2011 22:01:23 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p35M1MdT017360; Tue, 5 Apr 2011 22:01:23 GMT Message-ID: <4D9B9121.2080001@cisco.com> Date: Tue, 05 Apr 2011 18:01:05 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Russ White References: <4D651936.9020206@cisco.com> <1B04BA90-6619-4CD9-9BFC-C66B833FE655@ericsson.com> <4D6527C8.40003@cisco.com> In-Reply-To: <4D6527C8.40003@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE6F12A214EC0ED8940AC2143" Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Information Hiding X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:59:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE6F12A214EC0ED8940AC2143 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> OSPFv2, as specified in RFC 2328, states that a multi-access network's= subnet is specified by the DR's Network-LSA LSID/mask and installed duri= ng the SPF graph traversal. Hence, without some form of signaling, there = is no way to prevent other routers in the OSPF area from installing the s= ubnet route (whether or not it is really needed for any purpose in the OS= PF network deployment).=20 >=20 > So, in reality, this isn't about the way SPF is run, but the assumption= > in RFC2328 that the LSID/subnet mask from the type 2 is the "correct" > subnet to put in the table when building the tree... Hmm... >=20 > Then it seems like the magic number is unavoidable in this case. BTW --I'm fine with moving this doc forward... :-) Russ --=20 riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone 'I suppose there are two views about everything,' said Mark. 'Eh? Two views? There are a dozen views about everything, until you know the answer. Then there=C2=92s never more than one.' -C.S. Lewis --------------enigE6F12A214EC0ED8940AC2143 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2bkSEACgkQER27sUhU9OTrggCeMJu/aop2FPS6WdEBF1H7VMPW kY0AoOJTk/6O+w0ui/PS51P5KLyE6ro9 =4Z8M -----END PGP SIGNATURE----- --------------enigE6F12A214EC0ED8940AC2143-- From ogier@earthlink.net Fri Apr 8 11:44:39 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349EC3A69B4 for ; Fri, 8 Apr 2011 11:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhrbsxG+5U6Q for ; Fri, 8 Apr 2011 11:44:38 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 4B30E3A696B for ; Fri, 8 Apr 2011 11:44:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MF0sGJvnrntP5yZ3Uyke3zlVfoDzoBZRMGf1E5cnbqSZHp7CM5W7j4OiurAFZ+wk; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.255.49] by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Q8GhK-0006V8-90 for ospf@ietf.org; Fri, 08 Apr 2011 14:46:23 -0400 Message-ID: <4D9F590A.5050008@earthlink.net> Date: Fri, 08 Apr 2011 11:50:50 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ospf@ietf.org References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> In-Reply-To: <4D5474C5.1050107@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478dd836ef1d960a2d9ba5cce890007eb40bb41458c46f24811350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.255.49 Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:44:39 -0000 I decided to read the posts regarding this draft (hybrid-bcast-p2mp), since it is related to OSPF-MANET, and have a few comments. It was mentioned that RFC 5820 (OSPF-MANET with smart peering) solves the problem of this draft, assuming that smart peering and unsynchronized adjacencies are used. (E.g., Sheth's post on 2/10/2011.) I also want to point out that RFC 5614 (OSPF-MANET-MDR or OSPF-MDR), which uses CDS flooding via MDRs (MANET Designated Routers), not only solves the problem of this draft, but provides almost the same solution as this draft when OSPF-MDR (with full-topology LSAs and biconnected adjacencies) is applied to single-hop broadcast networks. The hybrid-bcast-p2mp draft is nice because it requires only minimal modifications to OSPF, keeping the DR and BDR and the same adjacencies. The reason that OSPF-MDR applied to single-hop broadcast networks provides almost the same solution as this draft is because it generalizes the concept of DRs and BDRs to MANETs, and requires only 2 adjacencies for a non-DR/BDR (or non-MDR/BMDR) in a single-hop broadcast network. More on this (near) equivalence below. In contrast, the solution of draft-retana-ospf-manet, which applies RFC 5820 with smart peering to single-hop broadcast networks, is quite different, resulting in a more random selection of adjacencies, which are not common to any single node such as a DR. Thus, unlike the other two solutions, draft-retana-ospf-manet is conceptually quite different from OSPF broadcast, since it does not use the concept of the DR and BDR. One of the goals in the design of OSPF-MDR was to minimize changes to OSPF. Thus, instead of throwing out the DR and BDR, they were generalized to multi-hop networks, and were kept essentially the same in the special case of a single-hop network, for the purpose of flooding and forming adjacencies. More information on OSPF-MDR can be found at www.manet-routing.org. Now more on the (near) equivalence between hybrid-bcast-p2mp and OSPF-MDR when applied to a single-hop broadcast network. In this case, the MDR selection algorithm is very similar to the DR election algorithm of OSPF, and both select a single DR/MDR. (There are a few minor differences that are not important to this discussion.) Also, if AdjConnectivity = 2, each node forms an adjacency with the MDR and BMDR. The origination of router LSAs is also nearly equivalent. The rules in Section 3.6 of hybrid-bcast-p2mp, which specifies which Type 1 links a non-DR includes in its router LSA, are similar to the corresponding rules in RFC 5614 when LSAFullness = 4 (full-topology LSAs). In that case, a router includes all bidirectional (2-Way or higher) neighbors that are "routable", where a neighbor is routable if SPF has calculated a route to the neighbor. Note that SPF will calculate such a route to the neighbor as long as both the router itself and the neighbor are fully adjacent to the MDR. This is slightly different from Section 3.6 of hybrid-bcast-p2mp, which only requires that the router itself be fully adjacent to the DR (thus relying on the requirement of SPF that the neighbor must include a link back to the router in its LSA). But both solutions achieve the same goal, in a similar way, using a single DR/MDR that becomes adjacent with all neighbors. Richard From sriganeshkini@gmail.com Sun Apr 10 10:03:18 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3913A6934 for ; Sun, 10 Apr 2011 10:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph2hKFfjWqsB for ; Sun, 10 Apr 2011 10:03:18 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id CBA923A6916 for ; Sun, 10 Apr 2011 10:03:17 -0700 (PDT) Received: by qyk7 with SMTP id 7so3179609qyk.10 for ; Sun, 10 Apr 2011 10:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=9Er7ztDJhIa1Jw972lpu4zBVpB9VXg7Tb9faSgZ56/Y=; b=jKpaTfSTgUCfKrFF4lcJLGbs4ghMON/DprIpWOJWNqviHjPHMGaaFwBSG7EUUU2iCL 4q5iD461qgZVhfTsJvE1e19umtAZ1tw9IDdkmRb8IE+UA/M+J9KHlaDII2E96VGPzQ/D fmhUCiKc6q+vRO/x7iA5KOvGND/drJuQWTOOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=k0cXhSoSDI8atKcIjaVRBrzkcQkk9nIsohOb9V7vmfr05kozbcIBYcyp88YQ+CqvCX UPX7iyKLA74cpC1mNTJIB/6nCgNXQqh+eqC/vAD8Qdd0Rk9ZV5OVJPJWuhawGgWUYSkL 2wCkaWKo1OYDdsS7K6x2ULuD44xFA08hlY+ZY= Received: by 10.229.29.20 with SMTP id o20mr3421641qcc.181.1302454997145; Sun, 10 Apr 2011 10:03:17 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.188.204 with HTTP; Sun, 10 Apr 2011 10:02:47 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB33316399F2BD0718@EMBX01-HQ.jnpr.net> References: <7C362EEF9C7896468B36C9B79200D8350CFCF67253@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104050225.p352PaCS029256@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFCF67274@INBANSXCHMBSA1.in.alcatel-lucent.com> <8DCD771BDA4A394E9BCBA8932E83929720E74AF217@ESESSCMS0363.eemea.ericsson.se> <5E893DB832F57341992548CDBB33316399F2BD0718@EMBX01-HQ.jnpr.net> From: Sriganesh Kini Date: Sun, 10 Apr 2011 10:02:47 -0700 X-Google-Sender-Auth: yu0X3Pzt1ohi-PMRbEH9y19j83k Message-ID: To: "ospf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 17:03:18 -0000 Thanks for all the feedback. We will take them into consideration in deciding how to proceed. - Sri From acee.lindem@ericsson.com Mon Apr 11 05:30:33 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03DF028C0F6 for ; Mon, 11 Apr 2011 05:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.114 X-Spam-Level: X-Spam-Status: No, score=-5.114 tagged_above=-999 required=5 tests=[AWL=1.485, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyOMDuLvAHqR for ; Mon, 11 Apr 2011 05:30:31 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 141D028C0FC for ; Mon, 11 Apr 2011 05:30:30 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3BCUNCC021381; Mon, 11 Apr 2011 07:30:28 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.177]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 11 Apr 2011 08:30:23 -0400 From: Acee Lindem To: Dean cheng , Mohamed Boucadair Date: Mon, 11 Apr 2011 08:30:20 -0400 Thread-Topic: Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03 Thread-Index: Acv4RDnn/P2XdJzDQ9+eU5tv4ZHwsA== Message-ID: <99450535-8674-463E-940E-AED55B4A69CF@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-84--52210231"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 12:30:33 -0000 --Apple-Mail-84--52210231 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dean, Mohammed,=20 We've had some support for this document and there has been on = opposition. Please make it an OSPF WG document with intended status = informational.=20 Thanks, Acee= --Apple-Mail-84--52210231 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxMTEyMzAyMFowIwYJKoZI hvcNAQkEMRYEFFrj1K81Na0R7r7wqmV8kdWkradnMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgEyWPJzDdP+niNTVUNo9LiasQ2OccuAE87gWUBnGK3JPHB59/+NslCk6LbEGFiH+ b6f6ZrwMU7InaWUAfEDk7WleUanaZW1V7J2WXTgFyvok46fZS6dhn9VR4J+IWdB3K21Z15Kicm3/ Rmv0R8eMqxHt03uBRLrue2dmgTaoi+zYAAAAAAAA --Apple-Mail-84--52210231-- From acee.lindem@ericsson.com Mon Apr 11 09:10:47 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D052328C12F for ; Mon, 11 Apr 2011 09:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.185 X-Spam-Level: X-Spam-Status: No, score=-5.185 tagged_above=-999 required=5 tests=[AWL=1.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 700f3cDP6Bzx for ; Mon, 11 Apr 2011 09:10:44 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id A061C28C135 for ; Mon, 11 Apr 2011 09:10:44 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3BGANaV029267; Mon, 11 Apr 2011 11:10:24 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.177]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 11 Apr 2011 12:10:17 -0400 From: Acee Lindem To: OSPF WG List Date: Mon, 11 Apr 2011 12:10:15 -0400 Thread-Topic: Hiding Transit-only Networks in OSPF - draft-yang-ospf-hiding-00.txt Thread-Index: Acv4YvJXn9RrFg0cQhCyF2G1Wv7Qiw== Message-ID: <30EB735E-6702-43DC-B807-899ADB9E4093@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-90--39015417"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [OSPF] Hiding Transit-only Networks in OSPF - draft-yang-ospf-hiding-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:10:47 -0000 --Apple-Mail-90--39015417 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This was presented at the Beijing IETF. Since that time we've had some = support and no opposition. Is anyone opposed to making this optional = capability a WG document with an intended status of Proposed Standard?=20= There is one commercial implementation.=20 Thanks, Acee=20= --Apple-Mail-90--39015417 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxMTE2MTAxNVowIwYJKoZI hvcNAQkEMRYEFLu4+yHdDLjSeOEnc8v+OOQYGxYxMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgH3CUEu5K0Z1qQOLMAeS2ukz5LRmpFnhBK5ctZFD1EYeRzgDz3LLsx6ZLDj+jKZ2 M6iwH79StDCwNuCkPLuthohddHtSac2mdRVTmDHkWC9hXchNhlvnVd97HQ9feMKyKdhBTAW5q2sz R2m38VGlFAZf+rCp/CIY8taiIM2lgnM9AAAAAAAA --Apple-Mail-90--39015417-- From akr@cisco.com Mon Apr 11 09:19:12 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205213A68DC for ; Mon, 11 Apr 2011 09:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.798 X-Spam-Level: X-Spam-Status: No, score=-109.798 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9QTRf-pggkc for ; Mon, 11 Apr 2011 09:19:11 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3EEE53A683C for ; Mon, 11 Apr 2011 09:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akr@cisco.com; l=5130; q=dns/txt; s=iport; t=1302538751; x=1303748351; h=message-id:date:from:mime-version:to:subject; bh=4CWmFIYAi6qlXMYkFTKVltMhgeqtWunTzEzSSjt8KN8=; b=kRZFr/LEI7uXbtxJiFyckGlbneBm3HxyeZ6ZvTKA6sTi1Xy/BE5OEGA/ n5TfJNVpPNeI/0VX8t6jPuUlq34q5Eybjp65ZJVeeiadPJpvgvXEK9FRp IhgRvUiDJzdPvMeJx88cDSvR64S4teEGcQ+NgtEgH3YCX5THOG5l1bwYQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKIoo02rRDoJ/2dsb2JhbACmGnenIJwThW4EhVuHfQ X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208,217";a="334747113" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2011 16:19:10 +0000 Received: from sjc-vpn5-895.cisco.com (sjc-vpn5-895.cisco.com [10.21.91.127]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3BGJAGG002331 for ; Mon, 11 Apr 2011 16:19:10 GMT Message-ID: <4DA329FE.4050108@cisco.com> Date: Mon, 11 Apr 2011 09:19:10 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: "ospf@ietf.org" Content-Type: multipart/alternative; boundary="------------070107040903040000020701" Subject: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:19:12 -0000 This is a multi-part message in MIME format. --------------070107040903040000020701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We are starting the Working Group Last Call of this revision of the subject draft. This drafts is intended to be a Proposed Standard. The OSPF WG last call will begin today and will end at 5pm PST, April 25th, 2011. Abhay/Acee -------- Original Message -------- Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt Date: Sat, 19 Feb 2011 12:00:02 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ospf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Supporting Authentication Trailer for OSPFv3 Author(s) : M. Bhatia, et al. Filename : draft-ietf-ospf-auth-trailer-ospfv3-03.txt Pages : 20 Date : 2011-02-19 Currently OSPFv3 uses IPsec for authenticating protocol packets. However, there are some environments, e.g., Mobile Ad-hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used. This draft proposes an alternative mechanism that can be used so that OSPFv3 does not depend upon IPsec for authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------070107040903040000020701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We are starting the Working Group Last Call of this revision of the subject draft.

This drafts is intended to be a Proposed Standard. The OSPF WG last call
will begin today and will end at 5pm PST,  April 25th, 2011.

Abhay/Acee

-------- Original Message --------
Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt
Date: Sat, 19 Feb 2011 12:00:02 -0800
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: ospf@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.


	Title           : Supporting Authentication Trailer for OSPFv3
	Author(s)       : M. Bhatia, et al.
	Filename        : draft-ietf-ospf-auth-trailer-ospfv3-03.txt
	Pages           : 20
	Date            : 2011-02-19

Currently OSPFv3 uses IPsec for authenticating protocol packets.
However, there are some environments, e.g., Mobile Ad-hoc Networks
(MANETs), where IPsec is difficult to configure and maintain, and
this mechanism cannot be used.  This draft proposes an alternative
mechanism that can be used so that OSPFv3 does not depend upon IPsec
for authentication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------070107040903040000020701-- From acee.lindem@ericsson.com Mon Apr 11 09:22:02 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6649728C137 for ; Mon, 11 Apr 2011 09:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aABJ9KnEQ4sO for ; Mon, 11 Apr 2011 09:22:01 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 537633A683C for ; Mon, 11 Apr 2011 09:22:01 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3BGLg2O031736; Mon, 11 Apr 2011 11:22:00 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.177]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 11 Apr 2011 12:21:59 -0400 From: Acee Lindem To: OSPF WG List Date: Mon, 11 Apr 2011 12:21:56 -0400 Thread-Topic: Poll on OSPF Stub Router Advertisement - draft-retana-ospf-rfc3137bis-00 Thread-Index: Acv4ZJTEnLmFFK07RdaIyvW77Bog8w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alex Zinin Subject: [OSPF] Poll on OSPF Stub Router Advertisement - draft-retana-ospf-rfc3137bis-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:22:02 -0000 There was general agreement that this should be a WG document at the meetin= g in Prague. Please indicate your position on making this draft a WG docume= nt with intended status Informational.=20 Thanks, Acee= From jeff.tantsura@ericsson.com Mon Apr 11 10:02:03 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64A428C14E for ; Mon, 11 Apr 2011 10:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.558 X-Spam-Level: X-Spam-Status: No, score=-5.558 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOjYq7u1SZvt for ; Mon, 11 Apr 2011 10:02:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id A6B9D28C147 for ; Mon, 11 Apr 2011 10:02:02 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3BH1x5S007638; Mon, 11 Apr 2011 12:02:01 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 11 Apr 2011 13:01:55 -0400 From: Jeff Tantsura To: Abhay Roy , "ospf@ietf.org" Date: Mon, 11 Apr 2011 13:01:54 -0400 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt Thread-Index: Acv4ZDSPAhBQq/0YQxuqtbTpw3h2EAABdYzA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CAB395E7B@EUSAACMS0701.eamcs.ericsson.se> References: <4DA329FE.4050108@cisco.com> In-Reply-To: <4DA329FE.4050108@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0ED867EB33AB2B45AAB470D5A64CDBF60CAB395E7BEUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 17:02:04 -0000 --_000_0ED867EB33AB2B45AAB470D5A64CDBF60CAB395E7BEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Supported Regards, Jeff ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Abh= ay Roy Sent: Monday, April 11, 2011 09:19 To: ospf@ietf.org Subject: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPF= v3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt We are starting the Working Group Last Call of this revision of the subject= draft. This drafts is intended to be a Proposed Standard. The OSPF WG last call will begin today and will end at 5pm PST, April 25th, 2011. Abhay/Acee -------- Original Message -------- Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt Date: Sat, 19 Feb 2011 12:00:02 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ospf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Open Shortest Path First IGP Working Group= of the IETF. Title : Supporting Authentication Trailer for OSPFv3 Author(s) : M. Bhatia, et al. Filename : draft-ietf-ospf-auth-trailer-ospfv3-03.txt Pages : 20 Date : 2011-02-19 Currently OSPFv3 uses IPsec for authenticating protocol packets. However, there are some environments, e.g., Mobile Ad-hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used. This draft proposes an alternative mechanism that can be used so that OSPFv3 does not depend upon IPsec for authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --_000_0ED867EB33AB2B45AAB470D5A64CDBF60CAB395E7BEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/Supported=

 

Regards,
Jeff 

From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] = On Behalf Of Abhay Roy
Sent: Monday, April 11, 2011= 09:19
To: ospf@ietf.org
Subject: [OSPF] WG Last Call= for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt

=  

= We are starting the Working Group Last Call of t= his revision of the subject draft.

This drafts is intended to be a Proposed Standard. The OSPF WG last call will begin today and will end at 5pm PST,  April 25th, 2011.

Abhay/Acee

-------- Original Message --------

Subject:

Date:

From:

In= ternet-Drafts@ietf.org

Reply-To:

in= ternet-drafts@ietf.org

To:

i-d-a= nnounce@ietf.org

CC:

ospf@ietf.org=

 = 

A New Internet-Draft is available from the on-line Internet-Dr=
afts directories.
This draft is a work item of the Open Shortest Path First IGP Working Gro=
up of the IETF.
 
 
        Title    &=
nbsp;      : Supporting Authentication Trailer for=
 OSPFv3
        Author(s)   &nb=
sp;   : M. Bhatia, et al.
        Filename   &nbs=
p;    : draft-ietf-ospf-auth-trailer-ospfv3-03.txt
        Pages    &=
nbsp;      : 20
        Date    &n= bsp;       : 2011-02-19
 
Currently OSPFv3 uses IPsec for authenticating protocol packets.
However, there are some environments, e.g., Mobile Ad-hoc Networks
(MANETs), where IPsec is difficult to configure and maintain, and
this mechanism cannot be used.  This draft proposes an alternative
mechanism that can be used so that OSPFv3 does not depend upon IPsec=

for authentication.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trail=
er-ospfv3-03.txt
 
Internet-Drafts are also available by anonymous FTP at:=

ftp://ftp.ietf.org/internet-dr=
afts/
 
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
 
--_000_0ED867EB33AB2B45AAB470D5A64CDBF60CAB395E7BEUSAACMS0701e_-- From acee.lindem@ericsson.com Mon Apr 11 10:18:26 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5312A3A6B2C for ; Mon, 11 Apr 2011 10:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.308 X-Spam-Level: X-Spam-Status: No, score=-5.308 tagged_above=-999 required=5 tests=[AWL=1.291, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxqQEHizDb+K for ; Mon, 11 Apr 2011 10:18:25 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id AF74A3A68DC for ; Mon, 11 Apr 2011 10:18:25 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3BHHpWu010861; Mon, 11 Apr 2011 12:18:19 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.177]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 11 Apr 2011 13:18:11 -0400 From: Acee Lindem To: OSPF WG List Date: Mon, 11 Apr 2011 13:18:08 -0400 Thread-Topic: Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 Thread-Index: Acv4bG4wkRLNDkFQQ6un9i/747rzBg== Message-ID: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sam Hartman Subject: [OSPF] Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 17:18:26 -0000 There was general agreement that this should be a WG document at the meetin= g in Prague. Please indicate your position on making this draft a WG docume= nt with intended status Proposed Standard.=20 Thanks, Acee= From sratliff@cisco.com Mon Apr 11 11:16:32 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A193A6988 for ; Mon, 11 Apr 2011 11:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV05JOyo4A82 for ; Mon, 11 Apr 2011 11:16:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BDEC73A6946 for ; Mon, 11 Apr 2011 11:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=438; q=dns/txt; s=iport; t=1302545792; x=1303755392; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=A9YRaR3i1wH5T53Yx8ue1ZTVBE3OvVKMljBj/8aXcoE=; b=CrO8Vz2yM/0LGUwPDf0/50lFWVgkz8S4umjk3PgOyEclFhLfNVkindlx vjiFxXfJPwDcB1I5xRQJztfHmMYok80sILts3MBot925sDyffnsjs4zJU nwRawVYa9O/6tPmRgy3QTn23XgoV+Gzb8qdlJJoGEHXhNDXUoDXKN0I2h o=; X-IronPort-AV: E=Sophos;i="4.64,192,1301875200"; d="scan'208";a="293884850" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2011 18:16:32 +0000 Received: from dhcp-64-102-54-197.cisco.com (dhcp-64-102-54-197.cisco.com [64.102.54.197]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3BIFeWl013785; Mon, 11 Apr 2011 18:16:31 GMT Message-Id: <2F7A40C2-85F0-4D56-824D-39D2F60EA7A7@cisco.com> From: Stan Ratliff To: Acee Lindem In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 11 Apr 2011 14:16:31 -0400 References: X-Mailer: Apple Mail (2.936) Cc: OSPF WG List , Alex Zinin Subject: Re: [OSPF] Poll on OSPF Stub Router Advertisement - draft-retana-ospf-rfc3137bis-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:16:32 -0000 Support. Regards, Stan On Apr 11, 2011, at 12:21 PM, Acee Lindem wrote: > There was general agreement that this should be a WG document at the > meeting in Prague. Please indicate your position on making this > draft a WG document with intended status Informational. > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From sratliff@cisco.com Mon Apr 11 11:16:48 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6623A6A49 for ; Mon, 11 Apr 2011 11:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PCbQU9J6l4H for ; Mon, 11 Apr 2011 11:16:48 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 233D33A6988 for ; Mon, 11 Apr 2011 11:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=446; q=dns/txt; s=iport; t=1302545808; x=1303755408; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=SfoC16sBsrrhwrBkI01hrD2/7z6gKgbYgTlci0weBIo=; b=b4KrfjNO5hPL1/8ArFyDOnGBAyQWZTUSX3K1lkt5+soOpB/5DYanJEf1 6iUzv8w6TSbYqGi0OIly5dqlncuMuNo1yv4ynr2AOzddTq/knsZC6EznR CVt4tRKg8Ku/WfCntAsiI5dBvH/3kuDVUcftmyLqht8LqmBjSmDmlQ6V3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFlEo02tJXG9/2dsb2JhbACmH3eIep4unC2FbgSNWA X-IronPort-AV: E=Sophos;i="4.64,192,1301875200"; d="scan'208";a="293885113" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2011 18:16:48 +0000 Received: from dhcp-64-102-54-197.cisco.com (dhcp-64-102-54-197.cisco.com [64.102.54.197]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3BIFeWm013785; Mon, 11 Apr 2011 18:16:48 GMT Message-Id: From: Stan Ratliff To: Acee Lindem In-Reply-To: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 11 Apr 2011 14:16:48 -0400 References: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> X-Mailer: Apple Mail (2.936) Cc: OSPF WG List , Sam Hartman Subject: Re: [OSPF] Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:16:48 -0000 Support. Regards, Stan On Apr 11, 2011, at 1:18 PM, Acee Lindem wrote: > There was general agreement that this should be a WG document at the > meeting in Prague. Please indicate your position on making this > draft a WG document with intended status Proposed Standard. > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From zzhang@juniper.net Mon Apr 11 12:10:21 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066B03A6AF4 for ; Mon, 11 Apr 2011 12:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNqiFhjTk8Tl for ; Mon, 11 Apr 2011 12:10:20 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 91C023A6A47 for ; Mon, 11 Apr 2011 12:10:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTaNSGZ0lUGzF15z5WJjlnPcR4Ojod3Fo@postini.com; Mon, 11 Apr 2011 12:10:20 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 11 Apr 2011 12:07:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 11 Apr 2011 15:09:08 -0400 From: "Jeffrey (Zhaohui) Zhang" To: Richard Ogier , "ospf@ietf.org" Date: Mon, 11 Apr 2011 15:09:07 -0400 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: Acv2H274G523fBH3TwqGwZNvQO/NpQCWW/ow Message-ID: <13205C286662DE4387D9AF3AC30EF456D340CA09EE@EMBX01-WF.jnpr.net> References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> <4D9F590A.5050008@earthlink.net> In-Reply-To: <4D9F590A.5050008@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 19:10:21 -0000 Richard, Thanks for your comments and detailed comparison. > -----Original Message----- > From: Richard Ogier [mailto:ogier@earthlink.net]=20 > Sent: Friday, April 08, 2011 2:51 PM > To: ospf@ietf.org > Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > I decided to read the posts regarding this draft (hybrid-bcast-p2mp), > since it is related to OSPF-MANET, and have a few comments. We actually try to completely disassociated it from OSPF-MANET, and the pre= mise is really about "true broadcast single-hop network with per-neighbor m= etrics". >=20 > It was mentioned that RFC 5820 (OSPF-MANET with smart peering) solves > the problem of this draft, assuming that smart peering and=20 > unsynchronized > adjacencies are used. (E.g., Sheth's post on 2/10/2011.) Sheth's comment is not really about that RFC 5820 solves the problem. Rathe= r, a comment was made by someone else about RFC 5820's applicability here a= nd Sheth was trying to point out what exactly need to be done if one were t= o use MANET to get the same result. >=20 > I also want to point out that RFC 5614 (OSPF-MANET-MDR or OSPF-MDR), > which uses CDS flooding via MDRs (MANET Designated Routers), not only > solves the problem of this draft, but provides almost the=20 > same solution > as this draft when OSPF-MDR (with full-topology LSAs and biconnected > adjacencies) is applied to single-hop broadcast networks. The final result does look similar. >=20 > The hybrid-bcast-p2mp draft is nice because it requires only minimal > modifications to OSPF, keeping the DR and BDR and the same=20 > adjacencies. Right - that's why we have been trying to completely disassociating it from= various MANET methods. One could look at it and the alternatives the following way: - Hybrid method is a smiple and straightforward "step-up" from the well-kno= wn/understood/implemented/deployed broadcast interface - MANET method is a "step-down" from the MANET interface which has relative= ly fewer implementations/deployments, and which is understood by fewer peop= le, and which does require some MANET-related code. Therefore, we believe the hybrid way is worth the WG effort to standardize = it. We hope you were not really opposing its acceptance as a WG item, but it is= not quite clear so if you could clarify that'd be great. Thanks. Jeffrey > The reason that OSPF-MDR applied to single-hop broadcast networks > provides almost the same solution as this draft is because it > generalizes the concept of DRs and BDRs to MANETs, and requires > only 2 adjacencies for a non-DR/BDR (or non-MDR/BMDR) in a > single-hop broadcast network. More on this (near) equivalence below. >=20 > In contrast, the solution of draft-retana-ospf-manet, which applies > RFC 5820 with smart peering to single-hop broadcast networks, is quite > different, resulting in a more random selection of adjacencies, > which are not common to any single node such as a DR. > Thus, unlike the other two solutions, draft-retana-ospf-manet is > conceptually quite different from OSPF broadcast, since it does not > use the concept of the DR and BDR. >=20 > One of the goals in the design of OSPF-MDR was to minimize changes > to OSPF. Thus, instead of throwing out the DR and BDR, they were > generalized to multi-hop networks, and were kept essentially the > same in the special case of a single-hop network, for the purpose > of flooding and forming adjacencies. More information on OSPF-MDR > can be found at www.manet-routing.org. >=20 > Now more on the (near) equivalence between hybrid-bcast-p2mp and > OSPF-MDR when applied to a single-hop broadcast network. > In this case, the MDR selection algorithm is very similar to the > DR election algorithm of OSPF, and both select a single DR/MDR. > (There are a few minor differences that are not important to > this discussion.) Also, if AdjConnectivity =3D 2, each node forms > an adjacency with the MDR and BMDR. >=20 > The origination of router LSAs is also nearly equivalent. > The rules in Section 3.6 of hybrid-bcast-p2mp, which specifies > which Type 1 links a non-DR includes in its router LSA, > are similar to the corresponding rules in RFC 5614 when > LSAFullness =3D 4 (full-topology LSAs). In that case, a router > includes all bidirectional (2-Way or higher) neighbors that are > "routable", where a neighbor is routable if SPF has calculated > a route to the neighbor. Note that SPF will calculate such a route > to the neighbor as long as both the router itself and the neighbor > are fully adjacent to the MDR. >=20 > This is slightly different from Section 3.6 of=20 > hybrid-bcast-p2mp, which > only requires that the router itself be fully adjacent to the DR (thus > relying on the requirement of SPF that the neighbor must include a > link back to the router in its LSA). But both solutions achieve the > same goal, in a similar way, using a single DR/MDR that becomes > adjacent with all neighbors. >=20 > Richard >=20 > = From russ@cisco.com Mon Apr 11 15:14:15 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 222F4E065F for ; Mon, 11 Apr 2011 15:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13PmfhjbEqFO for ; Mon, 11 Apr 2011 15:14:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id A729BE0613 for ; Mon, 11 Apr 2011 15:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=961; q=dns/txt; s=iport; t=1302560053; x=1303769653; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=PPXoRWZLdbkbaULbsrrE6pmP8M06lGKR+K+bHScXpa0=; b=S8mtc9wPgEYaSDhMBW0l+KL2h5mixpazqQ3a8hsCcb9lvR18RvUYUznX FkPFxWd+7sqQPkA0ct/InoLfsjDMUW0+Dbs2hlNQ3s3/xz++AkccutTNz P0H6xbBFUvOC+tP+/kw95zUR65LiQc9ATeSraxh3LidN9cYvoANSoJcGV k=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="asc'?scan'208";a="334912915" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2011 20:26:52 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3BKQp5r007689; Mon, 11 Apr 2011 20:26:51 GMT Message-ID: <4DA36406.9060100@cisco.com> Date: Mon, 11 Apr 2011 16:26:46 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Acee Lindem References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE18F31B891A9AA3B7BD4ACED" Cc: OSPF WG List , Alex Zinin Subject: Re: [OSPF] Poll on OSPF Stub Router Advertisement - draft-retana-ospf-rfc3137bis-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 22:14:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE18F31B891A9AA3B7BD4ACED Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > There was general agreement that this should be a WG document at the me= eting in Prague. Please indicate your position on making this draft a WG = document with intended status Informational.=20 Agreed. :-) Russ --------------enigE18F31B891A9AA3B7BD4ACED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2jZAYACgkQER27sUhU9OTy3wCfRmSFOX8ZVatCbqVja64cxcL6 ITYAn0N7qzzyUVtLOkK4D0vhtRiGfKYO =Km9V -----END PGP SIGNATURE----- --------------enigE18F31B891A9AA3B7BD4ACED-- From asmirnov@cisco.com Mon Apr 11 15:33:36 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B5E0E06D4 for ; Mon, 11 Apr 2011 15:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.401 X-Spam-Level: ** X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPO0WQeMPdwJ for ; Mon, 11 Apr 2011 15:33:34 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfc.amsl.com (Postfix) with ESMTP id D480BE06D1 for ; Mon, 11 Apr 2011 15:33:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3BKsiCN022823 for ; Mon, 11 Apr 2011 22:54:44 +0200 (CEST) Received: from [10.55.140.84] (ams-asmirnov-8713.cisco.com [10.55.140.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3BKsf6G008403 for ; Mon, 11 Apr 2011 22:54:42 +0200 (CEST) Message-ID: <4DA36A91.7070305@cisco.com> Date: Mon, 11 Apr 2011 22:54:41 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Thunderbird/3.1.8 MIME-Version: 1.0 To: ospf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 22:33:36 -0000 Hi all, even though I put OSPF-FN draft in the subject it is the framework approach FN-FRWK which draws more questions. At the very first line it reads: > This document describes an architectural work that competes with the > IP Fast Re-Route (IPFRR) solution Lets compare speed of traffic restoration between the two. So, traditional OSPF convergence time consists of the sum of: 1. Failure detection 2. LSA origination 3. Per-hop flooding 4. SPF (delay and calculation itself) 5. RIB/FIB/hardware update 3, 4 and 5 all can be significant depending on network size, number of routes etc. FRR (both MPLS TE FRR and IPFRR) address 2-5. With good implementation FRR should be by order of magnitude as fast as 1. FN addresses only 3. It doesn't address 4 and 5. As I wrote above in many networks they are at least as significant as 3. So, by the speed of convergence FN doesn't look to come anywhere close to FRR. Now, lets look at FN from another perspective. Router announcing failure doesn't benefit from FN. Its immediate neighbors do not benefit from FN either - 1 hop traditional flooding should be as fast as 1 hop FN flooding. It is only distant routers who benefit from the FN - and the farther is router from the failure the bigger is gain. On the other hand, if there exists path alternative to the failed one then _typically_ it is not too far (in terms of hops) from the failing one. I.e. from point of view of router which is 15 hops away from the point of failure it is less likely that routes will change. BTW, ordered FIB approach builds on concept that 'old' routes on remote routers do not cause traffic blackholing or loops. The big problem with FN approach is that routers remote from the point of failure benefit most - but at the same time their convergence is the least important for end-to-end traffic restoration. The worst case network for FN is fully meshed area. Since each router is 1 hop away from every other one FN will give no benefits. The best case network for FN is an area consisting of one big ring. In this case alternative path is on diametrically opposite end of the network and convergence of remote routers is crucial. So yeah, FN will help remote routers to converge faster. But how much this will improve end-to-end traffic restoration in real networks? I suspect not much. Some degree of meshiness in network topology is the norm. FN is an interesting proposal but it is very far from being convincing. Pitching FN against FRR is a mistake. -- Anton From gregimirsky@gmail.com Mon Apr 11 16:12:30 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 39D99E06D8 for ; Mon, 11 Apr 2011 16:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-1.937, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLFtYfVbN3SL for ; Mon, 11 Apr 2011 16:12:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id BC6BBE06B3 for ; Mon, 11 Apr 2011 16:12:28 -0700 (PDT) Received: by vws12 with SMTP id 12so5723272vws.31 for ; Mon, 11 Apr 2011 16:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dNzrse1KdSyJkHIMDsZ3UyUT6qKSHacZ/uCpdVkXFOA=; b=eW7LllEWLCj2wiGD/s7Crua1BQ/4zQDLDTqWew0nVmH/NHQG+TaJPQIWBDXNQZvLgE QYFr6Sh7Vku4SCjCvBklvfuWJZeLTBRiePCG0fheQ69C0ZuhJ3/IlAX2bByJ8Et1rJU6 1OHn0CcVNx15H0b32Vw5oiSXqRmnzTnxwC3Fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IWmvOCE2Ke5Ob9Qlh5Wmva1P8m8FzQb/n6NKP8mZFF2dHYin2Ptm8xdB3U67GR0EAU uplfdXxaqvcBvR60SfGsIAtLM4Rs8uiITeGizRavw1LKgN+bhjLvlJ4s21A223QsELHe ptmAlG5LfJI5tCzVLQ3y6y0I/FRTeAanU4loM= MIME-Version: 1.0 Received: by 10.52.98.97 with SMTP id eh1mr408545vdb.148.1302563547082; Mon, 11 Apr 2011 16:12:27 -0700 (PDT) Received: by 10.52.159.38 with HTTP; Mon, 11 Apr 2011 16:12:26 -0700 (PDT) In-Reply-To: <4DA36A91.7070305@cisco.com> References: <4DA36A91.7070305@cisco.com> Date: Mon, 11 Apr 2011 16:12:26 -0700 Message-ID: From: Greg Mirsky To: Anton Smirnov Content-Type: multipart/alternative; boundary=20cf307d046c856f2c04a0acb500 Cc: ospf@ietf.org Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:12:30 -0000 --20cf307d046c856f2c04a0acb500 Content-Type: text/plain; charset=ISO-8859-1 Dear Anton, I believe that MPLS-TE FRR does not address tasks 2 through 5 in the same sense as it is required in IPFRR. Certainly, protecting LSP has to be calculated by SPF, signaled and RIB/FIB/HW properly updated. But these actions all done prior to when an MPLS-TE deemed protected. Upon Fault detection the only action required is on the PLR. Regards, Greg On Mon, Apr 11, 2011 at 1:54 PM, Anton Smirnov wrote: > Hi all, > even though I put OSPF-FN draft in the subject it is the framework > approach FN-FRWK which draws more questions. At the very first line it > reads: > > This document describes an architectural work that competes with the >> IP Fast Re-Route (IPFRR) solution >> > > Lets compare speed of traffic restoration between the two. So, traditional > OSPF convergence time consists of the sum of: > > 1. Failure detection > 2. LSA origination > 3. Per-hop flooding > 4. SPF (delay and calculation itself) > 5. RIB/FIB/hardware update > > 3, 4 and 5 all can be significant depending on network size, number of > routes etc. > > FRR (both MPLS TE FRR and IPFRR) address 2-5. With good implementation FRR > should be by order of magnitude as fast as 1. > > FN addresses only 3. It doesn't address 4 and 5. As I wrote above in many > networks they are at least as significant as 3. > > So, by the speed of convergence FN doesn't look to come anywhere close to > FRR. > > > Now, lets look at FN from another perspective. Router announcing failure > doesn't benefit from FN. Its immediate neighbors do not benefit from FN > either - 1 hop traditional flooding should be as fast as 1 hop FN flooding. > It is only distant routers who benefit from the FN - and the farther is > router from the failure the bigger is gain. > On the other hand, if there exists path alternative to the failed one > then _typically_ it is not too far (in terms of hops) from the failing one. > I.e. from point of view of router which is 15 hops away from the point of > failure it is less likely that routes will change. BTW, ordered FIB approach > builds on concept that 'old' routes on remote routers do not cause traffic > blackholing or loops. > > The big problem with FN approach is that routers remote from the point of > failure benefit most - but at the same time their convergence is the least > important for end-to-end traffic restoration. > The worst case network for FN is fully meshed area. Since each router is > 1 hop away from every other one FN will give no benefits. > The best case network for FN is an area consisting of one big ring. In > this case alternative path is on diametrically opposite end of the network > and convergence of remote routers is crucial. > > So yeah, FN will help remote routers to converge faster. But how much > this will improve end-to-end traffic restoration in real networks? I suspect > not much. Some degree of meshiness in network topology is the norm. > > FN is an interesting proposal but it is very far from being convincing. > Pitching FN against FRR is a mistake. > > -- > Anton > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --20cf307d046c856f2c04a0acb500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Anton,
I believe that MPLS-TE FRR does not address tasks 2 through = 5 in the same sense as it is required in IPFRR. Certainly, protecting LSP h= as to be calculated by SPF, signaled and RIB/FIB/HW properly updated. But t= hese actions all done prior to when an MPLS-TE deemed protected. Upon Fault= detection the only action required is on the PLR.

Regards,
Greg

On Mon, Apr 11, 2011= at 1:54 PM, Anton Smirnov <asmirnov@cisco.com> wrote:
=A0 Hi all,
=A0 even though I put OSPF-FN draft in the subject it is the framework app= roach FN-FRWK which draws more questions. At the very first line it reads:<= br>
This document describes an architectural work that competes with the
IP Fast Re-Route (IPFRR) solution

Lets compare speed of traffic restoration between the two. So, traditional = OSPF convergence time consists of the sum of:

1. Failure detection
2. LSA origination
3. Per-hop flooding
4. SPF (delay and calculation itself)
5. RIB/FIB/hardware update

3, 4 and 5 all can be significant depending on network size, number of rout= es etc.

FRR (both MPLS TE FRR and IPFRR) address 2-5. With good implementation FRR = should be by order of magnitude as fast as 1.

FN addresses only 3. It doesn't address 4 and 5. As I wrote above in ma= ny networks they are at least as significant as 3.

So, by the speed of convergence FN doesn't look to come anywhere close = to FRR.


=A0 Now, lets look at FN from another perspective. Router announcing failu= re doesn't benefit from FN. Its immediate neighbors do not benefit from= FN either - 1 hop traditional flooding should be as fast as 1 hop FN flood= ing. It is only distant routers who benefit from the FN - and the farther i= s router from the failure the bigger is gain.
=A0 On the other hand, if there exists path alternative to the failed one = then _typically_ it is not too far (in terms of hops) from the failing one.= I.e. from point of view of router which is 15 hops away from the point of = failure it is less likely that routes will change. BTW, ordered FIB approac= h builds on concept that 'old' routes on remote routers do not caus= e traffic blackholing or loops.

=A0 The big problem with FN approach is that routers remote from the point= of failure benefit most - but at the same time their convergence is the le= ast important for end-to-end traffic restoration.
=A0 The worst case network for FN is fully meshed area. Since each router = is 1 hop away from every other one FN will give no benefits.
=A0 The best case network for FN is an area consisting of one big ring. In= this case alternative path is on diametrically opposite end of the network= and convergence of remote routers is crucial.

=A0 So yeah, FN will help remote routers to converge faster. But how much = this will improve end-to-end traffic restoration in real networks? I suspec= t not much. Some degree of meshiness in network topology is the norm.

=A0 FN is an interesting proposal but it is very far from being convincing= . Pitching FN against FRR is a mistake.

--
Anton

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf

--20cf307d046c856f2c04a0acb500-- From yiya@cisco.com Mon Apr 11 16:36:50 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D823EE066E for ; Mon, 11 Apr 2011 16:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMD1aEyh+S+K for ; Mon, 11 Apr 2011 16:36:50 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 029B8E0613 for ; Mon, 11 Apr 2011 16:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yiya@cisco.com; l=425; q=dns/txt; s=iport; t=1302565010; x=1303774610; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CDZ0l03qirBSF8HAX+0t00noo4bTDAGZS81KHF4fdq4=; b=DIXTPt4pYR6jE5Vn601yYcasOzphl2TbfLiGimlZ2IOyvc4Jw6g8oxS8 nPXZzBqNgv/Lz0BcndB3hUbIrCBzetjPCSOY5gkHAtsI3r9o/liytMO4B iAVDzRbMe9UydExWB2hHf92xcoM/aRGSaInP/TEARmFWQRf9UB6MPBHvg k=; X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="scan'208";a="294085767" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2011 23:36:43 +0000 Received: from rtp-yiya-87111.cisco.com (rtp-yiya-87111.cisco.com [10.116.75.12]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3BNaglb006557; Mon, 11 Apr 2011 23:36:42 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Yi Yang In-Reply-To: Date: Mon, 11 Apr 2011 19:37:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F919940-FA70-4072-A9B0-A513E835394F@cisco.com> References: To: Acee Lindem X-Mailer: Apple Mail (2.1082) Cc: OSPF WG List , Alex Zinin Subject: Re: [OSPF] Poll on OSPF Stub Router Advertisement - draft-retana-ospf-rfc3137bis-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:36:51 -0000 support. Yi On Apr 11, 2011, at 12:21 PM, Acee Lindem wrote: > There was general agreement that this should be a WG document at the = meeting in Prague. Please indicate your position on making this draft a = WG document with intended status Informational.=20 > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From glen.kent@gmail.com Mon Apr 11 16:40:30 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8A83E06D2 for ; Mon, 11 Apr 2011 16:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6n7-k7PMte1 for ; Mon, 11 Apr 2011 16:40:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id C48BDE06A3 for ; Mon, 11 Apr 2011 16:40:29 -0700 (PDT) Received: by vws12 with SMTP id 12so5748718vws.31 for ; Mon, 11 Apr 2011 16:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HMiWc44bmAOyu9oKwhPkmwWXo1+FUjeNWs0F/P5ayEU=; b=L2ZmfiH9dxh6WmkmDlZ0AV6+1jc7bW4zMijXaysqLoE1K8MYClxsl/m0fJQ4S1gs59 m1At3vEJ27STtOJDdSSI3sfu5Vx0bi5rGdAkuSfTImrz4kMHqwPgVQsQn7JZ5Lcb0D+p Ul9JqorC5gsbQLcosZ8WxDBbRu6R7dzAiDddY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c0+D1Rb2LsFDr4BdokZmEQK5K6E68WwVYRBuzUY2hSPq6T87ef2zz0YFFCt4wQKCdq H+nPvjuynLB/BG1OrWPTbEvHy4nvLRCY6JotACvdpg/Q4x+9nmXX2J5r3K0/8jkE94bw UMI0+47WiqC+0WsH6D1spHwyRyZuLHVMUkL08= MIME-Version: 1.0 Received: by 10.52.76.195 with SMTP id m3mr507181vdw.130.1302565216716; Mon, 11 Apr 2011 16:40:16 -0700 (PDT) Received: by 10.52.160.6 with HTTP; Mon, 11 Apr 2011 16:40:16 -0700 (PDT) In-Reply-To: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> References: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> Date: Tue, 12 Apr 2011 05:10:16 +0530 Message-ID: From: Glen Kent To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Cc: OSPF WG List Subject: Re: [OSPF] Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:40:31 -0000 Support On Mon, Apr 11, 2011 at 10:48 PM, Acee Lindem wrote: > There was general agreement that this should be a WG document at the meeting in Prague. Please indicate your position on making this draft a WG document with intended status Proposed Standard. > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From glen.kent@gmail.com Mon Apr 11 16:40:40 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B0DDE06F4 for ; Mon, 11 Apr 2011 16:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAJ3+kr7j6Vt for ; Mon, 11 Apr 2011 16:40:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id A68C1E06EE for ; Mon, 11 Apr 2011 16:40:35 -0700 (PDT) Received: by mail-vw0-f44.google.com with SMTP id 12so5748718vws.31 for ; Mon, 11 Apr 2011 16:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n+9DvXg0SRMz6aQS89Iab4+pesZ+NsPlsdee6LEFXJg=; b=ftsmgrg7+tnpLVjCIKv4Edk/47caDxzJD/087eaMxjrC3sF1IwUEHeT18quip96gup gT73/8/d7WiSUTmPhtqBRqmgvmd63MpZQWeCr7rZ2sgUNvcdJq1MwwpMjtA+U18jeNmr GgN8/AuJ4RpBuWTaHhqv5SK/rMG3QGNcN7zgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Is8C1JObKiPbpgRqVaO0B7YiGTmT699LlmfNPGgoy4/2oi1rXsgRfrj5ooOCIPimk8 K0mxgmgA/b/8a8sKQCBVxRTqc4qwibsC/j37ZqEosR+XMk0OpHgixwLS3jZYJnmKqgVS U6NHtIL61qQrVIdYnbsL9JWYJv0xIq9jtm/Bk= MIME-Version: 1.0 Received: by 10.52.176.163 with SMTP id cj3mr2418836vdc.210.1302565235728; Mon, 11 Apr 2011 16:40:35 -0700 (PDT) Received: by 10.52.160.6 with HTTP; Mon, 11 Apr 2011 16:40:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2011 05:10:35 +0530 Message-ID: From: Glen Kent To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Cc: OSPF WG List , Alex Zinin Subject: Re: [OSPF] Poll on OSPF Stub Router Advertisement - draft-retana-ospf-rfc3137bis-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:40:40 -0000 Support On Mon, Apr 11, 2011 at 9:51 PM, Acee Lindem wrote: > There was general agreement that this should be a WG document at the meeting in Prague. Please indicate your position on making this draft a WG document with intended status Informational. > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From glen.kent@gmail.com Mon Apr 11 16:41:38 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54D11E0703 for ; Mon, 11 Apr 2011 16:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYWpzUNH3oFi for ; Mon, 11 Apr 2011 16:41:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 69E42E0700 for ; Mon, 11 Apr 2011 16:41:36 -0700 (PDT) Received: by vws12 with SMTP id 12so5749798vws.31 for ; Mon, 11 Apr 2011 16:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6cxJAIG5jj4dZz4MJnTdolMT42B03meW/6cX8l4JSgg=; b=okVrRMIkOgGy4GLiEqyDhpnU2jQm9GMcIszWyWP+ThAyhxs/3YKFX5cIucLjgy74Sl qdrQ8Scgsny754df6pwcIdW7PK2vO7Mdsu6aGMvJoBAfGYpsr5HjNNR0oLdt6a0468bK RVvVfluWmtwnYIywbZ0hXNwbjN35uPM5X6nbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xF6XciWZSOiGcS4PLV7HD4CKJ8t/HZ8DPzNUlNAgrFza3zAhoUzm1h6qrF8duRG1Pj tocs5X3DjRM/X2kmr8YTdZAQPUKyePG8xGlvlINrGCjczAyvMAs9r+39SnsoyyD+IN8w +MZkSs90kQedHXb/uU205O0oxpQHPxK4AH6UA= MIME-Version: 1.0 Received: by 10.52.172.2 with SMTP id ay2mr8627510vdc.50.1302565295130; Mon, 11 Apr 2011 16:41:35 -0700 (PDT) Received: by 10.52.160.6 with HTTP; Mon, 11 Apr 2011 16:41:35 -0700 (PDT) In-Reply-To: <4DA329FE.4050108@cisco.com> References: <4DA329FE.4050108@cisco.com> Date: Tue, 12 Apr 2011 05:11:35 +0530 Message-ID: From: Glen Kent To: Abhay Roy Content-Type: multipart/alternative; boundary=bcaec53f2ae7b6897a04a0ad1d9e Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:41:38 -0000 --bcaec53f2ae7b6897a04a0ad1d9e Content-Type: text/plain; charset=ISO-8859-1 No comments! On Mon, Apr 11, 2011 at 9:49 PM, Abhay Roy wrote: > We are starting the Working Group Last Call of this revision of the > subject draft. > > This drafts is intended to be a Proposed Standard. The OSPF WG last call > will begin today and will end at 5pm PST, April 25th, 2011. > > Abhay/Acee > > -------- Original Message -------- Subject: I-D > Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt Date: Sat, 19 Feb 2011 > 12:00:02 -0800 From: Internet-Drafts@ietf.org Reply-To: > internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ospf@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > > Title : Supporting Authentication Trailer for OSPFv3 > Author(s) : M. Bhatia, et al. > Filename : draft-ietf-ospf-auth-trailer-ospfv3-03.txt > Pages : 20 > Date : 2011-02-19 > > Currently OSPFv3 uses IPsec for authenticating protocol packets. > However, there are some environments, e.g., Mobile Ad-hoc Networks > (MANETs), where IPsec is difficult to configure and maintain, and > this mechanism cannot be used. This draft proposes an alternative > mechanism that can be used so that OSPFv3 does not depend upon IPsec > for authentication. > > A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.txt > > Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --bcaec53f2ae7b6897a04a0ad1d9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No comments!

On Mon, Apr 11, 2011 at 9:49= PM, Abhay Roy <akr@c= isco.com> wrote:
=20
We are starting the Working Group Last Call of this revision of the subject draft.

This drafts is intended to be a Proposed Standard. The OSPF WG last call
will begin today and will end at 5pm PST,=A0 April 25th, 2011.

Abhay/Acee

-------- Original Message --------
Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt
Date: Sat, 19 Feb 2011 12:00:02 -0800
From: Int= ernet-Drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-an= nounce@ietf.org
CC: ospf@ietf.org<= /a> 


A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
This draft is a work item of the Open Shortest Path First IGP Working Group=
 of the IETF.


	Title           : Supporting Authentication Trailer for OSPFv3
	Author(s)       : M. Bhatia, et al.
	Filename        : draft-ietf-ospf-auth-trailer-ospfv3-03.txt
	Pages           : 20
	Date            : 2011-02-19

Currently OSPFv3 uses IPsec for authenticating protocol packets.
However, there are some environments, e.g., Mobile Ad-hoc Networks
(MANETs), where IPsec is difficult to configure and maintain, and
this mechanism cannot be used.  This draft proposes an alternative
mechanism that can be used so that OSPFv3 does not depend upon IPsec
for authentication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft=
-ietf-ospf-auth-trailer-ospfv3-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp=
.ietf.org/internet-drafts/

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

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf


--bcaec53f2ae7b6897a04a0ad1d9e-- From kohn.jack@gmail.com Mon Apr 11 17:00:18 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 43A3DE0613 for ; Mon, 11 Apr 2011 17:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OAxV7tVrd31 for ; Mon, 11 Apr 2011 17:00:17 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id CA249E069D for ; Mon, 11 Apr 2011 17:00:16 -0700 (PDT) Received: by pvh1 with SMTP id 1so2736916pvh.31 for ; Mon, 11 Apr 2011 17:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s0oJFIJbyn9+wIFkUvEz/JZkBuNhPlLV4F6RaA9H33M=; b=j1FiArumo0+rj8nNebtjs7umfAneeOVnvvQMG1ZeoMTd+cRkT5zn4JUAqX4HOXDtxu w3T/xtzD/OwWzwmqp12wQUkOGr4qMCegft8TkmeY1h5TPrtf2rEXdJu1tvtFaQudaSqE 4/PboMXMUfxhWkcjhimhN/7XyBoxbj0u+TbrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YuV8FMF7SJatbS2nuU1t9KsZfNGtOQPuDF7f4+IVttWyP9v8xdyA9lFaKjnSUU6MVF d/iJlaD6VuYkU7lNpHk9d6hjSf99prsnDOb6d7pnoAQzmg5Q6Y83JhcPBM+E4cpPCpmH 1/UZoWmt1VqBWVxhJiIs3UYrUH9r0fsVQ/iMg= MIME-Version: 1.0 Received: by 10.142.151.6 with SMTP id y6mr5600421wfd.34.1302566414957; Mon, 11 Apr 2011 17:00:14 -0700 (PDT) Received: by 10.68.52.131 with HTTP; Mon, 11 Apr 2011 17:00:14 -0700 (PDT) In-Reply-To: References: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> Date: Tue, 12 Apr 2011 05:30:14 +0530 Message-ID: From: Jack Kohn To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: OSPF WG List , Sam Hartman Subject: Re: [OSPF] Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 00:00:18 -0000 +1 On Mon, Apr 11, 2011 at 11:46 PM, Stan Ratliff wrote: > Support. > > Regards, > Stan > > > On Apr 11, 2011, at 1:18 PM, Acee Lindem wrote: > >> There was general agreement that this should be a WG document at the >> meeting in Prague. Please indicate your position on making this draft a WG >> document with intended status Proposed Standard. >> >> Thanks, >> Acee >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From shtsuchi@cisco.com Mon Apr 11 18:03:38 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CFBFCE06A4 for ; Mon, 11 Apr 2011 18:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74FUuujrXJVx for ; Mon, 11 Apr 2011 18:03:36 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 21D06E0613 for ; Mon, 11 Apr 2011 18:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=431; q=dns/txt; s=iport; t=1302570216; x=1303779816; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kCFiR2ojH5oE4runGZpN37TfadKDijoBL+Mqjv8w/H0=; b=bQqBPoYcxQ0QO3vXYvPI4gZ5/d6EGfDhlbeCDMUNKK9tROfSbH8TnlKj B56xedE5YrDbf22JrzfiT+r1mphHfnOA5XqOPlw/kWDLPpBWKigD1ExEP 1FobyfEvb8Z3vPO+Eo3AZcj/mXr/ZvlgRzlys7bUvgU1JzIn1Mz4bC5Rc U=; X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="scan'208";a="335059790" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2011 01:03:29 +0000 Received: from [10.71.33.219] (tky-shtsuchi-87110.cisco.com [10.71.33.219]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3C13S2E026964; Tue, 12 Apr 2011 01:03:28 GMT Message-ID: <4DA3A4E2.6090603@cisco.com> Date: Tue, 12 Apr 2011 10:03:30 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: acee.lindem@ericsson.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org, azinin@cisco.com Subject: Re: [OSPF] Poll on OSPF Stub Router Advertisement - draft-retana-ospf-rfc3137bis-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 01:03:38 -0000 Of course support! Regards, -Shishio (2011/04/12 1:21), Acee Lindem wrote: > There was general agreement that this should be a WG document at the meeting in Prague. Please indicate your position on making this draft a WG document with intended status Informational. > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From curtis@occnc.com Mon Apr 11 19:42:55 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5668AE069F for ; Mon, 11 Apr 2011 19:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mi88i-Fep6H for ; Mon, 11 Apr 2011 19:42:54 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id B0BC1E069D for ; Mon, 11 Apr 2011 19:42:54 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3C2gqQQ022480; Mon, 11 Apr 2011 22:42:52 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104120242.p3C2gqQQ022480@harbor.orleans.occnc.com> To: Abhay Roy From: Curtis Villamizar In-reply-to: Your message of "Mon, 11 Apr 2011 09:19:10 PDT." <4DA329FE.4050108@cisco.com> Date: Mon, 11 Apr 2011 22:42:52 -0400 Sender: curtis@occnc.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 02:42:55 -0000 In message <4DA329FE.4050108@cisco.com> Abhay Roy writes: > > We are starting the Working Group Last Call of this revision of the > subject draft. > > This drafts is intended to be a Proposed Standard. The OSPF WG last > call will begin today and will end at 5pm PST, April 25th, 2011. > > Abhay/Acee It is weak with only the 32 bit sequence number. That said, if there is concensus for moving forward as-is I have no objection. It is a step in the right direction, though IMHO it is too small a step in the right direction and would not have to be revisited quite as soon if something more robust were proposed. Bottom line. Falls short of what I'd like to see but no objection. Curtis From curtis@occnc.com Mon Apr 11 19:58:21 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 538A6E06C2 for ; Mon, 11 Apr 2011 19:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3pAGQdbesus for ; Mon, 11 Apr 2011 19:58:20 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id AEFDAE06B3 for ; Mon, 11 Apr 2011 19:58:20 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3C2wGfH022688; Mon, 11 Apr 2011 22:58:16 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104120258.p3C2wGfH022688@harbor.orleans.occnc.com> To: Acee Lindem From: Curtis Villamizar In-reply-to: Your message of "Mon, 11 Apr 2011 13:18:08 EDT." <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> Date: Mon, 11 Apr 2011 22:58:16 -0400 Sender: curtis@occnc.com Cc: OSPF WG List , Sam Hartman Subject: Re: [OSPF] Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 02:58:21 -0000 In message <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> Acee Lindem writes: > > There was general agreement that this should be a WG document at the > meeting in Prague. Please indicate your position on making this draft > a WG document with intended status Proposed Standard. > > Thanks, > Acee Yes I support making this a WG item. One improvement and something pointed out in KARP is that public/private key pairs are often used and have advantages over shared keys. One thing that can be done if a public/private key pair is used is encrypt a session key for use during a session. Instead of a sequence number or session ID, the key itself is exchanged. That is somewhat similar to the way kerberos makes use of a session key to encrypt as little information as possible using the shared secret that is used to get a tgt from the KDC. This has an advantage that with a periodic change in the session key a snooper with access to a lot of computing resource could still have trouble breaking the session key before it changed. For most applications of OSPF this won't matter. For some it might. Curtis And always remember - just because you are paranoid doesn't mean they are not out to get you. :-) From manav.bhatia@alcatel-lucent.com Mon Apr 11 20:08:57 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DE49DE0676 for ; Mon, 11 Apr 2011 20:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.46 X-Spam-Level: X-Spam-Status: No, score=-4.46 tagged_above=-999 required=5 tests=[AWL=2.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ziw0fAYIdbVO for ; Mon, 11 Apr 2011 20:08:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id 49814E0663 for ; Mon, 11 Apr 2011 20:08:56 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3C38pAY017279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Apr 2011 22:08:53 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3C38nwL021075 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Apr 2011 08:38:50 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 12 Apr 2011 08:38:49 +0530 From: "Bhatia, Manav (Manav)" To: "curtis@occnc.com" , Abhay Roy Date: Tue, 12 Apr 2011 08:38:47 +0530 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt Thread-Index: Acv4u1pkZIwQl4A3QZ68PORM3FCnGwAAv5Pg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD037ADA@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of "Mon, 11 Apr 2011 09:19:10 PDT." <4DA329FE.4050108@cisco.com> <201104120242.p3C2gqQQ022480@harbor.orleans.occnc.com> In-Reply-To: <201104120242.p3C2gqQQ022480@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 03:08:58 -0000 Hi Curtis, This draft aligns the OSPFv3 security mechanism with that of OSPFv2. Once t= his is done, any proposal or extension that works for OSPFv2 will work for = OSPFv3 as well.=20 If for example, we decide to go via the nonce and session ID mechanism or t= he KARP boot count, then that mechanism will work for OSPFv3 also. So, this really is orthogonal to the work that's being carried out in KARP/= OSPF WGs. Once that gets frozen it will be applicable to OSPFv3 as well. Ho= wever, that can happen only once we have this piece in. Cheers, Manav > It is weak with only the 32 bit sequence number. That said, if there > is concensus for moving forward as-is I have no objection. It is a > step in the right direction, though IMHO it is too small a step in the > right direction and would not have to be revisited quite as soon if > something more robust were proposed. >=20 > Bottom line. Falls short of what I'd like to see but no objection. >=20 > Curtis >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > = From curtis@occnc.com Mon Apr 11 20:16:33 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33577E0663 for ; Mon, 11 Apr 2011 20:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfTFuPY+3Cmy for ; Mon, 11 Apr 2011 20:16:32 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 60AF4E0674 for ; Mon, 11 Apr 2011 20:16:32 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3C3GSbv022950; Mon, 11 Apr 2011 23:16:28 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104120316.p3C3GSbv022950@harbor.orleans.occnc.com> To: Greg Mirsky From: Curtis Villamizar In-reply-to: Your message of "Mon, 11 Apr 2011 16:12:26 PDT." Date: Mon, 11 Apr 2011 23:16:28 -0400 Sender: curtis@occnc.com Cc: ospf@ietf.org Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 03:16:33 -0000 In message Greg Mirsky writes: > > Dear Anton, > > I believe that MPLS-TE FRR does not address tasks 2 through 5 in the > same sense as it is required in IPFRR. Certainly, protecting LSP has > to be calculated by SPF, signaled and RIB/FIB/HW properly updated. But > these actions all done prior to when an MPLS-TE deemed protected. Upon > Fault detection the only action required is on the PLR. > > Regards, > Greg Greg, IPFRR does not need tasks 2 through 5 either. OTOH, IPFRR coverage is often less than full coverage. In both MPLS FRR and IPFRR, if protection works it is handled entirely by the PLR. In IPFRR, some PLRs have no fast protection and have to rely on flooding. In IPFRR and MPLS FRR sometimes unexpected multiple failures occur since a previously unknown shared resource is discovered the hard way or an extroidinary event occurs (ie: two fibers on same fault line, etc). In this case even protection from the MPLS FRR PLR doesn't work. In MPLS if a reroute is required, the CSPF load being N^2 log N (order N CSPF computation have to be run), the LSA flooding has no significant impact at all. In IPFRR where only one SPF has to be run, flooding is still not the primary contributor to convergence time. It may be a combination of 4 and 5 below. Curtis > On Mon, Apr 11, 2011 at 1:54 PM, Anton Smirnov wrote: > > > Hi all, > > even though I put OSPF-FN draft in the subject it is the framework > > approach FN-FRWK which draws more questions. At the very first line it > > reads: > > > > This document describes an architectural work that competes with the > >> IP Fast Re-Route (IPFRR) solution > >> > > > > Lets compare speed of traffic restoration between the two. So, traditional > > OSPF convergence time consists of the sum of: > > > > 1. Failure detection > > 2. LSA origination > > 3. Per-hop flooding > > 4. SPF (delay and calculation itself) > > 5. RIB/FIB/hardware update > > > > 3, 4 and 5 all can be significant depending on network size, number of > > routes etc. > > > > FRR (both MPLS TE FRR and IPFRR) address 2-5. With good implementation FRR > > should be by order of magnitude as fast as 1. > > > > FN addresses only 3. It doesn't address 4 and 5. As I wrote above in many > > networks they are at least as significant as 3. > > > > So, by the speed of convergence FN doesn't look to come anywhere close to > > FRR. > > > > > > Now, lets look at FN from another perspective. Router announcing failure > > doesn't benefit from FN. Its immediate neighbors do not benefit from FN > > either - 1 hop traditional flooding should be as fast as 1 hop FN flooding. > > It is only distant routers who benefit from the FN - and the farther is > > router from the failure the bigger is gain. > > On the other hand, if there exists path alternative to the failed one > > then _typically_ it is not too far (in terms of hops) from the failing one. > > I.e. from point of view of router which is 15 hops away from the point of > > failure it is less likely that routes will change. BTW, ordered FIB approach > > builds on concept that 'old' routes on remote routers do not cause traffic > > blackholing or loops. > > > > The big problem with FN approach is that routers remote from the point of > > failure benefit most - but at the same time their convergence is the least > > important for end-to-end traffic restoration. > > The worst case network for FN is fully meshed area. Since each router is > > 1 hop away from every other one FN will give no benefits. > > The best case network for FN is an area consisting of one big ring. In > > this case alternative path is on diametrically opposite end of the network > > and convergence of remote routers is crucial. > > > > So yeah, FN will help remote routers to converge faster. But how much > > this will improve end-to-end traffic restoration in real networks? I suspect > > not much. Some degree of meshiness in network topology is the norm. > > > > FN is an interesting proposal but it is very far from being convincing. > > Pitching FN against FRR is a mistake. > > > > -- > > Anton From michael_barnes@usa.net Mon Apr 11 20:33:57 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 66D04E06C2 for ; Mon, 11 Apr 2011 20:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ4cM4pkEu2h for ; Mon, 11 Apr 2011 20:33:56 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by ietfc.amsl.com (Postfix) with ESMTP id B4BE5E0698 for ; Mon, 11 Apr 2011 20:33:56 -0700 (PDT) Received: from cmsout02.mbox.net (co02-lo [127.0.0.1]) by cmsout02.mbox.net (Postfix) with ESMTP id BFE401340D2; Tue, 12 Apr 2011 03:33:55 +0000 (GMT) X-USANET-Received: from cmsout02.mbox.net [127.0.0.1] by cmsout02.mbox.net via mtad (C8.MAIN.3.72B) with ESMTP id 783PDLDhz2864M02; Tue, 12 Apr 2011 03:33:51 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from cmsapps03.cms.usa.net [165.212.11.132] by cmsout02.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID785PDLDhz3032X02; Tue, 12 Apr 2011 03:33:51 -0000 X-USANET-Source: 165.212.11.132 IN michael_barnes@usa.net cmsapps03.cms.usa.net X-USANET-MsgId: XID785PDLDhz3032X02 Received: from web02.cms.usa.net [165.212.8.202] by cmsapps03.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.72B) with ESMTP id 803PDLDhY3072M39; Tue, 12 Apr 2011 03:33:50 -0000 X-USANET-Auth: 165.212.8.202 AUTO michael_barnes@usa.net web02.cms.usa.net Received: from 198.144.206.23 [198.144.206.23] by web02.cms.usa.net (USANET web-mailer C8.MAIN.3.73O); Tue, 12 Apr 2011 03:33:50 -0000 Date: Mon, 11 Apr 2011 20:33:50 -0700 From: "Michael Barnes" To: , Abhay Roy X-Mailer: USANET web-mailer (C8.MAIN.3.73O) Mime-Version: 1.0 Message-ID: <741PDLDGY7792S02.1302579230@web02.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID803PDLDhz3072X39 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 03:33:57 -0000 ------ Original Message ------ Received: Mon, 11 Apr 2011 07:43:06 PM PDT From: Curtis Villamizar To: Abhay Roy Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer fo= r OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt > = > In message <4DA329FE.4050108@cisco.com> > Abhay Roy writes: > > = > > We are starting the Working Group Last Call of this revision of the > > subject draft. > > = > > This drafts is intended to be a Proposed Standard. The OSPF WG last > > call will begin today and will end at 5pm PST, April 25th, 2011. > > = > > Abhay/Acee > = > = > It is weak with only the 32 bit sequence number. That said, if there > is concensus for moving forward as-is I have no objection. It is a > step in the right direction, though IMHO it is too small a step in the > right direction and would not have to be revisited quite as soon if > something more robust were proposed. > = > Bottom line. Falls short of what I'd like to see but no objection. > = > Curtis I agree with Curis. I'd really like to see the first version of this spec= at least have the extended sequence number as is being discussed for v2. Regards, Michael From curtis@occnc.com Mon Apr 11 20:40:18 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CC55FE069F for ; Mon, 11 Apr 2011 20:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hZl1Afu2+CZ for ; Mon, 11 Apr 2011 20:40:18 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 3013EE0663 for ; Mon, 11 Apr 2011 20:40:18 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3C3eDnC023873; Mon, 11 Apr 2011 23:40:13 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104120340.p3C3eDnC023873@harbor.orleans.occnc.com> To: "Bhatia, Manav (Manav)" From: Curtis Villamizar In-reply-to: Your message of "Tue, 12 Apr 2011 08:38:47 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD037ADA@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 11 Apr 2011 23:40:13 -0400 Sender: curtis@occnc.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 03:40:19 -0000 In message <7C362EEF9C7896468B36C9B79200D8350CFD037ADA@INBANSXCHMBSA1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > Hi Curtis, > > This draft aligns the OSPFv3 security mechanism with that of > OSPFv2. Once this is done, any proposal or extension that works for > OSPFv2 will work for OSPFv3 as well. > > If for example, we decide to go via the nonce and session ID mechanism > or the KARP boot count, then that mechanism will work for OSPFv3 also. > > So, this really is orthogonal to the work that's being carried out in > KARP/OSPF WGs. Once that gets frozen it will be applicable to OSPFv3 > as well. However, that can happen only once we have this piece in. > > Cheers, Manav Thanks. Curtis > > It is weak with only the 32 bit sequence number. That said, if there > > is concensus for moving forward as-is I have no objection. It is a > > step in the right direction, though IMHO it is too small a step in the > > right direction and would not have to be revisited quite as soon if > > something more robust were proposed. > > > > Bottom line. Falls short of what I'd like to see but no objection. > > > > Curtis > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf From gregimirsky@gmail.com Mon Apr 11 21:45:09 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B1934E070A for ; Mon, 11 Apr 2011 21:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.207 X-Spam-Level: X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[AWL=-2.195, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phEp-Bx+puwq for ; Mon, 11 Apr 2011 21:45:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 53396E065A for ; Mon, 11 Apr 2011 21:45:08 -0700 (PDT) Received: by vxg33 with SMTP id 33so5677465vxg.31 for ; Mon, 11 Apr 2011 21:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MgkH8dzdzhCbQ35mMSWh8uIvq5HlmmbhRFQ0BiVALhI=; b=iIlcNwVJyB5u4+Qi4mF6/BmHfi1yhvGwxAC7L/+SavCm4c41fVEG15t/wCmwkKTb/l GStAsVH0lJqnT9z35kv9U2MLHhNlLJ97+6YowzEUXF00fOMJpQ7n+ZEpAFJ0ydBbQXdJ 3Fz0DR2vcAD0wFEc01biWcRPUfGKvlYRrYr0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fiu5tByzFraZUpdWUvKsK/n/u3Cs+RtEfH1QpyaKIvkTQSU5YeYOMXZ8NI3DOwiHmP f8TbGWlNVywB2YqqizLsD+2DkG1QXmz3vga+UNLYB5YhHLu5+kejN+ehM4QM+y7Rc9p5 y+nKgsL1txD1KxgDpQRt3d1RajdSODZfMkCxw= MIME-Version: 1.0 Received: by 10.52.72.14 with SMTP id z14mr1068211vdu.68.1302583507961; Mon, 11 Apr 2011 21:45:07 -0700 (PDT) Received: by 10.52.159.38 with HTTP; Mon, 11 Apr 2011 21:45:07 -0700 (PDT) In-Reply-To: <201104120316.p3C3GSbv022950@harbor.orleans.occnc.com> References: <201104120316.p3C3GSbv022950@harbor.orleans.occnc.com> Date: Mon, 11 Apr 2011 21:45:07 -0700 Message-ID: From: Greg Mirsky To: curtis@occnc.com Content-Type: multipart/alternative; boundary=20cf307cfe7848490804a0b15b14 Cc: ospf@ietf.org Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 04:45:09 -0000 --20cf307cfe7848490804a0b15b14 Content-Type: text/plain; charset=ISO-8859-1 Hi Curtis, thank you for the explanation on IPFRR. I know that things are sometimes are not what we call them but I believe that if MPLS FRR doesn't work for some reason and LSP rerouted to restore service it's not FRR. Would IPFRR still be considered FRR if restoration of connectivity relies on flooding and route convergence, not on use of pre-calculated RIB? Regards, Greg On Mon, Apr 11, 2011 at 8:16 PM, Curtis Villamizar wrote: > > In message > Greg Mirsky writes: > > > > Dear Anton, > > > > I believe that MPLS-TE FRR does not address tasks 2 through 5 in the > > same sense as it is required in IPFRR. Certainly, protecting LSP has > > to be calculated by SPF, signaled and RIB/FIB/HW properly updated. But > > these actions all done prior to when an MPLS-TE deemed protected. Upon > > Fault detection the only action required is on the PLR. > > > > Regards, > > Greg > > Greg, > > IPFRR does not need tasks 2 through 5 either. OTOH, IPFRR coverage is > often less than full coverage. > > In both MPLS FRR and IPFRR, if protection works it is handled entirely > by the PLR. In IPFRR, some PLRs have no fast protection and have to > rely on flooding. In IPFRR and MPLS FRR sometimes unexpected multiple > failures occur since a previously unknown shared resource is > discovered the hard way or an extroidinary event occurs (ie: two > fibers on same fault line, etc). In this case even protection from > the MPLS FRR PLR doesn't work. > > In MPLS if a reroute is required, the CSPF load being N^2 log N (order > N CSPF computation have to be run), the LSA flooding has no > significant impact at all. In IPFRR where only one SPF has to be run, > flooding is still not the primary contributor to convergence time. It > may be a combination of 4 and 5 below. > > Curtis > > > > On Mon, Apr 11, 2011 at 1:54 PM, Anton Smirnov > wrote: > > > > > Hi all, > > > even though I put OSPF-FN draft in the subject it is the framework > > > approach FN-FRWK which draws more questions. At the very first line it > > > reads: > > > > > > This document describes an architectural work that competes with the > > >> IP Fast Re-Route (IPFRR) solution > > >> > > > > > > Lets compare speed of traffic restoration between the two. So, > traditional > > > OSPF convergence time consists of the sum of: > > > > > > 1. Failure detection > > > 2. LSA origination > > > 3. Per-hop flooding > > > 4. SPF (delay and calculation itself) > > > 5. RIB/FIB/hardware update > > > > > > 3, 4 and 5 all can be significant depending on network size, number of > > > routes etc. > > > > > > FRR (both MPLS TE FRR and IPFRR) address 2-5. With good implementation > FRR > > > should be by order of magnitude as fast as 1. > > > > > > FN addresses only 3. It doesn't address 4 and 5. As I wrote above in > many > > > networks they are at least as significant as 3. > > > > > > So, by the speed of convergence FN doesn't look to come anywhere close > to > > > FRR. > > > > > > > > > Now, lets look at FN from another perspective. Router announcing > failure > > > doesn't benefit from FN. Its immediate neighbors do not benefit from FN > > > either - 1 hop traditional flooding should be as fast as 1 hop FN > flooding. > > > It is only distant routers who benefit from the FN - and the farther is > > > router from the failure the bigger is gain. > > > On the other hand, if there exists path alternative to the failed one > > > then _typically_ it is not too far (in terms of hops) from the failing > one. > > > I.e. from point of view of router which is 15 hops away from the point > of > > > failure it is less likely that routes will change. BTW, ordered FIB > approach > > > builds on concept that 'old' routes on remote routers do not cause > traffic > > > blackholing or loops. > > > > > > The big problem with FN approach is that routers remote from the > point of > > > failure benefit most - but at the same time their convergence is the > least > > > important for end-to-end traffic restoration. > > > The worst case network for FN is fully meshed area. Since each router > is > > > 1 hop away from every other one FN will give no benefits. > > > The best case network for FN is an area consisting of one big ring. > In > > > this case alternative path is on diametrically opposite end of the > network > > > and convergence of remote routers is crucial. > > > > > > So yeah, FN will help remote routers to converge faster. But how much > > > this will improve end-to-end traffic restoration in real networks? I > suspect > > > not much. Some degree of meshiness in network topology is the norm. > > > > > > FN is an interesting proposal but it is very far from being > convincing. > > > Pitching FN against FRR is a mistake. > > > > > > -- > > > Anton > --20cf307cfe7848490804a0b15b14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Curtis,
thank you for the explanation on IPFRR. I know that things ar= e sometimes are not what we call them=A0 but I believe that if MPLS FRR doe= sn't work for some reason and LSP rerouted to restore service it's = not FRR. Would IPFRR still be considered FRR if restoration of connectivity= relies on flooding=A0 and route convergence, not on use of pre-calculated = RIB?

Regards,
Greg

On Mon, Apr 11, 2011= at 8:16 PM, Curtis Villamizar <curtis@occnc.com> wrote:

In message <BANLkTinDb-P=3DdbHuV6q1jdExZ3hyuwdLqA@mail.gmail.com>
Greg Mirsky writes:
>
> Dear Anton,
>
> I believe that MPLS-TE FRR does not address tasks 2 through 5 in the > same sense as it is required in IPFRR. Certainly, protecting LSP has > to be calculated by SPF, signaled and RIB/FIB/HW properly updated. But=
> these actions all done prior to when an MPLS-TE deemed protected. Upon=
> Fault detection the only action required is on the PLR.
>
> Regards,
> Greg

Greg,

IPFRR does not need tasks 2 through 5 either. =A0OTOH, IPFRR coverage is often less than full coverage.

In both MPLS FRR and IPFRR, if protection works it is handled entirely
by the PLR. =A0In IPFRR, some PLRs have no fast protection and have to
rely on flooding. =A0In IPFRR and MPLS FRR sometimes unexpected multiple failures occur since a previously unknown shared resource is
discovered the hard way or an extroidinary event occurs (ie: two
fibers on same fault line, etc). =A0In this case even protection from
the MPLS FRR PLR doesn't work.

In MPLS if a reroute is required, the CSPF load being N^2 log N (order
N CSPF computation have to be run), the LSA flooding has no
significant impact at all. =A0In IPFRR where only one SPF has to be run, flooding is still not the primary contributor to convergence time. =A0It may be a combination of 4 and 5 below.

Curtis


> On Mon, Apr 11, 2011 at 1:54 PM, Anton Smirnov <asmirnov@cisco.com> wrote:
>
> > =A0 Hi all,
> > =A0 even though I put OSPF-FN draft in the subject it is the fram= ework
> > approach FN-FRWK which draws more questions. At the very first li= ne it
> > reads:
> >
> > =A0This document describes an architectural work that competes wi= th the
> >> IP Fast Re-Route (IPFRR) solution
> >>
> >
> > Lets compare speed of traffic restoration between the two. So, tr= aditional
> > OSPF convergence time consists of the sum of:
> >
> > 1. Failure detection
> > 2. LSA origination
> > 3. Per-hop flooding
> > 4. SPF (delay and calculation itself)
> > 5. RIB/FIB/hardware update
> >
> > 3, 4 and 5 all can be significant depending on network size, numb= er of
> > routes etc.
> >
> > FRR (both MPLS TE FRR and IPFRR) address 2-5. With good implement= ation FRR
> > should be by order of magnitude as fast as 1.
> >
> > FN addresses only 3. It doesn't address 4 and 5. As I wrote a= bove in many
> > networks they are at least as significant as 3.
> >
> > So, by the speed of convergence FN doesn't look to come anywh= ere close to
> > FRR.
> >
> >
> > =A0 Now, lets look at FN from another perspective. Router announc= ing failure
> > doesn't benefit from FN. Its immediate neighbors do not benef= it from FN
> > either - 1 hop traditional flooding should be as fast as 1 hop FN= flooding.
> > It is only distant routers who benefit from the FN - and the fart= her is
> > router from the failure the bigger is gain.
> > =A0 On the other hand, if there exists path alternative to the fa= iled one
> > then _typically_ it is not too far (in terms of hops) from the fa= iling one.
> > I.e. from point of view of router which is 15 hops away from the = point of
> > failure it is less likely that routes will change. BTW, ordered F= IB approach
> > builds on concept that 'old' routes on remote routers do = not cause traffic
> > blackholing or loops.
> >
> > =A0 The big problem with FN approach is that routers remote from = the point of
> > failure benefit most - but at the same time their convergence is = the least
> > important for end-to-end traffic restoration.
> > =A0 The worst case network for FN is fully meshed area. Since eac= h router is
> > 1 hop away from every other one FN will give no benefits.
> > =A0 The best case network for FN is an area consisting of one big= ring. In
> > this case alternative path is on diametrically opposite end of th= e network
> > and convergence of remote routers is crucial.
> >
> > =A0 So yeah, FN will help remote routers to converge faster. But = how much
> > this will improve end-to-end traffic restoration in real networks= ? I suspect
> > not much. Some degree of meshiness in network topology is the nor= m.
> >
> > =A0 FN is an interesting proposal but it is very far from being c= onvincing.
> > Pitching FN against FRR is a mistake.
> >
> > --
> > Anton

--20cf307cfe7848490804a0b15b14-- From manav.bhatia@alcatel-lucent.com Mon Apr 11 22:05:22 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45A8AE0716 for ; Mon, 11 Apr 2011 22:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[AWL=1.901, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUU1ZlYi4tkI for ; Mon, 11 Apr 2011 22:05:21 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id AC34DE0711 for ; Mon, 11 Apr 2011 22:05:21 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3C55GHM001034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 00:05:18 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3C55EdY012319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Apr 2011 10:35:14 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 12 Apr 2011 10:35:14 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes , "curtis@occnc.com" , Abhay Roy Date: Tue, 12 Apr 2011 10:34:15 +0530 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv4wnjm/tplLuZkRcWXYCGjweZOCAACw1zg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD037B1F@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <741PDLDGY7792S02.1302579230@web02.cms.usa.net> In-Reply-To: <741PDLDGY7792S02.1302579230@web02.cms.usa.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 05:05:22 -0000 Hi Michael, > > right direction and would not have to be revisited quite as soon if > > something more robust were proposed. > >=20 > > Bottom line. Falls short of what I'd like to see but no objection. > >=20 > > Curtis >=20 > I agree with Curis. I'd really like to see the first version=20 > of this spec at > least have the extended sequence number as is being discussed for v2. I disagree that AT should have a 64 bit sequence space in the base specific= ation primarily because we are not yet sure if the KARP boot count approach= is what the WG will finally converge on (in which case we would need an ex= tended sequence space). Also note that the AT provides an "Auth Type" field= which can be assigned a new value (similar to how it will be done for OSPF= v2) once we decide to move to a different scheme. The same standard that ex= tends the OSPFv2 sequence space can also do it for OSPFv3 AT block - really= hardly an overhead. Also note that you could consider this proposal as just bringing OSPFv3 at = par with OSPFv2. Once this is done, any proposal that extends OSPFv2 will n= atively work for OSPFv3 as well. Cheers, Manav= From michael_barnes@usa.net Mon Apr 11 22:27:33 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33D0CE0719 for ; Mon, 11 Apr 2011 22:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKneloHin3Cw for ; Mon, 11 Apr 2011 22:27:32 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by ietfc.amsl.com (Postfix) with ESMTP id 80CA8E0718 for ; Mon, 11 Apr 2011 22:27:32 -0700 (PDT) Received: from cmsout02.mbox.net (co02-lo [127.0.0.1]) by cmsout02.mbox.net (Postfix) with ESMTP id 95969134194; Tue, 12 Apr 2011 05:27:31 +0000 (GMT) X-USANET-Received: from cmsout02.mbox.net [127.0.0.1] by cmsout02.mbox.net via mtad (C8.MAIN.3.72B) with ESMTP id 220PDLFbC3664M02; Tue, 12 Apr 2011 05:27:28 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from cmsapps04.cms.usa.net [165.212.11.133] by cmsout02.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID222PDLFbC8280X02; Tue, 12 Apr 2011 05:27:28 -0000 X-USANET-Source: 165.212.11.133 IN michael_barnes@usa.net cmsapps04.cms.usa.net X-USANET-MsgId: XID222PDLFbC8280X02 Received: from web04.cms.usa.net [165.212.8.204] by cmsapps04.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.72B) with ESMTP id 125PDLFbC8768M40; Tue, 12 Apr 2011 05:27:27 -0000 X-USANET-Auth: 165.212.8.204 AUTO michael_barnes@usa.net web04.cms.usa.net Received: from 198.144.206.23 [198.144.206.23] by web04.cms.usa.net (USANET web-mailer C8.MAIN.3.73O); Tue, 12 Apr 2011 05:27:27 -0000 Date: Mon, 11 Apr 2011 22:27:27 -0700 From: "Michael Barnes" To: "Bhatia, Manav (Manav)" , Michael Barnes , "curtis@occnc.com" , Abhay Roy X-Mailer: USANET web-mailer (C8.MAIN.3.73O) Mime-Version: 1.0 Message-ID: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID125PDLFbC8768X40 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 05:27:33 -0000 Hello Manav, ------ Original Message ------ Received: Mon, 11 Apr 2011 10:05:36 PM PDT From: "Bhatia, Manav (Manav)" To: Michael Barnes , "curtis@occnc.com" , Abhay Roy Cc: "ospf@ietf.org" Subject: RE: [OSPF] WG Last Call for Supporting Authentication Trailer fo= r OSPFv3 - draft-ietf-ospf-auth-trai > Hi Michael, > = > > > right direction and would not have to be revisited quite as soon if= > > > something more robust were proposed. > > > = > > > Bottom line. Falls short of what I'd like to see but no objection.= > > > = > > > Curtis > > = > > I agree with Curis. I'd really like to see the first version = > > of this spec at > > least have the extended sequence number as is being discussed for v2.= > = > I disagree that AT should have a 64 bit sequence space in the base specification primarily because we are not yet sure if the KARP boot coun= t approach is what the WG will finally converge on (in which case we would = need an extended sequence space). Also note that the AT provides an "Auth Type= " field which can be assigned a new value (similar to how it will be done f= or OSPFv2) once we decide to move to a different scheme. The same standard t= hat extends the OSPFv2 sequence space can also do it for OSPFv3 AT block - re= ally hardly an overhead. > = > Also note that you could consider this proposal as just bringing OSPFv3= at par with OSPFv2. Once this is done, any proposal that extends OSPFv2 will= natively work for OSPFv3 as well. So you are saying that this flaw is okay with you? I'd rather hold off on= pushing this forward until this flaw is fixed. And I think waiting to see= what happens in KARP might be a good idea. Regards, Michael From manav.bhatia@alcatel-lucent.com Mon Apr 11 22:34:13 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E231DE0707 for ; Mon, 11 Apr 2011 22:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.888 X-Spam-Level: X-Spam-Status: No, score=-4.888 tagged_above=-999 required=5 tests=[AWL=1.711, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGLvNEhN3AFA for ; Mon, 11 Apr 2011 22:34:13 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id 048E0E067E for ; Mon, 11 Apr 2011 22:34:12 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3C5Y6Fw009763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 00:34:10 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3C5Y5rG015559 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Apr 2011 11:04:05 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 12 Apr 2011 11:04:05 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes , "curtis@occnc.com" , Abhay Roy Date: Tue, 12 Apr 2011 11:04:04 +0530 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv40m2oFVDu5CZYTl6+94+dq0tsfQAAEJcw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD037B4A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> In-Reply-To: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 05:34:14 -0000 Hi Michael, Different boxes would require different kind of security properties. There = are many boxes/deployments that would not care about the inter-session repl= ay attack or may not have the capability to store additional information in= non-volatile memory or may not want the additional complexity that the non= ce and the session ID brings in. Those devices may just want to use the AT = block as is currently defined. I don't see any reason why we should preclude the possibility of such devic= es existing. I would have agreed to delay this based on KARP result if it would have ent= ailed a significant change in the AT design. Since it doesn't, I see no rea= son why we should do that. Cheers, Manav > -----Original Message----- > From: Michael Barnes [mailto:michael_barnes@usa.net]=20 > Sent: Tuesday, April 12, 2011 10.57 AM > To: Bhatia, Manav (Manav); Michael Barnes; curtis@occnc.com; Abhay Roy > Cc: ospf@ietf.org > Subject: RE: [OSPF] WG Last Call for Supporting=20 > Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >=20 > Hello Manav, >=20 > ------ Original Message ------ > Received: Mon, 11 Apr 2011 10:05:36 PM PDT > From: "Bhatia, Manav (Manav)" > To: Michael Barnes , "curtis@occnc.com" > , Abhay Roy Cc: "ospf@ietf.org" > > Subject: RE: [OSPF] WG Last Call for Supporting=20 > Authentication Trailer for > OSPFv3 - draft-ietf-ospf-auth-trai >=20 > > Hi Michael, > >=20 > > > > right direction and would not have to be revisited=20 > quite as soon if > > > > something more robust were proposed. > > > >=20 > > > > Bottom line. Falls short of what I'd like to see but=20 > no objection. > > > >=20 > > > > Curtis > > >=20 > > > I agree with Curis. I'd really like to see the first version=20 > > > of this spec at > > > least have the extended sequence number as is being=20 > discussed for v2. > >=20 > > I disagree that AT should have a 64 bit sequence space in the base > specification primarily because we are not yet sure if the=20 > KARP boot count > approach is what the WG will finally converge on (in which=20 > case we would need > an extended sequence space). Also note that the AT provides=20 > an "Auth Type" > field which can be assigned a new value (similar to how it=20 > will be done for > OSPFv2) once we decide to move to a different scheme. The=20 > same standard that > extends the OSPFv2 sequence space can also do it for OSPFv3=20 > AT block - really > hardly an overhead. > >=20 > > Also note that you could consider this proposal as just=20 > bringing OSPFv3 at > par with OSPFv2. Once this is done, any proposal that extends=20 > OSPFv2 will > natively work for OSPFv3 as well. >=20 > So you are saying that this flaw is okay with you? I'd rather=20 > hold off on > pushing this forward until this flaw is fixed. And I think=20 > waiting to see what > happens in KARP might be a good idea. >=20 > Regards, > Michael >=20 > = From asmirnov@cisco.com Tue Apr 12 01:13:57 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 888B2E066F for ; Tue, 12 Apr 2011 01:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.401 X-Spam-Level: ** X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKifBOXB+juF for ; Tue, 12 Apr 2011 01:13:56 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfc.amsl.com (Postfix) with ESMTP id 793FDE0613 for ; Tue, 12 Apr 2011 01:13:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3C86PjP026084; Tue, 12 Apr 2011 10:06:25 +0200 (CEST) Received: from [10.55.140.84] (ams-asmirnov-8713.cisco.com [10.55.140.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3C86OtD000679; Tue, 12 Apr 2011 10:06:24 +0200 (CEST) Message-ID: <4DA40800.1080908@cisco.com> Date: Tue, 12 Apr 2011 10:06:24 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Thunderbird/3.1.8 MIME-Version: 1.0 To: Greg Mirsky References: <201104120316.p3C3GSbv022950@harbor.orleans.occnc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:13:57 -0000 Hi Greg, > Would > IPFRR still be considered FRR if restoration of connectivity relies on > flooding I don't understand the question. Failed IPFRR is still FRR. But failed one. We all know that each technology has its limitations. Not full coverage is known limitation of IPFRR. And it is also understood that when IPFRR fails routers have to resort to traditional convergence. But this doesn't change the fact that flooding is not part of IPFRR. Flooding is part of traditional convergence. Flooding and traditional convergence are required even if IPFRR succeeds because router can't run forever on repair routes. So flooding is always part of the bigger picture, it just is not part of IPFRR technology itself. Anton On 04/12/2011 06:45 AM, Greg Mirsky wrote: > Hi Curtis, > thank you for the explanation on IPFRR. I know that things are sometimes > are not what we call them but I believe that if MPLS FRR doesn't work > for some reason and LSP rerouted to restore service it's not FRR. Would > IPFRR still be considered FRR if restoration of connectivity relies on > flooding and route convergence, not on use of pre-calculated RIB? > > Regards, > Greg > > On Mon, Apr 11, 2011 at 8:16 PM, Curtis Villamizar > wrote: > > > In message > > Greg Mirsky writes: > > > > Dear Anton, > > > > I believe that MPLS-TE FRR does not address tasks 2 through 5 in the > > same sense as it is required in IPFRR. Certainly, protecting LSP has > > to be calculated by SPF, signaled and RIB/FIB/HW properly > updated. But > > these actions all done prior to when an MPLS-TE deemed protected. > Upon > > Fault detection the only action required is on the PLR. > > > > Regards, > > Greg > > Greg, > > IPFRR does not need tasks 2 through 5 either. OTOH, IPFRR coverage is > often less than full coverage. > > In both MPLS FRR and IPFRR, if protection works it is handled entirely > by the PLR. In IPFRR, some PLRs have no fast protection and have to > rely on flooding. In IPFRR and MPLS FRR sometimes unexpected multiple > failures occur since a previously unknown shared resource is > discovered the hard way or an extroidinary event occurs (ie: two > fibers on same fault line, etc). In this case even protection from > the MPLS FRR PLR doesn't work. > > In MPLS if a reroute is required, the CSPF load being N^2 log N (order > N CSPF computation have to be run), the LSA flooding has no > significant impact at all. In IPFRR where only one SPF has to be run, > flooding is still not the primary contributor to convergence time. It > may be a combination of 4 and 5 below. > > Curtis > > > > On Mon, Apr 11, 2011 at 1:54 PM, Anton Smirnov > > wrote: > > > > > Hi all, > > > even though I put OSPF-FN draft in the subject it is the > framework > > > approach FN-FRWK which draws more questions. At the very first > line it > > > reads: > > > > > > This document describes an architectural work that competes > with the > > >> IP Fast Re-Route (IPFRR) solution > > >> > > > > > > Lets compare speed of traffic restoration between the two. So, > traditional > > > OSPF convergence time consists of the sum of: > > > > > > 1. Failure detection > > > 2. LSA origination > > > 3. Per-hop flooding > > > 4. SPF (delay and calculation itself) > > > 5. RIB/FIB/hardware update > > > > > > 3, 4 and 5 all can be significant depending on network size, > number of > > > routes etc. > > > > > > FRR (both MPLS TE FRR and IPFRR) address 2-5. With good > implementation FRR > > > should be by order of magnitude as fast as 1. > > > > > > FN addresses only 3. It doesn't address 4 and 5. As I wrote > above in many > > > networks they are at least as significant as 3. > > > > > > So, by the speed of convergence FN doesn't look to come > anywhere close to > > > FRR. > > > > > > > > > Now, lets look at FN from another perspective. Router > announcing failure > > > doesn't benefit from FN. Its immediate neighbors do not benefit > from FN > > > either - 1 hop traditional flooding should be as fast as 1 hop > FN flooding. > > > It is only distant routers who benefit from the FN - and the > farther is > > > router from the failure the bigger is gain. > > > On the other hand, if there exists path alternative to the > failed one > > > then _typically_ it is not too far (in terms of hops) from the > failing one. > > > I.e. from point of view of router which is 15 hops away from > the point of > > > failure it is less likely that routes will change. BTW, ordered > FIB approach > > > builds on concept that 'old' routes on remote routers do not > cause traffic > > > blackholing or loops. > > > > > > The big problem with FN approach is that routers remote from > the point of > > > failure benefit most - but at the same time their convergence > is the least > > > important for end-to-end traffic restoration. > > > The worst case network for FN is fully meshed area. Since > each router is > > > 1 hop away from every other one FN will give no benefits. > > > The best case network for FN is an area consisting of one big > ring. In > > > this case alternative path is on diametrically opposite end of > the network > > > and convergence of remote routers is crucial. > > > > > > So yeah, FN will help remote routers to converge faster. But > how much > > > this will improve end-to-end traffic restoration in real > networks? I suspect > > > not much. Some degree of meshiness in network topology is the norm. > > > > > > FN is an interesting proposal but it is very far from being > convincing. > > > Pitching FN against FRR is a mistake. > > > > > > -- > > > Anton > > From to-yamagata@kddi.com Tue Apr 12 03:31:36 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9D27CE073D for ; Tue, 12 Apr 2011 03:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2eaGXB67oQi for ; Tue, 12 Apr 2011 03:31:36 -0700 (PDT) Received: from UTMC1101.kddi.com (athena.kddi.com [210.141.112.39]) by ietfc.amsl.com (Postfix) with ESMTP id E61C0E073B for ; Tue, 12 Apr 2011 03:31:35 -0700 (PDT) Received: from UTMC1133 (unknown [10.5.16.198]) by UTMC1101.kddi.com (Postfix) with SMTP id ACDFF11DD; Tue, 12 Apr 2011 19:31:32 +0900 (JST) Received: from UTMC1124.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 92A5F1C40; Tue, 12 Apr 2011 19:31:27 +0900 (JST) Received: from UTMC1112.kddi.com (unknown [10.5.16.9]) by UTMC1124.kddi.com (Postfix) with ESMTP id 78A0C1AA0; Tue, 12 Apr 2011 19:31:27 +0900 (JST) Received: from KDDI-0711PC0029 ([10.200.154.196] [10.200.154.196]) by post-ims.kddi.com with ESMTPA; Tue, 12 Apr 2011 19:31:27 +0900 To: acee.lindem@ericsson.com, ospf@ietf.org From: Tomohiro Yamagata References: In-Reply-To: Message-Id: <201104121931.JHD35436.PBUZHBBUBtN@kddi.com> X-Mailer: Winbiff [Version 2.51 PL4] X-Accept-Language: ja,en,zh Date: Tue, 12 Apr 2011 19:31:26 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 1104121931270000326987 Cc: azinin@cisco.com Subject: Re: [OSPF] Poll on OSPF Stub Router Advertisement -draft-retana-ospf-rfc3137bis-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 10:31:36 -0000 Support. Best regards, Tomo On Mon, 11 Apr 2011 12:21:56 -0400 Acee Lindem wrote : >There was general agreement that this should be a WG document at the meeting in Prague. Please indicate your position on making this draft a WG document with intended status Informational. >Thanks, >Acee >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf > From jeff.tantsura@ericsson.com Tue Apr 12 08:05:53 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E26B2E07D7 for ; Tue, 12 Apr 2011 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4o9DeHvNFBG for ; Tue, 12 Apr 2011 08:05:53 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 61002E0705 for ; Tue, 12 Apr 2011 08:05:53 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3CF5npn032199; Tue, 12 Apr 2011 10:05:52 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 12 Apr 2011 11:05:51 -0400 From: Jeff Tantsura To: Acee Lindem , OSPF WG List Date: Tue, 12 Apr 2011 11:04:12 -0400 Thread-Topic: [OSPF] Poll on OSPF Stub Router Advertisement - draft-retana-ospf-rfc3137bis-00 Thread-Index: Acv4ZJTEnLmFFK07RdaIyvW77Bog8wAvklMw Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CAB39637B@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alex Zinin Subject: Re: [OSPF] Poll on OSPF Stub Router Advertisement - draft-retana-ospf-rfc3137bis-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:05:54 -0000 Yes/support Regards, Jeff =20 -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Monday, April 11, 2011 09:22 To: OSPF WG List Cc: Alex Zinin Subject: [OSPF] Poll on OSPF Stub Router Advertisement - draft-retana-ospf-= rfc3137bis-00 There was general agreement that this should be a WG document at the meetin= g in Prague. Please indicate your position on making this draft a WG docume= nt with intended status Informational.=20 Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From glen.kent@gmail.com Tue Apr 12 08:12:36 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0896E07B2 for ; Tue, 12 Apr 2011 08:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtjF0SGSjyc1 for ; Tue, 12 Apr 2011 08:12:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 8D265E079A for ; Tue, 12 Apr 2011 08:12:34 -0700 (PDT) Received: by vws12 with SMTP id 12so6393552vws.31 for ; Tue, 12 Apr 2011 08:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qN1wu1kRTPD7isw2DH2Y2G3gZoG86NXsHS6iM/oCGm8=; b=ZDQKYX8oNLuPnXgqA1FriFwGxqqg3YhsUslILi632BS/u9UcCgor4O/S3C1Z2SLmv+ /x5Pyuhn03zalFIyDLuqa7biVtuFbXOCcqUbWiwySa2rlQ7R6f32LzMK3LGSWmJMykge uas3q7H0ppQ8raQQyiPrM6S3SPiVs9Ol25d2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LANnrRHQ2G+3voZBi0m1NG2WKOzse3LUb266GBIK3QZ6nZ/+B0ytxyTdAx/PGRP1Ep JVwcV9Y36La1BnezWUIbDbLdU58Ytf5v/rijHgm9uvSDuy48egIVv27mdctabBawEfiq 0hWRYaE0qMlZwKJGssWJuGaw49zhnuDXZ8cPU= MIME-Version: 1.0 Received: by 10.52.18.72 with SMTP id u8mr1288120vdd.290.1302621152679; Tue, 12 Apr 2011 08:12:32 -0700 (PDT) Received: by 10.52.160.6 with HTTP; Tue, 12 Apr 2011 08:12:32 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD037B4A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037B4A@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 12 Apr 2011 20:42:32 +0530 Message-ID: From: Glen Kent To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:12:36 -0000 I think i'll agree with Manav - Lets leave the current draft as is. Its extensible and can support the future extensions that are being currently defined for OSPFv2. Glen On Tue, Apr 12, 2011 at 11:04 AM, Bhatia, Manav (Manav) wrote: > Hi Michael, > > Different boxes would require different kind of security properties. Ther= e are many boxes/deployments that would not care about the inter-session re= play attack or may not have the capability to store additional information = in non-volatile memory or may not want the additional complexity that the n= once and the session ID brings in. Those devices may just want to use the A= T block as is currently defined. > > I don't see any reason why we should preclude the possibility of such dev= ices existing. > > I would have agreed to delay this based on KARP result if it would have e= ntailed a significant change in the AT design. Since it doesn't, I see no r= eason why we should do that. > > Cheers, Manav > >> -----Original Message----- >> From: Michael Barnes [mailto:michael_barnes@usa.net] >> Sent: Tuesday, April 12, 2011 10.57 AM >> To: Bhatia, Manav (Manav); Michael Barnes; curtis@occnc.com; Abhay Roy >> Cc: ospf@ietf.org >> Subject: RE: [OSPF] WG Last Call for Supporting >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >> >> Hello Manav, >> >> ------ Original Message ------ >> Received: Mon, 11 Apr 2011 10:05:36 PM PDT >> From: "Bhatia, Manav (Manav)" >> To: Michael Barnes , =A0 =A0 =A0 =A0"curtis@occn= c.com" >> , Abhay Roy Cc: "ospf@ietf.org" >> >> Subject: RE: [OSPF] WG Last Call for Supporting >> Authentication Trailer for >> OSPFv3 - draft-ietf-ospf-auth-trai >> >> > Hi Michael, >> > >> > > > right direction and would not have to be revisited >> quite as soon if >> > > > something more robust were proposed. >> > > > >> > > > Bottom line. =A0Falls short of what I'd like to see but >> no objection. >> > > > >> > > > Curtis >> > > >> > > I agree with Curis. I'd really like to see the first version >> > > of this spec at >> > > least have the extended sequence number as is being >> discussed for v2. >> > >> > I disagree that AT should have a 64 bit sequence space in the base >> specification primarily because we are not yet sure if the >> KARP boot count >> approach is what the WG will finally converge on (in which >> case we would need >> an extended sequence space). Also note that the AT provides >> an "Auth Type" >> field which can be assigned a new value (similar to how it >> will be done for >> OSPFv2) once we decide to move to a different scheme. The >> same standard that >> extends the OSPFv2 sequence space can also do it for OSPFv3 >> AT block - really >> hardly an overhead. >> > >> > Also note that you could consider this proposal as just >> bringing OSPFv3 at >> par with OSPFv2. Once this is done, any proposal that extends >> OSPFv2 will >> natively work for OSPFv3 as well. >> >> So you are saying that this flaw is okay with you? I'd rather >> hold off on >> pushing this forward until this flaw is fixed. And I think >> waiting to see what >> happens in KARP might be a good idea. >> >> Regards, >> Michael >> >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From vishwas.ietf@gmail.com Tue Apr 12 10:02:24 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CFCC6E0816 for ; Tue, 12 Apr 2011 10:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnUBVrYwbgqB for ; Tue, 12 Apr 2011 10:02:21 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 1847AE0800 for ; Tue, 12 Apr 2011 10:02:20 -0700 (PDT) Received: by pzk30 with SMTP id 30so3058582pzk.31 for ; Tue, 12 Apr 2011 10:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EzWKn3niSJHVcrR/BI6dKbzoSdCSan+SnW1ON/ICVdE=; b=fLVoeiZVagxxRCqiCul1vn3XwMfDipGWmYBgXe/HIkEim6pAmiPFjyis6+QIlaPPaf M/fJ9JeeHasWJ1M3R/jooLpiSRc56zXYVuadIpE1e0WWX58veYPCDoj0sn+KVvZcUkTE 9o/1bxu4+UwaVCa4q/gt6ea/KYd6XRHTg8r0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ilIqdQYNbk0v3lu7pYZ4cSb56/Mjj6Fw8fNEmaz+NRjFjCwmOsvM/5379oQEXukgNK N+3KhGk0YfdRIf65ursAfW6P4F1y6LYVliZuXNn0qsmdYE5UnAXoffS/Hp9WDG4GHcP6 Z87ANeGIwSkrCo3iDDjg4onXEoqt5hf9BC2Uk= MIME-Version: 1.0 Received: by 10.143.178.10 with SMTP id f10mr6655903wfp.108.1302627733291; Tue, 12 Apr 2011 10:02:13 -0700 (PDT) Received: by 10.68.41.163 with HTTP; Tue, 12 Apr 2011 10:02:13 -0700 (PDT) In-Reply-To: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> Date: Tue, 12 Apr 2011 10:02:13 -0700 Message-ID: From: Vishwas Manral To: Michael Barnes Content-Type: multipart/alternative; boundary=000e0cd5ccba514fa604a0bba719 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 17:02:24 -0000 --000e0cd5ccba514fa604a0bba719 Content-Type: text/plain; charset=ISO-8859-1 Hi Manav/ Mike, Though it is ok to have another draft invalidate this one after some time. It would be a challenge to get implementations to change as fast (if at all). In my view if the current solution is deemed incomplete, we can correct the current solution. Thanks, Vishwas On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes wrote: > Hello Manav, > > ------ Original Message ------ > Received: Mon, 11 Apr 2011 10:05:36 PM PDT > From: "Bhatia, Manav (Manav)" > To: Michael Barnes , "curtis@occnc.com" > , Abhay Roy Cc: "ospf@ietf.org" > > Subject: RE: [OSPF] WG Last Call for Supporting Authentication Trailer for > OSPFv3 - draft-ietf-ospf-auth-trai > > > Hi Michael, > > > > > > right direction and would not have to be revisited quite as soon if > > > > something more robust were proposed. > > > > > > > > Bottom line. Falls short of what I'd like to see but no objection. > > > > > > > > Curtis > > > > > > I agree with Curis. I'd really like to see the first version > > > of this spec at > > > least have the extended sequence number as is being discussed for v2. > > > > I disagree that AT should have a 64 bit sequence space in the base > specification primarily because we are not yet sure if the KARP boot count > approach is what the WG will finally converge on (in which case we would > need > an extended sequence space). Also note that the AT provides an "Auth Type" > field which can be assigned a new value (similar to how it will be done for > OSPFv2) once we decide to move to a different scheme. The same standard > that > extends the OSPFv2 sequence space can also do it for OSPFv3 AT block - > really > hardly an overhead. > > > > Also note that you could consider this proposal as just bringing OSPFv3 > at > par with OSPFv2. Once this is done, any proposal that extends OSPFv2 will > natively work for OSPFv3 as well. > > So you are saying that this flaw is okay with you? I'd rather hold off on > pushing this forward until this flaw is fixed. And I think waiting to see > what > happens in KARP might be a good idea. > > Regards, > Michael > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --000e0cd5ccba514fa604a0bba719 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Manav/ Mike,
=A0
Though it is ok to have another draft invalidate this one after some t= ime.=A0It would be a challenge to get implementations to change as fast (if= at all).
=A0
In my view=A0if the current solution is deemed incomplete, we can corr= ect the current solution.
=A0
Thanks,
Vishwas
On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes= <michael_ba= rnes@usa.net> wrote:
Hello Manav,

------ Original Message ------
Received: Mon, 11 A= pr 2011 10:05:36 PM PDT
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.= com>
To: Michael Barnes <michael_ba= rnes@usa.net>, =A0 =A0 =A0 =A0"curtis@occnc.com"
<c= urtis@occnc.com>, Abhay Roy <akr= @cisco.com>Cc: "ospf@ietf.org<= /a>"
<ospf@ietf.org>
Subject: RE: = [OSPF] WG Last Call for Supporting Authentication Trailer for
OSPFv3 - d= raft-ietf-ospf-auth-trai

> Hi Michael,
>
> > > = right direction and would not have to be revisited quite as soon if
> > > something more robust were proposed.
> > >
&g= t; > > Bottom line. =A0Falls short of what I'd like to see but no= objection.
> > >
> > > Curtis
> >
>= > I agree with Curis. I'd really like to see the first version
> > of this spec at
> > least have the extended sequence num= ber as is being discussed for v2.
>
> I disagree that AT should= have a 64 bit sequence space in the base
specification primarily becaus= e we are not yet sure if the KARP boot count
approach is what the WG will finally converge on (in which case we would ne= ed
an extended sequence space). Also note that the AT provides an "= Auth Type"
field which can be assigned a new value (similar to how = it will be done for
OSPFv2) once we decide to move to a different scheme. The same standard tha= t
extends the OSPFv2 sequence space can also do it for OSPFv3 AT block -= really
hardly an overhead.
>
> Also note that you could con= sider this proposal as just bringing OSPFv3 at
par with OSPFv2. Once this is done, any proposal that extends OSPFv2 willnatively work for OSPFv3 as well.

So you are saying th= at this flaw is okay with you? I'd rather hold off on
pushing this f= orward until this flaw is fixed. And I think waiting to see what
happens in KARP might be a good idea.

Regards,
Michael

_______________________________________________
OS= PF mailing list
OSPF@ietf.org
http= s://www.ietf.org/mailman/listinfo/ospf

--000e0cd5ccba514fa604a0bba719-- From wenhu.lu@ericsson.com Tue Apr 12 11:25:52 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7CAA9E07E4 for ; Tue, 12 Apr 2011 11:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.46 X-Spam-Level: X-Spam-Status: No, score=-4.46 tagged_above=-999 required=5 tests=[AWL=2.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljlQFvNbZkAA for ; Tue, 12 Apr 2011 11:25:51 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id DADA6E065C for ; Tue, 12 Apr 2011 11:25:51 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3CIPULK001939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Apr 2011 13:25:51 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 12 Apr 2011 14:25:31 -0400 From: Wenhu Lu To: Acee Lindem , OSPF WG List Date: Tue, 12 Apr 2011 14:25:30 -0400 Thread-Topic: [OSPF] Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 Thread-Index: Acv4bG4wkRLNDkFQQ6un9i/747rzBgA0iDNQ Message-ID: <8249B703AE8442429AF89B86E8206AA26EF57BCCAF@EUSAACMS0703.eamcs.ericsson.se> References: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> In-Reply-To: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sam Hartman Subject: Re: [OSPF] Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:25:52 -0000 Yes I support. Regards, -wenhu=20 -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Monday, April 11, 2011 10:18 AM To: OSPF WG List Cc: Sam Hartman Subject: [OSPF] Security Extension for OSPFv2 when using Manual Key Managem= ent - draft-bhatia-karp-ospf-ip-layer-protection-03 There was general agreement that this should be a WG document at the meetin= g in Prague. Please indicate your position on making this draft a WG docume= nt with intended status Proposed Standard.=20 Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From russ@cisco.com Tue Apr 12 11:42:53 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2245CE07D5 for ; Tue, 12 Apr 2011 11:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ+eeNLu1TWT for ; Tue, 12 Apr 2011 11:42:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 0A352E081C for ; Tue, 12 Apr 2011 11:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=3025; q=dns/txt; s=iport; t=1302633769; x=1303843369; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=CknXYb2uADerQRjvDYbRKuc+gUyZNolK7jdLqReXe6E=; b=c9H3uwpMvwg/+Z6zhNF7gbH0mbx9/uVBcapP86FMtB30cLUNYamIXrnC CV0AadxyUucObPjT+GLC6oKB2VKhtDS3ij/m9cAh0TyHG2ktOjLPdJczs 5EeATrRDP6SYZ3f4mGd+Jn+sOsDlVE+Jun2AHUCyigvyM9WnVZZw29CjN g=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.64,198,1301875200"; d="asc'?scan'208";a="679880137" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 12 Apr 2011 18:42:48 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3CIgl8F000680; Tue, 12 Apr 2011 18:42:47 GMT Message-ID: <4DA49D1B.4040008@cisco.com> Date: Tue, 12 Apr 2011 14:42:35 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Abhay Roy References: <4DA329FE.4050108@cisco.com> In-Reply-To: <4DA329FE.4050108@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD868443C1CD590D901328EDF" Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:42:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD868443C1CD590D901328EDF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support. :-) Russ On 4/11/2011 12:19 PM, Abhay Roy wrote: > We are starting the Working Group Last Call of this revision of the > subject draft. >=20 > This drafts is intended to be a Proposed Standard. The OSPF WG last cal= l > will begin today and will end at 5pm PST, April 25th, 2011. >=20 > Abhay/Acee >=20 > -------- Original Message -------- > Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt > Date: Sat, 19 Feb 2011 12:00:02 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: ospf@ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Open Shortest Path First IGP Working G= roup of the IETF. >=20 >=20 > Title : Supporting Authentication Trailer for OSPFv3 > Author(s) : M. Bhatia, et al. > Filename : draft-ietf-ospf-auth-trailer-ospfv3-03.txt > Pages : 20 > Date : 2011-02-19 >=20 > Currently OSPFv3 uses IPsec for authenticating protocol packets. > However, there are some environments, e.g., Mobile Ad-hoc Networks > (MANETs), where IPsec is difficult to configure and maintain, and > this mechanism cannot be used. This draft proposes an alternative > mechanism that can be used so that OSPFv3 does not depend upon IPsec > for authentication. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3= -03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > 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 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --=20 riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone Now, we never can annihilate a penalty. We can only divert it from the head of the man who has incurred it to the heads of others who have not incurred it. A vast amount of "social reform" consists in just this operation. -William Graham Sumner --------------enigD868443C1CD590D901328EDF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2knR8ACgkQER27sUhU9OTbBgCdGDky0QxNt49RUzjM6EoW8uhg bRMAoLdXi83LztX+3HZH6a4/zbvrmHWy =8kA5 -----END PGP SIGNATURE----- --------------enigD868443C1CD590D901328EDF-- From russ@cisco.com Tue Apr 12 11:45:21 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E70C2E0887 for ; Tue, 12 Apr 2011 11:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtMy8F5D7sRg for ; Tue, 12 Apr 2011 11:45:20 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 8CB79E088C for ; Tue, 12 Apr 2011 11:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1170; q=dns/txt; s=iport; t=1302633920; x=1303843520; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=YYcIU8lDNuDPu0xrrdtMXMTf92XGhrvEwxtdeLwQHKM=; b=W6OlvmmYgSokQCd8f+92oT1266RGSKyefNTkjA9zF7u9uBlb/HU7K4ul cCvi/mp1RMUnpLQzC9dDQSvlo0qd0k07Pp7BD50V6w94V6uZsBVoJZInI IAqGmu+K+TwbjZeTqUlk+Gw2OTJoW4g3sk1aFwBFHKS0gkER3LXVDK6w6 o=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGKdpE2tJXG8/2dsb2JhbACmAHemC50EhW4EjWKDbg X-IronPort-AV: E=Sophos;i="4.64,198,1301875200"; d="asc'?scan'208";a="335664062" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2011 18:43:13 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3CIhCmj000953; Tue, 12 Apr 2011 18:43:12 GMT Message-ID: <4DA49D38.8020206@cisco.com> Date: Tue, 12 Apr 2011 14:43:04 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Acee Lindem References: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> In-Reply-To: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig340EE36A2E8780BCFE04818E" Cc: OSPF WG List , Sam Hartman Subject: Re: [OSPF] Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:45:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig340EE36A2E8780BCFE04818E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support. :-) Russ On 4/11/2011 1:18 PM, Acee Lindem wrote: > There was general agreement that this should be a WG document at the me= eting in Prague. Please indicate your position on making this draft a WG = document with intended status Proposed Standard.=20 >=20 > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --------------enig340EE36A2E8780BCFE04818E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2knTgACgkQER27sUhU9OTJwwCeNZzubadI5ZdHR1s8AvhEgDNf pRQAmQH0SEjntnkHFG+d2pXH0jDxkH/K =YGdP -----END PGP SIGNATURE----- --------------enig340EE36A2E8780BCFE04818E-- From ogier@earthlink.net Tue Apr 12 13:06:55 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EFB85E08D5 for ; Tue, 12 Apr 2011 13:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btZpXLKCGZRg for ; Tue, 12 Apr 2011 13:06:55 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfc.amsl.com (Postfix) with ESMTP id E3D50E08A2 for ; Tue, 12 Apr 2011 13:06:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rVap+1WnySey7tsiD/0ICZBYGypvwwM3GOBkzvnpB2nvNOVknjyfZsfuafDDbKup; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.251.245] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Q9jrP-0001cL-JV; Tue, 12 Apr 2011 16:06:54 -0400 Message-ID: <4DA4B1EB.1030105@earthlink.net> Date: Tue, 12 Apr 2011 13:11:23 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jeffrey (Zhaohui) Zhang" References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> <4D9F590A.5050008@earthlink.net> <13205C286662DE4387D9AF3AC30EF456D340CA09EE@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D340CA09EE@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478dd836ef1d960a2d9296bda4293fea1c9e3dc63163ab1e6cc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.251.245 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:06:56 -0000 Jeffrey, I agree with your comments and was not opposing acceptance of the hybrid draft. In fact, I said: >The hybrid-bcast-p2mp draft is nice because it requires only minimal >modifications to OSPF, keeping the DR and BDR and the same >adjacencies. > My main point was to show how OSPF-MDR (RFC 5614) provides a similar solution when applied to single-hop networks, since the application of RFC 5820 to such networks had already been discussed. In particular, RFC 5614 looks a lot like OSPF when applied to single-hop networks (with DR, BDR and associated adjacencies) whereas RFC 5820 looks quite different. Richard Jeffrey (Zhaohui) Zhang wrote: >Richard, > >Thanks for your comments and detailed comparison. > > > >>-----Original Message----- >>From: Richard Ogier [mailto:ogier@earthlink.net] >>Sent: Friday, April 08, 2011 2:51 PM >>To: ospf@ietf.org >>Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >> >>I decided to read the posts regarding this draft (hybrid-bcast-p2mp), >>since it is related to OSPF-MANET, and have a few comments. >> >> > >We actually try to completely disassociated it from OSPF-MANET, and the premise is really about "true broadcast single-hop network with per-neighbor metrics". > > > >>It was mentioned that RFC 5820 (OSPF-MANET with smart peering) solves >>the problem of this draft, assuming that smart peering and >>unsynchronized >>adjacencies are used. (E.g., Sheth's post on 2/10/2011.) >> >> > >Sheth's comment is not really about that RFC 5820 solves the problem. Rather, a comment was made by someone else about RFC 5820's applicability here and Sheth was trying to point out what exactly need to be done if one were to use MANET to get the same result. > > > >>I also want to point out that RFC 5614 (OSPF-MANET-MDR or OSPF-MDR), >>which uses CDS flooding via MDRs (MANET Designated Routers), not only >>solves the problem of this draft, but provides almost the >>same solution >>as this draft when OSPF-MDR (with full-topology LSAs and biconnected >>adjacencies) is applied to single-hop broadcast networks. >> >> > >The final result does look similar. > > > >>The hybrid-bcast-p2mp draft is nice because it requires only minimal >>modifications to OSPF, keeping the DR and BDR and the same >>adjacencies. >> >> > >Right - that's why we have been trying to completely disassociating it from various MANET methods. > >One could look at it and the alternatives the following way: > >- Hybrid method is a smiple and straightforward "step-up" from the well-known/understood/implemented/deployed broadcast interface >- MANET method is a "step-down" from the MANET interface which has relatively fewer implementations/deployments, and which is understood by fewer people, and which does require some MANET-related code. > >Therefore, we believe the hybrid way is worth the WG effort to standardize it. > >We hope you were not really opposing its acceptance as a WG item, but it is not quite clear so if you could clarify that'd be great. > >Thanks. >Jeffrey > > > >>The reason that OSPF-MDR applied to single-hop broadcast networks >>provides almost the same solution as this draft is because it >>generalizes the concept of DRs and BDRs to MANETs, and requires >>only 2 adjacencies for a non-DR/BDR (or non-MDR/BMDR) in a >>single-hop broadcast network. More on this (near) equivalence below. >> >>In contrast, the solution of draft-retana-ospf-manet, which applies >>RFC 5820 with smart peering to single-hop broadcast networks, is quite >>different, resulting in a more random selection of adjacencies, >>which are not common to any single node such as a DR. >>Thus, unlike the other two solutions, draft-retana-ospf-manet is >>conceptually quite different from OSPF broadcast, since it does not >>use the concept of the DR and BDR. >> >>One of the goals in the design of OSPF-MDR was to minimize changes >>to OSPF. Thus, instead of throwing out the DR and BDR, they were >>generalized to multi-hop networks, and were kept essentially the >>same in the special case of a single-hop network, for the purpose >>of flooding and forming adjacencies. More information on OSPF-MDR >>can be found at www.manet-routing.org. >> >>Now more on the (near) equivalence between hybrid-bcast-p2mp and >>OSPF-MDR when applied to a single-hop broadcast network. >>In this case, the MDR selection algorithm is very similar to the >>DR election algorithm of OSPF, and both select a single DR/MDR. >>(There are a few minor differences that are not important to >>this discussion.) Also, if AdjConnectivity = 2, each node forms >>an adjacency with the MDR and BMDR. >> >>The origination of router LSAs is also nearly equivalent. >>The rules in Section 3.6 of hybrid-bcast-p2mp, which specifies >>which Type 1 links a non-DR includes in its router LSA, >>are similar to the corresponding rules in RFC 5614 when >>LSAFullness = 4 (full-topology LSAs). In that case, a router >>includes all bidirectional (2-Way or higher) neighbors that are >>"routable", where a neighbor is routable if SPF has calculated >>a route to the neighbor. Note that SPF will calculate such a route >>to the neighbor as long as both the router itself and the neighbor >>are fully adjacent to the MDR. >> >>This is slightly different from Section 3.6 of >>hybrid-bcast-p2mp, which >>only requires that the router itself be fully adjacent to the DR (thus >>relying on the requirement of SPF that the neighbor must include a >>link back to the router in its LSA). But both solutions achieve the >>same goal, in a similar way, using a single DR/MDR that becomes >>adjacent with all neighbors. >> >>Richard >> >> >> > > > From curtis@occnc.com Tue Apr 12 13:18:21 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E61F8E0870 for ; Tue, 12 Apr 2011 13:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.318 X-Spam-Level: X-Spam-Status: No, score=0.318 tagged_above=-999 required=5 tests=[AWL=-2.083, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9mpfGuONZuE for ; Tue, 12 Apr 2011 13:18:21 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 0B0B2E06BC for ; Tue, 12 Apr 2011 13:18:20 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3CKIDtO099940; Tue, 12 Apr 2011 16:18:13 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104122018.p3CKIDtO099940@harbor.orleans.occnc.com> To: Greg Mirsky From: Curtis Villamizar In-reply-to: Your message of "Mon, 11 Apr 2011 21:45:07 PDT." Date: Tue, 12 Apr 2011 16:18:13 -0400 Sender: curtis@occnc.com Cc: ospf@ietf.org Subject: Re: [OSPF] draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:18:22 -0000 In message Greg Mirsky writes: > > Hi Curtis, > > thank you for the explanation on IPFRR. I know that things are > sometimes are not what we call them but I believe that if MPLS FRR > doesn't work for some reason and LSP rerouted to restore service it's > not FRR. Would IPFRR still be considered FRR if restoration of > connectivity relies on flooding and route convergence, not on use of > pre-calculated RIB? > > Regards, > Greg Greg, Call it what you want. Multiple failures where MPLS protection doesn't work is reality and has to be dealt with. The alternative is transport style multiple hour outages where single fault protection is backed up only by manual intervention (an apparent goal of TP). Curtis > On Mon, Apr 11, 2011 at 8:16 PM, Curtis Villamizar wrote: > > > > > In message > > Greg Mirsky writes: > > > > > > Dear Anton, > > > > > > I believe that MPLS-TE FRR does not address tasks 2 through 5 in the > > > same sense as it is required in IPFRR. Certainly, protecting LSP has > > > to be calculated by SPF, signaled and RIB/FIB/HW properly updated. But > > > these actions all done prior to when an MPLS-TE deemed protected. Upon > > > Fault detection the only action required is on the PLR. > > > > > > Regards, > > > Greg > > > > Greg, > > > > IPFRR does not need tasks 2 through 5 either. OTOH, IPFRR coverage is > > often less than full coverage. > > > > In both MPLS FRR and IPFRR, if protection works it is handled entirely > > by the PLR. In IPFRR, some PLRs have no fast protection and have to > > rely on flooding. In IPFRR and MPLS FRR sometimes unexpected multiple > > failures occur since a previously unknown shared resource is > > discovered the hard way or an extroidinary event occurs (ie: two > > fibers on same fault line, etc). In this case even protection from > > the MPLS FRR PLR doesn't work. > > > > In MPLS if a reroute is required, the CSPF load being N^2 log N (order > > N CSPF computation have to be run), the LSA flooding has no > > significant impact at all. In IPFRR where only one SPF has to be run, > > flooding is still not the primary contributor to convergence time. It > > may be a combination of 4 and 5 below. > > > > Curtis > > > > > > > On Mon, Apr 11, 2011 at 1:54 PM, Anton Smirnov > > wrote: > > > > > > > Hi all, > > > > even though I put OSPF-FN draft in the subject it is the framework > > > > approach FN-FRWK which draws more questions. At the very first line it > > > > reads: > > > > > > > > This document describes an architectural work that competes with the > > > >> IP Fast Re-Route (IPFRR) solution > > > >> > > > > > > > > Lets compare speed of traffic restoration between the two. So, > > traditional > > > > OSPF convergence time consists of the sum of: > > > > > > > > 1. Failure detection > > > > 2. LSA origination > > > > 3. Per-hop flooding > > > > 4. SPF (delay and calculation itself) > > > > 5. RIB/FIB/hardware update > > > > > > > > 3, 4 and 5 all can be significant depending on network size, number of > > > > routes etc. > > > > > > > > FRR (both MPLS TE FRR and IPFRR) address 2-5. With good implementation > > FRR > > > > should be by order of magnitude as fast as 1. > > > > > > > > FN addresses only 3. It doesn't address 4 and 5. As I wrote above in > > many > > > > networks they are at least as significant as 3. > > > > > > > > So, by the speed of convergence FN doesn't look to come anywhere close > > to > > > > FRR. > > > > > > > > > > > > Now, lets look at FN from another perspective. Router announcing > > failure > > > > doesn't benefit from FN. Its immediate neighbors do not benefit from FN > > > > either - 1 hop traditional flooding should be as fast as 1 hop FN > > flooding. > > > > It is only distant routers who benefit from the FN - and the farther is > > > > router from the failure the bigger is gain. > > > > On the other hand, if there exists path alternative to the failed one > > > > then _typically_ it is not too far (in terms of hops) from the failing > > one. > > > > I.e. from point of view of router which is 15 hops away from the point > > of > > > > failure it is less likely that routes will change. BTW, ordered FIB > > approach > > > > builds on concept that 'old' routes on remote routers do not cause > > traffic > > > > blackholing or loops. > > > > > > > > The big problem with FN approach is that routers remote from the > > point of > > > > failure benefit most - but at the same time their convergence is the > > least > > > > important for end-to-end traffic restoration. > > > > The worst case network for FN is fully meshed area. Since each router > > is > > > > 1 hop away from every other one FN will give no benefits. > > > > The best case network for FN is an area consisting of one big ring. > > In > > > > this case alternative path is on diametrically opposite end of the > > network > > > > and convergence of remote routers is crucial. > > > > > > > > So yeah, FN will help remote routers to converge faster. But how much > > > > this will improve end-to-end traffic restoration in real networks? I > > suspect > > > > not much. Some degree of meshiness in network topology is the norm. > > > > > > > > FN is an interesting proposal but it is very far from being > > convincing. > > > > Pitching FN against FRR is a mistake. > > > > > > > > -- > > > > Anton From manav.bhatia@alcatel-lucent.com Tue Apr 12 13:41:44 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3F955E0957 for ; Tue, 12 Apr 2011 13:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[AWL=1.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYk4N6-P87OP for ; Tue, 12 Apr 2011 13:41:43 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id 2AEE8E0924 for ; Tue, 12 Apr 2011 13:41:43 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3CKfYCa020603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 15:41:36 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3CKfV43030598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Apr 2011 02:11:31 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 13 Apr 2011 02:11:31 +0530 From: "Bhatia, Manav (Manav)" To: Vishwas Manral , Michael Barnes Date: Wed, 13 Apr 2011 02:11:28 +0530 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv5M2YzBOOzWLq7TICvbcMDYI+EIQAHg/yw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CFD037D65INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:41:44 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFD037D65INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vishwas, As i have explained earlier, AT is a complete solution and none of the curr= ent proposals in KARP (nonce ID, boot count, etc) will be invalidating it. = AT provides the basic infrastructure over which other these will get built.= The two are thus not comparable. Cheers, Manav ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, April 12, 2011 10.32 PM To: Michael Barnes Cc: Bhatia, Manav (Manav); curtis@occnc.com; Abhay Roy; ospf@ietf.org Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for = OSPFv3 - draft-ietf-ospf-auth-trai Hi Manav/ Mike, Though it is ok to have another draft invalidate this one after some time. = It would be a challenge to get implementations to change as fast (if at all= ). In my view if the current solution is deemed incomplete, we can correct the= current solution. Thanks, Vishwas On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes > wrote: Hello Manav, ------ Original Message ------ Received: Mon, 11 Apr 2011 10:05:36 PM PDT From: "Bhatia, Manav (Manav)" > To: Michael Barnes >,= "curtis@occnc.com" >, Abhay Roy >Cc: "ospf@ietf.org" > Subject: RE: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > Hi Michael, > > > > right direction and would not have to be revisited quite as soon if > > > something more robust were proposed. > > > > > > Bottom line. Falls short of what I'd like to see but no objection. > > > > > > Curtis > > > > I agree with Curis. I'd really like to see the first version > > of this spec at > > least have the extended sequence number as is being discussed for v2. > > I disagree that AT should have a 64 bit sequence space in the base specification primarily because we are not yet sure if the KARP boot count approach is what the WG will finally converge on (in which case we would ne= ed an extended sequence space). Also note that the AT provides an "Auth Type" field which can be assigned a new value (similar to how it will be done for OSPFv2) once we decide to move to a different scheme. The same standard tha= t extends the OSPFv2 sequence space can also do it for OSPFv3 AT block - real= ly hardly an overhead. > > Also note that you could consider this proposal as just bringing OSPFv3 a= t par with OSPFv2. Once this is done, any proposal that extends OSPFv2 will natively work for OSPFv3 as well. So you are saying that this flaw is okay with you? I'd rather hold off on pushing this forward until this flaw is fixed. And I think waiting to see w= hat happens in KARP might be a good idea. Regards, Michael _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_7C362EEF9C7896468B36C9B79200D8350CFD037D65INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Vishwas,
 
As i have explained earlier, AT is a complete= solution=20 and none of the current proposals in KARP (nonce ID, boot count, etc) = will=20 be invalidating it. AT provides the basic infrastructure over which other t= hese=20 will get built. The two are thus not comparable.
 
Cheers, Manav

From: Vishwas Manral=20 [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, April 12, 2011 = 10.32=20 PM
To: Michael Barnes
Cc: Bhatia, Manav (Manav);=20 curtis@occnc.com; Abhay Roy; ospf@ietf.org
Subject: Re: [OSPF] = WG=20 Last Call for Supporting Authentication Trailer for OSPFv3 -=20 draft-ietf-ospf-auth-trai

Hi Manav/ Mike,
 
Though it is ok to have another draft invalidate this one after some= =20 time. It would be a challenge to get implementations to change as fa= st=20 (if at all).
 
In my view if the current solution is deemed incomplete, we can= =20 correct the current solution.
 
Thanks,
Vishwas
On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes= <michael_barnes@usa.net>=20 wrote:
Hello=20 Manav,

------ Original Message ------
Received: Mon, 11= Apr=20 2011 10:05:36 PM PDT
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lu= cent.com>
To:=20 Michael Barnes <michael_barnes@usa.net>, =  =20      "curtis@occnc.com"
<curtis@occnc.com>, Abhay Roy &l= t;akr@cisco.com>Cc: "ospf@ietf.org"
<ospf@ietf.org>
Subject: RE: [OS= PF] WG=20 Last Call for Supporting Authentication Trailer for
OSPFv3 -=20 draft-ietf-ospf-auth-trai

> Hi Michael,
>
> > = >=20 right direction and would not have to be revisited quite as soon if
= >=20 > > something more robust were proposed.
> > >
>= ;=20 > > Bottom line.  Falls short of what I'd like to see but no= =20 objection.
> > >
> > > Curtis
> >
&= gt;=20 > I agree with Curis. I'd really like to see the first version
&g= t;=20 > of this spec at
> > least have the extended sequence numb= er as=20 is being discussed for v2.
>
> I disagree that AT should ha= ve a=20 64 bit sequence space in the base
specification primarily because we= are=20 not yet sure if the KARP boot count
approach is what the WG will fin= ally=20 converge on (in which case we would need
an extended sequence space)= .=20 Also note that the AT provides an "Auth Type"
field which can be ass= igned=20 a new value (similar to how it will be done for
OSPFv2) once we deci= de to=20 move to a different scheme. The same standard that
extends the OSPFv= 2=20 sequence space can also do it for OSPFv3 AT block - really
hardly an= =20 overhead.
>
> Also note that you could consider this propos= al as=20 just bringing OSPFv3 at
par with OSPFv2. Once this is done, any prop= osal=20 that extends OSPFv2 will
natively work for OSPFv3 as=20 well.

So you are saying that this flaw is okay with = you?=20 I'd rather hold off on
pushing this forward until this flaw is fixed= . And=20 I think waiting to see what
happens in KARP might be a good=20 idea.

Regards,
Michael

_______________________________________________
= OSPF=20 mailing list
OSPF@ietf.org
<= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ospf"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ospf

--_000_7C362EEF9C7896468B36C9B79200D8350CFD037D65INBANSXCHMBSA_-- From acee.lindem@ericsson.com Wed Apr 13 08:01:58 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 144B1E078F for ; Wed, 13 Apr 2011 08:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iT6IU-tIywH for ; Wed, 13 Apr 2011 08:01:57 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 2270FE0778 for ; Wed, 13 Apr 2011 08:01:57 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3DF1oB1012812; Wed, 13 Apr 2011 10:01:53 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([147.117.20.157]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 13 Apr 2011 11:01:49 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Date: Wed, 13 Apr 2011 11:01:47 -0400 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv567cx8/QTKvS6Q06GP3nYLT1BOw== Message-ID: <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:01:58 -0000 Hi Manav, OTOH, we could add the strictly increasing 64 bit sequence number to OSPFv3= Auth Trailer draft without too much trouble. Even though it might not end = up to be exactly what is used for the OSPFv2 draft, it seems there is a req= uirement to do something better than is done today. Right now, the OSPFv2 I= P layer security draft still has all the nounce stuff in it. The 64 sequenc= e was primarily a product of the E-mail thread between you, Sam, and myself= . Thanks, Acee On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: Hi Vishwas, As i have explained earlier, AT is a complete solution and none of the curr= ent proposals in KARP (nonce ID, boot count, etc) will be invalidating it. = AT provides the basic infrastructure over which other these will get built.= The two are thus not comparable. Cheers, Manav ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, April 12, 2011 10.32 PM To: Michael Barnes Cc: Bhatia, Manav (Manav); curtis@occnc.com; Abhay= Roy; ospf@ietf.org Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for = OSPFv3 - draft-ietf-ospf-auth-trai Hi Manav/ Mike, Though it is ok to have another draft invalidate this one after some time. = It would be a challenge to get implementations to change as fast (if at all= ). In my view if the current solution is deemed incomplete, we can correct the= current solution. Thanks, Vishwas On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes > wrote: Hello Manav, ------ Original Message ------ Received: Mon, 11 Apr 2011 10:05:36 PM PDT From: "Bhatia, Manav (Manav)" > To: Michael Barnes >,= "curtis@occnc.com" >, Abhay Roy >Cc: "ospf@ietf.org" > Subject: RE: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > Hi Michael, > > > > right direction and would not have to be revisited quite as soon if > > > something more robust were proposed. > > > > > > Bottom line. Falls short of what I'd like to see but no objection. > > > > > > Curtis > > > > I agree with Curis. I'd really like to see the first version > > of this spec at > > least have the extended sequence number as is being discussed for v2. > > I disagree that AT should have a 64 bit sequence space in the base specification primarily because we are not yet sure if the KARP boot count approach is what the WG will finally converge on (in which case we would ne= ed an extended sequence space). Also note that the AT provides an "Auth Type" field which can be assigned a new value (similar to how it will be done for OSPFv2) once we decide to move to a different scheme. The same standard tha= t extends the OSPFv2 sequence space can also do it for OSPFv3 AT block - real= ly hardly an overhead. > > Also note that you could consider this proposal as just bringing OSPFv3 a= t par with OSPFv2. Once this is done, any proposal that extends OSPFv2 will natively work for OSPFv3 as well. So you are saying that this flaw is okay with you? I'd rather hold off on pushing this forward until this flaw is fixed. And I think waiting to see w= hat happens in KARP might be a good idea. Regards, Michael _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Wed Apr 13 08:56:35 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E2845E0803 for ; Wed, 13 Apr 2011 08:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzu+hM6Sf3ZP for ; Wed, 13 Apr 2011 08:56:34 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id C8D91E080A for ; Wed, 13 Apr 2011 08:56:34 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3DFuPmn013126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2011 10:56:28 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3DFuOuR022473 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Apr 2011 21:26:24 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 13 Apr 2011 21:26:24 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem Date: Wed, 13 Apr 2011 21:26:20 +0530 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv567cx8/QTKvS6Q06GP3nYLT1BOwAB1NKQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> In-Reply-To: <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:56:36 -0000 Hi Acee, I am ok with adding the sequence number strictly increasing in the AT draft= . What I was opposing was to include the nonce or the 64 bit auth sequence = space that has been proposed for OSPFv2. Cheers, Manav > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Wednesday, April 13, 2011 8.32 PM > To: Bhatia, Manav (Manav) > Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org > Subject: Re: [OSPF] WG Last Call for Supporting=20 > Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >=20 > Hi Manav, >=20 > OTOH, we could add the strictly increasing 64 bit sequence=20 > number to OSPFv3 Auth Trailer draft without too much trouble.=20 > Even though it might not end up to be exactly what is used=20 > for the OSPFv2 draft, it seems there is a requirement to do=20 > something better than is done today. Right now, the OSPFv2 IP=20 > layer security draft still has all the nounce stuff in it.=20 > The 64 sequence was primarily a product of the E-mail thread=20 > between you, Sam, and myself. >=20 > Thanks, > Acee >=20 > On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: >=20 > Hi Vishwas, >=20 > As i have explained earlier, AT is a complete solution and=20 > none of the current proposals in KARP (nonce ID, boot count,=20 > etc) will be invalidating it. AT provides the basic=20 > infrastructure over which other these will get built. The two=20 > are thus not comparable. >=20 > Cheers, Manav >=20 > ________________________________ > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, April 12, 2011 10.32 PM > To: Michael Barnes > Cc: Bhatia, Manav (Manav);=20 > curtis@occnc.com; Abhay Roy;=20 > ospf@ietf.org > Subject: Re: [OSPF] WG Last Call for Supporting=20 > Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >=20 > Hi Manav/ Mike, >=20 > Though it is ok to have another draft invalidate this one=20 > after some time. It would be a challenge to get=20 > implementations to change as fast (if at all). >=20 > In my view if the current solution is deemed incomplete, we=20 > can correct the current solution. >=20 > Thanks, > Vishwas > On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes=20 > > wrote: > Hello Manav, >=20 > ------ Original Message ------ > Received: Mon, 11 Apr 2011 10:05:36 PM PDT > From: "Bhatia, Manav (Manav)"=20 > ucent.com>> > To: Michael Barnes=20 > >, =20 > "curtis@occnc.com" > >, Abhay Roy=20 > >Cc:=20 > "ospf@ietf.org" > > > Subject: RE: [OSPF] WG Last Call for Supporting=20 > Authentication Trailer for > OSPFv3 - draft-ietf-ospf-auth-trai >=20 > > Hi Michael, > > > > > > right direction and would not have to be revisited=20 > quite as soon if > > > > something more robust were proposed. > > > > > > > > Bottom line. Falls short of what I'd like to see but=20 > no objection. > > > > > > > > Curtis > > > > > > I agree with Curis. I'd really like to see the first version > > > of this spec at > > > least have the extended sequence number as is being=20 > discussed for v2. > > > > I disagree that AT should have a 64 bit sequence space in the base > specification primarily because we are not yet sure if the=20 > KARP boot count > approach is what the WG will finally converge on (in which=20 > case we would need > an extended sequence space). Also note that the AT provides=20 > an "Auth Type" > field which can be assigned a new value (similar to how it=20 > will be done for > OSPFv2) once we decide to move to a different scheme. The=20 > same standard that > extends the OSPFv2 sequence space can also do it for OSPFv3=20 > AT block - really > hardly an overhead. > > > > Also note that you could consider this proposal as just=20 > bringing OSPFv3 at > par with OSPFv2. Once this is done, any proposal that extends=20 > OSPFv2 will > natively work for OSPFv3 as well. >=20 > So you are saying that this flaw is okay with you? I'd rather=20 > hold off on > pushing this forward until this flaw is fixed. And I think=20 > waiting to see what > happens in KARP might be a good idea. >=20 > Regards, > Michael >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 > = From acee.lindem@ericsson.com Wed Apr 13 09:06:42 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EEDF8E080E for ; Wed, 13 Apr 2011 09:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.821 X-Spam-Level: X-Spam-Status: No, score=-4.821 tagged_above=-999 required=5 tests=[AWL=1.778, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV7cJX9tWcKP for ; Wed, 13 Apr 2011 09:06:41 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id C97ABE07CE for ; Wed, 13 Apr 2011 09:06:41 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3DG5lIC023450; Wed, 13 Apr 2011 11:06:35 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([147.117.20.157]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 13 Apr 2011 12:06:13 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Date: Wed, 13 Apr 2011 12:06:11 -0400 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv59LYv8GTK2lZWSQepdDCXwtBS8w== Message-ID: <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:06:43 -0000 Hi Manav, On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote: > Hi Acee, >=20 > I am ok with adding the sequence number strictly increasing in the AT dra= ft. What I was opposing was to include the nonce or the 64 bit auth sequenc= e space that has been proposed for OSPFv2. I agree with the nonce but I don't see why we don't use the 64-bit sequence= number. We've changed a number of things from the existing OSPFv2 authenti= cation trailer already and using a 64 bit non-decreasing sequence number is= a relatively small change.=20 Thanks, Acee >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >> Sent: Wednesday, April 13, 2011 8.32 PM >> To: Bhatia, Manav (Manav) >> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org >> Subject: Re: [OSPF] WG Last Call for Supporting=20 >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>=20 >> Hi Manav, >>=20 >> OTOH, we could add the strictly increasing 64 bit sequence=20 >> number to OSPFv3 Auth Trailer draft without too much trouble.=20 >> Even though it might not end up to be exactly what is used=20 >> for the OSPFv2 draft, it seems there is a requirement to do=20 >> something better than is done today. Right now, the OSPFv2 IP=20 >> layer security draft still has all the nounce stuff in it.=20 >> The 64 sequence was primarily a product of the E-mail thread=20 >> between you, Sam, and myself. >>=20 >> Thanks, >> Acee >>=20 >> On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: >>=20 >> Hi Vishwas, >>=20 >> As i have explained earlier, AT is a complete solution and=20 >> none of the current proposals in KARP (nonce ID, boot count,=20 >> etc) will be invalidating it. AT provides the basic=20 >> infrastructure over which other these will get built. The two=20 >> are thus not comparable. >>=20 >> Cheers, Manav >>=20 >> ________________________________ >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Tuesday, April 12, 2011 10.32 PM >> To: Michael Barnes >> Cc: Bhatia, Manav (Manav);=20 >> curtis@occnc.com; Abhay Roy;=20 >> ospf@ietf.org >> Subject: Re: [OSPF] WG Last Call for Supporting=20 >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>=20 >> Hi Manav/ Mike, >>=20 >> Though it is ok to have another draft invalidate this one=20 >> after some time. It would be a challenge to get=20 >> implementations to change as fast (if at all). >>=20 >> In my view if the current solution is deemed incomplete, we=20 >> can correct the current solution. >>=20 >> Thanks, >> Vishwas >> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes=20 >> > wrote: >> Hello Manav, >>=20 >> ------ Original Message ------ >> Received: Mon, 11 Apr 2011 10:05:36 PM PDT >> From: "Bhatia, Manav (Manav)"=20 >> > ucent.com>> >> To: Michael Barnes=20 >> >, =20 >> "curtis@occnc.com" >> >, Abhay Roy=20 >> >Cc:=20 >> "ospf@ietf.org" >> > >> Subject: RE: [OSPF] WG Last Call for Supporting=20 >> Authentication Trailer for >> OSPFv3 - draft-ietf-ospf-auth-trai >>=20 >>> Hi Michael, >>>=20 >>>>> right direction and would not have to be revisited=20 >> quite as soon if >>>>> something more robust were proposed. >>>>>=20 >>>>> Bottom line. Falls short of what I'd like to see but=20 >> no objection. >>>>>=20 >>>>> Curtis >>>>=20 >>>> I agree with Curis. I'd really like to see the first version >>>> of this spec at >>>> least have the extended sequence number as is being=20 >> discussed for v2. >>>=20 >>> I disagree that AT should have a 64 bit sequence space in the base >> specification primarily because we are not yet sure if the=20 >> KARP boot count >> approach is what the WG will finally converge on (in which=20 >> case we would need >> an extended sequence space). Also note that the AT provides=20 >> an "Auth Type" >> field which can be assigned a new value (similar to how it=20 >> will be done for >> OSPFv2) once we decide to move to a different scheme. The=20 >> same standard that >> extends the OSPFv2 sequence space can also do it for OSPFv3=20 >> AT block - really >> hardly an overhead. >>>=20 >>> Also note that you could consider this proposal as just=20 >> bringing OSPFv3 at >> par with OSPFv2. Once this is done, any proposal that extends=20 >> OSPFv2 will >> natively work for OSPFv3 as well. >>=20 >> So you are saying that this flaw is okay with you? I'd rather=20 >> hold off on >> pushing this forward until this flaw is fixed. And I think=20 >> waiting to see what >> happens in KARP might be a good idea. >>=20 >> Regards, >> Michael >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >>=20 From manav.bhatia@alcatel-lucent.com Wed Apr 13 09:12:16 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 39B07E07CF for ; Wed, 13 Apr 2011 09:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.743 X-Spam-Level: X-Spam-Status: No, score=-5.743 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgE1zAWpoPo3 for ; Wed, 13 Apr 2011 09:12:15 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id ACBF7E07CE for ; Wed, 13 Apr 2011 09:12:11 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3DGC6L5021854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2011 11:12:08 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3DGC41x011806 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Apr 2011 21:42:04 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 13 Apr 2011 21:42:04 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem Date: Wed, 13 Apr 2011 21:42:01 +0530 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv59LYv8GTK2lZWSQepdDCXwtBS8wAADCPA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE1F1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> In-Reply-To: <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:12:16 -0000 Hi Acee, The reason I didn't want a 64 bit non-decreasing sequence number in AT is b= ecause we are not yet sure if that's the final approach that we will take. = While it appears that this is probably the path that we will go down with e= ventually, I would really like to wait till this gets finalized.=20 In the OSPFv2 draft, its trivial to define a new Auth type for OSPFv3 which= expands the sequence space to 64 bits, for folks that really want to use a= n expanded sequence space. Cheers, Manav > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Wednesday, April 13, 2011 9.36 PM > To: Bhatia, Manav (Manav) > Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org > Subject: Re: [OSPF] WG Last Call for Supporting=20 > Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >=20 > Hi Manav, >=20 > On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote: >=20 > > Hi Acee, > >=20 > > I am ok with adding the sequence number strictly increasing=20 > in the AT draft. What I was opposing was to include the nonce=20 > or the 64 bit auth sequence space that has been proposed for OSPFv2. >=20 > I agree with the nonce but I don't see why we don't use the=20 > 64-bit sequence number. We've changed a number of things from=20 > the existing OSPFv2 authentication trailer already and using=20 > a 64 bit non-decreasing sequence number is a relatively small change.=20 >=20 > Thanks, > Acee >=20 >=20 > >=20 > > Cheers, Manav > >=20 > >> -----Original Message----- > >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > >> Sent: Wednesday, April 13, 2011 8.32 PM > >> To: Bhatia, Manav (Manav) > >> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org > >> Subject: Re: [OSPF] WG Last Call for Supporting=20 > >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > >>=20 > >> Hi Manav, > >>=20 > >> OTOH, we could add the strictly increasing 64 bit sequence=20 > >> number to OSPFv3 Auth Trailer draft without too much trouble.=20 > >> Even though it might not end up to be exactly what is used=20 > >> for the OSPFv2 draft, it seems there is a requirement to do=20 > >> something better than is done today. Right now, the OSPFv2 IP=20 > >> layer security draft still has all the nounce stuff in it.=20 > >> The 64 sequence was primarily a product of the E-mail thread=20 > >> between you, Sam, and myself. > >>=20 > >> Thanks, > >> Acee > >>=20 > >> On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: > >>=20 > >> Hi Vishwas, > >>=20 > >> As i have explained earlier, AT is a complete solution and=20 > >> none of the current proposals in KARP (nonce ID, boot count,=20 > >> etc) will be invalidating it. AT provides the basic=20 > >> infrastructure over which other these will get built. The two=20 > >> are thus not comparable. > >>=20 > >> Cheers, Manav > >>=20 > >> ________________________________ > >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > >> Sent: Tuesday, April 12, 2011 10.32 PM > >> To: Michael Barnes > >> Cc: Bhatia, Manav (Manav);=20 > >> curtis@occnc.com; Abhay Roy;=20 > >> ospf@ietf.org > >> Subject: Re: [OSPF] WG Last Call for Supporting=20 > >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > >>=20 > >> Hi Manav/ Mike, > >>=20 > >> Though it is ok to have another draft invalidate this one=20 > >> after some time. It would be a challenge to get=20 > >> implementations to change as fast (if at all). > >>=20 > >> In my view if the current solution is deemed incomplete, we=20 > >> can correct the current solution. > >>=20 > >> Thanks, > >> Vishwas > >> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes=20 > >> > wrote: > >> Hello Manav, > >>=20 > >> ------ Original Message ------ > >> Received: Mon, 11 Apr 2011 10:05:36 PM PDT > >> From: "Bhatia, Manav (Manav)"=20 > >> >> ucent.com>> > >> To: Michael Barnes=20 > >> >, =20 > >> "curtis@occnc.com" > >> >, Abhay Roy=20 > >> >Cc:=20 > >> "ospf@ietf.org" > >> > > >> Subject: RE: [OSPF] WG Last Call for Supporting=20 > >> Authentication Trailer for > >> OSPFv3 - draft-ietf-ospf-auth-trai > >>=20 > >>> Hi Michael, > >>>=20 > >>>>> right direction and would not have to be revisited=20 > >> quite as soon if > >>>>> something more robust were proposed. > >>>>>=20 > >>>>> Bottom line. Falls short of what I'd like to see but=20 > >> no objection. > >>>>>=20 > >>>>> Curtis > >>>>=20 > >>>> I agree with Curis. I'd really like to see the first version > >>>> of this spec at > >>>> least have the extended sequence number as is being=20 > >> discussed for v2. > >>>=20 > >>> I disagree that AT should have a 64 bit sequence space in the base > >> specification primarily because we are not yet sure if the=20 > >> KARP boot count > >> approach is what the WG will finally converge on (in which=20 > >> case we would need > >> an extended sequence space). Also note that the AT provides=20 > >> an "Auth Type" > >> field which can be assigned a new value (similar to how it=20 > >> will be done for > >> OSPFv2) once we decide to move to a different scheme. The=20 > >> same standard that > >> extends the OSPFv2 sequence space can also do it for OSPFv3=20 > >> AT block - really > >> hardly an overhead. > >>>=20 > >>> Also note that you could consider this proposal as just=20 > >> bringing OSPFv3 at > >> par with OSPFv2. Once this is done, any proposal that extends=20 > >> OSPFv2 will > >> natively work for OSPFv3 as well. > >>=20 > >> So you are saying that this flaw is okay with you? I'd rather=20 > >> hold off on > >> pushing this forward until this flaw is fixed. And I think=20 > >> waiting to see what > >> happens in KARP might be a good idea. > >>=20 > >> Regards, > >> Michael > >>=20 > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> https://www.ietf.org/mailman/listinfo/ospf > >>=20 > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> https://www.ietf.org/mailman/listinfo/ospf > >>=20 > >>=20 >=20 > = From acee.lindem@ericsson.com Wed Apr 13 09:18:33 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6115EE07C7 for ; Wed, 13 Apr 2011 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlzK3Krxnyke for ; Wed, 13 Apr 2011 09:18:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 42C7CE07C0 for ; Wed, 13 Apr 2011 09:18:32 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3DGIT2L025501; Wed, 13 Apr 2011 11:18:31 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([147.117.20.157]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 13 Apr 2011 12:18:23 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Date: Wed, 13 Apr 2011 12:18:21 -0400 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv59mmD+0TAhlhWT7SfRfUZEaC5uQ== Message-ID: <7C4E79A4-6AC9-4797-822C-5C0963091C7A@ericsson.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1F1@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0DE1F1@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:18:33 -0000 Hi Manav, On Apr 13, 2011, at 12:12 PM, Bhatia, Manav (Manav) wrote: > Hi Acee, >=20 > The reason I didn't want a 64 bit non-decreasing sequence number in AT is= because we are not yet sure if that's the final approach that we will take= . While it appears that this is probably the path that we will go down with= eventually, I would really like to wait till this gets finalized.=20 I believe we all accept that this is not necessarily the final solution. Ho= wever, the 64 bit sequence number is better (as discussed in the E-mail thr= ead between you, Sam, and myself) is much better than what we have with OSP= Fv2 today.=20 Thanks, Acee >=20 > In the OSPFv2 draft, its trivial to define a new Auth type for OSPFv3 whi= ch expands the sequence space to 64 bits, for folks that really want to use= an expanded sequence space. >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >> Sent: Wednesday, April 13, 2011 9.36 PM >> To: Bhatia, Manav (Manav) >> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org >> Subject: Re: [OSPF] WG Last Call for Supporting=20 >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>=20 >> Hi Manav, >>=20 >> On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote: >>=20 >>> Hi Acee, >>>=20 >>> I am ok with adding the sequence number strictly increasing=20 >> in the AT draft. What I was opposing was to include the nonce=20 >> or the 64 bit auth sequence space that has been proposed for OSPFv2. >>=20 >> I agree with the nonce but I don't see why we don't use the=20 >> 64-bit sequence number. We've changed a number of things from=20 >> the existing OSPFv2 authentication trailer already and using=20 >> a 64 bit non-decreasing sequence number is a relatively small change.=20 >>=20 >> Thanks, >> Acee >>=20 >>=20 >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >>>> Sent: Wednesday, April 13, 2011 8.32 PM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org >>>> Subject: Re: [OSPF] WG Last Call for Supporting=20 >>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>>=20 >>>> Hi Manav, >>>>=20 >>>> OTOH, we could add the strictly increasing 64 bit sequence=20 >>>> number to OSPFv3 Auth Trailer draft without too much trouble.=20 >>>> Even though it might not end up to be exactly what is used=20 >>>> for the OSPFv2 draft, it seems there is a requirement to do=20 >>>> something better than is done today. Right now, the OSPFv2 IP=20 >>>> layer security draft still has all the nounce stuff in it.=20 >>>> The 64 sequence was primarily a product of the E-mail thread=20 >>>> between you, Sam, and myself. >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>> On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: >>>>=20 >>>> Hi Vishwas, >>>>=20 >>>> As i have explained earlier, AT is a complete solution and=20 >>>> none of the current proposals in KARP (nonce ID, boot count,=20 >>>> etc) will be invalidating it. AT provides the basic=20 >>>> infrastructure over which other these will get built. The two=20 >>>> are thus not comparable. >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> ________________________________ >>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>> Sent: Tuesday, April 12, 2011 10.32 PM >>>> To: Michael Barnes >>>> Cc: Bhatia, Manav (Manav);=20 >>>> curtis@occnc.com; Abhay Roy;=20 >>>> ospf@ietf.org >>>> Subject: Re: [OSPF] WG Last Call for Supporting=20 >>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>>=20 >>>> Hi Manav/ Mike, >>>>=20 >>>> Though it is ok to have another draft invalidate this one=20 >>>> after some time. It would be a challenge to get=20 >>>> implementations to change as fast (if at all). >>>>=20 >>>> In my view if the current solution is deemed incomplete, we=20 >>>> can correct the current solution. >>>>=20 >>>> Thanks, >>>> Vishwas >>>> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes=20 >>>> > wrote: >>>> Hello Manav, >>>>=20 >>>> ------ Original Message ------ >>>> Received: Mon, 11 Apr 2011 10:05:36 PM PDT >>>> From: "Bhatia, Manav (Manav)"=20 >>>> >>> ucent.com>> >>>> To: Michael Barnes=20 >>>> >, =20 >>>> "curtis@occnc.com" >>>> >, Abhay Roy=20 >>>> >Cc:=20 >>>> "ospf@ietf.org" >>>> > >>>> Subject: RE: [OSPF] WG Last Call for Supporting=20 >>>> Authentication Trailer for >>>> OSPFv3 - draft-ietf-ospf-auth-trai >>>>=20 >>>>> Hi Michael, >>>>>=20 >>>>>>> right direction and would not have to be revisited=20 >>>> quite as soon if >>>>>>> something more robust were proposed. >>>>>>>=20 >>>>>>> Bottom line. Falls short of what I'd like to see but=20 >>>> no objection. >>>>>>>=20 >>>>>>> Curtis >>>>>>=20 >>>>>> I agree with Curis. I'd really like to see the first version >>>>>> of this spec at >>>>>> least have the extended sequence number as is being=20 >>>> discussed for v2. >>>>>=20 >>>>> I disagree that AT should have a 64 bit sequence space in the base >>>> specification primarily because we are not yet sure if the=20 >>>> KARP boot count >>>> approach is what the WG will finally converge on (in which=20 >>>> case we would need >>>> an extended sequence space). Also note that the AT provides=20 >>>> an "Auth Type" >>>> field which can be assigned a new value (similar to how it=20 >>>> will be done for >>>> OSPFv2) once we decide to move to a different scheme. The=20 >>>> same standard that >>>> extends the OSPFv2 sequence space can also do it for OSPFv3=20 >>>> AT block - really >>>> hardly an overhead. >>>>>=20 >>>>> Also note that you could consider this proposal as just=20 >>>> bringing OSPFv3 at >>>> par with OSPFv2. Once this is done, any proposal that extends=20 >>>> OSPFv2 will >>>> natively work for OSPFv3 as well. >>>>=20 >>>> So you are saying that this flaw is okay with you? I'd rather=20 >>>> hold off on >>>> pushing this forward until this flaw is fixed. And I think=20 >>>> waiting to see what >>>> happens in KARP might be a good idea. >>>>=20 >>>> Regards, >>>> Michael >>>>=20 >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>>=20 >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>>=20 >>>>=20 >>=20 >>=20 From pauwells@cisco.com Wed Apr 13 09:50:16 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 55759E07A1 for ; Wed, 13 Apr 2011 09:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgjKKYIFcHlN for ; Wed, 13 Apr 2011 09:50:15 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id BD207E0831 for ; Wed, 13 Apr 2011 09:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pauwells@cisco.com; l=7458; q=dns/txt; s=iport; t=1302713414; x=1303923014; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1t5XYTn9qPv8JmPzL1HtKBoH/olBJDcXFGzl8W4byv0=; b=GBa+K0DP2z0eETwKJkXINuOC2AAOsUsKNbePiqCsjRtAI+ecnjdL67uQ UxbLkLcu5dod6e176kskKT3dYWCd1ZozYb64moenCA8rKZvwf0UcQ9WeI nDfF4y7HnvvqVdRa8WFBgOtMnz90sJe4Emsp2b1VkWJxomz9cGJeYvuIu g=; X-IronPort-AV: E=Sophos;i="4.64,205,1301875200"; d="scan'208";a="429094515" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2011 16:50:14 +0000 Received: from pauwells-linux.cisco.com (sjc-pauwells-8914.cisco.com [10.20.194.117]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3DGoDkj006266; Wed, 13 Apr 2011 16:50:13 GMT Message-ID: <4DA5D445.7060705@cisco.com> Date: Wed, 13 Apr 2011 11:50:13 -0500 From: Paul Wells User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Acee Lindem References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1F1@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C4E79A4-6AC9-4797-822C-5C0963091C7A@ericsson.com> In-Reply-To: <7C4E79A4-6AC9-4797-822C-5C0963091C7A@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:50:16 -0000 Hi Manav, I'd like to second this. I'd like to minimize the number of variations I need to develop and support. The 64-bit sequence number space may not be the ultimate answer, but it's just as easy to implement as a 32-bit space and can more readily be made non-decreasing. Put another way, what is the advantage of a 32-bit sequence number? Regards, Paul On 04/13/2011 11:18 AM, Acee Lindem wrote: > Hi Manav, > > On Apr 13, 2011, at 12:12 PM, Bhatia, Manav (Manav) wrote: > >> Hi Acee, >> >> The reason I didn't want a 64 bit non-decreasing sequence number in AT is because we are not yet sure if that's the final approach that we will take. While it appears that this is probably the path that we will go down with eventually, I would really like to wait till this gets finalized. > > I believe we all accept that this is not necessarily the final solution. However, the 64 bit sequence number is better (as discussed in the E-mail thread between you, Sam, and myself) is much better than what we have with OSPFv2 today. > > Thanks, > Acee > > > >> >> In the OSPFv2 draft, its trivial to define a new Auth type for OSPFv3 which expands the sequence space to 64 bits, for folks that really want to use an expanded sequence space. >> >> Cheers, Manav >> >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> Sent: Wednesday, April 13, 2011 9.36 PM >>> To: Bhatia, Manav (Manav) >>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org >>> Subject: Re: [OSPF] WG Last Call for Supporting >>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>> >>> Hi Manav, >>> >>> On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote: >>> >>>> Hi Acee, >>>> >>>> I am ok with adding the sequence number strictly increasing >>> in the AT draft. What I was opposing was to include the nonce >>> or the 64 bit auth sequence space that has been proposed for OSPFv2. >>> >>> I agree with the nonce but I don't see why we don't use the >>> 64-bit sequence number. We've changed a number of things from >>> the existing OSPFv2 authentication trailer already and using >>> a 64 bit non-decreasing sequence number is a relatively small change. >>> >>> Thanks, >>> Acee >>> >>> >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- >>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>> Sent: Wednesday, April 13, 2011 8.32 PM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org >>>>> Subject: Re: [OSPF] WG Last Call for Supporting >>>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>>> >>>>> Hi Manav, >>>>> >>>>> OTOH, we could add the strictly increasing 64 bit sequence >>>>> number to OSPFv3 Auth Trailer draft without too much trouble. >>>>> Even though it might not end up to be exactly what is used >>>>> for the OSPFv2 draft, it seems there is a requirement to do >>>>> something better than is done today. Right now, the OSPFv2 IP >>>>> layer security draft still has all the nounce stuff in it. >>>>> The 64 sequence was primarily a product of the E-mail thread >>>>> between you, Sam, and myself. >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: >>>>> >>>>> Hi Vishwas, >>>>> >>>>> As i have explained earlier, AT is a complete solution and >>>>> none of the current proposals in KARP (nonce ID, boot count, >>>>> etc) will be invalidating it. AT provides the basic >>>>> infrastructure over which other these will get built. The two >>>>> are thus not comparable. >>>>> >>>>> Cheers, Manav >>>>> >>>>> ________________________________ >>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>> Sent: Tuesday, April 12, 2011 10.32 PM >>>>> To: Michael Barnes >>>>> Cc: Bhatia, Manav (Manav); >>>>> curtis@occnc.com; Abhay Roy; >>>>> ospf@ietf.org >>>>> Subject: Re: [OSPF] WG Last Call for Supporting >>>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>>> >>>>> Hi Manav/ Mike, >>>>> >>>>> Though it is ok to have another draft invalidate this one >>>>> after some time. It would be a challenge to get >>>>> implementations to change as fast (if at all). >>>>> >>>>> In my view if the current solution is deemed incomplete, we >>>>> can correct the current solution. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes >>>>> > wrote: >>>>> Hello Manav, >>>>> >>>>> ------ Original Message ------ >>>>> Received: Mon, 11 Apr 2011 10:05:36 PM PDT >>>>> From: "Bhatia, Manav (Manav)" >>>>> >>>> ucent.com>> >>>>> To: Michael Barnes >>>>> >, >>>>> "curtis@occnc.com" >>>>> >, Abhay Roy >>>>> >Cc: >>>>> "ospf@ietf.org" >>>>> > >>>>> Subject: RE: [OSPF] WG Last Call for Supporting >>>>> Authentication Trailer for >>>>> OSPFv3 - draft-ietf-ospf-auth-trai >>>>> >>>>>> Hi Michael, >>>>>> >>>>>>>> right direction and would not have to be revisited >>>>> quite as soon if >>>>>>>> something more robust were proposed. >>>>>>>> >>>>>>>> Bottom line. Falls short of what I'd like to see but >>>>> no objection. >>>>>>>> >>>>>>>> Curtis >>>>>>> >>>>>>> I agree with Curis. I'd really like to see the first version >>>>>>> of this spec at >>>>>>> least have the extended sequence number as is being >>>>> discussed for v2. >>>>>> >>>>>> I disagree that AT should have a 64 bit sequence space in the base >>>>> specification primarily because we are not yet sure if the >>>>> KARP boot count >>>>> approach is what the WG will finally converge on (in which >>>>> case we would need >>>>> an extended sequence space). Also note that the AT provides >>>>> an "Auth Type" >>>>> field which can be assigned a new value (similar to how it >>>>> will be done for >>>>> OSPFv2) once we decide to move to a different scheme. The >>>>> same standard that >>>>> extends the OSPFv2 sequence space can also do it for OSPFv3 >>>>> AT block - really >>>>> hardly an overhead. >>>>>> >>>>>> Also note that you could consider this proposal as just >>>>> bringing OSPFv3 at >>>>> par with OSPFv2. Once this is done, any proposal that extends >>>>> OSPFv2 will >>>>> natively work for OSPFv3 as well. >>>>> >>>>> So you are saying that this flaw is okay with you? I'd rather >>>>> hold off on >>>>> pushing this forward until this flaw is fixed. And I think >>>>> waiting to see what >>>>> happens in KARP might be a good idea. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> >>>>> >>> >>> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Wed Apr 13 10:29:35 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22322E07D6 for ; Wed, 13 Apr 2011 10:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk5ftE79FTbA for ; Wed, 13 Apr 2011 10:29:33 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id B45E9E0789 for ; Wed, 13 Apr 2011 10:29:33 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3DHTSGX023304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2011 12:29:30 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3DHTRTb025098 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Apr 2011 22:59:27 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 13 Apr 2011 22:59:27 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem Date: Wed, 13 Apr 2011 22:59:24 +0530 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv59mmD+0TAhlhWT7SfRfUZEaC5uQACLTwA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE210@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1F1@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C4E79A4-6AC9-4797-822C-5C0963091C7A@ericsson.com> In-Reply-To: <7C4E79A4-6AC9-4797-822C-5C0963091C7A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:29:35 -0000 Ok, I give up - lets increase the sequence space to 64 bits! I seem to be t= he only one who is opposing adding something that I have myself proposed in= some other draft! :)=20 I am not very comfortable with mandating that upper 32 bits should be retri= eved from the non volatile storage because there may be devices that cannot= do this (i.e. may not be able to store data in nvram) and they will thus b= ecome non compliant to the about-to-be-RFC. How does a device that's wants = to do AT but cant store info in nvram ever become compliant to this standar= d? I see two ways to deal with this: (1) The text on upper 32 bits should be a MAY and not a MUST, so that imple= mentations that don't have nvram or don't want to implement this part of th= e spec still remain compliant to the standard. OR (2) We just increase the sequence space to 64 bits and don't say anything a= bout it. We let a later RFC define how the upper 32 bits may be populated. Cheers, Manav > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Wednesday, April 13, 2011 9.48 PM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org > Subject: Re: [OSPF] WG Last Call for Supporting=20 > Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >=20 > Hi Manav, >=20 > On Apr 13, 2011, at 12:12 PM, Bhatia, Manav (Manav) wrote: >=20 > > Hi Acee, > >=20 > > The reason I didn't want a 64 bit non-decreasing sequence=20 > number in AT is because we are not yet sure if that's the=20 > final approach that we will take. While it appears that this=20 > is probably the path that we will go down with eventually, I=20 > would really like to wait till this gets finalized.=20 >=20 > I believe we all accept that this is not necessarily the=20 > final solution. However, the 64 bit sequence number is better=20 > (as discussed in the E-mail thread between you, Sam, and=20 > myself) is much better than what we have with OSPFv2 today.=20 >=20 > Thanks, > Acee >=20 >=20 >=20 > >=20 > > In the OSPFv2 draft, its trivial to define a new Auth type=20 > for OSPFv3 which expands the sequence space to 64 bits, for=20 > folks that really want to use an expanded sequence space. > >=20 > > Cheers, Manav > >=20 > >> -----Original Message----- > >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > >> Sent: Wednesday, April 13, 2011 9.36 PM > >> To: Bhatia, Manav (Manav) > >> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org > >> Subject: Re: [OSPF] WG Last Call for Supporting=20 > >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > >>=20 > >> Hi Manav, > >>=20 > >> On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote: > >>=20 > >>> Hi Acee, > >>>=20 > >>> I am ok with adding the sequence number strictly increasing=20 > >> in the AT draft. What I was opposing was to include the nonce=20 > >> or the 64 bit auth sequence space that has been proposed=20 > for OSPFv2. > >>=20 > >> I agree with the nonce but I don't see why we don't use the=20 > >> 64-bit sequence number. We've changed a number of things from=20 > >> the existing OSPFv2 authentication trailer already and using=20 > >> a 64 bit non-decreasing sequence number is a relatively=20 > small change.=20 > >>=20 > >> Thanks, > >> Acee > >>=20 > >>=20 > >>>=20 > >>> Cheers, Manav > >>>=20 > >>>> -----Original Message----- > >>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > >>>> Sent: Wednesday, April 13, 2011 8.32 PM > >>>> To: Bhatia, Manav (Manav) > >>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org > >>>> Subject: Re: [OSPF] WG Last Call for Supporting=20 > >>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > >>>>=20 > >>>> Hi Manav, > >>>>=20 > >>>> OTOH, we could add the strictly increasing 64 bit sequence=20 > >>>> number to OSPFv3 Auth Trailer draft without too much trouble.=20 > >>>> Even though it might not end up to be exactly what is used=20 > >>>> for the OSPFv2 draft, it seems there is a requirement to do=20 > >>>> something better than is done today. Right now, the OSPFv2 IP=20 > >>>> layer security draft still has all the nounce stuff in it.=20 > >>>> The 64 sequence was primarily a product of the E-mail thread=20 > >>>> between you, Sam, and myself. > >>>>=20 > >>>> Thanks, > >>>> Acee > >>>>=20 > >>>> On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: > >>>>=20 > >>>> Hi Vishwas, > >>>>=20 > >>>> As i have explained earlier, AT is a complete solution and=20 > >>>> none of the current proposals in KARP (nonce ID, boot count,=20 > >>>> etc) will be invalidating it. AT provides the basic=20 > >>>> infrastructure over which other these will get built. The two=20 > >>>> are thus not comparable. > >>>>=20 > >>>> Cheers, Manav > >>>>=20 > >>>> ________________________________ > >>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > >>>> Sent: Tuesday, April 12, 2011 10.32 PM > >>>> To: Michael Barnes > >>>> Cc: Bhatia, Manav (Manav);=20 > >>>> curtis@occnc.com; Abhay Roy;=20 > >>>> ospf@ietf.org > >>>> Subject: Re: [OSPF] WG Last Call for Supporting=20 > >>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > >>>>=20 > >>>> Hi Manav/ Mike, > >>>>=20 > >>>> Though it is ok to have another draft invalidate this one=20 > >>>> after some time. It would be a challenge to get=20 > >>>> implementations to change as fast (if at all). > >>>>=20 > >>>> In my view if the current solution is deemed incomplete, we=20 > >>>> can correct the current solution. > >>>>=20 > >>>> Thanks, > >>>> Vishwas > >>>> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes=20 > >>>> > wrote: > >>>> Hello Manav, > >>>>=20 > >>>> ------ Original Message ------ > >>>> Received: Mon, 11 Apr 2011 10:05:36 PM PDT > >>>> From: "Bhatia, Manav (Manav)"=20 > >>>> >>>> ucent.com>> > >>>> To: Michael Barnes=20 > >>>> >, =20 > >>>> "curtis@occnc.com" > >>>> >, Abhay Roy=20 > >>>> >Cc:=20 > >>>> "ospf@ietf.org" > >>>> > > >>>> Subject: RE: [OSPF] WG Last Call for Supporting=20 > >>>> Authentication Trailer for > >>>> OSPFv3 - draft-ietf-ospf-auth-trai > >>>>=20 > >>>>> Hi Michael, > >>>>>=20 > >>>>>>> right direction and would not have to be revisited=20 > >>>> quite as soon if > >>>>>>> something more robust were proposed. > >>>>>>>=20 > >>>>>>> Bottom line. Falls short of what I'd like to see but=20 > >>>> no objection. > >>>>>>>=20 > >>>>>>> Curtis > >>>>>>=20 > >>>>>> I agree with Curis. I'd really like to see the first version > >>>>>> of this spec at > >>>>>> least have the extended sequence number as is being=20 > >>>> discussed for v2. > >>>>>=20 > >>>>> I disagree that AT should have a 64 bit sequence space=20 > in the base > >>>> specification primarily because we are not yet sure if the=20 > >>>> KARP boot count > >>>> approach is what the WG will finally converge on (in which=20 > >>>> case we would need > >>>> an extended sequence space). Also note that the AT provides=20 > >>>> an "Auth Type" > >>>> field which can be assigned a new value (similar to how it=20 > >>>> will be done for > >>>> OSPFv2) once we decide to move to a different scheme. The=20 > >>>> same standard that > >>>> extends the OSPFv2 sequence space can also do it for OSPFv3=20 > >>>> AT block - really > >>>> hardly an overhead. > >>>>>=20 > >>>>> Also note that you could consider this proposal as just=20 > >>>> bringing OSPFv3 at > >>>> par with OSPFv2. Once this is done, any proposal that extends=20 > >>>> OSPFv2 will > >>>> natively work for OSPFv3 as well. > >>>>=20 > >>>> So you are saying that this flaw is okay with you? I'd rather=20 > >>>> hold off on > >>>> pushing this forward until this flaw is fixed. And I think=20 > >>>> waiting to see what > >>>> happens in KARP might be a good idea. > >>>>=20 > >>>> Regards, > >>>> Michael > >>>>=20 > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> OSPF@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ospf > >>>>=20 > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> OSPF@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ospf > >>>>=20 > >>>>=20 > >>=20 > >>=20 >=20 > = From acee.lindem@ericsson.com Wed Apr 13 10:40:34 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A1B65E0705 for ; Wed, 13 Apr 2011 10:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.144 X-Spam-Level: X-Spam-Status: No, score=-5.144 tagged_above=-999 required=5 tests=[AWL=1.455, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw65yFqg-tiI for ; Wed, 13 Apr 2011 10:40:33 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 28056E0850 for ; Wed, 13 Apr 2011 10:40:33 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3DHeUCw006324; Wed, 13 Apr 2011 12:40:32 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([147.117.20.157]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 13 Apr 2011 13:40:26 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Date: Wed, 13 Apr 2011 13:40:24 -0400 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv6Ad+DupogWElfQmqT+DQB0oNxPQ== Message-ID: References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1F1@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C4E79A4-6AC9-4797-822C-5C0963091C7A@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE210@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0DE210@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-5-139193336"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:40:34 -0000 --Apple-Mail-5-139193336 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Manav, On Apr 13, 2011, at 1:29 PM, Bhatia, Manav (Manav) wrote: > Ok, I give up - lets increase the sequence space to 64 bits! I seem to = be the only one who is opposing adding something that I have myself = proposed in some other draft! :)=20 >=20 > I am not very comfortable with mandating that upper 32 bits should be = retrieved from the non volatile storage because there may be devices = that cannot do this (i.e. may not be able to store data in nvram) and = they will thus become non compliant to the about-to-be-RFC. How does a = device that's wants to do AT but cant store info in nvram ever become = compliant to this standard? >=20 > I see two ways to deal with this: >=20 > (1) The text on upper 32 bits should be a MAY and not a MUST, so that = implementations that don't have nvram or don't want to implement this = part of the spec still remain compliant to the standard. I'd vote for this option since I'd bet that devices sophisticated enough = to run OSPFv3 deployed in places where you care about replay protection = across cold restarts will have some form of non-volatile memory. Hence, = I'd make it a SHOULD instead of a MUST.=20 Thanks, Acee >=20 > OR >=20 > (2) We just increase the sequence space to 64 bits and don't say = anything about it. We let a later RFC define how the upper 32 bits may = be populated. >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >> Sent: Wednesday, April 13, 2011 9.48 PM >> To: Bhatia, Manav (Manav) >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] WG Last Call for Supporting=20 >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>=20 >> Hi Manav, >>=20 >> On Apr 13, 2011, at 12:12 PM, Bhatia, Manav (Manav) wrote: >>=20 >>> Hi Acee, >>>=20 >>> The reason I didn't want a 64 bit non-decreasing sequence=20 >> number in AT is because we are not yet sure if that's the=20 >> final approach that we will take. While it appears that this=20 >> is probably the path that we will go down with eventually, I=20 >> would really like to wait till this gets finalized.=20 >>=20 >> I believe we all accept that this is not necessarily the=20 >> final solution. However, the 64 bit sequence number is better=20 >> (as discussed in the E-mail thread between you, Sam, and=20 >> myself) is much better than what we have with OSPFv2 today.=20 >>=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >>>=20 >>> In the OSPFv2 draft, its trivial to define a new Auth type=20 >> for OSPFv3 which expands the sequence space to 64 bits, for=20 >> folks that really want to use an expanded sequence space. >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >>>> Sent: Wednesday, April 13, 2011 9.36 PM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org >>>> Subject: Re: [OSPF] WG Last Call for Supporting=20 >>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>>=20 >>>> Hi Manav, >>>>=20 >>>> On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote: >>>>=20 >>>>> Hi Acee, >>>>>=20 >>>>> I am ok with adding the sequence number strictly increasing=20 >>>> in the AT draft. What I was opposing was to include the nonce=20 >>>> or the 64 bit auth sequence space that has been proposed=20 >> for OSPFv2. >>>>=20 >>>> I agree with the nonce but I don't see why we don't use the=20 >>>> 64-bit sequence number. We've changed a number of things from=20 >>>> the existing OSPFv2 authentication trailer already and using=20 >>>> a 64 bit non-decreasing sequence number is a relatively=20 >> small change.=20 >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>>=20 >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >>>>>> Sent: Wednesday, April 13, 2011 8.32 PM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org >>>>>> Subject: Re: [OSPF] WG Last Call for Supporting=20 >>>>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>>>>=20 >>>>>> Hi Manav, >>>>>>=20 >>>>>> OTOH, we could add the strictly increasing 64 bit sequence=20 >>>>>> number to OSPFv3 Auth Trailer draft without too much trouble.=20 >>>>>> Even though it might not end up to be exactly what is used=20 >>>>>> for the OSPFv2 draft, it seems there is a requirement to do=20 >>>>>> something better than is done today. Right now, the OSPFv2 IP=20 >>>>>> layer security draft still has all the nounce stuff in it.=20 >>>>>> The 64 sequence was primarily a product of the E-mail thread=20 >>>>>> between you, Sam, and myself. >>>>>>=20 >>>>>> Thanks, >>>>>> Acee >>>>>>=20 >>>>>> On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: >>>>>>=20 >>>>>> Hi Vishwas, >>>>>>=20 >>>>>> As i have explained earlier, AT is a complete solution and=20 >>>>>> none of the current proposals in KARP (nonce ID, boot count,=20 >>>>>> etc) will be invalidating it. AT provides the basic=20 >>>>>> infrastructure over which other these will get built. The two=20 >>>>>> are thus not comparable. >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> ________________________________ >>>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>>> Sent: Tuesday, April 12, 2011 10.32 PM >>>>>> To: Michael Barnes >>>>>> Cc: Bhatia, Manav (Manav);=20 >>>>>> curtis@occnc.com; Abhay Roy;=20 >>>>>> ospf@ietf.org >>>>>> Subject: Re: [OSPF] WG Last Call for Supporting=20 >>>>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>>>>=20 >>>>>> Hi Manav/ Mike, >>>>>>=20 >>>>>> Though it is ok to have another draft invalidate this one=20 >>>>>> after some time. It would be a challenge to get=20 >>>>>> implementations to change as fast (if at all). >>>>>>=20 >>>>>> In my view if the current solution is deemed incomplete, we=20 >>>>>> can correct the current solution. >>>>>>=20 >>>>>> Thanks, >>>>>> Vishwas >>>>>> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes=20 >>>>>> > wrote: >>>>>> Hello Manav, >>>>>>=20 >>>>>> ------ Original Message ------ >>>>>> Received: Mon, 11 Apr 2011 10:05:36 PM PDT >>>>>> From: "Bhatia, Manav (Manav)"=20 >>>>>> >>>>> ucent.com>> >>>>>> To: Michael Barnes=20 >>>>>> >, =20 >>>>>> "curtis@occnc.com" >>>>>> >, Abhay Roy=20 >>>>>> >Cc:=20 >>>>>> "ospf@ietf.org" >>>>>> > >>>>>> Subject: RE: [OSPF] WG Last Call for Supporting=20 >>>>>> Authentication Trailer for >>>>>> OSPFv3 - draft-ietf-ospf-auth-trai >>>>>>=20 >>>>>>> Hi Michael, >>>>>>>=20 >>>>>>>>> right direction and would not have to be revisited=20 >>>>>> quite as soon if >>>>>>>>> something more robust were proposed. >>>>>>>>>=20 >>>>>>>>> Bottom line. Falls short of what I'd like to see but=20 >>>>>> no objection. >>>>>>>>>=20 >>>>>>>>> Curtis >>>>>>>>=20 >>>>>>>> I agree with Curis. I'd really like to see the first version >>>>>>>> of this spec at >>>>>>>> least have the extended sequence number as is being=20 >>>>>> discussed for v2. >>>>>>>=20 >>>>>>> I disagree that AT should have a 64 bit sequence space=20 >> in the base >>>>>> specification primarily because we are not yet sure if the=20 >>>>>> KARP boot count >>>>>> approach is what the WG will finally converge on (in which=20 >>>>>> case we would need >>>>>> an extended sequence space). Also note that the AT provides=20 >>>>>> an "Auth Type" >>>>>> field which can be assigned a new value (similar to how it=20 >>>>>> will be done for >>>>>> OSPFv2) once we decide to move to a different scheme. The=20 >>>>>> same standard that >>>>>> extends the OSPFv2 sequence space can also do it for OSPFv3=20 >>>>>> AT block - really >>>>>> hardly an overhead. >>>>>>>=20 >>>>>>> Also note that you could consider this proposal as just=20 >>>>>> bringing OSPFv3 at >>>>>> par with OSPFv2. Once this is done, any proposal that extends=20 >>>>>> OSPFv2 will >>>>>> natively work for OSPFv3 as well. >>>>>>=20 >>>>>> So you are saying that this flaw is okay with you? I'd rather=20 >>>>>> hold off on >>>>>> pushing this forward until this flaw is fixed. And I think=20 >>>>>> waiting to see what >>>>>> happens in KARP might be a good idea. >>>>>>=20 >>>>>> Regards, >>>>>> Michael >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 --Apple-Mail-5-139193336 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxMzE3NDAyNFowIwYJKoZI hvcNAQkEMRYEFNzninH3W8HzTceWazf3OiG+7+ldMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgHQYH22KEJ1VpLm1he4IKp5SHFQI17u3EDdSkaDGWG9iZaTNCDA7PZB9QS0sorjb Onr3HM+KKgY3cLX3iWvAIDVrfa3axfqoaWiH6TT5YK7zeTbRLONcmtAafrwcO9GOqTFr1LhSa1ED ByO8XqSr+LV39Ge98r+3zA1woFlQNA+EAAAAAAAA --Apple-Mail-5-139193336-- From vishwas.ietf@gmail.com Wed Apr 13 10:46:01 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1DA81E0842 for ; Wed, 13 Apr 2011 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXPWhvWClyUc for ; Wed, 13 Apr 2011 10:45:59 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id A8EABE0705 for ; Wed, 13 Apr 2011 10:45:58 -0700 (PDT) Received: by pzk30 with SMTP id 30so382461pzk.31 for ; Wed, 13 Apr 2011 10:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ypSBbZqDn/6NdyQNvAbmGFven/7uqnJMd/c/U/5uGAI=; b=b9RIAryfCf/Ha9/u/dGlKz6nKcfILLFVFUoe3+25r8QtuVWN9aNEF8eiK5NjPwILrW vbdnPU77kO/Gg5DJ7lVPaIj6YT1Il93yAt963h/rLCN35LyqC/ELoTaT0rWaWGJAEUMP nHa7iUNYe7KnEPvb6jodgEZ9uuMJRm7X0Lr+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MLHKUnlo632HxQYiMaKwQsnSOJqM2WVy6qnSXdHMb96KcZ83+FmmK0CfA3+uCrKWEL AGq/BzhpvzEsMV9pc0L8Kt4SIdy8d1OtScWdtdcKc5mfSAaxn9vP2Rgi/pVWsdaiwLHl O/lCJDg+KDz6UkRBxXfWlz9QsMfORmxL+WXMQ= MIME-Version: 1.0 Received: by 10.142.1.12 with SMTP id 12mr7386798wfa.393.1302716757071; Wed, 13 Apr 2011 10:45:57 -0700 (PDT) Received: by 10.68.41.163 with HTTP; Wed, 13 Apr 2011 10:45:57 -0700 (PDT) In-Reply-To: References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1F1@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C4E79A4-6AC9-4797-822C-5C0963091C7A@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE210@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 13 Apr 2011 10:45:57 -0700 Message-ID: From: Vishwas Manral To: Acee Lindem Content-Type: multipart/alternative; boundary=00504502b67c8c57f404a0d0615d Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:46:01 -0000 --00504502b67c8c57f404a0d0615d Content-Type: text/plain; charset=ISO-8859-1 Hi Acee/ Manav, Good to see we have nearly converged. I see no reason to mention how to break up the 64 bit sequence number, we should just mention the behavior desired from that sequence number. The actual generation of the should be implementation specific. This is no different from any other spec. Thanks, Vishwas On Wed, Apr 13, 2011 at 10:40 AM, Acee Lindem wrote: > Hi Manav, > > On Apr 13, 2011, at 1:29 PM, Bhatia, Manav (Manav) wrote: > > > Ok, I give up - lets increase the sequence space to 64 bits! I seem to be > the only one who is opposing adding something that I have myself proposed in > some other draft! :) > > > > I am not very comfortable with mandating that upper 32 bits should be > retrieved from the non volatile storage because there may be devices that > cannot do this (i.e. may not be able to store data in nvram) and they will > thus become non compliant to the about-to-be-RFC. How does a device that's > wants to do AT but cant store info in nvram ever become compliant to this > standard? > > > > I see two ways to deal with this: > > > > (1) The text on upper 32 bits should be a MAY and not a MUST, so that > implementations that don't have nvram or don't want to implement this part > of the spec still remain compliant to the standard. > > I'd vote for this option since I'd bet that devices sophisticated enough to > run OSPFv3 deployed in places where you care about replay protection across > cold restarts will have some form of non-volatile memory. Hence, I'd make it > a SHOULD instead of a MUST. > > Thanks, > Acee > > > > > > OR > > > > (2) We just increase the sequence space to 64 bits and don't say anything > about it. We let a later RFC define how the upper 32 bits may be populated. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >> Sent: Wednesday, April 13, 2011 9.48 PM > >> To: Bhatia, Manav (Manav) > >> Cc: ospf@ietf.org > >> Subject: Re: [OSPF] WG Last Call for Supporting > >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > >> > >> Hi Manav, > >> > >> On Apr 13, 2011, at 12:12 PM, Bhatia, Manav (Manav) wrote: > >> > >>> Hi Acee, > >>> > >>> The reason I didn't want a 64 bit non-decreasing sequence > >> number in AT is because we are not yet sure if that's the > >> final approach that we will take. While it appears that this > >> is probably the path that we will go down with eventually, I > >> would really like to wait till this gets finalized. > >> > >> I believe we all accept that this is not necessarily the > >> final solution. However, the 64 bit sequence number is better > >> (as discussed in the E-mail thread between you, Sam, and > >> myself) is much better than what we have with OSPFv2 today. > >> > >> Thanks, > >> Acee > >> > >> > >> > >>> > >>> In the OSPFv2 draft, its trivial to define a new Auth type > >> for OSPFv3 which expands the sequence space to 64 bits, for > >> folks that really want to use an expanded sequence space. > >>> > >>> Cheers, Manav > >>> > >>>> -----Original Message----- > >>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >>>> Sent: Wednesday, April 13, 2011 9.36 PM > >>>> To: Bhatia, Manav (Manav) > >>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org > >>>> Subject: Re: [OSPF] WG Last Call for Supporting > >>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > >>>> > >>>> Hi Manav, > >>>> > >>>> On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote: > >>>> > >>>>> Hi Acee, > >>>>> > >>>>> I am ok with adding the sequence number strictly increasing > >>>> in the AT draft. What I was opposing was to include the nonce > >>>> or the 64 bit auth sequence space that has been proposed > >> for OSPFv2. > >>>> > >>>> I agree with the nonce but I don't see why we don't use the > >>>> 64-bit sequence number. We've changed a number of things from > >>>> the existing OSPFv2 authentication trailer already and using > >>>> a 64 bit non-decreasing sequence number is a relatively > >> small change. > >>>> > >>>> Thanks, > >>>> Acee > >>>> > >>>> > >>>>> > >>>>> Cheers, Manav > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >>>>>> Sent: Wednesday, April 13, 2011 8.32 PM > >>>>>> To: Bhatia, Manav (Manav) > >>>>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org > >>>>>> Subject: Re: [OSPF] WG Last Call for Supporting > >>>>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > >>>>>> > >>>>>> Hi Manav, > >>>>>> > >>>>>> OTOH, we could add the strictly increasing 64 bit sequence > >>>>>> number to OSPFv3 Auth Trailer draft without too much trouble. > >>>>>> Even though it might not end up to be exactly what is used > >>>>>> for the OSPFv2 draft, it seems there is a requirement to do > >>>>>> something better than is done today. Right now, the OSPFv2 IP > >>>>>> layer security draft still has all the nounce stuff in it. > >>>>>> The 64 sequence was primarily a product of the E-mail thread > >>>>>> between you, Sam, and myself. > >>>>>> > >>>>>> Thanks, > >>>>>> Acee > >>>>>> > >>>>>> On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: > >>>>>> > >>>>>> Hi Vishwas, > >>>>>> > >>>>>> As i have explained earlier, AT is a complete solution and > >>>>>> none of the current proposals in KARP (nonce ID, boot count, > >>>>>> etc) will be invalidating it. AT provides the basic > >>>>>> infrastructure over which other these will get built. The two > >>>>>> are thus not comparable. > >>>>>> > >>>>>> Cheers, Manav > >>>>>> > >>>>>> ________________________________ > >>>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > >>>>>> Sent: Tuesday, April 12, 2011 10.32 PM > >>>>>> To: Michael Barnes > >>>>>> Cc: Bhatia, Manav (Manav); > >>>>>> curtis@occnc.com; Abhay Roy; > >>>>>> ospf@ietf.org > >>>>>> Subject: Re: [OSPF] WG Last Call for Supporting > >>>>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai > >>>>>> > >>>>>> Hi Manav/ Mike, > >>>>>> > >>>>>> Though it is ok to have another draft invalidate this one > >>>>>> after some time. It would be a challenge to get > >>>>>> implementations to change as fast (if at all). > >>>>>> > >>>>>> In my view if the current solution is deemed incomplete, we > >>>>>> can correct the current solution. > >>>>>> > >>>>>> Thanks, > >>>>>> Vishwas > >>>>>> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes > >>>>>> > wrote: > >>>>>> Hello Manav, > >>>>>> > >>>>>> ------ Original Message ------ > >>>>>> Received: Mon, 11 Apr 2011 10:05:36 PM PDT > >>>>>> From: "Bhatia, Manav (Manav)" > >>>>>> >>>>>> ucent.com>> > >>>>>> To: Michael Barnes > >>>>>> >, > >>>>>> "curtis@occnc.com" > >>>>>> >, Abhay Roy > >>>>>> >Cc: > >>>>>> "ospf@ietf.org" > >>>>>> > > >>>>>> Subject: RE: [OSPF] WG Last Call for Supporting > >>>>>> Authentication Trailer for > >>>>>> OSPFv3 - draft-ietf-ospf-auth-trai > >>>>>> > >>>>>>> Hi Michael, > >>>>>>> > >>>>>>>>> right direction and would not have to be revisited > >>>>>> quite as soon if > >>>>>>>>> something more robust were proposed. > >>>>>>>>> > >>>>>>>>> Bottom line. Falls short of what I'd like to see but > >>>>>> no objection. > >>>>>>>>> > >>>>>>>>> Curtis > >>>>>>>> > >>>>>>>> I agree with Curis. I'd really like to see the first version > >>>>>>>> of this spec at > >>>>>>>> least have the extended sequence number as is being > >>>>>> discussed for v2. > >>>>>>> > >>>>>>> I disagree that AT should have a 64 bit sequence space > >> in the base > >>>>>> specification primarily because we are not yet sure if the > >>>>>> KARP boot count > >>>>>> approach is what the WG will finally converge on (in which > >>>>>> case we would need > >>>>>> an extended sequence space). Also note that the AT provides > >>>>>> an "Auth Type" > >>>>>> field which can be assigned a new value (similar to how it > >>>>>> will be done for > >>>>>> OSPFv2) once we decide to move to a different scheme. The > >>>>>> same standard that > >>>>>> extends the OSPFv2 sequence space can also do it for OSPFv3 > >>>>>> AT block - really > >>>>>> hardly an overhead. > >>>>>>> > >>>>>>> Also note that you could consider this proposal as just > >>>>>> bringing OSPFv3 at > >>>>>> par with OSPFv2. Once this is done, any proposal that extends > >>>>>> OSPFv2 will > >>>>>> natively work for OSPFv3 as well. > >>>>>> > >>>>>> So you are saying that this flaw is okay with you? I'd rather > >>>>>> hold off on > >>>>>> pushing this forward until this flaw is fixed. And I think > >>>>>> waiting to see what > >>>>>> happens in KARP might be a good idea. > >>>>>> > >>>>>> Regards, > >>>>>> Michael > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OSPF mailing list > >>>>>> OSPF@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ospf > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OSPF mailing list > >>>>>> OSPF@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ospf > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --00504502b67c8c57f404a0d0615d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Acee/ Manav,
=A0
Good to see we have nearly converged.
=A0
I see no reason to mention how to break up the 64 bit sequence number,= we should just mention the behavior desired from that sequence number.
=A0
The actual=A0generation of the=A0should be implementation specific.=A0= This is no different from any other spec.
=A0
Thanks,
Vishwas
On Wed, Apr 13, 2011 at 10:40 AM, Acee Lindem <acee.lindem= @ericsson.com> wrote:
Hi Manav,

On Apr 13, 2011, at 1:29 PM, Bhatia, Manav (Manav) wr= ote:

> Ok, I give up - lets increase the sequence space to 64 bit= s! I seem to be the only one who is opposing adding something that I have m= yself proposed in some other draft! :)
>
> I am not very comfortable with mandating that upper 32 bits sh= ould be retrieved from the non volatile storage because there may be device= s that cannot do this (i.e. may not be able to store data in nvram) and the= y will thus become non compliant to the about-to-be-RFC. How does a device = that's wants to do AT but cant store info in nvram ever become complian= t to this standard?
>
> I see two ways to deal with this:
>
> (1) The text= on upper 32 bits should be a MAY and not a MUST, so that implementations t= hat don't have nvram or don't want to implement this part of the sp= ec still remain compliant to the standard.

I'd vote for this option since I'd bet that devices sophi= sticated enough to run OSPFv3 deployed in places where you care about repla= y protection across cold restarts will have some form of non-volatile memor= y. Hence, I'd make it a SHOULD instead of a MUST.

Thanks,
Acee


>
> OR
>
> (2) We just incre= ase the sequence space to 64 bits and don't say anything about it. We l= et a later RFC define how the upper 32 bits may be populated.
>
> Cheers, Manav
>
>> -----Original Message-----
>&g= t; From: Acee Lindem [mailto:ac= ee.lindem@ericsson.com]
>> Sent: Wednesday, April 13, 2011 9.4= 8 PM
>> To: Bhatia, Manav (Manav)
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] WG Last Call for= Supporting
>> Authentication Trailer for OSPFv3 - draft-ietf-ospf= -auth-trai
>>
>> Hi Manav,
>>
>> On Apr 13, 2011, at = 12:12 PM, Bhatia, Manav (Manav) wrote:
>>
>>> Hi Acee,=
>>>
>>> The reason I didn't want a 64 bit non-= decreasing sequence
>> number in AT is because we are not yet sure if that's the
&= gt;> final approach that we will take. While it appears that this
>= ;> is probably the path that we will go down with eventually, I
>&= gt; would really like to wait till this gets finalized.
>>
>> I believe we all accept that this is not necessarily t= he
>> final solution. However, the 64 bit sequence number is bette= r
>> (as discussed in the E-mail thread between you, Sam, and
>> myself) is much better than what we have with OSPFv2 today.
>= ;>
>> Thanks,
>> Acee
>>
>>
>&= gt;
>>>
>>> In the OSPFv2 draft, its trivial to def= ine a new Auth type
>> for OSPFv3 which expands the sequence space to 64 bits, for
>= ;> folks that really want to use an expanded sequence space.
>>= >
>>> Cheers, Manav
>>>
>>>> ----= -Original Message-----
>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]
>>>> Sent: Wednesd= ay, April 13, 2011 9.36 PM
>>>> To: Bhatia, Manav (Manav) >>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org
>>>> Subject: Re: [OSPF] WG Las= t Call for Supporting
>>>> Authentication Trailer for OSPFv3= - draft-ietf-ospf-auth-trai
>>>>
>>>> Hi Manav,
>>>>
>&= gt;>> On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote:
&= gt;>>>
>>>>> Hi Acee,
>>>>> >>>>> I am ok with adding the sequence number strictly incre= asing
>>>> in the AT draft. What I was opposing was to inclu= de the nonce
>>>> or the 64 bit auth sequence space that has= been proposed
>> for OSPFv2.
>>>>
>>>> I agree with t= he nonce but I don't see why we don't use the
>>>> 6= 4-bit sequence number. We've changed a number of things from
>>= ;>> the existing OSPFv2 authentication trailer already and using
>>>> a 64 bit non-decreasing sequence number is a relatively>> small change.
>>>>
>>>> Thanks,
= >>>> Acee
>>>>
>>>>
>>&g= t;>>
>>>>> Cheers, Manav
>>>>>
>>>&= gt;>> -----Original Message-----
>>>>>> From: Ac= ee Lindem [mailto:acee.lindem@e= ricsson.com]
>>>>>> Sent: Wednesday, April 13, 2011 8.32 PM
>>= ;>>>> To: Bhatia, Manav (Manav)
>>>>>> Cc:= Vishwas Manral; Michael Barnes; ospf@ietf= .org
>>>>>> Subject: Re: [OSPF] WG Last Call for Supporting>>>>>> Authentication Trailer for OSPFv3 - draft-ietf-os= pf-auth-trai
>>>>>>
>>>>>> Hi Man= av,
>>>>>>
>>>>>> OTOH, we could add the= strictly increasing 64 bit sequence
>>>>>> number to = OSPFv3 Auth Trailer draft without too much trouble.
>>>>>= > Even though it might not end up to be exactly what is used
>>>>>> for the OSPFv2 draft, it seems there is a requirem= ent to do
>>>>>> something better than is done today. = Right now, the OSPFv2 IP
>>>>>> layer security draft s= till has all the nounce stuff in it.
>>>>>> The 64 sequence was primarily a product of the E-m= ail thread
>>>>>> between you, Sam, and myself.
>= ;>>>>>
>>>>>> Thanks,
>>>&g= t;>> Acee
>>>>>>
>>>>>> On Apr 12, 2011, at 4:= 41 PM, Bhatia, Manav (Manav) wrote:
>>>>>>
>>= >>>> Hi Vishwas,
>>>>>>
>>>>= ;>> As i have explained earlier, AT is a complete solution and
>>>>>> none of the current proposals in KARP (nonce ID, b= oot count,
>>>>>> etc) will be invalidating it. AT pro= vides the basic
>>>>>> infrastructure over which other= these will get built. The two
>>>>>> are thus not comparable.
>>>>>&g= t;
>>>>>> Cheers, Manav
>>>>>>>>>>>> ________________________________
>>>&= gt;>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
>>>>>> Sent: Tuesday, April 12, 2011 10.32 PM
>>= >>>> To: Michael Barnes
>>>>>> Cc: Bhatia,= Manav (Manav);
>>>>>> curtis@occnc.com<mailto:cur= tis@occnc.com>; Abhay Roy;
>>>>>> ospf@ietf.org= <mailto:ospf@ietf.org>
>&g= t;>>>> Subject: Re: [OSPF] WG Last Call for Supporting
>&= gt;>>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-aut= h-trai
>>>>>>
>>>>>> Hi Manav/ Mike,
>= ;>>>>>
>>>>>> Though it is ok to have a= nother draft invalidate this one
>>>>>> after some tim= e. It would be a challenge to get
>>>>>> implementations to change as fast (if at all).
= >>>>>>
>>>>>> In my view if the curr= ent solution is deemed incomplete, we
>>>>>> can corre= ct the current solution.
>>>>>>
>>>>>> Thanks,
>>>= ;>>> Vishwas
>>>>>> On Mon, Apr 11, 2011 at 1= 0:27 PM, Michael Barnes
>>>>>> <michael_barnes@usa.net<mailto:michael_barnes@usa.net>> wrote:
>>>>>> Hello Manav,
>>>>>>
>&g= t;>>>> ------ Original Message ------
>>>>>&g= t; Received: Mon, 11 Apr 2011 10:05:36 PM PDT
>>>>>> F= rom: "Bhatia, Manav (Manav)"
>>>>>> <manav.bhatia@alcatel-lucent.com<mailto:manav.bhatia@alcatel-l
>>>>>> ucent.com>>
>>>>>> To: Michael Barnes
>>>>>> <= ;michael_barnes@usa.net<ma= ilto:michael_barnes@usa.net&g= t;>,
>>>>>> "curtis@o= ccnc.com<mailto:curtis@occnc.com= >"
>>>>>> <curtis@occnc.com<mailto:= curtis@occnc.com>>, Abhay Roy
>>>>>> <akr@cisco.com= <mailto:akr@cisco.com>>Cc= :
>>>>>> "ospf@i= etf.org<mailto:ospf@ietf.org>= ;"
>>>>>> <ospf@ietf.org= <mailto:ospf@ietf.org>>>>>>>> Subject: RE: [OSPF] WG Last Call for Supporting<= br> >>>>>> Authentication Trailer for
>>>>>= > OSPFv3 - draft-ietf-ospf-auth-trai
>>>>>>
>= >>>>>> Hi Michael,
>>>>>>>
>>>>>>>>> right direction and would not have to = be revisited
>>>>>> quite as soon if
>>>&g= t;>>>>> something more robust were proposed.
>>>= >>>>>>
>>>>>>>>> Bottom line. =A0Falls short of what I&= #39;d like to see but
>>>>>> no objection.
>>= >>>>>>>
>>>>>>>>> Curtis=
>>>>>>>>
>>>>>>>> I agre= e with Curis. I'd really like to see the first version
>>>&= gt;>>>> of this spec at
>>>>>>>> lea= st have the extended sequence number as is being
>>>>>> discussed for v2.
>>>>>>><= br>>>>>>>> I disagree that AT should have a 64 bit seq= uence space
>> in the base
>>>>>> specificati= on primarily because we are not yet sure if the
>>>>>> KARP boot count
>>>>>> approa= ch is what the WG will finally converge on (in which
>>>>>= ;> case we would need
>>>>>> an extended sequence s= pace). Also note that the AT provides
>>>>>> an "Auth Type"
>>>>>&g= t; field which can be assigned a new value (similar to how it
>>&g= t;>>> will be done for
>>>>>> OSPFv2) once we= decide to move to a different scheme. The
>>>>>> same standard that
>>>>>> ext= ends the OSPFv2 sequence space can also do it for OSPFv3
>>>>= ;>> AT block - really
>>>>>> hardly an overhead.=
>>>>>>>
>>>>>>> Also note that= you could consider this proposal as just
>>>>>> bring= ing OSPFv3 at
>>>>>> par with OSPFv2. Once this is don= e, any proposal that extends
>>>>>> OSPFv2 will
>>>>>> natively w= ork for OSPFv3 as well.
>>>>>>
>>>>>= > So you are saying that this flaw is okay with you? I'd rather
>>>>>> hold off on
>>>>>> pushing th= is forward until this flaw is fixed. And I think
>>>>>>= ; waiting to see what
>>>>>> happens in KARP might be = a good idea.
>>>>>>
>>>>>> Regards,
>>&g= t;>>> Michael
>>>>>>
>>>>>&= gt; _______________________________________________
>>>>>= > OSPF mailing list
>>>>>> OSPF@ietf.org= <mailto:OSPF@ietf.org>
>&g= t;>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>>
>>>>>> ______________________= _________________________
>>>>>> OSPF mailing list
= >>>>>> OSPF@ietf.org= <mailto:OSPF@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/ospf
&g= t;>>>>>
>>>>>>
>>>>
&= gt;>>>
>>
>>


_______________________________= ________________
OSPF mailing list
O= SPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf


--00504502b67c8c57f404a0d0615d-- From russ@cisco.com Wed Apr 13 10:46:17 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 414D2E0871 for ; Wed, 13 Apr 2011 10:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08kj9JnEdFcb for ; Wed, 13 Apr 2011 10:46:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 487EEE086C for ; Wed, 13 Apr 2011 10:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=597; q=dns/txt; s=iport; t=1302716776; x=1303926376; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BNwaw7GYwADfMt429+9kDG2LhcymWESie0/gG2Sypr0=; b=D+1bxEXoJneH7rB2/69OWXB7Vo0/j9QDTIVctGB1cz6k9wX2vERKm0Tg zJXQyf1WzmIA9HKfJ4wHAIS80YljfufLBbMSsdiulUa5QbFAp2kfhXQwc y30/kxZgAoBFO/nvOvWGYakVIl3C/KMyNXC+Qjx37H9ObH+P5PWSQbIjS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD7hpU2tJV2b/2dsb2JhbACmGXemOp0EhW4EjWiDbw X-IronPort-AV: E=Sophos;i="4.64,205,1301875200"; d="scan'208";a="429138585" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2011 17:45:58 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3DHjvqi032618; Wed, 13 Apr 2011 17:45:58 GMT Message-ID: <4DA5E14B.6010102@cisco.com> Date: Wed, 13 Apr 2011 13:45:47 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Acee Lindem References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1F1@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C4E79A4-6AC9-4797-822C-5C0963091C7A@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE210@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:46:17 -0000 >> (1) The text on upper 32 bits should be a MAY and not a MUST, so that implementations that don't have nvram or don't want to implement this part of the spec still remain compliant to the standard. > > I'd vote for this option since I'd bet that devices sophisticated enough to run OSPFv3 deployed in places where you care about replay protection across cold restarts will have some form of non-volatile memory. Hence, I'd make it a SHOULD instead of a MUST. I'd vote for this option, as well. It provides the best chance of providing what's needed to prevent replays. :-) Russ From michael_barnes@usa.net Wed Apr 13 12:01:25 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 86DD2E06EE for ; Wed, 13 Apr 2011 12:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CGYhy1YghZt for ; Wed, 13 Apr 2011 12:01:24 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by ietfc.amsl.com (Postfix) with ESMTP id 983EBE0853 for ; Wed, 13 Apr 2011 12:01:21 -0700 (PDT) Received: from cmsout02.mbox.net (co02-lo [127.0.0.1]) by cmsout02.mbox.net (Postfix) with ESMTP id A6C0B1341C1; Wed, 13 Apr 2011 19:01:20 +0000 (GMT) X-USANET-Received: from cmsout02.mbox.net [127.0.0.1] by cmsout02.mbox.net via mtad (C8.MAIN.3.72B) with ESMTP id 391PDmTBR2464M02; Wed, 13 Apr 2011 19:01:17 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from cmsapps02.cms.usa.net [165.212.11.138] by cmsout02.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID393PDmTBR7896X02; Wed, 13 Apr 2011 19:01:17 -0000 X-USANET-Source: 165.212.11.138 IN michael_barnes@usa.net cmsapps02.cms.usa.net X-USANET-MsgId: XID393PDmTBR7896X02 Received: from web04.cms.usa.net [165.212.8.204] by cmsapps02.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.72B) with ESMTP id 714PDmTBR9568M38; Wed, 13 Apr 2011 19:01:17 -0000 X-USANET-Auth: 165.212.8.204 AUTO michael_barnes@usa.net web04.cms.usa.net Received: from 198.144.206.23 [198.144.206.23] by web04.cms.usa.net (USANET web-mailer C8.MAIN.3.73O); Wed, 13 Apr 2011 19:01:17 -0000 Date: Wed, 13 Apr 2011 12:01:17 -0700 From: "Michael Barnes" To: "Bhatia, Manav (Manav)" X-Mailer: USANET web-mailer (C8.MAIN.3.73O) Mime-Version: 1.0 Message-ID: <214PDmTaR0880S04.1302721277@web04.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID714PDmTBR9568X38 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:01:25 -0000 ------ Original Message ------ Received: Wed, 13 Apr 2011 10:29:47 AM PDT From: "Bhatia, Manav (Manav)" To: Acee Lindem Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer fo= r OSPFv3 - draft-ietf-ospf-auth-trai > Ok, I give up - lets increase the sequence space to 64 bits! I seem to = be the = >only one who is opposing adding something that I have myself proposed in= some > other draft! :) = > = > I am not very comfortable with mandating that upper 32 bits should be retrieved = >from the non volatile storage because there may be devices that cannot d= o this = It is okay if this is not mandated. I am quite happy that it is an option= =2E > (i.e. may not be able to store data in nvram) and they will thus become= non > compliant to the about-to-be-RFC. How does a device that's wants to do = AT but = > cant store info in nvram ever become compliant to this standard? > = > I see two ways to deal with this: > = > (1) The text on upper 32 bits should be a MAY and not a MUST, so that implementations that don't have nvram or don't want to implement this par= t of the spec still remain compliant to the standard. > = > OR > = > (2) We just increase the sequence space to 64 bits and don't say anythi= ng about it. We let a later RFC define how the upper 32 bits may be populate= d. > = > Cheers, Manav I suggest the draft simply increases the space but doesn't mandate how it= is used. However, the draft can offer suggestions that the upper 32-bits MAY= be generated in some way such as nvram or date or whatever. I don't think it= really matters exactly how the value is derived, and there are multiple methods that would work equally well. I agree that the draft shouldn't mandate which method is used. The draft could even say that if a vendor chooses they may leave the upper 32-bits as zeros. Thanks, Michael From acee.lindem@ericsson.com Wed Apr 13 13:05:47 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9DC5FE084E for ; Wed, 13 Apr 2011 13:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-JbC6yGzSXK for ; Wed, 13 Apr 2011 13:05:45 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id BA025E06BC for ; Wed, 13 Apr 2011 13:05:45 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3DK5dxU000600; Wed, 13 Apr 2011 15:05:42 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 13 Apr 2011 16:05:37 -0400 From: Acee Lindem To: Vishwas Manral Date: Wed, 13 Apr 2011 16:05:34 -0400 Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai Thread-Index: Acv6Fieg//JiwiwhQaq9rcslg/GC5A== Message-ID: <08CCC98D-EFB7-400D-8516-82D63D7ECE8F@ericsson.com> References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com> <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1EF@INBANSXCHMBSA1.in.alcatel-lucent.com> <66C78CD1-77BC-4DAA-BC79-818292E0659C@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE1F1@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C4E79A4-6AC9-4797-822C-5C0963091C7A@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE210@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 20:05:47 -0000 Hi Vishwas, Manav, On Apr 13, 2011, at 1:45 PM, Vishwas Manral wrote: Hi Acee/ Manav, Good to see we have nearly converged. I see no reason to mention how to break up the 64 bit sequence number, we s= hould just mention the behavior desired from that sequence number. The actual generation of the should be implementation specific. This is no = different from any other spec. This is ok with me as well - I'll simply include the sequence number requir= ements and we can review before resubmitting a new revision. All, Although we'll restart the WG last call with the new revision. Please send = any additional comments on the draft. Thanks, Acee Thanks, Vishwas On Wed, Apr 13, 2011 at 10:40 AM, Acee Lindem > wrote: Hi Manav, On Apr 13, 2011, at 1:29 PM, Bhatia, Manav (Manav) wrote: > Ok, I give up - lets increase the sequence space to 64 bits! I seem to be= the only one who is opposing adding something that I have myself proposed = in some other draft! :) > > I am not very comfortable with mandating that upper 32 bits should be ret= rieved from the non volatile storage because there may be devices that cann= ot do this (i.e. may not be able to store data in nvram) and they will thus= become non compliant to the about-to-be-RFC. How does a device that's want= s to do AT but cant store info in nvram ever become compliant to this stand= ard? > > I see two ways to deal with this: > > (1) The text on upper 32 bits should be a MAY and not a MUST, so that imp= lementations that don't have nvram or don't want to implement this part of = the spec still remain compliant to the standard. I'd vote for this option since I'd bet that devices sophisticated enough to= run OSPFv3 deployed in places where you care about replay protection acros= s cold restarts will have some form of non-volatile memory. Hence, I'd make= it a SHOULD instead of a MUST. Thanks, Acee > > OR > > (2) We just increase the sequence space to 64 bits and don't say anything= about it. We let a later RFC define how the upper 32 bits may be populated= . > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Wednesday, April 13, 2011 9.48 PM >> To: Bhatia, Manav (Manav) >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] WG Last Call for Supporting >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >> >> Hi Manav, >> >> On Apr 13, 2011, at 12:12 PM, Bhatia, Manav (Manav) wrote: >> >>> Hi Acee, >>> >>> The reason I didn't want a 64 bit non-decreasing sequence >> number in AT is because we are not yet sure if that's the >> final approach that we will take. While it appears that this >> is probably the path that we will go down with eventually, I >> would really like to wait till this gets finalized. >> >> I believe we all accept that this is not necessarily the >> final solution. However, the 64 bit sequence number is better >> (as discussed in the E-mail thread between you, Sam, and >> myself) is much better than what we have with OSPFv2 today. >> >> Thanks, >> Acee >> >> >> >>> >>> In the OSPFv2 draft, its trivial to define a new Auth type >> for OSPFv3 which expands the sequence space to 64 bits, for >> folks that really want to use an expanded sequence space. >>> >>> Cheers, Manav >>> >>>> -----Original Message----- >>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>> Sent: Wednesday, April 13, 2011 9.36 PM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org >>>> Subject: Re: [OSPF] WG Last Call for Supporting >>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>> >>>> Hi Manav, >>>> >>>> On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote: >>>> >>>>> Hi Acee, >>>>> >>>>> I am ok with adding the sequence number strictly increasing >>>> in the AT draft. What I was opposing was to include the nonce >>>> or the 64 bit auth sequence space that has been proposed >> for OSPFv2. >>>> >>>> I agree with the nonce but I don't see why we don't use the >>>> 64-bit sequence number. We've changed a number of things from >>>> the existing OSPFv2 authentication trailer already and using >>>> a 64 bit non-decreasing sequence number is a relatively >> small change. >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>>> >>>>> Cheers, Manav >>>>> >>>>>> -----Original Message----- >>>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>>> Sent: Wednesday, April 13, 2011 8.32 PM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Vishwas Manral; Michael Barnes; ospf@ietf.org >>>>>> Subject: Re: [OSPF] WG Last Call for Supporting >>>>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>>>> >>>>>> Hi Manav, >>>>>> >>>>>> OTOH, we could add the strictly increasing 64 bit sequence >>>>>> number to OSPFv3 Auth Trailer draft without too much trouble. >>>>>> Even though it might not end up to be exactly what is used >>>>>> for the OSPFv2 draft, it seems there is a requirement to do >>>>>> something better than is done today. Right now, the OSPFv2 IP >>>>>> layer security draft still has all the nounce stuff in it. >>>>>> The 64 sequence was primarily a product of the E-mail thread >>>>>> between you, Sam, and myself. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>> On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: >>>>>> >>>>>> Hi Vishwas, >>>>>> >>>>>> As i have explained earlier, AT is a complete solution and >>>>>> none of the current proposals in KARP (nonce ID, boot count, >>>>>> etc) will be invalidating it. AT provides the basic >>>>>> infrastructure over which other these will get built. The two >>>>>> are thus not comparable. >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>> ________________________________ >>>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>>> Sent: Tuesday, April 12, 2011 10.32 PM >>>>>> To: Michael Barnes >>>>>> Cc: Bhatia, Manav (Manav); >>>>>> curtis@occnc.com>; Abhay Roy; >>>>>> ospf@ietf.org> >>>>>> Subject: Re: [OSPF] WG Last Call for Supporting >>>>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >>>>>> >>>>>> Hi Manav/ Mike, >>>>>> >>>>>> Though it is ok to have another draft invalidate this one >>>>>> after some time. It would be a challenge to get >>>>>> implementations to change as fast (if at all). >>>>>> >>>>>> In my view if the current solution is deemed incomplete, we >>>>>> can correct the current solution. >>>>>> >>>>>> Thanks, >>>>>> Vishwas >>>>>> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes >>>>>> >> wrote: >>>>>> Hello Manav, >>>>>> >>>>>> ------ Original Message ------ >>>>>> Received: Mon, 11 Apr 2011 10:05:36 PM PDT >>>>>> From: "Bhatia, Manav (Manav)" >>>>>> >>>>>> ucent.com>> >>>>>> To: Michael Barnes >>>>>> >>, >>>>>> "curtis@occnc.com>" >>>>>> >>, Abhay Roy >>>>>> >>Cc: >>>>>> "ospf@ietf.org>" >>>>>> >> >>>>>> Subject: RE: [OSPF] WG Last Call for Supporting >>>>>> Authentication Trailer for >>>>>> OSPFv3 - draft-ietf-ospf-auth-trai >>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>>>> right direction and would not have to be revisited >>>>>> quite as soon if >>>>>>>>> something more robust were proposed. >>>>>>>>> >>>>>>>>> Bottom line. Falls short of what I'd like to see but >>>>>> no objection. >>>>>>>>> >>>>>>>>> Curtis >>>>>>>> >>>>>>>> I agree with Curis. I'd really like to see the first version >>>>>>>> of this spec at >>>>>>>> least have the extended sequence number as is being >>>>>> discussed for v2. >>>>>>> >>>>>>> I disagree that AT should have a 64 bit sequence space >> in the base >>>>>> specification primarily because we are not yet sure if the >>>>>> KARP boot count >>>>>> approach is what the WG will finally converge on (in which >>>>>> case we would need >>>>>> an extended sequence space). Also note that the AT provides >>>>>> an "Auth Type" >>>>>> field which can be assigned a new value (similar to how it >>>>>> will be done for >>>>>> OSPFv2) once we decide to move to a different scheme. The >>>>>> same standard that >>>>>> extends the OSPFv2 sequence space can also do it for OSPFv3 >>>>>> AT block - really >>>>>> hardly an overhead. >>>>>>> >>>>>>> Also note that you could consider this proposal as just >>>>>> bringing OSPFv3 at >>>>>> par with OSPFv2. Once this is done, any proposal that extends >>>>>> OSPFv2 will >>>>>> natively work for OSPFv3 as well. >>>>>> >>>>>> So you are saying that this flaw is okay with you? I'd rather >>>>>> hold off on >>>>>> pushing this forward until this flaw is fixed. And I think >>>>>> waiting to see what >>>>>> happens in KARP might be a good idea. >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>> >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>> >>>>>> >>>> >>>> >> >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Wed Apr 13 19:32:20 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22E6EE07AA for ; Wed, 13 Apr 2011 19:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nLAencwucOV for ; Wed, 13 Apr 2011 19:32:19 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfc.amsl.com (Postfix) with ESMTP id 54604E0707 for ; Wed, 13 Apr 2011 19:32:19 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p3E2WFvh026185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Apr 2011 21:32:18 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3E2WECB014445 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 14 Apr 2011 08:02:15 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 14 Apr 2011 08:02:14 +0530 From: "Bhatia, Manav (Manav)" To: "ospf@ietf.org" Date: Thu, 14 Apr 2011 08:02:12 +0530 Thread-Topic: Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv6NTMFTlWOl/kBQCiD5tHWT/WyAQAFtRvA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE257@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 02:32:20 -0000 OSPFers, Can a variant of this method be used to protect OSPFv2 and OSPFv3-AT?=20 Cheers, Manav > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, April 14, 2011 5.18 AM > To: karp@ietf.org > Subject: [karp] Using dynamically derived Traffic Keys for=20 > Routing Protocols >=20 > Hi, >=20 > Instead of using the pre shared key (PSK) in manual keying=20 > for all packets the routing protocols could use a traffic key=20 > that's derived from the PSK using some key derivation=20 > function. Each side could announce a random number (a nonce)=20 > and the KDF could mix this with the PSK to derive the traffic=20 > key per session. Benefits of this approach: >=20 > o Key rollover becomes very easy as it's a local decision now=20 > requiring now co-ordination with our peers. Each side can=20 > generate a new nonce and all others recompute the traffic key=20 > based on the new nonce value. Attackers cant inject packets=20 > with spurious nonces as this packet will be protected using=20 > the traffic key based on the nonce that others have sent. >=20 > o Avoids inter-session replay attacks without involving non=20 > volatile memory as each router will use a different nonce=20 > upon booting up. >=20 > In OSPF the nonce could be carried in the HELLO packets.=20 > There could be bit carried in the HELLOs which would indicate=20 > that the Hello is currently using the long lived key (or the=20 > PSK). The receiver upon receiving this would authenticate the=20 > packet using the PSK and would use the KDF to derive the=20 > traffic key. The KDF would mix the nonce with the PSK in some=20 > deterministic fashion. The receiver uses the derived traffic=20 > key for signing all subsequent OSPF packets and would=20 > indicate this by setting some bit (which says using traffic=20 > key). It will also include its own nonce. The original sender=20 > now uses the nonce that it receives and starts using the=20 > traffic key derived from this nonce for all subsequent=20 > packets. For a key rollover, the senders just have to choose=20 > a new nonce value. This can be done as frequently as desired=20 > and requires no manual intervention.=20 >=20 > Does this sound as going in the right direction? >=20 > Cheers, Manav >=20 > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From curtis@occnc.com Wed Apr 13 21:19:09 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2EED1E06D3 for ; Wed, 13 Apr 2011 21:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Krjn1NiJTzp for ; Wed, 13 Apr 2011 21:19:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 0ADA2E06F0 for ; Wed, 13 Apr 2011 21:19:07 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3E4J65C025986; Thu, 14 Apr 2011 00:19:06 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104140419.p3E4J65C025986@harbor.orleans.occnc.com> To: "Bhatia, Manav (Manav)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 08:02:12 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DE257@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 14 Apr 2011 00:19:06 -0400 Sender: curtis@occnc.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 04:19:09 -0000 In message <7C362EEF9C7896468B36C9B79200D8350CFD0DE257@INBANSXCHMBSA1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > OSPFers, > > Can a variant of this method be used to protect OSPFv2 and OSPFv3-AT? > > Cheers, Manav Hesitant to say "me too" again for S/N reasons, but ... yes/agree Someone needs to write up the details though. (and Manav seems willing to volunteer). Curtis > > -----Original Message----- > > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On > > Behalf Of Bhatia, Manav (Manav) > > Sent: Thursday, April 14, 2011 5.18 AM > > To: karp@ietf.org > > Subject: [karp] Using dynamically derived Traffic Keys for > > Routing Protocols > > > > Hi, > > > > Instead of using the pre shared key (PSK) in manual keying > > for all packets the routing protocols could use a traffic key > > that's derived from the PSK using some key derivation > > function. Each side could announce a random number (a nonce) > > and the KDF could mix this with the PSK to derive the traffic > > key per session. Benefits of this approach: > > > > o Key rollover becomes very easy as it's a local decision now > > requiring now co-ordination with our peers. Each side can > > generate a new nonce and all others recompute the traffic key > > based on the new nonce value. Attackers cant inject packets > > with spurious nonces as this packet will be protected using > > the traffic key based on the nonce that others have sent. > > > > o Avoids inter-session replay attacks without involving non > > volatile memory as each router will use a different nonce > > upon booting up. > > > > In OSPF the nonce could be carried in the HELLO packets. > > There could be bit carried in the HELLOs which would indicate > > that the Hello is currently using the long lived key (or the > > PSK). The receiver upon receiving this would authenticate the > > packet using the PSK and would use the KDF to derive the > > traffic key. The KDF would mix the nonce with the PSK in some > > deterministic fashion. The receiver uses the derived traffic > > key for signing all subsequent OSPF packets and would > > indicate this by setting some bit (which says using traffic > > key). It will also include its own nonce. The original sender > > now uses the nonce that it receives and starts using the > > traffic key derived from this nonce for all subsequent > > packets. For a key rollover, the senders just have to choose > > a new nonce value. This can be done as frequently as desired > > and requires no manual intervention. > > > > Does this sound as going in the right direction? > > > > Cheers, Manav > > > > -- > > Manav Bhatia, > > Service Router Product Group (SRPG) > > Alcatel-Lucent, India > > _______________________________________________ > > karp mailing list > > karp@ietf.org > > https://www.ietf.org/mailman/listinfo/karp > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Wed Apr 13 21:22:46 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A158AE06D3 for ; Wed, 13 Apr 2011 21:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7UzO5JndNQM for ; Wed, 13 Apr 2011 21:22:45 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id BEE2BE06B3 for ; Wed, 13 Apr 2011 21:22:45 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3E4MdNr011209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2011 23:22:42 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3E4MWOm024223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Apr 2011 09:52:38 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 14 Apr 2011 09:52:36 +0530 Message-ID: <4DA67655.10301@alcatel-lucent.com> Date: Thu, 14 Apr 2011 09:51:41 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: "curtis@occnc.com" References: <201104140419.p3E4J65C025986@harbor.orleans.occnc.com> In-Reply-To: <201104140419.p3E4J65C025986@harbor.orleans.occnc.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 04:22:46 -0000 Curtis, I can write a small ID explaining how this can be used for OSPF if folks believe this is something acceptable for doing key rollovers. Cheers, Manav On 4/14/2011 9:49 AM, Curtis Villamizar wrote: > > In message<7C362EEF9C7896468B36C9B79200D8350CFD0DE257@INBANSXCHMBSA1.in.alcatel-lucent.com> > "Bhatia, Manav (Manav)" writes: >> >> OSPFers, >> >> Can a variant of this method be used to protect OSPFv2 and OSPFv3-AT? >> >> Cheers, Manav > > > Hesitant to say "me too" again for S/N reasons, but ... yes/agree > > Someone needs to write up the details though. (and Manav seems > willing to volunteer). > > Curtis > > > >>> -----Original Message----- >>> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On >>> Behalf Of Bhatia, Manav (Manav) >>> Sent: Thursday, April 14, 2011 5.18 AM >>> To: karp@ietf.org >>> Subject: [karp] Using dynamically derived Traffic Keys for >>> Routing Protocols >>> >>> Hi, >>> >>> Instead of using the pre shared key (PSK) in manual keying >>> for all packets the routing protocols could use a traffic key >>> that's derived from the PSK using some key derivation >>> function. Each side could announce a random number (a nonce) >>> and the KDF could mix this with the PSK to derive the traffic >>> key per session. Benefits of this approach: >>> >>> o Key rollover becomes very easy as it's a local decision now >>> requiring now co-ordination with our peers. Each side can >>> generate a new nonce and all others recompute the traffic key >>> based on the new nonce value. Attackers cant inject packets >>> with spurious nonces as this packet will be protected using >>> the traffic key based on the nonce that others have sent. >>> >>> o Avoids inter-session replay attacks without involving non >>> volatile memory as each router will use a different nonce >>> upon booting up. >>> >>> In OSPF the nonce could be carried in the HELLO packets. >>> There could be bit carried in the HELLOs which would indicate >>> that the Hello is currently using the long lived key (or the >>> PSK). The receiver upon receiving this would authenticate the >>> packet using the PSK and would use the KDF to derive the >>> traffic key. The KDF would mix the nonce with the PSK in some >>> deterministic fashion. The receiver uses the derived traffic >>> key for signing all subsequent OSPF packets and would >>> indicate this by setting some bit (which says using traffic >>> key). It will also include its own nonce. The original sender >>> now uses the nonce that it receives and starts using the >>> traffic key derived from this nonce for all subsequent >>> packets. For a key rollover, the senders just have to choose >>> a new nonce value. This can be done as frequently as desired >>> and requires no manual intervention. >>> >>> Does this sound as going in the right direction? >>> >>> Cheers, Manav >>> >>> -- >>> Manav Bhatia, >>> Service Router Product Group (SRPG) >>> Alcatel-Lucent, India >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > From curtis@occnc.com Wed Apr 13 22:07:23 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 294F8E081D for ; Wed, 13 Apr 2011 22:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV1F8qcRs+Vf for ; Wed, 13 Apr 2011 22:07:22 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 4DF02E07FC for ; Wed, 13 Apr 2011 22:07:22 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3E57IrZ030963; Thu, 14 Apr 2011 01:07:19 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104140507.p3E57IrZ030963@harbor.orleans.occnc.com> To: Manav Bhatia From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 09:51:41 +0530." <4DA67655.10301@alcatel-lucent.com> Date: Thu, 14 Apr 2011 01:07:18 -0400 Sender: curtis@occnc.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:07:23 -0000 In message <4DA67655.10301@alcatel-lucent.com> Manav Bhatia writes: > > Curtis, > > I can write a small ID explaining how this can be used for OSPF if > folks believe this is something acceptable for doing key rollovers. > > Cheers, Manav Manav, You might want to say "for doing *session* key rollovers". The persistant key rollover would need a different mechanism. Curtis > On 4/14/2011 9:49 AM, Curtis Villamizar wrote: > > > > In message<7C362EEF9C7896468B36C9B79200D8350CFD0DE257@INBANSXCHMBSA1.in.alcatel-lucent.com> > > "Bhatia, Manav (Manav)" writes: > >> > >> OSPFers, > >> > >> Can a variant of this method be used to protect OSPFv2 and OSPFv3-AT? > >> > >> Cheers, Manav > > > > > > Hesitant to say "me too" again for S/N reasons, but ... yes/agree > > > > Someone needs to write up the details though. (and Manav seems > > willing to volunteer). > > > > Curtis > > > > > > > >>> -----Original Message----- > >>> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On > >>> Behalf Of Bhatia, Manav (Manav) > >>> Sent: Thursday, April 14, 2011 5.18 AM > >>> To: karp@ietf.org > >>> Subject: [karp] Using dynamically derived Traffic Keys for > >>> Routing Protocols > >>> > >>> Hi, > >>> > >>> Instead of using the pre shared key (PSK) in manual keying > >>> for all packets the routing protocols could use a traffic key > >>> that's derived from the PSK using some key derivation > >>> function. Each side could announce a random number (a nonce) > >>> and the KDF could mix this with the PSK to derive the traffic > >>> key per session. Benefits of this approach: > >>> > >>> o Key rollover becomes very easy as it's a local decision now > >>> requiring now co-ordination with our peers. Each side can > >>> generate a new nonce and all others recompute the traffic key > >>> based on the new nonce value. Attackers cant inject packets > >>> with spurious nonces as this packet will be protected using > >>> the traffic key based on the nonce that others have sent. > >>> > >>> o Avoids inter-session replay attacks without involving non > >>> volatile memory as each router will use a different nonce > >>> upon booting up. > >>> > >>> In OSPF the nonce could be carried in the HELLO packets. > >>> There could be bit carried in the HELLOs which would indicate > >>> that the Hello is currently using the long lived key (or the > >>> PSK). The receiver upon receiving this would authenticate the > >>> packet using the PSK and would use the KDF to derive the > >>> traffic key. The KDF would mix the nonce with the PSK in some > >>> deterministic fashion. The receiver uses the derived traffic > >>> key for signing all subsequent OSPF packets and would > >>> indicate this by setting some bit (which says using traffic > >>> key). It will also include its own nonce. The original sender > >>> now uses the nonce that it receives and starts using the > >>> traffic key derived from this nonce for all subsequent > >>> packets. For a key rollover, the senders just have to choose > >>> a new nonce value. This can be done as frequently as desired > >>> and requires no manual intervention. > >>> > >>> Does this sound as going in the right direction? > >>> > >>> Cheers, Manav > >>> > >>> -- > >>> Manav Bhatia, > >>> Service Router Product Group (SRPG) > >>> Alcatel-Lucent, India > >>> _______________________________________________ > >>> karp mailing list > >>> karp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/karp > >>> > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Wed Apr 13 22:11:43 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E67AEE07FC for ; Wed, 13 Apr 2011 22:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.961 X-Spam-Level: X-Spam-Status: No, score=-5.961 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwQxo7GJ66qR for ; Wed, 13 Apr 2011 22:11:43 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id 24394E0839 for ; Wed, 13 Apr 2011 22:11:26 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3E5BMRa002727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2011 00:11:24 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3E5BKW8029606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Apr 2011 10:41:20 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 14 Apr 2011 10:41:20 +0530 Message-ID: <4DA681C2.5070108@alcatel-lucent.com> Date: Thu, 14 Apr 2011 10:40:26 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: "curtis@occnc.com" References: <201104140507.p3E57IrZ030963@harbor.orleans.occnc.com> In-Reply-To: <201104140507.p3E57IrZ030963@harbor.orleans.occnc.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:11:44 -0000 Hi Curtis, > > You might want to say "for doing *session* key rollovers". The > persistant key rollover would need a different mechanism. > I had actually meant a persistant key rollover. Why would this mechanism not work there? Assume A and B are speaking to each other and A now wants to move to a different key. All it needs to do is to generate a new Nonce that will be fed into the KDF that B will use to generate the new traffic key. Also note that the keys used in this proposal will not be symmetrical. Cheers, Manav From acee.lindem@ericsson.com Thu Apr 14 05:31:21 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9CA1DE08DF for ; Thu, 14 Apr 2011 05:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.41 X-Spam-Level: X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1LfGsrjzDks for ; Thu, 14 Apr 2011 05:31:21 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 004D4E08DE for ; Thu, 14 Apr 2011 05:31:20 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3ECVJcL011596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Apr 2011 07:31:19 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 14 Apr 2011 08:31:18 -0400 From: Acee Lindem To: OSPF WG List Date: Thu, 14 Apr 2011 08:31:18 -0400 Thread-Topic: New Version Notification for draft-ietf-ospf-auth-trailer-ospfv3-04 Thread-Index: Acv6n9qdQUPXf888R4SZ75PbvXVhYw== Message-ID: References: <20110414101115.B7322E06D8@ietfc.amsl.com> In-Reply-To: <20110414101115.B7322E06D8@ietfc.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] New Version Notification for draft-ietf-ospf-auth-trailer-ospfv3-04 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:31:21 -0000 This version includes the change from a 32 bit monotonically increasing seq= uence number to a 64 bit strictly increasing sequence number.=20 The only changes are in sections 4.1, 4.5, and Appendix A.=20 Thanks, Acee On Apr 14, 2011, at 6:11 AM, IETF I-D Submission Tool wrote: >=20 > A new version of I-D, draft-ietf-ospf-auth-trailer-ospfv3-04.txt has been= successfully submitted by Acee Lindem and posted to the IETF repository. >=20 > Filename: draft-ietf-ospf-auth-trailer-ospfv3 > Revision: 04 > Title: Supporting Authentication Trailer for OSPFv3 > Creation_date: 2011-04-14 > WG ID: ospf > Number_of_pages: 21 >=20 > Abstract: > Currently OSPFv3 uses IPsec for authenticating protocol packets. > However, there are some environments, e.g., Mobile Ad-hoc Networks > (MANETs), where IPsec is difficult to configure and maintain, and > this mechanism cannot be used. This draft proposes an alternative > mechanism that can be used so that OSPFv3 does not depend upon IPsec > for authentication. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 From ben@niven-jenkins.co.uk Thu Apr 14 12:11:14 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DFB6E07FD; Thu, 14 Apr 2011 12:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.307 X-Spam-Level: X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw0QkGpul2We; Thu, 14 Apr 2011 12:11:13 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfc.amsl.com (Postfix) with ESMTP id D208FE0791; Thu, 14 Apr 2011 12:11:13 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-108-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QARwg-0007GI-Gn; Thu, 14 Apr 2011 20:11:14 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <0636D1EB-942D-4416-858E-E698863B141C@niven-jenkins.co.uk> Date: Thu, 14 Apr 2011 20:11:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0636D1EB-942D-4416-858E-E698863B141C@niven-jenkins.co.uk> To: Benjamin Niven-Jenkins X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: ospf@ietf.org, L3VPN WG mailing list Subject: Re: [OSPF] Joint L3VPN & OSPF WG LC for draft-ietf-l3vpn-ospfv3-pece-07 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 19:11:14 -0000 L3VPNers & OSPFers, This joint WG LC has now ended. One person commented on the L3VPN = mailing list: http://www.ietf.org/mail-archive/web/l3vpn/current/msg02903.html Can the authors continue to work to resolve the comments and produce an = updated draft. Thanks Ben =20 On 16 Mar 2011, at 07:44, Benjamin Niven-Jenkins wrote: > L3VPNers & OSPFers, >=20 > You may recall that back in January 2010 we pulled = draft-ietf-l3vpn-ospfv3-pece-04 out of the RFC Editor's queue because we = had forgotten to solicit a review from the OSPF WG. See = http://www.ietf.org/mail-archive/web/ospf/current/msg05658.htm for more = info on that. >=20 > The OSPF WG raised some comments on the draft, which has gone through = a few revisions and draft-ietf-l3vpn-ospfv3-pece-07 is thought to = address all the previous comments raised. >=20 > This e-mail is therefore the start of a joint L3VPN & OSPF WG Last = Call for the updated draft. It is restricted to changes made since the = last review (i.e. changes between -04 and -07). >=20 > Due to the proximity of IETF80 we are allowing 4 weeks for the LC. = Please provide any further comments on the changes by midnight PDT on = the 13th April 2011. >=20 > You can view -07 of the draft here: > http://tools.ietf.org/id/draft-ietf-l3vpn-ospfv3-pece-07.txt >=20 > You can view a diff between -04 and -07 here: > = http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-l3vpn-ospfv3-pece-04&url2=3D= draft-ietf-l3vpn-ospfv3-pece-07 >=20 > Thanks > Ben (on behalf of the L3VPN & OSPF chairs) >=20 From curtis@occnc.com Fri Apr 15 13:39:16 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3234AE0682 for ; Fri, 15 Apr 2011 13:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFAh8-3BktYS for ; Fri, 15 Apr 2011 13:39:15 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 4F423E067F for ; Fri, 15 Apr 2011 13:39:15 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FKd8U9075368; Fri, 15 Apr 2011 16:39:08 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104152039.p3FKd8U9075368@harbor.orleans.occnc.com> To: Manav Bhatia From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 10:40:26 +0530." <4DA681C2.5070108@alcatel-lucent.com> Date: Fri, 15 Apr 2011 16:39:08 -0400 Sender: curtis@occnc.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 20:39:16 -0000 In message <4DA681C2.5070108@alcatel-lucent.com> Manav Bhatia writes: > > Hi Curtis, > > > > > You might want to say "for doing *session* key rollovers". The > > persistant key rollover would need a different mechanism. > > > > I had actually meant a persistant key rollover. Why would this mechanism > not work there? > > Assume A and B are speaking to each other and A now wants to move to a > different key. All it needs to do is to generate a new Nonce that will > be fed into the KDF that B will use to generate the new traffic key. > > Also note that the keys used in this proposal will not be symmetrical. > > Cheers, Manav The common practice as I understand it is to maintain at least two keys, one is used to build authentication headers and one or either of the two can be used to check authentication headers. During a cutover, there is an interim period during which one end is more up to date than the other. First the second key is added as an alternate key to check authentication headers. Then when the provider (or software) has verified that this key is available where it needs to be, the new key is used to build authentication headers. Finally the old key is disabled and the process can be repeated later. The same applies to assymmetrical key pairs. The new public key needs to be on the recieve side before the sender starts using the new private key (assuming that sort of key pair). There should be no requirement for the persistant key to be symmetrical and it is perfectly valid to have different shared session keys for each direction, though perhaps there is very if any little benefit. The session keys would be unique to a pair of routers, would be transient in nature, and there is no need for the NOC (network operation center) to know what session keys are in use at any given time. Only the persistant keys would be maintained by the NOC and held in non-volitile memory so as to remain persistant over reboots. Curtis From manav.bhatia@alcatel-lucent.com Fri Apr 15 19:04:42 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 85C09E0690 for ; Fri, 15 Apr 2011 19:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFsl7s868OIc for ; Fri, 15 Apr 2011 19:04:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id B57F9E061E for ; Fri, 15 Apr 2011 19:04:41 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3G24YVL020425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Apr 2011 21:04:37 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3G24Xce027663 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 16 Apr 2011 07:34:33 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 16 Apr 2011 07:34:33 +0530 From: "Bhatia, Manav (Manav)" To: "curtis@occnc.com" Date: Sat, 16 Apr 2011 07:34:31 +0530 Thread-Topic: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv7rTHNlCY0I8J3RdyYpuosivy/MwAKoPeQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE7A3@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of "Thu, 14 Apr 2011 10:40:26 +0530." <4DA681C2.5070108@alcatel-lucent.com> <201104152039.p3FKd8U9075368@harbor.orleans.occnc.com> In-Reply-To: <201104152039.p3FKd8U9075368@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 02:04:42 -0000 =20 > The common practice as I understand it is to maintain at least two > keys, one is used to build authentication headers and one or either of > the two can be used to check authentication headers. During a > cutover, there is an interim period during which one end is more up to > date than the other. First the second key is added as an alternate > key to check authentication headers. Then when the provider (or > software) has verified that this key is available where it needs to > be, the new key is used to build authentication headers. Finally the > old key is disabled and the process can be repeated later. Yes, this is correct. =20 > The session keys would be unique to a pair of routers, would be > transient in nature, and there is no need for the NOC (network > operation center) to know what session keys are in use at any given > time. Only the persistant keys would be maintained by the NOC and > held in non-volitile memory so as to remain persistant over reboots. This too is correct and is inline with what I am thinking. I was initially thinking of deriving the traffic or the session key based o= n the nonce that the other end generates. While this works when there are o= nly two routers speaking to each other, it creates a problem on a LAN becau= se now you don't know which nonce to pick for generating the traffic key. W= e could define some election mechanism but that's getting needlessly comple= x. A different approach that fixes this issue is by deriving the traffic key b= ased on the nonce that the router itself generates. Let me explain how. Routers A and B have a Key/Password that is exchanged through some OOB mech= anism or a KMP. Each side generates a nonce and mixes it with the Key using= some KDF to derive its own traffic keys. This means that both A and B use = a different traffic key/password to secure the packets on the TX. Upon rece= iving the protected protocol packets each side reads the Nonce that's carri= ed in the packet and is able to derive the traffic key since its aware of t= he original Key and the KDF. It uses this traffic key to authenticate the p= acket.=20 To make this work the freshness of a packet carrying the nonce must be guar= anteed, because we don't want the receiver to start consuming replayed pack= ets carrying an older nonce. This can be achieved by using a mechanism similar to our original challenge= /response mechanism which will always guarantee freshness. Traffic or Session Key rollover is achieved by simply changing the Nonce at= the local end. The receiver will verify that its indeed the router that it= should be speaking to that's changed this and once it verifies it will mov= e to the new key. Again, how the receiver verifies this has been explained = in draft-bhatia-karp-ospf-ip-layer-protection Cheers, Manav= From lberger@labn.net Mon Apr 18 12:30:24 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E7895E070C for ; Mon, 18 Apr 2011 12:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJkTC5oElIfp for ; Mon, 18 Apr 2011 12:30:24 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by ietfc.amsl.com (Postfix) with SMTP id 6BC41E0723 for ; Mon, 18 Apr 2011 12:30:24 -0700 (PDT) Received: (qmail 22461 invoked by uid 0); 18 Apr 2011 19:23:44 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 18 Apr 2011 19:23:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=c1b99aOCyQh/mUfnGhSQ3wB4EbgeCEIyMT7YDinPDB7NtS5+LVdoRvAD2UJMWDl0nkK5oC5XxvI80P1srtzjYPrDoZ9BWiWsFGUQVoJJa5MEEDct5VQk8dTir2IK899V; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QBu2y-0002mP-CA; Mon, 18 Apr 2011 13:23:44 -0600 Message-ID: <4DAC8FB7.2080603@labn.net> Date: Mon, 18 Apr 2011 15:23:35 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: mpls@ietf.org, ospf@ietf.org, isis-wg@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [OSPF] Fwd: 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:30:25 -0000 The enclosed last call is taking place in CCAMP. Please send any comments to ccamp@ietf.org. Thank you, Lou -------- Original Message -------- Subject: 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib Date: Mon, 18 Apr 2011 15:19:27 -0400 From: Lou Berger To: CCAMP This mail begins a 2nd WG last call on: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08 The draft has been updated after the earlier working group primarily based on MIB Dr. review and discussion on the ccamp list. This working group last call ends on May 2nd. This LC will be announced on the MPLS, OSPF, and ISIS WG lists. Please send comments to the CCAMP mailing list. Lou (and Deborah) From acee.lindem@ericsson.com Mon Apr 18 14:01:58 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D7DFE08A8 for ; Mon, 18 Apr 2011 14:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.62 X-Spam-Level: X-Spam-Status: No, score=-5.62 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQTWgGiPUJvJ for ; Mon, 18 Apr 2011 14:01:57 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id D36E1E0883 for ; Mon, 18 Apr 2011 14:01:57 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3IL1rj6030116 for ; Mon, 18 Apr 2011 16:01:57 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 18 Apr 2011 17:01:55 -0400 From: Acee Lindem To: OSPF WG List Date: Mon, 18 Apr 2011 17:01:53 -0400 Thread-Topic: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib Thread-Index: Acv+C9i1umuNZyPASwi+5gElENdJnA== Message-ID: References: <4DAC8EBF.6080400@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] Fwd: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:01:58 -0000 FYI for those not subscribed to the CCAMP mailing list - Please consider re= viewing this draft if you are involved with Traffic Engineering. Thanks, Acee Begin forwarded message: From: Lou Berger > Date: April 18, 2011 3:19:27 PM EDT To: CCAMP > Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib This mail begins a 2nd WG last call on: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08 The draft has been updated after the earlier working group primarily based on MIB Dr. review and discussion on the ccamp list. This working group last call ends on May 2nd. This LC will be announced on the MPLS, OSPF, and ISIS WG lists. Please send comments to the CCAMP mailing list. Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From acee.lindem@ericsson.com Mon Apr 18 14:04:54 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 03BEDE08B7 for ; Mon, 18 Apr 2011 14:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.674 X-Spam-Level: X-Spam-Status: No, score=-5.674 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-5WQEW9v06F for ; Mon, 18 Apr 2011 14:04:53 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id E791CE08AF for ; Mon, 18 Apr 2011 14:04:52 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3IL4nP6030589 for ; Mon, 18 Apr 2011 16:04:52 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 18 Apr 2011 17:04:50 -0400 From: Acee Lindem To: OSPF WG List Date: Mon, 18 Apr 2011 17:04:48 -0400 Thread-Topic: [OSPF] Fwd: 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib Thread-Index: Acv+DEETExGE9H3UQ4O7Gcf+ECMnoQ== Message-ID: References: <4DAC8FB7.2080603@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] Fwd: Fwd: 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:04:54 -0000 I didn't know this was coming... I guess sometimes great minds do think ali= ke :^) Acee Begin forwarded message: From: Lou Berger > Date: April 18, 2011 3:23:35 PM EDT To: "mpls@ietf.org" >, "ospf@ietf.org" >, "isis-wg@ietf.org" > Subject: [OSPF] Fwd: 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib The enclosed last call is taking place in CCAMP. Please send any comments to ccamp@ietf.org. Thank you, Lou -------- Original Message -------- Subject: 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib Date: Mon, 18 Apr 2011 15:19:27 -0400 From: Lou Berger > To: CCAMP > This mail begins a 2nd WG last call on: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08 The draft has been updated after the earlier working group primarily based on MIB Dr. review and discussion on the ccamp list. This working group last call ends on May 2nd. This LC will be announced on the MPLS, OSPF, and ISIS WG lists. Please send comments to the CCAMP mailing list. Lou (and Deborah) _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From wenhu.lu@ericsson.com Mon Apr 18 14:55:47 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8DA86E077C for ; Mon, 18 Apr 2011 14:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[AWL=1.901, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JmPgHulazOY for ; Mon, 18 Apr 2011 14:55:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id E5FF3E075C for ; Mon, 18 Apr 2011 14:55:46 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3ILtj8w005883 for ; Mon, 18 Apr 2011 16:55:47 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.159]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 18 Apr 2011 17:55:39 -0400 From: Wenhu Lu To: OSPF WG List Date: Mon, 18 Apr 2011 17:55:39 -0400 Thread-Topic: [OSPF] Fwd: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib Thread-Index: Acv+C9i1umuNZyPASwi+5gElENdJnAAAx2Xw Message-ID: <8249B703AE8442429AF89B86E8206AA26F3A395788@EUSAACMS0703.eamcs.ericsson.se> References: <4DAC8EBF.6080400@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] Fwd: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:55:47 -0000 Page 7: TedAreaIdTC has SYNTAX Unsigned32. For ISIS, the area address is of variable length. Please refer to ISO 10589= 2002 Figure 4 on page 16 and change the SYNTAX accordingly. Similar comments for TedRouterIdTC, TedLinkStateIdTC when applied to ISIS. Also it looks like the REFERENCE only cites OSPFv2 and OSPFv3. Thanks, -wenhu -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Monday, April 18, 2011 2:02 PM To: OSPF WG List Subject: [OSPF] Fwd: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted= -mib FYI for those not subscribed to the CCAMP mailing list - Please consider re= viewing this draft if you are involved with Traffic Engineering. Thanks, Acee Begin forwarded message: From: Lou Berger > Date: April 18, 2011 3:19:27 PM EDT To: CCAMP > Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib This mail begins a 2nd WG last call on: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08 The draft has been updated after the earlier working group primarily based = on MIB Dr. review and discussion on the ccamp list. This working group last call ends on May 2nd. This LC will be announced on = the MPLS, OSPF, and ISIS WG lists. Please send comments to the CCAMP maili= ng list. Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From lberger@labn.net Tue Apr 19 05:18:21 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F3257E00BE for ; Tue, 19 Apr 2011 05:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.175 X-Spam-Level: X-Spam-Status: No, score=-102.175 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aaHJmFzXUjF for ; Tue, 19 Apr 2011 05:18:20 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by ietfc.amsl.com (Postfix) with SMTP id 12227E06E0 for ; Tue, 19 Apr 2011 05:18:15 -0700 (PDT) Received: (qmail 32734 invoked by uid 0); 19 Apr 2011 12:18:15 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 19 Apr 2011 12:18:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=xrcwAfR87kI+cr8uxnmTblmznTGfHWLl74XwU2N7XoIonL/x4OgZsoFPU1iQsgtiXZVWpDLmYgtOyXtkWk343WUKZG+CNA0oVQW0TjZP/rB2bX/CIaIRIMUviVgClfwx; Received: from localhost ([127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QC9sk-0002uk-9R; Tue, 19 Apr 2011 06:18:15 -0600 Message-ID: <4DAD7D74.5080903@labn.net> Date: Tue, 19 Apr 2011 08:17:56 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: draft-ietf-ccamp-gmpls-ted-mib@tools.ietf.org References: <4DAC8EBF.6080400@labn.net> <8249B703AE8442429AF89B86E8206AA26F3A395788@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <8249B703AE8442429AF89B86E8206AA26F3A395788@EUSAACMS0703.eamcs.ericsson.se> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.mobi} {sentby:program running on server} Cc: OSPF WG List , CCAMP Subject: Re: [OSPF] Fwd: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:18:21 -0000 Authors, Please treat this as a LC comment. Please send replies/follow-ups to ccamp (and Wenhu) only. (OSPF cc'ed on this message so they may know where the conversation has moved.) Much thanks, Lou On 4/18/2011 5:55 PM, Wenhu Lu wrote: > Page 7: > TedAreaIdTC has SYNTAX Unsigned32. > For ISIS, the area address is of variable length. Please refer to ISO 10589 2002 Figure 4 on page 16 and change the SYNTAX accordingly. > > Similar comments for TedRouterIdTC, TedLinkStateIdTC when applied to ISIS. > Also it looks like the REFERENCE only cites OSPFv2 and OSPFv3. > > Thanks, > -wenhu > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > Sent: Monday, April 18, 2011 2:02 PM > To: OSPF WG List > Subject: [OSPF] Fwd: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib > > FYI for those not subscribed to the CCAMP mailing list - Please consider reviewing this draft if you are involved with Traffic Engineering. > Thanks, > Acee > > Begin forwarded message: > > From: Lou Berger > > Date: April 18, 2011 3:19:27 PM EDT > To: CCAMP > > Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib > > This mail begins a 2nd WG last call on: > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08 > > The draft has been updated after the earlier working group primarily based on MIB Dr. review and discussion on the ccamp list. > > This working group last call ends on May 2nd. This LC will be announced on the MPLS, OSPF, and ISIS WG lists. Please send comments to the CCAMP mailing list. > > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > > From ma-miyazawa@kddilabs.jp Thu Apr 21 17:51:19 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25066E0766; Thu, 21 Apr 2011 17:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9tM8Y9gaLi3; Thu, 21 Apr 2011 17:51:18 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfc.amsl.com (Postfix) with ESMTP id 5F4D9E074B; Thu, 21 Apr 2011 17:50:53 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id BD05D17481F7; Fri, 22 Apr 2011 09:50:51 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcjLnI5B2E11; Fri, 22 Apr 2011 09:50:51 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6A12E17481C0; Fri, 22 Apr 2011 09:50:51 +0900 (JST) Received: from miyazawaPC (dhcp228.wlan.kddilabs.jp [172.19.110.228]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id 5A4DA1E0002; Fri, 22 Apr 2011 09:50:51 +0900 (JST) From: "Masanori Miyazawa" To: References: <4DAC8EBF.6080400@labn.net> <8249B703AE8442429AF89B86E8206AA26F3A395788@EUSAACMS0703.eamcs.ericsson.se> <4DAD7D74.5080903@labn.net> In-Reply-To: <4DAD7D74.5080903@labn.net> Date: Fri, 22 Apr 2011 09:50:53 +0900 Message-ID: <006301cc0087$554d0e40$ffe72ac0$@jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+jBO5v3rCpeJQQJeB5Z6GOZsjowB+sQ4Q Content-Language: ja Cc: 'OSPF WG List' , 'CCAMP' , draft-ietf-ccamp-gmpls-ted-mib@tools.ietf.org Subject: Re: [OSPF] Fwd: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 00:51:19 -0000 Hi, Wenhu, Thank you for your comments. I agree the SYNTAX of TCs should be updated to take into account IS-IS, so, I think it will be changed to Octet String (O..20). Also, the Reference will be revised to include ISIS. Thank you, Masanori > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Lou Berger > Sent: Tuesday, April 19, 2011 9:18 PM > To: draft-ietf-ccamp-gmpls-ted-mib@tools.ietf.org > Cc: OSPF WG List; CCAMP > Subject: Re: [OSPF] Fwd: [CCAMP] 2nd WG last call on > draft-ietf-ccamp-gmpls-ted-mib > > Authors, > Please treat this as a LC comment. > > Please send replies/follow-ups to ccamp (and Wenhu) only. (OSPF cc'ed on > this message so they may know where the conversation has moved.) > > Much thanks, > Lou > > On 4/18/2011 5:55 PM, Wenhu Lu wrote: > > Page 7: > > TedAreaIdTC has SYNTAX Unsigned32. > > For ISIS, the area address is of variable length. Please refer to ISO > 10589 2002 Figure 4 on page 16 and change the SYNTAX accordingly. > > > > Similar comments for TedRouterIdTC, TedLinkStateIdTC when applied to > ISIS. > > Also it looks like the REFERENCE only cites OSPFv2 and OSPFv3. > > > > Thanks, > > -wenhu > > > > -----Original Message----- > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Acee Lindem > > Sent: Monday, April 18, 2011 2:02 PM > > To: OSPF WG List > > Subject: [OSPF] Fwd: [CCAMP] 2nd WG last call on > draft-ietf-ccamp-gmpls-ted-mib > > > > FYI for those not subscribed to the CCAMP mailing list - Please consider > reviewing this draft if you are involved with Traffic Engineering. > > Thanks, > > Acee > > > > Begin forwarded message: > > > > From: Lou Berger > > > Date: April 18, 2011 3:19:27 PM EDT > > To: CCAMP > > > Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib > > > > This mail begins a 2nd WG last call on: > > > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08 > > > > The draft has been updated after the earlier working group primarily based > on MIB Dr. review and discussion on the ccamp list. > > > > This working group last call ends on May 2nd. This LC will be announced > on the MPLS, OSPF, and ISIS WG lists. Please send comments to the CCAMP > mailing list. > > > > Lou (and Deborah) > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From vladica.stanisic@ericsson.com Mon Apr 25 08:01:56 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F795E06F5 for ; Mon, 25 Apr 2011 08:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQZQxCIYcs5X for ; Mon, 25 Apr 2011 08:01:56 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id E10E7E0682 for ; Mon, 25 Apr 2011 08:01:55 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3PF1sC0006471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Apr 2011 10:01:55 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 25 Apr 2011 11:01:54 -0400 From: Vladica Stanisic To: "ospf@ietf.org" Date: Mon, 25 Apr 2011 11:01:53 -0400 Thread-Topic: Error in description of the MIB objects ospfVirtNbrEvents and ospfv3VirtNbrEvents in RFCs 4750 and 5643 Thread-Index: AcwDWRa+rbo9aajoTBGlwfN2Lae5fAAAJObg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFA917582FF6524F94AB504C6DC3F16DBD286CEE0BEUSAACMS0702e_" MIME-Version: 1.0 Cc: Shukri Abdallah , Athanasios Kyparlis Subject: Re: [OSPF] Error in description of the MIB objects ospfVirtNbrEvents and ospfv3VirtNbrEvents in RFCs 4750 and 5643 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 15:01:56 -0000 --_000_FFA917582FF6524F94AB504C6DC3F16DBD286CEE0BEUSAACMS0702e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe there is an error in the description of the MIB objects ospfVirtN= brEvents and ospfv3VirtNbrEvents in RFCs 4750 and 5643 Description The number of times this virtual link has changed its state or an error has= occurred should be The number of times this virtual neighbor has changed its state or an error= has occurred Regards Vladica Stanisic --_000_FFA917582FF6524F94AB504C6DC3F16DBD286CEE0BEUSAACMS0702e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I believe= there is=20 an error in the description of the MIB objects ospfVirtNbrEvents and=20 ospfv3VirtNbrEvents in RFCs 4750 and 5643
 
Descripti= on=20
 
The= number of=20 times this virtual link has changed= its=20 state or an error has occurred
 
sho= uld be=20
 
The= number of=20 times this virtual neighbor has cha= nged=20 its state or an error has occurred
 
Regards
 
Vladica=20 Stanisic
--_000_FFA917582FF6524F94AB504C6DC3F16DBD286CEE0BEUSAACMS0702e_-- From acee.lindem@ericsson.com Mon Apr 25 09:22:12 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DBF6DE0766 for ; Mon, 25 Apr 2011 09:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3blqOjJ5gBI for ; Mon, 25 Apr 2011 09:22:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 3FACDE0765 for ; Mon, 25 Apr 2011 09:22:12 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3PGMAfX017147 for ; Mon, 25 Apr 2011 11:22:12 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 25 Apr 2011 12:22:05 -0400 From: Acee Lindem To: Vladica Stanisic Date: Mon, 25 Apr 2011 12:22:02 -0400 Thread-Topic: [OSPF] Error in description of the MIB objects ospfVirtNbrEvents and ospfv3VirtNbrEvents in RFCs 4750 and 5643 Thread-Index: AcwDZOobDtngpajvRPuOzkOKYb/Bew== Message-ID: <08B66694-D1F4-4889-9276-D8A85DCA7F4F@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-13--976192029"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Shukri Abdallah , "ospf@ietf.org" , Athanasios Kyparlis Subject: Re: [OSPF] Error in description of the MIB objects ospfVirtNbrEvents and ospfv3VirtNbrEvents in RFCs 4750 and 5643 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:22:13 -0000 --Apple-Mail-13--976192029 Content-Type: multipart/alternative; boundary=Apple-Mail-12--976192046 --Apple-Mail-12--976192046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Vladica, I agree that this has always been incorrect. It is interesting that = nobody has complained.=20 You could issue errata for both RFCs.=20 http://www.rfc-editor.org/errata.php Thanks, Acee On Apr 25, 2011, at 11:01 AM, Vladica Stanisic wrote: > I believe there is an error in the description of the MIB objects = ospfVirtNbrEvents and ospfv3VirtNbrEvents in RFCs 4750 and 5643 > =20 > Description > =20 > The number of times this virtual link has changed its state or an = error has occurred > =20 > should be > =20 > The number of times this virtual neighbor has changed its state or an = error has occurred > =20 > Regards > =20 > Vladica Stanisic > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-12--976192046 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Hi Vladica,

I agree that this has always been incorrect. It is interesting that nobody has complained. 

You could issue errata for both RFCs. 

http://www.rfc-editor.org/errata.php

Thanks,
Acee

On Apr 25, 2011, at 11:01 AM, Vladica Stanisic wrote:

I believe there is an error in the description of the MIB objects ospfVirtNbrEvents and ospfv3VirtNbrEvents in RFCs 4750 and 5643
 
Description
 
The number of times this virtual link has changed its state or an error has occurred
 
should be
 
The number of times this virtual neighbor has changed its state or an error has occurred
 
Regards
 
Vladica Stanisic
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

--Apple-Mail-12--976192046-- --Apple-Mail-13--976192029 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQyNTE2MjIwMlowIwYJKoZI hvcNAQkEMRYEFL4bFvBcTMx75NI5nKb6iFHiCLGdMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgHgmo/ZvgXMJD5fba41JIExuFxvkS6uvsCrV8qWSoY5+7KLKbpLyW8SBe974NQxu 7vys0ZqAYicodL9M8oPWFbstxeOBP0Nun2Rl9LcsnPGZiaKYTPshf1g23+og69dP7g8Anmt7ehvb C31dRGlHd6kKpQAjgOBJOyYuIDKVWxUNAAAAAAAA --Apple-Mail-13--976192029-- From wwwrun@rfc-editor.org Mon Apr 25 10:22:06 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7B40E06E1 for ; Mon, 25 Apr 2011 10:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7YWiyG275DC for ; Mon, 25 Apr 2011 10:22:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfc.amsl.com (Postfix) with ESMTP id E3725E06AE for ; Mon, 25 Apr 2011 10:22:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3060EE076E; Mon, 25 Apr 2011 10:22:05 -0700 (PDT) To: djoyal@nortel.com, pgalecki@airvana.com, spencer.giacalone@gmail.com, fred@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, acee.lindem@ericsson.com, akr@cisco.com From: RFC Errata System Message-Id: <20110425172205.3060EE076E@rfc-editor.org> Date: Mon, 25 Apr 2011 10:22:05 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC4750 (2788) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 17:22:06 -0000 The following errata report has been submitted for RFC4750, "OSPF Version 2 Management Information Base". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4750&eid=2788 -------------------------------------- Type: Editorial Reported by: Vladica Stanisic Section: 3 Original Text ------------- ospfVirtNbrEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this virtual link has changed its state or an error has occurred. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfVirtNbrEntry 6 } Corrected Text -------------- ospfVirtNbrEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this virtual neighbor has changed its state or an error has occurred. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfVirtNbrEntry 6 } Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4750 (draft-ietf-ospf-mib-update-11) -------------------------------------- Title : OSPF Version 2 Management Information Base Publication Date : December 2006 Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R. Coltun, F. Baker Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Apr 25 10:24:13 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6651EE06AE for ; Mon, 25 Apr 2011 10:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.331 X-Spam-Level: X-Spam-Status: No, score=-102.331 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Be10WFeFHMY for ; Mon, 25 Apr 2011 10:24:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfc.amsl.com (Postfix) with ESMTP id 176EAE0699 for ; Mon, 25 Apr 2011 10:24:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A429DE076D; Mon, 25 Apr 2011 10:24:11 -0700 (PDT) To: djoyal@nortel.com, vishwas@ipinfusion.com, stbryant@cisco.com, adrian@olddog.co.uk, acee.lindem@ericsson.com, akr@cisco.com From: RFC Errata System Message-Id: <20110425172411.A429DE076D@rfc-editor.org> Date: Mon, 25 Apr 2011 10:24:11 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC5643 (2789) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 17:24:13 -0000 The following errata report has been submitted for RFC5643, "Management Information Base for OSPFv3". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5643&eid=2789 -------------------------------------- Type: Editorial Reported by: Vladica Stanisic Section: 5 Original Text ------------- ospfv3VirtNbrEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this virtual link has changed its state or an error has occurred. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3VirtNbrEntry 9 } Corrected Text -------------- ospfv3VirtNbrEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this virtual neighbor has changed its state or an error has occurred. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3VirtNbrEntry 9 } Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5643 (draft-ietf-ospf-ospfv3-mib-15) -------------------------------------- Title : Management Information Base for OSPFv3 Publication Date : August 2009 Author(s) : D. Joyal, Ed., V. Manral, Ed. Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From vishwas.ietf@gmail.com Mon Apr 25 10:35:16 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6FA25E076A for ; Mon, 25 Apr 2011 10:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6WPlcjpuYiT for ; Mon, 25 Apr 2011 10:35:15 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 891B9E075B for ; Mon, 25 Apr 2011 10:35:15 -0700 (PDT) Received: by vws12 with SMTP id 12so2372454vws.31 for ; Mon, 25 Apr 2011 10:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TnC9io5B0GYdtCqheogEUU63uOiJk7d3alLSK4m54Po=; b=lcVWgAmjX7eAxkc/UPXIkK7RsHGy03XazDMJd355vHpRWTaGg086cyMi4pkA1FoDJp X404X4nh42T8xl3P72hS+l8Q4F/3o1HA6BQo4+5qQGi2ezT692e9QaCJwJ05MeOmd60G Zuj+nF+wel9bLPw+If82EI5QrY6fAtpkQMbYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n2OBkPCNd0Jk58O1D/gGoH63B4Jr1w683wwZKSMB1/Vhz0DPfqpbJRno/D8I5kIsMY xW6yohRUrLE3jxNN59k5L1whn6cPJIJC1x31v198+31Evygq5grz+fQPSbbW6Fxv+eo2 QILJONW213U3vW9GqdLzBiEGaFh3Ougao5dvY= MIME-Version: 1.0 Received: by 10.52.97.227 with SMTP id ed3mr4353011vdb.295.1303752914083; Mon, 25 Apr 2011 10:35:14 -0700 (PDT) Received: by 10.52.186.199 with HTTP; Mon, 25 Apr 2011 10:35:14 -0700 (PDT) In-Reply-To: <20110425172411.A429DE076D@rfc-editor.org> References: <20110425172411.A429DE076D@rfc-editor.org> Date: Mon, 25 Apr 2011 10:35:14 -0700 Message-ID: From: Vishwas Manral To: RFC Errata System Content-Type: multipart/alternative; boundary=20cf307abeed51a0f604a1c1a125 Cc: vishwas@ipinfusion.com, djoyal@nortel.com, ospf@ietf.org Subject: Re: [OSPF] [Editorial Errata Reported] RFC5643 (2789) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 17:35:16 -0000 --20cf307abeed51a0f604a1c1a125 Content-Type: text/plain; charset=ISO-8859-1 Hi RFC-Editor, Looks good to me. Approve. Thanks, Vishwas On Mon, Apr 25, 2011 at 10:24 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC5643, > "Management Information Base for OSPFv3". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5643&eid=2789 > > -------------------------------------- > Type: Editorial > Reported by: Vladica Stanisic > > Section: 5 > > Original Text > ------------- > ospfv3VirtNbrEvents OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times this virtual link has > changed its state or an error has occurred. > Discontinuities in the value of this counter > can occur at re-initialization of the management > system and at other times as indicated by the > value of ospfv3DiscontinuityTime." > ::= { ospfv3VirtNbrEntry 9 } > > Corrected Text > -------------- > ospfv3VirtNbrEvents OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times this virtual neighbor has > changed its state or an error has occurred. > Discontinuities in the value of this counter > can occur at re-initialization of the management > system and at other times as indicated by the > value of ospfv3DiscontinuityTime." > ::= { ospfv3VirtNbrEntry 9 } > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5643 (draft-ietf-ospf-ospfv3-mib-15) > -------------------------------------- > Title : Management Information Base for OSPFv3 > Publication Date : August 2009 > Author(s) : D. Joyal, Ed., V. Manral, Ed. > Category : PROPOSED STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --20cf307abeed51a0f604a1c1a125 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi RFC-Editor,
=A0
Looks good to me.=A0Approve.
=A0
Thanks,
Vishwas
On Mon, Apr 25, 2011 at 10:24 AM, RFC Errata Sys= tem <rfc-= editor@rfc-editor.org> wrote:

The following errata report = has been submitted for RFC5643,
"Management Information Base for OS= PFv3".

--------------------------------------
You may review the report bel= ow and at:
http://www.rfc-editor.org/errata_sea= rch.php?rfc=3D5643&eid=3D2789

--------------------------------------
Type: Editorial
Reported b= y: Vladica Stanisic <vl= adica.stanisic@ericsson.com>

Section: 5

Original Text<= br> -------------
ospfv3VirtNbrEvents OBJECT-TYPE
SYNTAX Counter32
MAX= -ACCESS read-only
STATUS current
DESCRIPTION
"The number of t= imes this virtual link has
changed its state or an error has occurred. Discontinuities in the value of this counter
can occur at re-initializat= ion of the management
system and at other times as indicated by the
v= alue of ospfv3DiscontinuityTime."
::=3D { ospfv3VirtNbrEntry 9 }
Corrected Text
--------------
ospfv3VirtNbrEvents OBJECT-TYPE
= SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION"The number of times this virtual neighbor has
changed its state = or an error has occurred.
Discontinuities in the value of this counter
can occur at re-initializat= ion of the management
system and at other times as indicated by the
v= alue of ospfv3DiscontinuityTime."
::=3D { ospfv3VirtNbrEntry 9 }
Notes
-----


Instructions:
-------------
This errata= is currently posted as "Reported". If necessary, please
use &= quot;Reply All" to discuss whether it should be verified or
rejecte= d. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

-= -------------------------------------
RFC5643 (draft-ietf-ospf-ospfv3-mi= b-15)
--------------------------------------
Title =A0 =A0 =A0 =A0 = =A0 =A0 =A0 : Management Information Base for OSPFv3
Publication Date =A0 =A0: August 2009
Author(s) =A0 =A0 =A0 =A0 =A0 : D.= Joyal, Ed., V. Manral, Ed.
Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED S= TANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Open Shortest Path First IGP=
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG<= br>_______________________________________________
OSPF mailing list
= OSPF@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ospf

--20cf307abeed51a0f604a1c1a125-- From acee.lindem@ericsson.com Mon Apr 25 12:16:45 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EEADDE0717 for ; Mon, 25 Apr 2011 12:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.832, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK2lZfq6Pjwu for ; Mon, 25 Apr 2011 12:16:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 4B34AE06BB for ; Mon, 25 Apr 2011 12:16:45 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3PJGd1i026308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Apr 2011 14:16:39 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 25 Apr 2011 15:16:38 -0400 From: Acee Lindem To: RFC Errata System Date: Mon, 25 Apr 2011 15:16:35 -0400 Thread-Topic: [Editorial Errata Reported] RFC4750 (2788) Thread-Index: AcwDfUxCUz79auAeQf27p7hUWmBHAw== Message-ID: <4CC4DAD3-2A9E-431C-87AA-71C485FCF29C@ericsson.com> References: <20110425172205.3060EE076E@rfc-editor.org> In-Reply-To: <20110425172205.3060EE076E@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pgalecki@airvana.com" , "djoyal@nortel.com" , "ospf@ietf.org" Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (2788) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 19:16:46 -0000 Approve.=20 Acee=20 On Apr 25, 2011, at 1:22 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC4750, > "OSPF Version 2 Management Information Base". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4750&eid=3D2788 >=20 > -------------------------------------- > Type: Editorial > Reported by: Vladica Stanisic >=20 > Section: 3 >=20 > Original Text > ------------- > ospfVirtNbrEvents OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times this virtual link has > changed its state or an error has occurred. > Discontinuities in the value of this counter can occur > at re-initialization of the management system, and at other > times as indicated by the value of ospfDiscontinuityTime." > ::=3D { ospfVirtNbrEntry 6 } >=20 > Corrected Text > -------------- > ospfVirtNbrEvents OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times this virtual neighbor has > changed its state or an error has occurred. > Discontinuities in the value of this counter can occur > at re-initialization of the management system, and at other > times as indicated by the value of ospfDiscontinuityTime." > ::=3D { ospfVirtNbrEntry 6 } >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4750 (draft-ietf-ospf-mib-update-11) > -------------------------------------- > Title : OSPF Version 2 Management Information Base > Publication Date : December 2006 > Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., = R. Coltun, F. Baker > Category : PROPOSED STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG From acee.lindem@ericsson.com Mon Apr 25 12:16:53 2011 Return-Path: X-Original-To: ospf@ietfc.amsl.com Delivered-To: ospf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 99B22E0700 for ; Mon, 25 Apr 2011 12:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.806 X-Spam-Level: X-Spam-Status: No, score=-5.806 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKd15zQID2GB for ; Mon, 25 Apr 2011 12:16:53 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id DDA04E06FD for ; Mon, 25 Apr 2011 12:16:52 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3PJGoNJ026334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Apr 2011 14:16:51 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 25 Apr 2011 15:16:50 -0400 From: Acee Lindem To: RFC Errata System Date: Mon, 25 Apr 2011 15:16:49 -0400 Thread-Topic: [Editorial Errata Reported] RFC5643 (2789) Thread-Index: AcwDfVPSeGR7YacvS3Co/ALnYzrXsg== Message-ID: <86974367-059B-4E3A-89A9-AA996693B77A@ericsson.com> References: <20110425172411.A429DE076D@rfc-editor.org> In-Reply-To: <20110425172411.A429DE076D@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Vishwas Manral , "djoyal@nortel.com" , "ospf@ietf.org" Subject: Re: [OSPF] [Editorial Errata Reported] RFC5643 (2789) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 19:16:53 -0000 Approve. Acee On Apr 25, 2011, at 1:24 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5643, > "Management Information Base for OSPFv3". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5643&eid=3D2789 >=20 > -------------------------------------- > Type: Editorial > Reported by: Vladica Stanisic >=20 > Section: 5 >=20 > Original Text > ------------- > ospfv3VirtNbrEvents OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times this virtual link has > changed its state or an error has occurred. > Discontinuities in the value of this counter > can occur at re-initialization of the management > system and at other times as indicated by the > value of ospfv3DiscontinuityTime." > ::=3D { ospfv3VirtNbrEntry 9 } >=20 > Corrected Text > -------------- > ospfv3VirtNbrEvents OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times this virtual neighbor has > changed its state or an error has occurred. > Discontinuities in the value of this counter > can occur at re-initialization of the management > system and at other times as indicated by the > value of ospfv3DiscontinuityTime." > ::=3D { ospfv3VirtNbrEntry 9 } >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5643 (draft-ietf-ospf-ospfv3-mib-15) > -------------------------------------- > Title : Management Information Base for OSPFv3 > Publication Date : August 2009 > Author(s) : D. Joyal, Ed., V. Manral, Ed. > Category : PROPOSED STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG From akr@cisco.com Wed Apr 27 08:47:35 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83B9E06CE for ; Wed, 27 Apr 2011 08:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+pz0ODsVeqj for ; Wed, 27 Apr 2011 08:47:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2A44BE07E9 for ; Wed, 27 Apr 2011 08:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akr@cisco.com; l=523; q=dns/txt; s=iport; t=1303919255; x=1305128855; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oQfaZsFzN4welVy3K0+nQCjsdTSQ5oz7F/hzEF9wX2A=; b=d7a9Lb+qkCuB730yel8S42yH52tTeVF2uQrLwesf0d12JON9VmEGlVQS NBB+RnADq+8oXltlQYdBfGohIuQoMlcFbIfaSbKIUtZV9JFkn8czstqqF CNa6uTP/bF2xYsXovweoubUpWLsyqlpBQc8bVs7EuUPynkkfr5mSkJaip c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKI5uE2rRDoG/2dsb2JhbAClbHemeJx6hXYEhgOITo5M X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="scan'208";a="437445270" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2011 15:47:34 +0000 Received: from sjc-vpn3-1328.cisco.com (sjc-vpn3-1328.cisco.com [10.21.69.48]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3RFlYLf028522; Wed, 27 Apr 2011 15:47:34 GMT Message-ID: <4DB83A96.80104@cisco.com> Date: Wed, 27 Apr 2011 08:47:34 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Acee Lindem References: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> In-Reply-To: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OSPF WG List , Sam Hartman Subject: Re: [OSPF] Security Extension for OSPFv2 when using Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:47:35 -0000 There has been multiple support and no opposition for this draft. We will make this a WG draft.. Regards, -Abhay On 4/11/11 10:18 AM, Acee Lindem wrote: > There was general agreement that this should be a WG document at the meeting in Prague. Please indicate your position on making this draft a WG document with intended status Proposed Standard. > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From akr@cisco.com Wed Apr 27 08:54:27 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D40E06DA for ; Wed, 27 Apr 2011 08:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVx6cNaDN9HT for ; Wed, 27 Apr 2011 08:54:26 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB571E0718 for ; Wed, 27 Apr 2011 08:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akr@cisco.com; l=6661; q=dns/txt; s=iport; t=1303919665; x=1305129265; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=LN+yItF7Z00NnaF6T71Tl4fHIklKcfb8IHG82j1BJLs=; b=aLatTx142I+YC9/6Mdh0ZBEinJXCPpOM08hOyEIwgtKZ5UV6fpx/wyEM 3Y560JKtYG+s5pnhKFLWGfC8FVgPWYtgioa0hi2KGfEOsaZHeUPfUMNq1 uQpSSjBMY6C1dsVjEDpJKl6YndOOn6IcyuFzzjydeB917/pfctyIFY/JV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAI7uE2rRDoG/2dsb2JhbAClbHemdJx6hXYEhgOITo5M X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="scan'208,217";a="303234508" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2011 15:54:21 +0000 Received: from sjc-vpn3-1328.cisco.com (sjc-vpn3-1328.cisco.com [10.21.69.48]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3RFsKd1004952 for ; Wed, 27 Apr 2011 15:54:20 GMT Message-ID: <4DB83C2C.6000404@cisco.com> Date: Wed, 27 Apr 2011 08:54:20 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: "ospf@ietf.org" References: <4DA329FE.4050108@cisco.com> In-Reply-To: <4DA329FE.4050108@cisco.com> Content-Type: multipart/alternative; boundary="------------030507070002050008020300" Subject: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:54:27 -0000 This is a multi-part message in MIME format. --------------030507070002050008020300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There has been much discussion on the list, and one significant change was made to -03 version. Cryptographic Sequence Number has changed from 32 bit to 64 bits. We would like to extend the Last Call till 5pm PST, May 9th 2011. Please review the changes from 03 -> 04 version. Diff can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-auth-trailer-ospfv3-04.txt -Abhay/Acee On 4/11/11 9:19 AM, Abhay Roy wrote: > We are starting the Working Group Last Call of this revision of the > subject draft. > > This drafts is intended to be a Proposed Standard. The OSPF WG last call > will begin today and will end at 5pm PST, April 25th, 2011. > > Abhay/Acee > > -------- Original Message -------- > Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt > Date: Sat, 19 Feb 2011 12:00:02 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: ospf@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > > Title : Supporting Authentication Trailer for OSPFv3 > Author(s) : M. Bhatia, et al. > Filename : draft-ietf-ospf-auth-trailer-ospfv3-03.txt > Pages : 20 > Date : 2011-02-19 > > Currently OSPFv3 uses IPsec for authenticating protocol packets. > However, there are some environments, e.g., Mobile Ad-hoc Networks > (MANETs), where IPsec is difficult to configure and maintain, and > this mechanism cannot be used. This draft proposes an alternative > mechanism that can be used so that OSPFv3 does not depend upon IPsec > for authentication. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --------------030507070002050008020300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There has been much discussion on the list, and one significant change was made to -03 version. Cryptographic Sequence Number has changed from 32 bit to 64 bits.

We would like to extend the Last Call till 5pm PST, May 9th 2011.

Please review the changes from 03 -> 04 version. Diff can be found here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-auth-trailer-ospfv3-04.txt

-Abhay/Acee



On 4/11/11 9:19 AM, Abhay Roy wrote:
We are starting the Working Group Last Call of this revision of the subject draft.

This drafts is intended to be a Proposed Standard. The OSPF WG last call
will begin today and will end at 5pm PST,  April 25th, 2011.

Abhay/Acee

-------- Original Message --------
Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt
Date: Sat, 19 Feb 2011 12:00:02 -0800
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: ospf@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.


	Title           : Supporting Authentication Trailer for OSPFv3
	Author(s)       : M. Bhatia, et al.
	Filename        : draft-ietf-ospf-auth-trailer-ospfv3-03.txt
	Pages           : 20
	Date            : 2011-02-19

Currently OSPFv3 uses IPsec for authenticating protocol packets.
However, there are some environments, e.g., Mobile Ad-hoc Networks
(MANETs), where IPsec is difficult to configure and maintain, and
this mechanism cannot be used.  This draft proposes an alternative
mechanism that can be used so that OSPFv3 does not depend upon IPsec
for authentication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------030507070002050008020300-- From jeff.tantsura@ericsson.com Wed Apr 27 09:08:35 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90319E06EC for ; Wed, 27 Apr 2011 09:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=2.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4oWnSNxnpQ5 for ; Wed, 27 Apr 2011 09:08:34 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 807BCE06A3 for ; Wed, 27 Apr 2011 09:08:34 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3RG8JPc002765; Wed, 27 Apr 2011 11:08:33 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Apr 2011 12:08:15 -0400 From: Jeff Tantsura To: Abhay Roy , "ospf@ietf.org" Date: Wed, 27 Apr 2011 12:08:14 -0400 Thread-Topic: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt Thread-Index: AcwE82h5Q/hQx1lpRkiYjRqUWEPz8AAAeN4A Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CABEC57F0@EUSAACMS0701.eamcs.ericsson.se> References: <4DA329FE.4050108@cisco.com> <4DB83C2C.6000404@cisco.com> In-Reply-To: <4DB83C2C.6000404@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0ED867EB33AB2B45AAB470D5A64CDBF60CABEC57F0EUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 16:08:35 -0000 --_000_0ED867EB33AB2B45AAB470D5A64CDBF60CABEC57F0EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Regards, Jeff ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Abh= ay Roy Sent: Wednesday, April 27, 2011 08:54 To: ospf@ietf.org Subject: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trail= er for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt There has been much discussion on the list, and one significant change was = made to -03 version. Cryptographic Sequence Number has changed from 32 bit = to 64 bits. We would like to extend the Last Call till 5pm PST, May 9th 2011. Please review the changes from 03 -> 04 version. Diff can be found here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-auth-trailer-ospfv3-04= .txt -Abhay/Acee On 4/11/11 9:19 AM, Abhay Roy wrote: We are starting the Working Group Last Call of this revision of the subject= draft. This drafts is intended to be a Proposed Standard. The OSPF WG last call will begin today and will end at 5pm PST, April 25th, 2011. Abhay/Acee -------- Original Message -------- Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt Date: Sat, 19 Feb 2011 12:00:02 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ospf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Open Shortest Path First IGP Working Group= of the IETF. Title : Supporting Authentication Trailer for OSPFv3 Author(s) : M. Bhatia, et al. Filename : draft-ietf-ospf-auth-trailer-ospfv3-03.txt Pages : 20 Date : 2011-02-19 Currently OSPFv3 uses IPsec for authenticating protocol packets. However, there are some environments, e.g., Mobile Ad-hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used. This draft proposes an alternative mechanism that can be used so that OSPFv3 does not depend upon IPsec for authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --_000_0ED867EB33AB2B45AAB470D5A64CDBF60CABEC57F0EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support

 

Regards,
Jeff 

From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] = On Behalf Of Abhay Roy
Sent: Wednesday, April 27, 2= 011 08:54
To: ospf@ietf.org
Subject: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt

=  

= There has been much discussion on the list, and = one significant change was made to -03 version. Cryptographic Sequence Number h= as changed from 32 bit to 64 bits.

We would like to extend the Last Call till 5pm PST, May 9th 2011.

Please review the changes from 03 -> 04 version. Diff can be found here:=

http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-auth-tra= iler-ospfv3-04.txt

-Abhay/Acee



On 4/11/11 9:19 AM, Abhay Roy wrote:

= We are starting the Working Group Last Call of t= his revision of the subject draft.

This drafts is intended to be a Proposed Standard. The OSPF WG last call will begin today and will end at 5pm PST,  April 25th, 2011.

Abhay/Acee

-------- Original Message --------

Subject:

Date:

From:

Internet-Drafts@ietf.org

Reply-To:

internet-drafts@ietf.org

To:

i-d-announce@ietf.org=

CC:

ospf@ietf.org

 = 

A New Internet-Draft is available from the on-line Internet-Dr=
afts directories.
This draft is a work item of the Open Shortest Path First IGP Working Gro=
up of the IETF.
 
 
        Title    &=
nbsp;      : Supporting Authentication Trailer for=
 OSPFv3
        Author(s)   &nb=
sp;   : M. Bhatia, et al.
        Filename   &nbs=
p;    : draft-ietf-ospf-auth-trailer-ospfv3-03.txt
        Pages    &=
nbsp;      : 20
        Date    &n= bsp;       : 2011-02-19
 
Currently OSPFv3 uses IPsec for authenticating protocol packets.
However, there are some environments, e.g., Mobile Ad-hoc Networks
(MANETs), where IPsec is difficult to configure and maintain, and
this mechanism cannot be used.  This draft proposes an alternative
mechanism that can be used so that OSPFv3 does not depend upon IPsec=

for authentication.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-=
auth-trailer-ospfv3-03.txt
 
Internet-Drafts are also available by anonymous FTP at:=

ftp://f=
tp.ietf.org/internet-drafts/
 
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
 
 
--_000_0ED867EB33AB2B45AAB470D5A64CDBF60CABEC57F0EUSAACMS0701e_-- From michael_barnes@usa.net Wed Apr 27 12:38:53 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80995E07D0 for ; Wed, 27 Apr 2011 12:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdLyap8vT50t for ; Wed, 27 Apr 2011 12:38:53 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6A1E0803 for ; Wed, 27 Apr 2011 12:38:50 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01-lo [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id 2804A2AC769 for ; Wed, 27 Apr 2011 19:38:49 +0000 (GMT) X-USANET-Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.72B) with ESMTP id 045PDATMt9920M01; Wed, 27 Apr 2011 19:38:45 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from cmsapps02.cms.usa.net [165.212.11.138] by cmsout01.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID085PDATMt9197X01; Wed, 27 Apr 2011 19:38:45 -0000 X-USANET-Source: 165.212.11.138 IN michael_barnes@usa.net cmsapps02.cms.usa.net X-USANET-MsgId: XID085PDATMt9197X01 Received: from web02.cms.usa.net [165.212.8.202] by cmsapps02.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.72B) with ESMTP id 962PDATMt5968M38; Wed, 27 Apr 2011 19:38:45 -0000 X-USANET-Auth: 165.212.8.202 AUTO michael_barnes@usa.net web02.cms.usa.net Received: from 128.107.114.97 [128.107.114.97] by web02.cms.usa.net (USANET web-mailer C8.MAIN.3.73O); Wed, 27 Apr 2011 19:38:45 -0000 Date: Wed, 27 Apr 2011 12:38:45 -0700 From: "Michael Barnes" To: X-Mailer: USANET web-mailer (C8.MAIN.3.73O) Mime-Version: 1.0 Message-ID: <786PDATlt2608S02.1303933125@web02.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID962PDATMt5968X38 Subject: Re: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 19:38:53 -0000 I have no further comments and support this draft to become an RFC. Regards, Michael ------ Original Message ------ Received: Wed, 27 Apr 2011 08:54:36 AM PDT From: Abhay Roy To: "ospf@ietf.org" Subject: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Tra= iler for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt > There has been much discussion on the list, and one significant change = > was made to -03 version. Cryptographic Sequence Number has changed from= = > 32 bit to 64 bits. > = > We would like to extend the Last Call till 5pm PST, May 9th 2011. > = > Please review the changes from 03 -> 04 version. Diff can be found here= : > = > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-auth-trailer-ospfv3-= 04.txt > = > -Abhay/Acee > = > = > = > On 4/11/11 9:19 AM, Abhay Roy wrote: > > We are starting the Working Group Last Call of this revision of the = > > subject draft. > > > > This drafts is intended to be a Proposed Standard. The OSPF WG last c= all > > will begin today and will end at 5pm PST, April 25th, 2011. > > > > Abhay/Acee > > > > -------- Original Message -------- > > Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt > > Date: Sat, 19 Feb 2011 12:00:02 -0800 > > From: Internet-Drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: ospf@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Open Shortest Path First IGP Working= Group of the IETF. > > > > > > Title : Supporting Authentication Trailer for OSPFv3 > > Author(s) : M. Bhatia, et al. > > Filename : draft-ietf-ospf-auth-trailer-ospfv3-03.txt > > Pages : 20 > > Date : 2011-02-19 > > > > Currently OSPFv3 uses IPsec for authenticating protocol packets. > > However, there are some environments, e.g., Mobile Ad-hoc Networks > > (MANETs), where IPsec is difficult to configure and maintain, and > > this mechanism cannot be used. This draft proposes an alternative > > mechanism that can be used so that OSPFv3 does not depend upon IPsec > > for authentication. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-0= 3.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > = > = > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > = From glen.kent@gmail.com Wed Apr 27 17:55:04 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8943E08EE for ; Wed, 27 Apr 2011 17:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnwatsXYzhXy for ; Wed, 27 Apr 2011 17:55:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB599E0800 for ; Wed, 27 Apr 2011 17:55:03 -0700 (PDT) Received: by wyb29 with SMTP id 29so1944446wyb.31 for ; Wed, 27 Apr 2011 17:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BxWFACiRbiqNVZvTAB4uyKE9CtEpHu0WpKvcUf879Rc=; b=a+ZkhDLqvV/YlTl8wjUDxi2SqP7l+BNy8I1ilPBVVLxeFh6uhidB/Co3FneSecafXb MqB0/DqCzwrSpMDpQbfN8WpjTEHa/LhjNcvgHKpfs7akyPT0LeNul8E7L6QZSe00bsVy LP7L9kGLKoTvBT/rGZDKoTAX5M4cUJWc4Bn74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tLFeoNBiz1bWRgTN1Z3JsDB/xpUyCAvUFvIEWYAIzIOBjFBL4CPxjYlhDAHT5C7ila qZlxWBNjoTmN6boke3AoanZrLuj14qSvHNoEarivJ6ZFikFm9JCyPD1/IHYy5F1AVZJe 8Oc0xSdLXvNHR/5GAuYPKx7J21pmvj1t+cgow= MIME-Version: 1.0 Received: by 10.227.32.69 with SMTP id b5mr2855188wbd.99.1303952102845; Wed, 27 Apr 2011 17:55:02 -0700 (PDT) Received: by 10.227.9.34 with HTTP; Wed, 27 Apr 2011 17:55:02 -0700 (PDT) In-Reply-To: <786PDATlt2608S02.1303933125@web02.cms.usa.net> References: <786PDATlt2608S02.1303933125@web02.cms.usa.net> Date: Thu, 28 Apr 2011 06:25:02 +0530 Message-ID: From: Glen Kent To: Michael Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ospf@ietf.org Subject: Re: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 00:55:04 -0000 I think this has been one of the least controversial drafts where everyone in the WG has always supported it. So, if you really need it, then +1 from my side as well. Glen On Thu, Apr 28, 2011 at 1:08 AM, Michael Barnes wr= ote: > I have no further comments and support this draft to become an RFC. > > Regards, > Michael > > ------ Original Message ------ > Received: Wed, 27 Apr 2011 08:54:36 AM PDT > From: Abhay Roy > To: "ospf@ietf.org" > Subject: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Tra= iler > for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt > >> There has been much discussion on the list, and one significant change >> was made to -03 version. Cryptographic Sequence Number has changed from >> 32 bit to 64 bits. >> >> We would like to extend the Last Call till 5pm PST, May 9th 2011. >> >> Please review the changes from 03 -> 04 version. Diff can be found here: >> >> > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-auth-trailer-ospfv3-= 04.txt >> >> -Abhay/Acee >> >> >> >> On 4/11/11 9:19 AM, Abhay Roy wrote: >> > We are starting the Working Group Last Call of this revision of the >> > subject draft. >> > >> > This drafts is intended to be a Proposed Standard. The OSPF WG last ca= ll >> > will begin today and will end at 5pm PST, =A0April 25th, 2011. >> > >> > Abhay/Acee >> > >> > -------- Original Message -------- >> > Subject: =A0 =A0I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt >> > Date: =A0 =A0 =A0 Sat, 19 Feb 2011 12:00:02 -0800 >> > From: =A0 =A0 =A0 Internet-Drafts@ietf.org >> > Reply-To: =A0 internet-drafts@ietf.org >> > To: =A0 =A0 =A0 =A0 i-d-announce@ietf.org >> > CC: =A0 =A0 =A0 =A0 ospf@ietf.org >> > >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> > This draft is a work item of the Open Shortest Path First IGP Working > Group of the IETF. >> > >> > >> > =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Supporting Authentication Trailer = for OSPFv3 >> > =A0 =A0 Author(s) =A0 =A0 =A0 : M. Bhatia, et al. >> > =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-ospf-auth-trailer-ospfv3-= 03.txt >> > =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20 >> > =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-19 >> > >> > Currently OSPFv3 uses IPsec for authenticating protocol packets. >> > However, there are some environments, e.g., Mobile Ad-hoc Networks >> > (MANETs), where IPsec is difficult to configure and maintain, and >> > this mechanism cannot be used. =A0This draft proposes an alternative >> > mechanism that can be used so that OSPFv3 does not depend upon IPsec >> > for authentication. >> > >> > A URL for this Internet-Draft is: >> > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-0= 3.txt >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > Below is the data which will enable a MIME compliant mail reader >> > implementation to automatically retrieve the ASCII version of the >> > Internet-Draft. >> > >> > >> > >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >