Question about Stub advertisement of a PtP link RFC 2328

Date: July 22, 2009 8:40:47 PM = EDT

Cc: <ospf@ietf.org>, <Black_David@emc.com>

Subject: RE: Gen-ART review of = draft-ietf-ospf-hmac-sha-05

Ran,

This is = fine with me - about the level of requirement for

SHA-224 and SHA-384, I originally wrote:

To avoid confusion, this is a = request that the authors think
about this = topic; it is *not* a comment that the requirement
needs to be changed. If the authors believe = that the current
"SHOULD" requirements for these = two hashes are the right
approach, = that is acceptable to me.

Thinking has = clearly happened ;-), and I have no problem with

a result that that the requirement level will not be = changed

because doing so would reduce = consensus.

--David

-----Original = Message-----
From: RJ Atkinson [mailto:rja@extremenetworks.com= ]
Sent: Wednesday, July 22, 2009 5:55 PM
To: Black, David
Cc: ospf@ietf.org
Subject: Re: Gen-ART review of = draft-ietf-ospf-hmac-sha-05

All,

On 22 Jul 2009, at 11:31, = Bhatia, Manav (Manav) wrote:

Given that SHA-224 (and perhaps SHA-384) is not even = present in all
crypto libraries we could, if = others don't see a problem, move this
from a = SHOULD to a MAY.

All of the key-lengths for SHA-1 = and SHA-2 are available in
at least some = freely available crypto libraries, specifically
including both SHA-224 and SHA-384.

Commonly = used search engines can be used to find such

libraries.

Choice of which libraries, if any, to use is = obviously implementer's

Making that = change to "MAY" would reduce consensus, as compared

with retaining the current "SHOULD" text, so it is = best to keep

the current language = as-is.

In Section 3.2, it would be useful for the draft to = say that an
OSPFv2 Security Association is = not set up inband via OSPFv2, in
contrast to = an IPsec Security Association created via IKE. Among
=

Yup, sounds reasonable. We could add this too.
=

I made that edit about an hour after David's note = was originally sent.

the reasons that this should be done is that the = term "OSPFv2
Security Association" is = introduced in this draft - that term
does not = occur in RFC 2328, even though Section D.3 of RFC 2328
defines an abstraction for which "OSPFv2 Security = Association"
is an appropriate name. I recommend stating that = this term is
new to this draft.

The = mention of IP Security in the next to last paragraph of
the Security Considerations (section 4) should cite = an
informative reference, RFC 4301 would be = appropriate.

=

Yup, this can also be done.

Again, I = made that edit about an hour after David's note was

originally sent.

Cheers,

Ran = Atkinson

(who is the active document = editor for this draft)

= = --Apple-Mail-15--579718459-- From prvs=4537901f5=acee@redback.com Tue Jul 28 01:29:05 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D0E3A6D53; Tue, 28 Jul 2009 01:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G96Uwwhu173; Tue, 28 Jul 2009 01:29:04 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 60A363A677E; Tue, 28 Jul 2009 01:29:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,282,1246863600"; d="txt'?scan'208";a="3919467" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 28 Jul 2009 01:29:03 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C560AC90724; Tue, 28 Jul 2009 01:29:03 -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 01658-02; Tue, 28 Jul 2009 01:29:03 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id AF0D9C90722; Tue, 28 Jul 2009 01:29:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) To: Ross Callon , Adrian Farrel Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-2--120397666 From: Acee Lindem Date: Tue, 28 Jul 2009 04:29:01 -0400 X-Mailer: Apple Mail (2.753.1) Cc: OSPF List , iesg-secretary@ietf.org Subject: [OSPF] Advertising a Router's Local Addresses in OSPF TE Extensions - draft-ietf-ospf-te-node-addr-06.txt (Resending with IESG Secretrary Copied) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:30:15 -0000 --Apple-Mail-2--120397666 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Ross, Adrian, The OSPF WG would like to request publication of the subject standards track document. http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-06.txt I've attached the protocol write-up for the draft. Thanks, Acee --Apple-Mail-2--120397666 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name=ospf-te-node-address-proto-writeup.txt Content-Disposition: attachment; filename=ospf-te-node-address-proto-writeup.txt 1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes 2. Has the document had adequate review from both key WG members and key non-WG members? Yes - I've reviewed it myself several times. Do you have any concerns about the depth or breadth of the reviews that have been performed? No 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The draft has been around for several years and evolved to allow its applicability to ASON routing. I see no barriers to standardization. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No 7. Have the chairs verified that the document adheres to all of the ID Checklist items? idnits 2.11.11 tmp/draft-ietf-ospf-te-node-addr-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 1 warning (==), 0 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 8. Is the document split into normative and informative references? Yes Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) No 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Proposed Standard 10. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This draft extends OSPF TE to advertise addresses and prefixes without the overhead of the TE link sub-TLV or relegation to host addresses. * Working Group Summary There is no opposition to the draft and at least on CCAMP draft has it as a normative reference. * Protocol Quality The TLV and sub-TLV definitions and conventions for advertisement of IPv4 and IPv6 addresses are consistent with OSPF and OSPFv3. This encoding is both straight forward and concise. --Apple-Mail-2--120397666 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-2--120397666-- From prvs=4537901f5=acee@redback.com Tue Jul 28 01:41:07 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E873A6907 for ; Tue, 28 Jul 2009 01:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX7FRmFzEvwk for ; Tue, 28 Jul 2009 01:41:06 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 0085C3A6A75 for ; Tue, 28 Jul 2009 01:41:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,282,1246863600"; d="scan'208,217";a="3919856" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 28 Jul 2009 01:41:07 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A4DAD3ABA0C for ; Tue, 28 Jul 2009 01:41:07 -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 08374-08 for ; Tue, 28 Jul 2009 01:41:07 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 3C50D3ABA0A for ; Tue, 28 Jul 2009 01:41:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) To: OSPF List Message-Id: <0E570257-B6C9-4829-BF3C-46223359E978@redback.com> Content-Type: multipart/alternative; boundary=Apple-Mail-3--119673208 From: Acee Lindem Date: Tue, 28 Jul 2009 04:41:06 -0400 X-Mailer: Apple Mail (2.753.1) Subject: [OSPF] OSPF WG Agenda Addition X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:41:07 -0000 --Apple-Mail-3--119673208 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Lyndon Ong will present the Optical Interworking Forum (OIF) OSPF TE extension requirements for ASON. Reference draft-ietf-ccamp-gmpls- ason-routing-ospf-08.txt for more information on ASON routing and the extensions defined in CCAMP. Thanks, Acee --Apple-Mail-3--119673208 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII Lyndon Ong will present the Optical Interworking Forum (OIF) OSPF TE extension requirements for ASON. Reference draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt for more information on ASON routing and the extensions defined in CCAMP.

