Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric

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:ppsenak@cisco.com]
> Sent: Monday, July 21, 2014 5:00 PM
> To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
> Cc: vibhor.julka@l-3Com.com; Dave.Dubois@gdc4s.com; 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
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
> >