Hi Jeffrey,
understood and the encoding in the draft looks good then.
I would propose to mention that the new Sub-TLV only applies to
link-type 2 (Connection to a transit network) and MUST be ignored for
other link types.
Section 3 says:
"This document does not currently specify
a way to detect a router's capability of supporting this, and relies
on operator's due diligence in provisioning. A protocol mechanism
may be developer in the future."
Contrary, section 3.5 defines a mechanism to detect the
"Upon detecting the presence of a reachable Router LSA without a
companion RI LSA that has the bit set, all routers MUST disable the
two-part metric functionalities"
thanks,
Peter
On 10/3/14 14:28 , Jeffrey (Zhaohui) Zhang wrote:
Peter,
For the DR to learn different cost to different neighbors from the network (not
from the DR), it may be difficult or may require some out of band mechanism. If
the out of band mechanism is available, I would also prefer to do so - and that
was indeed in revision -02 as an further optimization. It was removed per
Acee's comment.
Thanks.
Jeffrey
-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Friday, October 03, 2014 8:18 AM
To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
Cc: vibhor.ju...@l-3com.com; dave.dub...@gdc4s.com; tom.mcmillan@l-
3com.com; Lili Wang
Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-
metric
Hi Jeffrey,
On 10/3/14 13:54 , Jeffrey (Zhaohui) Zhang wrote:
Peter,
Let's say we have router A on the network. The metric from the network
to A is encoded in router A's own extended LSA, so no neighbor
information is needed. You can imagine that it is AS IF the metric was
encoded next to the normal to-network metric side by side.
Router A (DR)
|
----------------------
| |
Router B Router C
- what you are trying to solve is the lack of metric in A->B and A->C
direction
- the natural choice would be for A (DR) to advertise a metric for each
adjacent neighbor. Why do you prefer to advertise the reverse metric
from B and C instead?
thanks,
Peter
We did consider to optionally encode that in the extended network LSA
for OSPFv3, so that if the underlying network has the ability for the DR
to learn the from-network metric for each neighbor, then it'll be able
encode those metrics in the network LSA, further reducing the churning
when an affect-all event happens. That was in -02, but it was deemed too
dependent on the underlying network (to let the DR know those metrics)
and deviating from the normal OSPF, so it was take out.
Thanks.
Jeffrey
-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Friday, October 03, 2014 7:37 AM
To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
Cc: vibhor.ju...@l-3com.com; dave.dub...@gdc4s.com; tom.mcmillan@l-
3com.com; Lili Wang
Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-
part-
metric
Jeffrey,
the encoding you proposed would not work.
OSPFv2:
- you added Network-to-Router Metric Sub-TLV in Extended Link TLV,
but
Extended Link TLV does not have any neighbor identification. Please
look
at LAN Adj-SID Sub-TLV defined in
draft-ietf-ospf-segment-routing-extensions - you need something
similar.
OSPFv3:
- you added Network-to-Router Metric Sub-TLV to Router-Link TLV of
E-Router-LSA. That is not the right place. You should put the metric
from DR to neighbors inside OSPFv3 E-Network-LSA and include neighbor
identifier in it.
thanks,
Peter
On 10/2/14 20:42 , Jeffrey (Zhaohui) Zhang wrote:
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: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
.
.
.
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
