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

[Acee Lindem <[e-mail]>]

Hi Alvaro, 
I agree with the scope of the changes but I wouldn't mention the V6-bit since it really doesn't satisfy the stub router requirements. Actually, the only use case I can imagine for the V6-bit is to snoop the OSPFv3 topology but not be reachable throughout the OSPFv3 routing domain. I'm not sure what the original authors envisioned but I suspect they thought it might help in supporting other address families. Anyway, If you only consider the R-bit, it both satisfies the stub router requirements and simplifies the text:

  OSPFv3 [RFC5340] introduced additional options to provide similar, if
  not better, control of the forwarding topology; the R-bit provides 
  a more granular indication of whether an OSPFv3 router should be
  used for transit traffic. 
 
  On the other hand, clearing the R-bit will consistently result
  in the router not being used for IPv6 transit traffic. 

Do you agree? Any opinions from others? 

Thanks,
Acee  

On Jul 10, 2012, at 10:48 AM, Retana, Alvaro wrote:

> 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.
>