-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, July 21, 2014 5:00 PM
To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
Cc: vibhor.ju...@l-3com.com; dave.dub...@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
