From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 2 11:27:37 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24145 for ; Wed, 2 Feb 2005 11:27:35 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F68DB5@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 11:27:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56191442 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 11:27:30 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 2 Feb 2005 11:27:29 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2005 11:37:31 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j12GRRjZ029027 for ; Wed, 2 Feb 2005 11:27:28 -0500 (EST) Received: from [64.102.48.133] (dhcp-64-102-48-133.cisco.com [64.102.48.133]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFA34637; Wed, 2 Feb 2005 08:27:24 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4200FF6C.8060009@cisco.com> Date: Wed, 2 Feb 2005 11:27:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPFv2 Multiple Topology Routing - draft-ietf-ospf-mt-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit We accepted this as a WG document a couple IETFs back. Are there any additional comments ? I know the authors are about to respin the draft. Also, I think this draft is close to ready for WG last call (with the respin comments incorportated). This will probably occur sometime after the March IETF. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 10 16:02:26 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08085 for ; Thu, 10 Feb 2005 16:02:24 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F8040D@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 16:02:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57317647 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 16:02:16 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 15:52:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06299; Thu, 10 Feb 2005 15:52:13 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200502102052.PAA06299@ietf.org> Date: Thu, 10 Feb 2005 15:52:13 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-07.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart 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 : Authentication/Confidentiality for OSPFv3 Author(s) : M. Gupta, N. Melam Filename : draft-ietf-ospf-ospfv3-auth-07.txt Pages : 15 Date : 2005-2-10 This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-auth-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-10155941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-auth-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-10155941.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 11 09:34:18 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01533 for ; Fri, 11 Feb 2005 09:34:17 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F82B97@cherry.ease.lsoft.com>; Fri, 11 Feb 2005 9:34:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57397618 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Feb 2005 09:34:15 -0500 Received: from 32.97.110.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Feb 2005 09:34:14 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1BEYDiK193220 for ; Fri, 11 Feb 2005 09:34:13 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1BEYCvR244192 for ; Fri, 11 Feb 2005 07:34:12 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BEYC4i015069 for ; Fri, 11 Feb 2005 07:34:12 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1BEYCkw015053 for ; Fri, 11 Feb 2005 07:34:12 -0700 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 X-MIMETrack: S/MIME Sign by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 02/11/2005 09:38:01 AM, Serialize by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 02/11/2005 09:38:01 AM, Serialize complete at 02/11/2005 09:38:01 AM, S/MIME Sign failed at 02/11/2005 09:38:01 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/11/2005 07:34:11, Serialize complete at 02/11/2005 07:34:11 Content-Type: multipart/alternative; boundary="=_alternative 0050629885256FA5_=" Message-ID: Date: Fri, 11 Feb 2005 07:34:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Questions about OSPF v3 security draft To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart message in MIME format. --=_alternative 0050629885256FA5_= Content-Type: text/plain; charset="US-ASCII" Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, and the previous drafts, a couple of questions have come up in our shop. 1) Section 7, 2nd paragraph says "the implementations MUST use manually configured keys with same SA for inbound and outbound traffic (as shown in figure 3). I assume the "same SA" MUST rule applies to multicast traffic only and not unicast traffic. This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP address. For unicast addresses, by definition there will be as many SAs as there are unicast destination addresses. Therefore, I don't think it is possible to apply this MUST rule given the current IPSec definition (RFC 2401 section 4.1) of an SA for unicast. Assuming the intention of the draft was to apply only to multicast and given the number of potential SAs carrying unicast traffic, it would seem that using IKE to setup the SAs dynamically would be a reasonable alternative to manual keying. 2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel dynamically once it acquires the required information". Since this traffic is unicast only, IKE could easily set up the required SAs without knowing the specific IP addresses in advance. Creating SAs dynamically do not fit easily within scope of manual SA functional capabilities. Why not use IKE for this traffic? Is this an acceptable option? Mike ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA --=_alternative 0050629885256FA5_= Content-Type: text/html; charset="US-ASCII"
Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, and the previous drafts, a couple of questions have come up in our shop.

1) Section 7, 2nd paragraph says "the implementations MUST use manually configured keys with same SA for inbound and outbound traffic (as shown in figure 3).  I assume the "same SA" MUST rule applies to multicast traffic only and not unicast traffic. This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP address. For unicast addresses, by definition there will be as many SAs as there are unicast destination addresses. Therefore, I don't think it is possible to apply this MUST rule given the current IPSec definition (RFC 2401 section 4.1) of an SA for unicast. Assuming the intention of the draft was to apply only to multicast and given the number of potential SAs carrying unicast traffic, it would seem that using IKE to setup the SAs dynamically would be a reasonable alternative to manual keying.    
 
2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel dynamically once it acquires the required information".  Since this traffic is unicast only, IKE could easily set up the required SAs without knowing the specific IP addresses in advance. Creating SAs dynamically do not fit easily within scope of manual SA functional capabilities. Why not use IKE for this traffic? Is this an acceptable option?  

Mike

-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA
--=_alternative 0050629885256FA5_=-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 11 15:54:31 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10597 for ; Fri, 11 Feb 2005 15:54:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00F8379D@cherry.ease.lsoft.com>; Fri, 11 Feb 2005 15:54:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57432431 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Feb 2005 15:54:19 -0500 Received: from 207.217.121.252 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Feb 2005 15:54:19 -0500 Received: from h-68-164-82-176.snvacaid.dynamic.covad.net ([68.164.82.176] helo=earthlink.net) by pop-a065d14.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1Czhnt-00024z-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Feb 2005 12:54:17 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <420D1C62.E55BE9D2@earthlink.net> Date: Fri, 11 Feb 2005 12:58:10 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: draft-ietf-ospf-ospfv3-auth-07.txt : Questions To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, 1) First, if the title specifies OSPFv3, should this RFC be making comparisons to OSPFv2? 2) There are two expriration dates specified on the first page: Auguest 2005 and June 2005, the later with the page 1 header. 3) Doesn't OSPFv3 specifiy Instance values in the headers so multiple instances can be matched with Authentication? This is a major diff between OSPFv2 and OSPFv3. Without the Instance field, only Auth/Encrypt could be used to distinguish multiple instances. You hide part of this when dealing with multiple SAs per link in section 8. 4) Isn't NULL authtication supported in v3? When we support NULL Auth, is that a must support for Auth? "Section 3. Implimentations conforming to this specification MUST support Authentication for OSPFv3." Does this prevent NULL auth? Is this right? 5) Why must v3 packets be sliently discarded when authentication/ confidentially is enabled? Why shouldn't their be calls into OSPF so OSPF can log these dropped packets. "4. Confidentiality * OSPFv3 packets that are not protected ... MUST be silently discarded." Doesn't silent discards prevent administrators from identifing adj failures, unsucessful secutity probing, non-synchronized keyrollovers, etc... 6) If a Implimentation does not support confidentiiality and conforms to this specifiecation, is the packet discard behaviour UNDEFINED? "implimentations ... SHOULD Support... ." 7) 5. Distinguishing OSPFv3 from OSPFv2 "OSPF version field in the OSPF header cannot be used" Then what was the use of this version field? Are you saying that if a implimentor pushes OSPFv3 packets into a IPv4 domain, then they must be processed as OSPFv2 pkts?????? I remember a discussion of pushing OSPFv2 into the IPv6 domain and/or OSPFv3 into IPv4. What was the result of this? Did the result invalidate this section? 8) "version field in IP header can be used" What if an implimentation strips the IP header before it passes it to OSPF?? Shouldn't they be stripped before lower layers are called? 9) 7. Key Managemement "it is not scalable" This means that you can't use even 2 communcation channels when different SAs are used for inbound and outbound traffic. It may be more proper to say that "it does not scale well". Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 14 23:52:33 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26703 for ; Mon, 14 Feb 2005 23:52:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F8D47B@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 23:52:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57851506 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 23:52:23 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 23:52:23 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5131B.9A22B41C" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Questions about OSPF v3 security draft Thread-Index: AcUQSDbJNaXAodg2QlWcHOtQ3pQZYQC0ndZQ Message-ID: Date: Mon, 14 Feb 2005 21:01:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Questions about OSPF v3 security draft To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C5131B.9A22B41C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 I think both the authors are on leave, so they will probably reply later. =20 However regarding the first point, I agree the wording should be clearer. However what it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an interface. =20 Regarding the second point, I think I too have brought the issue on this list and the reply I think was that the draft does not prohibit the use of IKE for unicast flows. =20 Thanks, Vishwas ________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox Sent: Friday, February 11, 2005 8:04 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Questions about OSPF v3 security draft =20 Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, and the previous drafts, a couple of questions have come up in our shop. 1) Section 7, 2nd paragraph says "the implementations MUST use manually configured keys with same SA for inbound and outbound traffic (as shown in figure 3). I assume the "same SA" MUST rule applies to multicast traffic only and not unicast traffic. This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP address. For unicast addresses, by definition there will be as many SAs as there are unicast destination addresses. Therefore, I don't think it is possible to apply this MUST rule given the current IPSec definition (RFC 2401 section 4.1) of an SA for unicast. Assuming the intention of the draft was to apply only to multicast and given the number of potential SAs carrying unicast traffic, it would seem that using IKE to setup the SAs dynamically would be a reasonable alternative to manual keying. =20 =20 2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel dynamically once it acquires the required information". Since this traffic is unicast only, IKE could easily set up the required SAs without knowing the specific IP addresses in advance. Creating SAs dynamically do not fit easily within scope of manual SA functional capabilities. Why not use IKE for this traffic? Is this an acceptable option? =20 Mike=20 ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA=20 ------_=_NextPart_001_01C5131B.9A22B41C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Mike,

 

I think both the authors are on = leave, so they will probably reply later.

 

However regarding the first point, = I agree the wording should be clearer. However what it means is we will use the = same crypto-algorithm and keys for all traffic to a neighbor over an = interface.

 

Regarding the second point, I think = I too have brought the issue on this list and the reply I think was that the draft = does not prohibit the use of IKE for unicast = flows.

      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =  

Thanks,

=

Vishwas

=

From: = Mailing List = [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox
Sent: Friday, February = 11, 2005 8:04 PM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Questions about = OSPF v3 security draft

 


Regarding http://www.ietf.org/internet-drafts/draft-ietf= -ospf-ospfv3-auth-07.txt, and the previous drafts, a couple of questions have come up in our shop. =

1) Section 7, 2nd paragraph says "the implementations MUST use = manually configured keys with same SA for inbound and outbound traffic (as shown = in figure 3).  I assume the "same SA" MUST rule applies to multicast traffic only and not unicast traffic. This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP = address. For unicast addresses, by definition there will be as many SAs as there = are unicast destination addresses. Therefore, I don't think it is possible = to apply this MUST rule given the current IPSec definition (RFC 2401 section 4.1) = of an SA for unicast. Assuming the intention of the draft was to apply only to multicast and given the number of potential SAs carrying unicast = traffic, it would seem that using IKE to setup the SAs dynamically would be a = reasonable alternative to manual keying.    
 
2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel = dynamically once it acquires the required information".  Since this = traffic is unicast only, IKE could easily set up the required SAs without knowing = the specific IP addresses in advance. Creating SAs dynamically do not fit = easily within scope of manual SA functional capabilities. Why not use IKE for = this traffic? Is this an acceptable option?  

Mike

----------------------------------------------------------------------- Enterprise Network Solutions
----------------------------------------------------------------------- Research Triangle = Park, NC  USA

------_=_NextPart_001_01C5131B.9A22B41C-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 15 15:20:01 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07165 for ; Tue, 15 Feb 2005 15:20:01 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F8F7E8@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 15:20:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57959046 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 15:19:53 -0500 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 15:19:53 -0500 Received: (qmail 5609 invoked from network); 15 Feb 2005 20:19:53 -0000 Received: from web.xebeo.com (HELO web.nj.us.utstar.com) (192.168.0.3) by lxmail.xebeo.com with SMTP; 15 Feb 2005 20:19:53 -0000 Received: from utstar.com (IDENT:rohit@localhost.localdomain [127.0.0.1]) by web.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id PAA31449 for ; Tue, 15 Feb 2005 15:19:52 -0500 Message-ID: <200502152019.PAA31449@web.nj.us.utstar.com> Date: Tue, 15 Feb 2005 15:19:52 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: OSPF WG meeting at IETF 62 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Folks, This is just a gentle reminder that there will be an OSPF WG meeting in Minneapolis. If you have suggestions for discussion items, please send Acee and Me some email. Thanks, --rohit. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 16 05:44:54 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23074 for ; Wed, 16 Feb 2005 05:44:54 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F91B4A@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 5:44:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58019329 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 05:44:53 -0500 Received: from 192.51.44.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 05:44:53 -0500 Received: from m7.gw.fujitsu.co.jp ([10.0.50.77]) by fgwmail5.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id j1GAiqOP028784 for ; Wed, 16 Feb 2005 19:44:52 +0900 (envelope-from kashima@jp.fujitsu.com) Received: from s7.gw.fujitsu.co.jp by m7.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id j1GAipDE020341 for ; Wed, 16 Feb 2005 19:44:51 +0900 (envelope-from kashima@jp.fujitsu.com) Received: from s7.gw.fujitsu.co.jp (localhost [127.0.0.1]) by s7.gw.fujitsu.co.jp (Postfix) with ESMTP id D5A8EEFB0A for ; Wed, 16 Feb 2005 19:44:51 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp (chisato.nd.net.fujitsu.co.jp [10.22.112.21]) by s7.gw.fujitsu.co.jp (Postfix) with ESMTP id 9A149EFB03 for ; Wed, 16 Feb 2005 19:44:51 +0900 (JST) Received: from mail1.nd.net.fujitsu.co.jp (k4.kh0110-222.dhcp.css.fujitsu.com [10.17.222.55]) by chisato.nd.net.fujitsu.co.jp (8.12.9p2/8.12.9) with SMTP id j1GAioeO037113 for ; Wed, 16 Feb 2005 19:44:50 +0900 (JST) (envelope-from kashima@jp.fujitsu.com) X-Mailer: EdMax Ver2.85.5F MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <200502161044.j1GAioeO037113@chisato.nd.net.fujitsu.co.jp> Date: Wed, 16 Feb 2005 19:45:01 +0900 Reply-To: Mailing List Sender: Mailing List From: KASHIMA Hiroaki Subject: RestartState (draft-nguyen-ospf-restart-05.txt) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello all. I have an question when studying draft-nguyen-ospf-{lls,resync,restart}-05.txt. Is the purpose of Restart flag (in restart-05.txt) only for Section 2.3? In other words, is this flag not necessary when the configuration is not implemented? Thanks in regards. -- KASHIMA, Hiroaki Software group, SystemFront Division, Fujitsu Ltd From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 16 10:34:43 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25112 for ; Wed, 16 Feb 2005 10:34:42 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00F925AE@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 10:34:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58077444 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 10:34:41 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 10:24:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23147; Wed, 16 Feb 2005 10:24:38 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200502161524.KAA23147@ietf.org> Date: Wed, 16 Feb 2005 10:24:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-cap-06.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart 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 : Extensions to OSPF for Advertising Optional Router Capabilities Author(s) : A. Lindem, et al. Filename : draft-ietf-ospf-cap-06.txt Pages : 15 Date : 2005-2-15 It is useful for routers in an OSPF routing domain to know the capabilities of their neighbors and other routers in the OSPF routing domain. This draft proposes extensions to OSPF for advertising optional router capabilities. A new Router Information (RI) opaque LSA is proposed for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-cap-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-cap-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-16102714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-cap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-cap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-16102714.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 16 13:41:41 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19590 for ; Wed, 16 Feb 2005 13:41:40 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F92D39@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 13:41:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58105112 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 13:41:17 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 13:41:17 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Feb 2005 10:51:23 -0800 Received: from rtp-iosxdm1.cisco.com (rtp-iosxdm1.cisco.com [64.102.16.214]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GIfCq8027254 for ; Wed, 16 Feb 2005 10:41:13 -0800 (PST) Received: (lhnguyen@localhost) by rtp-iosxdm1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA09245 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 13:41:14 -0500 (EST) References: <200502161044.j1GAioeO037113@chisato.nd.net.fujitsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <20050216184114.GK7859@rtp-iosxdm1.cisco.com> Date: Wed, 16 Feb 2005 13:41:14 -0500 Reply-To: Mailing List Sender: Mailing List From: Liem Nguyen Subject: Re: RestartState (draft-nguyen-ospf-restart-05.txt) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200502161044.j1GAioeO037113@chisato.nd.net.fujitsu.co.jp> Precedence: list KASHIMA, On Wed, Feb 16, 2005 at 07:45:01PM +0900, KASHIMA Hiroaki wrote: > Hello all. > > I have an question when studying > draft-nguyen-ospf-{lls,resync,restart}-05.txt. > > Is the purpose of Restart flag (in restart-05.txt) > only for Section 2.3? Its use is mentioned in 2.2. It's needed regardless of the configuration setting in 2.3. > In other words, is this flag not necessary > when the configuration is not implemented? > > Thanks in regards. > -- > KASHIMA, Hiroaki > Software group, > SystemFront Division, Fujitsu Ltd -- Liem Nguyen From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 16 15:21:18 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17395 for ; Wed, 16 Feb 2005 15:21:17 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F93000@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 15:21:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58113877 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 15:21:15 -0500 Received: from 207.217.121.251 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 15:21:14 -0500 Received: from h-68-164-158-104.snvacaid.dynamic.covad.net ([68.164.158.104] helo=earthlink.net) by pop-a065d10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D1Vfd-0005I6-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 12:21:13 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200502161524.KAA23147@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4213AC43.5A232C20@earthlink.net> Date: Wed, 16 Feb 2005 12:25:39 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: I-D ACTION:draft-ietf-ospf-cap-06.txt : Quest To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, 0) You specify multiple times that it is a NEW Router information (RI) LSA in this RFC draft. Isn't it really just a new TLV within the Opaque LSA? "A new Router Information (RI) is proposed for this purpose." Thus shouldn't it really be: A new Router Information (RI) TLV within the Opaque LSA framework is proposed for this purpose". 1) Nit: 2. OSPF Router Information (RI) LSA Future OSPF features could the to Future OSPF features could use the 2) Bit 6 Stub Router Support What is broken without advertising that one may boost the cost of its links to attempt to remove transit traffic when multiple paths exist? What happens if the O bit isn't set in the original capabilitiy set? What is broken that is needed to set the "0" and this bit? What should be done / not done if this bit is set to 0 or 1? Crazy, should a router ignore the high link advertised cost if this bit is set to 0? FYI: If one is concerned with LSInfinity with the value of link cost, one could just set it abnormally high cost value. Shouldn't it then result in the same thing? 3) Undefined behaviour??? This LSA TLV in my opinion really does three things. The first is awareness of a set of capabilities and the second whether the capabilities are present and third set within the router. If a router is capabile of it, I don't know why it wouldn't be set forever. I don't think I have ever seen a router intentionally supporting a degraded set of anything.. The draft RFC does not give me the impression of capability awareness. It just specifies capability support. A router may want to wait until all the routers within a scope have awareness of a capability, and then after all are aware, turn on its capability. This could be done as a automatic sysnchronization. Specificly.. I assume that there must be a reason why one would not originate this TLV with all bits set to 0. Is their one? Yes, the not sending out of this TLV is non awareness. The sending of this TLV with all bits set to 0, is forced awareness of all the bits, and lastly setting the bits is supported capability. (just interested in the non-setting of the bits) So, should their be any architectural differences in sending out this LSA with all or some bits to 0 vs not sending out the LSA? If this LSA was originated and then MaxAged / withdrawn voluntarily or Max sequenced, should their be a behviour change with the non-set bits (set to 0))? 3b) Sorry, I see this as also being undefined. If a router sets different bits for the different flooding scopes, should the link-local set of bits be used in the link scope? You have the possibility of having an implimentation set different values per flooding scope. Isn't the area flooding LSA first flooded through a link? Thus if we get a area scope Opaque LSA after the link-local LSA and some of the bits are different, the area would take precendence. Else the link-would over-ride in the link-scope and be different outside the immediate links? Woooow.... Sorry, the only way around this is that the bits themselves need a flooding scope and not based on the flooding scope of the Opaque LSA. This could then allow the super-scope of the flooding take precendence. Thus, if the capability is only set for the link. That is simple. If the capability is set for the area, then link and area routers would get the LSA and be be synch as to the capability of the router. Lastly, all routers within the AS would recieve the LSA. The only way this could happen is to use the single AS scope Opaque LSA to distribute capability information ,,, right???? 4) In the future, I would expect a bit to be supported that specifies it should be a better candidate as a DR BECAUSE the DR should have the superset of capabilities? Thus, shouldn't their be more here? 5) Capability mismatch is one criteria that COULD determine that a adj should be kept or dropped? Shouldn't we have defined behviours with the acceptance of certain capabilities? For instance, with BGP, their is a term called transitive which allows different handling behaviours when unrecognized attributes are recieved. ??6) Why would a router be interested in withdrawing or changing a capability? If we consider this a rare occurance, why don't we specify it as a DNA (Do Not Age) LSA that doesn't needed to be repeatedly sent. Thus would decrease the amount of un-ncecessary control traffic within the OSPF domain? The LSA for the TLV could always increment the seq field and change a value. 7) Lastly, I am just a little confused due to the multiple implimentations that I have seen. If a Opaque LSA changes one or more of its sets of TLVs, does it need to originate its full set of TLVs for its LSA flooding type? This is based on the OSPFv2 Router LSA where only 1 can be originated by a specific router. If they can be subsets, then only deltas need be originated. Thus if one capbility bit changed, only the capability TLV needs to be re-originated... Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 16 17:01:25 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01807 for ; Wed, 16 Feb 2005 17:01:25 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F9351F@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 17:01:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58124762 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 17:01:09 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 17:01:09 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 16 Feb 2005 17:13:44 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,91,1107752400"; d="scan'208"; a="37257658:sNHT286247244" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GL14hH011964 for ; Wed, 16 Feb 2005 16:01:05 -0500 (EST) Received: from [64.102.48.217] (dhcp-64-102-48-217.cisco.com [64.102.48.217]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFJ62695; Wed, 16 Feb 2005 14:01:03 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200502161524.KAA23147@ietf.org> <4213AC43.5A232C20@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4213C29F.1030200@cisco.com> Date: Wed, 16 Feb 2005 17:01:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-cap-06.txt : Quest To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4213AC43.5A232C20@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: >Group, > > > 0) You specify multiple times that it is a NEW Router > information (RI) LSA in this RFC draft. Isn't it really > just a new TLV within the Opaque LSA? > > No - Opaque LSA are further demux'ed using opaque type and this is a new type (See RFC 2370). > "A new Router Information (RI) is proposed for this > purpose." > > Thus shouldn't it really be: > > A new Router Information (RI) TLV within the Opaque > LSA framework is proposed for this purpose". > > 1) Nit: > > 2. OSPF Router Information (RI) LSA > > Future OSPF features could the > > to > > Future OSPF features could use the > > Will update. > 2) Bit 6 Stub Router Support > > What is broken without advertising that one may boost > the cost of its links to attempt to remove transit > traffic when multiple paths exist? > > What happens if the O bit isn't set in the original > capabilitiy set? What is broken that is needed to > set the "0" and this bit? > > What should be done / not done if this bit is set > to 0 or 1? Crazy, should a router ignore the high > link advertised cost if this bit is set to 0? > > FYI: If one is concerned with LSInfinity with the value > of link cost, one could just set it abnormally high > cost value. Shouldn't it then result in the same > thing? > > The bit is for informational purposes (i.e. the router supports the stub router function as specified in RFC 3137). Please address concerns with that RFC in a separate E-mail as they are beyond the scope of the capabilities LSA. > 3) Undefined behaviour??? > > This LSA TLV in my opinion really does three things. The > first is awareness of a set of capabilities and the > second whether the capabilities are present and third > set within the router. If a router is capabile of > it, I don't know why it wouldn't be set forever. I > don't think I have ever seen a router intentionally > supporting a degraded set of anything.. > > These are supported capabilies (as opposed to currently active). > The draft RFC does not give me the impression of > capability awareness. It just specifies capability > support. A router may want to wait until all the > routers within a scope have awareness of a capability, > and then after all are aware, turn on its capability. > This could be done as a automatic sysnchronization. > > Specificly.. > I assume that there must be a reason why one would > not originate this TLV with all bits set to 0. Is their > one? > > Yes, the not sending out of this TLV is > non awareness. The sending of this TLV with all > bits set to 0, is forced awareness of all the bits, > and lastly setting the bits is supported capability. > > (just interested in the non-setting of the bits) > So, should their be any architectural differences in > sending out this LSA with all or some bits to 0 vs > not sending out the LSA? > > If this LSA was originated and then MaxAged / withdrawn > voluntarily or Max sequenced, should their be a behviour > change with the non-set bits (set to 0))? > > 3b) Sorry, I see this as also being undefined. > > If a router sets different bits for the different > flooding scopes, should the link-local set of bits > be used in the link scope? > > You have the possibility of having an implimentation > set different values per flooding scope. Isn't the > area flooding LSA first flooded through a link? Thus > if we get a area scope Opaque LSA after the link-local > LSA and some of the bits are different, the area would > take precendence. Else the link-would over-ride in > the link-scope and be different outside the immediate > links? Woooow.... > > Sorry, the only way around this is that the bits > themselves need a flooding scope and not based on the > flooding scope of the Opaque LSA. This could then > allow the super-scope of the flooding take precendence. > > Thus, if the capability is only set for the link. That > is simple. > > If the capability is set for the area, then link and > area routers would get the LSA and be be synch as to > the capability of the router. > > Lastly, all routers within the AS would recieve the > LSA. > > The only way this could happen is to use the single > AS scope Opaque LSA to distribute capability information > ,,, right???? > > Possibly, we need some more discussion on this amongst the authors. The questions on these seem to continue. > 4) In the future, I would expect a bit to be supported > that specifies it should be a better candidate as a > DR BECAUSE the DR should have the superset of capabilities? > Thus, shouldn't their be more here? > > 5) Capability mismatch is one criteria that COULD determine > that a adj should be kept or dropped? Shouldn't we have > defined behviours with the acceptance of certain > capabilities? For instance, with BGP, their is a term > called transitive which allows different handling > behaviours when unrecognized attributes are recieved. > > ??6) Why would a router be interested in withdrawing or > changing a capability? If we consider this a rare > occurance, why don't we specify it as a DNA (Do Not > Age) LSA that doesn't needed to be repeatedly sent. > Thus would decrease the amount of un-ncecessary control > traffic within the OSPF domain? > > The LSA for the TLV could always increment the > seq field and change a value. > > 7) Lastly, I am just a little confused due to the multiple > implimentations that I have seen. If a Opaque LSA changes > one or more of its sets of TLVs, does it need to originate > its full set of TLVs for its LSA flooding type? This is > based on the OSPFv2 Router LSA where only 1 can be originated > by a specific router. If they can be subsets, then only > deltas need be originated. Thus if one capbility bit changed, > only the capability TLV needs to be re-originated... > > While it may be interesting, there is no support for incremental LSA and, at least initially, we are not originating multiple LSAs and concatenating. Thanks, Acee > > Mitchell Erblich > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 16 18:41:27 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12600 for ; Wed, 16 Feb 2005 18:41:27 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F9380C@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 18:41:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58130697 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 18:27:37 -0500 Received: from 207.217.121.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 18:27:36 -0500 Received: from h-68-164-158-104.snvacaid.dynamic.covad.net ([68.164.158.104] helo=earthlink.net) by pop-a065d19.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D1YZz-0001Wt-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 15:27:35 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200502161524.KAA23147@ietf.org> <4213AC43.5A232C20@earthlink.net> <4213C29F.1030200@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4213D7E5.890F6011@earthlink.net> Date: Wed, 16 Feb 2005 15:31:49 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: I-D ACTION:draft-ietf-ospf-cap-06.txt : Quest To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem, As usual, you are concise with your answers. Its minor, but I think you are under the Opaque LSA framework, and the capabilities are TLVs, thus I didn't say Opaque LSA, but Opaque LSA framework.. It specifies flooding scope, etc and is specified from the Opaque LSA rfc.. Ok... yes, I will ask this as a separate email.. But same with GR... What happens if someone volunteers as a GR helper and doesn't declare the GR capability... Each capability has the same question, what happens if a router does somthing that shows the capability without declaring its capability???? A) #6 is not a future item. IMO, capability should be a rarely changing item. If that is so, their should be no need to impliment aging with respect to this LSA. Thus, in my opinion, this LSA should be a DNA LSA. Yes implimentations can impliment this without it being specified in the rfc.. I just don't see them really changing or SHOULD BE changing once advertised. Thus, they really don't need to be refused on a periodic basis. B) This is very tricky... as of 3b) My suggestion which would be a start from scratch. It is dictated by the embeded recieve flooding scope to remove the possibility of mutiple LSAs being sent out with different bits set... It could be something like: Each bit expands to: Subtype(8 bits) Flooding scope (3 bits) transitive scope(x bits) reserved x bits.. If they were ordered subtypes (1 to current non zero value : with the first subtype number accepted) (what happens if you had two #4 subtypes after each other) Else If they were ordered begining with AS scope and sent in a Opaque AS flooding LSA, then... Then as the Link-type only subtypes would first be stripped, then area, then finally. but it would happen from the bottom up (length truncations) Yes, upon each strip, a new length and checksum would need to be computed which is not normal to spec. Or one or more fields per subtype gets 0'ed. Length would stay the same, but checksum would change. xx) Else if, the same LSA always gets flooded to a AS scope and only the TLVs that are relevent to the scope are used. Then the reciever would have to determine which flooding scope is current and check the appropriate flooding bit. Else, if multiple LSA flooding scopes are used, their then becomes a issue.. Mitchell Erblich --------------------- Acee Lindem wrote: > > Erblichs wrote: > > >Group, > > > > > > 0) You specify multiple times that it is a NEW Router > > information (RI) LSA in this RFC draft. Isn't it really > > just a new TLV within the Opaque LSA? > > > > > No - Opaque LSA are further demux'ed using opaque type and this is a new > type > (See RFC 2370). > > > "A new Router Information (RI) is proposed for this > > purpose." > > > > Thus shouldn't it really be: > > > > A new Router Information (RI) TLV within the Opaque > > LSA framework is proposed for this purpose". > > > > 1) Nit: > > > > 2. OSPF Router Information (RI) LSA > > > > Future OSPF features could the > > > > to > > > > Future OSPF features could use the > > > > > Will update. > > > 2) Bit 6 Stub Router Support > > > > What is broken without advertising that one may boost > > the cost of its links to attempt to remove transit > > traffic when multiple paths exist? > > > > What happens if the O bit isn't set in the original > > capabilitiy set? What is broken that is needed to > > set the "0" and this bit? > > > > What should be done / not done if this bit is set > > to 0 or 1? Crazy, should a router ignore the high > > link advertised cost if this bit is set to 0? > > > > FYI: If one is concerned with LSInfinity with the value > > of link cost, one could just set it abnormally high > > cost value. Shouldn't it then result in the same > > thing? > > > > > The bit is for informational purposes (i.e. the router supports the stub > router function > as specified in RFC 3137). Please address concerns with that RFC in a > separate > E-mail as they are beyond the scope of the capabilities LSA. > > > 3) Undefined behaviour??? > > > > This LSA TLV in my opinion really does three things. The > > first is awareness of a set of capabilities and the > > second whether the capabilities are present and third > > set within the router. If a router is capabile of > > it, I don't know why it wouldn't be set forever. I > > don't think I have ever seen a router intentionally > > supporting a degraded set of anything.. > > > > > These are supported capabilies (as opposed to currently active). > > > The draft RFC does not give me the impression of > > capability awareness. It just specifies capability > > support. A router may want to wait until all the > > routers within a scope have awareness of a capability, > > and then after all are aware, turn on its capability. > > This could be done as a automatic sysnchronization. > > > > Specificly.. > > I assume that there must be a reason why one would > > not originate this TLV with all bits set to 0. Is their > > one? > > > > Yes, the not sending out of this TLV is > > non awareness. The sending of this TLV with all > > bits set to 0, is forced awareness of all the bits, > > and lastly setting the bits is supported capability. > > > > (just interested in the non-setting of the bits) > > So, should their be any architectural differences in > > sending out this LSA with all or some bits to 0 vs > > not sending out the LSA? > > > > If this LSA was originated and then MaxAged / withdrawn > > voluntarily or Max sequenced, should their be a behviour > > change with the non-set bits (set to 0))? > > > > 3b) Sorry, I see this as also being undefined. > > > > If a router sets different bits for the different > > flooding scopes, should the link-local set of bits > > be used in the link scope? > > > > You have the possibility of having an implimentation > > set different values per flooding scope. Isn't the > > area flooding LSA first flooded through a link? Thus > > if we get a area scope Opaque LSA after the link-local > > LSA and some of the bits are different, the area would > > take precendence. Else the link-would over-ride in > > the link-scope and be different outside the immediate > > links? Woooow.... > > > > Sorry, the only way around this is that the bits > > themselves need a flooding scope and not based on the > > flooding scope of the Opaque LSA. This could then > > allow the super-scope of the flooding take precendence. > > > > Thus, if the capability is only set for the link. That > > is simple. > > > > If the capability is set for the area, then link and > > area routers would get the LSA and be be synch as to > > the capability of the router. > > > > Lastly, all routers within the AS would recieve the > > LSA. > > > > The only way this could happen is to use the single > > AS scope Opaque LSA to distribute capability information > > ,,, right???? > > > > > Possibly, we need some more discussion on this amongst the authors. The > questions > on these seem to continue. > > > 4) In the future, I would expect a bit to be supported > > that specifies it should be a better candidate as a > > DR BECAUSE the DR should have the superset of capabilities? > > Thus, shouldn't their be more here? > > > > 5) Capability mismatch is one criteria that COULD determine > > that a adj should be kept or dropped? Shouldn't we have > > defined behviours with the acceptance of certain > > capabilities? For instance, with BGP, their is a term > > called transitive which allows different handling > > behaviours when unrecognized attributes are recieved. > > > > ??6) Why would a router be interested in withdrawing or > > changing a capability? If we consider this a rare > > occurance, why don't we specify it as a DNA (Do Not > > Age) LSA that doesn't needed to be repeatedly sent. > > Thus would decrease the amount of un-ncecessary control > > traffic within the OSPF domain? > > > > The LSA for the TLV could always increment the > > seq field and change a value. > > > > 7) Lastly, I am just a little confused due to the multiple > > implimentations that I have seen. If a Opaque LSA changes > > one or more of its sets of TLVs, does it need to originate > > its full set of TLVs for its LSA flooding type? This is > > based on the OSPFv2 Router LSA where only 1 can be originated > > by a specific router. If they can be subsets, then only > > deltas need be originated. Thus if one capbility bit changed, > > only the capability TLV needs to be re-originated... > > > > > While it may be interesting, there is no support for incremental LSA > and, at least initially, > we are not originating multiple LSAs and concatenating. > > Thanks, > Acee > > > > > Mitchell Erblich > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 16 18:46:29 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13315 for ; Wed, 16 Feb 2005 18:46:28 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00F93906@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 18:46:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58130464 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 18:31:27 -0500 Received: from 192.51.44.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 18:21:26 -0500 Received: from m4.gw.fujitsu.co.jp ([10.0.50.74]) by fgwmail5.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id j1GNLOOP010996; Thu, 17 Feb 2005 08:21:24 +0900 (envelope-from kashima@jp.fujitsu.com) Received: from s3.gw.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id j1GNLNfQ010793; Thu, 17 Feb 2005 08:21:24 +0900 (envelope-from kashima@jp.fujitsu.com) Received: from s3.gw.fujitsu.co.jp (s3 [127.0.0.1]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id DD5E243F0F; Thu, 17 Feb 2005 08:21:23 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp (chisato.nd.net.fujitsu.co.jp [10.22.112.21]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 90A3B43F03; Thu, 17 Feb 2005 08:21:23 +0900 (JST) Received: from mail1.nd.net.fujitsu.co.jp (k4.kh0110-222.dhcp.css.fujitsu.com [10.17.222.55]) by chisato.nd.net.fujitsu.co.jp (8.12.9p2/8.12.9) with SMTP id j1GNLLeO047285; Thu, 17 Feb 2005 08:21:21 +0900 (JST) (envelope-from kashima@jp.fujitsu.com) X-Mailer: EdMax Ver2.85.5F MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200502161044.j1GAioeO037113@chisato.nd.net.fujitsu.co.jp> <20050216184114.GK7859@rtp-iosxdm1.cisco.com> Message-ID: <200502162321.j1GNLLeO047285@chisato.nd.net.fujitsu.co.jp> Date: Thu, 17 Feb 2005 08:21:32 +0900 Reply-To: Mailing List Sender: Mailing List From: KASHIMA Hiroaki Subject: Re: RestartState (draft-nguyen-ospf-restart-05.txt) Comments: To: Liem Nguyen To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050216184114.GK7859@rtp-iosxdm1.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Nguyen, I find some set/clear statements for RestartState in 2.2, but I cannot find read statement for it. Who read it? -- kashima Liem Nguyen wrote: > KASHIMA, > > On Wed, Feb 16, 2005 at 07:45:01PM +0900, KASHIMA Hiroaki wrote: > > Hello all. > > > > I have an question when studying > > draft-nguyen-ospf-{lls,resync,restart}-05.txt. > > > > Is the purpose of Restart flag (in restart-05.txt) > > only for Section 2.3? > > Its use is mentioned in 2.2. > It's needed regardless of the configuration setting in 2.3. > > > > In other words, is this flag not necessary > > when the configuration is not implemented? > > > > Thanks in regards. > > -- > > KASHIMA, Hiroaki > > Software group, > > SystemFront Division, Fujitsu Ltd > > -- > > Liem Nguyen From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 16 19:38:04 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18423 for ; Wed, 16 Feb 2005 19:38:04 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F93B79@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 19:38:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58133488 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 19:25:22 -0500 Received: from 207.217.121.184 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 19:25:22 -0500 Received: from h-68-164-158-104.snvacaid.dynamic.covad.net ([68.164.158.104] helo=earthlink.net) by pop-a065c10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D1ZTr-0006SB-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 16:25:19 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200502161524.KAA23147@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4213E567.51F51CB2@earthlink.net> Date: Wed, 16 Feb 2005 16:29:27 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Gracefull restart authors wrt capability bits To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, their is a capability draft that includes informative capbility bits that apply to GR. 1) What happens if a router impliments GR funtions without advertising this fact? 2) How does the capability information bits effect the architecture of the GR functionality? 3) What is the difference from setting 0 capability bits in the capability LSA vs not sending out the capability LSA? 4) What is the stickyness of the GR bits? Under what conditions would GR informative bits be set and unset after boot? 5) What should the flooding scope of these GR be and at what different flooding scopes effect the GR support??? 6) If no routers in a area have the GR capability bits set, should the router attempt to follow GR procedures or bypass GR?? 7) If GR bits are set by routers in the area and no helpers are identified as part of the GR spec, should we do anything different? Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 16 19:38:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18443 for ; Wed, 16 Feb 2005 19:38:06 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F93B1F@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 19:38:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58133499 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 19:25:26 -0500 Received: from 207.217.121.184 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 19:25:26 -0500 Received: from h-68-164-158-104.snvacaid.dynamic.covad.net ([68.164.158.104] helo=earthlink.net) by pop-a065c10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D1ZTx-0006VQ-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 16:25:25 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200502161524.KAA23147@ietf.org> <4213AC43.5A232C20@earthlink.net> <4213C29F.1030200@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4213E56E.1CE16085@earthlink.net> Date: Wed, 16 Feb 2005 16:29:34 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Stub router advertisement / capability rfc3137 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Acee asked me split out these concerns from the capability draft... bit #6. 1) What happens if RFC3137 is supported and not advertised in the upcoming draft as a informative capability? 2) What should be diff between advertising a "0" infmormative bit in the capability LSA and never sending out the advertised capability LSA? basicly Not yet supporting the capability Opaque LSA.. 3) Why is the capability bit needed? What will it fix by advertising it in the capability Opaque LSA known as a RI? 4) Do you expect a router once advertising this bit in the capability RI LSA, to unadvertise the bit by clearing and resending the LSA? Basicly, once set, what is the reason for it to be changed? 5) What should the flooding scope of the bit #6 be and how does different flooding scopes effect the implimentation of support of 3137? Mitchell Erblich -------------------- > > > 2) Bit 6 Stub Router Support > > > > What is broken without advertising that one may boost > > the cost of its links to attempt to remove transit > > traffic when multiple paths exist? > > > > What happens if the O bit isn't set in the original > > capabilitiy set? What is broken that is needed to > > set the "0" and this bit? > > > > What should be done / not done if this bit is set > > to 0 or 1? Crazy, should a router ignore the high > > link advertised cost if this bit is set to 0? > > > > FYI: If one is concerned with LSInfinity with the value > > of link cost, one could just set it abnormally high > > cost value. Shouldn't it then result in the same > > thing? > > > > > The bit is for informational purposes (i.e. the router supports the stub > router function > as specified in RFC 3137). Please address concerns with that RFC in a > separate > E-mail as they are beyond the scope of the capabilities LSA. > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 17 00:37:27 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17173 for ; Thu, 17 Feb 2005 00:37:27 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F949CD@cherry.ease.lsoft.com>; Thu, 17 Feb 2005 0:37:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58157290 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Feb 2005 00:37:25 -0500 Received: from 220.227.179.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 17 Feb 2005 00:27:23 -0500 Received: from indhubbhs03.ad.infosys.com ([192.168.18.90]) by kecgate03.infosys.com with InterScan Messaging Security Suite; Thu, 17 Feb 2005 10:39:34 +0530 Received: from shlmsg05.ad.infosys.com ([172.25.42.50]) by indhubbhs03.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Feb 2005 10:44:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C514AF.8AC06840" Thread-Topic: Opaque LSA Thread-Index: AcUUryVcF5PijhlvQza7ADW0+/A54A== X-OriginalArrivalTime: 17 Feb 2005 05:14:26.0829 (UTC) FILETIME=[8D0E63D0:01C514AF] Message-ID: <5E4A1DD002BC4840B3E715A9C557D1C9089A058C@shlmsg05.ad.infosys.com> Date: Thu, 17 Feb 2005 10:44:22 +0530 Reply-To: Mailing List Sender: Mailing List From: Chitra Lakshmi Namadevan Subject: Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C514AF.8AC06840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Will Opaque LSA be originated when there is no fully adjacent neighbor? =20 Regards, =20 Chitra ------_=_NextPart_001_01C514AF.8AC06840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Will Opaque LSA be originated when there is no fully adjacent neighbor?

 