Thanks,

Acee

--Apple-Mail-3--119673208-- From prvs=4537901f5=acee@redback.com Tue Jul 28 02:12:00 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACCF3A6D24 for ; Tue, 28 Jul 2009 02:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4BGMkPS5Rfv for ; Tue, 28 Jul 2009 02:11:59 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 3965B3A6A75 for ; Tue, 28 Jul 2009 02:11:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,282,1246863600"; d="scan'208";a="3920615" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 28 Jul 2009 02:12:00 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DC00E477A11 for ; Tue, 28 Jul 2009 02:12:00 -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 18024-01 for ; Tue, 28 Jul 2009 02:12:00 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 7261B477A10 for ; Tue, 28 Jul 2009 02:12:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: <95684776-CCED-4474-ABC9-BE0E92E39345@redback.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: OSPF List From: Acee Lindem Date: Tue, 28 Jul 2009 05:11:59 -0400 X-Mailer: Apple Mail (2.753.1) Subject: [OSPF] Updated OSPF WG Agenda X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:12:00 -0000 http://www.ietf.org/proceedings/75/agenda/ospf.txt From JARLT@nortel.com Tue Jul 28 03:03:21 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0A13A6D27 for ; Tue, 28 Jul 2009 03:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlO7Cq-5moAx for ; Tue, 28 Jul 2009 03:03:16 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D50E23A6CC9 for ; Tue, 28 Jul 2009 03:03:15 -0700 (PDT) Received: from zharhxm0.corp.nortel.com (zharhxm0.corp.nortel.com [47.165.48.148]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6SA1Nw12513 for ; Tue, 28 Jul 2009 10:01:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0F6A.9C381DC0" Date: Tue, 28 Jul 2009 11:03:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about Stub advertisement of a PtP link RFC 2328 Thread-Index: AcoPaq5/MnrPWyJ4RPieObB89srg3A== From: "Juergen Arlt" To: Subject: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 10:03:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0F6A.9C381DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a very specific problem on an unnumbered point to point link for an IPsec tunnel. This link is associated to another IP interfaces address on the device to borrow an IP (source) address for the packets. The link itself (as being unnumbered has no IP subnet assigned). Which option of the following in "12.4.1.1. Describing point-to-point interfaces" would apply for the stub area advertisement?=20 In addition, as long as the state of the interface is "Point-to-Point" (and regardless of the neighboring router state), a Type 3 link (stub network) should be added. There are two forms that this stub link can take: Option 1 Assuming that the neighboring router's IP address is known, set the Link ID of the Type 3 link to the neighbor's IP address, the Link Data to the mask 0xffffffff (indicating a host route), and the cost to the interface's configured output cost.[15] Option 2 If a subnet has been assigned to the point-to- point link, set the Link ID of the Type 3 link to the subnet's IP address, the Link Data to the subnet's mask, and the cost to the interface's configured output cost.[16] I would read that option 2 would not apply as the link is unnumbered therefore no subnet has been assigned to that link (even though an associated address is set).=20 For my specific PtP case the neighbor address is known as the tunnel endpoint is manually configured (though not in any local network) therefore I can use this for the Stub entry.=20 Is that reading correct? What if we are talking about a virtual link?=20 Although a virtual link acts like an unnumbered point-to-point link, it does have an associated IP interface address. This address is used as the IP source in OSPF protocol packets it sends along the virtual link, and is set dynamically during the routing table build process. Is has no known neighbor router IP as it knows only the neighbor routers router-ID (not IP) and it has no subnet assigned to the virtual link (though an associated IP). How should the stub advertisement look like - which of the options apply? Regards Juergen Arlt ------------------------------------------------- Juergen Arlt Nortel GmbH Senior Network Solutions Engineer Global Network Technical Support Mittlerer Pfad 26 70499 Stuttgart Germany Tel: +49 (711) 1394361 ESN: 595 4361 Fax: +49 (711) 1394330 ------------------------------------------------- ------_=_NextPart_001_01CA0F6A.9C381DC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question about Stub advertisement of a PtP link RFC 2328

I = have a very specific problem on an unnumbered point to point = link for an IPsec tunnel. This link is associated to = another IP interfaces = address on the device to borrow an IP = (source) address for the = packets. The link itself (as being unnumbered has no IP subnet = assigned).

Which option of the following = in “12.4.1.1. Describing point-to-point = interfaces” would apply for the stub area = advertisement?

= In addition, as long = as the state of the interface

&n= bsp; is = "Point-to-Point" (and regardless of the

&n= bsp; neighboring router = state), a Type 3 link (stub

&n= bsp; network) should be added. = There are two forms that

&n= bsp; this stub link can = take:

&n= bsp; Option = 1

&n= bsp; = Assuming that the neighboring router's IP

&n= bsp; = address is known, set the Link ID of the Type 3

&n= bsp; = link to the neighbor's IP address, the Link Data

&n= bsp; = to the mask 0xffffffff (indicating a host

&n= bsp; = route), and the cost to the interface's

&n= bsp; = configured output cost.[15]

&n= bsp; Option = 2

&n= bsp; = If a subnet has been assigned to the point-to-

&n= bsp; = point link, set the Link ID of the Type 3 link

&n= bsp; = to the subnet's IP address, the Link Data to the

&n= bsp; = subnet's mask, and the cost to the interface's

&n= bsp; = configured output cost.[16]

I = would read that option 2 would not apply as the link is unnumbered = therefore no subnet has been assigned to that link (even though an = associated address is set). =

For my specific PtP case the neighbor address = is known as the tunnel endpoint is manually = configured (though not in any local = network) therefore I can use this for the Stub entry. =

Is = that reading correct?

What if we are talking about a virtual link?

Although a virtual = link acts like an

unnumbered = point-to-point link, it does have an associated IP

interface address. = This address is used as the IP source in

OSPF protocol packets it = sends along the virtual link, and is

set dynamically during = the routing table build process.

Is = has no known neighbor router IP as it knows only the neighbor routers = router-ID (not IP) and it has no subnet assigned to the virtual = link (though an associated IP). How should the stub advertisement look = like - which of the options apply?

Regards

Juergen Arlt

-------------------------------------------------

Juergen = Arlt

Nortel = GmbH

Senior = Network Solutions Engineer

Global = Network Technical Support

Mittlerer Pfad 26

70499 = Stuttgart

Germany

Tel: +49 = (711) 1394361

ESN: 595 4361

Fax: +49 = (711) 1394330

-------------------------------------------------

------_=_NextPart_001_01CA0F6A.9C381DC0-- From joakim.tjernlund@transmode.se Tue Jul 28 03:15:13 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DD73A69D5 for ; Tue, 28 Jul 2009 03:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4uh7mKgA9uj for ; Tue, 28 Jul 2009 03:15:12 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 1BF0B3A6CB7 for ; Tue, 28 Jul 2009 03:15:12 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id B5F2A650001; Tue, 28 Jul 2009 12:14:36 +0200 (CEST) In-Reply-To: References: X-KeepSent: 53796D24:FE2287D0-C1257601:0037B9DB; type=4; name=$KeepSent To: "Juergen Arlt" X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 28 Jul 2009 12:15:10 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-07-28 12:15:11 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Cc: ospf@ietf.org Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 10:15:13 -0000 > > I have a very specific problem on an unnumbered point to point link for an > IPsec tunnel. This link is associated to another IP interfaces address on the > device to borrow an IP (source) address for the packets. The link itself (as > being unnumbered has no IP subnet assigned). > Which option of the following in “12.4.1.1. Describing point-to-point > interfaces” would apply for the stub area advertisement? > In addition, as long as the state of the interface > is "Point-to-Point" (and regardless of the > neighboring router state), a Type 3 link (stub > network) should be added. There are two forms that > this stub link can take: > Option 1 > Assuming that the neighboring router's IP > address is known, set the Link ID of the Type 3 > link to the neighbor's IP address, the Link Data > to the mask 0xffffffff (indicating a host > route), and the cost to the interface's > configured output cost.[15] > Option 2 > If a subnet has been assigned to the point-to- > point link, set the Link ID of the Type 3 link > to the subnet's IP address, the Link Data to the > subnet's mask, and the cost to the interface's > configured output cost.[16] > I would read that option 2 would not apply as the link is unnumbered therefore > no subnet has been assigned to that link (even though an associated address is set). > For my specific PtP case the neighbor address is known as the tunnel endpoint > is manually configured (though not in any local network) therefore I can use > this for the Stub entry. > Is that reading correct? There was a discussion about this some months ago(started by me) on this subject. The short answer is that for unnumbered links you don't send Option 1 nor Option 2. The spec is a bit unclear but that is what the list concluded. > What if we are talking about a virtual link? > Although a virtual link acts like an > unnumbered point-to-point link, it does have an associated IP > interface address. This address is used as the IP source in > OSPF protocol packets it sends along the virtual link, and is > set dynamically during the routing table build process. > Is has no known neighbor router IP as it knows only the neighbor routers > router-ID (not IP) and it has no subnet assigned to the virtual link (though > an associated IP). How should the stub advertisement look like - which of the > options apply? > Regards > Juergen Arlt > ------------------------------------------------- > Juergen Arlt > Nortel GmbH > Senior Network Solutions Engineer > Global Network Technical Support > Mittlerer Pfad 26 > 70499 Stuttgart > Germany > Tel: +49 (711) 1394361 > ESN: 595 4361 > Fax: +49 (711) 1394330 > ------------------------------------------------- > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From JARLT@nortel.com Tue Jul 28 03:22:32 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FFBE3A6D9D for ; Tue, 28 Jul 2009 03:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkusYX0-g1rU for ; Tue, 28 Jul 2009 03:22:31 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2E1073A6D86 for ; Tue, 28 Jul 2009 03:22:31 -0700 (PDT) Received: from zharhxm0.corp.nortel.com (zharhxm0.corp.nortel.com [47.165.48.148]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6SAMOs14699; Tue, 28 Jul 2009 10:22:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jul 2009 11:22:44 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 Thread-Index: AcoPbE2pD6rOe9zDTq6eyeR+7o+AugAAI+mQ References:

From: "Juergen Arlt" To: "Joakim Tjernlund" Cc: ospf@ietf.org Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 10:22:32 -0000 As I need to convince our development team - can you give me some more background on this. They are advertising currently the associated address for the link (that to me is the incorrect approach) which caused some misbehavior in the network. Thanks and regards Juergen -----Original Message----- From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]=20 Sent: Dienstag, 28. Juli 2009 12:15 To: Arlt, Juergen (GERST:476S) Cc: ospf@ietf.org Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 > > I have a very specific problem on an unnumbered point to point link for an > IPsec tunnel. This link is associated to another IP interfaces address on the > device to borrow an IP (source) address for the packets. The link itself (as > being unnumbered has no IP subnet assigned). > Which option of the following in "12.4.1.1. Describing point-to-point > interfaces" would apply for the stub area advertisement? > In addition, as long as the state of the interface > is "Point-to-Point" (and regardless of the > neighboring router state), a Type 3 link (stub > network) should be added. There are two forms that > this stub link can take: > Option 1 > Assuming that the neighboring router's IP > address is known, set the Link ID of the Type 3 > link to the neighbor's IP address, the Link Data > to the mask 0xffffffff (indicating a host > route), and the cost to the interface's > configured output cost.[15] > Option 2 > If a subnet has been assigned to the point-to- > point link, set the Link ID of the Type 3 link > to the subnet's IP address, the Link Data to the > subnet's mask, and the cost to the interface's > configured output cost.[16] > I would read that option 2 would not apply as the link is unnumbered therefore > no subnet has been assigned to that link (even though an associated address is set). > For my specific PtP case the neighbor address is known as the tunnel endpoint > is manually configured (though not in any local network) therefore I can use > this for the Stub entry. > Is that reading correct? There was a discussion about this some months ago(started by me) on this subject. The short answer is that for unnumbered links you don't send Option 1 nor Option 2. The spec is a bit unclear but that is what the list concluded. > What if we are talking about a virtual link? > Although a virtual link acts like an > unnumbered point-to-point link, it does have an associated IP > interface address. This address is used as the IP source in > OSPF protocol packets it sends along the virtual link, and is > set dynamically during the routing table build process. > Is has no known neighbor router IP as it knows only the neighbor routers > router-ID (not IP) and it has no subnet assigned to the virtual link (though > an associated IP). How should the stub advertisement look like - which of the > options apply? > Regards > Juergen Arlt > ------------------------------------------------- > Juergen Arlt > Nortel GmbH > Senior Network Solutions Engineer > Global Network Technical Support > Mittlerer Pfad 26 > 70499 Stuttgart > Germany > Tel: +49 (711) 1394361 > ESN: 595 4361 > Fax: +49 (711) 1394330 > ------------------------------------------------- > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From joakim.tjernlund@transmode.se Tue Jul 28 03:34:56 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3F43A68B5 for ; Tue, 28 Jul 2009 03:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNsBzmTNfyJr for ; Tue, 28 Jul 2009 03:34:55 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id EC5F53A6CDA for ; Tue, 28 Jul 2009 03:34:54 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 5ED6F650001; Tue, 28 Jul 2009 12:34:15 +0200 (CEST) In-Reply-To: References:

X-KeepSent: 1CAFB686:6695737C-C1257601:0039A980; type=4; name=$KeepSent To: "Juergen Arlt" X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 28 Jul 2009 12:34:49 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-07-28 12:34:50 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 10:34:56 -0000 "Juergen Arlt" wrote on 28/07/2009 12:22:44: > > As I need to convince our development team - can you give me some more > background on this. They are advertising currently the associated > address for the link (that to me is the incorrect approach) which caused > some misbehavior in the network. > Thanks and regards > Juergen Just find the discussion in the archive. It was quite clear what to do. Acee Lindem, chair of OSPF WG, clarified this and there was no room for other interpretations. If you read the OSPF spec there are lots of hints and the previous version of the OSPF spec was very clear too. Jocke > > -----Original Message----- > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] > Sent: Dienstag, 28. Juli 2009 12:15 > To: Arlt, Juergen (GERST:476S) > Cc: ospf@ietf.org > Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC > 2328 > > > > > I have a very specific problem on an unnumbered point to point link > for an > > IPsec tunnel. This link is associated to another IP interfaces address > on the > > device to borrow an IP (source) address for the packets. The link > itself (as > > being unnumbered has no IP subnet assigned). > > Which option of the following in "12.4.1.1. Describing point-to-point > > interfaces" would apply for the stub area advertisement? > > In addition, as long as the state of the > interface > > is "Point-to-Point" (and regardless of the > > neighboring router state), a Type 3 link (stub > > network) should be added. There are two forms that > > this stub link can take: > > Option 1 > > Assuming that the neighboring router's IP > > address is known, set the Link ID of the Type > 3 > > link to the neighbor's IP address, the Link > Data > > to the mask 0xffffffff (indicating a host > > route), and the cost to the interface's > > configured output cost.[15] > > Option 2 > > If a subnet has been assigned to the point-to- > > point link, set the Link ID of the Type 3 link > > to the subnet's IP address, the Link Data to > the > > subnet's mask, and the cost to the interface's > > configured output cost.[16] > > I would read that option 2 would not apply as the link is unnumbered > therefore > > no subnet has been assigned to that link (even though an associated > address is set). > > For my specific PtP case the neighbor address is known as the tunnel > endpoint > > is manually configured (though not in any local network) therefore I > can use > > this for the Stub entry. > > Is that reading correct? > > There was a discussion about this some months ago(started by me) on this > subject. > The short answer is that for unnumbered links you don't send Option 1 > nor Option 2. The > spec is a bit unclear but that is what the list concluded. > > > What if we are talking about a virtual link? > > Although a virtual link acts like an > > unnumbered point-to-point link, it does have an associated IP > > interface address. This address is used as the IP source in > > OSPF protocol packets it sends along the virtual link, and is > > set dynamically during the routing table build process. > > Is has no known neighbor router IP as it knows only the neighbor > routers > > router-ID (not IP) and it has no subnet assigned to the virtual link > (though > > an associated IP). How should the stub advertisement look like - which > of the > > options apply? > > Regards > > Juergen Arlt > > ------------------------------------------------- > > Juergen Arlt > > Nortel GmbH > > Senior Network Solutions Engineer > > Global Network Technical Support > > Mittlerer Pfad 26 > > 70499 Stuttgart > > Germany > > Tel: +49 (711) 1394361 > > ESN: 595 4361 > > Fax: +49 (711) 1394330 > > ------------------------------------------------- > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > From prvs=4537901f5=acee@redback.com Tue Jul 28 05:50:07 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE5B3A6A3C for ; Tue, 28 Jul 2009 05:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO3YcjaTkpuL for ; Tue, 28 Jul 2009 05:50:06 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 4EF903A69AA for ; Tue, 28 Jul 2009 05:50:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,283,1246863600"; d="scan'208";a="3927392" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 28 Jul 2009 05:50:07 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id F191AC54E2D; Tue, 28 Jul 2009 05:50:07 -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 25876-07; Tue, 28 Jul 2009 05:50:07 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id DB05FC54E2C; Tue, 28 Jul 2009 05:50:06 -0700 (PDT) In-Reply-To: References:

From: "Juergen Arlt" To: "Acee Lindem" , "Joakim Tjernlund" Cc: ospf@ietf.org Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 13:09:51 -0000 I don't want to worm up the long discussion that took place in January (thanks to Joakims hint) but I still read that the option 1 should be used to advertise the remote router IP as a stub host route - though it is not required for the protocol to work. I agree however that in the LSA example of 2328 Router 3 ommited the option 1 as well. But the advertisement of the neighbor IP is clearly stated in RFC 1583 and I would read now the same in 2328. Quote "When interface addresses are assigned, they are modelled as stub links, with each router advertising a stub connection to the other router's interface address." The issue however is actually not the tunnel endpoint reachability but our developers did advertise the network of the unnumbered associated IP address as stub (which did not even have OSPF configured) along with the ptp link which led to some weird routing problems.=20 Now I am trying to convince them to correct this and want to make sure it is done correctly. So I proposed to use option 1 - as we know the tunnel endpoints IP (manual configuration) and remove the incorrect option 2 implementation. Thanks Juergen -----Original Message----- From: Acee Lindem [mailto:acee@redback.com]=20 Sent: Dienstag, 28. Juli 2009 14:50 To: Joakim Tjernlund Cc: Arlt, Juergen (GERST:476S); ospf@ietf.org Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 Hi Joakim, Juergen, That is correct, there is no stub link at all associated with an =20 unnumbered link. It sounds like you have some requirements to =20 advertise local endpoints though. If you are truly modeling the =20 tunnel as an unnumbered P2P interface, then these requirements should =20 be satisfied by advertising the endpoint interface independently as a =20 stub link. Many times this is the loopback and the endpoint for many =20 tunnels. Thanks, Acee On Jul 28, 2009, at 6:34 AM, Joakim Tjernlund wrote: > "Juergen Arlt" wrote on 28/07/2009 12:22:44: >> >> As I need to convince our development team - can you give me some =20 >> more >> background on this. They are advertising currently the associated >> address for the link (that to me is the incorrect approach) which =20 >> caused >> some misbehavior in the network. >> Thanks and regards >> Juergen > > Just find the discussion in the archive. It was quite clear what to =20 > do. > Acee Lindem, chair of OSPF WG, clarified this and there was no > room for other interpretations. If you read the OSPF spec there are > lots of hints and the previous version of the OSPF spec was very clear > too. > > Jocke > >> >> -----Original Message----- >> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] >> Sent: Dienstag, 28. Juli 2009 12:15 >> To: Arlt, Juergen (GERST:476S) >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] Question about Stub advertisement of a PtP =20 >> link RFC >> 2328 >> >>> >>> I have a very specific problem on an unnumbered point to point link >> for an >>> IPsec tunnel. This link is associated to another IP interfaces =20 >>> address >> on the >>> device to borrow an IP (source) address for the packets. The link >> itself (as >>> being unnumbered has no IP subnet assigned). >>> Which option of the following in "12.4.1.1. Describing point-to-=20 >>> point >>> interfaces" would apply for the stub area advertisement? >>> In addition, as long as the state of the >> interface >>> is "Point-to-Point" (and regardless of the >>> neighboring router state), a Type 3 link (stub >>> network) should be added. There are two forms =20 >>> that >>> this stub link can take: >>> Option 1 >>> Assuming that the neighboring router's IP >>> address is known, set the Link ID of the =20 >>> Type >> 3 >>> link to the neighbor's IP address, the Link >> Data >>> to the mask 0xffffffff (indicating a host >>> route), and the cost to the interface's >>> configured output cost.[15] >>> Option 2 >>> If a subnet has been assigned to the =20 >>> point-to- >>> point link, set the Link ID of the Type 3 =20 >>> link >>> to the subnet's IP address, the Link Data to >> the >>> subnet's mask, and the cost to the =20 >>> interface's >>> configured output cost.[16] >>> I would read that option 2 would not apply as the link is unnumbered >> therefore >>> no subnet has been assigned to that link (even though an associated >> address is set). >>> For my specific PtP case the neighbor address is known as the tunnel >> endpoint >>> is manually configured (though not in any local network) therefore I >> can use >>> this for the Stub entry. >>> Is that reading correct? >> >> There was a discussion about this some months ago(started by me) =20 >> on this >> subject. >> The short answer is that for unnumbered links you don't send Option 1 >> nor Option 2. The >> spec is a bit unclear but that is what the list concluded. >> >>> What if we are talking about a virtual link? >>> Although a virtual link acts like an >>> unnumbered point-to-point link, it does have an =20 >>> associated IP >>> interface address. This address is used as the IP source in >>> OSPF protocol packets it sends along the virtual link, =20 >>> and is >>> set dynamically during the routing table build process. >>> Is has no known neighbor router IP as it knows only the neighbor >> routers >>> router-ID (not IP) and it has no subnet assigned to the virtual link >> (though >>> an associated IP). How should the stub advertisement look like - =20 >>> which >> of the >>> options apply? >>> Regards >>> Juergen Arlt >>> ------------------------------------------------- >>> Juergen Arlt >>> Nortel GmbH >>> Senior Network Solutions Engineer >>> Global Network Technical Support >>> Mittlerer Pfad 26 >>> 70499 Stuttgart >>> Germany >>> Tel: +49 (711) 1394361 >>> ESN: 595 4361 >>> Fax: +49 (711) 1394330 >>> ------------------------------------------------- >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From joakim.tjernlund@transmode.se Tue Jul 28 08:20:42 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EE53A6AD9 for ; Tue, 28 Jul 2009 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_37=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-SB+7+CZH34 for ; Tue, 28 Jul 2009 08:20:41 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 2EB9C3A6F6F for ; Tue, 28 Jul 2009 08:20:41 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 9F189650002; Tue, 28 Jul 2009 17:20:05 +0200 (CEST) In-Reply-To: References:

