(The response to this question ended up off of the list, so I'm posting it to continue the discussion on the list.)
Russ, I see your point in link information being carried in Node related LSA. The link information is carried in Router LSA and it's not extendible to carry any other information. Since RI-LSA is modeled as an extension to Router LSA, my idea was to tag the additional link information With new TLV in RI-LSA. Another approach could have been to define a new LSA type and originate a new LSA for each link which is in-eligible to participate in MRT. A separate LSA for each link to advertise ineligibility looks suboptimal considering the amount of state machine/data structure that needs to be maintained for a separate LSA. >> It seems like it might be better to move this bit of information into the >> TLV where the actual link state is advertised in some way. Link related information is advertised in OSPF-TE opaque LSAs as well. MRT could run on non-TE enabled networks as well, so it may not be appropriate to use TE LSAs. Let me know if you think we could stuff-in in existing LSAs or we should go with new LSA altogether. Rgds, Shraddha -----Original Message----- From: OSPF [mailto:[email protected]] On Behalf Of Russ White Sent: Sunday, July 06, 2014 7:41 AM To: 'OSPF List' Cc: Alia Atlas Subject: [OSPF] draft-atlas-ospf-mrt-02 Just one question/comment on this draft -- In section 6.1, MRT-Ineligible Links TLV for OSPFv2, the draft says there should be a new TLV in the router capabilities LSA that advertises links not to be included in the MRT calculation (excluded links). I'm not certain why an option isn't used in the LSA header for this, instead. Two things that seem strange to me: - The exclusion of a link is a link property, not a router property, so I'm not certain why this would be advertised as a property of the OSPF router. This seems to muddy the line between router and properties and link properties in a way that sets the stage for make the router capabilities just another area into which to stuff various bits of information we can't find a home for elsewhere. - If you modify a specific link state, then you must advertise two TLVs, or rather two LSAs, rather than one. Thus these two pieces of information must be connected in a local database, but advertised separately, with all the coordination/etc. that implies. It seems like it might be better to move this bit of information into the TLV where the actual link state is advertised in some way. :-) Russ _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
