Re: draft-ietf-ospf-cap-04.txt

[Acee Lindem <[e-mail]>]

Hi Vivek,
See inline.

Vivek Dubey wrote:

> Hi Acee,
> Sorry for delayed response.
>
> My thoughts:
> - Save OSPF capabilities (TLV 1), other capabilities/TLV (like TLV 2
>   etc), mostly would be opaque to OSPF, i.e depending on required
>   distribution in routing domain, how they are distributed (OSPF
>   flooding scopes)is decided. Dont see why for such TLVs content be
>   affected by flooding scope.
>
In most cases they will. However, we want to allow for situations
where a capability is enabled in one area but not another.

>  
>   That is, taking TLV or sub-tlv, for a particular router,
>   it should represent consistent view across different flooding
>   scopes.
>
> 1)Router X is connected to Router A(through normal Areas - A1 and A2)
>
>   Assume there is TLV TV1 (opaque to OSPF), having bits (B1, B2)
>   representing different capabilities.
>
>   Router A capabilities flooded (based on policy/configuration):
>   Area A1 (Type 10): TV1 - Bits(1,0)
>   Area A2 (Type 10): TV1 - Bits(0,1)
>
>   Now at Router X, one will maintain some kind of centalized database
>   for advertised opaque capabilities of Router A (these should not be
>   associated with OSPF AREA as TLV itself is opaque to OSPF).
>
>   Router X database: Router A Capability: TV1 (1,1)
>
>   Dont see any benefit of having different TLV contents in different
>   areas in such cases.
>
If the function corresponding to the capability is also scoped at the 
area level,
then it makes sense to only advertise it at that level. I could add a 
sentence to
that effect.

>
> 2)Router A capabilities flooded (based on policy/configuration):
>   Area A1 (Type 10): TV1 - Bits(1,0)
>   Area A2 (Type 10): TV1 - Bits(0,1)
>
>   Router X database: Router A Capability: TV1 (1,1)
>
>   Next Area A1 adjacency is lost between Router A and Router X.
>   Resulting in flushing of RI OPQ LSA in that area.
>
LSAs aren't flushed when an adjacency goes down but it
shouldn't be used if the corresponding router is unreachable.
Eventually, it will age out.

>
>   What should than Router X database contain ???
>
>   Router X database: Router A Capability: TV1 (1,1)
>     OR
>   Router X database: Router A Capability: TV1 (0,1)
>
Router X's area A2 database will contain the latter. The capability
LSA for Router A in area A1 database is no longer applicable since
Router A is unreachable.

