draft-ietf-ospf-ospfv3-auth-04.txt

From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 2 00:21:01 2004 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 AAA21440 for ; Fri, 2 Jul 2004 00:21:00 -0400 (EDT) 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.00E01E5A@cherry.ease.lsoft.com>; Fri, 2 Jul 2004 0:10:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24070173 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 2 Jul 2004 00:10:32 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 2 Jul 2004 00:10:27 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45FEA.D8BE7344" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRdmwZVHkBCqjaeSuGz4FzDGv5/cwCTqRYg Message-ID: Date: Thu, 1 Jul 2004 21:12:53 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C45FEA.D8BE7344 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Not sure if this got through earlier. Reforwarding. =20 -Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of = Vishwas Manral Sent: Tuesday, June 29, 2004 11:14 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: draft-ietf-ospf-ospfv3-auth-04.txt Hi,=20 I just did a quick read of the draft, and had some comments: -=20 1. I am not sure we should have a statement which says OSPFv3 is only = for IPv6.=20 "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction = between the packets can be easily made by IP version. " 2. I think the value of next header field in the ESP header to indicate = OSPFv3 should be specified, though it may seem a trivial question. 3. ESP already states that "integrity-only (MUST be supported)" do we = really need to put down "ESP with NULL encryption MUST be supported in = transport mode". 4. I think we may want to state that Authentication service must always = be supported whenever we do encryption. Our primary aim is to have data = integrity right(anyway encryption only service is a MAY for ESP)? 5. OSPF packets received in clear text or with incorrect AH Integrity = Check Value (ICV) MUST be dropped when authentication is enabled.=20 Do we mean only AH/ICV or do we need ESP ICV too? Besides do we need to = state about combined mode algorithms like AES-CCM where ICV may not = checked even when authentication is done. 6. SA Granularity and Selectors section - I think you are referring to = parallel links we may want to state that too.=20 7. Changing Keys may also be required in case of sequence number = rollover.=20 8. Would we want to refer to the newer drafts for ESP/AH drafts rather = then the old RFC's itself?=20 Thanks,=20 Vishwas=20 ------_=_NextPart_001_01C45FEA.D8BE7344 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-ospf-ospfv3-auth-04.txt

Not=20 sure if this got through earlier. Reforwarding.

-Vishwas

-----Original Message-----
From: Mailing List=20 [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Vishwas=20 Manral
Sent: Tuesday, June 29, 2004 11:14 AM
To:=20 OSPF@PEACH.EASE.LSOFT.COM
Subject:=20 draft-ietf-ospf-ospfv3-auth-04.txt

Hi,

I just did a quick read of the draft, = and had some=20 comments: -

1. I am not sure we should have a = statement which=20 says OSPFv3 is only for IPv6.
"As=20 OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction = between=20 the packets can be easily made by IP version. "

2. I think the value of next header = field in=20 the ESP header to indicate OSPFv3 should be specified, though it may = seem a=20 trivial question.

3. ESP already states that = "integrity-only=20 (MUST be supported)" do we really need to put down "ESP with NULL = encryption=20 MUST be supported in transport mode".

4. I think we may want to state that = Authentication service must always be supported whenever we do = encryption. Our=20 primary aim is to have data integrity right(anyway encryption only = service is=20 a MAY for ESP)?

5. OSPF packets received in clear = text or with=20 incorrect AH Integrity Check Value (ICV) MUST be dropped when = authentication=20 is enabled.

Do we mean only AH/ICV or do we need = ESP ICV=20 too? Besides do we need to state about combined mode algorithms like = AES-CCM=20 where ICV may not checked even when authentication is done.

6. SA Granularity and Selectors = section - I=20 think you are referring to parallel links we may want to state that=20 too.
7. Changing Keys may = also be=20 required in case of sequence number rollover.
8. Would we want to refer to the newer drafts = for=20 ESP/AH drafts rather then the old RFC's itself?
Thanks,
Vishwas =

------_=_NextPart_001_01C45FEA.D8BE7344-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 2 14:22:13 2004 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 OAA25568 for ; Fri, 2 Jul 2004 14:22:12 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00E02E5B@cherry.ease.lsoft.com>; Fri, 2 Jul 2004 14:22:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24180112 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 2 Jul 2004 14:22:10 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 2 Jul 2004 14:22:10 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 878E29CC2DF for ; Fri, 2 Jul 2004 11:22:09 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29734-03 for ; Fri, 2 Jul 2004 11:22:09 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.64]) by prattle.redback.com (Postfix) with SMTP id 466F99CC2DD for ; Fri, 2 Jul 2004 11:22:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0A32_01C4603F.C42B3A70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0a4701c46061$764f76f0$0202a8c0@aceeinspiron> Date: Fri, 2 Jul 2004 14:20:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Fw: I-D ACTION:draft-lindem-ospf-route-attr-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0A32_01C4603F.C42B3A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This draft describes a mechanism for attaching extra attributes to OSPF advertised routes. It also describes the propagation of the attributes across area boundaries. The driving application is support of "Nexthop Fast ReRoute for IP and MPLS" as described in . The draft also offers an alternative to as a mechanism for attaching administrative tags to OSPF intra-area and inter-area routes. Note that the next verision of the draft will include an informative reference to the ISIS adminstrative tag draft (before somebody asks why I didn't include one). This was simply an oversight. I will present it at the San Diego IETF. Thanks, Acee ----- Original Message ----- From: To: Sent: Friday, June 25, 2004 10:00 AM Subject: I-D ACTION:draft-lindem-ospf-route-attr-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Extensions to OSPF for Advertising Optional Route Attributes > Author(s) : A. Lindem, N. Shen > Filename : draft-lindem-ospf-route-attr-00.txt > Pages : 13 > Date : 2004-6-24 > > There are applications which require additional attributes to > be advertised with an OSPF route. The existing OSPF LSA > formats do not allow for backward compatible extension to advertise > these attributes. This draft proposes an extension to OSPF for > advertising additional attributes which will be associated with an > OSPF route. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lindem-ospf-route-attr-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-lindem-ospf-route-attr-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-lindem-ospf-route-attr-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > ------=_NextPart_000_0A32_01C4603F.C42B3A70 Content-Type: application/octet-stream; name="ATT02605.dat" Content-Disposition: attachment; filename="ATT02605.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-6-25102425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lindem-ospf-route-attr-00.txt ------=_NextPart_000_0A32_01C4603F.C42B3A70 Content-Type: text/plain; name="draft-lindem-ospf-route-attr-00.txt" Content-Disposition: attachment; filename="draft-lindem-ospf-route-attr-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-6-25102425.I-D@ietf.org> ------=_NextPart_000_0A32_01C4603F.C42B3A70-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 5 15:21:52 2004 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 PAA13664 for ; Mon, 5 Jul 2004 15:21:52 -0400 (EDT) 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.00E06C15@cherry.ease.lsoft.com>; Mon, 5 Jul 2004 15:21:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24580526 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 5 Jul 2004 15:21:29 -0400 Received: from 131.228.20.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 5 Jul 2004 15:21:28 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i65JLP227698 for ; Mon, 5 Jul 2004 22:21:25 +0300 (EET DST) X-Scanned: Mon, 5 Jul 2004 22:20:51 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i65JKpkg015407 for ; Mon, 5 Jul 2004 22:20:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00r258Ho; Mon, 05 Jul 2004 22:20:48 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i65JKlH08209 for ; Mon, 5 Jul 2004 22:20:48 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Jul 2004 14:19:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRdmwZVHkBCqjaeSuGz4FzDGv5/cwFIVTXQ X-OriginalArrivalTime: 05 Jul 2004 19:19:26.0469 (UTC) FILETIME=[FCA04350:01C462C4] Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A87@daebe009.americas.nokia.com> Date: Mon, 5 Jul 2004 14:19:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Vishwas, Thanks for the comments. Please see my comments inline.. > 1. I am not sure we should have a statement which says OSPFv3=20 > is only for IPv6.=20 > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6,=20 > the distinction between the packets can be easily made by=20 > IP version. " Do you have a replacement statement that you would prefer ? As the IP protocol type value for OSPF and OSPFv3 is same, we have to depend upon the IP version to separate OSPF and OSPFv3 packets. > 2. I think the value of next header field in the ESP header=20 > to indicate OSPFv3 should be specified, though it may seem=20 > a trivial question. Why do you think it should be specified? Whenever ESP is applied to any IP packet, the IP Protocol Type field value from the IP header is copied to the next header field of ESP/AH. There are no exceptions here. > 3. ESP already states that "integrity-only (MUST be supported)"=20 > do we really need to put down "ESP with NULL encryption MUST be=20 > supported in transport mode". An implementation may support ESP/AH that conform to ESP/AH RFCs, but the idea of putting this in this draft was to ensure that the user is allowed to use the specified combinations for securing the OSPF traffic. So that 2 independent secured OSPF=20 implementations have at least one common combination to configure. Do you see any harm in putting this text in the draft ? > 4. I think we may want to state that Authentication service must=20 > always be supported whenever we do encryption. Our primary aim is=20 > to have data integrity right(anyway encryption only service is a=20 > MAY for ESP)? Doesn't the sentence "Providing confidentiality to OSPFv3 in addition=20 to authentication is optional." imply that ? Or would it better to replace=20 "ESP with non-null encryption in transport mode MUST be used=20 for providing the confidentiality to OSPFv3."=20 with=20 "ESP with non-null encryption and non-null authentication in transport=20 mode MUST be used for providing the confidentiality to OSPFv3." > 5. OSPF packets received in clear text or with incorrect AH=20 > Integrity Check Value (ICV) MUST be dropped when authentication is=20 > enabled.=20 > Do we mean only AH/ICV or do we need ESP ICV too? Besides do we=20 > need to state about combined mode algorithms like AES-CCM where=20 > ICV may not checked even when authentication is done. It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the=20 next version. The draft for AES-CCM says "it is inappropriate to use this CCM with statically configured keys". We are using staticaly configured keys here. So should we just NOT use AES-CCM ? > 6. SA Granularity and Selectors section - I think you are referring=20 > to parallel links we may want to state that too.=20 No I am not referring to parallel links (if you mean 2 links connecting the same routers). It should be possible to use the same SA for = multiple=20 interfaces belonging to even different areas. > 7. Changing Keys may also be required in case of sequence number = rollover. How is the user going to know about the sequence number rollover ? so that he/she can initiate the key change. That brings an interesting question. If the user never changes the keys, what happens when the sequence number rollovers ? > 8. Would we want to refer to the newer drafts for ESP/AH drafts rather = > then the old RFC's itself?=20 That's a good idea but the problem is that if we put the new drafts=20 as normative references, this draft will not be published before those=20 drafts. Do we want to block the draft waiting for those drafts ? The draft was reviewed by the IESG on June 26th and the comments can=20 be seen at = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D9745&rfc_flag=3D0 We will be working on addressing all the comments now and will publish an updated version of the draft probably after the IETF 60th. regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 6 00:30:50 2004 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 AAA05061 for ; Tue, 6 Jul 2004 00:30:49 -0400 (EDT) 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.00E075B6@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 0:30:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24634006 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 00:30:44 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 00:30:44 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRdmwZVHkBCqjaeSuGz4FzDGv5/cwFIVTXQABRyoGA= Message-ID: Date: Mon, 5 Jul 2004 21:33:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mukesh, >>1. I am not sure we should have a statement which says OSPFv3=20 >>is only for IPv6.=20 >>"As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6,=20 >> the distinction between the packets can be easily made by=20 >> IP version. " >Do you have a replacement statement that you would prefer ? >As the IP protocol type value for OSPF and OSPFv3 is same, >we have to depend upon the IP version to separate OSPF and >OSPFv3 packets. There is a distinction between running over and "only for"(which=20 I assumed you meant the contents). It seems you mean running over. >>2. I think the value of next header field in the ESP header=20 >>to indicate OSPFv3 should be specified, though it may seem=20 >>a trivial question. >Why do you think it should be specified? Whenever ESP is >applied to any IP packet, the IP Protocol Type field value >from the IP header is copied to the next header field of >ESP/AH. There are no exceptions here. The whole draft is full of informational statements like: - "AH in transport mode provides authentication to higher layer protocols, selected portions of IPv6 header, selected portions of extension headers and selected options. ESP with NULL encryption in transport mode will provide authentication to only higher layer protocol data and not to the IPv6 header, extension headers and options." I think putting what the value in the next header would be would be helpful. >>3. ESP already states that "integrity-only (MUST be supported)"=20 >>do we really need to put down "ESP with NULL encryption MUST be=20 >>supported in transport mode". >An implementation may support ESP/AH that conform to ESP/AH RFCs, >but the idea of putting this in this draft was to ensure that the >user is allowed to use the specified combinations for securing >the OSPF traffic. So that 2 independent secured OSPF=20 >implementations have at least one common combination to configure. >Do you see any harm in putting this text in the draft ? Not at all, but I am unable to see the point of=20 "ESP with NULL encryption MUST be supported in transport mode". The=20 point is we are saying a restriction on ESP MUST be there, where ESP=20 already has said its a MUST in the protocol itself. I think we may=20 also want to state other things then, like using ESN(if its supported),=20 default authentication/encryption algorithm etc when using manual = keying. >>5. OSPF packets received in clear text or with incorrect AH=20 >>Integrity Check Value (ICV) MUST be dropped when authentication is=20 >>enabled.=20 >> Do we mean only AH/ICV or do we need ESP ICV too? Besides do we=20 >>need to state about combined mode algorithms like AES-CCM where=20 >>ICV may not checked even when authentication is done. >It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the=20 >next version. >The draft for AES-CCM says "it is inappropriate to use this CCM >with statically configured keys". We are using staticaly configured >keys here. So should we just NOT use AES-CCM ? AES-CCM is an example of a combined mode algorithm, there are other and can be further combined mode algorithms. We shouldn't put any=20 restriction that is based on the algorithm we use. From ESP "For combined mode algorithms, the ICV that would normally=20 appear at the end of the ESP packet (when integrity is selected) may=20 be omitted. " >>6. SA Granularity and Selectors section - I think you are referring=20 >>to parallel links we may want to state that too.=20 >No I am not referring to parallel links (if you mean 2 links connecting >the same routers). It should be possible to use the same SA for = multiple=20 >interfaces belonging to even different areas. May be text clarifying what you mean should be put. Also text to state=20 whether in case of parallel links we need to have one SA or not can be=20 clarified. >>7. Changing Keys may also be required in case of sequence number = rollover. >How is the user going to know about the sequence number rollover ? >so that he/she can initiate the key change. That brings an interesting >question. If the user never changes the keys, what happens when the >sequence number rollovers ? There are a lot of ways to provide that, a simple way could be to poll = at some interval, and when we are near rollover we change the keys. From ESP=20 "Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA." This is in case of normal SN, when we use ESN that will change, I think. >That's a good idea but the problem is that if we put the new drafts=20 >as normative references, this draft will not be published before those=20 >drafts. Do we want to block the draft waiting for those drafts ? I think that is the authors wish. >We will be working on addressing all the comments now and will publish >an updated version of the draft probably after the IETF 60th. That would be great. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Mukesh.Gupta@NOKIA.COM Sent: Tuesday, July 06, 2004 12:49 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Hi Vishwas, Thanks for the comments. Please see my comments inline.. > 1. I am not sure we should have a statement which says OSPFv3=20 > is only for IPv6.=20 > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6,=20 > the distinction between the packets can be easily made by=20 > IP version. " Do you have a replacement statement that you would prefer ? As the IP protocol type value for OSPF and OSPFv3 is same, we have to depend upon the IP version to separate OSPF and OSPFv3 packets. > 2. I think the value of next header field in the ESP header=20 > to indicate OSPFv3 should be specified, though it may seem=20 > a trivial question. Why do you think it should be specified? Whenever ESP is applied to any IP packet, the IP Protocol Type field value from the IP header is copied to the next header field of ESP/AH. There are no exceptions here. > 3. ESP already states that "integrity-only (MUST be supported)"=20 > do we really need to put down "ESP with NULL encryption MUST be=20 > supported in transport mode". An implementation may support ESP/AH that conform to ESP/AH RFCs, but the idea of putting this in this draft was to ensure that the user is allowed to use the specified combinations for securing the OSPF traffic. So that 2 independent secured OSPF=20 implementations have at least one common combination to configure. Do you see any harm in putting this text in the draft ? > 4. I think we may want to state that Authentication service must=20 > always be supported whenever we do encryption. Our primary aim is=20 > to have data integrity right(anyway encryption only service is a=20 > MAY for ESP)? Doesn't the sentence "Providing confidentiality to OSPFv3 in addition=20 to authentication is optional." imply that ? Or would it better to replace=20 "ESP with non-null encryption in transport mode MUST be used=20 for providing the confidentiality to OSPFv3."=20 with=20 "ESP with non-null encryption and non-null authentication in transport=20 mode MUST be used for providing the confidentiality to OSPFv3." > 5. OSPF packets received in clear text or with incorrect AH=20 > Integrity Check Value (ICV) MUST be dropped when authentication is=20 > enabled.=20 > Do we mean only AH/ICV or do we need ESP ICV too? Besides do we=20 > need to state about combined mode algorithms like AES-CCM where=20 > ICV may not checked even when authentication is done. It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the=20 next version. The draft for AES-CCM says "it is inappropriate to use this CCM with statically configured keys". We are using staticaly configured keys here. So should we just NOT use AES-CCM ? > 6. SA Granularity and Selectors section - I think you are referring=20 > to parallel links we may want to state that too.=20 No I am not referring to parallel links (if you mean 2 links connecting the same routers). It should be possible to use the same SA for = multiple=20 interfaces belonging to even different areas. > 7. Changing Keys may also be required in case of sequence number = rollover. How is the user going to know about the sequence number rollover ? so that he/she can initiate the key change. That brings an interesting question. If the user never changes the keys, what happens when the sequence number rollovers ? > 8. Would we want to refer to the newer drafts for ESP/AH drafts rather = > then the old RFC's itself?=20 That's a good idea but the problem is that if we put the new drafts=20 as normative references, this draft will not be published before those=20 drafts. Do we want to block the draft waiting for those drafts ? The draft was reviewed by the IESG on June 26th and the comments can=20 be seen at = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D9745&rfc_flag=3D0 We will be working on addressing all the comments now and will publish an updated version of the draft probably after the IETF 60th. regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 6 00:35:22 2004 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 AAA05245 for ; Tue, 6 Jul 2004 00:35:21 -0400 (EDT) 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.00E076E4@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 0:35:23 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24635026 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 00:35:21 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 00:35:21 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRdmwZVHkBCqjaeSuGz4FzDGv5/cwFIVTXQABRyoGAAAN4IkA== Message-ID: Date: Mon, 5 Jul 2004 21:37:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mukesh, Just wanted to add from ESP "If anti-replay is enabled (the default), the transmitted Sequence = Number must never be allowed to cycle." I think there is no consistent = way a sender or receiver would work after rollover. The receiver could = very well break the SA on rollover(I think). Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Vishwas Manral Sent: Tuesday, July 06, 2004 10:03 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Hi Mukesh, >>1. I am not sure we should have a statement which says OSPFv3=20 >>is only for IPv6.=20 >>"As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6,=20 >> the distinction between the packets can be easily made by=20 >> IP version. " >Do you have a replacement statement that you would prefer ? >As the IP protocol type value for OSPF and OSPFv3 is same, >we have to depend upon the IP version to separate OSPF and >OSPFv3 packets. There is a distinction between running over and "only for"(which=20 I assumed you meant the contents). It seems you mean running over. >>2. I think the value of next header field in the ESP header=20 >>to indicate OSPFv3 should be specified, though it may seem=20 >>a trivial question. >Why do you think it should be specified? Whenever ESP is >applied to any IP packet, the IP Protocol Type field value >from the IP header is copied to the next header field of >ESP/AH. There are no exceptions here. The whole draft is full of informational statements like: - "AH in transport mode provides authentication to higher layer protocols, selected portions of IPv6 header, selected portions of extension headers and selected options. ESP with NULL encryption in transport mode will provide authentication to only higher layer protocol data and not to the IPv6 header, extension headers and options." I think putting what the value in the next header would be would be helpful. >>3. ESP already states that "integrity-only (MUST be supported)"=20 >>do we really need to put down "ESP with NULL encryption MUST be=20 >>supported in transport mode". >An implementation may support ESP/AH that conform to ESP/AH RFCs, >but the idea of putting this in this draft was to ensure that the >user is allowed to use the specified combinations for securing >the OSPF traffic. So that 2 independent secured OSPF=20 >implementations have at least one common combination to configure. >Do you see any harm in putting this text in the draft ? Not at all, but I am unable to see the point of=20 "ESP with NULL encryption MUST be supported in transport mode". The=20 point is we are saying a restriction on ESP MUST be there, where ESP=20 already has said its a MUST in the protocol itself. I think we may=20 also want to state other things then, like using ESN(if its supported),=20 default authentication/encryption algorithm etc when using manual = keying. >>5. OSPF packets received in clear text or with incorrect AH=20 >>Integrity Check Value (ICV) MUST be dropped when authentication is=20 >>enabled.=20 >> Do we mean only AH/ICV or do we need ESP ICV too? Besides do we=20 >>need to state about combined mode algorithms like AES-CCM where=20 >>ICV may not checked even when authentication is done. >It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the=20 >next version. >The draft for AES-CCM says "it is inappropriate to use this CCM >with statically configured keys". We are using staticaly configured >keys here. So should we just NOT use AES-CCM ? AES-CCM is an example of a combined mode algorithm, there are other and can be further combined mode algorithms. We shouldn't put any=20 restriction that is based on the algorithm we use. From ESP "For combined mode algorithms, the ICV that would normally=20 appear at the end of the ESP packet (when integrity is selected) may=20 be omitted. " >>6. SA Granularity and Selectors section - I think you are referring=20 >>to parallel links we may want to state that too.=20 >No I am not referring to parallel links (if you mean 2 links connecting >the same routers). It should be possible to use the same SA for = multiple=20 >interfaces belonging to even different areas. May be text clarifying what you mean should be put. Also text to state=20 whether in case of parallel links we need to have one SA or not can be=20 clarified. >>7. Changing Keys may also be required in case of sequence number = rollover. >How is the user going to know about the sequence number rollover ? >so that he/she can initiate the key change. That brings an interesting >question. If the user never changes the keys, what happens when the >sequence number rollovers ? There are a lot of ways to provide that, a simple way could be to poll = at some interval, and when we are near rollover we change the keys. From ESP=20 "Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA." This is in case of normal SN, when we use ESN that will change, I think. >That's a good idea but the problem is that if we put the new drafts=20 >as normative references, this draft will not be published before those=20 >drafts. Do we want to block the draft waiting for those drafts ? I think that is the authors wish. >We will be working on addressing all the comments now and will publish >an updated version of the draft probably after the IETF 60th. That would be great. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Mukesh.Gupta@NOKIA.COM Sent: Tuesday, July 06, 2004 12:49 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Hi Vishwas, Thanks for the comments. Please see my comments inline.. > 1. I am not sure we should have a statement which says OSPFv3=20 > is only for IPv6.=20 > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6,=20 > the distinction between the packets can be easily made by=20 > IP version. " Do you have a replacement statement that you would prefer ? As the IP protocol type value for OSPF and OSPFv3 is same, we have to depend upon the IP version to separate OSPF and OSPFv3 packets. > 2. I think the value of next header field in the ESP header=20 > to indicate OSPFv3 should be specified, though it may seem=20 > a trivial question. Why do you think it should be specified? Whenever ESP is applied to any IP packet, the IP Protocol Type field value from the IP header is copied to the next header field of ESP/AH. There are no exceptions here. > 3. ESP already states that "integrity-only (MUST be supported)"=20 > do we really need to put down "ESP with NULL encryption MUST be=20 > supported in transport mode". An implementation may support ESP/AH that conform to ESP/AH RFCs, but the idea of putting this in this draft was to ensure that the user is allowed to use the specified combinations for securing the OSPF traffic. So that 2 independent secured OSPF=20 implementations have at least one common combination to configure. Do you see any harm in putting this text in the draft ? > 4. I think we may want to state that Authentication service must=20 > always be supported whenever we do encryption. Our primary aim is=20 > to have data integrity right(anyway encryption only service is a=20 > MAY for ESP)? Doesn't the sentence "Providing confidentiality to OSPFv3 in addition=20 to authentication is optional." imply that ? Or would it better to replace=20 "ESP with non-null encryption in transport mode MUST be used=20 for providing the confidentiality to OSPFv3."=20 with=20 "ESP with non-null encryption and non-null authentication in transport=20 mode MUST be used for providing the confidentiality to OSPFv3." > 5. OSPF packets received in clear text or with incorrect AH=20 > Integrity Check Value (ICV) MUST be dropped when authentication is=20 > enabled.=20 > Do we mean only AH/ICV or do we need ESP ICV too? Besides do we=20 > need to state about combined mode algorithms like AES-CCM where=20 > ICV may not checked even when authentication is done. It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the=20 next version. The draft for AES-CCM says "it is inappropriate to use this CCM with statically configured keys". We are using staticaly configured keys here. So should we just NOT use AES-CCM ? > 6. SA Granularity and Selectors section - I think you are referring=20 > to parallel links we may want to state that too.=20 No I am not referring to parallel links (if you mean 2 links connecting the same routers). It should be possible to use the same SA for = multiple=20 interfaces belonging to even different areas. > 7. Changing Keys may also be required in case of sequence number = rollover. How is the user going to know about the sequence number rollover ? so that he/she can initiate the key change. That brings an interesting question. If the user never changes the keys, what happens when the sequence number rollovers ? > 8. Would we want to refer to the newer drafts for ESP/AH drafts rather = > then the old RFC's itself?=20 That's a good idea but the problem is that if we put the new drafts=20 as normative references, this draft will not be published before those=20 drafts. Do we want to block the draft waiting for those drafts ? The draft was reviewed by the IESG on June 26th and the comments can=20 be seen at = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D9745&rfc_flag=3D0 We will be working on addressing all the comments now and will publish an updated version of the draft probably after the IETF 60th. regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 6 01:03:16 2004 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 BAA06925 for ; Tue, 6 Jul 2004 01:03:16 -0400 (EDT) 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.00E07561@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 1:03:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24637388 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 01:03:13 -0400 Received: from 216.82.255.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 01:03:13 -0400 X-VirusChecked: Checked X-Env-Sender: rmalhotra@bankofny.com X-Msg-Ref: server-14.tower-53.messagelabs.com!1089090192!10097881 X-StarScan-Version: 5.2.10; banners=bankofny.com,-,- X-Originating-IP: [160.254.107.25] Received: (qmail 19766 invoked from network); 6 Jul 2004 05:03:12 -0000 Received: from unknown (HELO lgsbrc01.bankofny.com) (160.254.107.25) by server-14.tower-53.messagelabs.com with SMTP; 6 Jul 2004 05:03:12 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Tue, 6 Jul 2004 01:03:11 -0400 Reply-To: Mailing List Sender: Mailing List From: rmalhotra@BANKOFNY.COM Subject: Ravi Malhotra is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office starting 07/02/2004 and will not return until 07/07/2004. I will respond to your message when I return. Thank You, Ravi Malhotra ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 6 01:34:14 2004 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 BAA08175 for ; Tue, 6 Jul 2004 01:34:14 -0400 (EDT) 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.00E076C6@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 1:34:13 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24639144 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 01:34:12 -0400 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 01:34:12 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 05 Jul 2004 22:34:54 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i665Y9gI020211 for ; Mon, 5 Jul 2004 22:34:10 -0700 (PDT) Received: from irp-view9.cisco.com (irp-view9.cisco.com [171.70.65.147]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVC28092; Mon, 5 Jul 2004 22:32:58 -0700 (PDT) References: <8D260779A766FB4A9C1739A476F84FA401F79A87@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 5 Jul 2004 22:34:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F79A87@daebe009.americas.nokia.com> Precedence: list On 07/05/04-0500 at 2:19pm, Mukesh.Gupta@NOKIA.COM writes: > Hi Vishwas, > > Thanks for the comments. Please see my comments inline.. > > > 1. I am not sure we should have a statement which says OSPFv3 > > is only for IPv6. > > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > the distinction between the packets can be easily made by > > IP version. " > > Do you have a replacement statement that you would prefer ? > As the IP protocol type value for OSPF and OSPFv3 is same, > we have to depend upon the IP version to separate OSPF and > OSPFv3 packets. Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux will be based on OSPF protocol version. Regards, -Roy- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 6 01:39:20 2004 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 BAA08352 for ; Tue, 6 Jul 2004 01:39:20 -0400 (EDT) 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.00E077EF@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 1:39:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24640166 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 01:39:18 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 01:39:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRjGz1cY8AME/dKRoC9SjwIOmM8jwAAOqDg Message-ID: Date: Mon, 5 Jul 2004 22:41:54 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Abhay, Good point, didnt know the draft was actually out(actually I think = Sina/Michael actually started working on it togather a long long while = back before the idea was dropped). Just curious would we still use IPSec = or would we use the current authentication mechanism? To add further, we intend to add a draft to allow out of order sequence = of packets with authentication enabled like in IPSec for OSPFv2 too. (IP = does not guarentee inorder dilevery anyway/besides we can allow for = packet prioritization) Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Abhay Roy Sent: Tuesday, July 06, 2004 11:04 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt On 07/05/04-0500 at 2:19pm, Mukesh.Gupta@NOKIA.COM writes: > Hi Vishwas, > > Thanks for the comments. Please see my comments inline.. > > > 1. I am not sure we should have a statement which says OSPFv3 > > is only for IPv6. > > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > the distinction between the packets can be easily made by > > IP version. " > > Do you have a replacement statement that you would prefer ? > As the IP protocol type value for OSPF and OSPFv3 is same, > we have to depend upon the IP version to separate OSPF and > OSPFv3 packets. Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux will be based on OSPF protocol version. Regards, -Roy- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 6 10:57:32 2004 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 KAA21380 for ; Tue, 6 Jul 2004 10:57:31 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00E08192@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 10:57:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24717739 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 10:57:28 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 10:57:27 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 16B08BF9263 for ; Tue, 6 Jul 2004 07:57:25 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12730-09 for ; Tue, 6 Jul 2004 07:57:24 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.16]) by prattle.redback.com (Postfix) with SMTP id BBB9E3B023D for ; Tue, 6 Jul 2004 07:49:43 -0700 (PDT) References: <8D260779A766FB4A9C1739A476F84FA401F79A87@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <014b01c46368$743bc800$0202a8c0@aceeinspiron> Date: Tue, 6 Jul 2004 10:49:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Even though this has gone through WG last call it may be a good to schedule some time at the San Deigo IETF to discuss recent issues and how they are addressed in the new draft. Comments? ----- Original Message ----- From: To: Sent: Monday, July 05, 2004 3:19 PM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Hi Vishwas, Thanks for the comments. Please see my comments inline.. > 1. I am not sure we should have a statement which says OSPFv3 > is only for IPv6. > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > the distinction between the packets can be easily made by > IP version. " Do you have a replacement statement that you would prefer ? As the IP protocol type value for OSPF and OSPFv3 is same, we have to depend upon the IP version to separate OSPF and OSPFv3 packets. > 2. I think the value of next header field in the ESP header > to indicate OSPFv3 should be specified, though it may seem > a trivial question. Why do you think it should be specified? Whenever ESP is applied to any IP packet, the IP Protocol Type field value from the IP header is copied to the next header field of ESP/AH. There are no exceptions here. > 3. ESP already states that "integrity-only (MUST be supported)" > do we really need to put down "ESP with NULL encryption MUST be > supported in transport mode". An implementation may support ESP/AH that conform to ESP/AH RFCs, but the idea of putting this in this draft was to ensure that the user is allowed to use the specified combinations for securing the OSPF traffic. So that 2 independent secured OSPF implementations have at least one common combination to configure. Do you see any harm in putting this text in the draft ? > 4. I think we may want to state that Authentication service must > always be supported whenever we do encryption. Our primary aim is > to have data integrity right(anyway encryption only service is a > MAY for ESP)? Doesn't the sentence "Providing confidentiality to OSPFv3 in addition to authentication is optional." imply that ? Or would it better to replace "ESP with non-null encryption in transport mode MUST be used for providing the confidentiality to OSPFv3." with "ESP with non-null encryption and non-null authentication in transport mode MUST be used for providing the confidentiality to OSPFv3." > 5. OSPF packets received in clear text or with incorrect AH > Integrity Check Value (ICV) MUST be dropped when authentication is > enabled. > Do we mean only AH/ICV or do we need ESP ICV too? Besides do we > need to state about combined mode algorithms like AES-CCM where > ICV may not checked even when authentication is done. It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the next version. The draft for AES-CCM says "it is inappropriate to use this CCM with statically configured keys". We are using staticaly configured keys here. So should we just NOT use AES-CCM ? > 6. SA Granularity and Selectors section - I think you are referring > to parallel links we may want to state that too. No I am not referring to parallel links (if you mean 2 links connecting the same routers). It should be possible to use the same SA for multiple interfaces belonging to even different areas. > 7. Changing Keys may also be required in case of sequence number rollover. How is the user going to know about the sequence number rollover ? so that he/she can initiate the key change. That brings an interesting question. If the user never changes the keys, what happens when the sequence number rollovers ? > 8. Would we want to refer to the newer drafts for ESP/AH drafts rather > then the old RFC's itself? That's a good idea but the problem is that if we put the new drafts as normative references, this draft will not be published before those drafts. Do we want to block the draft waiting for those drafts ? The draft was reviewed by the IESG on June 26th and the comments can be seen at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9745&rfc_flag=0 We will be working on addressing all the comments now and will publish an updated version of the draft probably after the IETF 60th. regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 6 17:22:33 2004 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 RAA24066 for ; Tue, 6 Jul 2004 17:22:33 -0400 (EDT) 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.00E08909@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 17:22:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24757985 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 17:22:32 -0400 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 17:22:32 -0400 Received: (qmail 27206 invoked by uid 404); 6 Jul 2004 21:22:31 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.862567 secs); 06 Jul 2004 21:22:31 -0000 Received: from web.xebeo.com (HELO web.nj.us.utstar.com) (192.168.0.3) by lxmail.xebeo.com with SMTP; 6 Jul 2004 21:22:30 -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 RAA23110; Tue, 6 Jul 2004 17:22:29 -0400 Message-ID: <200407062122.RAA23110@web.nj.us.utstar.com> Date: Tue, 6 Jul 2004 17:22:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: 60th IETF OSPF WG Meeting Comments: cc: acee@redback.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list An OSPF meeting is scheduled for Monday, August 2, in San Diego. Please send me and Acee agenda items to consider. Thanks, --rohit. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 6 20:10:45 2004 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 UAA06230 for ; Tue, 6 Jul 2004 20:10:45 -0400 (EDT) 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.00E08A06@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 20:10:44 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24775199 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 20:10:41 -0400 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 20:10:39 -0400 Received: from user-2ivfnbm.dialup.mindspring.com ([165.247.221.118] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Bi01E-0006U1-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 06 Jul 2004 17:10:37 -0700 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: <8D260779A766FB4A9C1739A476F84FA401F79A87@daebe009.americas.nokia.com> <014b01c46368$743bc800$0202a8c0@aceeinspiron> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <40EB400B.69801942@earthlink.net> Date: Tue, 6 Jul 2004 17:12:59 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ace, et al, I realize that this is a late comment.. Section 3. Authentication But this really applies throughout this doc. "OSPF packets recieved ... MUST be dropped ..." Their is no mention that I have seen that identifies an appropriate MISMATCH message that allows the recv'r administrator to correct this or other bad configurations. Also, can a OSPF router sychronize or update its database with another router if a percentage of its packets are dropped? I keep on thinking that dropped msgs of this type need to be tracked and as much information should be logged about the xmit'er of the MISMATCHED pkt. What happens if some OSPF packets are dropped from a router and others are accepted? Thus, I would think and this is a bit extreme, if a OSPF packet is recieved that has a mismatch in any encryption or authentication field(s) from the xmit router, the adjacency or its 2-way link status should be dropped. The router can not be a trusted router if some of its packets are untrusted and/or its contents are unknown. Can it? Yes, this is assuming that the router-id is known. Mitchell Erblich ----------------- Acee Lindem wrote: > > Even though this has gone through WG last call it may > be a good to schedule some time at the San Deigo IETF > to discuss recent issues and how they are addressed > in the new draft. Comments? > > ----- Original Message ----- > From: > To: > Sent: Monday, July 05, 2004 3:19 PM > Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > Hi Vishwas, > > Thanks for the comments. Please see my comments inline.. > > > 1. I am not sure we should have a statement which says OSPFv3 > > is only for IPv6. > > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > the distinction between the packets can be easily made by > > IP version. " > > Do you have a replacement statement that you would prefer ? > As the IP protocol type value for OSPF and OSPFv3 is same, > we have to depend upon the IP version to separate OSPF and > OSPFv3 packets. > > > 2. I think the value of next header field in the ESP header > > to indicate OSPFv3 should be specified, though it may seem > > a trivial question. > > Why do you think it should be specified? Whenever ESP is > applied to any IP packet, the IP Protocol Type field value > from the IP header is copied to the next header field of > ESP/AH. There are no exceptions here. > > > 3. ESP already states that "integrity-only (MUST be supported)" > > do we really need to put down "ESP with NULL encryption MUST be > > supported in transport mode". > > An implementation may support ESP/AH that conform to ESP/AH RFCs, > but the idea of putting this in this draft was to ensure that the > user is allowed to use the specified combinations for securing > the OSPF traffic. So that 2 independent secured OSPF > implementations have at least one common combination to configure. > > Do you see any harm in putting this text in the draft ? > > > 4. I think we may want to state that Authentication service must > > always be supported whenever we do encryption. Our primary aim is > > to have data integrity right(anyway encryption only service is a > > MAY for ESP)? > > Doesn't the sentence "Providing confidentiality to OSPFv3 in addition > to authentication is optional." imply that ? Or would it better to > replace > > "ESP with non-null encryption in transport mode MUST be used > for providing the confidentiality to OSPFv3." > > with > > "ESP with non-null encryption and non-null authentication in transport > mode MUST be used for providing the confidentiality to OSPFv3." > > > 5. OSPF packets received in clear text or with incorrect AH > > Integrity Check Value (ICV) MUST be dropped when authentication is > > enabled. > > Do we mean only AH/ICV or do we need ESP ICV too? Besides do we > > need to state about combined mode algorithms like AES-CCM where > > ICV may not checked even when authentication is done. > > It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the > next version. > > The draft for AES-CCM says "it is inappropriate to use this CCM > with statically configured keys". We are using staticaly configured > keys here. So should we just NOT use AES-CCM ? > > > 6. SA Granularity and Selectors section - I think you are referring > > to parallel links we may want to state that too. > > No I am not referring to parallel links (if you mean 2 links connecting > the same routers). It should be possible to use the same SA for multiple > interfaces belonging to even different areas. > > > 7. Changing Keys may also be required in case of sequence number rollover. > > How is the user going to know about the sequence number rollover ? > so that he/she can initiate the key change. That brings an interesting > question. If the user never changes the keys, what happens when the > sequence number rollovers ? > > > 8. Would we want to refer to the newer drafts for ESP/AH drafts rather > > then the old RFC's itself? > > That's a good idea but the problem is that if we put the new drafts > as normative references, this draft will not be published before those > drafts. Do we want to block the draft waiting for those drafts ? > > The draft was reviewed by the IESG on June 26th and the comments can > be seen at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9745&rfc_flag=0 > We will be working on addressing all the comments now and will publish > an updated version of the draft probably after the IETF 60th. > > regards > Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 6 22:51:56 2004 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 WAA15388 for ; Tue, 6 Jul 2004 22:51:55 -0400 (EDT) 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.00E08D30@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 22:51:55 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24788004 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 22:51:54 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 22:51:54 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8E63172997E for ; Tue, 6 Jul 2004 19:50:37 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23745-09 for ; Tue, 6 Jul 2004 19:50:37 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.23]) by prattle.redback.com (Postfix) with SMTP id 2A66672998A for ; Tue, 6 Jul 2004 19:50:36 -0700 (PDT) References: <8D260779A766FB4A9C1739A476F84FA401F79A87@daebe009.americas.nokia.com> <014b01c46368$743bc800$0202a8c0@aceeinspiron> <40EB400B.69801942@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <03e501c463cd$27b22b90$0202a8c0@aceeinspiron> Date: Tue, 6 Jul 2004 22:50:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Mitchell, See inline. ----- Original Message ----- From: "Erblichs" To: Sent: Tuesday, July 06, 2004 8:12 PM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > Ace, et al, > > I realize that this is a late comment.. > > Section 3. Authentication > > But this really applies throughout > this doc. > > "OSPF packets recieved ... MUST be dropped ..." > > Their is no mention that I have seen that identifies > an appropriate MISMATCH message that allows the > recv'r administrator to correct this or other bad > configurations. I don't think we should try and standardise logging and/or log throttling mechanisms. The OSPFv2 MIB does define an ospfIfAuthFailure trap and I would imagine that when traps are added to the OSPFv3 MIB, this one would be included. It might be ok to say add a general statement saying that there should be some type of local auth failure notification and that it would be a good idea to throttle them. > Also, can a OSPF router sychronize > or update its database with another router if a > percentage of its packets are dropped? It depends on the percentage. > > I keep on thinking that dropped msgs of this type > need to be tracked and as much information should > be logged about the xmit'er of the MISMATCHED pkt. > > What happens if some OSPF packets are dropped from > a router and others are accepted? It depends on which packets :^) > > Thus, I would think and this is a bit extreme, if > a OSPF packet is recieved that has a mismatch in > any encryption or authentication field(s) from the > xmit router, the adjacency or its 2-way link status > should be dropped. The router can not be a trusted > router if some of its packets are untrusted and/or > its contents are unknown. Can it? > Yes, this is assuming that the router-id is known. I disagree. Authentication should be done on a packet by packet basis without OSPF trying to maintain any state other than what is maintained by IPSEC itself. > > Mitchell Erblich > ----------------- > > > > Acee Lindem wrote: > > > > Even though this has gone through WG last call it may > > be a good to schedule some time at the San Deigo IETF > > to discuss recent issues and how they are addressed > > in the new draft. Comments? > > > > ----- Original Message ----- > > From: > > To: > > Sent: Monday, July 05, 2004 3:19 PM > > Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > > > Hi Vishwas, > > > > Thanks for the comments. Please see my comments inline.. > > > > > 1. I am not sure we should have a statement which says OSPFv3 > > > is only for IPv6. > > > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > > the distinction between the packets can be easily made by > > > IP version. " > > > > Do you have a replacement statement that you would prefer ? > > As the IP protocol type value for OSPF and OSPFv3 is same, > > we have to depend upon the IP version to separate OSPF and > > OSPFv3 packets. > > > > > 2. I think the value of next header field in the ESP header > > > to indicate OSPFv3 should be specified, though it may seem > > > a trivial question. > > > > Why do you think it should be specified? Whenever ESP is > > applied to any IP packet, the IP Protocol Type field value > > from the IP header is copied to the next header field of > > ESP/AH. There are no exceptions here. > > > > > 3. ESP already states that "integrity-only (MUST be supported)" > > > do we really need to put down "ESP with NULL encryption MUST be > > > supported in transport mode". > > > > An implementation may support ESP/AH that conform to ESP/AH RFCs, > > but the idea of putting this in this draft was to ensure that the > > user is allowed to use the specified combinations for securing > > the OSPF traffic. So that 2 independent secured OSPF > > implementations have at least one common combination to configure. > > > > Do you see any harm in putting this text in the draft ? > > > > > 4. I think we may want to state that Authentication service must > > > always be supported whenever we do encryption. Our primary aim is > > > to have data integrity right(anyway encryption only service is a > > > MAY for ESP)? > > > > Doesn't the sentence "Providing confidentiality to OSPFv3 in addition > > to authentication is optional." imply that ? Or would it better to > > replace > > > > "ESP with non-null encryption in transport mode MUST be used > > for providing the confidentiality to OSPFv3." > > > > with > > > > "ESP with non-null encryption and non-null authentication in transport > > mode MUST be used for providing the confidentiality to OSPFv3." > > > > > 5. OSPF packets received in clear text or with incorrect AH > > > Integrity Check Value (ICV) MUST be dropped when authentication is > > > enabled. > > > Do we mean only AH/ICV or do we need ESP ICV too? Besides do we > > > need to state about combined mode algorithms like AES-CCM where > > > ICV may not checked even when authentication is done. > > > > It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the > > next version. > > > > The draft for AES-CCM says "it is inappropriate to use this CCM > > with statically configured keys". We are using staticaly configured > > keys here. So should we just NOT use AES-CCM ? > > > > > 6. SA Granularity and Selectors section - I think you are referring > > > to parallel links we may want to state that too. > > > > No I am not referring to parallel links (if you mean 2 links connecting > > the same routers). It should be possible to use the same SA for multiple > > interfaces belonging to even different areas. > > > > > 7. Changing Keys may also be required in case of sequence number rollover. > > > > How is the user going to know about the sequence number rollover ? > > so that he/she can initiate the key change. That brings an interesting > > question. If the user never changes the keys, what happens when the > > sequence number rollovers ? > > > > > 8. Would we want to refer to the newer drafts for ESP/AH drafts rather > > > then the old RFC's itself? > > > > That's a good idea but the problem is that if we put the new drafts > > as normative references, this draft will not be published before those > > drafts. Do we want to block the draft waiting for those drafts ? > > > > The draft was reviewed by the IESG on June 26th and the comments can > > be seen at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9745&rfc_flag=0 > > We will be working on addressing all the comments now and will publish > > an updated version of the draft probably after the IETF 60th. > > > > regards > > Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 7 03:16:07 2004 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 DAA27077 for ; Wed, 7 Jul 2004 03:16:07 -0400 (EDT) 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.00E09223@cherry.ease.lsoft.com>; Wed, 7 Jul 2004 3:16:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24815180 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Jul 2004 03:16:04 -0400 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 7 Jul 2004 03:16:04 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i677G2J05462 for ; Wed, 7 Jul 2004 10:16:03 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 10:14:17 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i677EHvc007342 for ; Wed, 7 Jul 2004 10:14:17 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 009vNE2c; Wed, 07 Jul 2004 10:13:06 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i677D4H00509 for ; Wed, 7 Jul 2004 10:13:04 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 02:13:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRjzbAdHlvkj1RrQwCOMHV7f8mrtQAIyi3g X-OriginalArrivalTime: 07 Jul 2004 07:13:03.0580 (UTC) FILETIME=[D806A9C0:01C463F1] Message-ID: <8D260779A766FB4A9C1739A476F84FA4026AB133@daebe009.americas.nokia.com> Date: Wed, 7 Jul 2004 02:13:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Acee/Mitchell, Comments inline.. > > Ace, et al, > > > > I realize that this is a late comment.. > > > > Section 3. Authentication > > > > But this really applies throughout > > this doc. > > > > "OSPF packets recieved ... MUST be dropped ..." > > > > Their is no mention that I have seen that identifies > > an appropriate MISMATCH message that allows the > > recv'r administrator to correct this or other bad > > configurations. > > > I don't think we should try and standardise logging and/or > log throttling mechanisms. The OSPFv2 MIB does define an > ospfIfAuthFailure trap and I would imagine that when traps > are added to the OSPFv3 MIB, this one would be included. > It might be ok to say add a general statement saying that there > should be some type of local auth failure notification and that > it would be a good idea to throttle them. I don't think OSPFv3 MIB could include this trap. As the packets are being dropped by IPsec before they even reach OSPF, OSPF is not going to know about the packets being dropped. The point that I am not able to understand is that how is it possible that some packets will be dropped and the others will not be ? If the keys are matching then all the packets will be delivered to OSPF. If there is a mismatch in the keys, all the packets will be dropped by the IPsec. The OSPF=20 adjacency will be down in the mismatch case so the admin will definitely know about that :) > > Also, can a OSPF router sychronize > > or update its database with another router if a > > percentage of its packets are dropped? > > It depends on the percentage. > > > > > I keep on thinking that dropped msgs of this type > > need to be tracked and as much information should > > be logged about the xmit'er of the MISMATCHED pkt. > > > > What happens if some OSPF packets are dropped from > > a router and others are accepted? > > It depends on which packets :^) Again when do you expect to see a percentage of the pkts being dropped ? > > Thus, I would think and this is a bit extreme, if > > a OSPF packet is recieved that has a mismatch in > > any encryption or authentication field(s) from the > > xmit router, the adjacency or its 2-way link status > > should be dropped. The router can not be a trusted > > router if some of its packets are untrusted and/or > > its contents are unknown. Can it? > > Yes, this is assuming that the router-id is known. > > I disagree. Authentication should be done on a packet by packet > basis without OSPF trying to maintain any state other than what is > maintained by IPSEC itself. I also disagree. First of all I am not able to understand the situation in which some of the packets are being dropped and some of them are being delivered to OSPF. Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 7 13:00:44 2004 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 NAA01048 for ; Wed, 7 Jul 2004 13:00:44 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00E09C3B@cherry.ease.lsoft.com>; Wed, 7 Jul 2004 13:00:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24891963 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Jul 2004 13:00:41 -0400 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 7 Jul 2004 13:00:41 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i67H0em6031668 for ; Wed, 7 Jul 2004 10:00:40 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i67H0e2P031665 for ; Wed, 7 Jul 2004 10:00:40 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <200407062122.RAA23110@web.nj.us.utstar.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20040707095330.Q31621@kummer.juniper.net> Date: Wed, 7 Jul 2004 10:00:40 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: 60th IETF OSPF WG Meeting To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200407062122.RAA23110@web.nj.us.utstar.com> Precedence: list Hi Rohit, On Tue, 6 Jul 2004, Rohit Dube wrote: > An OSPF meeting is scheduled for Monday, August 2, in San Diego. > Please send me and Acee agenda items to consider. I just submitted a draft on IANA considerations for OSPF -- draft-kompella-ospf-iana-00.txt. I'm not sure it makes sense to discuss this face-to-face -- you or Acee can make an announcement from the chair. However, I would encourage all to read it. The primary motivation is improved review before code points are allocated by IANA, which is increasingly important. Kireeti. ------- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 7 14:09:23 2004 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 OAA05084 for ; Wed, 7 Jul 2004 14:09:22 -0400 (EDT) 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.00E09E41@cherry.ease.lsoft.com>; Wed, 7 Jul 2004 14:09:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24906997 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Jul 2004 14:09:21 -0400 Received: from 207.217.120.126 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 7 Jul 2004 14:09:20 -0400 Received: from user-38lc1fm.dialup.mindspring.com ([209.86.5.246] helo=earthlink.net) by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BiGr7-0004fV-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 07 Jul 2004 11:09:18 -0700 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: <8D260779A766FB4A9C1739A476F84FA4026AB133@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <40EC3B6B.68CC916E@earthlink.net> Date: Wed, 7 Jul 2004 11:05:31 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Inline. Mitchell Erblich Mukesh.Gupta@NOKIA.COM wrote: > > Acee/Mitchell, > > Comments inline.. > > > > Ace, et al, > > > > > > I realize that this is a late comment.. > > > > > > Section 3. Authentication > > > > > > But this really applies throughout > > > this doc. > > > > > > "OSPF packets recieved ... MUST be dropped ..." > > > > > > Their is no mention that I have seen that identifies > > > an appropriate MISMATCH message that allows the > > > recv'r administrator to correct this or other bad > > > configurations. > > > > > I don't think we should try and standardise logging and/or > > log throttling mechanisms. The OSPFv2 MIB does define an > > ospfIfAuthFailure trap and I would imagine that when traps > > are added to the OSPFv3 MIB, this one would be included. > > It might be ok to say add a general statement saying that there > > should be some type of local auth failure notification and that > > it would be a good idea to throttle them. > > I don't think OSPFv3 MIB could include this trap. As the packets > are being dropped by IPsec before they even reach OSPF, OSPF is > not going to know about the packets being dropped. > IMO, the current above sentance implies that the OSPF layer is dropping the MISMATCHED packets. If IP is actually dropping ALL of the mismatched pkts, then I would think that the sentance could be changed to add something like this: OSPF packets recieved in clear text or with incorrect AH integrity Check value (ICV) MUST be dropped when authentication enabled. This layer, which is below the OSPF code, will transparently drop all all the above packets that would have been recieved by OSPF. > The point that I am not able to understand is that how is it > possible that some packets will be dropped and the others will > not be ? If the keys are matching then all the packets will > be delivered to OSPF. If there is a mismatch in the keys, > all the packets will be dropped by the IPsec. The OSPF > adjacency will be down in the mismatch case so the admin > will definitely know about that :) > > > > Also, can a OSPF router sychronize > > > or update its database with another router if a > > > percentage of its packets are dropped? > > > > It depends on the percentage. > > > > > > > > I keep on thinking that dropped msgs of this type > > > need to be tracked and as much information should > > > be logged about the xmit'er of the MISMATCHED pkt. > > > > > > What happens if some OSPF packets are dropped from > > > a router and others are accepted? > > > > It depends on which packets :^) > > Again when do you expect to see a percentage of the pkts > being dropped ? > > > > Thus, I would think and this is a bit extreme, if > > > a OSPF packet is recieved that has a mismatch in > > > any encryption or authentication field(s) from the > > > xmit router, the adjacency or its 2-way link status > > > should be dropped. The router can not be a trusted > > > router if some of its packets are untrusted and/or > > > its contents are unknown. Can it? > > > Yes, this is assuming that the router-id is known. > > > > I disagree. Authentication should be done on a packet by packet > > basis without OSPF trying to maintain any state other than what is > > maintained by IPSEC itself. > > I also disagree. First of all I am not able to understand > the situation in which some of the packets are being dropped > and some of them are being delivered to OSPF. > Mukesh and Acee, the SIMPLEST scenario that I can think of is the acceptance of 100% OSPF control pkts, a admin who performs a CLI change that changes the config and now all OSPF pkts are dropped. In this scenario, if ALL MISMATCH checks are done and acted upon transparently, it would take a min of hello interval times the hello multiplier before the 2-way or adj is dropped by the link partner. I thought we were going to a lower latency detection of changed adjs or 2-ways. And the worst cases IMO, is when the periodic hellos are surpressed, as in the case of demand circuits, I believe that incorrect routing can occur for up to 1 hour in these cases, if the above auth/encrypt MISMATCH drop is done transparently in a layer other than OSPF. IMO, if the MISMATCH drop is currently done transparently then some arch change needs to be done to remove or minimize these delayed effects. Lastly, I just wanted to see if anyone has the same concerns about this possible Very Long Convergence time frame due to a simple incorrect change by a admin. > Regards > Mukesh Mukesh.Gupta@NOKIA.COM wrote: > > Acee/Mitchell, > > Comments inline.. > > > > Ace, et al, > > > > > > I realize that this is a late comment.. > > > > > > Section 3. Authentication > > > > > > But this really applies throughout > > > this doc. > > > > > > "OSPF packets recieved ... MUST be dropped ..." > > > > > > Their is no mention that I have seen that identifies > > > an appropriate MISMATCH message that allows the > > > recv'r administrator to correct this or other bad > > > configurations. > > > > > I don't think we should try and standardise logging and/or > > log throttling mechanisms. The OSPFv2 MIB does define an > > ospfIfAuthFailure trap and I would imagine that when traps > > are added to the OSPFv3 MIB, this one would be included. > > It might be ok to say add a general statement saying that there > > should be some type of local auth failure notification and that > > it would be a good idea to throttle them. > > I don't think OSPFv3 MIB could include this trap. As the packets > are being dropped by IPsec before they even reach OSPF, OSPF is > not going to know about the packets being dropped. > > The point that I am not able to understand is that how is it > possible that some packets will be dropped and the others will > not be ? If the keys are matching then all the packets will > be delivered to OSPF. If there is a mismatch in the keys, > all the packets will be dropped by the IPsec. The OSPF > adjacency will be down in the mismatch case so the admin > will definitely know about that :) > > > > Also, can a OSPF router sychronize > > > or update its database with another router if a > > > percentage of its packets are dropped? > > > > It depends on the percentage. > > > > > > > > I keep on thinking that dropped msgs of this type > > > need to be tracked and as much information should > > > be logged about the xmit'er of the MISMATCHED pkt. > > > > > > What happens if some OSPF packets are dropped from > > > a router and others are accepted? > > > > It depends on which packets :^) > > Again when do you expect to see a percentage of the pkts > being dropped ? > > > > Thus, I would think and this is a bit extreme, if > > > a OSPF packet is recieved that has a mismatch in > > > any encryption or authentication field(s) from the > > > xmit router, the adjacency or its 2-way link status > > > should be dropped. The router can not be a trusted > > > router if some of its packets are untrusted and/or > > > its contents are unknown. Can it? > > > Yes, this is assuming that the router-id is known. > > > > I disagree. Authentication should be done on a packet by packet > > basis without OSPF trying to maintain any state other than what is > > maintained by IPSEC itself. If the state is done independently, and the above scenario occurs, are we incurring a penalty of lost packets, routing loops, etc, just because we have moved the auth / encrypt checks outside of OSPF and don't inform OSPF? > > I also disagree. First of all I am not able to understand > the situation in which some of the packets are being dropped > and some of them are being delivered to OSPF. > > Regards > Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 7 16:44:14 2004 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 QAA16347 for ; Wed, 7 Jul 2004 16:44:13 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00E0A180@cherry.ease.lsoft.com>; Wed, 7 Jul 2004 16:44:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24921734 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Jul 2004 16:44:11 -0400 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 7 Jul 2004 16:44:07 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67Ki6J19298 for ; Wed, 7 Jul 2004 23:44:06 +0300 (EET DST) X-Scanned: Wed, 7 Jul 2004 23:43:20 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i67KhKrS016526 for ; Wed, 7 Jul 2004 23:43:20 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 004aidYd; Wed, 07 Jul 2004 23:43:18 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67KhHu07815 for ; Wed, 7 Jul 2004 23:43:17 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 15:42:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRkTaYiwtuqeTK+RseaN7lJUFIwHgACeqZQ X-OriginalArrivalTime: 07 Jul 2004 20:42:07.0216 (UTC) FILETIME=[DE49AF00:01C46462] Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A8C@daebe009.americas.nokia.com> Date: Wed, 7 Jul 2004 15:42:06 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Mitchell, See inline.. > IMO, the current above sentance implies that the OSPF > layer is dropping the MISMATCHED packets. If IP > is actually dropping ALL of the mismatched pkts, > then I would think that the sentance could be changed > to add something like this: > > OSPF packets recieved in clear text or with incorrect > AH integrity Check value (ICV) MUST be dropped when > authentication enabled. This layer, which is below the > OSPF code, will transparently drop all all the above > packets that would have been recieved by OSPF. Now I understand your concern. The basic assumption in the draft is that all the packets are dropped by the IPsec layer=20 and none of the unauthenticated pkts reach OSPF. This=20 assumption is mentioned in section 2. The text that you mentioned "OSPF packets received in clear .. .. MUST be dropped when authentication is enabled." is assuming that they are dropped by the IPsec layer as always. Do you still think that we should mention it everywhere in the draft that the pkts will be dropped by the IPsec layer ? Or we should clarify it more in section 2 and make it explicit that whenever we say "drop the pkt", it means it is dropped by the IPsec layer ? > Mukesh and Acee, the SIMPLEST scenario that I can think of > is the acceptance of 100% OSPF control pkts, a admin who > performs a CLI change that changes the config and now all > OSPF pkts are dropped. > > In this scenario, if ALL MISMATCH checks are done and > acted upon transparently, it would take a min of hello > interval times the hello multiplier before the 2-way > or adj is dropped by the link partner. > > I thought we were going to a lower latency detection > of changed adjs or 2-ways. > > And the worst cases IMO, is when the periodic hellos > are surpressed, as in the case of demand circuits, I believe > that incorrect routing can occur for up to 1 hour > in these cases, if the above auth/encrypt MISMATCH drop > is done transparently in a layer other than OSPF. > > IMO, if the MISMATCH drop is currently done > transparently then some arch change needs to be done > to remove or minimize these delayed effects. > > Lastly, I just wanted to see if anyone has the same > concerns about this possible Very Long Convergence > time frame due to a simple incorrect change by a > admin. By the way, isn't it the way we handle authentication in OSPFv2 ? If you don't have any authentication and FULL adjacency between the neighbors and then you change the configuration of one of the neighbors to use simple/md5 authentication, the adjacency is not torn down immediately. It takes the dead interval time=20 before each of them mark the adjacency down. If we are ok with that behavior in OSPFv2, why should we have any problems for OSPFv3 ? Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 8 05:20:21 2004 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 FAA09030 for ; Thu, 8 Jul 2004 05:20:20 -0400 (EDT) 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.00E0B02F@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 5:20:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24990819 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 05:19:57 -0400 Received: from 210.202.42.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 05:09:56 -0400 Received: from CHARLESLIANG ([10.44.8.1]) by hqmail1.alphanetworks.com (Lotus Domino Release 5.0.12) with SMTP id 2004070817092276:8671 ; Thu, 8 Jul 2004 17:09:22 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/08/2004 05:09:22 PM, Serialize by Router on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/08/2004 05:09:26 PM, Serialize complete at 07/08/2004 05:09:26 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D5_01C4650E.A3EC5AE0" Message-ID: <00d801c464cb$9babe910$01082c1e@CHARLESLIANG> Date: Thu, 8 Jul 2004 17:11:42 +0800 Reply-To: Mailing List Sender: Mailing List From: Charles Yi-tung Liang Organization: Alpha Networks Inc. Subject: LSDB Overflow Limitation? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00D5_01C4650E.A3EC5AE0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, Here below is my understanding from RFC1765 to process lsdb overflow condition. Goal: Make every OSPF router to be awared of the overflow state, and thus reduce the number of lsdb. That's why we required all the OSPF routers setup the same limited lsdb threshold. Process: As mentioned in RFC1765. Limitation?/Problem?: Since the new LSA update from someone triggers overflow state (when currentLSACount =3D=3D limitedLSACount) via flooding, there is chance that certain OSPF router will miss such a critial event. Moreover, the following premature actions may make someone else believing there is not yet an overflow event. Why don't we just set up a beacon bit to notify everyone? For example, using a reserved filed in HELLO-Option to notify overflow. Afterward, when all the neighbors acked with overflow beacon-bit, reset (clear) such a bit. Could anyone help clearing my doubt? BTW, if the overflow process needs to be applied to Inter-AS LSAs (Area-Oriented), what kind of LSA is suggested to be prematured? Can I leave RTRLink, NetLink, and ASSummary alone? Will OSPF WG include the overflow process as a part of OSPFv3? Thanks in advance. Charles ------=_NextPart_000_00D5_01C4650E.A3EC5AE0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable

