Hi Tony,
On 24/05/2021 20:44, Tony Li wrote:
Hi Ketan,
In general, I support the adoption of this document. There is,
however, one specific point which is not clear to me (8) below that I
would appreciate some clarity on before adoption.
As the chairs have noted, adoption is binary and not contingent upon
rough consensus on the content, just on rough consensus on the interest.
1. Why is the Generic Metric type in ISIS limited to 3 byte size?
OSPF allows 4 byte size and so why not the same for ISIS?
Elsewhere in the document, I do see MAX METRIC being referred to
as 4,261,412,864.
Because I’m a lazy sod.
It’s far easier to detect metric overflow on three byte values than four
byte values. True, four byte is not impossible, but it’s just quick and
easy with three byte values. Adding a fourth byte would add range to
the metric space, but in practice, this seemed like it was not really
relevant. Most areas are not a very high diameter and the need for
detailed metric distinctions has not been that high. Thus, we went with
a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work.
1.
2. Would be good to cover the max-metric considerations for the
Generic Metric. Similar
tohttps://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3
Fair
2.
3. Since the draft is covering FlexAlgo, I would have expected that
Generic Metric is carried only in the ASLA and this document
specifies usage only for the FA application. Later this can be
also used/extended for other applications but still within ASLA.
Keeping an option of advertising both outside and within the ASLA
is problematic – we will need precedence rules and such. I prefer
we avoid this complication.
We preferred avoiding ASLA.
we are not avoiding ASLA. We allow the ISIS Generic Metric sub-TLV to be
sent inside or outside ASLA.
For flex-algo purposes we mandate it to be in ASLA. That's all what we
need for the purpose of this draft. The rest is for future.
3.
4. For the newly proposed FAD b/w constraints, I would suggest the
following names for the constraint sub-TLVs where the b/w value
signalled by all is compared with the Max Link B/w attribute. This
is just to make the meaning, at least IMHO, more clear.
1. Exclude Higher Bandwidth Links
2. Exclude Lower Bandwidth Links
3. Include-Only Higher Bandwidth Links
4. Include-Only Lower Bandwidth Links
5. Similar naming for the FAD delay constraints as well would help.
Though I can only think of the use of “exclude” for links above a
certain delay threshold to be more practical but perhaps others
might eventually be required as well?
Thank you for the suggestions.
5.
6. For the Max B/w Link attribute and its comparison with the FAD b/w
constraints, I see the reference to ASLA. While in OSPF
max-bandwidth is not allowed in ASLA
-https://datatracker.ietf.org/doc/html/rfc8920#section-7, in case
of ISIS also, it is not really appropriate for use within ASLA
-https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?
I’m sorry, I don’t understand this comment.
6.
7. Document should cover the FAPM aspects for the Generic Metric and
especially the Bandwidth metric.
Nor this one.
7.
8. The document introduces a new Generic Metric type called Bandwidth
metric. I’ve been trying to follow some of the discussion related
to this on the mailing list – about it being cumulative or not. I
am perhaps somewhat confused by those discussions. The OSPF/ISIS
SPT computation has always worked with cumulative link (and
prefix) metrics. If the computation for the Generic Metric of this
new type b/w is not going to be cumulative (I thought it is – but
not very clear anymore), then the document needs to describe the
computation algorithm. Is it then hop count based? Perhaps I am
missing something very basic here and if so, please point me to
the text in the draft.
I’m sorry if this has been confusing. My understanding is that the
metric is cumulative. Others had other expectations.
my expectation is to be cumulative as well.
thanks,
Peter
When there are multiple links with the same bandwidth, and thus the same
metric, then the total path metric becomes (link metric) * (number of
links).
Regards,
Tony
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
