Re: [OSPF] draft-atlas-ospf-mrt-02

[Shraddha Hegde <[e-mail]>]

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:[e-mail]] 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 <[e-mail]> 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:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ospf