X-KeepSent: 957B381E:B8F2E8C2-C1257601:00533D34; type=4; name=$KeepSent To: "Juergen Arlt" X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 28 Jul 2009 17:20:39 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-07-28 17:20:40 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:20:42 -0000 "Juergen Arlt" wrote on 28/07/2009 15:09:49: > > I don't want to worm up the long discussion that took place in January > (thanks to Joakims hint) but I still read that the option 1 should be > used to advertise the remote router IP as a stub host route - though it > is not required for the protocol to work. I agree however that in the > LSA example of 2328 Router 3 ommited the option 1 as well. > > But the advertisement of the neighbor IP is clearly stated in RFC 1583 > and I would read now the same in 2328. > > Quote "When interface addresses are assigned, they are modelled as stub > links, with each router advertising a stub connection to the other > router's interface address." Since the P2P I/F has an IP address(as I read it) and I guess an /32 mask I think you can view it as an numbered I/F and use Option 1. It does not matter that the IP address isn't unique I think. I you have many P2P links you get a significantly bigger Router LSA though so I think Acee's suggestion is better. > > The issue however is actually not the tunnel endpoint reachability but > our developers did advertise the network of the unnumbered associated IP > address as stub (which did not even have OSPF configured) along with the > ptp link which led to some weird routing problems. > > Now I am trying to convince them to correct this and want to make sure > it is done correctly. So I proposed to use option 1 - as we know the > tunnel endpoints IP (manual configuration) and remove the incorrect > option 2 implementation. > > Thanks > Juergen > > > > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com] > Sent: Dienstag, 28. Juli 2009 14:50 > To: Joakim Tjernlund > Cc: Arlt, Juergen (GERST:476S); ospf@ietf.org > Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC > 2328 > > Hi Joakim, Juergen, > > That is correct, there is no stub link at all associated with an > unnumbered link. It sounds like you have some requirements to > advertise local endpoints though. If you are truly modeling the > tunnel as an unnumbered P2P interface, then these requirements should > be satisfied by advertising the endpoint interface independently as a > stub link. Many times this is the loopback and the endpoint for many > tunnels. > > Thanks, > Acee > On Jul 28, 2009, at 6:34 AM, Joakim Tjernlund wrote: > > > "Juergen Arlt" wrote on 28/07/2009 12:22:44: > >> > >> As I need to convince our development team - can you give me some > >> more > >> background on this. They are advertising currently the associated > >> address for the link (that to me is the incorrect approach) which > >> caused > >> some misbehavior in the network. > >> Thanks and regards > >> Juergen > > > > Just find the discussion in the archive. It was quite clear what to > > do. > > Acee Lindem, chair of OSPF WG, clarified this and there was no > > room for other interpretations. If you read the OSPF spec there are > > lots of hints and the previous version of the OSPF spec was very clear > > too. > > > > Jocke > > > >> > >> -----Original Message----- > >> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] > >> Sent: Dienstag, 28. Juli 2009 12:15 > >> To: Arlt, Juergen (GERST:476S) > >> Cc: ospf@ietf.org > >> Subject: Re: [OSPF] Question about Stub advertisement of a PtP > >> link RFC > >> 2328 > >> > >>> > >>> I have a very specific problem on an unnumbered point to point link > >> for an > >>> IPsec tunnel. This link is associated to another IP interfaces > >>> address > >> on the > >>> device to borrow an IP (source) address for the packets. The link > >> itself (as > >>> being unnumbered has no IP subnet assigned). > >>> Which option of the following in "12.4.1.1. Describing point-to- > >>> point > >>> interfaces" would apply for the stub area advertisement? > >>> In addition, as long as the state of the > >> interface > >>> is "Point-to-Point" (and regardless of the > >>> neighboring router state), a Type 3 link (stub > >>> network) should be added. There are two forms > >>> that > >>> this stub link can take: > >>> Option 1 > >>> Assuming that the neighboring router's IP > >>> address is known, set the Link ID of the > >>> Type > >> 3 > >>> link to the neighbor's IP address, the Link > >> Data > >>> to the mask 0xffffffff (indicating a host > >>> route), and the cost to the interface's > >>> configured output cost.[15] > >>> Option 2 > >>> If a subnet has been assigned to the > >>> point-to- > >>> point link, set the Link ID of the Type 3 > >>> link > >>> to the subnet's IP address, the Link Data to > >> the > >>> subnet's mask, and the cost to the > >>> interface's > >>> configured output cost.[16] > >>> I would read that option 2 would not apply as the link is unnumbered > >> therefore > >>> no subnet has been assigned to that link (even though an associated > >> address is set). > >>> For my specific PtP case the neighbor address is known as the tunnel > >> endpoint > >>> is manually configured (though not in any local network) therefore I > >> can use > >>> this for the Stub entry. > >>> Is that reading correct? > >> > >> There was a discussion about this some months ago(started by me) > >> on this > >> subject. > >> The short answer is that for unnumbered links you don't send Option 1 > >> nor Option 2. The > >> spec is a bit unclear but that is what the list concluded. > >> > >>> What if we are talking about a virtual link? > >>> Although a virtual link acts like an > >>> unnumbered point-to-point link, it does have an > >>> associated IP > >>> interface address. This address is used as the IP source in > >>> OSPF protocol packets it sends along the virtual link, > >>> and is > >>> set dynamically during the routing table build process. > >>> Is has no known neighbor router IP as it knows only the neighbor > >> routers > >>> router-ID (not IP) and it has no subnet assigned to the virtual link > >> (though > >>> an associated IP). How should the stub advertisement look like - > >>> which > >> of the > >>> options apply? > >>> Regards > >>> Juergen Arlt > >>> ------------------------------------------------- > >>> Juergen Arlt > >>> Nortel GmbH > >>> Senior Network Solutions Engineer > >>> Global Network Technical Support > >>> Mittlerer Pfad 26 > >>> 70499 Stuttgart > >>> Germany > >>> Tel: +49 (711) 1394361 > >>> ESN: 595 4361 > >>> Fax: +49 (711) 1394330 > >>> ------------------------------------------------- > >>> _______________________________________________ > >>> OSPF mailing list > >>> OSPF@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ospf > >> > >> > >> > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > From joakim.tjernlund@transmode.se Tue Jul 28 10:18:54 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6013A67FF for ; Tue, 28 Jul 2009 10:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4GikAQwY326 for ; Tue, 28 Jul 2009 10:18:53 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 31A153A6D80 for ; Tue, 28 Jul 2009 10:18:43 -0700 (PDT) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 5FDB465000A; Tue, 28 Jul 2009 19:16:17 +0200 (CEST) In-Reply-To: References:

X-KeepSent: 295BED83:5999A671-C1257601:005E8327; type=4; name=$KeepSent To: "Juergen Arlt" X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Joakim Tjernlund Date: Tue, 28 Jul 2009 19:16:52 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF407|May 07, 2009) at 2009-07-28 19:16:52 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: ospf@ietf.org Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 17:18:54 -0000 "Juergen Arlt" wrote on 28/07/2009 15:09:49: > > I don't want to worm up the long discussion that took place in January > (thanks to Joakims hint) but I still read that the option 1 should be > used to advertise the remote router IP as a stub host route - though it > is not required for the protocol to work. I agree however that in the > LSA example of 2328 Router 3 ommited the option 1 as well. > > But the advertisement of the neighbor IP is clearly stated in RFC 1583 > and I would read now the same in 2328. > > Quote "When interface addresses are assigned, they are modelled as stub > links, with each router advertising a stub connection to the other > router's interface address." BTW, I read "interface addresses are assigned" == numbered so this para does not apply to unnumbered I/F's Jocke From prvs=45427c54b=acee@redback.com Wed Jul 29 01:28:52 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C96C3A6A73 for ; Wed, 29 Jul 2009 01:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmOSadHVwk2A for ; Wed, 29 Jul 2009 01:28:51 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 591213A6BBB for ; Wed, 29 Jul 2009 01:28:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,288,1246863600"; d="scan'208";a="3966840" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 29 Jul 2009 01:28:41 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 314935363E6; Wed, 29 Jul 2009 01:28:41 -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 12814-09; Wed, 29 Jul 2009 01:28:41 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 1858A5363E7; Wed, 29 Jul 2009 01:28:39 -0700 (PDT) In-Reply-To: References:

Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Wed, 29 Jul 2009 04:28:38 -0400 To: Juergen Arlt X-Mailer: Apple Mail (2.753.1) Cc: ospf@ietf.org, Joakim Tjernlund Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:30:54 -0000 Hi Juergen, I agree that in this situation you should not advertise the subnet of the outgoing link for the IPsec tunnel. If you advertise the tunnel endpoint as per option 1, you are not modeling the link as an unnumbered link. The OSPF specification does not specify how to model the tunnel - this is up to your implementation. Acee On Jul 28, 2009, at 9:09 AM, Juergen Arlt wrote: > I don't want to worm up the long discussion that took place in January > (thanks to Joakims hint) but I still read that the option 1 should be > used to advertise the remote router IP as a stub host route - > though it > is not required for the protocol to work. I agree however that in the > LSA example of 2328 Router 3 ommited the option 1 as well. > > But the advertisement of the neighbor IP is clearly stated in RFC 1583 > and I would read now the same in 2328. > > Quote "When interface addresses are assigned, they are modelled as > stub > links, with each router advertising a stub connection to the other > router's interface address." > > The issue however is actually not the tunnel endpoint reachability but > our developers did advertise the network of the unnumbered > associated IP > address as stub (which did not even have OSPF configured) along > with the > ptp link which led to some weird routing problems. > > Now I am trying to convince them to correct this and want to make sure > it is done correctly. So I proposed to use option 1 - as we know the > tunnel endpoints IP (manual configuration) and remove the incorrect > option 2 implementation. > > Thanks > Juergen > > > > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com] > Sent: Dienstag, 28. Juli 2009 14:50 > To: Joakim Tjernlund > Cc: Arlt, Juergen (GERST:476S); ospf@ietf.org > Subject: Re: [OSPF] Question about Stub advertisement of a PtP link > RFC > 2328 > > Hi Joakim, Juergen, > > That is correct, there is no stub link at all associated with an > unnumbered link. It sounds like you have some requirements to > advertise local endpoints though. If you are truly modeling the > tunnel as an unnumbered P2P interface, then these requirements should > be satisfied by advertising the endpoint interface independently as a > stub link. Many times this is the loopback and the endpoint for many > tunnels. > > Thanks, > Acee > On Jul 28, 2009, at 6:34 AM, Joakim Tjernlund wrote: > >> "Juergen Arlt" wrote on 28/07/2009 12:22:44: >>> >>> As I need to convince our development team - can you give me some >>> more >>> background on this. They are advertising currently the associated >>> address for the link (that to me is the incorrect approach) which >>> caused >>> some misbehavior in the network. >>> Thanks and regards >>> Juergen >> >> Just find the discussion in the archive. It was quite clear what to >> do. >> Acee Lindem, chair of OSPF WG, clarified this and there was no >> room for other interpretations. If you read the OSPF spec there are >> lots of hints and the previous version of the OSPF spec was very >> clear >> too. >> >> Jocke >> >>> >>> -----Original Message----- >>> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] >>> Sent: Dienstag, 28. Juli 2009 12:15 >>> To: Arlt, Juergen (GERST:476S) >>> Cc: ospf@ietf.org >>> Subject: Re: [OSPF] Question about Stub advertisement of a PtP >>> link RFC >>> 2328 >>> >>>> >>>> I have a very specific problem on an unnumbered point to point link >>> for an >>>> IPsec tunnel. This link is associated to another IP interfaces >>>> address >>> on the >>>> device to borrow an IP (source) address for the packets. The link >>> itself (as >>>> being unnumbered has no IP subnet assigned). >>>> Which option of the following in "12.4.1.1. Describing point-to- >>>> point >>>> interfaces" would apply for the stub area advertisement? >>>> In addition, as long as the state of the >>> interface >>>> is "Point-to-Point" (and regardless of the >>>> neighboring router state), a Type 3 link (stub >>>> network) should be added. There are two forms >>>> that >>>> this stub link can take: >>>> Option 1 >>>> Assuming that the neighboring router's IP >>>> address is known, set the Link ID of the >>>> Type >>> 3 >>>> link to the neighbor's IP address, the Link >>> Data >>>> to the mask 0xffffffff (indicating a host >>>> route), and the cost to the interface's >>>> configured output cost.[15] >>>> Option 2 >>>> If a subnet has been assigned to the >>>> point-to- >>>> point link, set the Link ID of the Type 3 >>>> link >>>> to the subnet's IP address, the Link >>>> Data to >>> the >>>> subnet's mask, and the cost to the >>>> interface's >>>> configured output cost.[16] >>>> I would read that option 2 would not apply as the link is >>>> unnumbered >>> therefore >>>> no subnet has been assigned to that link (even though an associated >>> address is set). >>>> For my specific PtP case the neighbor address is known as the >>>> tunnel >>> endpoint >>>> is manually configured (though not in any local network) >>>> therefore I >>> can use >>>> this for the Stub entry. >>>> Is that reading correct? >>> >>> There was a discussion about this some months ago(started by me) >>> on this >>> subject. >>> The short answer is that for unnumbered links you don't send >>> Option 1 >>> nor Option 2. The >>> spec is a bit unclear but that is what the list concluded. >>> >>>> What if we are talking about a virtual link? >>>> Although a virtual link acts like an >>>> unnumbered point-to-point link, it does have an >>>> associated IP >>>> interface address. This address is used as the IP >>>> source in >>>> OSPF protocol packets it sends along the virtual link, >>>> and is >>>> set dynamically during the routing table build process. >>>> Is has no known neighbor router IP as it knows only the neighbor >>> routers >>>> router-ID (not IP) and it has no subnet assigned to the virtual >>>> link >>> (though >>>> an associated IP). How should the stub advertisement look like - >>>> which >>> of the >>>> options apply? >>>> Regards >>>> Juergen Arlt >>>> ------------------------------------------------- >>>> Juergen Arlt >>>> Nortel GmbH >>>> Senior Network Solutions Engineer >>>> Global Network Technical Support >>>> Mittlerer Pfad 26 >>>> 70499 Stuttgart >>>> Germany >>>> Tel: +49 (711) 1394361 >>>> ESN: 595 4361 >>>> Fax: +49 (711) 1394330 >>>> ------------------------------------------------- >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> >>> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > From erblichs@earthlink.net Wed Jul 29 10:43:29 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A483A6D27 for ; Wed, 29 Jul 2009 10:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6V3wRW667im for ; Wed, 29 Jul 2009 10:43:28 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 74BD93A6843 for ; Wed, 29 Jul 2009 10:43:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=bOpfilzV4mD5HW7MY9n4VvtamvqKNSX/c3wRkWYLFgjk9VdXKglxdIFsDEswuETX; h=Received:Message-Id:From:To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.234.127.54] (helo=[10.0.1.4]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1MWDBa-0007xe-1z for ospf@ietf.org; Wed, 29 Jul 2009 13:43:30 -0400 Message-Id: <1FB0B0EB-0409-4A0A-8B76-62E777463D65@earthlink.net> From: Mitchell Erblich To: OSPF List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 10:43:28 -0700 X-Mailer: Apple Mail (2.935.3) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79d13e8dd4ac4f636fbcd2f3bae443b881350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.234.127.54 Subject: [OSPF] old draft : Efficient LSA Refreshment in OSPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 17:43:29 -0000 Group, I had a discussion whether this older problem and solution is still a valid problem in today's routers. My assumption is that since the time that thus draft was written that a core interface media has moved from 100Mb to 10Gb. Due to this and more efficient processors, this is no longer an issue. Secondary items that lessen this are: * when a number of IP datagrams are recieved, the systems move to a polling mode to effectively decrease the number of interrupt per packets, * grouping a larger number of LSAs together should minimize the internal fragmentation and minimize the total number of packets and reduce the byte count recieved by the size of headers, * and IP now has ECN support in addition to OSPFs acks Thus, if a byte count of the LSAs (non DNA LSAs) to be refreshed is tracked, the new and Refreshed LSAs, then the LSAs need minimal dispersion, to keep the active bit rate that will prevent rexmits and keep the cpu load below 5%. IMO, if the number of LSAs to be refreshed from one router is excessive, todays routers can process / spread out all of the LSAs within within a few secs without consuming even 5% of the interface's bandwidth.. Mitchell Erblich From prvs=456ebf9e7=acee@redback.com Fri Jul 31 13:56:31 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D87D3A6DBD for ; Fri, 31 Jul 2009 13:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ5h-FddfFVT for ; Fri, 31 Jul 2009 13:56:30 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 9335F3A6D0B for ; Fri, 31 Jul 2009 13:56:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,304,1246863600"; d="scan'208";a="4088139" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 31 Jul 2009 13:56:32 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C632B79C90B; Fri, 31 Jul 2009 13:56:32 -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 14728-04; Fri, 31 Jul 2009 13:56:32 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id 5B4D51D1612; Fri, 31 Jul 2009 13:56:32 -0700 (PDT) In-Reply-To: <1FB0B0EB-0409-4A0A-8B76-62E777463D65@earthlink.net> References: <1FB0B0EB-0409-4A0A-8B76-62E777463D65@earthlink.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Fri, 31 Jul 2009 03:06:52 -0400 To: Mitchell Erblich X-Mailer: Apple Mail (2.753.1) Cc: OSPF List Subject: Re: [OSPF] old draft : Efficient LSA Refreshment in OSPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 21:21:34 -0000 Hi Mitchell, I don't think everyone knows which problem or draft you are referring too (at least I didn't). Thanks, Acee On Jul 29, 2009, at 1:43 PM, Mitchell Erblich wrote: > > Group, > > I had a discussion whether this older problem and solution is still > a valid problem in today's routers. > > My assumption is that since the time that thus draft was written > that a core interface media has moved from 100Mb to 10Gb. Due > to this and more efficient processors, this is no longer an issue. > Secondary items that lessen this are: > > * when a number of IP datagrams are recieved, the systems > move to a polling mode to effectively decrease the number of > interrupt per packets, > > * grouping a larger number of LSAs together should minimize > the internal fragmentation and minimize the total number > of packets and reduce the byte count recieved by the size > of headers, > > * and IP now has ECN support in addition to OSPFs acks > > Thus, if a byte count of the LSAs (non DNA LSAs) to be refreshed is > tracked, the new and Refreshed LSAs, then the LSAs need minimal > dispersion, to keep the active bit rate that will prevent rexmits > and > keep the cpu load below 5%. > > IMO, if the number of LSAs to be refreshed from one router is > excessive, todays routers can process / spread out all of the > LSAs within > within a few secs without consuming even 5% of the interface's > bandwidth.. > > Mitchell Erblich > > > > > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf