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

["Abhay D.S" <[e-mail]>]

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



Acee Lindem wrote:
> Hi Abhay,
>
> Abhay D.S wrote:
>>
>> 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
> 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
>>  
>>
>>
>>  
>>  
>>  
>>    
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/ospf
>>   
>
>

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