>
> -Vivek   
>
>
> On Sun, 19 Dec 2004 Acee Lindem wrote :
> >Hi Vivek,
> >Independent of the capabilities LSA application, I don't see why a
> >router couldn't have different capabilities in different areas dependent
> >on configuration or policy. What do you see wrong with this?
> >
> >Speaking as work group member,
> >Acee
> >
> >Vivek Dubey wrote:
> >
> >>JP,
> >>Comments inlined:
> >>
> >>Indeed. In the case of TE, there are various cases where a router may
> >>want to advertise a capability with different flooding scopes thus two
> >>different opaque LSAs. For instance, a router may belong to two
> >>different meshes of TE LSPs, one local to its area (RI LSA of Type 10)
> >>one across the routing domain (RI LSA of Type 11).
> >>
> >>vivek> If i understand correctly you are referring to the case when 
> router has attached NSSA/STUB area's, otherwise RI LSA of Type 11, 
> would suffice.
> >>
> >>The same TLV (automesh) is used, with different contents, carried in 
> different LSA (type 10 and 11).
> >>
> >>vivek> Why same TLV is required to carry different contents in 
> different scoped LSAs. What if same contents are carried in both Type 
> 10 and Type 11 RI opaque LSAs. Are we intending to hide some 
> information across different OSPF flooding scopes ? Since router's 
> capability is independent of "Flooding Scopes", that should not be the 
> case.
> >>
> >>Thanks
> >>Vivek
> >>
> >>
> >>
> >>
> >>On Wed, 08 Dec 2004 JP Vasseur wrote :
> >> >Hi Vivek,
> >> >
> >> >On Dec 7, 2004, at 5:16 PM, Acee Lindem wrote:
> >> >
> >> >>Hi Vivek,
> >> >>
> >> >>
> >> >>Vivek Dubey wrote:
> >> >>
> >> >>>Peter,
> >> >>>
> >> >>>1) In case of ABR analogy, the information was directly relevant to
> >> >>>  OSPF routing and even than it was provided as configuration 
> option,
> >> >>>  not a "should" condition.
> >> >>>
> >> >>I think the configuration option is implementation specific. Although
> >> >>it is
> >> >>not covered explicitly I think RFC 3103 implies an ABR will
> >> >>redistribute
> >> >>into both attached NSSAs and regular areas.
> >> >>
> >> >>
> >> >>>
> >> >>>  Here, OSPF RI Opaque LSA is used for both:
> >> >>>  a) Advertising router's OSPF capabilities (TLV 1)
> >> >>>  b) Capablities Opaque to OSPF (Any future TLVs defined)
> >> >>>
> >> >>>  And since flooding scope is per TLV and depends on local policy,
> >> >>>  there should be no dependency on Type's of area configured at OSPF
> >> >>>  level.
> >> >>>
> >> >>>2)
> >> >>>draft>An OSPF router MAY advertise different capabilities when both
> >> >>>      NSSA/stub area type 10 LSA(s) and an AS scoped type 11 opaque
> >> >>>      LSA is advertised.
> >> >>>vivek> Capabilities here should map to different TLV's ??
> >> >>>
> >> >>>Peter>I guess it can be different TLVs or different content in the
> >> >>>same TLV.
> >> >>>
> >> >>>vivek> Different content in same TLV, advertised in different scoped
> >> >>>      LSAs (Type 10 and Type 11). Doesnt seems a good idea to me.
> >> >>>      Any possible scenarios?
> >> >>>
> >> >>JP - can you take a shot at this? I seem to remember that you had a
> >> >>scenario in minde.
> >> >>
> >> >
> >> >Indeed. In the case of TE, there are various cases where a router may
> >> >want to advertise a capability with different flooding scopes thus two
> >> >different opaque LSAs. For instance, a router may belong to two
> >> >different meshes of TE LSPs, one local to its area (RI LSA of Type 10)
> >> >one across the routing domain (RI LSA of Type 11). The same TLV
> >> >(automesh) is used, with different contents, carried in different LSA
> >> >(type 10 and 11).
> >> >
> >> >Thanks.
> >> >
> >> >JP.
> >> >
> >> >>Thanks,
> >> >>Acee
> >> >>
> >> >>>
> >> >>>Thanks
> >> >>>Vivek
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>On Tue, 07 Dec 2004 Peter Psenak wrote :
> >> >>> >Vivek,
> >> >>> >
> >> >>> >Vivek Dubey wrote:
> >> >>> >>Hi,
> >> >>> >>Section 2.3:
> >> >>> >>draft>TLV flooding scope rules will be specified on a per-TLV 
> basis
> >> >>> >>draft>If a type 11 opaque LSA is chosen, the originating router
> >> >>>should
> >> >>> >>      also advertise type 10 LSA(s) into any attached 
> NSSA/stub area
> >> >>> >>
> >> >>> >>vivek) If scope of TLV is defined to be AS (Type 11), why should,
> >> >>>the
> >> >>> >>      originating router advertise type 10 LSA(s) into any
> >> >>> >>      attached NSSA/stub area ? Idea seems to get the 
> capabilities
> >> >>> >>      advertised to NSSA/STUB neighbors of originating 
> router. But
> >> >>> >>      what about NSSA/STUB areas attached not to "originating"
> >> >>> >>      routers??
> >> >>> >
> >> >>> >an analogy is when you have an ABR connected to backbone area and
> >> >>>NSSA
> >> >>> >area and you redistribute routes from some external source. 
> ABR will
> >> >>> >generate Type-5 external LSA, plus it can be configured to 
> advertise
> >> >>> >Type-7 LSA to the NSSA area for the same prefix.
> >> >>> >If you have another ASBR somewhere in backbone area, Type-5 
> LSAs it
> >> >>> >generates will not get propagated to NSSA area.
> >> >>> >
> >> >>> >>
> >> >>> >>draft>An OSPF router MAY advertise different capabilities 
> when both
> >> >>> >>      NSSA/stub area type 10 LSA(s) and an AS scoped type 11 
> opaque
> >> >>> >>      LSA is advertised.
> >> >>> >>vivek> Capabilities here should map to different TLV's ??
> >> >>> >
> >> >>> >I guess it can be different TLVs or different content in the same
> >> >>>TLV.
> >> >>> >
> >> >>> >Peter
> >> >>> >
> >> >>> >>
> >> >>> >>Thanks
> >> >>> >>Vivek
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >><http://clients.rediff.com/signature/track_sig.asp>
> >> >>>
> >> >>>
> >> >>>
> >> >>><http://clients.rediff.com/signature/track_sig.asp>
> >> >>
> >>
> >>
> >><http://clients.rediff.com/signature/track_sig.asp>
>
>
>
> <http://clients.rediff.com/signature/track_sig.asp>