Subject: [OSPF] Extensions to OSPF for Advertising Optional Router Capabilities

From: "Abhay D.S" <[email-masked]>
Date: Thu, 09 Nov 2006 16:11:48 +0800

hi acee, and other neighbors in the AS,

   5.  Flooding Scope of the Router Information LSA

   The flooding scope for a Router Information LSA is determined by the
   LSA type.  For OSPFv2, type 9 (link-scoped), type 10 (area-scoped),
   or a type 11 (AS-scoped) opaque LSA may be flooded.  For OSPFv3, the
   S1 and S2 bits in the LSA type determine flooding scope.  If AS wide
   flooding scope is chosen, the originating router should also
   advertise area scoped LSA(s) into any attached NSSA area(s).  An OSPF
   router MAY advertise different capabilities when both NSSA area
   scoped LSA(s) and an AS scoped LSA are advertised.  This allows
   functional capabilities to be limited in scope.  For example, a
   router may be an area border router but only support traffic
   engineering (TE) in a subset of its attached areas.

   *The choice of flooding scope is made by the advertising router and is
   a matter of local policy. 

   *This specification, takes OSPFv2 to new levels of  intelligence.
   Flooding scope MAY  also be policed. Such as only a subset of 
capabilities to be
   advertised  from capability subset in each scope.

   Such as when a router becomes ASBR, ABR or just an Internal Area 
Router, GR capable
   Overloaded, busy for example (if you receive a busy bit) (add to 
capability set ?). Busy and Free
   capability  might be used by CSPF. ( You might have just edited the 
new specification for the TE Addresses
   for all OSPF interfaces). You might read the relation.

   You might want to add a section, IMPACT:   Where in you might add the 
impact
    Action: Router shall perform only those actions upon reception of 
these capability information

   Any comments ,
   - Abhay

   

  
_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Mon, 27 Nov 2006 17:10:56 -0500

Hi Abhay,

Abhay D.S wrote:
>   You might want to add a section, IMPACT:   Where in you might add 
> the impact
Since the draft defines a generic mechanism for advertising router 
capabilities and
the action an OSPF router would take is specific to a capability, I 
don't think this is
necessary. Note that all the bits in the OSPF Router Informational 
Capabilities TLV
are informational and no explicit action is necessary.

Thanks,
Acee
>
>   Any comments ,
>   - Abhay
>  
>
>
>  
>  
>  
>   
>  
> ------------------------------------------------------------------------
>

---

From: "Abhay D.S" <[email-masked]>
Date: Tue, 28 Nov 2006 09:52:59 +0800

hi acee,
Thanks .  Im curious about the ACTIONS one might take upon
receiving these BITS.

This draft's useful  since its specification lies at  the intersection 
of all OSPFv2 protocol
enhancements and possible problem solvers (which  may arise due to
_known_ software and hardware limitations ).

As it is informational there is also  some C++ here.

--Abhay