Santanu, On 3/30/15 09:07 , Santanu Kar wrote:
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
more specifically, it will send 48 instances if the same LSA.
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.
yes, what is wrong with the above? The exact same thing happens with Router LSA today. If you do not like it, your implementation can generate a dedicated Ext. Prefix LSA for each prefix. Both ways are allowed. But your implementation MUST be able to deal with the received Ext. Prefix LSAs that have multiple Ext Prefix TLVs.
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
each prefix should be only advertised in a single Ext Prefix LSA...
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.
what you described above is incorrect. When Ext Prefix LSA has multiple Ext Prefix TLVs and you want to remove one of them, you simply regenerate the Ext Prefix LSA without the Ext Prefix TLV that corresponds to that prefix and keep the rest of the Ext Prefix TLVs in the LSA - these prefixes are NOT affected.
I propose the following solutions for this problem. i) The Ext Prefix LSA can have a fixed instance number associated with
above is by definition - Instance (or Opaque-ID), is part of the LSID, which together with the Adv-Rtr-ID uniquely identifies the LSA itself.
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.
none of the above needs to be standardized. Base OSPF spec specifies that newer version of LSA replaces the old one. The way you deal with it is up to you. The only requirement is that you only use info that is in the latest version of the LSA.
ii) The Ext Prefix LSA can allow only a single Top Level TLV per LSA.
no, we want to have the flexibility in packing the single or multiple TLVs in the Ext Prefix LSA.
regards, Peter
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] <mailto:[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 <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
