Hi, All: I have the similar opinions as Les.
Such mechanism is actually one maintenance tools and can’t be used to accomplish the metric auto adjustment, as that described in section 2.1 The scenario described in section 2.2 is somewhat problematic: AGGR1 should calculate the adjusted metric value based on its POV, but the adjustment will influence the traffic distribution within all the IGP domain. Such automatic adjustment is dangerous, and is not one solution that can be applied for the more general scenario. Based on the above considerations, I think the authors should limit its usage only for maintenance scenarios as described in RFC8500. For the encoding, I think the “offset” value and the “O” bit is not necessary, because the meaningful “Reverse Metric” should be the maximum value of the metric. Best Regards Aijun Wang China Telecom From: [email protected] <[email protected]> On Behalf Of Les Ginsberg (ginsberg) Sent: Tuesday, April 19, 2022 2:44 PM To: Acee Lindem (acee) <[email protected]>; [email protected] Cc: [email protected] Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" I support progressing this draft. However, I have some concerns about the current content – specifically the use cases – which I would like to see addressed before going to Last Call. The equivalent functionality is defined in RFC 8500 for IS-IS and has proven useful – make sense to also have it for OSPF. But the primary use case discussed in RFC 8500 is during maintenance – which is discussed extensively and is mentioned as the first use case. In the case of draft-ietf-lsr-ospf-reverse-metric, the maintenance use case is not even mentioned. Of the two use cases that are mentioned, the one in Section 2.1 has many limitations and constraints. These include: * Only works when there is a switch in the middle – something which the protocol is not able to detect * Only works in the presence of symmetrical metrics * If both neighbors have L2 bundles to the switch and are both doing auto-cost adjustment based on the number of members currently up, the mechanism doesn’t work * Detecting symmetrical metrics in the presence of reverse metric is problematical. Is the neighbor cost including the reverse metric or does it reflect something else (e.g., config change on the neighbor) I would prefer that this use case be removed. If not, a more complete discussion of the limitations should be included. In summary, before progressing this draft I would like to see maintenance included as the primary use case and the use case described in Section 2.1 removed. Les From: Lsr <[email protected] <mailto:[email protected]> > On Behalf Of Acee Lindem (acee) Sent: Thursday, April 7, 2022 12:18 PM To: [email protected] <mailto:[email protected]> Cc: [email protected] <mailto:[email protected]> Subject: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" This begins a Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric. While there hasn’t been as much discussion as I would like on the draft, it is filling a gap in OSPF corresponding to IS-IS Reverse Metric (RFC 8500). Please review and send your comments, support, or objection to this list before 12 AM UTC on April 22nd, 2022. Thanks, Acee
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
