Hi Peter Yeah, I understand that for updates of Ext Prefix LSA (when we are adding/modifying/deleting Prefix TLVs) if we keep the Link ID (Type number, Opaque ID/Instance) same, then by general OSPF rules we will take only the latest LSA , and scenarios mentioned above will work perfectly. When the link ID remains same, the working is very similar to the router LSA.
My only concern is on the text which talks about different instances of Ext Prefix LSA from same router. If this TLV is advertised multiple times for the same prefix in different OSPFv2 Extended Prefix Opaque LSAs originated by the same OSPF router, the OSPF advertising router is re-originating Extended Prefix Opaque LSAs for multiple prefixes and is most likely repacking Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case, the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the smallest Instance is used by receiving OSPFv2 Routers. This situation MAY be logged as a warning. What are the conditions on which a router will generate different instances (in effect different link IDs) of Ext Prefix LSA? So if there are say 5 prefix TLVs to send, the router can choose to send i) All in one LSA, or ii)Send 2 TLVs in one instance and 3 in other, or may be even iii) 5 LSAs each having one TLV ? Regards Santanu On Mon, Mar 30, 2015 at 1:33 PM, Peter Psenak <[email protected]> wrote: > 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 >> ------------------------------------------------------------ >> ---------------------------------- >> > > -- 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