Regards,

 

Chitra

------_=_NextPart_001_01C514AF.8AC06840-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 18 13:44:52 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21141 for ; Fri, 18 Feb 2005 13:44:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00FA80F7@cherry.ease.lsoft.com>; Fri, 18 Feb 2005 13:44:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58489677 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Feb 2005 13:44:50 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Feb 2005 13:44:50 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2005 13:57:46 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,99,1107752400"; d="scan'208"; a="37535076:sNHT19167236" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1IIim1j002199 for ; Fri, 18 Feb 2005 13:44:49 -0500 (EST) Received: from [10.82.225.130] (rtp-vpn1-386.cisco.com [10.82.225.130]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFL06850; Fri, 18 Feb 2005 10:44:47 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5E4A1DD002BC4840B3E715A9C557D1C9089A058C@shlmsg05.ad.infosys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4216379F.5070900@cisco.com> Date: Fri, 18 Feb 2005 13:44:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <5E4A1DD002BC4840B3E715A9C557D1C9089A058C@shlmsg05.ad.infosys.com> Precedence: list Content-Transfer-Encoding: 7bit Chitra Lakshmi Namadevan wrote: > Hi, > > > > Will Opaque LSA be originated when there is no fully adjacent neighbor? > Hi Chitra, Go ahead and originate it when the event triggering the opaque LSAs first occurs. I don't see much value in keying LSA origination for any LSA type on whether or not there are neighbors to which the LSA would be flooded. Thanks, Acee > > > Regards, > > > > Chitra > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 18 13:59:55 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23765 for ; Fri, 18 Feb 2005 13:59:54 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00FA8090@cherry.ease.lsoft.com>; Fri, 18 Feb 2005 13:59:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58491207 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Feb 2005 13:59:51 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Feb 2005 13:59:51 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2005 13:59:52 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1IIxlhF001150 for ; Fri, 18 Feb 2005 13:59:47 -0500 (EST) Received: from [10.82.225.130] (rtp-vpn1-386.cisco.com [10.82.225.130]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFL08352; Fri, 18 Feb 2005 10:59:48 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200502161524.KAA23147@ietf.org> <4213E567.51F51CB2@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42163B24.3070901@cisco.com> Date: Fri, 18 Feb 2005 13:59:48 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Gracefull restart authors wrt capability bits To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4213E567.51F51CB2@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Hi Mitchell, Since the graceful restart capability predates the capability draft, the bit in the TLV are for informational purposes only. So an OSPF implementation could certainly support graceful restart without supporting the capabilities draft. However, if an OSPF implementation supports the capabilites LSA it should correctly advertise its capabilities. It it didn't, I'd consider it a bug. Thanks, Acee Erblichs wrote: >Group, > > their is a capability draft that includes > informative capbility bits that apply to > GR. > > 1) What happens if a router impliments GR funtions > without advertising this fact? > > 2) How does the capability information bits > effect the architecture of the GR functionality? > > 3) What is the difference from setting 0 capability > bits in the capability LSA vs not sending out the > capability LSA? > > 4) What is the stickyness of the GR bits? Under > what conditions would GR informative bits be > set and unset after boot? > > 5) What should the flooding scope of these GR > be and at what different flooding scopes effect > the GR support??? > > 6) If no routers in a area have the GR capability > bits set, should the router attempt to follow GR > procedures or bypass GR?? > > 7) If GR bits are set by routers in the area and > no helpers are identified as part of the GR > spec, should we do anything different? > > > Mitchell Erblich > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 18 14:01:53 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24139 for ; Fri, 18 Feb 2005 14:01:53 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00FA8138@cherry.ease.lsoft.com>; Fri, 18 Feb 2005 14:01:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58491628 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Feb 2005 14:01:49 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Feb 2005 14:01:49 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2005 14:14:45 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,99,1107752400"; d="scan'208"; a="37537309:sNHT20756496" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1IJ1l1j005933 for ; Fri, 18 Feb 2005 14:01:48 -0500 (EST) Received: from [10.82.225.130] (rtp-vpn1-386.cisco.com [10.82.225.130]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFL08548; Fri, 18 Feb 2005 11:01:46 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200502161524.KAA23147@ietf.org> <4213AC43.5A232C20@earthlink.net> <4213C29F.1030200@cisco.com> <4213E56E.1CE16085@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42163B9A.8010202@cisco.com> Date: Fri, 18 Feb 2005 14:01:46 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Stub router advertisement / capability rfc3137 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4213E56E.1CE16085@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Hi Mitchell, Since the stub router capability predates the capability draft, the bit in the TLV are for informational purposes only. So an OSPF implementation could certainly support stub router without supporting the capabilities draft. However, if an OSPF implementation supports the capabilites LSA it should correctly advertise its capabilities. It it didn't, I'd consider it a bug. Note that an implementation may support configuration options to disable a capability and that would be one reason for re-origination of the capabilities LSA. Thanks, Acee Erblichs wrote: >Group, > > Acee asked me split out these concerns from the > capability draft... bit #6. > > 1) What happens if RFC3137 is supported and > not advertised in the upcoming draft as a > informative capability? > > 2) What should be diff between advertising > a "0" infmormative bit in the capability LSA > and never sending out the advertised capability LSA? > basicly Not yet supporting the capability > Opaque LSA.. > > 3) Why is the capability bit needed? What will > it fix by advertising it in the capability > Opaque LSA known as a RI? > > 4) Do you expect a router once advertising this > bit in the capability RI LSA, to unadvertise > the bit by clearing and resending the LSA? > Basicly, once set, what is the reason for it > to be changed? > > 5) What should the flooding scope of the bit > #6 be and how does different flooding scopes > effect the implimentation of support of > 3137? > > > Mitchell Erblich > -------------------- > > > > > > > >>> 2) Bit 6 Stub Router Support >>> >>> What is broken without advertising that one may boost >>> the cost of its links to attempt to remove transit >>> traffic when multiple paths exist? >>> >>> What happens if the O bit isn't set in the original >>> capabilitiy set? What is broken that is needed to >>> set the "0" and this bit? >>> >>> What should be done / not done if this bit is set >>> to 0 or 1? Crazy, should a router ignore the high >>> link advertised cost if this bit is set to 0? >>> >>> FYI: If one is concerned with LSInfinity with the value >>> of link cost, one could just set it abnormally high >>> cost value. Shouldn't it then result in the same >>> thing? >>> >>> >>> >>> >>The bit is for informational purposes (i.e. the router supports the stub >>router function >>as specified in RFC 3137). Please address concerns with that RFC in a >>separate >>E-mail as they are beyond the scope of the capabilities LSA. >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 21 16:01:46 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14889 for ; Mon, 21 Feb 2005 16:01:45 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00FAC981@cherry.ease.lsoft.com>; Mon, 21 Feb 2005 16:01:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58868271 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 21 Feb 2005 16:01:43 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 21 Feb 2005 15:51:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13891; Mon, 21 Feb 2005 15:51:41 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200502212051.PAA13891@ietf.org> Date: Mon, 21 Feb 2005 15:51:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-traffic-03.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart 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 : Traffic Engineering Extensions to OSPF version 3 Author(s) : K. Ishiguro, et al. Filename : draft-ietf-ospf-ospfv3-traffic-03.txt Pages : 16 Date : 2005-2-21 This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-traffic-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-21151927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-traffic-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21151927.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 22 05:02:36 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09005 for ; Tue, 22 Feb 2005 05:02:34 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00FAD78E@cherry.ease.lsoft.com>; Tue, 22 Feb 2005 5:02:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58912587 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 22 Feb 2005 05:02:32 -0500 Received: from 207.217.121.249 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 22 Feb 2005 05:02:32 -0500 Received: from h-68-164-89-21.snvacaid.dynamic.covad.net ([68.164.89.21] helo=earthlink.net) by pop-a065d05.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D3WsA-0004Hl-00; Tue, 22 Feb 2005 02:02:30 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <421AF5C1.7C251E19@earthlink.net> Date: Tue, 22 Feb 2005 01:05:05 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Prioritized Treatment of OSPFv2 Pkts.. draft 9.. Comments: To: gchoudhury@att.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, This draft has been in draft for about 2 years and maybe I think it is moving in the right direction. Over the years, I have learned alot about CA in what works and what doesn't. Here is a set of suggested changes for this document in "prioritized order" .. This set of Recommendations really includes Congestion Relief/Mitigation as modifing the rexmit interval assumes that congestion is already present and we will decrease the amount of congestion based on our actions. A) (4)Implicit Congestion Detection and Action based on That: "can implicitly detect it based on the number of unacknowledged LSAs to this router" No......... FYI: LSAs are placed on a rexmit list when initially xmited. To implicitly detect the level of nbr scope congestion, one must timestamp each LSA placed on this nbr rexmit list. Only the LSAs that have a age greater than the arch specified rexmit interval can then be summed and then divided by the number of these late ack'ed LSAs. The greater the result value, the greater the current level of nbr congestion which is time dependent. If the value is at X.xx and we have 10k LSAs present, I don't know that we can even consider the adj router as congested. It is possible that we have the acks in our in pkt list, so minimally a delayed rexmit should follow only AFTER we check our input FIFO pkt list for these acks. One could also measure the avg time the LSAs are present on the rexmit list per nbr, to check the min LSA ack time. The rexmit interval should be 5 secs more than this min value as a begining value. The reason for this is that we may aggregate the LSAs into the control pkt, have a unknown latency to xmit the pkt, the recv'r then needs to process the pkt (maybe behind a LSA storm), then send the pkt, which we then have another media xmit latency, AND then we have to process it which may be behind another LSA storm. B) (5) Throttling Adjs to be brought up Simultaneously: FYI: Not all pre-full adjs are equal! The best load dependent measurement that a single adj should be based on the size of the sum of the LS Request sizes. This sum is close to "0" for what I consider warm LSDBs, which are almost fully populated with LSAs. Versus the number of tobe LSAs present * LSA size for a "cold" LSDB. Thus, I feel that warm LSDBs should not be counted. They will only exchange Database Description pkts and force lookups of each LSA header. Simply a warm LSDB exchange occurs between the DR and BDR after they formed their adjs with others. Just the originated LSAs from the DR and BDR need to be specified in the LS Request pkt. Close to 0% of LSAs. A cold LSDB exchange is when two DRs merge their LSDBs after a merge. 100% od LSAs would need to be specified in the LS Request pkts. So, to summarize, only cold LSDB adjs SHOULD be counted and throttled to minimize LSA flooding loads.. Fewer simultaneious adj formations CAN result in significantly longer convergence times due to repetative SPF calcs based on multiple no MTU sized Update pkt flooding. If the number of cold LSDB adjs is too small then the resultant Update pkts may not at least MTU size and repetative pkts will need to be flooded. The order should NOT be FCFS. Recently dropped adjs should be penalized and placed at the end of the order. Hopefully, the event that caused the lost of the adj was infrequent and transient. C) (1) Classify all OSPF pkt in two classes.. If we assume that we can pre-process the OSPF hellos and other control pkts and ... have one FIFO list: We just need to be able to set a flag to determine whether we have experienced tail-drop (lose a pkt off the end due to a memory shortage) and if we haven't we know that all rec'ed pkts are present. If we assume that a adj loss due to a LSA storm is rare, then we process the control pkts as normal. IFF we loose an adj (we identify the number of pkts on this list), process that count of pkts and determine whether we continue with the adj or destroy it. This is based solely on whether the hello pkt was found, but just delayed its processing due to a large number of LSAs showing up before it. have one FIFO list, but we support RED (random early discard) of non hello pkts to make sure that we don;t loose hello pkts based on memory exhaustion and proceed as above. have two or more FIFO lists, and allocate one to hello pkts to verify that we never drop hellos, due to a LSA storm So, even in the worst case in the in above delayed hello processing, all the hello multiplier count of nbr hellos would have to be dropped for us to drop the adj.. D) NEW: Congestion really has SCOPE and TIME. This draft still does not recognize that congestion and recommendations of Avoidance / Awareness/ and Mitigation.. Nbr congestion (transient and prolonged) One nbr could be "congested" because of a extensive LSDB aging and chksum scan, requried flooding, and a multiple area SPF calc that takes X amount of time. Link Congestion : One of more nbrs on the same link This normally occurs when a set of routers are initially synchronizing their LSDBs.. Area Congestion : Multiple events are occuring which effect all the links/routers in a area. Global Congestion : Multiple areas are experiencing an event that is effecting more than just an area scope. E) Use the Exponential backoff algoriithm First, see A for the min LSA ack time. Without a min value, you do not know really where you need to start with. This should give you a value that will scale based on the link-bandwidth. A exponential value assumes that inflight pkts are causing a lag, which we need to compensatre for. The problems with exponentials is that as they increase the courseness of their higher values can and will lead to excessive convergence timeframes. thank you, Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 23 10:24:42 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26849 for ; Wed, 23 Feb 2005 10:24:40 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00FAFBF8@cherry.ease.lsoft.com>; Wed, 23 Feb 2005 10:24:37 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59105704 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Feb 2005 10:24:33 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 23 Feb 2005 10:24:33 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2005 10:24:33 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1NFOT1j018165; Wed, 23 Feb 2005 10:24:30 -0500 (EST) Received: from [64.102.48.217] (dhcp-64-102-48-217.cisco.com [64.102.48.217]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFN36936; Wed, 23 Feb 2005 07:24:28 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <53F74F5A7B94D511841C00B0D0AB16F8057D8C13@baker.datcon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <421CA02C.4080309@cisco.com> Date: Wed, 23 Feb 2005 10:24:28 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-ietf-ospf-ospfv3-traffic-03 Comments: To: Alan Davey Comments: cc: kunihiro@ipinfusion.com, takada@ipinfusion.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F8057D8C13@baker.datcon.co.uk> Precedence: list Content-Transfer-Encoding: 7bit Hi Alan, Thanks much for your review and comments. I'm copying the OSPF list to see if there is any discussion. See comments inline. Alan Davey wrote: >Folks > >I have some comments on draft-ietf-ospf-ospfv3-traffic-03. Also, I note that some previous comments of mine have not made it into this revision and so I have reproduced them in this mail for completeness. > >The new comments are all minor editorial points. > >The previous comments include a suggested change to the value used as the LSA Link State ID, points for clarification and more minor editorial comments. > >Please let me know what you think. > >Regards > >Alan >------------------------------------ >Alan Davey >Data Connection Ltd >Tel: +44 20 8366 1177 >Fax: +44 20 8363 1039 >Email: Alan.Davey@dataconnection.com >Web: http://www.dataconnection.com > > >New Comments >------------ > >_Minor editorial points_ > >* Section 1, paragraph 2. s/TLSs/TLVs/ > >* Section 1, paragraph 2, final sentence. s/Some TLVs/Some existing TLVs/ ? > >* Section 2, paragraph 1. s/When the U bit/When the U bit/ > >* Section 2, Intra-Area-TE-LSA definition should be > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LS age |1|0|1| 10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > instead of > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LS age |1|1|0| 10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >* Section 2, paragraphs 3 and 4. s/TLV's/TLVs/ > >* Section 4.4, paragraph 1. s/associated with neighbor's interface/associated with the neighbor's interface/ > > These are all errors I injected when editting the draft and I will gladly incorporate them. >Previously Noted Comments >------------------------- > >_Suggested Change to the Value Used as the Link State ID_ > >I do not think that the interface ID of the link is suitable for use as the Link State ID of the Intra-Area-TE-LSA. In particular, it is not suitable for the Link State ID of the single Intra-Area-TE-LSA containing the Router IPv6 Address TLV advertised by a router as this Link State ID must be different to all Link State IDs used for Intra-Area-TE-LSAs containing Link TLVs. > >I suggest using an arbitrary value with no topological significance as the Link State ID for Intra-Area-TE-LSAs, in a similar manner to LSA IDs in RFC3630 (Traffic Engineering (TE) Extensions to OSPF Version 2). > > In practice, many implementations do use the IfIndex for the the 23 bit OSPF opaque ID. My previous implementation used the IfIndex for the LSA opaque type for the link TLVs and 0 for the LSA opaque type for the router address TLV. Anyway, I can see arguments for going both ways. In the case of using Interface ID and 0 (router IPv6 address TLV), we simplify access and mapping between TE LSAs and Network-LSAs. In the case of the arbitrary IDs, we are not limiting ourselves to specific ID when adding future Intra-Area-TE-LSA TLVs. Any other opinions here? >_Points requiring Clarification_ > >* Section 4.2. The Neighbor ID replaces the OSPFv2 TE Link ID to identify the remote end of a link. The Link ID is mandatory in OSPFv2 TE. I think that Neighbor ID should be mandatory in OSPFv3 TE. > > Agreed. >I suggest adding paragraph defining which sub-TLVs are mandatory for OSPFv3 support. For example: "The Neighbor ID sub-TLV is mandatory for OSPFv3 Traffic Engineering support, that is, it MUST appear exactly once in a Link TLV. All other sub-TLVs defined here MAY occur at most once in a Link TLV." > > Agreed. >* Section 4.4. This section correctly states that link-local addresses should not be contained in this sub-TLV. I suggest adding a sentence stating that IPv6 addresses advertised by the neighbor in Link-LSAs >as 128-bit prefixes with the LA-bit set MAY be included. > > Agreed. >* Section 5. In RFC3630, it is defined that an LSA contains one and only one top-level TLV. Is this also the case for the Intra-Area-TE-LSA? > > I see no reason to change this and believe it simplifies things. >* RFC3630 states that unnumbered links are not supported. Is this also the case in this draft? > > IMHO, No. Personally, I don't see the requirement to even define the concept of an unnumbered IPv6 link :^) Anyway, IPv6 links are no longer identified by their addresses - we have OSPF interface ID and our neighbor's interface ID so there is no ambiguity among parrallel unnumbered links. >_Minor editorial points_ > >* Suggest adding a "Terms" section referencing RFC2119. RFC2119 appears in the Normative References section but is not referenced in the body of the draft. > >* Section 1, paragraph 2. s/applicabilty/applicability/ > >* Section 1, paragraph 3. s/TLV/TLVs/ > >* Section 3, paragraph 1. Suggest current tense instead of "will advertise". > >* Section 4, paragraph 1. > o Suggest "consists of a set of...". > o Instead of "consists a set of...". > >* Section 4, paragraph 1. s/All of sub-TLVs/All of the sub-TLVs/ > >* Section 4, sub-TLV descriptions. > o Suggest "(16N octets, where N is the number of IPv6 addresses)". > o Instead of "(16N octets)". > >* Section 4.1, paragraph 1. > o Suggest "In OSPFv3, the Link ID sub-TLV SHOULD NOT be sent and MUST be ignored upon receipt". > o Instead of "In OSPFv3, The Link ID sub-TLV should not be sent and should be ignored upon receipt". > >* Section 4.3, paragraph 1. > o Suggest "If there are multiple local addresses assigned to the link then they MAY all be listed in this sub-TLV. Link-local scope addresses MUST NOT be included in this sub-TLV". > o Instead of "If there are multiple local addresses on the link, they are all listed in this sub-TLV. Link-local address should not be included in this sub-TLV". > >* Section 4.4, paragraph 1. > o Suggest "If the link type is multi-access, the Remote Interface IPv6 Address MAY be set to ::. Alternatively, an implementation MAY choose not to send this sub-TLV". > o Instead of "If the Link Type is multi-access, the Remote Interface IPv6 Address is set to ::." > > These sound reasonable. I know I've already addressed at least one of them when editting. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 23 16:04:32 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16560 for ; Wed, 23 Feb 2005 16:04:32 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00FB01D9@cherry.ease.lsoft.com>; Wed, 23 Feb 2005 16:04:32 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59133050 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Feb 2005 16:04:31 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 23 Feb 2005 15:54:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15261; Wed, 23 Feb 2005 15:54:28 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200502232054.PAA15261@ietf.org> Date: Wed, 23 Feb 2005 15:54:27 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mt-01.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart 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 : Multi-Topology (MT) Routing in OSPF Author(s) : P. Psenak, et al. Filename : draft-ietf-ospf-mt-01.txt Pages : 16 Date : 2005-2-23 This draft describes an extension to OSPF in order to define independent IP topologies called Multi-Topologies (MTs). The MT extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service, or in-band network management. [M-ISIS] describes a similar mechanism for ISIS. An optional extension to exclude selected links from the default topology is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-mt-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-mt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-23155846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-23155846.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 23 16:05:12 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16738 for ; Wed, 23 Feb 2005 16:05:11 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00FB0192@cherry.ease.lsoft.com>; Wed, 23 Feb 2005 16:05:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59133081 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Feb 2005 16:05:12 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 23 Feb 2005 15:55:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15326; Wed, 23 Feb 2005 15:55:08 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200502232055.PAA15326@ietf.org> Date: Wed, 23 Feb 2005 15:55:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-update-02.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart 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 : OSPF for IPv6 Author(s) : D. Ferguson, et al. Filename : draft-ietf-ospf-ospfv3-update-02.txt Pages : 85 Date : 2005-2-23 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-update-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-23155851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-23155851.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 24 12:03:01 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15985 for ; Thu, 24 Feb 2005 12:03:01 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00FB1C58@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 12:03:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59262590 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 12:02:58 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 12:02:58 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2005 08:50:12 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,114,1107763200"; d="scan'208"; a="163179345:sNHT920107156" Received: from rtp-iosxdm1.cisco.com (rtp-iosxdm1.cisco.com [64.102.16.214]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1OGlVuC025288; Thu, 24 Feb 2005 08:47:32 -0800 (PST) Received: (lhnguyen@localhost) by rtp-iosxdm1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03814; Thu, 24 Feb 2005 11:47:33 -0500 (EST) References: <200502161044.j1GAioeO037113@chisato.nd.net.fujitsu.co.jp> <20050216184114.GK7859@rtp-iosxdm1.cisco.com> <200502162321.j1GNLLeO047285@chisato.nd.net.fujitsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <20050224164733.GV9156@rtp-iosxdm1.cisco.com> Date: Thu, 24 Feb 2005 11:47:33 -0500 Reply-To: Mailing List Sender: Mailing List From: Liem Nguyen Subject: Re: RestartState (draft-nguyen-ospf-restart-05.txt) Comments: To: KASHIMA Hiroaki To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200502162321.j1GNLLeO047285@chisato.nd.net.fujitsu.co.jp> Precedence: list kashima, On Thu, Feb 17, 2005 at 08:21:32AM +0900, KASHIMA Hiroaki wrote: > Nguyen, > > I find some set/clear statements for RestartState in 2.2, > but I cannot find read statement for it. I see; yes, 2.3 is one application. But it can also be used in conjuction with the oob-resync draft as a mechanism to start/stop oob-resync. Note implementations can operate without the RestartState flag, as long as the received RS-bit is properly reacted to. Thanks, Liem > Who read it? > -- > kashima > > > Liem Nguyen wrote: > > > KASHIMA, > > > > On Wed, Feb 16, 2005 at 07:45:01PM +0900, KASHIMA Hiroaki wrote: > > > Hello all. > > > > > > I have an question when studying > > > draft-nguyen-ospf-{lls,resync,restart}-05.txt. > > > > > > Is the purpose of Restart flag (in restart-05.txt) > > > only for Section 2.3? > > > > Its use is mentioned in 2.2. > > It's needed regardless of the configuration setting in 2.3. > > > > > > > In other words, is this flag not necessary > > > when the configuration is not implemented? > > > > > > Thanks in regards. > > > -- > > > KASHIMA, Hiroaki > > > Software group, > > > SystemFront Division, Fujitsu Ltd From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 24 16:27:53 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23643 for ; Thu, 24 Feb 2005 16:27:53 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00FB24A1@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 16:27:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59284825 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 16:27:52 -0500 Received: from 32.97.110.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 16:27:52 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1OLRo5j625754 for ; Thu, 24 Feb 2005 16:27:50 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1OLRoov145838 for ; Thu, 24 Feb 2005 14:27:50 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1OLRoDZ011468 for ; Thu, 24 Feb 2005 14:27:50 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1OLRoLr011465 for ; Thu, 24 Feb 2005 14:27:50 -0700 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 X-MIMETrack: S/MIME Sign by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 02/24/2005 04:31:51 PM, Serialize by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 02/24/2005 04:31:51 PM, Serialize complete at 02/24/2005 04:31:51 PM, S/MIME Sign failed at 02/24/2005 04:31:51 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/24/2005 14:27:49, Serialize complete at 02/24/2005 14:27:49 Content-Type: multipart/alternative; boundary="=_alternative 0076430A85256FB2_=" Message-ID: Date: Thu, 24 Feb 2005 14:27:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Re: Questions about OSPF v3 security draft To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart message in MIME format. --=_alternative 0076430A85256FB2_= Content-Type: text/plain; charset="US-ASCII" Vishwas, I shared your response with our security expert and here is his response: What we need to know is whether the paragraph is referring to unicast. " What it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an interface." If this comment is referring to unicast, the point remains is that there will be multiple SAs. We will not be able to adhere to the figure 3 requirements for unicast, and there will be full meshing of SAs required between all communicating OSPFs. Not so bad if using IKE. Really bad if using manual SAs. Here is the thread of notes being referred to (since it's been a couple of weeks): Vishwas Manral Sent by: Mailing List 02/15/2005 12:01 AM Please respond to Mailing List To: OSPF@PEACH.EASE.LSOFT.COM cc: Subject: Re: Questions about OSPF v3 security draft Hi Mike, I think both the authors are on leave, so they will probably reply later. However regarding the first point, I agree the wording should be clearer. However what it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an interface. Regarding the second point, I think I too have brought the issue on this list and the reply I think was that the draft does not prohibit the use of IKE for unicast flows. Thanks, Vishwas From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox Sent: Friday, February 11, 2005 8:04 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Questions about OSPF v3 security draft Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, and the previous drafts, a couple of questions have come up in our shop. 1) Section 7, 2nd paragraph says "the implementations MUST use manually configured keys with same SA for inbound and outbound traffic (as shown in figure 3). I assume the "same SA" MUST rule applies to multicast traffic only and not unicast traffic. This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP address. For unicast addresses, by definition there will be as many SAs as there are unicast destination addresses. Therefore, I don't think it is possible to apply this MUST rule given the current IPSec definition (RFC 2401 section 4.1) of an SA for unicast. Assuming the intention of the draft was to apply only to multicast and given the number of potential SAs carrying unicast traffic, it would seem that using IKE to setup the SAs dynamically would be a reasonable alternative to manual keying. 2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel dynamically once it acquires the required information". Since this traffic is unicast only, IKE could easily set up the required SAs without knowing the specific IP addresses in advance. Creating SAs dynamically do not fit easily within scope of manual SA functional capabilities. Why not use IKE for this traffic? Is this an acceptable option? Mike --=_alternative 0076430A85256FB2_= Content-Type: text/html; charset="US-ASCII"
Vishwas,

