Speaking as WG Member and Document Shepherd: I agree on both points. With the exception of the use case in section 2.1, the draft is very easy to understand. By replacing it with the maintenance case, you’ll make the entire draft understandable.
Thanks, Acee From: Ketan Talaulikar <[email protected]> Date: Tuesday, April 19, 2022 at 6:53 AM To: "Les Ginsberg (ginsberg)" <[email protected]> Cc: Acee Lindem <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" Hi Les, Please check inline below. On Tue, Apr 19, 2022 at 12:13 PM Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: 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. KT> I agree that the maintenance use case is quite useful and the reverse metric is one of the mechanisms for achieving that in OSPF. We can add that to the draft. 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. KT> The use cases are only illustrative and I don't see it beneficial to get into an elaborate discussion of a specific use case. I also agree that this particular use case is constrained and not a "general" one. So, it should be ok for us to take this one out unless there are any objections. Thanks, Ketan 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
