Hi!
Before I publish an update I want to make sure that we're covering what you
want covered.
I pasted below the relevant sections. Note that the new sections are 3.1 and
the second paragraph in Section 5.
Thanks!
Alvaro.
...
3. Solutions
The solution introduced in this document solves two challenges
associated with the outlined problem. In the description below,
router X is the router announcing itself as a stub.
1) Making other routers prefer routes around router X while
performing the Dijkstra calculation.
2) Allowing other routers to reach IP prefixes directly connected to
router X.
Note that it would be easy to address issue 1) alone by just flushing
router X's router-LSA from the domain. However, it does not solve
problem 2), since other routers will not be able to use links to
router X in Dijkstra (no back link), and because router X will not
have links to its neighbors.
To address both problems, router X announces its router-LSA to the
neighbors with the costs of all non-stub links (links of the types
other than 3) set to MaxLinkMetric.
The solution above applies to both OSPFv2 [RFC2328] and OSPFv3
[RFC5340].
3.1. OSPFv3-only Solution
OSPFv3 [RFC5340] introduced additional options to provide similar, if
not better, control of the forwarding topology; the R-bit and the V6-
bit provide a more granular indication of whether a router is active
and/or whether it should be used specifically for IPv6 traffic,
respectively.
It is left to network operators to decide which technique to use in
their network.
4. Maximum Link Metric
...
5. Deployment Considerations
When using MaxLinkMetric, some inconsistency may be seen if the
network is constructed of routers that perform intra-area Dijkstra
calculation as specified in [RFC1247] (discarding link records in
router-LSAs that have a MaxLinkMetric cost value) and routers that
perform it as specified in [RFC1583] and higher (do not treat links
with MaxLinkMetric cost as unreachable). Note that this
inconsistency will not lead to routing loops, because if there are
some alternate paths in the network, both types of routers will agree
on using them rather than the path through the stub router. If the
path through the stub router is the only one, the routers of the
first type will not use the stub router for transit (which is the
desired behavior), while the routers of the second type will still
use this path.
On the other hand, clearing the R-bit/V6-bit will consistently result
in the router not being used as transit and/or specifically for IPv6
traffic, respectively.
> -----Original Message-----
> From: Retana, Alvaro
> Sent: Monday, July 02, 2012 12:23 PM
> To: 'Acee Lindem'
> Cc: Shishio Tsuchiya; [email protected]
> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt
>
> > -----Original Message-----
> > From: Acee Lindem [mailto:[email protected]]
> > Sent: Monday, July 02, 2012 11:29 AM
> ...
> > > Besides from the reference (see below), what else do you think we
> > should include?
> > >
> > > The point I'm trying to make is: rfc5340 already defines and
> > documents the R-bit functionality (and it is the standard!). IMHO,
> > there is no need to rehash here what is already defined and explained
> > somewhere else...which is why I think the reference is enough.
> >
> > I don't think you have to describe the mechanism. However, I agree R-
> > bit should be on equal ground as the max-metric links. Also, it would
> > be good to point out the difference in behavior. With max-metric
> links,
> > transit traffic is discouraged while with the R-bit, transit traffic
> is
> > completely suppressed.
>
> Ok, I'll work on that.
>
> Alvaro.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
