From: "Fred Baker (fred)" <fred@cisco.com>
To: David Lamparter <equinox@diac24.net>
Thread-Topic: [homenet] Egress Routing Discussion: Baker model
Thread-Index: AQHOESPgQtloSZFSukSmTv1pgutDzQ==
Date: Fri, 22 Feb 2013 17:41:43 +0000
Message-ID: <8C48B86A895913448548E6D15DA7553B79F4E1@xmb-rcd-x09.cisco.com>
References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com>
 <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com>
 <51273FE8.7050302@globis.net>
 <CAKD1Yr1qrtVKzK-oSTmDVdbjMPii3qD6DbkgHkACw5+znNqA_Q@mail.gmail.com>
 <20130222114822.GA3183407@jupiter.n2.diac24.net>
In-Reply-To: <20130222114822.GA3183407@jupiter.n2.diac24.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BC04EF78E697604591AFF9BB690A1EBF@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Ole Troan <ot@cisco.com>,
 "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>,
 "ospf@ietf.org" <ospf@ietf.org>, Ray Hunter <v6ops@globis.net>,
 "homenet@ietf.org Group" <homenet@ietf.org>,
 Lorenzo Colitti <lorenzo@google.com>
Subject: Re: [OSPF] [homenet] Egress Routing Discussion: Baker model
Precedence: list

inline=20

On Feb 23, 2013, at 12:48 AM, David Lamparter <equinox@diac24.net>
 wrote:
> For both "simple" and "full-blown" OSPFv3 the following loop/interop
> mechnisms come to my mind:
>=20
> 1. refusing adjacencies between SADR and non-SADR routers.
>   Easily implemented with a Hello bit, this is the crowbar solution.
>   Quite sufficient for homenet I guess, but probably less acceptable
>   for anything else.
>=20
> 2. flagging SADR support in router LSAs/LSPs.
>   Provides enough information to avoid loops.  Three things can be done
>   with this information:
>=20
> 2a. install null/reject routes for paths that cross non-SADR routers.
>     Provides adequate failure semantics, instead of looping packets
>     around we get an ICMP unreachable.  Easy to implement.
>     Downside: if there really is a non-SADR router, "not working" is
>     now a state that is part of the result set of the dynamic route
>     calculations.  Users (and admins) probably do not expect this.
>=20
> 2b. calculate SPF around non-SADR routers
>     Gets us a working network, but at a cost: there may now be 2
>     different paths to reach some faraway router, one for SADR-routed
>     packets and a different one for non-SADR packets.  Depending on how
>     the router performs its SPF calculations, this can be hard to
>     implement correctly - it's essentially a very narrowly and exactly
>     specified case of multitopology routing.
>=20
> 2c. on encountering non-SADR routers, figure whether they'll do the
>     right thing with the packet.
>     ... complicated and of questionable use IMHO.  Just listing this
>     for completeness.
>=20
> 2a and 2b can be mixed with each other; packets will get passed along by
> 2a-type routers until they get discarded at a 2b-type router.
>=20
> My personal opinion at this point is that 2a and 2b should both be
> specified, with a requirement to indicate support level in the router
> documentation.  We're unlikely to encounter normal OSPFv3 speakers in a
> plain "production/final" homenet, so they could take the easy way.  If
> this gets implemented on routers for enterprise use, I'd expect 2b
> behaviour.


So you want the non-SADR routers to implement a null route, and the SADR ro=
uters to route around the non-SADR routers.

I'm scratching my head on how the un-updated routers would know to install =
a null route if they don't understand the information.=20

I do think it would be straightforward to add a flag to the Hello indicatin=
g that they understand such updates, and refusing to neighbor with a router=
 that doesn't. We have done that for other features. That does mean that ad=
ding a router to an area that understands the updates forces an update to a=
ll of the routers in an area, which could be a pain when upgrading.=20

Setting a flag in the Router LSA indicating willingness to handle these rou=
tes is possible, but takes us in the direction of topological routing. My p=
roblem with approaching it as a topology is the implied management overhead=
; we need to know whether to include any given router or link in a given to=
pology, and where we might have advertised topology-specific metrics in RFC=
 4915, we now want to infer that from a capability flag. ick.=20