Hi,

Here below is my understanding from = RFC1765

to process lsdb overflow condition.

Goal: Make every OSPF router to be awared = of

the overflow state, and thus reduce the = number

of lsdb. That's why we required all the=20 OSPF

routers setup the same limited lsdb = threshold.

Process: As mentioned in RFC1765.

Limitation?/Problem?:

Since the new LSA update from someone=20 triggers

overflow state (when currentLSACount =3D=3D=20 limitedLSACount)

via flooding, there is chance that certain OSPF=20 router

will miss such a critial event. Moreover, the=20 following

premature actions may make someone else = believing

there is not yet an overflow event. Why don't = we just=20 set

up a beacon bit to notify everyone? For=20 example,

using a reserved filed in HELLO-Option to = notify

overflow. Afterward, when all the neighbors=20 acked

with overflow beacon-bit, reset (clear) such a=20 bit.

Could anyone help clearing my doubt?

BTW, if the overflow process needs to be = applied

to Inter-AS LSAs (Area-Oriented), what kind = of

LSA is suggested to be prematured? Can I=20 leave

RTRLink, NetLink, and ASSummary alone?

Will OSPF WG include the overflow process = as

a part of OSPFv3?

Thanks in advance.

Charles

------=_NextPart_000_00D5_01C4650E.A3EC5AE0-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 8 12:00:45 2004 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 MAA05047 for ; Thu, 8 Jul 2004 12:00:43 -0400 (EDT) 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.00E0B937@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 12:00:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25054162 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 12:00:41 -0400 Received: from 207.217.120.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 12:00:41 -0400 Received: from user-38lc118.dialup.mindspring.com ([209.86.4.40] helo=earthlink.net) by bittern.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BibKC-0006Hg-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Jul 2004 09:00:40 -0700 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: <00d801c464cb$9babe910$01082c1e@CHARLESLIANG> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <40ED714A.23EF5EF1@earthlink.net> Date: Thu, 8 Jul 2004 09:07:38 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: LSDB Overflow Limitation? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Charles, The number really has to do with the number of non default AS-external LSAs. These are believed to represent the maj of LSAs in the LSDB. In my experience, this only occurs with memory limited routers and routers within the same area are normally set to the same values. Realize that in memory limited routers, you are pre-allocating enough memory to cover the limit and that memory will not be available for other functions. Mitchell Erblich ----------------- > Charles Yi-tung Liang wrote: > > Hi, > > Here below is my understanding from RFC1765 > to process lsdb overflow condition. > > Goal: Make every OSPF router to be awared of > the overflow state, and thus reduce the number > of lsdb. That's why we required all the OSPF > routers setup the same limited lsdb threshold. > > Process: As mentioned in RFC1765. > > Limitation?/Problem?: > Since the new LSA update from someone triggers > overflow state (when currentLSACount == limitedLSACount) > via flooding, there is chance that certain OSPF router > will miss such a critial event. Moreover, the following > premature actions may make someone else believing > there is not yet an overflow event. Why don't we just set > up a beacon bit to notify everyone? For example, > using a reserved filed in HELLO-Option to notify > overflow. Afterward, when all the neighbors acked > with overflow beacon-bit, reset (clear) such a bit. > > Could anyone help clearing my doubt? > > BTW, if the overflow process needs to be applied > to Inter-AS LSAs (Area-Oriented), what kind of > LSA is suggested to be prematured? Can I leave > RTRLink, NetLink, and ASSummary alone? > Will OSPF WG include the overflow process as > a part of OSPFv3? > > Thanks in advance. > > Charles From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 8 12:52:05 2004 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 MAA08904 for ; Thu, 8 Jul 2004 12:52:04 -0400 (EDT) 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.00E0B9AF@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 12:52:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25058874 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 12:52:03 -0400 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 12:52:03 -0400 Received: from user-38lc118.dialup.mindspring.com ([209.86.4.40] helo=earthlink.net) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Bic7s-0003x2-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Jul 2004 09:52:01 -0700 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: <8D260779A766FB4A9C1739A476F84FA401F79A8C@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <40ED7D53.F4DCFAEB@earthlink.net> Date: Thu, 8 Jul 2004 09:58:59 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukesh, Inline... Mitchell ------- Mukesh.Gupta@NOKIA.COM wrote: > > Mitchell, > > See inline.. > > IMO, the current above sentance implies that the OSPF > > layer is dropping the MISMATCHED packets. If IP > > is actually dropping ALL of the mismatched pkts, > > then I would think that the sentance could be changed > > to add something like this: > > > > OSPF packets recieved in clear text or with incorrect > > AH integrity Check value (ICV) MUST be dropped when > > authentication enabled. This layer, which is below the > > OSPF code, will transparently drop all all the above > > packets that would have been recieved by OSPF. > > Now I understand your concern. The basic assumption in the > draft is that all the packets are dropped by the IPsec layer > and none of the unauthenticated pkts reach OSPF. This > assumption is mentioned in section 2. > > The text that you mentioned "OSPF packets received in clear .. > .. MUST be dropped when authentication is enabled." is assuming > that they are dropped by the IPsec layer as always. > > Do you still think that we should mention it everywhere in the > draft that the pkts will be dropped by the IPsec layer ? Or > we should clarify it more in section 2 and make it explicit > that whenever we say "drop the pkt", it means it is dropped > by the IPsec layer ? IMO, Minimally it should be explicitly stated. > > > Mukesh and Acee, the SIMPLEST scenario that I can think of > > is the acceptance of 100% OSPF control pkts, a admin who > > performs a CLI change that changes the config and now all > > OSPF pkts are dropped. > > > > In this scenario, if ALL MISMATCH checks are done and > > acted upon transparently, it would take a min of hello > > interval times the hello multiplier before the 2-way > > or adj is dropped by the link partner. > > > > I thought we were going to a lower latency detection > > of changed adjs or 2-ways. > > > > And the worst cases IMO, is when the periodic hellos > > are surpressed, as in the case of demand circuits, I believe > > that incorrect routing can occur for up to 1 hour > > in these cases, if the above auth/encrypt MISMATCH drop > > is done transparently in a layer other than OSPF. > > > > IMO, if the MISMATCH drop is currently done > > transparently then some arch change needs to be done > > to remove or minimize these delayed effects. > > > > Lastly, I just wanted to see if anyone has the same > > concerns about this possible Very Long Convergence > > time frame due to a simple incorrect change by a > > admin. > > By the way, isn't it the way we handle authentication in OSPFv2 ? > If you don't have any authentication and FULL adjacency between > the neighbors and then you change the configuration of one of > the neighbors to use simple/md5 authentication, the adjacency > is not torn down immediately. It takes the dead interval time > before each of them mark the adjacency down. First, what we are dealing here is online reconfiguration or dynamic reconfiguration. I haven't seen really any discussion in 2328, wrt changing values after 2-ways/ adjs are established. IMO, I have two very different ways of thinking about this. #1 If a field within a pkt is changed that "forces" the link partner to now drop the pkt, the router dead interval time frame is a built in latency period to re-establish re-synchronization of the values. However, this allows data movement accross the adj, where the adj REALLY is no longer valid / synchronized. In addition, if another router duplicates anothers router-id, but changes one required synchronized value, to invalidate the pkt, and this one pkt causes the adj to be dropped, it could be a DOS type attack. #2 To properly achieve "Faster Failure Detection", IMO Guyal, et al, should have considered the reception of a NOW invalid pkt. This would eliminate the router dead interval delay in tearing down the adj. It is the delay's / latencies that are built in tearing down a now no longer valid adj. So, we should be leaning from OSPFv2 the behaviours that we don't want in v3, and attempt to remove them versus forcing us to live with our past ?mistakes? for consistency sakes. Thus, IMO, if authentication is CHANGED locally the adj should be torn down immediately, and the reception of a pkt that would cause it to be dropped by the recvr, should effect the state of the adj. BTW, this should be only one of many fields that should effect the state of the adj. Don't we have to assume that the adj is going to fail anyway? Is the reception of a hello pkt that will be dropped repeatedly, the first indication that the nbr is no longer reachable? I think yes. Thus, it is a valid nbr state machine event to the down state. However, since it is so drastic, I assume that a CLI command should allow this event. > > If we are ok with that behavior in OSPFv2, why should we have > any problems for OSPFv3 ? > > Regards > Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 8 14:22:03 2004 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 OAA15344 for ; Thu, 8 Jul 2004 14:22:02 -0400 (EDT) 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.00E0BB86@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 14:21:58 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25068381 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 14:21:54 -0400 Received: from 210.202.42.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 14:21:54 -0400 Received: from hqmail3.alphanetworks.com ([172.19.3.26]) by hqmail1.alphanetworks.com (Lotus Domino Release 5.0.12) with ESMTP id 2004070902212227:9983 ; Fri, 9 Jul 2004 02:21:22 +0800 MIME-Version: 1.0 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on HQMAIL3/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 02:17:12 AM, Itemize by SMTP Server on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 02:21:22 AM, Serialize by Router on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 02:21:24 AM, Serialize complete at 07/09/2004 02:21:24 AM Content-Transfer-Encoding: base64 Content-Type: text/html; charset=UTF-8 Message-ID: Date: Fri, 9 Jul 2004 02:17:11 +0800 Reply-To: Mailing List Sender: Mailing List From: Charles Liang Subject: Re: LSDB Overflow Limitation? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 PFA+TWl0Y2hlbGwsPC9QPjxQPkl0IHNvdW5kcyBsaWtlIHdlIHByZWZlciB0byBwcmUtYWxsb2Nh dGUgdGhlIHJlc291cmNlLDxCUj5yYXRoZXIgdGhhbiBwcm9jZXNzIHRoZSBvdmVyZmxvdyBjb25k aXRpb25zPyE8QlI+SSBhbHNvIGJlbGl2ZSB0aGF0IHRoZSBudW1iZXIgaGFzIHRvIGJlIG1hdGNo ZWQgd2l0aDxCUj50aGUgbGltaXQgY291bnRzLCBhbmQgcHJlLWFsbG9jYXRpbmcgdGhlIHJlc291 cmNlPEJSPnNob3VsZCBiZSBhIHByYXRpY2FsIHNvbHV0aW9uLjwvUD48UD5XaGF0IEkgY29uY2Vy bmVkIGlzIHRoZSBleGNlcHRpb24/IGZyb20gUkZDMTc2NS48QlI+SWYgd2UgaGF2ZSB0byBpbXBs ZW1lbnQgdGhpcyBmZWF0dXJlLCB3ZSdkIGxpa2U8QlI+dG8gbWFrZSBzdXJlIHRoZSBpbXBsZW1l bnRhdGlvbiB3b3JrcyBmb3IgYWxsPEJSPnRoZSBwb3NzaWJsZSBjYXNlcy4gJm5ic3A7T3RoZXJ3 aXNlLCBzaG91bGRuJ3Qgd2UgcHJlZmVyPEJSPnRvIGFubm91bmNlIHRoYXQgbXkgT1NQRiByb3V0 ZXIgd2lsbCBORVZFUiBmYWxsPEJSPmludG8gTFNEQiBvdmVyZmxvdyBzdGF0ZS48L1A+PFA+VGhl cmVmb3JlLCBJJ20gd29uZGVyaW5nIHRoYXQ8QlI+KDEpIElzIG15IHJlYWxpemF0aW9uIGFib3V0 IFJGQzE3NjUgY29ycmVjdD88QlI+KDIpIFdpbGwgdGhlIHByb2JsZW0gdGhhdCBJIGRlc2NyaWJl ZCBoYXBwZW4/PEJSPigzKSBJcyB0aGVyZSBhbnkgc2lkZSBlZmZlY3QgaWYgSSB1c2UgYSByZXNl cnZlZDxCUj5hbmQgdW51c2VkIGZpZWxkIGluIEhFTExPLU9wdGlvbj88QlI+KDQpIElzIGl0IHdv cnRoIG9mIGltcGxlbWV0aW5nIFJGQzE3NjU/PC9QPjxQPkNoYXJsZXMgPEJSPjxCUj48Rk9OVCBT SVpFPTI+PEI+RXJibGljaHMgJmx0O2VyYmxpY2hzQEVBUlRITElOSy5ORVQmZ3Q7PC9CPjwvRk9O VD48QlI+PEZPTlQgU0laRT0yPlNlbnQgYnk6IE1haWxpbmcgTGlzdCAmbHQ7T1NQRkBQRUFDSC5F QVNFLkxTT0ZULkNPTSZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wNy8wOC8yMDA0IDA5OjA3 IEFNIE1TVDwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlBsZWFzZSByZXNwb25kIHRvIE1haWxpbmcg TGlzdDwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+ T1NQRkBQRUFDSC5FQVNFLkxTT0ZULkNPTTwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZP TlQ+IDxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1Ympl Y3Q6PC9GT05UPiA8Rk9OVCBTSVpFPTI+WyBTcGFtIE1haWwgXSBSZTogTFNEQiBPdmVyZmxvdyBM aW1pdGF0aW9uPyAoVGhpcyBtZXNzYWdlIGlzIHRvIGJlIGJsb2NrZWQgYnkgY29kZTogYmtuc3M2 MTE3Nyk8L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291 cmllciI+Q2hhcmxlcyw8QlI+PC9GT05UPjwvUD48VUw+PFVMPjxVTD48Rk9OVCBGQUNFPSJNb25v c3BhY2UsQ291cmllciI+VGhlIG51bWJlciByZWFsbHkgaGFzIHRvIGRvIHdpdGg8QlI+dGhlIG51 bWJlciBvZiBub24gZGVmYXVsdCBBUy1leHRlcm5hbDxCUj5MU0FzLjwvRk9OVD48QlI+PEJSPjxG T05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UaGVzZSBhcmUgYmVsaWV2ZWQgdG8gcmVwcmVz ZW50IHRoZTxCUj5tYWogb2YgTFNBcyBpbiB0aGUgTFNEQi48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBG QUNFPSJNb25vc3BhY2UsQ291cmllciI+SW4gbXkgZXhwZXJpZW5jZSwgdGhpcyBvbmx5IG9jY3Vy czxCUj53aXRoIG1lbW9yeSBsaW1pdGVkIHJvdXRlcnMgYW5kPEJSPnJvdXRlcnMgd2l0aGluIHRo ZSBzYW1lIGFyZWEgYXJlPEJSPm5vcm1hbGx5IHNldCB0byB0aGUgc2FtZSB2YWx1ZXMuPC9GT05U PjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlJlYWxpemUgdGhhdCBpbiBt ZW1vcnkgbGltaXRlZCByb3V0ZXJzLDxCUj55b3UgYXJlIHByZS1hbGxvY2F0aW5nIGVub3VnaCBt ZW1vcnk8QlI+dG8gY292ZXIgdGhlIGxpbWl0IGFuZCB0aGF0IG1lbW9yeSB3aWxsPEJSPm5vdCBi ZSBhdmFpbGFibGUgZm9yIG90aGVyIGZ1bmN0aW9ucy48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBGQUNF PSJNb25vc3BhY2UsQ291cmllciI+TWl0Y2hlbGwgRXJibGljaDxCUj4tLS0tLS0tLS0tLS0tLS0t LTwvRk9OVD48QlI+PC9VTD48L1VMPjwvVUw+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJp ZXIiPiZndDsgQ2hhcmxlcyBZaS10dW5nIExpYW5nIHdyb3RlOjxCUj4mZ3Q7PEJSPiZndDsgSGks PEJSPiZndDs8QlI+Jmd0OyBIZXJlIGJlbG93IGlzIG15IHVuZGVyc3RhbmRpbmcgZnJvbSBSRkMx NzY1PEJSPiZndDsgdG8gcHJvY2VzcyBsc2RiIG92ZXJmbG93IGNvbmRpdGlvbi48QlI+Jmd0OzxC Uj4mZ3Q7IEdvYWw6IE1ha2UgZXZlcnkgT1NQRiByb3V0ZXIgdG8gYmUgYXdhcmVkIG9mPEJSPiZn dDsgdGhlIG92ZXJmbG93IHN0YXRlLCBhbmQgdGh1cyByZWR1Y2UgdGhlIG51bWJlcjxCUj4mZ3Q7 IG9mIGxzZGIuICZuYnNwO1RoYXQncyB3aHkgd2UgcmVxdWlyZWQgYWxsIHRoZSBPU1BGPEJSPiZn dDsgcm91dGVycyBzZXR1cCB0aGUgc2FtZSBsaW1pdGVkIGxzZGIgdGhyZXNob2xkLjxCUj4mZ3Q7 PEJSPiZndDsgUHJvY2VzczogQXMgbWVudGlvbmVkIGluIFJGQzE3NjUuPEJSPiZndDs8QlI+Jmd0 OyBMaW1pdGF0aW9uPy9Qcm9ibGVtPzo8QlI+Jmd0OyBTaW5jZSB0aGUgbmV3IExTQSB1cGRhdGUg ZnJvbSBzb21lb25lIHRyaWdnZXJzPEJSPiZndDsgb3ZlcmZsb3cgc3RhdGUgKHdoZW4gY3VycmVu dExTQUNvdW50ID09IGxpbWl0ZWRMU0FDb3VudCk8QlI+Jmd0OyB2aWEgZmxvb2RpbmcsIHRoZXJl IGlzIGNoYW5jZSB0aGF0IGNlcnRhaW4gT1NQRiByb3V0ZXI8QlI+Jmd0OyB3aWxsIG1pc3Mgc3Vj aCBhIGNyaXRpYWwgZXZlbnQuICZuYnNwO01vcmVvdmVyLCB0aGUgZm9sbG93aW5nPEJSPiZndDsg cHJlbWF0dXJlIGFjdGlvbnMgbWF5IG1ha2Ugc29tZW9uZSBlbHNlIGJlbGlldmluZzxCUj4mZ3Q7 IHRoZXJlIGlzIG5vdCB5ZXQgYW4gb3ZlcmZsb3cgZXZlbnQuICZuYnNwO1doeSBkb24ndCB3ZSBq dXN0IHNldDxCUj4mZ3Q7IHVwIGEgYmVhY29uIGJpdCB0byBub3RpZnkgZXZlcnlvbmU/ICZuYnNw O0ZvciBleGFtcGxlLDxCUj4mZ3Q7IHVzaW5nIGEgcmVzZXJ2ZWQgZmlsZWQgaW4gSEVMTE8tT3B0 aW9uIHRvIG5vdGlmeTxCUj4mZ3Q7IG92ZXJmbG93LiAmbmJzcDtBZnRlcndhcmQsIHdoZW4gYWxs IHRoZSBuZWlnaGJvcnMgYWNrZWQ8QlI+Jmd0OyB3aXRoIG92ZXJmbG93IGJlYWNvbi1iaXQsIHJl c2V0IChjbGVhcikgc3VjaCBhIGJpdC48QlI+Jmd0OzxCUj4mZ3Q7IENvdWxkIGFueW9uZSBoZWxw IGNsZWFyaW5nIG15IGRvdWJ0PzxCUj4mZ3Q7PEJSPiZndDsgQlRXLCBpZiB0aGUgb3ZlcmZsb3cg cHJvY2VzcyBuZWVkcyB0byBiZSBhcHBsaWVkPEJSPiZndDsgdG8gSW50ZXItQVMgTFNBcyAoQXJl YS1PcmllbnRlZCksIHdoYXQga2luZCBvZjxCUj4mZ3Q7IExTQSBpcyBzdWdnZXN0ZWQgdG8gYmUg cHJlbWF0dXJlZD8gJm5ic3A7Q2FuIEkgbGVhdmU8QlI+Jmd0OyBSVFJMaW5rLCBOZXRMaW5rLCBh bmQgQVNTdW1tYXJ5IGFsb25lPzxCUj4mZ3Q7IFdpbGwgT1NQRiBXRyBpbmNsdWRlIHRoZSBvdmVy ZmxvdyBwcm9jZXNzIGFzPEJSPiZndDsgYSBwYXJ0IG9mIE9TUEZ2Mz88QlI+Jmd0OzxCUj4mZ3Q7 IFRoYW5rcyBpbiBhZHZhbmNlLjxCUj4mZ3Q7PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3Bh Y2UsQ291cmllciI+Jmd0OyBDaGFybGVzPC9GT05UPjwvUD4= From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 8 16:41:17 2004 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 QAA27053 for ; Thu, 8 Jul 2004 16:41:17 -0400 (EDT) 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.00E0BD1C@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 16:41:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25083400 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 16:41:13 -0400 Received: from 207.217.120.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 16:41:13 -0400 Received: from user-38lc118.dialup.mindspring.com ([209.86.4.40] helo=earthlink.net) by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Bifhf-0002q9-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Jul 2004 13:41:11 -0700 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: <40EDB307.CCD62B86@earthlink.net> Date: Thu, 8 Jul 2004 13:48:07 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: LSDB Overflow Limitation? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Charles, First 1765 is experimental. However, it is fairly simple to impliment and I think most vendors have implimented it. Using unused reserved bits SHOULD ONLY be done in controlled research environments with no connections outside of this environment. Your goal is wrong IMO. If overflow state is reached, selectively originate certain LSAs. Else, allow some routers to orginate those LSAs and others not to so LSDB convergence is achieved. Default routing will achieve the same means, although less efficent. If the problem persists admins should partition the area or reconfigure parts of the area as stubs or get more memory for the routers, or.. An option is not necessary when the LSDB overflow event is achieved. Purging and limiting should be sufficent to achieve convergence. Mitchell Erblich ------------------ Charles Liang wrote: > > Mitchell, > > It sounds like we prefer to pre-allocate the resource, > rather than process the overflow conditions?! > I also belive that the number has to be matched with > the limit counts, and pre-allocating the resource > should be a pratical solution. > > What I concerned is the exception? from RFC1765. > If we have to implement this feature, we'd like > to make sure the implementation works for all > the possible cases. Otherwise, shouldn't we prefer > to announce that my OSPF router will NEVER fall > into LSDB overflow state. > > Therefore, I'm wondering that > (1) Is my realization about RFC1765 correct? > (2) Will the problem that I described happen? > (3) Is there any side effect if I use a reserved > and unused field in HELLO-Option? > (4) Is it worth of implemeting RFC1765? > > Charles > > Erblichs > Sent by: Mailing List > 07/08/2004 09:07 AM MST > Please respond to Mailing List > > To: OSPF@PEACH.EASE.LSOFT.COM > cc: > bcc: > Subject: [ Spam Mail ] Re: LSDB Overflow Limitation? (This message is > to be blocked by code: bknss61177) > > Charles, > > The number really has to do with > the number of non default AS-external > LSAs. > > These are believed to represent the > maj of LSAs in the LSDB. > > In my experience, this only occurs > with memory limited routers and > routers within the same area are > normally set to the same values. > > Realize that in memory limited routers, > you are pre-allocating enough memory > to cover the limit and that memory will > not be available for other functions. > > Mitchell Erblich > ----------------- > > > Charles Yi-tung Liang wrote: > > > > Hi, > > > > Here below is my understanding from RFC1765 > > to process lsdb overflow condition. > > > > Goal: Make every OSPF router to be awared of > > the overflow state, and thus reduce the number > > of lsdb. That's why we required all the OSPF > > routers setup the same limited lsdb threshold. > > > > Process: As mentioned in RFC1765. > > > > Limitation?/Problem?: > > Since the new LSA update from someone triggers > > overflow state (when currentLSACount == limitedLSACount) > > via flooding, there is chance that certain OSPF router > > will miss such a critial event. Moreover, the following > > premature actions may make someone else believing > > there is not yet an overflow event. Why don't we just set > > up a beacon bit to notify everyone? For example, > > using a reserved filed in HELLO-Option to notify > > overflow. Afterward, when all the neighbors acked > > with overflow beacon-bit, reset (clear) such a bit. > > > > Could anyone help clearing my doubt? > > > > BTW, if the overflow process needs to be applied > > to Inter-AS LSAs (Area-Oriented), what kind of > > LSA is suggested to be prematured? Can I leave > > RTRLink, NetLink, and ASSummary alone? > > Will OSPF WG include the overflow process as > > a part of OSPFv3? > > > > Thanks in advance. > > > > Charles From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 8 17:04:34 2004 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 RAA28264 for ; Thu, 8 Jul 2004 17:04:32 -0400 (EDT) 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.00E0BF6B@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 17:04:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25085354 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 17:04:31 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 17:04:31 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 24DDF6ACEC1 for ; Thu, 8 Jul 2004 14:04:30 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17858-05 for ; Thu, 8 Jul 2004 14:04:29 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.53]) by prattle.redback.com (Postfix) with SMTP id E34206ACEBF for ; Thu, 8 Jul 2004 14:04:28 -0700 (PDT) References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0874_01C4650D.9834E4C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <087701c4652f$1fbc29f0$0202a8c0@aceeinspiron> Date: Thu, 8 Jul 2004 17:04:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: LSDB Overflow Limitation? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0874_01C4650D.9834E4C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Charles,=20 You can choose to implement RFC 1765 but you cannot advertise the fact that your router is in overflow state in a=20 field in OSPF hello packets. First of all, there are no unused fields or option bits and even if there were we wouldn't want to=20 allocate them for this purpose.=20 There are free bits in the router LSA bits but personally I don't see a strong requirement to advertise entry or exit from overflow state.=20 I don't agree with everything that has been stated in this mail thread but I do agree that RFC 1765 dates to a time when low-end routers had very limited memory. Again, you can choose to implement this RFC. However, I personally=20 think a local knob specifying the upper limit on the number of external routes that you'll advertise is more useful.=20 Thanks, Acee=20 ----- Original Message -----=20 From: Charles Liang=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Thursday, July 08, 2004 2:17 PM Subject: Re: LSDB Overflow Limitation? Mitchell, It sounds like we prefer to pre-allocate the resource, rather than process the overflow conditions?! I also belive that the number has to be matched with the limit counts, and pre-allocating the resource should be a pratical solution. What I concerned is the exception? from RFC1765. If we have to implement this feature, we'd like to make sure the implementation works for all the possible cases. Otherwise, shouldn't we prefer to announce that my OSPF router will NEVER fall into LSDB overflow state. Therefore, I'm wondering that (1) Is my realization about RFC1765 correct? (2) Will the problem that I described happen? (3) Is there any side effect if I use a reserved and unused field in HELLO-Option? (4) Is it worth of implemeting RFC1765? Charles=20 Erblichs Sent by: Mailing List 07/08/2004 09:07 AM MST Please respond to Mailing List To: OSPF@PEACH.EASE.LSOFT.COM cc:=20 bcc:=20 Subject: [ Spam Mail ] Re: LSDB Overflow Limitation? (This message is = to be blocked by code: bknss61177) Charles, The number really has to do with the number of non default AS-external LSAs. These are believed to represent the maj of LSAs in the LSDB. In my experience, this only occurs with memory limited routers and routers within the same area are normally set to the same values. Realize that in memory limited routers, you are pre-allocating enough memory to cover the limit and that memory will not be available for other functions. Mitchell Erblich ----------------- > Charles Yi-tung Liang wrote: > > Hi, > > Here below is my understanding from RFC1765 > to process lsdb overflow condition. > > Goal: Make every OSPF router to be awared of > the overflow state, and thus reduce the number > of lsdb. That's why we required all the OSPF > routers setup the same limited lsdb threshold. > > Process: As mentioned in RFC1765. > > Limitation?/Problem?: > Since the new LSA update from someone triggers > overflow state (when currentLSACount =3D=3D limitedLSACount) > via flooding, there is chance that certain OSPF router > will miss such a critial event. Moreover, the following > premature actions may make someone else believing > there is not yet an overflow event. Why don't we just set > up a beacon bit to notify everyone? For example, > using a reserved filed in HELLO-Option to notify > overflow. Afterward, when all the neighbors acked > with overflow beacon-bit, reset (clear) such a bit. > > Could anyone help clearing my doubt? > > BTW, if the overflow process needs to be applied > to Inter-AS LSAs (Area-Oriented), what kind of > LSA is suggested to be prematured? Can I leave > RTRLink, NetLink, and ASSummary alone? > Will OSPF WG include the overflow process as > a part of OSPFv3? > > Thanks in advance. > > Charles ------=_NextPart_000_0874_01C4650D.9834E4C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF

