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

[Shishio Tsuchiya <[e-mail]>]

Alvaro
(2012/07/15 0:17), Retana, Alvaro wrote:
> 6138 points to 5443, which points to 3137
> 
> Any now 3137bis, which would be referenced by 3137 (as its successor) would point to 6138 and 5443...   I'm no expert, but isn't that a loop? ;-)
> 
> Seriously, I think all this pointing around is overkill.
> 
> Are you trying to propose that we write an applicability section?  I'm afraid that whatever we specifically (i.e. with references) mention will not be complete because potentially other applications may come up.  The "Motivation" section (which I pasted below) already mentions some of the use cases (at a high level).   For example, the LDP sync application fits under graceful introduction, as well as waiting for BGP.
> 
> If you have specific text you want to suggest adding to the motivation (that doesn't make the new RFC become outdated faster), then we would be very glad to consider it.

Yes,I agree that it should not be redundant.
If one sentence adds to the Solution section which describes maximum link metric,how is it?


2.  Solution
2.1.  Maximum Link Metric
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].

The solution is already well-using with other protocol, such as  "wait for BGP startup", "LDP-Sync [RFC6138] [RFC5443]".

or

The solution is already implemented in a lot of vendors, it also works together with other protocols, such as "wait for BGP startup", "LDP-Sync [RFC6138] [RFC5443]".


2.2 R-bit (or OSPFv3 only solution)
....


Regards,
-Shishio


> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> 1. Motivation
> 
> 
>     In some situations, it may be advantageous to inform routers in a
>     network not to use a specific router as a transit point, but still
>     route to it.  Possible situations include the following:
> 
>     o  The router is in a critical condition (for example, has very high
>        CPU load or does not have enough memory to store all LSAs or build
>        the routing table).
> 
>     o  Graceful introduction and removal of the router to/from the
>        network.
> 
>     o  Other (administrative or traffic engineering) reasons.
> 
>     Note that the proposed solution does not remove the router from the
>     topology view of the network (as could be done by just flushing that
>     router's router-LSA), but prevents other routers from using it for
>     transit routing, while still routing packets to the router's own IP
>     addresses, i.e., the router is announced as a stub.
> 
>     It must be emphasized that the proposed solution provides real
>     benefits in networks designed with at least some level of redundancy
>     so that traffic can be routed around the stub router.  Otherwise,
>     traffic destined for the networks reachable through such a stub
>     router will be still routed through it.
> 
> 
> .
>