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

Vivek Dubey <vivek_ospf@REDIFFMAIL.COM> Fri, 07 January 2005 16:32 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24927 for <ospf-archive@LISTS.IETF.ORG>; Fri, 7 Jan 2005 11:32:16 -0500 (EST)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F3A6CB@cherry.ease.lsoft.com>; Fri, 7 Jan 2005 11:32:16 -0500
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52397954 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Jan 2005 11:32:15 -0500
Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 7 Jan 2005 11:32:14 -0500
Received: (qmail 15237 invoked by uid 510); 7 Jan 2005 16:33:38 -0000
Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 07 jan 2005 16:33:38 -0000
MIME-Version: 1.0
Content-type: multipart/alternative; boundary="Next_1105115618---0-203.199.83.246-15230"
Message-ID: <20050107163338.15236.qmail@webmail35.rediffmail.com>
Date: Fri, 07 Jan 2005 16:33:38 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: Re: draft-ietf-ospf-cap-04.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi Acee,
  
>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.

Takes care of my concern.

Thanks
Vivek




On Thu, 06 Jan 2005 Acee Lindem wrote :
>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>