Charles,

You can choose to implement RFC 1765 = but you=20 cannot

advertise the fact that your router is = in overflow=20 state in a

field in OSPF hello packets. First of all, there are no unused = fields

or option bits and even if there = were=20 we wouldn't want to

allocate them for this purpose. =

There are free bits=20 in the router LSA bits but personally

I don't see a strong requirement to = advertise entry=20 or

exit from overflow state.

I don't agree with everything that has = been stated=20 in this

mail thread but I do agree that RFC = 1765 dates to=20 a

time when low-end routers had very = limited memory.=20 Again, you

can choose to implement this RFC. = However, I=20 personally

think a local knob specifying = the upper limit=20 on the number

of external routes that you'll = advertise is more=20 useful.

Thanks,

Acee

----- Original Message -----
From:=20 Charles Liang =
To: OSPF@PEACH.EASE.LSOFT.COM =

Sent: Thursday, July 08, 2004 = 2:17=20 PM

Subject: Re: LSDB Overflow=20 Limitation?

Mitchell,

It sounds like we prefer to pre-allocate the resource,
rather = than=20 process the overflow conditions?!
I also belive that the number has = to be=20 matched with
the limit counts, and pre-allocating the = resource
should be=20 a pratical solution.

What I concerned is the exception? from RFC1765.
If we have to = implement=20 this feature, we'd like
to make sure the implementation works for=20 all
the possible cases. Otherwise, shouldn't we prefer
to = announce=20 that my OSPF router will NEVER fall
into LSDB overflow state.

Therefore, I'm wondering that
(1) Is my realization about = RFC1765=20 correct?
(2) Will the problem that I described happen?
(3) Is = there any=20 side effect if I use a reserved
and unused field in = HELLO-Option?
(4) Is=20 it worth of implemeting RFC1765?

Charles

Erblichs=20 <erblichs@EARTHLINK.NET>
Sent by: = Mailing=20 List <OSPF@PEACH.EASE.LSOFT.COM>
07/08/2004 09:07=20 AM MST
Please respond to Mailing=20 List

To: OSPF@PEACH.EASE.LSOFT.COM
cc: =
bcc:
Subject: [ Spam Mail ]=20 Re: LSDB Overflow Limitation? (This message is to be blocked by code:=20 bknss61177)

Charles,

The number really has to do = with
the=20 number of non default AS-external
LSAs.

These are believed to represent = the
maj of=20 LSAs in the LSDB.

In my=20 experience, this only occurs
with memory limited routers=20 and
routers within the same area are
normally set to the = same=20 values.

Realize = that in=20 memory limited routers,
you are pre-allocating enough = memory
to=20 cover the limit and that memory will
not be available for = other=20 functions.

Mitchell = Erblich
-----------------

> Charles Yi-tung Liang=20 wrote:
>
> Hi,
>
> Here below is my = understanding from=20 RFC1765
> to process lsdb overflow condition.
>
> = Goal: Make=20 every OSPF router to be awared of
> the overflow state, and thus = reduce=20 the number
> of lsdb. That's why we required all the = OSPF
>=20 routers setup the same limited lsdb threshold.
>
> = Process: As=20 mentioned in RFC1765.
>
> Limitation?/Problem?:
> = Since the=20 new LSA update from someone triggers
> overflow state (when=20 currentLSACount =3D=3D limitedLSACount)
> via flooding, there is = chance that=20 certain OSPF router
> will miss such a critial event. = Moreover,=20 the following
> premature actions may make someone else=20 believing
> there is not yet an overflow event. Why don't = we just=20 set
> up a beacon bit to notify everyone? For = example,
>=20 using a reserved filed in HELLO-Option to notify
> overflow.=20 Afterward, when all the neighbors acked
> with overflow=20 beacon-bit, reset (clear) such a bit.
>
> Could anyone = help=20 clearing my doubt?
>
> BTW, if the overflow process needs = to be=20 applied
> to Inter-AS LSAs (Area-Oriented), what kind of
> = LSA is=20 suggested to be prematured? Can I leave
> RTRLink, = NetLink, and=20 ASSummary alone?
> Will OSPF WG include the overflow process = as
>=20 a part of OSPFv3?
>
> Thanks in = advance.
>
> = Charles

------=_NextPart_000_0874_01C4650D.9834E4C0-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 8 22:48:08 2004 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 WAA09417 for ; Thu, 8 Jul 2004 22:48:08 -0400 (EDT) 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.00E0C4DF@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 22:48:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25115160 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 22:48:06 -0400 Received: from 64.233.170.206 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 22:37:31 -0400 Received: by mproxy.gmail.com with SMTP id d19so190580rnf for ; Thu, 08 Jul 2004 19:37:24 -0700 (PDT) Received: by 10.38.76.71 with SMTP id y71mr12882rna; Thu, 08 Jul 2004 19:37:24 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 8 Jul 2004 19:37:24 -0700 Reply-To: Mailing List Sender: Mailing List From: Dilip Kumar Subject: OSPF-V3 Instance ID To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello, I have couple of doubts w.r.to OSPF-V3's Instance ID interpretation 1. Can one router interface have more than one "Instance ID" configured simultaneously ? OSPF-V3 MIB draft (draft-ietf-ospf-ospfv3-mib-08) indicates that it is not possible. However, RFC-2740 indirectly points that it is possible. Following is the excerpt from the RFC-2740 "Another use for running multiple OSPF instances is if you want, for one reason or another, to have a single link belong to two or more OSPF areas." 2. Can LSAs received from a neighbor 'A' which has instance ID=2 be flooded to another neighbor B that has instance ID=5 ? InstanceID=2 InstanceID=5 A=================R================B Thanks in advance for any help. -- Dilip From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 8 23:15:20 2004 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 XAA12283 for ; Thu, 8 Jul 2004 23:15:20 -0400 (EDT) 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.00E0C9A1@cherry.ease.lsoft.com>; Thu, 8 Jul 2004 23:15:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25118986 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Jul 2004 23:15:19 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 Jul 2004 23:15:19 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DE9EA908167 for ; Thu, 8 Jul 2004 20:15:17 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26481-02 for ; Thu, 8 Jul 2004 20:15:17 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.53]) by prattle.redback.com (Postfix) with SMTP id 29E9B908165 for ; Thu, 8 Jul 2004 20:15:17 -0700 (PDT) References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <091801c46562$ec4f0ae0$0202a8c0@aceeinspiron> Date: Thu, 8 Jul 2004 23:15:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF-V3 Instance ID To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Dilip, ----- Original Message ----- From: "Dilip Kumar" To: Sent: Thursday, July 08, 2004 10:37 PM Subject: OSPF-V3 Instance ID > Hello, > I have couple of doubts w.r.to OSPF-V3's Instance ID interpretation > 1. Can one router interface have more than one "Instance ID" > configured simultaneously ? Yes. However, there may be implementations that only support one to be configured. > OSPF-V3 MIB draft (draft-ietf-ospf-ospfv3-mib-08) indicates that it is > not possible. This is wrong. ospfv3IfTable should be indexed by both ospfv3IfIndex and ospfv3InstId. > However, RFC-2740 indirectly points that it is possible. > Following is the excerpt from the RFC-2740 > > "Another use for running multiple OSPF instances is if you want, for > one reason or another, to have a single link belong to two or more > OSPF areas." This is one application of multiple instance IDs. > > 2. Can LSAs received from a neighbor 'A' which has instance ID=2 be > flooded to another neighbor B that has instance ID=5 ? > > InstanceID=2 InstanceID=5 > A=================R================B The base OSPFv3 specification (RFC 2740) certainly doesn't preclude this since the interface instance ID only has significance for that interface. In case of draft-mirtorabi-ospf-multi-area-adj-00.txt, the instance ID has significance beyond the scope of the interface and you would not. Hope this helps, Acee > > > Thanks in advance for any help. > -- Dilip From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 9 01:05:08 2004 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 BAA18436 for ; Fri, 9 Jul 2004 01:05:07 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00E0CB94@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 1:05:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25130104 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 01:04:59 -0400 Received: from 216.82.244.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 01:04:59 -0400 X-VirusChecked: Checked X-Env-Sender: rmalhotra@bankofny.com X-Msg-Ref: server-5.tower-65.messagelabs.com!1089349498!9271483 X-StarScan-Version: 5.2.10; banners=bankofny.com,-,- X-Originating-IP: [160.254.107.25] Received: (qmail 27546 invoked from network); 9 Jul 2004 05:04:58 -0000 Received: from unknown (HELO lgsbrc01.bankofny.com) (160.254.107.25) by server-5.tower-65.messagelabs.com with SMTP; 9 Jul 2004 05:04:58 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Fri, 9 Jul 2004 01:05:00 -0400 Reply-To: Mailing List Sender: Mailing List From: rmalhotra@BANKOFNY.COM Subject: Ravi Malhotra is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office starting 07/08/2004 and will not return until 07/12/2004. I will respond to your message when I return. Thank You, Ravi Malhotra ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 9 01:40:57 2004 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 BAA19717 for ; Fri, 9 Jul 2004 01:40:55 -0400 (EDT) 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.00E0CACA@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 1:40:55 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25132899 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 01:40:51 -0400 Received: from 210.202.42.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 01:40:50 -0400 Received: from hqmail1.alphanetworks.com (unverified) by sweeper2.alphanetworks.com (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Fri, 9 Jul 2004 13:38:41 +0800 Received: from CHARLESLIANG ([10.44.8.1]) by hqmail1.alphanetworks.com (Lotus Domino Release 5.0.12) with SMTP id 2004070913392267:11455 ; Fri, 9 Jul 2004 13:39:22 +0800 References: <087701c4652f$1fbc29f0$0202a8c0@aceeinspiron> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 01:39:22 PM, Serialize by Router on HQMAIL1/Alphanetworks(Release 5.0.12 |February 13, 2003) at 07/09/2004 01:39:23 PM, Serialize complete at 07/09/2004 01:39:23 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_013B_01C465BA.71DFC7B0" Message-ID: <013e01c46577$70b35110$01082c1e@CHARLESLIANG> Date: Fri, 9 Jul 2004 13:41:31 +0800 Reply-To: Mailing List Sender: Mailing List From: Charles Yi-tung Liang Organization: Alpha Networks Inc. Subject: Re: LSDB Overflow Limitation? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_013B_01C465BA.71DFC7B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Acee/Mitchell, Thanks for the advice. So the goal of this feature should be "If someone detects overflow event, it should select (proper) self-originated LSAs to be prematured." Again, I'm curious about the limit count. If the statement above is what we want, why should we required the limit count to be consistent in all OSPF routers? (I know what the cases will be, such as the problem described in RFC. I'm asking about the possible result as I proposed. Is there any chance to meet this situation?) Charles ----- Original Message -----=20 From: Acee Lindem=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Friday, July 09, 2004 5:04 AM Subject: [ Spam Mail ] Re: LSDB Overflow Limitation? (This message is = to be blocked by code: bknss61177) Charles,=20 You can choose to implement RFC 1765 but you cannot advertise the fact that your router is in overflow state in a=20 field in OSPF hello packets. First of all, there are no unused fields or option bits and even if there were we wouldn't want to=20 allocate them for this purpose.=20 There are free bits in the router LSA bits but personally I don't see a strong requirement to advertise entry or exit from overflow state.=20 I don't agree with everything that has been stated in this mail thread but I do agree that RFC 1765 dates to a time when low-end routers had very limited memory. Again, you can choose to implement this RFC. However, I personally=20 think a local knob specifying the upper limit on the number of external routes that you'll advertise is more useful.=20 Thanks, Acee=20 ----- Original Message -----=20 From: Charles Liang=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Thursday, July 08, 2004 2:17 PM Subject: Re: LSDB Overflow Limitation? Mitchell, It sounds like we prefer to pre-allocate the resource, rather than process the overflow conditions?! I also belive that the number has to be matched with the limit counts, and pre-allocating the resource should be a pratical solution. What I concerned is the exception? from RFC1765. If we have to implement this feature, we'd like to make sure the implementation works for all the possible cases. Otherwise, shouldn't we prefer to announce that my OSPF router will NEVER fall into LSDB overflow state. Therefore, I'm wondering that (1) Is my realization about RFC1765 correct? (2) Will the problem that I described happen? (3) Is there any side effect if I use a reserved and unused field in HELLO-Option? (4) Is it worth of implemeting RFC1765? Charles=20 Erblichs Sent by: Mailing List 07/08/2004 09:07 AM MST Please respond to Mailing List To: OSPF@PEACH.EASE.LSOFT.COM cc:=20 bcc:=20 Subject: [ Spam Mail ] Re: LSDB Overflow Limitation? (This message = is to be blocked by code: bknss61177) Charles, The number really has to do with the number of non default AS-external LSAs. These are believed to represent the maj of LSAs in the LSDB. In my experience, this only occurs with memory limited routers and routers within the same area are normally set to the same values. Realize that in memory limited routers, you are pre-allocating enough memory to cover the limit and that memory will not be available for other functions. Mitchell Erblich ----------------- > Charles Yi-tung Liang wrote: > > Hi, > > Here below is my understanding from RFC1765 > to process lsdb overflow condition. > > Goal: Make every OSPF router to be awared of > the overflow state, and thus reduce the number > of lsdb. That's why we required all the OSPF > routers setup the same limited lsdb threshold. > > Process: As mentioned in RFC1765. > > Limitation?/Problem?: > Since the new LSA update from someone triggers > overflow state (when currentLSACount =3D=3D limitedLSACount) > via flooding, there is chance that certain OSPF router > will miss such a critial event. Moreover, the following > premature actions may make someone else believing > there is not yet an overflow event. Why don't we just set > up a beacon bit to notify everyone? For example, > using a reserved filed in HELLO-Option to notify > overflow. Afterward, when all the neighbors acked > with overflow beacon-bit, reset (clear) such a bit. > > Could anyone help clearing my doubt? > > BTW, if the overflow process needs to be applied > to Inter-AS LSAs (Area-Oriented), what kind of > LSA is suggested to be prematured? Can I leave > RTRLink, NetLink, and ASSummary alone? > Will OSPF WG include the overflow process as > a part of OSPFv3? > > Thanks in advance. > > Charles ------=_NextPart_000_013B_01C465BA.71DFC7B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF

Acee/Mitchell,

Thanks for the = advice.

So the goal of = this feature should be

"If = someone detects overflow event, it

should select = (proper) self-originated

LSAs to = be = prematured."

Again, I'm = curious about the limit count.

If the statement = above is what we want,

why should we = required the limit count

to be consistent = in all OSPF routers?

(I know what the = cases will be, such as

the problem = described in RFC. I'm asking

about the = possible result as I proposed.

Is there any = chance to meet this situation?)

Charles

----- = Original Message -----
From:=20 Acee = Lindem=20
To: OSPF@PEACH.EASE.LSOFT.COM =

Sent: Friday, July 09, 2004 = 5:04 AM

Subject: [ Spam Mail ] Re: = LSDB Overflow=20 Limitation? (This message is to be blocked by code: bknss61177)

Charles,

You can choose to implement RFC 1765 = but you=20 cannot

advertise the fact that your router = is in=20 overflow state in a

field in OSPF hello packets. First of all, there are no unused = fields

or option bits and even if there = were=20 we wouldn't want to

allocate them for this purpose. =

There are free=20 bits in the router LSA bits but personally

I don't see a strong requirement to = advertise=20 entry or

exit from overflow state. =

I don't agree with everything that = has been=20 stated in this

mail thread but I do agree that RFC = 1765 dates to=20 a

time when low-end routers had very = limited=20 memory. Again, you

can choose to implement this RFC. = However, I=20 personally

think a local knob specifying = the upper=20 limit on the number

of external routes that you'll = advertise is more=20 useful.

Thanks,

Acee

----- Original Message -----
From:=20 Charles Liang =
To: OSPF@PEACH.EASE.LSOFT.COM =

Sent: Thursday, July 08, 2004 = 2:17=20 PM

Subject: Re: LSDB Overflow=20 Limitation?

Mitchell,

It sounds like we prefer to pre-allocate the resource,
rather = than=20 process the overflow conditions?!
I also belive that the number = has to be=20 matched with
the limit counts, and pre-allocating the = resource
should=20 be a pratical solution.

What I concerned is the exception? from RFC1765.
If we have to = implement this feature, we'd like
to make sure the implementation = works=20 for all
the possible cases. Otherwise, shouldn't we = prefer
to=20 announce that my OSPF router will NEVER fall
into LSDB overflow=20 state.

Therefore, I'm wondering that
(1) Is my realization about = RFC1765=20 correct?
(2) Will the problem that I described happen?
(3) Is = there=20 any side effect if I use a reserved
and unused field in=20 HELLO-Option?
(4) Is it worth of implemeting RFC1765?

Charles

Erblichs=20 <erblichs@EARTHLINK.NET>
Sent by: = Mailing=20 List <OSPF@PEACH.EASE.LSOFT.COM>
07/08/2004=20 09:07 AM MST
Please respond to Mailing=20 List

To: OSPF@PEACH.EASE.LSOFT.COM
cc:
bcc:
Subject: [ Spam Mail=20 ] Re: LSDB Overflow Limitation? (This message is to be blocked by = code:=20 bknss61177)

Charles,

The number really has to do=20 with
the number of non default=20 AS-external
LSAs.

These=20 are believed to represent the
maj of LSAs in the=20 LSDB.

In my = experience,=20 this only occurs
with memory limited routers and
routers = within=20 the same area are
normally set to the same=20 values.

Realize = that in=20 memory limited routers,
you are pre-allocating enough = memory
to=20 cover the limit and that memory will
not be available for = other=20 functions.

Mitchell=20 Erblich
-----------------

> Charles Yi-tung Liang=20 wrote:
>
> Hi,
>
> Here below is my = understanding=20 from RFC1765
> to process lsdb overflow = condition.
>
>=20 Goal: Make every OSPF router to be awared of
> the overflow = state, and=20 thus reduce the number
> of lsdb. That's why we required = all the=20 OSPF
> routers setup the same limited lsdb = threshold.
>
>=20 Process: As mentioned in RFC1765.
>
>=20 Limitation?/Problem?:
> Since the new LSA update from someone=20 triggers
> overflow state (when currentLSACount =3D=3D=20 limitedLSACount)
> via flooding, there is chance that certain = OSPF=20 router
> will miss such a critial event. Moreover, the=20 following
> premature actions may make someone else = believing
>=20 there is not yet an overflow event. Why don't we just = set
> up a=20 beacon bit to notify everyone? For example,
> using a = reserved=20 filed in HELLO-Option to notify
> overflow. Afterward, = when all=20 the neighbors acked
> with overflow beacon-bit, reset (clear) = such a=20 bit.
>
> Could anyone help clearing my = doubt?
>
>=20 BTW, if the overflow process needs to be applied
> to Inter-AS = LSAs=20 (Area-Oriented), what kind of
> LSA is suggested to be = prematured?=20 Can I leave
> RTRLink, NetLink, and ASSummary = alone?
>=20 Will OSPF WG include the overflow process as
> a part of=20 OSPFv3?
>
> Thanks in advance.
>
>=20 Charles

------=_NextPart_000_013B_01C465BA.71DFC7B0-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 9 11:42:06 2004 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 LAA06180 for ; Fri, 9 Jul 2004 11:42:06 -0400 (EDT) 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.00E0D580@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 11:42:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25216607 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 11:42:03 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 11:32:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05835; Fri, 9 Jul 2004 11:31:58 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200407091531.LAA05835@ietf.org> Date: Fri, 9 Jul 2004 11:31:58 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-cap-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 : Extensions to OSPF for Advertising Optional Router Capabilities Author(s) : A. Lindem, et al. Filename : draft-ietf-ospf-cap-03.txt Pages : 10 Date : 2004-7-8 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-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-cap-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-cap-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: <2004-7-9115337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-cap-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-cap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-9115337.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 9 11:42:30 2004 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 LAA06217 for ; Fri, 9 Jul 2004 11:42:30 -0400 (EDT) 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.00E0D453@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 11:42:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25218032 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 11:42:31 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 11:42:31 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5A0E62FC89C for ; Fri, 9 Jul 2004 08:42:30 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21860-03 for ; Fri, 9 Jul 2004 08:42:30 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.53]) by prattle.redback.com (Postfix) with SMTP id 856412FC896 for ; Fri, 9 Jul 2004 08:42:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0a3f01c465cb$4dbdb020$0202a8c0@aceeinspiron> Date: Fri, 9 Jul 2004 11:42:11 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Advertising a Router's Local Addresses in OSPF TE Extensions To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Are there any concerns with this document ? As I recall there was general agreement at the Minneapolis IETF. The only comment on the list was that it was unnecessary due to the fact that the loopbacks were carried in the router LSAs. However, I believe the general concensus was that putting in the TE LSA was a cleaner solution than populating TE database with router LSAs. Please correct me if I'm wrong. If there is no additional discussion, I'd like ask the authors to re-issue it with the new draft guidelines and last call it. Note that the OSPFv3 TE draft now references depends on the new TLV documented in this draft. Thanks, ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 9 14:01:50 2004 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 OAA16043 for ; Fri, 9 Jul 2004 14:01:50 -0400 (EDT) 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.00E0D7B3@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 14:01:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25231695 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 14:01:37 -0400 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 13:51:37 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i69HpZB07170 for ; Fri, 9 Jul 2004 20:51:35 +0300 (EET DST) X-Scanned: Fri, 9 Jul 2004 20:50:36 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i69Hoa5P029677 for ; Fri, 9 Jul 2004 20:50:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00YWszZO; Fri, 09 Jul 2004 20:50:33 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i69HoXu18539 for ; Fri, 9 Jul 2004 20:50:33 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 12:50:32 -0500 Received: mvebe001.americas.nokia.com 172.18.140.37 from 172.19.90.27 172.19.90.27 via HTTP with MS-WebStorage 6.0.6249 Received: from mvwsipd90027 by mvebe001.americas.nokia.com; 09 Jul 2004 10:47:59 -0700 Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) X-OriginalArrivalTime: 09 Jul 2004 17:50:32.0666 (UTC) FILETIME=[3B1583A0:01C465DD] Message-ID: <1089395279.853.57.camel@mvwsipd90027> Date: Fri, 9 Jul 2004 10:47:59 -0700 Reply-To: Mailing List Sender: Mailing List From: Suresh Melam Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Please see my comments inline, thanks, -suresh (Nagavenkata Suresh Melam) > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext >Vishwas Manral >Sent: Monday, July 05, 2004 9:38 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > >Hi Mukesh, > >Just wanted to add from ESP > >"If anti-replay is enabled (the default), the transmitted Sequence Number must never be >allowed to cycle." I think there is no consistent way a sender or receiver would work after >rollover. The receiver could very well break the SA on rollover(I think). > As manual keying doesn't use anti-replay mechanisms, the Sequence numbers need not be considered in our discussion. >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of >Vishwas Manral >Sent: Tuesday, July 06, 2004 10:03 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > >Hi Mukesh, > >>>1. I am not sure we should have a statement which says OSPFv3 >>>is only for IPv6. >>>"As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, >>> the distinction between the packets can be easily made by >>> IP version. " >>Do you have a replacement statement that you would prefer ? >>As the IP protocol type value for OSPF and OSPFv3 is same, >>we have to depend upon the IP version to separate OSPF and >>OSPFv3 packets. >There is a distinction between running over and "only for"(which >I assumed you meant the contents). It seems you mean running over. Yes, our intention was to mention "running over". We will change the sentence as follows. "The distinction between the OSPFv2 and OSPFv3 is made based on the IP version. If OSPFv3 runs on IPv4 protocol on a link for any reason, then IPsec security cannot be enabled on this link." >>>2. I think the value of next header field in the ESP header >>>to indicate OSPFv3 should be specified, though it may seem >>>a trivial question. >>Why do you think it should be specified? Whenever ESP is >>applied to any IP packet, the IP Protocol Type field value >>from the IP header is copied to the next header field of >>ESP/AH. There are no exceptions here. >The whole draft is full of informational statements like: - > > "AH in transport mode provides authentication to > higher layer protocols, selected portions of IPv6 header, selected > portions of extension headers and selected options. ESP with NULL > encryption in transport mode will provide authentication to only > higher layer protocol data and not to the IPv6 header, extension > headers and options." > >I think putting what the value in the next header would be would be >helpful. We will add another informational statement as follows. "IPsec copies the OSPF protocol value from the IPPROTO field of the IP packet to the next header field of the ESP/AH header." >>>3. ESP already states that "integrity-only (MUST be supported)" >>>do we really need to put down "ESP with NULL encryption MUST be >>>supported in transport mode". >>>An implementation may support ESP/AH that conform to ESP/AH RFCs, >>but the idea of putting this in this draft was to ensure that the >>user is allowed to use the specified combinations for securing >>the OSPF traffic. So that 2 independent secured OSPF >>implementations have at least one common combination to configure. >>Do you see any harm in putting this text in the draft ? >Not at all, but I am unable to see the point of >"ESP with NULL encryption MUST be supported in transport mode". The >point is we are saying a restriction on ESP MUST be there, where ESP >already has said its a MUST in the protocol itself. I think we may >also want to state other things then, like using ESN(if its supported), >default authentication/encryption algorithm etc when using manual keying. Our intention was to mention that "Inorder to support OSPFv3 authentication, the underlying IPsec implementation MUST support ESP with NULL encryption in transport mode." The reason is that we strongly suggest the usage of "ESP with NULL encryption in transport mode" for OSPFv3 authentication. We don't have any explicit suggestions for algorithms. But atleast now we should add another line. "While choosing algorithms for authentication/encryption, one should be careful to choose the algorithms that are suitable for manual keying. For eg., some stream cipher algorithms like AES-CCM are not suitable for manual keys" >>5. OSPF packets received in clear text or with incorrect AH >>>Integrity Check Value (ICV) MUST be dropped when authentication is >>>enabled. >>> Do we mean only AH/ICV or do we need ESP ICV too? Besides do we >>>need to state about combined mode algorithms like AES-CCM where >>>ICV may not checked even when authentication is done. >>It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the >>next version. >>The draft for AES-CCM says "it is inappropriate to use this CCM >>with statically configured keys". We are using staticaly configured >>keys here. So should we just NOT use AES-CCM ? >AES-CCM is an example of a combined mode algorithm, there are other >and can be further combined mode algorithms. We shouldn't put any >restriction that is based on the algorithm we use. > >From ESP "For combined mode algorithms, the ICV that would normally >appear at the end of the ESP packet (when integrity is selected) may >be omitted. " For the ICV term, we will add "if applicable". "OSPF packets received in clear text or with incorrect AH Integrity Check Value (ICV), if applicable, MUST be dropped when authentication is enabled." >>>6. SA Granularity and Selectors section - I think you are referring >>to parallel links we may want to state that too. >>No I am not referring to parallel links (if you mean 2 links connecting >>the same routers). It should be possible to use the same SA for multiple >>interfaces belonging to even different areas. >May be text clarifying what you mean should be put. Also text to state >whether in case of parallel links we need to have one SA or not can be >clarified. We will add another line: "User can choose to use same SA or different for parallel links." >>>7. Changing Keys may also be required in case of sequence number rollover. >>How is the user going to know about the sequence number rollover ? >>so that he/she can initiate the key change. That brings an interesting >>question. If the user never changes the keys, what happens when the >>sequence number rollovers ? >There are a lot of ways to provide that, a simple way could be to poll at some >interval, and when we are near rollover we change the keys. > >From ESP >"Thus, the sender's counter and the receiver's counter MUST > be reset (by establishing a new SA and thus a new key) prior to the > transmission of the 2^32nd packet on an SA." > >This is in case of normal SN, when we use ESN that will change, I think. In manual keying, sequence numbers are disabled. Hence there is no need for this discussion in the draft. >>That's a good idea but the problem is that if we put the new drafts >>as normative references, this draft will not be published before those >>drafts. Do we want to block the draft waiting for those drafts ? > >I think that is the authors wish. We will stick with the old RFCs. >>We will be working on addressing all the comments now and will publish >>an updated version of the draft probably after the IETF 60th. >That would be great. > >Thanks, >Vishwas From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 9 14:05:19 2004 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 OAA16382 for ; Fri, 9 Jul 2004 14:05:18 -0400 (EDT) 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.00E0D5E5@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 14:05:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25231933 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 14:05:16 -0400 Received: from 131.228.20.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 13:55:16 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i69HtEA03957 for ; Fri, 9 Jul 2004 20:55:14 +0300 (EET DST) X-Scanned: Fri, 9 Jul 2004 20:54:49 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i69Hsnpo001856 for ; Fri, 9 Jul 2004 20:54:49 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00XAxnYe; Fri, 09 Jul 2004 20:54:46 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i69Hsfu20100 for ; Fri, 9 Jul 2004 20:54:41 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 12:54:40 -0500 Received: mvebe001.americas.nokia.com 172.18.140.37 from 172.19.90.27 172.19.90.27 via HTTP with MS-WebStorage 6.0.6249 Received: from mvwsipd90027 by mvebe001.americas.nokia.com; 09 Jul 2004 10:52:07 -0700 Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) X-OriginalArrivalTime: 09 Jul 2004 17:54:40.0502 (UTC) FILETIME=[CECE4960:01C465DD] Message-ID: <1089395527.853.66.camel@mvwsipd90027> Date: Fri, 9 Jul 2004 10:52:07 -0700 Reply-To: Mailing List Sender: Mailing List From: Suresh Melam Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Abhay/Vishwas, comments inline, thanks, -suresh (Nagavenkata Suresh Melam) >> Hi Vishwas, >> >> Thanks for the comments. Please see my comments inline.. >> >> > 1. I am not sure we should have a statement which says OSPFv3 >> > is only for IPv6. >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, >> > the distinction between the packets can be easily made by >> > IP version. " >> >> Do you have a replacement statement that you would prefer ? >> As the IP protocol type value for OSPF and OSPFv3 is same, >> we have to depend upon the IP version to separate OSPF and >> OSPFv3 packets. > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux >will be based on OSPF protocol version. > IPsec selectors are not usually any deeper than protocol field of IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF protocol version cannot be one of the selector. If OSPFv3 runs on IPv4 transport, there wouldn't be any way to distinguish OSPFv3 packets from OSPFv2 packets, as both of them use same protocol value. Thus IPsec security, as mentioned in "Security considerations" section of RFC2740 and ospfv3-auth draft, cannot be provided to these packets. Perhaps this should be mentioned in the "Security Considerations" section of ospfv3-af-alt draft. >Regards, >-Roy- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 9 15:12:40 2004 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 PAA21560 for ; Fri, 9 Jul 2004 15:12:36 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00E0D994@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 15:12:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25240261 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 15:12:34 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 15:12:33 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2F6A166CD2 for ; Fri, 9 Jul 2004 12:12:31 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12564-05 for ; Fri, 9 Jul 2004 12:12:30 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.53]) by prattle.redback.com (Postfix) with SMTP id DD78866CD0 for ; Fri, 9 Jul 2004 12:12:29 -0700 (PDT) References: <087701c4652f$1fbc29f0$0202a8c0@aceeinspiron> <013e01c46577$70b35110$01082c1e@CHARLESLIANG> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BB3_01C465C7.1C60F4F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0bb601c465e8$a3eb4760$0202a8c0@aceeinspiron> Date: Fri, 9 Jul 2004 15:12:12 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: LSDB Overflow Limitation? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0BB3_01C465C7.1C60F4F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Charles,=20 What I said was that I thought a configurable local limit on the number of external routes that may be exported into OSPF was simpler and more useful than RFC 1765. You'll have to make your own feature/implementation decisions based on your target market and its associated requirements.=20 Thanks, Acee=20 ----- Original Message -----=20 From: Charles Yi-tung Liang=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Friday, July 09, 2004 1:41 AM Subject: Re: LSDB Overflow Limitation? Acee/Mitchell, Thanks for the advice. So the goal of this feature should be "If someone detects overflow event, it should select (proper) self-originated LSAs to be prematured." Again, I'm curious about the limit count. If the statement above is what we want, why should we required the limit count to be consistent in all OSPF routers? (I know what the cases will be, such as the problem described in RFC. I'm asking about the possible result as I proposed. Is there any chance to meet this situation?) Charles ----- Original Message -----=20 From: Acee Lindem=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Friday, July 09, 2004 5:04 AM Subject: [ Spam Mail ] Re: LSDB Overflow Limitation? (This message = is to be blocked by code: bknss61177) Charles,=20 You can choose to implement RFC 1765 but you cannot advertise the fact that your router is in overflow state in a=20 field in OSPF hello packets. First of all, there are no unused = fields or option bits and even if there were we wouldn't want to=20 allocate them for this purpose.=20 There are free bits in the router LSA bits but personally I don't see a strong requirement to advertise entry or exit from overflow state.=20 I don't agree with everything that has been stated in this mail thread but I do agree that RFC 1765 dates to a time when low-end routers had very limited memory. Again, you can choose to implement this RFC. However, I personally=20 think a local knob specifying the upper limit on the number of external routes that you'll advertise is more useful.=20 Thanks, Acee=20 ----- Original Message -----=20 From: Charles Liang=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Thursday, July 08, 2004 2:17 PM Subject: Re: LSDB Overflow Limitation? Mitchell, It sounds like we prefer to pre-allocate the resource, rather than process the overflow conditions?! I also belive that the number has to be matched with the limit counts, and pre-allocating the resource should be a pratical solution. What I concerned is the exception? from RFC1765. If we have to implement this feature, we'd like to make sure the implementation works for all the possible cases. Otherwise, shouldn't we prefer to announce that my OSPF router will NEVER fall into LSDB overflow state. Therefore, I'm wondering that (1) Is my realization about RFC1765 correct? (2) Will the problem that I described happen? (3) Is there any side effect if I use a reserved and unused field in HELLO-Option? (4) Is it worth of implemeting RFC1765? Charles=20 Erblichs Sent by: Mailing List 07/08/2004 09:07 AM MST Please respond to Mailing List To: OSPF@PEACH.EASE.LSOFT.COM cc:=20 bcc:=20 Subject: [ Spam Mail ] Re: LSDB Overflow Limitation? (This message = is to be blocked by code: bknss61177) Charles, The number really has to do with the number of non default AS-external LSAs. These are believed to represent the maj of LSAs in the LSDB. In my experience, this only occurs with memory limited routers and routers within the same area are normally set to the same values. Realize that in memory limited routers, you are pre-allocating enough memory to cover the limit and that memory will not be available for other functions. Mitchell Erblich ----------------- > Charles Yi-tung Liang wrote: > > Hi, > > Here below is my understanding from RFC1765 > to process lsdb overflow condition. > > Goal: Make every OSPF router to be awared of > the overflow state, and thus reduce the number > of lsdb. That's why we required all the OSPF > routers setup the same limited lsdb threshold. > > Process: As mentioned in RFC1765. > > Limitation?/Problem?: > Since the new LSA update from someone triggers > overflow state (when currentLSACount =3D=3D limitedLSACount) > via flooding, there is chance that certain OSPF router > will miss such a critial event. Moreover, the following > premature actions may make someone else believing > there is not yet an overflow event. Why don't we just set > up a beacon bit to notify everyone? For example, > using a reserved filed in HELLO-Option to notify > overflow. Afterward, when all the neighbors acked > with overflow beacon-bit, reset (clear) such a bit. > > Could anyone help clearing my doubt? > > BTW, if the overflow process needs to be applied > to Inter-AS LSAs (Area-Oriented), what kind of > LSA is suggested to be prematured? Can I leave > RTRLink, NetLink, and ASSummary alone? > Will OSPF WG include the overflow process as > a part of OSPFv3? > > Thanks in advance. > > Charles ------=_NextPart_000_0BB3_01C465C7.1C60F4F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF

Charles,

What I said was that I = thought a=20 configurable local

limit on the number of external routes = that may be=20 exported into

OSPF was simpler and more useful than = RFC=20 1765. You'll have to

make your own feature/implementation = decisions=20 based on your

target market and its associated = requirements.=20

Thanks,

Acee

----- Original Message -----
From:=20 Charles Yi-tung = Liang
To: OSPF@PEACH.EASE.LSOFT.COM =

Sent: Friday, July 09, 2004 = 1:41 AM

Subject: Re: LSDB Overflow=20 Limitation?

Acee/Mitchell,

Thanks for the = advice.

So the goal of = this feature should be

"If = someone detects overflow event, it

should select = (proper) self-originated

LSAs to = be=20 prematured."

Again, I'm = curious about the limit count.

If the = statement above is what we want,

why should we = required the limit count

to be = consistent in all OSPF routers?

(I know what = the cases will be, such as

the problem = described in RFC. I'm=20 asking

about the = possible result as I proposed.

Is there any = chance to meet this situation?)

Charles

----- = Original Message -----
From:=20 Acee = Lindem=20
To: OSPF@PEACH.EASE.LSOFT.COM =

Sent: Friday, July 09, 2004 = 5:04=20 AM

Subject: [ Spam Mail ] Re: = LSDB Overflow=20 Limitation? (This message is to be blocked by code: = bknss61177)

Charles,

You can choose to implement RFC = 1765 but you=20 cannot

advertise the fact that your router = is in=20 overflow state in a

field in OSPF hello packets. First of all, there are no unused = fields

or option bits and even if = there were=20 we wouldn't want to

allocate them for this purpose. =

There are free=20 bits in the router LSA bits but personally

I don't see a strong requirement to = advertise=20 entry or

exit from overflow state. =

I don't agree with everything that = has been=20 stated in this

mail thread but I do agree that RFC = 1765 dates=20 to a

time when low-end routers had very = limited=20 memory. Again, you

can choose to implement this RFC. = However, I=20 personally

think a local knob specifying = the upper=20 limit on the number

of external routes that you'll = advertise is=20 more useful.

Thanks,

Acee

----- Original Message ----- =
From:=20 Charles Liang =
To: OSPF@PEACH.EASE.LSOFT.COM=20

Sent: Thursday, July 08, = 2004 2:17=20 PM

Subject: Re: LSDB Overflow=20 Limitation?

Mitchell,

It sounds like we prefer to pre-allocate the = resource,
rather than=20 process the overflow conditions?!
I also belive that the number = has to=20 be matched with
the limit counts, and pre-allocating the=20 resource
should be a pratical solution.

What I concerned is the exception? from RFC1765.
If we have = to=20 implement this feature, we'd like
to make sure the = implementation works=20 for all
the possible cases. Otherwise, shouldn't we = prefer
to=20 announce that my OSPF router will NEVER fall
into LSDB overflow = state.

Therefore, I'm wondering that
(1) Is my realization about = RFC1765=20 correct?
(2) Will the problem that I described happen?
(3) = Is there=20 any side effect if I use a reserved
and unused field in=20 HELLO-Option?
(4) Is it worth of implemeting RFC1765?

Charles

Erblichs=20 <erblichs@EARTHLINK.NET>
Sent = by: Mailing=20 List <OSPF@PEACH.EASE.LSOFT.COM>
07/08/2004=20 09:07 AM MST
Please respond to Mailing=20 List

To: OSPF@PEACH.EASE.LSOFT.COM
cc:=20
bcc:
Subject: = [ Spam Mail ] Re: LSDB Overflow Limitation? (This message = is to be=20 blocked by code: bknss61177)

Charles,

The number really has to do = with
the number of non default=20 AS-external
LSAs.

These are believed to represent = the
maj of=20 LSAs in the LSDB.

In my=20 experience, this only occurs
with memory limited routers=20 and
routers within the same area are
normally set to = the same=20 values.

Realize = that in=20 memory limited routers,
you are pre-allocating enough=20 memory
to cover the limit and that memory will
not be=20 available for other functions.

Mitchell=20 Erblich
-----------------

> Charles Yi-tung Liang=20 wrote:
>
> Hi,
>
> Here below is my = understanding=20 from RFC1765
> to process lsdb overflow = condition.
>
>=20 Goal: Make every OSPF router to be awared of
> the overflow = state,=20 and thus reduce the number
> of lsdb. That's why we = required=20 all the OSPF
> routers setup the same limited lsdb=20 threshold.
>
> Process: As mentioned in=20 RFC1765.
>
> Limitation?/Problem?:
> Since the = new LSA=20 update from someone triggers
> overflow state (when = currentLSACount=20 =3D=3D limitedLSACount)
> via flooding, there is chance that = certain=20 OSPF router
> will miss such a critial event. = Moreover, the=20 following
> premature actions may make someone else=20 believing
> there is not yet an overflow event. Why = don't we=20 just set
> up a beacon bit to notify everyone? For=20 example,
> using a reserved filed in HELLO-Option to = notify
>=20 overflow. Afterward, when all the neighbors acked
> = with=20 overflow beacon-bit, reset (clear) such a bit.
>
> = Could=20 anyone help clearing my doubt?
>
> BTW, if the = overflow=20 process needs to be applied
> to Inter-AS LSAs = (Area-Oriented), what=20 kind of
> LSA is suggested to be prematured? Can I=20 leave
> RTRLink, NetLink, and ASSummary alone?
> Will = OSPF WG=20 include the overflow process as
> a part of = OSPFv3?
>
>=20 Thanks in advance.
>
>=20 = Charles

------=_NextPart_000_0BB3_01C465C7.1C60F4F0-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 9 17:52:26 2004 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 RAA04215 for ; Fri, 9 Jul 2004 17:52:25 -0400 (EDT) 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.00E0DB30@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 17:52:25 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25256726 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 17:52:23 -0400 Received: from 131.228.20.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 17:52:23 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i69LqMA26409 for ; Sat, 10 Jul 2004 00:52:22 +0300 (EET DST) X-Scanned: Sat, 10 Jul 2004 00:51:49 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i69LpnBB011850 for ; Sat, 10 Jul 2004 00:51:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00mNh2CT; Sat, 10 Jul 2004 00:51:47 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i69Lpkn04939 for ; Sat, 10 Jul 2004 00:51:46 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 16:51:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRlC/eTRcHCWO7nQISLwujGTe1CxgA7/2lw X-OriginalArrivalTime: 09 Jul 2004 21:51:45.0374 (UTC) FILETIME=[ED7D7FE0:01C465FE] Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A8E@daebe009.americas.nokia.com> Date: Fri, 9 Jul 2004 16:51:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Mitchell, Comments inline.. > > Do you still think that we should mention it everywhere in the > > draft that the pkts will be dropped by the IPsec layer ? Or > > we should clarify it more in section 2 and make it explicit > > that whenever we say "drop the pkt", it means it is dropped > > by the IPsec layer ? >=20 > IMO, Minimally it should be explicitly stated. Ok we will try to make it explicit in the next version. > > By the way, isn't it the way we handle authentication in OSPFv2 ? > > If you don't have any authentication and FULL adjacency between > > the neighbors and then you change the configuration of one of > > the neighbors to use simple/md5 authentication, the adjacency > > is not torn down immediately. It takes the dead interval time > > before each of them mark the adjacency down. >=20 > First, what we are dealing here is online reconfiguration > or dynamic reconfiguration. I haven't seen really any > discussion in 2328, wrt changing values after 2-ways/ > adjs are established. I haven't seen anything either. I tried our implementation and reported the findings. Are there any implementations that will tear down the adjacency immediately when the authentication method is changed ? > IMO, I have two very different ways of thinking about this. >=20 > #1 If a field within a pkt is changed that "forces" the > link partner to now drop the pkt, the router dead > interval time frame is a built in latency period to > re-establish re-synchronization of the values. However, > this allows data movement accross the adj, where the > adj REALLY is no longer valid / synchronized. In addition, > if another router duplicates anothers router-id, but > changes one required synchronized value, to invalidate > the pkt, and this one pkt causes the adj to be dropped, > it could be a DOS type attack. >=20 > #2 To properly achieve "Faster Failure Detection", > IMO Guyal, et al, should have considered the reception > of a NOW invalid pkt. This would eliminate the router > dead interval delay in tearing down the adj. >=20 > It is the delay's / latencies that are built in > tearing down a now no longer valid adj. >=20 > So, we should be leaning from OSPFv2 the behaviours > that we don't want in v3, and attempt to remove them > versus forcing us to live with our past ?mistakes? for > consistency sakes. Thus, IMO, if authentication is > CHANGED locally the adj should be torn down immediately, > and the reception of a pkt that would cause it to be > dropped by the recvr, should effect the state of the > adj. BTW, this should be only one of many fields that > should effect the state of the adj. Don't we have to assume > that the adj is going to fail anyway? Is the reception > of a hello pkt that will be dropped repeatedly, > the first indication that the nbr is no longer reachable? > I think yes. Thus, it is a valid nbr state machine event > to the down state. However, since it is so drastic, > I assume that a CLI command should allow this event. The current behavior is actually helpful during the configuration=20 changes. Consider the scnerio when an admin is transitioning the OSPF (v2 or v3) network from "no authentication" to "simple=20 authentication". Because of the current behavior, he/she gets=20 enough time to change the configuration on all the routers without=20 bringing the network (or data forwarding) down. If the router tears down the adjacency immediately, there will be a forwarding break in this case. IMHO, it is not worth tearing down the adjacency when the admin makes this configuration change just to notify him/her for some incorrect configuration. If the configuration is incorrect (mismatching authentication types on routers), the admin will know within minutes anyway. Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 9 20:04:18 2004 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 UAA14898 for ; Fri, 9 Jul 2004 20:04:17 -0400 (EDT) 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.00E0DDA9@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 20:04:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25268077 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 20:04:15 -0400 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 20:04:15 -0400 Received: from user-38lc12k.dialup.mindspring.com ([209.86.4.84] helo=earthlink.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Bj5Lh-00060W-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 09 Jul 2004 17:04:14 -0700 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: <8D260779A766FB4A9C1739A476F84FA401F79A8E@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <40EF3379.8AE9BAA0@earthlink.net> Date: Fri, 9 Jul 2004 17:08:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukesh, Inline.. Mitchell Mukesh.Gupta@NOKIA.COM wrote: > > Mitchell, > > Comments inline.. > > > > Do you still think that we should mention it everywhere in the > > > draft that the pkts will be dropped by the IPsec layer ? Or > > > we should clarify it more in section 2 and make it explicit > > > that whenever we say "drop the pkt", it means it is dropped > > > by the IPsec layer ? > > > > IMO, Minimally it should be explicitly stated. > > Ok we will try to make it explicit in the next version. > > > > By the way, isn't it the way we handle authentication in OSPFv2 ? > > > If you don't have any authentication and FULL adjacency between > > > the neighbors and then you change the configuration of one of > > > the neighbors to use simple/md5 authentication, the adjacency > > > is not torn down immediately. It takes the dead interval time > > > before each of them mark the adjacency down. > > > > First, what we are dealing here is online reconfiguration > > or dynamic reconfiguration. I haven't seen really any > > discussion in 2328, wrt changing values after 2-ways/ > > adjs are established. > > I haven't seen anything either. I tried our implementation > and reported the findings. > > Are there any implementations that will tear down the adjacency > immediately when the authentication method is changed ? > > > IMO, I have two very different ways of thinking about this. > > > > #1 If a field within a pkt is changed that "forces" the > > link partner to now drop the pkt, the router dead > > interval time frame is a built in latency period to > > re-establish re-synchronization of the values. However, > > this allows data movement accross the adj, where the > > adj REALLY is no longer valid / synchronized. In addition, > > if another router duplicates anothers router-id, but > > changes one required synchronized value, to invalidate > > the pkt, and this one pkt causes the adj to be dropped, > > it could be a DOS type attack. > > > > #2 To properly achieve "Faster Failure Detection", > > IMO Guyal, et al, should have considered the reception > > of a NOW invalid pkt. This would eliminate the router > > dead interval delay in tearing down the adj. > > > > It is the delay's / latencies that are built in > > tearing down a now no longer valid adj. > > > > So, we should be leaning from OSPFv2 the behaviours > > that we don't want in v3, and attempt to remove them > > versus forcing us to live with our past ?mistakes? for > > consistency sakes. Thus, IMO, if authentication is > > CHANGED locally the adj should be torn down immediately, > > and the reception of a pkt that would cause it to be > > dropped by the recvr, should effect the state of the > > adj. BTW, this should be only one of many fields that > > should effect the state of the adj. Don't we have to assume > > that the adj is going to fail anyway? Is the reception > > of a hello pkt that will be dropped repeatedly, > > the first indication that the nbr is no longer reachable? > > I think yes. Thus, it is a valid nbr state machine event > > to the down state. However, since it is so drastic, > > I assume that a CLI command should allow this event. > > The current behavior is actually helpful during the configuration > changes. Consider the scnerio when an admin is transitioning the > OSPF (v2 or v3) network from "no authentication" to "simple > authentication". Because of the current behavior, he/she gets > enough time to change the configuration on all the routers without > bringing the network (or data forwarding) down. If the router > tears down the adjacency immediately, there will be a forwarding > break in this case. > > IMHO, it is not worth tearing down the adjacency when the admin > makes this configuration change just to notify him/her for some > incorrect configuration. If the configuration is incorrect > (mismatching authentication types on routers), the admin will > know within minutes anyway. Is it really helpful? Ask any customer whether having his system that takes minutes to respond to a router CLI change and I think you will loose that customer! During this latency period that can be 1 hr, no hellos are being responded to, no LSAs are being sent or responded to, the DR doesn't acknowledge new nbrs, etc,... All due to a CLI timebomb. If it happens immediately, the admin should know that he just ran a CLI change and this was the cause. The latency time for the system to normally ack the change results in longer than necessary LSDB synchronization and failure detection. If you listed your nbrs, the list would not actually be correct, since you are no longer communicating with your nbrs. Lets see. If I am a router and I have my hello interval set to X secs, I can set up adjs with one set of routers. Then I change it to another value and get adjs with another set of routers. Then if I just toggle the value back and forth within router dead interval time frame, I will have adjs with routers with different hello intervals.. Is this proper operation???? If a change is done that is going to eventually drop the adj, then why wait? If the change is a two step process on a single router, then impliment a commit type functionality. I just think that this is an area that really needs a standardized RFC that allows the customer to get immediate changes to changed configurations. > > Regards > Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jul 10 03:57:30 2004 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 DAA28337 for ; Sat, 10 Jul 2004 03:57:30 -0400 (EDT) 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.00E0E600@cherry.ease.lsoft.com>; Sat, 10 Jul 2004 3:57:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25301497 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 10 Jul 2004 03:57:27 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 10 Jul 2004 03:57:27 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRl363Ikt3m+vnXTPmK9q1swyNltgAcqkbw Message-ID: Date: Sat, 10 Jul 2004 01:00:11 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Suresh, I was thinking the following assumptions would hold good: - 1. We either run OSPFv3 for IPv4 or OSPFv2 for IPv4 not both. 2. While configuring the SA(we dont use IKE), both ends agree to the = protocol they are using. Wouldn't it help in that case? I think the AF draft should state the = limitation instead. Suresh, also if the link is assumed to be point-to-point would we still = restrict to the use of static configuration and not IKE. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Suresh Melam Sent: Friday, July 09, 2004 11:22 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Hi Abhay/Vishwas, comments inline, thanks, -suresh (Nagavenkata Suresh Melam) >> Hi Vishwas, >> >> Thanks for the comments. Please see my comments inline.. >> >> > 1. I am not sure we should have a statement which says OSPFv3 >> > is only for IPv6. >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, >> > the distinction between the packets can be easily made by >> > IP version. " >> >> Do you have a replacement statement that you would prefer ? >> As the IP protocol type value for OSPF and OSPFv3 is same, >> we have to depend upon the IP version to separate OSPF and >> OSPFv3 packets. > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux >will be based on OSPF protocol version. > IPsec selectors are not usually any deeper than protocol field of IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF protocol version cannot be one of the selector. If OSPFv3 runs on IPv4 transport, there wouldn't be any way to distinguish OSPFv3 packets from OSPFv2 packets, as both of them use same protocol value. Thus IPsec security, as mentioned in "Security considerations" section of RFC2740 and ospfv3-auth draft, cannot be provided to these packets. Perhaps this should be mentioned in the "Security Considerations" section of ospfv3-af-alt draft. >Regards, >-Roy- From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jul 11 14:22:04 2004 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 OAA05132 for ; Sun, 11 Jul 2004 14:22:04 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00E1019B@cherry.ease.lsoft.com>; 11 Jul 2004 14:22:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25431591 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 11 Jul 2004 14:21:59 -0400 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jul 2004 14:21:59 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6BILvb13865 for ; Sun, 11 Jul 2004 21:21:57 +0300 (EET DST) X-Scanned: Sun, 11 Jul 2004 21:21:33 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6BILXk5015147 for ; Sun, 11 Jul 2004 21:21:33 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00md9iaF; Sun, 11 Jul 2004 21:21:32 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6BILVn27368 for ; Sun, 11 Jul 2004 21:21:31 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 11 Jul 2004 13:21:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRmEbAmi6Fwh/RFQbe1/wT3BG8w0gBYT/1w X-OriginalArrivalTime: 11 Jul 2004 18:21:30.0322 (UTC) FILETIME=[E328D320:01C46773] Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A90@daebe009.americas.nokia.com> Date: Sun, 11 Jul 2004 13:21:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Mitchell, Comments inline.. > Is it really helpful? Ask any customer whether having > his system that takes minutes to respond to a router CLI > change and I think you will loose that customer! Little correction.. It is not taking minutes to respond to a router CLI change. The router where you changed the authentication type will immediately start using the new authentication type. What about when the customer turns on OSPF on an interface. Doesn't that take minutes to be fully functional. That doesn't mean that the router took minutes to respond. > During this latency period that can be 1 hr, > no hellos are being responded to, no LSAs are being > sent or responded to, the DR doesn't acknowledge new > nbrs, etc,... All due to a CLI timebomb. If it happens > immediately, the admin should know that he just ran > a CLI change and this was the cause. How can it be 1 hour ? I remember you talking about no-hellos on the demand circuits. What happens when a neighbor crashes in these situation. How do we detect that the neighbor is dead and remove that from our neighbors' list ? > The latency time for the system to normally ack the > change results in longer than necessary LSDB > synchronization and failure detection. >=20 > If you listed your nbrs, the list would not actually > be correct, since you are no longer communicating > with your nbrs. Lets see. If I am a router and I > have my hello interval set to X secs, I can set up > adjs with one set of routers. Then I change it to > another value and get adjs with another set of routers. > Then if I just toggle the value back and forth within > router dead interval time frame, I will have adjs > with routers with different hello intervals.. Is > this proper operation???? >=20 > If a change is done that is going to eventually drop > the adj, then why wait? If the change is a two step > process on a single router, then impliment a commit > type functionality. >=20 > I just think that this is an area that really needs > a standardized RFC that allows the customer to get > immediate changes to changed configurations. Ok. Even if we agree with what you are saying, what exactly are you suggesting for the OSPFv3 security draft ? Would you be a little specific and tell me what you want to add/change in the draft ? Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jul 11 16:09:16 2004 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 QAA10371 for ; Sun, 11 Jul 2004 16:09:15 -0400 (EDT) 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.00E101C8@cherry.ease.lsoft.com>; 11 Jul 2004 16:09:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25437843 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 11 Jul 2004 16:09:12 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jul 2004 16:09:12 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2004 13:10:24 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6BK9At1008767 for ; Sun, 11 Jul 2004 13:09:10 -0700 (PDT) Received: from irp-view9.cisco.com (irp-view9.cisco.com [171.70.65.147]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVG27838; Sun, 11 Jul 2004 13:07:59 -0700 (PDT) References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sun, 11 Jul 2004 13:09:09 -0700 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Vishwas, As the draft stands today, it doesn't venture into the security mechanism(s). I guess we need to add something. My preference will be to stick with IPSec even for OSPFv3 IPv4 AF (irrespective of ipv4 or ipv6 transport). Regards, -Roy- On 07/05/04-0700 at 10:41pm, Vishwas Manral writes: > Hi Abhay, > > Good point, didnt know the draft was actually out(actually I > think Sina/Michael actually started working on it togather a > long long while back before the idea was dropped). Just curious > would we still use IPSec or would we use the current > authentication mechanism? > > To add further, we intend to add a draft to allow out of order > sequence of packets with authentication enabled like in IPSec > for OSPFv2 too. (IP does not guarentee inorder dilevery > anyway/besides we can allow for packet prioritization) > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Abhay > Roy > Sent: Tuesday, July 06, 2004 11:04 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > > On 07/05/04-0500 at 2:19pm, Mukesh.Gupta@NOKIA.COM writes: > > > Hi Vishwas, > > > > Thanks for the comments. Please see my comments inline.. > > > > > 1. I am not sure we should have a statement which says OSPFv3 > > > is only for IPv6. > > > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > > the distinction between the packets can be easily made by > > > IP version. " > > > > Do you have a replacement statement that you would prefer ? > > As the IP protocol type value for OSPF and OSPFv3 is same, > > we have to depend upon the IP version to separate OSPF and > > OSPFv3 packets. > > Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > will be based on OSPF protocol version. > > Regards, > -Roy- > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jul 11 16:14:11 2004 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 QAA10609 for ; Sun, 11 Jul 2004 16:14:10 -0400 (EDT) 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.00E101B1@cherry.ease.lsoft.com>; 11 Jul 2004 16:14:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25438446 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 11 Jul 2004 16:14:09 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jul 2004 16:14:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2004 13:15:21 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6BKE5t3009873 for ; Sun, 11 Jul 2004 13:14:06 -0700 (PDT) Received: from irp-view9.cisco.com (irp-view9.cisco.com [171.70.65.147]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVG27925; Sun, 11 Jul 2004 13:12:54 -0700 (PDT) References: <1089395527.853.66.camel@mvwsipd90027> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sun, 11 Jul 2004 13:14:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <1089395527.853.66.camel@mvwsipd90027> Precedence: list Suresh, I am afraid, we need to have IPsec selector go deeper. Otherwise we can't allow different OSPFv3 Instance ID's to use different IPsec security associations (SAs). I noticed that draft-ietf-ospf-ospfv3-auth doesn't talk about possibility of running multiple instance per link, and it's interaction / implications with IPSec SAs. We should address that. Regards, -Roy- On 07/09/04-0700 at 10:52am, Suresh Melam writes: > Hi Abhay/Vishwas, > > comments inline, > > thanks, > -suresh (Nagavenkata Suresh Melam) > > > >> Hi Vishwas, > >> > >> Thanks for the comments. Please see my comments inline.. > >> > >> > 1. I am not sure we should have a statement which says OSPFv3 > >> > is only for IPv6. > >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > >> > the distinction between the packets can be easily made by > >> > IP version. " > >> > >> Do you have a replacement statement that you would prefer ? > >> As the IP protocol type value for OSPF and OSPFv3 is same, > >> we have to depend upon the IP version to separate OSPF and > >> OSPFv3 packets. > > > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > >will be based on OSPF protocol version. > > > > IPsec selectors are not usually any deeper than protocol field of > IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF > protocol version cannot be one of the selector. > > If OSPFv3 runs on IPv4 transport, there wouldn't be any way > to distinguish OSPFv3 packets from OSPFv2 packets, as both of them > use same protocol value. Thus IPsec security, as mentioned in > "Security considerations" section of RFC2740 and ospfv3-auth draft, > cannot be provided to these packets. Perhaps this should be mentioned > in the "Security Considerations" section of ospfv3-af-alt draft. > > >Regards, > >-Roy- > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 12 22:30:00 2004 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 WAA16286 for ; Mon, 12 Jul 2004 22:30:00 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00E12E09@cherry.ease.lsoft.com>; Mon, 12 Jul 2004 22:30:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25641642 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 12 Jul 2004 22:29:59 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jul 2004 22:29:59 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i6D2TvBm049066 for ; Mon, 12 Jul 2004 19:29:58 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i6D2Tve33549 for ; Mon, 12 Jul 2004 19:29:57 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i6D2TvN09439 for ; Mon, 12 Jul 2004 19:29:57 -0700 (PDT) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs References: <0a3f01c465cb$4dbdb020$0202a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20040712192635.D31048@sapphire.juniper.net> Date: Mon, 12 Jul 2004 19:29:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: Advertising a Router's Local Addresses in OSPF TE Extensions To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0a3f01c465cb$4dbdb020$0202a8c0@aceeinspiron> Precedence: list Hi Acee, On Fri, 9 Jul 2004, Acee Lindem wrote: > Are there any concerns with this document > ? As I recall there > was general agreement at the Minneapolis IETF. The only > comment on the list was that it was unnecessary due to the > fact that the loopbacks were carried in the router LSAs. That comment was addressed and section 3 of the draft was updated to reflect why router LSAs cannot be used for this purpose. > However, > I believe the general concensus was that putting in the TE > LSA was a cleaner solution than populating TE database > with router LSAs. Please correct me if I'm wrong. > Yes. > If there is no additional discussion, I'd like ask the authors to > re-issue it with the new draft guidelines and last call it. > Will re-issue it this week. > Note that the OSPFv3 TE draft now references depends on > the new TLV documented in this draft. > Great. Thanks, rahul > Thanks, > ------ > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 13 10:12:35 2004 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 KAA12787 for ; Tue, 13 Jul 2004 10:12:35 -0400 (EDT) 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.00E13C61@cherry.ease.lsoft.com>; Tue, 13 Jul 2004 10:12:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25738944 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jul 2004 10:12:32 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jul 2004 10:12:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRnhAgOxnf9biFSQKq+KvDkqoNGdABXS9eA Message-ID: Date: Tue, 13 Jul 2004 07:15:24 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Abhay, I agree that could be made clearer in Section 7. Also keeping with the OSPFv3 RFC, the use of term link instead of = interface in a few cases in the draft. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Abhay Roy Sent: Monday, July 12, 2004 1:44 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Suresh, I am afraid, we need to have IPsec selector go deeper. Otherwise we can't allow different OSPFv3 Instance ID's to use different IPsec security associations (SAs). I noticed that draft-ietf-ospf-ospfv3-auth doesn't talk about possibility of running multiple instance per link, and it's interaction / implications with IPSec SAs. We should address that. Regards, -Roy- On 07/09/04-0700 at 10:52am, Suresh Melam writes: > Hi Abhay/Vishwas, > > comments inline, > > thanks, > -suresh (Nagavenkata Suresh Melam) > > > >> Hi Vishwas, > >> > >> Thanks for the comments. Please see my comments inline.. > >> > >> > 1. I am not sure we should have a statement which says OSPFv3 > >> > is only for IPv6. > >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > >> > the distinction between the packets can be easily made by > >> > IP version. " > >> > >> Do you have a replacement statement that you would prefer ? > >> As the IP protocol type value for OSPF and OSPFv3 is same, > >> we have to depend upon the IP version to separate OSPF and > >> OSPFv3 packets. > > > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > >will be based on OSPF protocol version. > > > > IPsec selectors are not usually any deeper than protocol field of > IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF > protocol version cannot be one of the selector. > > If OSPFv3 runs on IPv4 transport, there wouldn't be any way > to distinguish OSPFv3 packets from OSPFv2 packets, as both of them > use same protocol value. Thus IPsec security, as mentioned in > "Security considerations" section of RFC2740 and ospfv3-auth draft, > cannot be provided to these packets. Perhaps this should be mentioned > in the "Security Considerations" section of ospfv3-af-alt draft. > > >Regards, > >-Roy- > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 13 10:30:40 2004 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 KAA14572 for ; Tue, 13 Jul 2004 10:30:40 -0400 (EDT) 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.00E13BDA@cherry.ease.lsoft.com>; Tue, 13 Jul 2004 10:30:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25740324 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jul 2004 10:30:39 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jul 2004 10:30:39 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRng1qFm0Tkslo7RzyrDXbIrTakBwBX+1Og Message-ID: Date: Tue, 13 Jul 2004 07:33:31 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Abhay, Hmmmm. That way you will have to work on all relevent OSPFv2 RFC's for = OSPFv3 for IPv4.(a lot of work). Things like NSSA/TE/Hitless Restart and = every new functionality to OSPFv2. Maybe if a generalized mechanism to carry OSPFv2 LSA's(I think Kireeti = pointed this out sometime) in OSPFv3 framework was there, it would be = helpful? Besides that I think a small writeup on the NSSA changes for = OSPFv3(because of changes of the NSSA RFC) would be helpful too. Things = like Nt bit, optional summary importing, setting of forwarding addresses = etc. Anybody else willing? Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Abhay Roy Sent: Monday, July 12, 2004 1:39 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas, As the draft stands today, it doesn't venture into the security mechanism(s). I guess we need to add something. My preference will be to stick with IPSec even for OSPFv3 IPv4 AF (irrespective of ipv4 or ipv6 transport). Regards, -Roy- On 07/05/04-0700 at 10:41pm, Vishwas Manral writes: > Hi Abhay, > > Good point, didnt know the draft was actually out(actually I > think Sina/Michael actually started working on it togather a > long long while back before the idea was dropped). Just curious > would we still use IPSec or would we use the current > authentication mechanism? > > To add further, we intend to add a draft to allow out of order > sequence of packets with authentication enabled like in IPSec > for OSPFv2 too. (IP does not guarentee inorder dilevery > anyway/besides we can allow for packet prioritization) > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of = Abhay > Roy > Sent: Tuesday, July 06, 2004 11:04 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > > On 07/05/04-0500 at 2:19pm, Mukesh.Gupta@NOKIA.COM writes: > > > Hi Vishwas, > > > > Thanks for the comments. Please see my comments inline.. > > > > > 1. I am not sure we should have a statement which says OSPFv3 > > > is only for IPv6. > > > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > > the distinction between the packets can be easily made by > > > IP version. " > > > > Do you have a replacement statement that you would prefer ? > > As the IP protocol type value for OSPF and OSPFv3 is same, > > we have to depend upon the IP version to separate OSPF and > > OSPFv3 packets. > > Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > will be based on OSPF protocol version. > > Regards, > -Roy- > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 13 14:07:09 2004 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 OAA29829 for ; Tue, 13 Jul 2004 14:07:09 -0400 (EDT) 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.00E1409B@cherry.ease.lsoft.com>; Tue, 13 Jul 2004 14:07:08 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25770373 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jul 2004 14:07:07 -0400 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jul 2004 14:07:06 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DI75s15084 for ; Tue, 13 Jul 2004 21:07:05 +0300 (EET DST) X-Scanned: Tue, 13 Jul 2004 21:06:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6DI6RAt026380 for ; Tue, 13 Jul 2004 21:06:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00G60oCx; Tue, 13 Jul 2004 21:06:26 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DI6Pu01339 for ; Tue, 13 Jul 2004 21:06:26 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Jul 2004 13:06:23 -0500 Received: mvebe001 172.18.140.37 from 172.19.66.99 172.19.66.99 via HTTP with MS-WebStorage 6.0.6249 Received: from mvwsipd90027 by mvebe001; 13 Jul 2004 11:06:22 -0700 References: <1089395527.853.66.camel@mvwsipd90027> Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) X-OriginalArrivalTime: 13 Jul 2004 18:06:23.0455 (UTC) FILETIME=[1B7366F0:01C46904] Message-ID: <1089741982.20287.9.camel@mvwsipd90027> Date: Tue, 13 Jul 2004 11:06:22 -0700 Reply-To: Mailing List Sender: Mailing List From: Suresh Melam Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Abhay, I've following two observations. - While "Instances" are meant to distinguish multiple instances on a single link, each interface, as mentioned in 2740, will still be assigned a single Instance ID. Any packets received with instance ID different than the one in Interface structure will be dropped by the OSPF. All our IPsec rules/SAs have interface as one of the selector. Thus these SAs will be tied uniquely to an Instance. We will make explicit mention of this point in the draft. - IPsec is meant to provide security at the IP layer and thus most of the selectors are only IP selectors. Special consideration has been given to the port numbers of well-known transport protocols like TCP/UDP and thus they are also included as selectors. The latest IPsec architecture draft (draft-ietf-ipsec-rfc2401bis-02.txt, Sec 4.4.1.1) has added few more selectors that are specific to upper layers, but still hasn't provided any option to specify arbitrary upper layer fields as IPsec selectors. As we expect the underlying IPsec implementations to be standard ones, we cannot enforce any additional requirements to the IPsec implementations. Thus I would conclude that there are no issues with supporting multiple OSPF instances on a single link, but distinguishing OSPFv2 and OSPFv3 packets running over same IPv4 family would be not a viable solution. Please see my followup mail to Vishwas mail for further discussion of this multiple AF issue. thanks, -suresh On Sun, 2004-07-11 at 13:14, ext Abhay Roy wrote: > Suresh, > > I am afraid, we need to have IPsec selector go deeper. Otherwise > we can't allow different OSPFv3 Instance ID's to use different > IPsec security associations (SAs). > > I noticed that draft-ietf-ospf-ospfv3-auth doesn't talk about > possibility of running multiple instance per link, and it's > interaction / implications with IPSec SAs. We should address that. > > Regards, > -Roy- > > On 07/09/04-0700 at 10:52am, Suresh Melam writes: > > > Hi Abhay/Vishwas, > > > > comments inline, > > > > thanks, > > -suresh (Nagavenkata Suresh Melam) > > > > > > >> Hi Vishwas, > > >> > > >> Thanks for the comments. Please see my comments inline.. > > >> > > >> > 1. I am not sure we should have a statement which says OSPFv3 > > >> > is only for IPv6. > > >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > >> > the distinction between the packets can be easily made by > > >> > IP version. " > > >> > > >> Do you have a replacement statement that you would prefer ? > > >> As the IP protocol type value for OSPF and OSPFv3 is same, > > >> we have to depend upon the IP version to separate OSPF and > > >> OSPFv3 packets. > > > > > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > > >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > > >will be based on OSPF protocol version. > > > > > > > IPsec selectors are not usually any deeper than protocol field of > > IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF > > protocol version cannot be one of the selector. > > > > If OSPFv3 runs on IPv4 transport, there wouldn't be any way > > to distinguish OSPFv3 packets from OSPFv2 packets, as both of them > > use same protocol value. Thus IPsec security, as mentioned in > > "Security considerations" section of RFC2740 and ospfv3-auth draft, > > cannot be provided to these packets. Perhaps this should be mentioned > > in the "Security Considerations" section of ospfv3-af-alt draft. > > > > >Regards, > > >-Roy- > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 13 15:05:22 2004 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 PAA04383 for ; Tue, 13 Jul 2004 15:05:21 -0400 (EDT) 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.00E14370@cherry.ease.lsoft.com>; Tue, 13 Jul 2004 15:05:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25777635 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jul 2004 15:05:10 -0400 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jul 2004 15:05:09 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DJ57b23276 for ; Tue, 13 Jul 2004 22:05:08 +0300 (EET DST) X-Scanned: Tue, 13 Jul 2004 22:04:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i6DJ4fdw013727 for ; Tue, 13 Jul 2004 22:04:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 001k3v7Z; Tue, 13 Jul 2004 22:04:39 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DJ4bn00987 for ; Tue, 13 Jul 2004 22:04:38 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Jul 2004 14:04:21 -0500 Received: mvebe001 172.18.140.37 from 172.19.66.99 172.19.66.99 via HTTP with MS-WebStorage 6.0.6249 Received: from mvwsipd90027 by mvebe001; 13 Jul 2004 12:04:19 -0700 References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) X-OriginalArrivalTime: 13 Jul 2004 19:04:21.0035 (UTC) FILETIME=[343FFFB0:01C4690C] Message-ID: <1089745459.20287.68.camel@mvwsipd90027> Date: Tue, 13 Jul 2004 12:04:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Suresh Melam Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Vishwas, comments inline, thanks, -suresh On Sat, 2004-07-10 at 01:00, Vishwas Manral wrote: > Hi Suresh, > > I was thinking the following assumptions would hold good: - > > 1. We either run OSPFv3 for IPv4 or OSPFv2 for IPv4 not both. > 2. While configuring the SA(we dont use IKE), both ends agree to the protocol they are using. > > Wouldn't it help in that case? I think the AF draft should state the limitation instead. Yes, in this case of running only one of OSPFv3 or OSPFv2 over IPv4 AF, but not both, it should be possible to use same rules as those we suggest in our draft to secure the IPv4 OSPF traffic. Only difference is that we should use equivalent IPv4 addresses for instead of IPv6 addresses. For eg., IPv6 multicast OSPF address should be replaced with IPv4 multicast OSPF address and so on. While we try to make sure that any rule in our draft will not conflict with the requirement of running OSPFv3 traffic over IPv4 traffic, we too believe that AF draft should make a clear mention of how IPsec can be used in a such a case. > > Suresh, also if the link is assumed to be point-to-point would we still restrict to the use of static configuration and not IKE. Yes, we suggest to use manual keying in all cases just to have a simple configuration. IKE might involve PKI too. If manual keying is considered secure enough for other types of links, we believe it should be secure enough for point-to-point links too. If there is any strong reason why IKE should be used over point-to-point link, the two end points are welcome to use IKE and it would be specific to only those two endpoints. > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Suresh > Melam > Sent: Friday, July 09, 2004 11:22 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt > > > Hi Abhay/Vishwas, > > comments inline, > > thanks, > -suresh (Nagavenkata Suresh Melam) > > > >> Hi Vishwas, > >> > >> Thanks for the comments. Please see my comments inline.. > >> > >> > 1. I am not sure we should have a statement which says OSPFv3 > >> > is only for IPv6. > >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > >> > the distinction between the packets can be easily made by > >> > IP version. " > >> > >> Do you have a replacement statement that you would prefer ? > >> As the IP protocol type value for OSPF and OSPFv3 is same, > >> we have to depend upon the IP version to separate OSPF and > >> OSPFv3 packets. > > > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > >will be based on OSPF protocol version. > > > > IPsec selectors are not usually any deeper than protocol field of > IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF > protocol version cannot be one of the selector. > > If OSPFv3 runs on IPv4 transport, there wouldn't be any way > to distinguish OSPFv3 packets from OSPFv2 packets, as both of them > use same protocol value. Thus IPsec security, as mentioned in > "Security considerations" section of RFC2740 and ospfv3-auth draft, > cannot be provided to these packets. Perhaps this should be mentioned > in the "Security Considerations" section of ospfv3-af-alt draft. > > >Regards, > >-Roy- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 14 15:51:02 2004 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 PAA11945 for ; Wed, 14 Jul 2004 15:51:02 -0400 (EDT) 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.00E15FA3@cherry.ease.lsoft.com>; Wed, 14 Jul 2004 15:51:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25928447 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Jul 2004 15:50:59 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 Jul 2004 15:40:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11094; Wed, 14 Jul 2004 15:40:50 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200407141940.PAA11094@ietf.org> Date: Wed, 14 Jul 2004 15:40:49 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-traffic-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 : Traffic Engineering Extensions to OSPF version 3 Author(s) : K. Ishiguro, T. Takada Filename : draft-ietf-ospf-ospfv3-traffic-02.txt Pages : 6 Date : 2004-7-14 This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-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-traffic-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-traffic-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: <2004-7-14154232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-traffic-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-14154232.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 15 16:18:24 2004 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 QAA22127 for ; Thu, 15 Jul 2004 16:18:24 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00E17C07@cherry.ease.lsoft.com>; Thu, 15 Jul 2004 16:18:23 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26110424 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Jul 2004 16:18:21 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 15 Jul 2004 16:18:21 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 238DA7A48CB; Thu, 15 Jul 2004 13:18:20 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02925-09; Thu, 15 Jul 2004 13:18:19 -0700 (PDT) Received: from redback.com (login-1-300.redback.com [155.53.12.153]) by prattle.redback.com (Postfix) with ESMTP id DA7007A48CA; Thu, 15 Jul 2004 13:18:18 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070506070705040000000406" X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <40F6E694.60605@redback.com> Date: Thu, 15 Jul 2004 16:18:28 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: San Diego OSPF WG Agenda Comments: cc: Rohit Dube To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------070506070705040000000406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Attached is our tentative agenda. We are pretty much full. There are other items we would have covered if we didn't run out of time. I'll be on vacation for about 10-11 days (starting after tomorrow) so please send any comments/queries to Rohit. Thanks, -- Acee --------------070506070705040000000406 Content-Type: text/plain; name="agenda-60th.txt" Content-Disposition: inline; filename="agenda-60th.txt" Content-Transfer-Encoding: 7bit Open Shortest Path First WG (ospf) Monday, August 2nd at 1530-1730 =============================== CHAIR(s): Rohit Dube Acee Lindem AGENDA: o Administriva 5 minutes - Mailing list: OSPF@PEACH.EASE.LSOFT.COM Subscription/Removal: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 - Scribe? - Blue Sheets o Document Status 10 minutes Rohit o OSPF Wireless Design Team/Charter Update 5 minutes Acee/Rohit o Extensions to OSPF to Support Mobile Ad Hoc Networking 20 minutes draft-chandra-ospf-manet-ext-00.txt Madhavi Chandra/Liem Nguyen o Design Considerations for a Wireless OSPF Interface 20 minutes draft-spagnolo-manet-ospf-design-00.txt Thomas Henderson/Phil Spagnolo o OSPFv3 Authentication Issues/Action 10 minutes draft-ietf-ospf-ospfv3-auth-04.txt Mukesh Gupta o OSPFv2 Multi-Topology Routing 15 minutes draft-psenak-mt-ospf-00.txt Peter Psenak o Extensions to OSPF for Advertising Optional Route 10 minutes Attributes - draft-lindem-ospf-route-attr-00.txt Acee Lindem o OSPFv3 Destination Address Filter (time permitting) 5 minutes draft-lindem-ospfv3-dest-filter-00.txt Acee Lindem o IANA Considerations for OSPF (time permitting) 5 minutes draft-kompella-ospf-iana-00.txt Kiretti Kompella --------------070506070705040000000406-- From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jul 17 03:44:42 2004 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 DAA28979 for ; Sat, 17 Jul 2004 03:44:41 -0400 (EDT) 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.00E1A47A@cherry.ease.lsoft.com>; Sat, 17 Jul 2004 3:44:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26288493 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 17 Jul 2004 03:44:37 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 17 Jul 2004 03:44:36 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcRpBJ61NaxUHkouS6WzSZHOcPzDBACzGq8w Message-ID: Date: Sat, 17 Jul 2004 00:47:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Abhay/Suresh, Would it help to have different MCast Address for OSPFv2/OSPFv3 over = IPv4? Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Suresh Melam Sent: Tuesday, July 13, 2004 11:36 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Abhay, I've following two observations. - While "Instances" are meant to distinguish multiple instances on a single link, each interface, as mentioned in 2740, will still be assigned a single Instance ID. Any packets received with instance ID different than the one in Interface structure will be dropped by the OSPF. All our IPsec rules/SAs have interface as one of the selector. Thus these SAs will be tied uniquely to an Instance. We will make explicit mention of this point in the draft. - IPsec is meant to provide security at the IP layer and thus most of the selectors are only IP selectors. Special consideration has been given to the port numbers of well-known transport protocols like TCP/UDP and thus they are also included as selectors. The latest IPsec architecture draft (draft-ietf-ipsec-rfc2401bis-02.txt, Sec 4.4.1.1) has added few more selectors that are specific to upper layers, but still hasn't provided any option to specify arbitrary upper layer fields as IPsec selectors. As we expect the underlying IPsec implementations to be standard ones, we cannot enforce any additional requirements to the IPsec implementations. Thus I would conclude that there are no issues with supporting multiple OSPF instances on a single link, but distinguishing OSPFv2 and OSPFv3 packets running over same IPv4 family would be not a viable solution. Please see my followup mail to Vishwas mail for further discussion of this multiple AF issue. thanks, -suresh On Sun, 2004-07-11 at 13:14, ext Abhay Roy wrote: > Suresh, > > I am afraid, we need to have IPsec selector go deeper. Otherwise > we can't allow different OSPFv3 Instance ID's to use different > IPsec security associations (SAs). > > I noticed that draft-ietf-ospf-ospfv3-auth doesn't talk about > possibility of running multiple instance per link, and it's > interaction / implications with IPSec SAs. We should address that. > > Regards, > -Roy- > > On 07/09/04-0700 at 10:52am, Suresh Melam writes: > > > Hi Abhay/Vishwas, > > > > comments inline, > > > > thanks, > > -suresh (Nagavenkata Suresh Melam) > > > > > > >> Hi Vishwas, > > >> > > >> Thanks for the comments. Please see my comments inline.. > > >> > > >> > 1. I am not sure we should have a statement which says OSPFv3 > > >> > is only for IPv6. > > >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > >> > the distinction between the packets can be easily made by > > >> > IP version. " > > >> > > >> Do you have a replacement statement that you would prefer ? > > >> As the IP protocol type value for OSPF and OSPFv3 is same, > > >> we have to depend upon the IP version to separate OSPF and > > >> OSPFv3 packets. > > > > > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > > >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > > >will be based on OSPF protocol version. > > > > > > > IPsec selectors are not usually any deeper than protocol field of > > IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF > > protocol version cannot be one of the selector. > > > > If OSPFv3 runs on IPv4 transport, there wouldn't be any way > > to distinguish OSPFv3 packets from OSPFv2 packets, as both of them > > use same protocol value. Thus IPsec security, as mentioned in > > "Security considerations" section of RFC2740 and ospfv3-auth draft, > > cannot be provided to these packets. Perhaps this should be = mentioned > > in the "Security Considerations" section of ospfv3-af-alt draft. > > > > >Regards, > > >-Roy- > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 19 09:33:11 2004 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 JAA15730 for ; Mon, 19 Jul 2004 09:33:11 -0400 (EDT) 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.00E1D07E@cherry.ease.lsoft.com>; Mon, 19 Jul 2004 9:33:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26601782 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Jul 2004 09:33:08 -0400 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 Jul 2004 09:23:08 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <4.004D911F@grape.ease.lsoft.com>; Mon, 19 Jul 2004 9:23:08 -0400 Message-ID: Date: Mon, 19 Jul 2004 09:23:07 -0400 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF vishnuvardhan B Subject: How to test To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I am testing the algorithm as described under appendix E of rfc 2328. It says that for assigning link-state ID's as an example consider its operation when the following sequence of events occurs in a single router (Router A). (1) Router A wants to originate an AS-external-LSA for [10.0.0.0,255.255.255.0]: (a) A Link State ID of 10.0.0.0 is used. (2) Router A then wants to originate an AS-external-LSA for [10.0.0.0,255.255.0.0]: (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a new Link State ID of 10.0.0.255. (b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.255.0.0]. (3) Router A then wants to originate an AS-external-LSA for [10.0.0.0,255.0.0.0]: (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a new Link State ID of 10.0.255.255. (b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.0.0.0]. (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID of 10.0.0.255. So can anyone help me for step 2) configuration, how do i make router-A to originate an AS-external-LSA for [10.0.0.0,255.255.0.0] From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 19 09:38:15 2004 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 JAA16120 for ; Mon, 19 Jul 2004 09:38:15 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00E1CF82@cherry.ease.lsoft.com>; Mon, 19 Jul 2004 9:38:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26602116 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Jul 2004 09:38:15 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 Jul 2004 09:28:15 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00E1CF57@cherry.ease.lsoft.com>; Mon, 19 Jul 2004 9:28:15 -0400 Message-ID: Date: Mon, 19 Jul 2004 09:28:14 -0400 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF vishnuvardhan B Subject: How to test To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I am testing the algorithm as described under appendix E of rfc 2328. It says that for assigning link-state ID's as an example consider its operation when the following sequence of events occurs in a single router (Router A). (1) Router A wants to originate an AS-external-LSA for [10.0.0.0,255.255.255.0]: (a) A Link State ID of 10.0.0.0 is used. (2) Router A then wants to originate an AS-external-LSA for [10.0.0.0,255.255.0.0]: (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a new Link State ID of 10.0.0.255. (b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.255.0.0]. (3) Router A then wants to originate an AS-external-LSA for [10.0.0.0,255.0.0.0]: (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a new Link State ID of 10.0.255.255. (b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.0.0.0]. (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID of 10.0.0.255. So can anyone help me for step 2) configuration, how do i make router-A to originate an AS-external-LSA for [10.0.0.0,255.255.0.0] Thanks in Advance vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 19 09:38:23 2004 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 JAA16140 for ; Mon, 19 Jul 2004 09:38:23 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00E1D11E@cherry.ease.lsoft.com>; Mon, 19 Jul 2004 9:38:24 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26602881 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Jul 2004 09:38:22 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 Jul 2004 09:38:22 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: How to test Thread-Index: AcRtlVmrVMP2kLylRsuCKw+EffMz3wAAQHyQ Message-ID: Date: Mon, 19 Jul 2004 06:41:28 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: How to test Comments: To: vis reddy To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Vishnu, Though I am thoroughly out of touch with OSPF, this sounds very simple. 1. First make a topology that has as an intra area route 10.0.0.0/24. = Check if all is well? 2. Now add an interface to the topology such that there is another intra = area route 10.0.0.0/16. Check again? 3. etc etc. Thanks, Vishwas -----Original Message----- From: vis reddy [mailto:badveli_vishnuus@yahoo.com] Sent: Monday, July 19, 2004 7:03 PM To: Vishwas Manral Subject: How to test I am testing the algorithm as described under appendix E of rfc 2328. It says that for assigning link-state ID's as an example consider its=20 operation when the following sequence of events occurs in a single router=20 (Router A). (1) Router A wants to originate an summary-LSA for [10.0.0.0,255.255.255.0]: (a) A Link State ID of 10.0.0.0 is used. (2) Router A then wants to originate an summary-LSA for [10.0.0.0,255.255.0.0]: (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a new Link State ID of 10.0.0.255. (b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.255.0.0]. (3) Router A then wants to originate an summary-LSA for [10.0.0.0,255.0.0.0]: (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a new Link State ID of 10.0.255.255. (b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.0.0.0]. (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID of 10.0.0.255. So can you help me for step 2) configuration, how do i make router-A to originate an summary-LSA for [10.0.0.0,255.255.0.0] Thanks in Advance vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 20 04:07:06 2004 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 EAA28565 for ; Tue, 20 Jul 2004 04:07:06 -0400 (EDT) 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.00E1E7B2@cherry.ease.lsoft.com>; Tue, 20 Jul 2004 4:07:04 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26706701 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jul 2004 04:06:30 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Jul 2004 04:06:30 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00E1E7FC@cherry.ease.lsoft.com>; Tue, 20 Jul 2004 4:06:30 -0400 Received: from 198.152.12.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Jul 2004 04:06:30 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i6K852eq010583 for ; Tue, 20 Jul 2004 04:05:02 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i6K850eq010551 for ; Tue, 20 Jul 2004 04:05:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: DR election Thread-Index: AcMZdw+FANpD3u14SdeA51AyLvz41lUuVSjA Message-ID: Date: Tue, 20 Jul 2004 11:06:26 +0300 Reply-To: Mailing List Sender: Mailing List From: "Zebaida, Dror (Dror)" Subject: Configuring OSPF or RIP on negotiated IP address? Comments: To: Mailing List To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi all, I am trying to find out whether you can configure routing protocols such = as OSPF or RIP on interfaces which are dynamically negotiated with the = command: !ip address negotiated I was looking on the Cisco site and did not find any such = configurations. Thnaks Dror From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 20 16:28:26 2004 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 QAA27556 for ; Tue, 20 Jul 2004 16:28:25 -0400 (EDT) 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.00E1F6DB@cherry.ease.lsoft.com>; Tue, 20 Jul 2004 16:28:24 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26801968 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jul 2004 16:28:22 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Jul 2004 16:18:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25262; Tue, 20 Jul 2004 16:18:20 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200407202018.QAA25262@ietf.org> Date: Tue, 20 Jul 2004 16:18:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-multi-area-adj-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 : OSPF Multi-Area Adjacency Author(s) : S. Mirtorabi, et al. Filename : draft-ietf-ospf-multi-area-adj-01.txt Pages : 7 Date : 2004-7-20 This memo documents an extension to OSPF to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path to the corresponding areas sharing the same link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-multi-area-adj-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-multi-area-adj-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-multi-area-adj-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: <2004-7-20160223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-multi-area-adj-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-multi-area-adj-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160223.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 20 19:36:41 2004 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 TAA00824 for ; Tue, 20 Jul 2004 19:36:40 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00E1FBF5@cherry.ease.lsoft.com>; Tue, 20 Jul 2004 19:36:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26809760 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jul 2004 19:36:40 -0400 Received: from 128.196.133.142 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Jul 2004 19:26:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpgate.email.arizona.edu (Postfix) with ESMTP id 5DE196F8EA8 for ; Tue, 20 Jul 2004 16:26:39 -0700 (MST) Received: from ECEVL7EH7O4DMO (DHCP-42.ece.arizona.edu [150.135.222.42]) by smtpgate.email.arizona.edu (Postfix) with SMTP id E232B6F4AFD for ; Tue, 20 Jul 2004 16:26:38 -0700 (MST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at email.arizona.edu Message-ID: Date: Tue, 20 Jul 2004 16:26:38 -0700 Reply-To: Mailing List Sender: Mailing List From: wenji Subject: Re: San Diego OSPF WG Agenda To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <40F6E694.60605@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Hi, could anybody kindly tell me how to attend the San Diego OSPF WG Meeting? can anybody join the meeting? or some kind of registration fee is needed? thanks -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Thursday, July 15, 2004 1:18 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: San Diego OSPF WG Agenda Attached is our tentative agenda. We are pretty much full. There are other items we would have covered if we didn't run out of time. I'll be on vacation for about 10-11 days (starting after tomorrow) so please send any comments/queries to Rohit. Thanks, -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 20 19:53:13 2004 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 TAA04253 for ; Tue, 20 Jul 2004 19:53:13 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00E1FC42@cherry.ease.lsoft.com>; Tue, 20 Jul 2004 19:53:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26812805 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jul 2004 19:53:09 -0400 Received: from 131.228.20.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Jul 2004 19:53:09 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KNr8x16083 for ; Wed, 21 Jul 2004 02:53:08 +0300 (EET DST) X-Scanned: Wed, 21 Jul 2004 02:52:42 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6KNqgig026558 for ; Wed, 21 Jul 2004 02:52:42 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00IPzh3I; Wed, 21 Jul 2004 02:52:40 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KNqdu14698 for ; Wed, 21 Jul 2004 02:52:39 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Jul 2004 18:52:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: San Diego OSPF WG Agenda Thread-Index: AcRusnLK6IuoIaeuTpSFgj31NOPhSwAAd6Jg X-OriginalArrivalTime: 20 Jul 2004 23:52:38.0685 (UTC) FILETIME=[A3582CD0:01C46EB4] Message-ID: <8D260779A766FB4A9C1739A476F84FA4026AB1B3@daebe009.americas.nokia.com> Date: Tue, 20 Jul 2004 18:52:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: San Diego OSPF WG Agenda To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Look at=20 http://ietf.org/meetings/IETF-60.html http://ietf.org/meetings/meetings.html > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > wenji > Sent: Tuesday, July 20, 2004 4:27 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: San Diego OSPF WG Agenda >=20 >=20 > Hi, could anybody kindly tell me how to attend the San Diego OSPF WG > Meeting? can anybody join the meeting? or some kind of=20 > registration fee is > needed? >=20 > thanks >=20 > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee > Lindem > Sent: Thursday, July 15, 2004 1:18 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: San Diego OSPF WG Agenda >=20 >=20 > Attached is our tentative agenda. We are pretty much full. > There are other items we would have covered if we didn't run out > of time. I'll be on vacation for about 10-11 days (starting > after tomorrow) so please send any comments/queries to Rohit. >=20 > Thanks, > -- > Acee >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 20 20:00:20 2004 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 UAA05695 for ; Tue, 20 Jul 2004 20:00:20 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00E1FAF0@cherry.ease.lsoft.com>; Tue, 20 Jul 2004 20:00:20 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26813090 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Jul 2004 20:00:19 -0400 Received: from 64.76.72.108 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Jul 2004 20:00:19 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------stbwgaivwdkmvflikeii" Message-ID: Date: Tue, 20 Jul 2004 19:00:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list ----------stbwgaivwdkmvflikeii Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotogalary and Music

----------stbwgaivwdkmvflikeii Content-Type: application/octet-stream; name="New_MP3_Player.scr" Content-Disposition: attachment; filename="New_MP3_Player.scr" Content-Transfer-Encoding: base64 ----------stbwgaivwdkmvflikeii-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 21 01:28:56 2004 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 BAA19362 for ; Wed, 21 Jul 2004 01:28:56 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00E2037A@cherry.ease.lsoft.com>; Wed, 21 Jul 2004 1:28:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26845477 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jul 2004 01:28:53 -0400 Received: from 61.144.161.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jul 2004 01:18:52 -0400 Received: from PRASANNACL1222 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I1600DENRKBU2@mta1.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jul 2004 13:07:25 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.5 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com References: Message-ID: <002901c46ee2$eb271d90$9904120a@in.huawei.com> Date: Wed, 21 Jul 2004 10:53:54 +0530 Reply-To: Mailing List Sender: Mailing List From: prasanna s Subject: Regarding route calculation over Vlink in case of OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Iam running OSPFv3 in the following topology vlink +++++++++++++++++++++++++++++++++++ + + RTA(e1)-------------(e1)RTB(e2)------------(e2)RTC(e3)------| 2000:cccc::1/128 area 1 area 1 area 0 in this scenario, What should be the next hop for the route 2000:cccc::1/128 in the routing table of RTA Is it link-local address of e1 of RTB or Global/site-local ipv6 address of e2 of RTC or Null Thanx and regards Prasanna Kumar A.S Software Engineer Huawei Technologies India Pvt Ltd Level-3 & 4 ,Leela Galleria, The Leela Palace,No.23 Airport Road. Bangalore-560 008 Mobile : 98803-34587 phone(0ff): 5217474/5217152 ext 701 ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** ----- Original Message ----- From: "Vishwas Manral" To: Sent: Saturday, July 17, 2004 1:17 PM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Hi Abhay/Suresh, Would it help to have different MCast Address for OSPFv2/OSPFv3 over IPv4? Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Suresh Melam Sent: Tuesday, July 13, 2004 11:36 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Abhay, I've following two observations. - While "Instances" are meant to distinguish multiple instances on a single link, each interface, as mentioned in 2740, will still be assigned a single Instance ID. Any packets received with instance ID different than the one in Interface structure will be dropped by the OSPF. All our IPsec rules/SAs have interface as one of the selector. Thus these SAs will be tied uniquely to an Instance. We will make explicit mention of this point in the draft. - IPsec is meant to provide security at the IP layer and thus most of the selectors are only IP selectors. Special consideration has been given to the port numbers of well-known transport protocols like TCP/UDP and thus they are also included as selectors. The latest IPsec architecture draft (draft-ietf-ipsec-rfc2401bis-02.txt, Sec 4.4.1.1) has added few more selectors that are specific to upper layers, but still hasn't provided any option to specify arbitrary upper layer fields as IPsec selectors. As we expect the underlying IPsec implementations to be standard ones, we cannot enforce any additional requirements to the IPsec implementations. Thus I would conclude that there are no issues with supporting multiple OSPF instances on a single link, but distinguishing OSPFv2 and OSPFv3 packets running over same IPv4 family would be not a viable solution. Please see my followup mail to Vishwas mail for further discussion of this multiple AF issue. thanks, -suresh On Sun, 2004-07-11 at 13:14, ext Abhay Roy wrote: > Suresh, > > I am afraid, we need to have IPsec selector go deeper. Otherwise > we can't allow different OSPFv3 Instance ID's to use different > IPsec security associations (SAs). > > I noticed that draft-ietf-ospf-ospfv3-auth doesn't talk about > possibility of running multiple instance per link, and it's > interaction / implications with IPSec SAs. We should address that. > > Regards, > -Roy- > > On 07/09/04-0700 at 10:52am, Suresh Melam writes: > > > Hi Abhay/Vishwas, > > > > comments inline, > > > > thanks, > > -suresh (Nagavenkata Suresh Melam) > > > > > > >> Hi Vishwas, > > >> > > >> Thanks for the comments. Please see my comments inline.. > > >> > > >> > 1. I am not sure we should have a statement which says OSPFv3 > > >> > is only for IPv6. > > >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > >> > the distinction between the packets can be easily made by > > >> > IP version. " > > >> > > >> Do you have a replacement statement that you would prefer ? > > >> As the IP protocol type value for OSPF and OSPFv3 is same, > > >> we have to depend upon the IP version to separate OSPF and > > >> OSPFv3 packets. > > > > > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > > >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > > >will be based on OSPF protocol version. > > > > > > > IPsec selectors are not usually any deeper than protocol field of > > IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF > > protocol version cannot be one of the selector. > > > > If OSPFv3 runs on IPv4 transport, there wouldn't be any way > > to distinguish OSPFv3 packets from OSPFv2 packets, as both of them > > use same protocol value. Thus IPsec security, as mentioned in > > "Security considerations" section of RFC2740 and ospfv3-auth draft, > > cannot be provided to these packets. Perhaps this should be mentioned > > in the "Security Considerations" section of ospfv3-af-alt draft. > > > > >Regards, > > >-Roy- > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 21 01:40:06 2004 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 BAA20344 for ; Wed, 21 Jul 2004 01:40:06 -0400 (EDT) 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.00E20372@cherry.ease.lsoft.com>; Wed, 21 Jul 2004 1:40:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26847158 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jul 2004 01:40:04 -0400 Received: from 61.144.161.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jul 2004 01:40:03 -0400 Received: from PRASANNACL1222 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I1600ADYSB6O3@mta0.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jul 2004 13:23:31 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_MnAYXTVzE2/BlPTdmJhSjw)" X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Message-ID: <003901c46ee3$b78254e0$9904120a@in.huawei.com> Date: Wed, 21 Jul 2004 10:59:37 +0530 Reply-To: Mailing List Sender: Mailing List From: prasanna s Subject: Regarding route calculation over Vlink in case of O To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_MnAYXTVzE2/BlPTdmJhSjw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Iam running OSPFv3 in the following topology vlink ++++++++++++++++++++++++++ + + RTA(e1)-------(e1)RTB(e2)------(e2)RTC(e3)------|2000:cccc::1/128 area 1 area 1 area 0 In this scenario, What should be the next hop for the route 2000:cccc::1/128 in the routing table of RTA Is it link-local address of e1 of RTB or Global/site-local ipv6 address of e2 of RTC or Null Thanx and regards Prasanna Kumar A.S Software Engineer Huawei Technologies India Pvt Ltd Level-3 & 4 ,Leela Galleria, The Leela Palace,No.23 Airport Road. Bangalore-560 008 Mobile : 98803-34587 phone(0ff): 5217474/5217152 ext 701 ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** --Boundary_(ID_MnAYXTVzE2/BlPTdmJhSjw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT

Iam running OSPFv3 in the following topology

               vlink
    ++++++++++++++++++++++++++
   +                                                        +
RTA(e1)-------(e1)RTB(e2)------(e2)RTC(e3)------|2000:cccc::1/128
                area 1                     area 1                  area 0

In this scenario, What should be the next hop for the route 2000:cccc::1/128
in the routing table of RTA
Is it link-local address of e1 of RTB or
Global/site-local ipv6 address of e2 of RTC or
Null

Thanx and regards

Prasanna Kumar A.S
Software Engineer
Huawei Technologies India Pvt Ltd
Level-3 & 4 ,Leela Galleria,
The Leela Palace,No.23 Airport Road.
Bangalore-560 008
Mobile : 98803-34587
phone(0ff): 5217474/5217152 ext 701

*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************

--Boundary_(ID_MnAYXTVzE2/BlPTdmJhSjw)-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 21 16:00:46 2004 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 QAA19393 for ; Wed, 21 Jul 2004 16:00:46 -0400 (EDT) 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.00E212E1@cherry.ease.lsoft.com>; Wed, 21 Jul 2004 16:00:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26962175 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jul 2004 16:00:39 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jul 2004 15:50:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18070; Wed, 21 Jul 2004 15:50:36 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200407211950.PAA18070@ietf.org> Date: Wed, 21 Jul 2004 15:50:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-te-node-addr-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 : Advertising a Router's Local Addresses in OSPF TE Extensions Author(s) : R. Aggarwal, K. Kompella Filename : draft-ietf-ospf-te-node-addr-01.txt Pages : 6 Date : 2004-7-21 This document describes procedures that enhance OSPF Traffic Engineering (TE) extensions for advertising a router's local addresses. This is needed to enable other routers in a network to compute traffic engineered MPLS LSPs to a given router's local addresses. Currently, the only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE enabled links and the local address corresponding to the Router ID. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-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-te-node-addr-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-te-node-addr-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: <2004-7-21153327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-te-node-addr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-te-node-addr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153327.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 21 20:15:06 2004 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 UAA08265 for ; Wed, 21 Jul 2004 20:15:05 -0400 (EDT) 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.00E21997@cherry.ease.lsoft.com>; Wed, 21 Jul 2004 20:15:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26983734 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jul 2004 20:15:02 -0400 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jul 2004 20:15:02 -0400 Received: (qmail 10666 invoked by uid 404); 22 Jul 2004 00:15:02 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.944488 secs); 22 Jul 2004 00:15:02 -0000 Received: from web.xebeo.com (HELO web.nj.us.utstar.com) (192.168.0.3) by lxmail.xebeo.com with SMTP; 22 Jul 2004 00:15:01 -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 UAA15366 for ; Wed, 21 Jul 2004 20:15:01 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_5742793780" Message-ID: <200407220015.UAA15366@web.nj.us.utstar.com> Date: Wed, 21 Jul 2004 20:15:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: San Diego OSPF WG Agenda To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Message from Acee Lindem of "Thu, 15 Jul 2004 16:18:28 EDT." <40F6E694.60605@redback.com> Precedence: list This is a multipart MIME message. --==_Exmh_5742793780 Content-Type: text/plain; charset=us-ascii Attached is an updated version. As you can see, we are _very_ full. --rohit. On Thu, 15 Jul 2004 16:18:28 -0400 Acee Lindem writes: =>Attached is our tentative agenda. We are pretty much full. =>There are other items we would have covered if we didn't run out =>of time. I'll be on vacation for about 10-11 days (starting =>after tomorrow) so please send any comments/queries to Rohit. => =>Thanks, =>-- =>Acee --==_Exmh_5742793780 Content-Type: text/plain ; name="agenda-60th.txt"; charset=us-ascii Content-Description: agenda-60th.txt Content-Disposition: attachment; filename="agenda-60th.txt" Open Shortest Path First WG (ospf) Monday, August 2nd at 1530-1730 =============================== CHAIR(s): Rohit Dube Acee Lindem AGENDA: o Administriva 5 minutes - Mailing list: OSPF@PEACH.EASE.LSOFT.COM Subscription/Removal: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 - Scribe? - Blue Sheets o Document Status 10 minutes Rohit o OSPF Wireless Design Team/Charter Update 5 minutes Acee/Rohit o Extensions to OSPF to Support Mobile Ad Hoc Networking 20 minutes draft-chandra-ospf-manet-ext-00.txt Russ White o Design Considerations for a Wireless OSPF Interface 20 minutes draft-spagnolo-manet-ospf-design-00.txt Thomas Henderson/Phil Spagnolo o OSPFv3 Authentication Issues/Action 10 minutes draft-ietf-ospf-ospfv3-auth-04.txt Mukesh Gupta o OSPFv2 Multi-Topology Routing 15 minutes draft-psenak-mt-ospf-00.txt Peter Psenak o Extensions to OSPF for Advertising Optional Route 10 minutes Attributes - draft-lindem-ospf-route-attr-00.txt Acee Lindem o OSPFv3 Destination Address Filter (time permitting) 5 minutes draft-lindem-ospfv3-dest-filter-00.txt Acee Lindem o IANA Considerations for OSPF (time permitting) 5 minutes draft-kompella-ospf-iana-00.txt Kiretti Kompella o OSPF MPLS Traffic Engineering Capabilities 5 minutes (time permitting) draft-vasseur-ospf-te-caps-00.txt JP Vasseur --==_Exmh_5742793780-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 22 05:27:42 2004 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 FAA03803 for ; Thu, 22 Jul 2004 05:27:42 -0400 (EDT) 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.00E221A0@cherry.ease.lsoft.com>; Thu, 22 Jul 2004 5:27:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 27025212 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 22 Jul 2004 05:27:38 -0400 Received: from 203.199.83.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 22 Jul 2004 05:27:38 -0400 Received: (qmail 32402 invoked by uid 510); 22 Jul 2004 09:27:34 -0000 Received: from unknown (128.107.253.39) by rediffmail.com via HTTP; 22 jul 2004 09:27:34 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1090488454---0-203.199.83.247-32382" Message-ID: <20040722092734.32401.qmail@mailweb34.rediffmail.com> Date: Thu, 22 Jul 2004 09:27:34 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Regarding route calculation over Vlink in case of O To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1090488454---0-203.199.83.247-32382 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AIs RTA an ABR? Your topology doesnt specifies that. Vlink should not = be operational.
=0AIn any case next hop should be RTB.
=0A
=0A-Viv= ek
=0A
=0A
=0AOn Wed, 21 Jul 2004 prasanna s wrote :
=0A>Iam= running OSPFv3 in the following topology
=0A>
=0A> = ; vlink
=0A> = ++++++++++++++++++++++++++
=0A> + &n= bsp; = = ; +
=0A> RTA(e1)-------(e1)RTB(e2)------(= e2)RTC(e3)------|2000:cccc::1/128
=0A> &nb= sp; area 1 &= nbsp; area 1 = area 0
=0A>
=0A>In this scenario, What sh= ould be the next hop for the route 2000:cccc::1/128
=0A>in the routin= g table of RTA
=0A>Is it link-local address of e1 of RTB or
=0A>= ;Global/site-local ipv6 address of e2 of RTC or
=0A>Null
=0A>=0A>Thanx and regards
=0A>
=0A>Prasanna Kumar A.S
=0A&g= t;Software Engineer
=0A>Huawei Technologies India Pvt Ltd
=0A>L= evel-3 & 4 ,Leela Galleria,
=0A>The Leela Palace,No.23 Airport Ro= ad.
=0A>Bangalore-560 008
=0A>Mobile : 98803-34587
=0A= >phone(0ff): 5217474/5217152 ext 701
=0A>
=0A>
=0A>***= **************************************************************
=0A>Th= is e-mail and its attachments contain confidential information from HUAWEI,= which is intended only for the person or entity whose address is listed ab= ove. Any use of the information contained herein in any way (including, but= not limited to, total or partial disclosure, reproduction, or disseminatio= n) by persons other than the intended recipient(s) is prohibited. If you re= ceive this mail in error, please notify the sender by phone or email immedi= ately and delete it!
=0A>********************************************= *********************
=0A>
=0A>
=0A=0A

=0A

=0A

=0A --Next_1090488454---0-203.199.83.247-32382 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Is RTA an ABR? Your topology doesnt specifies that. Vlink should not be ope= rational.=0AIn any case next hop should be RTB.=0A=0A-Vivek=0A=0A=0AOn Wed,= 21 Jul 2004 prasanna s wrote :=0A>Iam running OSPFv3 in the following topo= logy=0A>=0A> vlink=0A> ++++++++++++++++++++++++++=0A> = + +=0A> RTA(e1)--= -----(e1)RTB(e2)------(e2)RTC(e3)------|2000:cccc::1/128=0A> = area 1 area 1 area 0=0A>=0A>In this = scenario, What should be the next hop for the route 2000:cccc::1/128=0A>in = the routing table of RTA=0A>Is it link-local address of e1 of RTB or=0A>Glo= bal/site-local ipv6 address of e2 of RTC or=0A>Null=0A>=0A>Thanx and regard= s=0A>=0A>Prasanna Kumar A.S=0A>Software Engineer=0A>Huawei Technologies Ind= ia Pvt Ltd=0A>Level-3 & 4 ,Leela Galleria,=0A>The Leela Palace,No.23 Airpor= t Road.=0A>Bangalore-560 008=0A>Mobile : 98803-34587=0A>phone(0ff): 521747= 4/5217152 ext 701=0A>=0A>=0A>**********************************************= *******************=0A>This e-mail and its attachments contain confidential= information from HUAWEI, which is intended only for the person or entity w= hose address is listed above. Any use of the information contained herein i= n any way (including, but not limited to, total or partial disclosure, repr= oduction, or dissemination) by persons other than the intended recipient(s)= is prohibited. If you receive this mail in error, please notify the sender= by phone or email immediately and delete it!=0A>**************************= ***************************************=0A>=0A>=0A --Next_1090488454---0-203.199.83.247-32382-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 22 14:33:03 2004 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 OAA13173 for ; Thu, 22 Jul 2004 14:33:02 -0400 (EDT) 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.00E22E18@cherry.ease.lsoft.com>; Thu, 22 Jul 2004 14:33:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 27103306 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 22 Jul 2004 14:32:59 -0400 Received: from 65.54.185.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 22 Jul 2004 14:22:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Jul 2004 11:22:58 -0700 Received: from 202.83.166.183 by by15fd.bay15.hotmail.msn.com with HTTP; Thu, 22 Jul 2004 18:22:58 GMT X-Originating-IP: [202.83.166.183] X-Originating-Email: [shahid_optical@hotmail.com] X-Sender: shahid_optical@hotmail.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Jul 2004 18:22:58.0662 (UTC) FILETIME=[EA5BB060:01C47018] Message-ID: Date: Thu, 22 Jul 2004 23:22:58 +0500 Reply-To: Mailing List Sender: Mailing List From: shahid nawaz Subject: optimization of Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Can Any body tell me that Is there any work on the optimization opaque LSA. Like the unreserved bandwidth has 32 octet, 4 octet for reservable, 4 for maximum available bandwidth. if Anyone knows please tell me. because i have an idea of optimization of opaque LSA. thakyou very much indeed from shahid nawaz _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 23 02:21:31 2004 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 CAA19910 for ; Fri, 23 Jul 2004 02:21:30 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00E23B30@cherry.ease.lsoft.com>; Fri, 23 Jul 2004 2:21:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 27167597 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 23 Jul 2004 02:21:26 -0400 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 Jul 2004 02:21:26 -0400 Received: from homejtm01a43f8 (unverified [155.53.0.252]) by ucmmail.com (Rockliffe SMTPRA 5.3.7) with ESMTP id for ; Fri, 23 Jul 2004 02:21:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: <002a01c4707d$4fc1a450$6600a8c0@homejtm01a43f8> Date: Thu, 22 Jul 2004 23:21:32 -0700 Reply-To: Mailing List Sender: Mailing List From: Farshad Tavallaei Subject: Re: Configuring OSPF or RIP on negotiated IP address? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Dror, I am not sure if this is the best place to ask vendor specific commands when you can open a ticket or simply email cisco to help you out on their available commands in whatever version of the ios you are using. But to leave you with a little information that I found after doing a little RTFM, I found out that the command "ip address negotiated" is used on either cable modem or on async interfaces. Here is an example of cisco config with rip 2: http://www.cisco.com/en/US/tech/tk86/tk89/technologies_configuration_exa mple09186a0080094544.shtml You can also read their release notes for more information. Best of luck to you, Sean Andersen -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Zebaida, Dror (Dror) Sent: Tuesday, July 20, 2004 1:06 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Configuring OSPF or RIP on negotiated IP address? Hi all, I am trying to find out whether you can configure routing protocols such as OSPF or RIP on interfaces which are dynamically negotiated with the command: !ip address negotiated I was looking on the Cisco site and did not find any such configurations. Thnaks Dror From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 23 05:27:32 2004 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 FAA04244 for ; Fri, 23 Jul 2004 05:27:32 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00E23E10@cherry.ease.lsoft.com>; Fri, 23 Jul 2004 5:27:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 27175901 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 23 Jul 2004 05:27:28 -0400 Received: from 192.91.191.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 Jul 2004 05:17:28 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Jul 2004 10:17:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80DC285@baker.datcon.co.uk> Date: Fri, 23 Jul 2004 10:17:16 +0100 Reply-To: Mailing List Sender: Mailing List From: Alan Davey Subject: Comments on draft-ietf-ospf-ospfv3-traffic-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Authors I have some comments on draft-ietf-ospf-ospfv3-traffic-02. I have divided these into * suggested changes to the advertising of stable addresses * suggested change to the value used as the Link State ID * points requiring clarification * minor editorial points. Could you please consider these comments and let me know * in which cases you will update the draft as suggested * in which cases you can correct my understanding. Suggested Changes to the Advertising of Stable Addresses -------------------------------------------------------- The "Node Address TLV" and the "Router IPv6 Address TLV" are both defined to provide a stable IP address of the advertising router that is always reachable. I think that only one TLV to define a stable IP address is required. Furthermore, the Node Address TLV, as defined in draft-ietf-ospf-te-node-addr, does not appear to be suitable for advertising a stable address as there is no way of defining which of any included addresses are stable. I suggest the following modifications. * Only the "Router IPv6 Address TLV" is defined for advertising a stable address. * The Node Address TLV is defined as an optional TLV to provide additional local addresses of the router. * The Node Address TLV section is moved to after the Link TLV section as it is of reduced importance. _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). Points requiring Clarification ------------------------------ * Section 2. This section is entitled "Node Address TLV" but refers to draft-ietf-ospf-te-node-addr which defines a "Node Attribute TLV". Should references to "Node Address TLV" be changed to read "Node Attribute TLV"? * 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. 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." * 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. * 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? * Section 5. For clarity, the draft could provide more details on Intra-Area-TE-LSA format. That is, specify o a diagram giving the format of the standard OSPFv3 LSA header that is used o the TLV format, presumably as defined in RFC3630. * RFC3630 states that unnumbered links are not supported. Is this also the case in this draft? Minor editorial points ---------------------- * Suggest adding a "Terms" section referencing RFC2119. * Section 1, paragraph 2. Typo "applicabilty". * Section 1, paragraph 3. Typo "TLV" instead of "TLVs". * Section 2, paragraph 1. o Suggest "This satisfies the requirements of the Traffic Engineering computation". o Instead of "This satisfy requirements of Traffic Engineering computation". * Section 2, paragraph 1. o Suggest "In OSPFv3 TE, the Node Address TLV MUST be supported". o Instead of "In OSPFv3 TE, node address must be supported". * Section 3, paragraph 1. Suggest current tense instead of "will advertise". * Section 3, paragraph 2. Typo "extentions". * Section 4, paragraph 1. o Suggest "consists of a set of...". o Instead of "consists a set of...". * Section 4, sub-TLV description. 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.3, paragraph 2 and section 4.4, paragraph 2. As the preceding paragraph has, correctly, stated that link-local addresses should not be included, I suggest deleting ", and contains the link's local addresses" to avoid possible confusion. * 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 ::." * Section 4.4, paragraph 1. o Suggest "Link-local scope addresses MUST NOT be included in this sub-TLV". o Instead of "Link-local address should not be included in this sub-TLV". Please let me know if you have any questions on any of the above. 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 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 23 07:35:44 2004 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 HAA13019 for ; Fri, 23 Jul 2004 07:35:44 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00E241ED@cherry.ease.lsoft.com>; Fri, 23 Jul 2004 7:35:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 27217807 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 23 Jul 2004 07:35:39 -0400 Received: from 200.45.191.180 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 Jul 2004 07:25:38 -0400 Received: from MSG-BE-02.ti.local ([192.168.220.105]) by mail-fe-04 with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jul 2004 08:25:20 -0300 Received: from mail pickup service by MSG-BE-02.ti.local with Microsoft SMTPSVC; Fri, 23 Jul 2004 08:24:53 -0300 Received: from mail-fe-03 ([192.168.220.53]) by MSG-BE-02.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jul 2004 00:37:51 -0300 Received: from qsmtp-mx-01.arnet.com.ar ([200.45.191.164]) by mail-fe-03 with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jul 2004 20:45:37 -0300 Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by host191164.arnet.net.ar with SMTP; 21 Jul 2004 23:43:03 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnOwQ-0003li-Le; Wed, 21 Jul 2004 17:47:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnN6s-0001nC-R2 for i-d-announce@megatron.ietf.org; Wed, 21 Jul 2004 15:50:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18070; Wed, 21 Jul 2004 15:50:36 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 21 Jul 2004 23:45:37.0974 (UTC) FILETIME=[D2FE8560:01C46F7C] Message-ID: <200407211950.PAA18070@ietf.org> Date: Wed, 21 Jul 2004 15:50:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-te-node-addr-01.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM --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 : Advertising a Router's Local Addresses in OSPF TE Extensions Author(s) : R. Aggarwal, K. Kompella Filename : draft-ietf-ospf-te-node-addr-01.txt Pages : 6 Date : 2004-7-21 This document describes procedures that enhance OSPF Traffic Engineering (TE) extensions for advertising a router's local addresses. This is needed to enable other routers in a network to compute traffic engineered MPLS LSPs to a given router's local addresses. Currently, the only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE enabled links and the local address corresponding to the Router ID. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-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-te-node-addr-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-te-node-addr-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: <2004-7-21153327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-te-node-addr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-te-node-addr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153327.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 26 12:17:31 2004 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 MAA25773 for ; Mon, 26 Jul 2004 12:17:30 -0400 (EDT) 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.00E284BB@cherry.ease.lsoft.com>; Mon, 26 Jul 2004 12:17:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 27659228 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 26 Jul 2004 12:17:18 -0400 Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 26 Jul 2004 12:07:18 -0400 Received: from sdn-ap-004castocp0008.dialsprint.net ([63.187.32.8] helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Bp80P-0003C1-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 26 Jul 2004 09:07:14 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41052C2A.80901@earthlink.net> Date: Mon, 26 Jul 2004 09:07:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Comments on draft-spagnolo-manet-ospf-design-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Please consider my comments below for the draft http://www.ietf.org/internet-drafts/draft-spagnolo-manet-ospf-design-00.txt to be presented next week in San Diego. Overall, the draft presents some nice analysis, simulation results, and conclusions, and I was happy to see that ideas from my draft http://www.ietf.org/internet-drafts/draft-ogier-manet-ospf-extension-01.txt (recently updated) were considered. However, I disagree with some of the conclusions as noted below. My comments are divided into the following 5 items: 1. Simulation Model 2. Originator-based LSA or ACK supression 3. Simulation results for reliable vs. unreliable flooding 4. Reliable flooding without ACKs, using periodic DDESC packets 5. Differential Hellos and differential LSAs Items 2 and 3 are a bit long, so I first summarize them, and later provide more details in items 2a and 3a. 1. Simulation Model Although the analysis considered up to 100 nodes, the simulation results considered only 20 nodes, which is quite limited. The high mobility case (for 20 nodes) had a neighbor change rate of 0.14, or one neighbor change every 7.14 sec on average. If there are 100 nodes and thus 5 times as many neighbors, then the neighbor change rate should increase to about 0.70, or one neighbor change every 1.43 sec, so that an LSA would be generated almost every MinLSInterval (5 sec), which would trigger the "periodic update" mode (possibly with non-ackable LSAs) in any of the hybrid flooding schemes we have considered (whether or not prediction of neighbor changes is used). Thus, your results are highly dependent on your choice of number of nodes and mobility level. In addition, a larger number of nodes would result in larger Hellos, thus making differential Hellos more beneficial in a highly mobile network (in which a smaller Hello interval would be used). As indicated in your analysis (Figure 1), using 100 nodes and a 2 second Hello interval results in about 62 times as much Hello overhead as using 20 nodes and a 10 second Hello interval (when full Hellos are used). Also, the only measure you used for data packets was delivery ratio, which was about .78 in your high mobility scenario. MANET simulations often assume that link-layer failure detection is used, which typically results in a delivery ratio close to 0.99 for even faster mobility than you considered. It would be good to run simulations that assume link-layer failure detection is used, and that consider other performance measures such as delay. 2. Originator-based LSA or ACK supression (summary) Although I mentioned receiver-based ACK suppression in version 00 of my draft, I later stated that I preferred originator-based methods (described in version 01 of my draft), so I will focus on such methods. However, I will also mention that your simulation result in Figure 10, which shows increased overhead for my ACK suppression method, does not use the parameters that I would use. (I would have used a threshold parameter that suppresses ACKs only when a new LSA is originated almost every MinLSInterval - not true in your case - which should not increase overhead. However, this is not important since we both prefer originator-based methods.) Regarding originator-based methods, we seem to agree that using an option bit to indicate a non-ackable LSA can be useful and should be investigated. However, I disagree with you that using an exponential moving average (EMA) to measure the rate of LSA changes is not a good approach. The following bullet from your draft refers to this approach: "The approach adapts to the link changes passively by predicting the future LSA change based upon the LSA's history. In the MANET environment, it is difficult to predict future link changes based on the past. Looking at both fixed and exponentially weighted windows with different window sizes and weights, we could not predict when future LSAs would be created. In fact the distribution of interarrival times looked almost as if the interarrivals were exponentially distributed (modulo the MinLSInterval)." My goal was to measure the long-term or medium-term average rate of LSA changes, and to base the decision of using reliable or periodic flooding on such a measurement. (The threshold should be chosen so that periodic flooding is used only if it generates less overhead than reliable flooding.) Thus, I was interested in a quasi-static scheme based on an average rate, rather than a scheme that reacts dynamically to short-term variations in the (exponentially distributed) interarrival times. Your prediction scheme is of the latter type, which tries to do better than the quasi-static approach by making a short-term prediction of the interarrival times. Although using prediction of LSA changes can result in better performance when the LSA change rate happens to be near the threshold as in your case (so that your predicted measurement frequently crosses the threshold), using an EMA based on LSA history can also be quite effective in reducing overhead (when used by the originator to decide whether to flood LSAs periodically vs. reliably) if done properly, and could be a good choice if it is decided that using a prediction technique is too complex. Simulations could be conducted to compare these two approaches for the hybrid reliable/unreliable LSA flooding method described in item 2a below (and in my updated draft), but we need to consider a large range of scenarios, and avoid drawing conclusions based only on a few scenarios. 3. Simulation results for reliable vs. unreliable flooding (summary) Your simulation results in Figure 17 compare the overhead for reliable vs. unreliable flooding, where the reliable flooding incorporates several of the proposed optimization techniques (source-independent CDS, source LSA suppression, multicast ACKS, and retransmit timer backoff.) Your results show that, for the high mobility case, unreliable flooding generates much less overhead than reliable flooding, with no significant difference in delivery ratio. As I explain below (item 3a), a hybrid reliable/unreliable flooding method can be used that performs the same as unreliable (periodic) flooding when mobility is high, and never performs significantly worse than unreliable flooding. Also, reliable flooding (or a hybrid solution) will generate much less overhead than periodic flooding in *non-mobile* wireless networks, which is an important advantage in low-bandwidth sensor networks, for example. (Thus, the fact that unreliable flooding overhead is independent of mobility can be a *bad* thing, for non-mobile networks.) Also, I discuss below (item 3a) other possible ways to reduce overhead in reliable flooding. For example, the CDS algorithm you are using may not be the best one. I have been running simulations to compare different CDS algorithms, and may announce my results soon. Maybe you can run simulations to evaluate the algorithm that I found to be the most promising. Other people may also suggest CDS algorithms, so it would be good to compare several of them. It is known that a good CDS will not result in more transmissions of a given LSA than MPRs, i.e., a source-independent CDS will be no larger than a source-dependent CDS (based on MPRs). 4. Reliable flooding without ACKs, using periodic DDESC packets In Section 6.5 of your draft, you mentioned the methods of INRIA [12] and Ogier [5] to achieve reliable flooding without ACKs, based on periodic sequence numbers, similar to IS-IS. However, in Sections 7 and 9.2 you mentioned only [12] for adjacency forming. What I suggested in my draft is a simple application of the IS-IS method of periodic Sequence Numbers packets, which translates to *periodic* DDESC packets in OSPF that are *broadcast* to all neighbors. This method is equivalent to using LSA NACKs instead of LSA ACKs. (The NACKs would actually be the LSR packets sent in response to DDESC packets.) If a CDS is used, then only CDS nodes need to send full DDESC packets. (If MPRs are used, then each MPR only needs to include a subset of LSA headers in the DDESC packets it sends, as described in my draft.) I agree with you that [12] is a big departure from OSPF, but what I propose is less of a departure from OSPF since it does not require any new message types. (An option bit could be used to distinguish a periodic DDESC packet from a regular one.) Also, you propose using INRIA's method [12] only for external LSAs, while using ACKs or unreliable flooding for internal LSAs, the rationale being that there will be more external LSAs than internal LSAs. (Although the manet could be configured as a stub area, you do not mention this in your draft.) However, it would be nice to have a single unified solution that is as scalable for internal LSAs (for very large manets) as for external LSAs. The method of periodic DDESC packets that I propose is one possible way to achieve such a unified solution. Simulations should be conducted to compare these alternatives. 5. Differential Hellos and differential LSAs As discussed above, Hellos can generate a significant amount of overhead in dense, highly mobile networks where a relatively small Hello interval is desirable. (That is why we used differential Hellos in TBRPF.) Therefore, I think that the design should include differential Hellos. For the same reason, I think that differential LSAs should be given serious consideration, since this can also reduce overhead significantly in dense, highly mobile networks. (That is why we used differental LSAs in TBRPF.) Of course, simulations are needed to evaluate this. ---------------- I will now provide more details for items 2 and 3 above. 2a. Originator-based LSA or ACK supression (details) As I said above, using prediction of neighbor changes can be helpful, but simply using an EMA to measure the rate of neighbor changes can also be quite effective if done properly. In fact, I believe it can achieve the same reduction in overhead as using prediction (if done properly). Using prediction may help to reduce LSA latency, by allowing an LSA to be originated earlier if it is predicted that no further link change is likely to occur soon. (However, your draft concludes that LSA latency is not a problem even if unreliable, periodic flooding is used.) In the hybrid reliable/unreliable flooding method that I suggest (described in my updated draft) the originator decides when to generate periodic non-ackable LSAs (unreliable/periodic mode) vs. event-driven ackable LSAs (reliable/event-driven mode), using an EMA that estimates the probability that a link change will occur within the next MinLSInterval (which I think is the same as your LSA_WAIT_TIME, which I assume is 5 seconds). When the EMA goes above a certain threshold (say 0.9), the originator goes to unreliable mode and generates a non-ackable LSA periodically every PERIODIC_WAIT_TIME (say 10 seconds). Since the LSAs are non-ackable, no ACKs or retransmitted LSAs are sent in this case, so going to unreliable mode can only decrease overhead. The originator goes to reliable mode when the EMA goes below the threshold (possibly a different threshold for hysteresis). The last LSA sent in periodic mode must be ackable, so that subsequent LSAs need to be originated only when there is a link change. Frankly, I was assuming that PERIODIC_WAIT_TIME = MinLSInterval, since I don't think it is a good idea to increase LSA latency when link changes are frequent. If this causes too much overhead, then the period used for unreliable mode can be adjusted based on the measured overhead of originated LSAs, using an EMA. (If the main goal is to control overhead, then I don't think it helps much to use prediction.) 3a. Simulation results for reliable vs. unreliable flooding (details) In item 3 above, I claimed that a hybrid reliable/unreliable flooding method can be used that performs the same as unreliable flooding when mobility is high, and never performs significantly worse than unreliable flooding. This can be achieved using something like the hybrid method described in item 2a above, except for the DDESC and LSR overhead, which I discuss below. The key is for the originator-based method to go to reliable/event-driven mode ONLY when doing so will generate less overhead than unreliable/periodic mode. The LSR overhead was negligible in your results of Figure 17, but the DDESC overhead (which was a significant 7.81 kbps) can be reduced by using one or more of the following techniques: - Only CDS nodes need to send a full DDESC (as described in my draft). Since a CDS typically consists of less than 10% of the nodes, this could reduce DDESC overhead by 90% or more. - A DDESC packe only needs to contain headers of ACKable LSAs, and thus could be EMPTY if all LSAs are non-ackable (in unreliable mode). - If the method of sending periodic DD packets is used (similar to IS-IS, as suggested in my draft), then only CDS nodes would send periodic DDESC packets. Regards, Richard Ogier From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 26 17:54:03 2004 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 RAA12792 for ; Mon, 26 Jul 2004 17:54:03 -0400 (EDT) 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.00E28DF3@cherry.ease.lsoft.com>; Mon, 26 Jul 2004 17:54:02 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 27700460 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 26 Jul 2004 17:54:00 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 26 Jul 2004 17:54:00 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00E28E15@cherry.ease.lsoft.com>; Mon, 26 Jul 2004 17:54:00 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 26 Jul 2004 17:53:59 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 26 Jul 2004 14:58:10 +0000 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6QLruq4005262; Mon, 26 Jul 2004 14:53:57 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-1-36.cisco.com [10.86.240.36]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA03298; Mon, 26 Jul 2004 14:53:55 -0700 (PDT) X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20040726174734.05ffa730@wells.cisco.com> Date: Mon, 26 Jul 2004 17:53:53 -0400 Reply-To: Mailing List Sender: Mailing List From: Jean Philippe Vasseur Subject: Update on the ISIS TE capability draft Comments: To: ccamp@ops.ietf.org, OSPF@DISCUSS.MICROSOFT.COM, isis-wg@ietf.org Comments: cc: zinin@psg.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, A quick update on the IGP TE capability drafts. There used to be two drafts proposing several TE-related extensions: draft-vasseur-ccamp-isis-te-caps draft-vasseur-ccamp-ospf-te-caps Based on the input from our AD and WG chairs, we restructured this work and came up with three drafts: draft-vasseur-ccamp-te-router-info-00 (discussed in CCAMP) and the IGP specific (sub)TLV encoding and elements of procedure are defined in: draft-vasseur-isis-te-caps-00 (in ISIS) draft-vasseur-ospf-te-caps-00 (in OSPF) Comments are of course very welcome. JP and al. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 26 17:58:14 2004 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 RAA13153 for ; Mon, 26 Jul 2004 17:58:14 -0400 (EDT) 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.00E28D98@cherry.ease.lsoft.com>; Mon, 26 Jul 2004 17:58:15 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 27700738 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 26 Jul 2004 17:58:14 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 26 Jul 2004 17:58:14 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00E28E56@cherry.ease.lsoft.com>; Mon, 26 Jul 2004 17:58:14 -0400 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 26 Jul 2004 17:58:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 26 Jul 2004 15:01:22 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6QLw98a022867; Mon, 26 Jul 2004 14:58:11 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-1-36.cisco.com [10.86.240.36]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA10858; Mon, 26 Jul 2004 14:58:07 -0700 (PDT) X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20040726175746.033cd1b8@wells.cisco.com> Date: Mon, 26 Jul 2004 17:58:05 -0400 Reply-To: Mailing List Sender: Mailing List From: Jean Philippe Vasseur Subject: Update on the IGP TE capability drafts Comments: To: ccamp@ops.ietf.org, OSPF@DISCUSS.MICROSOFT.COM, isis-wg@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list >X-BrightmailFiltered: true >X-BrightmailFiltered: true >X-Sender: jvasseur@wells.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Mon, 26 Jul 2004 17:53:53 -0400 >Reply-To: Mailing List >Sender: Mailing List >From: Jean Philippe Vasseur >Subject: Update on the ISIS TE capability draft >Comments: To: ccamp@ops.ietf.org, OSPF@DISCUSS.MICROSOFT.COM, isis-wg@ietf.org >Comments: cc: zinin@psg.com >To: OSPF@PEACH.EASE.LSOFT.COM >X-PMX-Version: 4.6.1.107272 >X-from-outside-Cisco: 128.107.250.145 > >Hi, > >A quick update on the IGP TE capability drafts. > >There used to be two drafts proposing several TE-related extensions: > draft-vasseur-ccamp-isis-te-caps > draft-vasseur-ccamp-ospf-te-caps > >Based on the input from our AD and WG chairs, we restructured this work and >came up with three drafts: > draft-vasseur-ccamp-te-router-info-00 (discussed in CCAMP) > >and the IGP specific (sub)TLV encoding and elements of procedure are >defined in: > draft-vasseur-isis-te-caps-00 (in ISIS) > draft-vasseur-ospf-te-caps-00 (in OSPF) > >Comments are of course very welcome. > >JP and al. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 26 19:06:49 2004 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 TAA19022 for ; Mon, 26 Jul 2004 19:06:49 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00E28F8D@cherry.ease.lsoft.com>; Mon, 26 Jul 2004 19:06:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 27706566 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 26 Jul 2004 19:06:45 -0400 Received: from 62.23.212.165 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 26 Jul 2004 19:06:45 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i6QN0caI018387 for ; Tue, 27 Jul 2004 01:06:28 +0200 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/27/2004 01:06:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Message-ID: Date: Tue, 27 Jul 2004 01:01:30 +0200 Reply-To: Mailing List Sender: Mailing List From: Wim.Tavernier@ALCATEL.BE Subject: Wim TAVERNIER/BE/ALCATEL is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office from 24/07/2004 until 30/08/2004. I will respond to your message when I return. For urgent matters contact Claude Tyberghien /Wim Hendericks for technical issues and Luc Beylkens for commercial issues. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 27 22:15:18 2004 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 WAA28549 for