Peter, and all, I have posted a new revision, which uses the following to encode the from-network metric.
> 1. OSPFv2: Extended Link LSA > 2. OSPFv3: E-Router LSAs http://www.ietf.org/id/draft-zzhang-ospf-two-part-metric-03.txt Please review and comment. Thanks! Jeffrey > -----Original Message----- > From: Peter Psenak [mailto:[email protected]] > Sent: Monday, July 21, 2014 5:00 PM > To: Jeffrey (Zhaohui) Zhang; [email protected] > Cc: [email protected]; [email protected]; tom.mcmillan@l- > 3com.com > Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part- > metric > > Hi Jeffrey, > > please see inline: > > > On 7/21/14 15:24 , Jeffrey (Zhaohui) Zhang wrote: > > Hi, > > > > In today's OSPF session there were mainly two questions/comments > during my presentation: > > > > 1. Acee: more discussion on mailing list about whether this is a > general problem/solution that the WG should be taking on > > 2. Peter: should we use OSPFv3 Extended LSA for a cleaner encoding > > my comment was not specific to OSPFv3. > I propose to use following extensions to encode metric from DR to > attached router: > > 1. OSPFv2: Extended Link LSA > 2. OSPFv3: E-Router LSAs > > > > > I want to repeat and add some comments/answers here as a starting > point for more discussions on the mailing list. > > > > For #1: > > > > - The described problem is real for some large scale and mission > critical networks > > - The problem and solution are not only applicable to the above > mentioned example network, but also general to any broadcast network > that have different costs between different pair of routers. As long as > the router-to-router costs can be presented as a to-network and a from- > network part, then the simple solution applies > > - The two-part-metric concept is a natural extension of the SPF graph > theory - we're just changing the previously zero from-network cost to > none-zero. > > > > For #2, there are pros and cons with each approach. > > > > - The stub-link based approach does not depend on the in-progress LSA > Extensibility work. This has larger impact on implementation - the > feature can be supported w/o big changes to support extended LSA format. > > though the stub-link approach is simpler to implement, it's a bit of a > "hack", as you are using a standard encoding for a stub link to > advertise a metric for a neighbor on a broadcast link. > > > - The LSA Extensibility work is only applicable for OSPFv3. That means > OSPFv2 would need a different approach for the problem. Acee also > mentioned that it would be good to have consistent approaches between > OSPFv2 and OSPFv3. > > what I proposed is consistent - uses new extended LSAs in both OSPFv2 > and OSPFv3. > > thanks, > Peter > > > - As a result at this time we would prefer the stub-link approach. > > > > The authors would like to hear more of your opinions/suggestions. > Hopefully we can reach consensus on the applicability of the problem & > solution so that it can become a WG item, and choose the best encoding > approach. > > > > Thanks! > > Jeffrey > > > > _______________________________________________ > > OSPF mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
