Hi Acee, Thanks for your inputs and we'll update the draft accordingly.
Thanks, Ketan On Tue, Apr 19, 2022 at 6:54 PM Acee Lindem (acee) <[email protected]> wrote: > 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]> 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]> *On Behalf Of *Acee Lindem (acee) > *Sent:* Thursday, April 7, 2022 12:18 PM > *To:* [email protected] > *Cc:* [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
