Hi Mav,
I am afraid you are making things more complicated than they are.
The reason you don't see the routing bit on any of the RFC's is because the routing bit is an Cisco OSPF extension..
I would not call it an extension. The routing bit is simply an internal variable that is exposed to the user. Compare these two little C-language programs:
#include
int main (void)
{
int i = 2+3;
printf ("The sum is %d\n", i);
return 0;
}
and
#include
int main(void)
{
printf ("The sum is %d\n", 2+3);
return 0;
}
Both programs do the same - they compute and print the sum of 2+3. However, the first program uses an auxiliary variable i to store the intermediate result while the second program refers to a literal value directly. You could call the variable i a proprietary extension of the basic algorithm but in fact it is just an implementation issue - an internal matter of how the algorithm has been implemented, not a proprietary extension. You have to distinguish between an extension and an implementation detail. An extension enhances the algorithm or protocol. An implementation detail does not enhance the protocol in any way, rather it is a way (one of many) of making the algorithm or protocol do its work. The same goes for the "routing bit". It is only an internal variable of Cisco's OSPF implementation and it neither extends nor modifies the OSPF working. It is only a way how to quickly declare which LSAs shall not be used when computing the routing table.
I would say - forget about the "routing bit" altogether Have you actually read and understood the thread about the routing bit I have referenced in my first reply?
Cisco implemented the routing bit to avoid Customer AS accidentally
acting as a Transit Area for networks originating in the MP-BGP
backbone..
No. I believe that Cisco implemented the "routing bit" as a part of their OSPF algorithm to flag LSAs as usable or unusable, without any regard to VPNs, DN-bit or any other application.
When dealing with a scenario like in the third example and I repeat only in the third example...
The PE routers need to change there path selection process, to do this they need to ignore the down bit...
I have troubles understanding your third scenario. Can you describe the routing loop being created in this scenario step-by-step? In any case, the PE routers need to change their path selection process by observing the DN-bit, not by ignoring it as you suggest.
The cisco router clears the routing bit marking it basically as a route that originated from the MP-BGP backbone..
No. If the "routing bit" is cleared then the router indicates that for the shortest-path algorithm in OSPF, the LSA shall be ignored as if it was not even present in the LSDB.
Well, when the PE routers calculate there LSDB it's considered as best,
but because the routing bit was cleared it's NOT inserted into the
Official RIB table..
No. An LSA with "routing bit" cleared is considered unusable for shortest-path calculation so it will be skipped as if it was not even present in the LSDB.
the routing bit is not included in the LSA update to other routers in the area, it's locally significant...
Once
another PE router attached to the same area receives the LSA update it
notices that for that particular network the routing bit was cleared
You are actually contradicting yourself here. How can another PE notice that the "routing bit" was cleared when this bit is locally significant and not transmitted anywhere as you have yourself stated?
I say - calm down and try to reevaluate this entire principle once again but totally forget about the so-called "routing bit". The bit is not relevant to the MPLS VPN issue or any other issue in OSPF. In any moment, the notion of the "routing bit" can be fully replaced by a set of checks
- whether the originator of a particular LSA is topologically reachable
- whether the LSA contents are sane
- whether it is allowed to use the LSA in shortest path calculations for a particular purpose
I cannot stress this enough - the "routing bit" is obviously confusing you terribly. Forget about it - it does not make any difference to the operation of OSPF in PE/CE environment whatsoever.
Best regards,
Peter