I shared your response with our security expert and here is his response:

What we need to know is whether the paragraph is referring to unicast. " What it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an interface." If this comment is referring to unicast, the point remains is that there will be multiple SAs. We will not be able to adhere to the figure 3 requirements for unicast, and there will be full meshing of SAs required between all communicating OSPFs. Not so bad if using IKE. Really bad if using manual SAs.  

Here is the thread of notes being referred to (since it's been a couple of weeks):

Vishwas Manral <Vishwas@SINETT.COM>
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>

02/15/2005 12:01 AM
Please respond to Mailing List

       
        To:        OSPF@PEACH.EASE.LSOFT.COM
        cc:        
        Subject:        Re: Questions about OSPF v3 security draft



Hi Mike,
 
I think both the authors are on leave, so they will probably reply later.
 
However regarding the first point, I agree the wording should be clearer. However what it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an interface.
 
Regarding the second point, I think I too have brought the issue on this list and the reply I think was that the draft does not prohibit the use of IKE for unicast flows.
                                                                                                                                                         
Thanks,
Vishwas


From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox
Sent: Friday, February 11, 2005 8:04 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Questions about OSPF v3 security draft
 

Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, and the previous drafts, a couple of questions have come up in our shop.

1) Section 7, 2nd paragraph says "the implementations MUST use manually configured keys with same SA for inbound and outbound traffic (as shown in figure 3).  I assume the "same SA" MUST rule applies to multicast traffic only and not unicast traffic. This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP address. For unicast addresses, by definition there will be as many SAs as there are unicast destination addresses. Therefore, I don't think it is possible to apply this MUST rule given the current IPSec definition (RFC 2401 section 4.1) of an SA for unicast. Assuming the intention of the draft was to apply only to multicast and given the number of potential SAs carrying unicast traffic, it would seem that using IKE to setup the SAs dynamically would be a reasonable alternative to manual keying.    
 
2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel dynamically once it acquires the required information".  Since this traffic is unicast only, IKE could easily set up the required SAs without knowing the specific IP addresses in advance. Creating SAs dynamically do not fit easily within scope of manual SA functional capabilities. Why not use IKE for this traffic? Is this an acceptable option?  

Mike

--=_alternative 0076430A85256FB2_=-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 24 17:15:43 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28663 for ; Thu, 24 Feb 2005 17:15:43 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00FB24BA@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 17:15:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59288182 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 17:15:42 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 17:15:42 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2005 17:15:42 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1OMFX1l026935 for ; Thu, 24 Feb 2005 17:15:40 -0500 (EST) Received: from [10.82.241.145] (rtp-vpn2-401.cisco.com [10.82.241.145]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFO78150; Thu, 24 Feb 2005 14:15:32 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <421E5204.2000804@cisco.com> Date: Thu, 24 Feb 2005 17:15:32 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPFv3 Future Extendibility To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit At the Washington IETF, draft-mirtorabi-mt-ospfv3-01.txt was presented. While the goal of the draft is to support multi-topologies with a single OSPFv3 instance, the draft introduced the concept of TLV-based OSPFv3 LSAs in addition to the existing base RFC 2740 types. I was hoping this would generate more discussion but heretofore it has not. I see this as a very important decision with respect to the future of direction of OSPFv3 and believe it goes beyond multi-topology support. I would support this draft as I believe it will make our work easier in the future and eliminate the main advantage of ISIS over OSPF. Solutions involving carrying additional attributes in ancillary LSAs will always suffer from the issues involved with synchronizing the base LSA with the additional information in the new LSAs. So let's begin this discussion and I'm also thinking of reserving some time on OSPF WG agenda since I'd expect there will be interest. As for positioning versus draft-ietf-ospf-af-alt-01.txt, we will move forward with this draft as it provides a low implementation cost solution and isolation between address families via separate instance. BGP allows both today (i.e., support for multiple address families per session or separate of address families between sessions). Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 24 17:52:31 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02258 for ; Thu, 24 Feb 2005 17:52:30 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00FB26E8@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 17:52:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59291498 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 17:52:29 -0500 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 17:52:29 -0500 Received: (qmail 7344 invoked from network); 24 Feb 2005 22:52:27 -0000 Received: from unknown (HELO ?192.168.1.28?) (172.16.104.131) by lxmail.nj.us.utstar.com with SMTP; 24 Feb 2005 22:52:27 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20040921 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <421E5204.2000804@cisco.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <421E68C1.6010802@xebeo.com> Date: Thu, 24 Feb 2005 23:52:33 +0000 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: OSPFv3 Future Extendibility To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <421E5204.2000804@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: > > > As for positioning versus draft-ietf-ospf-af-alt-01.txt, we will move > forward > with this draft as it provides a low implementation cost solution and > isolation > between address families via separate instance. BGP allows both today > (i.e., > support for multiple address families per session or separate of address > families between sessions). As to BGP, the isolation suffers (-ed) from the fact that different families are normally carried on the same session and interesting priotization problems under load occur. That also causes as well non-trivial implementation/spec issues to avoid synchronization-loss/error handling cross-talk between families. Reading your draft that does not seem to happen but just keep that in mind when moving things forward, I would suggest, so it doesn't creep in ... thanks -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 24 18:06:05 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03993 for ; Thu, 24 Feb 2005 18:06:03 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00FB267F@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 18:06:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59292997 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 18:06:03 -0500 Received: from 192.51.44.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 18:06:02 -0500 Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail5.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id j1ON61PN016422 for ; Fri, 25 Feb 2005 08:06:01 +0900 (envelope-from kashima@jp.fujitsu.com) Received: from s1.gw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id j1ON60dQ003587 for ; Fri, 25 Feb 2005 08:06:00 +0900 (envelope-from kashima@jp.fujitsu.com) Received: from s1.gw.fujitsu.co.jp (s1 [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 5FF81370109 for ; Fri, 25 Feb 2005 08:06:00 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp (chisato.nd.net.fujitsu.co.jp [10.22.112.21]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 0ED0F37010A for ; Fri, 25 Feb 2005 08:06:00 +0900 (JST) Received: from mail1.nd.net.fujitsu.co.jp (k4.kh0110-222.dhcp.css.fujitsu.com [10.17.222.185]) by chisato.nd.net.fujitsu.co.jp (8.12.9p2/8.12.9) with SMTP id j1ON5xeO053567; Fri, 25 Feb 2005 08:05:59 +0900 (JST) (envelope-from kashima@jp.fujitsu.com) X-Mailer: EdMax Ver2.85.5F MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050216184114.GK7859@rtp-iosxdm1.cisco.com> <200502162321.j1GNLLeO047285@chisato.nd.net.fujitsu.co.jp> <20050224164733.GV9156@rtp-iosxdm1.cisco.com> Message-ID: <200502242305.j1ON5xeO053567@chisato.nd.net.fujitsu.co.jp> Date: Fri, 25 Feb 2005 08:05:52 +0900 Reply-To: Mailing List Sender: Mailing List From: KASHIMA Hiroaki Subject: Re: RestartState (draft-nguyen-ospf-restart-05.txt) Comments: To: Liem Nguyen To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050224164733.GV9156@rtp-iosxdm1.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Liem, I see. Thank you very much. -- kashima Liem Nguyen wrote: > kashima, > > On Thu, Feb 17, 2005 at 08:21:32AM +0900, KASHIMA Hiroaki wrote: > > Nguyen, > > > > I find some set/clear statements for RestartState in 2.2, > > but I cannot find read statement for it. > > I see; yes, 2.3 is one application. > But it can also be used in conjuction with the oob-resync draft > as a mechanism to start/stop oob-resync. > Note implementations can operate without the RestartState flag, > as long as the received RS-bit is properly reacted to. > > Thanks, > Liem > > > > Who read it? > > -- > > kashima > > > > > > Liem Nguyen wrote: > > > > > KASHIMA, > > > > > > On Wed, Feb 16, 2005 at 07:45:01PM +0900, KASHIMA Hiroaki wrote: > > > > Hello all. > > > > > > > > I have an question when studying > > > > draft-nguyen-ospf-{lls,resync,restart}-05.txt. > > > > > > > > Is the purpose of Restart flag (in restart-05.txt) > > > > only for Section 2.3? > > > > > > Its use is mentioned in 2.2. > > > It's needed regardless of the configuration setting in 2.3. > > > > > > > > > > In other words, is this flag not necessary > > > > when the configuration is not implemented? > > > > > > > > Thanks in regards. > > > > -- > > > > KASHIMA, Hiroaki > > > > Software group, > > > > SystemFront Division, Fujitsu Ltd From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 24 20:28:21 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17254 for ; Thu, 24 Feb 2005 20:28:20 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00FB28C7@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 20:28:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59301103 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 20:28:19 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 20:28:19 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2005 20:42:21 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,115,1107752400"; d="scan'208"; a="38350323:sNHT19879084" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1P1SG1j020794 for ; Thu, 24 Feb 2005 20:28:17 -0500 (EST) Received: from [10.82.241.145] (rtp-vpn2-401.cisco.com [10.82.241.145]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFO93553; Thu, 24 Feb 2005 17:28:16 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <421E5204.2000804@cisco.com> <421E68C1.6010802@xebeo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <421E7F2F.8030805@cisco.com> Date: Thu, 24 Feb 2005 20:28:15 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 Future Extendibility To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <421E68C1.6010802@xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit Tony Przygienda wrote: > Acee Lindem wrote: > >> >> >> As for positioning versus draft-ietf-ospf-af-alt-01.txt, we will move >> forward >> with this draft as it provides a low implementation cost solution and >> isolation >> between address families via separate instance. BGP allows both today >> (i.e., >> support for multiple address families per session or separate of address >> families between sessions). > > > > As to BGP, the isolation suffers (-ed) from the fact that different > families are normally > carried on the same session and interesting priotization problems > under load occur. That > also causes as > well non-trivial implementation/spec issues to avoid > synchronization-loss/error handling cross-talk between families. > Reading your > draft that does not seem to happen but just keep that in mind when > moving things > forward, I would suggest, so it doesn't creep in ... Hi Tony, Your comment on BGP is a good argument with going forward with the existing WG document. If you have suggestions or things that should be clarified in the OSPFv3 MT draft, please don't hesitate to bring them up. Of particular interest would be rules for encoding TLVs that would have made life easier had they been imposed from day one in ISIS or BGP. Thanks, Acee > > thanks > > -- tony > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 24 23:29:37 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03116 for ; Thu, 24 Feb 2005 23:29:37 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00FB2D01@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 23:29:37 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59313832 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 23:29:35 -0500 Received: from 207.217.121.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 23:29:35 -0500 Received: from h-68-164-89-21.snvacaid.dynamic.covad.net ([68.164.89.21] helo=earthlink.net) by pop-a065d19.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D4X6c-00030C-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 20:29:34 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <421EA48A.E8A94619@earthlink.net> Date: Thu, 24 Feb 2005 20:07:38 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: draft-nguyen-ospf-restart-05.txt : bit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit >"PEACH.EASE.LSOFT.COM LISTSERV Server (14.3)" wrote: > > Your message is being returned to you unprocessed because it looks like a > LISTSERV command, rather than material intended for distribution to the members > of the OSPF list. Please note that LISTSERV commands must ALWAYS be sent to the > LISTSERV address; if it was indeed a command you were attempting to issue, > please send it again to LISTSERV@PEACH.EASE.LSOFT.COM for execution. Otherwise, > please accept our apologies and try to rewrite the message with a slightly > different wording - for instance, change the first word of the message, enclose > it in quotation marks, insert a line of dashes at the beginning of your > message, etc. > > ------------------------------------------------------------------------ > > Subject: draft-nguyen-ospf-restart-05.txt > Date: Thu, 24 Feb 2005 15:06:12 -0800 > From: Erblichs > To: zinin@psg.com, akr@cisco.com, lhnguyen@cisco.com, > OSPF@PEACH.EASE.LSOFT.COM > > ok guys, > > I am sure that I am missing something here about > your implimentations of why you even need this bit. > > Wouldn't a simple method of delaying output of > a hello pkt when a interface comes up after a > graceful restart suffice? > > Yes, the minor stuff is to process hellos over > say 15 secs, set up the fields in the hello pkt > and then send hellos that are appropriate to the > recieved information... Yes, if hellos are lost > going to the restarting router, then those nbrs hellos > would not be seen and not stated in the hello > based reply by the restarting router. > > Thus all hellos recieved from nbrs, would see a > reply hello with that nbr stated.This would be a > transparent change vs the need to support this > new bit. > > Yes, for your knowledgeable people out there, demand > circuits suppresss hellos, so the hello sent on a > demand circuit with GR would need an flag to generate > a longer delay. However, I would expect this to > happen anyway... > > Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Sat Feb 26 20:55:52 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16299 for ; Sat, 26 Feb 2005 20:55:51 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00FB56F6@cherry.ease.lsoft.com>; Sat, 26 Feb 2005 20:55:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59531051 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 26 Feb 2005 20:55:43 -0500 Received: from 209.119.1.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 26 Feb 2005 20:55:43 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wnt.dc.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.006CF349@wnt.dc.lsoft.com>; Sat, 26 Feb 2005 20:55:43 -0500 Message-ID: Date: Sat, 26 Feb 2005 20:55:42 -0500 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF vishnuvardhan B Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt Comments: To: sina@CISCO.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hello , Still the issue of interdependency between primary and secondary is not clear to me. so i am giving an example to explain the configuration: I have made the link with ip 10.1.1.1 in backbone(primary adjacency comes up) with the command >>>>network 10.1.1.1 0.0.0.0 area 0 Now i am making the same link to be part of area 1(secondary adjacency comes up) with another command. Now i am removing the link from the backbone by issuing the command >>>>no network 10.1.1.1 0.0.0.0 area 0 Now whether the link should still be considered in area 1(i.e secondary adjacency should still exist)? Thanks in Advance, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Sun Feb 27 20:47:32 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24189 for ; Sun, 27 Feb 2005 20:47:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00FB6E49@cherry.ease.lsoft.com>; 27 Feb 2005 20:47:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59632382 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 27 Feb 2005 20:47:24 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 27 Feb 2005 20:47:24 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 27 Feb 2005 21:01:59 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,120,1107752400"; d="scan'208"; a="38613958:sNHT19430844" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1S1lKhF013066 for ; Sun, 27 Feb 2005 20:47:20 -0500 (EST) Received: from [10.82.217.179] (rtp-vpn3-433.cisco.com [10.82.217.179]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFQ27660; Sun, 27 Feb 2005 17:47:21 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42227829.80004@cisco.com> Date: Sun, 27 Feb 2005 20:47:21 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Vishnu, SUBSCRIBE OSPF vishnuvardhan B wrote: >Hello , >Still the issue of interdependency between primary and secondary is not >clear to me. > There is none. >so i am giving an example to explain the configuration: > > >I have made the link with ip 10.1.1.1 in backbone(primary adjacency comes >up) with the command > > >>>>>network 10.1.1.1 0.0.0.0 area 0 >>>>> >>>>> > >Now i am making the same link to be part of area 1(secondary adjacency >comes up) with another command. > >Now i am removing the link from the backbone by issuing the command > > >>>>>no network 10.1.1.1 0.0.0.0 area 0 >>>>> >>>>> > >Now whether the link should still be considered in area 1(i.e secondary >adjacency should still exist)? > > The secondary ajacenci(es) would need to be configured separately and independent of the primary interface. > >Thanks in Advance, >Vishnu > > >