Hi, Ketan: The aim of OSPF Two-Part Metric[RFC8042] is to solve the situation that one router can be reached via different metrics by other routers on the same LAN, its application is different from the maintenance purpose(OSPF Reverse Metric) on one interface that connected to the LAN.
>From my POV, the possible similar procedures to solve the maintenance purposes >on LAN interfaces are the followings: 1. Define and put the “Reverse Metric” sub-TLV within the “Router-Link TLV” (https://datatracker.ietf.org/doc/html/rfc8362#section-3.2) (Instead of using LLS block) 2. The mentioned router(Router A) advertise the Router LSA to DR, with the “Reverse Metric” sub-TLV attached within the “Router-Link TLV” 3. The DR/BDR act upon the “Reverse Metric” sub-TLV, using the “W”-bit to signal whether only “to the advertising router” is changed, or the metrics to all routers on the LAN should be changed. 4. DRothers use the updated neighbor metric to calculate the SPF path to the original mentioned router(Router A), push the traffic away to the mentioned router(Router A) Similar procedures as RFC8500. Is there any issues? Best Regards Aijun Wang China Telecom From: [email protected] <[email protected]> On Behalf Of Ketan Talaulikar Sent: Friday, April 22, 2022 10:10 PM To: Aijun Wang <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; Acee Lindem (acee) <[email protected]>; [email protected]; lsr <[email protected]> Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" Hi Aijun, Please check inline below. On Fri, Apr 22, 2022 at 8:57 AM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Ketan and Acee: I have not seen there is any other possible application of the “Reverse Metric” mechanism, except that are described in RFC8500. There is no additional value to repeat to illustrate them, refer to them is enough. KT> I am considering this as an editorial comment. As explained by me and also confirmed by Acee, there are significant differences in the applicability of the use-cases given that the OSPF reverse metric does not apply for the LAN. That said, we (authors) will be posting an update next week to address the comments received and I believe they will partially incorporate your feedback. The “W” bit in RFC8500 is useful in LAN environment and I have said that there is no technical issue to apply the “Reverse Metric” mechanism to LAN environment. >From my POV, such solution is more straightforward than the 2-part metric >based solution. KT> The OSPF reverse metric cannot be applied to LAN similar to how it is done in ISIS due to some fundamental differences between the protocols. If you have worked out a solution to the LAN problem that is significantly better than the OSPF Two-Part Metric mechanism and one that leverages Reverse Metric, then I am eager to see it. Please provide the solution and the WG can evaluate it. Thanks, Ketan The existing implementation doesn’t imply it is the best. Anyway, you can insist your direction. Best Regards Aijun Wang China Telecom From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of Ketan Talaulikar Sent: Thursday, April 21, 2022 11:00 PM To: Acee Lindem (acee) <[email protected] <mailto:[email protected]> > Cc: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]> >; Aijun Wang <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; lsr <[email protected] <mailto:[email protected]> > Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" Hi Aijun, +1 to Acee's response. Thanks, Ketan On Thu, Apr 21, 2022 at 7:28 PM Acee Lindem (acee) <[email protected] <mailto:[email protected]> > wrote: Speaking as WG member and Document Shepherd: Hi Aijun, There is no requirement to directly follow the encodings and terminology in RFC 8500. In fact, this draft is, IMO, cleaner. From: Aijun Wang <[email protected] <mailto:[email protected]> > Date: Wednesday, April 20, 2022 at 8:52 PM To: 'Ketan Talaulikar' <[email protected] <mailto:[email protected]> > Cc: "Les Ginsberg (ginsberg)" <[email protected] <mailto:[email protected]> >, 'lsr' <[email protected] <mailto:[email protected]> >, "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> >, Acee Lindem <[email protected] <mailto:[email protected]> > Subject: RE: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" Hi, Ketan: For document integrity, I think you can write the following corresponding parts of RFC8500: 1) 1.1 Node and Link Isolation 2) 1.2 Spine-Leaf Applications(with the term “Congested” to be replaced by “broken down”) 3) 1.3 Distributed Forwarding Planes 4) 1.4 LDP IGP Synchronization(Although RFC8042 can solve such problem, it doesn’t prevent the usage of “Reverse Metric” mechanism to solve it) Or ,you just refer to the above parts in your documents, and avoid to repeat the scenarios again. As Ketan already indicated, some of these use cases aren’t applicable for various reason, e.g., 2-part metric. For the encoding, I still think you need only specify the metric value is offset directly(as that in RFC8500), and needn’t introduce the H/O bit to complex the implementation and deployments. There may already be implementations and no one has complained. Note that this draft doesn’t include the W-Bit or U-Bit that are in RFC 8500. It is more straight-forward. Thanks, Acee Best Regards Aijun Wang China Telecom From: Ketan Talaulikar <[email protected] <mailto:[email protected]> > Sent: Wednesday, April 20, 2022 6:47 PM To: Aijun Wang <[email protected] <mailto:[email protected]> > Cc: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]> >; lsr <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; Acee Lindem (acee) <[email protected] <mailto:[email protected]> > Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" Hi Aijun, Please check inline below. On Wed, Apr 20, 2022 at 7:36 AM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Ketan: My suggestion is to refer some contents in RFC8500, don’t need to describe the scenarios again, to introduce the necessary of protocol extension in OSPF. KT> I am not sure that I understand your suggestion. Which specific portions of the text would you like to be removed and instead point to the ISIS Reverse metric spec in a manner that does not affect the readability of the document. For your mentioned use case 2.2 “Adaptive Metric Signaling”, also the application described in section 1.3 of RFC 8500(Spine-Leaf Application), my comments are still the same: 1. The described problem is valid, but the “Reversed Metric” based proposed solution is problematic. 2. Here are the explanations( Take your use case 2.2 as the example): 1）Normally all the leaf routers(R1, R2,… … Rn) will have the same metric to the Spine(AGG1, AGG2), the traffic from these leafs will be evenly distributed to/from AGG1 and AGG2. 2) Once the uplink AGG1 encounter the congestion, if it push the “Reverse Metric” to R1, then all traffic from R1 will divert to AGG2; KT> I think the use of the term "congestion" seems to be the cause of some confusion. This is about AGG1 losing some of its capacity towards the core due to an upstream link going down. We can remove the use of the term "congestion" in this context. 3) Will the uplink on AGG2 encounter congestion then? If so, it should also push the “Reverse Metric” to R1, then all traffic from R1 will back to AGG1(when the uplink congestion of AGG1 is released, AGG1 will stop send the “Reverse Metric”) KT> Please see my previous response. Thanks, Ketan The traffic from R1 will oscillate between AGGR1 and AGGR2. This is not the traffic engineering result that the operator want. Then, my suggestion is that this use case should also be removed. The application of “Reverse Metric” mechanism should not be expanded, it should be triggered by manual, not automatically. Regarding to the encoding, RFC8500 proposes only the offset value, there are only U/W flag being defined. The “U” bit just indicates the maximum value is (2^24-1)(corresponding to the “wide”metric). Considering that the only applicable scenarios is for maintenance, the introduction of H/U bit complexes its usage. It should be simplified. Best Regards Aijun Wang China Telecom From: Ketan Talaulikar <[email protected] <mailto:[email protected]> > Sent: Tuesday, April 19, 2022 6:59 PM To: Aijun Wang <[email protected] <mailto:[email protected]> > Cc: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]> >; Acee Lindem (acee) <[email protected] <mailto:[email protected]> >; lsr <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" Hi Aijun, Please check inline below for responses. On Tue, Apr 19, 2022 at 1:00 PM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: 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 KT> Please check my response to Les and let us know if that is not addressing your concerns. 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. KT> Any time the IGP metric is updated for a link, it does influence the traffic distribution in the IGP domain. This is a given and so I don't really understand your concern. This use case is very similar to the Spine Leaf one in RFC8500 - we can clarify that in the text. 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. KT> The additive offset is there in RFC8500 as well and so I don't see why we would want to not have that in OSPF. Thanks, Ketan Best Regards Aijun Wang China Telecom From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of Les Ginsberg (ginsberg) Sent: Tuesday, April 19, 2022 2:44 PM To: Acee Lindem (acee) <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Cc: [email protected] <mailto:[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] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
