Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt

["Retana, Alvaro" <[e-mail]>]

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; [e-mail]
> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt
> 
> > -----Original Message-----
> > From: Acee Lindem [mailto:[e-mail]]
> > 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.