[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OSPF] Unnumbered PtoP router LSA question.
Dave Katz wrote:
On Jan 7, 2009, at 9:25 PM, Richard Ogier wrote:
I have found this discussion interesting and educational.
The above argument is very convincing, which I guess is why nobody
is arguing against it. Based on the discussion, I think RFC 2328
should
be clarified as follows to allow some flexibility while ensuring
interoperability between different implementations (including most
existing implementations).
- Footnote [From ospf-bounces at ietf.org Wed Jan 7 22:54:49 2009
Return-Path: <ospf-bounces at ietf.org>
X-Original-To: ospf-archive at optimus.ietf.org
Delivered-To: ietfarch-ospf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 361FE3A6A7B;
Wed, 7 Jan 2009 22:54:49 -0800 (PST)
X-Original-To: ospf at core3.amsl.com
Delivered-To: ospf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CBDCB3A6A7B
for <ospf at core3.amsl.com>; Wed, 7 Jan 2009 22:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,
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 Y+RH60xGckW6 for <ospf at core3.amsl.com>;
Wed, 7 Jan 2009 22:54:46 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net
(elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66])
by core3.amsl.com (Postfix) with ESMTP id B509B3A69FB
for <ospf at ietf.org>; Wed, 7 Jan 2009 22:54:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net;
b=iYnvERn8mzK2f+8ioWm/xoDq0Q2rSQvAklyp1HyRP65g6n2D1O0JjtxI0RaLibTU;
h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [66.81.221.26]
by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67)
(envelope-from <ogier at earthlink.net>)
id 1LKomj-0003Ro-4t; Thu, 08 Jan 2009 01:54:30 -0500
Message-ID: <4965A3CD.6090005 at earthlink.net>
Date: Wed, 07 Jan 2009 22:57:17 -0800
From: Richard Ogier <ogier at earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Katz <dkatz at juniper.net>
References: <001701c9701a$73c8f460$5b5add20$ at Tjernlund@transmode.se> <BBDB23A7-EEAE-44D7-AB64-DC2B14C11117 at redback.com> <002001c9702c$f007ba40$d0172ec0$ at Tjernlund@transmode.se> <9D385273-7F28-4C06-810E-47C28822F506 at juniper.net> <002301c97031$206e0780$614a1680$ at Tjernlund@transmode.se> <5FB748DF-5570-4066-AD6B-B6C066AF9D9B at juniper.net> <002c01c97044$713b2b80$53b18280$ at Tjernlund@transmode.se> <E2B72E4C-8447-44C5-97D8-65E17491CB0D at juniper.net>
<1231337929.21348.177.camel at gentoo-jocke.transmode.se>
<49658039.1090204 at earthlink.net>
<1D5D3DA2-0CE6-47AF-AABD-2DAD113EA1D9 at juniper.net>
In-Reply-To: <1D5D3DA2-0CE6-47AF-AABD-2DAD113EA1D9 at juniper.net>
X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4781111e4c6ff0530fa7d1b82a788939e12a92243df993c2de3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 66.81.221.26
Cc: ospf at ietf.org, joakim.tjernlund at transmode.se
Subject: Re: [OSPF] Unnumbered PtoP router LSA question.
X-BeenThere: ospf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ospf>,
<mailto:ospf-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf at ietf.org>
List-Help: <mailto:ospf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>,
<mailto:ospf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ospf-bounces at ietf.org
Errors-To: ospf-bounces at ietf.org
Dave Katz wrote:
On Jan 7, 2009, at 9:25 PM, Richard Ogier wrote:
I have found this discussion interesting and educational.
The above argument is very convincing, which I guess is why nobody
is arguing against it. Based on the discussion, I think RFC 2328
should
be clarified as follows to allow some flexibility while ensuring
interoperability between different implementations (including most
existing implementations).
- Footnote [2] MUST 2] MUST be implemented, i.e., if all of the router's
interfaces
are point-to-point links, then the router's IP address MUST be
advertised
in the router-LSA as a host route.
If all the router's interfaces are *unnumbered* point-to-point
links. This is, for the most part, an uninteresting degenerate case
and doesn't apply to the broader problem here, which is who should
be advertising the source address of OSPF packets sent on *any*
unnumbered link, independent of what the other link types are.
- For unnumbered point-to-point links, a Type 3 link (stub network)
MAY be added to the router-LSA (Option 1), but is not required.
Although
adding such links may seem redundant, it has the benefit of ensuring
that
routes calculated to each router are *shortest* paths. Without
adding the
stub links, the calculated routing table will provide the shortest
path to
each network and host, but that need not result in the shortest path
to a
router that is not advertising its own IP address as a host route.
For example, the last hop of the shortest path might be via an
unnumbered
point-to-point link, but the last hop of the calculated path might be
via a numbered point-to-point link (which includes a stub link to the
destination router). Let me know if I am mistaken.
This is presumably what the dreaded Option 1 attempted to do. It
attracts traffic to the neighbor router, which will then resolve the
last hop to the unnumbered link itself via the usual mechanisms for
directly-connected neighbors. Of course, this only results in
optimal routing if *all* of the links are unnumbered (so all of the
neighbors are injecting the stub), but then footnote 2 kicks in and
saves the day in the only case that actually works optimally.
I am assuming that a stub link is always required for *numbered*
point-to-point links (as per RFC 2328), and is optional for *unnumbered*
links (my suggestion). So this allows optimal routing even if only some
of the links are unnumbered, by allowing Option 1 to be used for all
point-to-point links. (Maybe I wasn't clear about this.) My point is
that some people might think it is redundant to advertise stub links for
unnumbered links, but there is a benefit - optimal routing to all routers.
In addition, Footnote 2 is required to ensure interoperability with
routers that decide not to use Option 1 for unnumbered links. The
resulting clarification to RFC 2328 allows optimal routing to all
routers (optionally), while hopefully complying with almost all existing
implementations. Let me know if I am mistaken.
Richard
You are right that the only way to get optimal routing to the router
in the general case is for the router itself to advertise a stub.
I fail to see what's controversial about Option 1, save for the fact
that it's suboptimal and a stupid way of solving the problem (rather
than having the router owning the address advertise the route instead
of its neighbors) and for the colloquial use of "should", which I
always read as MUST in the more modern dialect. To me it is
straightforwardly and unambiguously required for unnumbered links
(just as Option 2 is required for subnetted links.) Other than
substituting MUST for "should" I don't see any question about this.
It is brain-dead six ways from Sunday (like a number of things in
OSPF) but I think we're stuck with it due to backward compatibility
issues.
Unfortunately, I doubt there is no IETF equivalent of the Federalist
Papers to try to give hints of the true intentions of the framers.
(I was there, but didn't take notes, and was more interested in ISIS
at the time anyhow.) As soon as we figure out what the 2nd Amendment
was for, we can go on to Option 1. ;-)
--Dave
_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf
be implemented, i.e., if all of the router's
interfaces
are point-to-point links, then the router's IP address MUST be
advertised
in the router-LSA as a host route.
If all the router's interfaces are *unnumbered* point-to-point
links. This is, for the most part, an uninteresting degenerate case
and doesn't apply to the broader problem here, which is who should
be advertising the source address of OSPF packets sent on *any*
unnumbered link, independent of what the other link types are.
- For unnumbered point-to-point links, a Type 3 link (stub network)
MAY be added to the router-LSA (Option 1), but is not required.
Although
adding such links may seem redundant, it has the benefit of ensuring
that
routes calculated to each router are *shortest* paths. Without
adding the
stub links, the calculated routing table will provide the shortest
path to
each network and host, but that need not result in the shortest path
to a
router that is not advertising its own IP address as a host route.
For example, the last hop of the shortest path might be via an
unnumbered
point-to-point link, but the last hop of the calculated path might be
via a numbered point-to-point link (which includes a stub link to the
destination router). Let me know if I am mistaken.
This is presumably what the dreaded Option 1 attempted to do. It
attracts traffic to the neighbor router, which will then resolve the
last hop to the unnumbered link itself via the usual mechanisms for
directly-connected neighbors. Of course, this only results in
optimal routing if *all* of the links are unnumbered (so all of the
neighbors are injecting the stub), but then footnote 2 kicks in and
saves the day in the only case that actually works optimally.
I am assuming that a stub link is always required for *numbered*
point-to-point links (as per RFC 2328), and is optional for *unnumbered*
links (my suggestion). So this allows optimal routing even if only some
of the links are unnumbered, by allowing Option 1 to be used for all
point-to-point links. (Maybe I wasn't clear about this.) My point is
that some people might think it is redundant to advertise stub links for
unnumbered links, but there is a benefit - optimal routing to all routers.
In addition, Footnote 2 is required to ensure interoperability with
routers that decide not to use Option 1 for unnumbered links. The
resulting clarification to RFC 2328 allows optimal routing to all
routers (optionally), while hopefully complying with almost all existing
implementations. Let me know if I am mistaken.
Richard
You are right that the only way to get optimal routing to the router
in the general case is for the router itself to advertise a stub.
I fail to see what's controversial about Option 1, save for the fact
that it's suboptimal and a stupid way of solving the problem (rather
than having the router owning the address advertise the route instead
of its neighbors) and for the colloquial use of "should", which I
always read as MUST in the more modern dialect. To me it is
straightforwardly and unambiguously required for unnumbered links
(just as Option 2 is required for subnetted links.) Other than
substituting MUST for "should" I don't see any question about this.
It is brain-dead six ways from Sunday (like a number of things in
OSPF) but I think we're stuck with it due to backward compatibility
issues.
Unfortunately, I doubt there is no IETF equivalent of the Federalist
Papers to try to give hints of the true intentions of the framers.
(I was there, but didn't take notes, and was more interested in ISIS
at the time anyhow.) As soon as we figure out what the 2nd Amendment
was for, we can go on to Option 1. ;-)
--Dave
_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf