Hi Peter Thanks for the clarification.
I still do not completely agree that scenario (1) is a 'error or temporary condition'. Scenario A: Lets consider we have a network of routers and each router has 48 ports and OSPF routing enabled on all. We want to replace LDP in the network and have Prefix Segment based label mappings for all prefixes in the network. So while configuring for the first time, each prefix with a prefix SID one by one, OSPF will send out 48 Ext Prefix LSAs. The first one will have only one Prefix TLV, the next one two, and subsequent ones keep adding the additional Prefix TLVs and repacking into the LSA. All the LSAs will keep having incremental instance. So the first prefix is advertised 48 times by the same router in different Ext Prefix LSAs. There are few more scenarios that needs to be considered for Multiple-Prefix TLV .Consider the following. Scenario B: Withdrawing of Prefix TLV. If on a particular router the prefix SID configured for one of its prefixes is unconfigured, the router needs to withdraw that specific Prefix TLV from the OSPF network. If this Prefix TLV was part of one or more LSA as described in scenario A, then all such LSAs needs to be withdrawn by issuing a LSA of MaxAge. Also since each LSA has multiple Prefix TLVs , all other Prefix-TLVs in that LSA will also get effected. This is undesirable. Even if there is no duplicate prefix TLVs across LSAs, this problem is applicable for the LSA which is withdrawn. I propose the following solutions for this problem. i) The Ext Prefix LSA can have a fixed instance number associated with it. Whenever a prefix-TLV is received, as part of any Ext Prefix LSA, it needs to check for any modifications from the previous LSA. If none, it will ignore that prefix-TLV. Else it will be updated. In this way, even if a particular prefix-TLV is sent multiple times , and the latest one is considered as per the age of LSA, it will have no impact internally on the routes corresponding to that Prefix. Also it will significantly reduce the Link State Database to be maintained, and it will always be one per router. Any new prefix TLV in the new LSA will be added, and if any prefix TLV previously advertised is missing, will be removed. ii) The Ext Prefix LSA can allow only a single Top Level TLV per LSA. Here announcing new Prefix and its withdraw can happen individually and will be a much simpler approach. This is similar to approach followed in OSPF TE ( https://tools.ietf.org/html/rfc3630#section-2.4) Regards Santanu On Wed, Mar 25, 2015 at 7:03 PM, Peter Psenak <[email protected]> wrote: > Hi Santanu, > > On 3/25/15 14:08 , Santanu Kar wrote: > >> Hi Authors >> >> The Section 2, doesn't provide any clarification on the 'Instance' part >> of the Link ID of >> OSPFv2 Extended Prefix Opaque LSA. >> > > Instance is an arbitrary number to make each OSPFv2 Extended Prefix Opaque > LSA's LSID unique, please see RFC5250, section abut Opaque-ID. > > >> There can be two possible implementations >> >> 1) When a Segment routing enabled router is advertising multiple Ext >> Prefix TLV, it can keep repacking it into a single Ext Prefix LSA, as >> has been mentioned in end of section 2 and keep increasing the instance >> . The lowest instance is taken. Higher instance from same router for >> same prefix is ignored. >> > > above only applies to the case where OSPFv2 Extended Prefix TLV is > advertised for the _same_ prefix in multiple different OSPFv2 Extended > Prefix Opaque LSAs, which is either an error or temporary condition. > > > >> 2) Another possible way is, not to go for this repacking. Instead it >> should be possible to originate separate Ext Prefix LSAs for every Ext >> Prefix TLV, and only one TLV per LSA. The instance number or Opaque id >> can be derived from the prefix/interface so as to ensure its unique for >> every prefix originating from the same advertising router. >> > > yes above is correct, but the draft allows to pack multiple Ext > Prefix TLVs in the single Extended Prefix Opaquer LSA if the > implementation prefers to do so. > > >> The draft is not clear on whether (2) can be allowed. It hasn't >> > > the draft says: > > Multiple OSPF Extended Prefix TLVs MAY be advertised in each OSPFv2 > Extended Prefix Opaque LSA." > > That means it can be one or more. > > > mentioned that the instance is topology independent and dependent on how >> we choose to implement it. The TE RFC however has a section devoted to >> this >> https://tools.ietf.org/html/rfc3630#section-2.2 >> > > I can add a similar text to draft-ietf-ospf-prefix-link-attr. > > > thanks, > Peter > > > >> Please give your thoughts on this. >> >> Regards >> Santanu >> >> >> > -- Best Regards Santanu Kar ---------------------------------------------------------------------------------------------- When you really want something to happen, the whole universe conspires so that your wish comes true ----------------------------------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
