Hi Acee, Defining a new MRT sub TLV to be carried in the OSPFv2 Extended link TLV as defined in https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/
"Router-Link TLVs"as defined in https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend looks to be a good option. We will work on the draft to update. Rgds Shraddha -----Original Message----- From: OSPF [mailto:[email protected]] On Behalf Of Acee Lindem Sent: Tuesday, July 15, 2014 1:18 AM To: Chris Bowers Cc: OSPF List; Alia Atlas Subject: Re: [OSPF] draft-atlas-ospf-mrt-02 Hi Chris, Shraddha, On Jul 14, 2014, at 3:36 PM, Chris Bowers <[email protected]> wrote: > (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. Do NOT use the OSPF RI LSA for link information. Rather than define a new LSA, use the OSPFv2 Extended-Link opaque LSA defined in https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ Thanks, Acee > > 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
