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

[Vivek Dubey <[e-mail]>]

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.
  
  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.

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.

  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)

-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>