Hi Aijun, Thanks for confirming and looks like we have converged on the way forward on this topic.
Thanks, Ketan On Fri, Apr 29, 2022 at 3:16 PM Aijun Wang <[email protected]> wrote: > Hi, Ketan: > > I am OK with the updated version that the LAN situation is stripped off > the current document. > > I am considering other general solution to accomplish the application > scenarios of the reverse metric mechanism. > > Will try to write one draft when the thought has finalized. > > > > Best Regards > > > > Aijun Wang > > China Telecom > > *From:* [email protected] <[email protected]> *On Behalf Of *Ketan > Talaulikar > *Sent:* Thursday, April 28, 2022 10:50 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Acee Lindem (acee) <[email protected]>; Les Ginsberg > (ginsberg) <[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, > > > > My apologies for the delay in getting back to you. I am not sure that I > follow your points well and so let me rephrase based on my understanding. > Please feel free to correct me if I am wrong. > > > > 1) You are OK with the solution proposed in this reverse metric draft for > both OSPFv2 and OSPFv3 for non-LAN networks. > > > > 2) You are OK with the Two-Part Metric solution in RFC8042 for addressing > similar use-cases in the LAN networks for OSPFv2. > > > > 3) You are proposing a solution for OSPFv3 for LAN networks that is > different from the Two-Part metric mechanism. At this point, there is no > RFC/draft that is covering this problem space even though RFC8042 provides > some hints on how it may be solved using the Two-Part metric. > > > > If my understanding is correct, then I would suggest that we can tackle > (3) in a separate draft. > > > > My view on this is that the Two-Part metric mechanism is also suitable for > OSPFv3 LAN but we can have that debate on a separate thread. > > > > Thanks, > > Ketan > > > > > > On Thu, Apr 28, 2022 at 8:53 AM Aijun Wang <[email protected]> > wrote: > > No. I don’t think so, OSPFv3(RFC8362) can solve the problem described in > RFC8402 now. > > To solve the “reverse-metric” problem in LAN interface for both OSPFv2 > and OSPFv3, why not depend on RFC6845? > > > > The reason that RFC8042 doesn’t using RFC6845 for its scenarios, are the > followings: (https://datatracker.ietf.org/doc/html/rfc8042#section-1) > > “… …Consider that there could be many terminals > > and many of them can be moving fast and frequently. The number and > > frequency of updates of those large Router-LSAs could inhibit network > > scaling.” > > But for “reverse-metric” scenario, the advertised router doesn’t move, > there is not much number and frequency of the updates. > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* [email protected] <[email protected]> *On Behalf Of *Acee > Lindem (acee) > *Sent:* Thursday, April 28, 2022 2:23 AM > *To:* Aijun Wang <[email protected]>; 'Acee Lindem (acee)' <acee= > [email protected]>; 'Ketan Talaulikar' <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; > [email protected]; 'lsr' <[email protected]> > *Subject:* Re: [Lsr] Working Group Last Call for > draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" > > > > RFC 8042 needs to be updated to include OSPFv3 – thanks for reminding us > (as co-author). It was consciously omitted to avoid waiting for OSPFv3 > Extended LSAs (RFC 8362) for which we required implementations before > advancing. > > > > Thanks, > > Acee > > > > *From: *Lsr <[email protected]> on behalf of Aijun Wang < > [email protected]> > *Date: *Tuesday, April 26, 2022 at 10:26 PM > *To: *"'Acee Lindem (acee)'" <[email protected]>, 'Ketan > Talaulikar' <[email protected]> > *Cc: *"Les Ginsberg (ginsberg)" <[email protected]>, " > [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, Acee: > > Because there is no “Network-to-Router Metric” definition in > OSPFv3(actually, OSPFv3 needn’t it), then solely described in the current > draft to rely on RFC8042 to solve the LAN situation is not enough. > > > > Considering that it is difficult to extend the OSPFv2, to let the Router > LSA include also the “Router-Link TLV”, as that done in RFC8362, and also > this is the Last Call stage, I propose the following update to the current > solution: > > 1. Attached the “Reverse Metric TLV” on LLS for OSPFv2 and OSPFv3. > > 2. For LAN interface in OSPFv2, using the two-part metric > solution(RFC8042). > > 3. For LAN interface in OSPFv3, when the DRother receives the hello > packet with “LLS Reverse Metric TLV”, each will advertise the Router LSA, > with the metric value for the LAN interface to the advertised router > attached in “Router-Link TLV” set to the value (or adding the offset > value) appointed by the “Reverse Metric”. The “W” bit can be preserved, > to signal whether only the interface to the advertised router be changed, > or all the routers on the LAN will be influenced. > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* [email protected] <[email protected]> *On Behalf Of *Acee > Lindem (acee) > *Sent:* Wednesday, April 27, 2022 12:46 AM > *To:* Aijun Wang <[email protected]>; 'Ketan Talaulikar' < > [email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; > [email protected]; 'lsr' <[email protected]> > *Subject:* Re: [Lsr] Working Group Last Call for > draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" > > > > Speaking as WG Member: > > > > Hi Aijun, > > > > One could accomplish this with extensions to the LSAs as you suggest but > that would be inferior to the approach in the current draft. The > reverse-metric information only needs to be signaled to the neighbor(s) on > the link to influence their metric advertisement and not the entire OSPF > area. We are not changing the base SPF calculation for everyone in the > domain so the deployment requirements are limited to the router and its > neighbor(s) on the link. If we were only doing this for OSPFv3, it would > make sense to use the OSPFv3 Link-LSA. However, since we are supporting > OSPFv2 which is still wider deployed, OSPF Hello LLS is a better mechanism > since it is readily available in both OSPFv2 and OSPFv3. > > > > > > Speaking as WG Chair: > > > > If you are going to suggest an alternate solution for a draft, it is best > to do it during WG adoption as opposed to WG last call. > > > > Thanks, > > Acee > > > > *From: *Aijun Wang <[email protected]> > *Date: *Monday, April 25, 2022 at 10:05 PM > *To: *'Ketan Talaulikar' <[email protected]> > *Cc: *"Les Ginsberg (ginsberg)" <[email protected]>, Acee Lindem < > [email protected]>, "[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, Ketan: > > What I want to say is that the mechanism described in your draft can act > also upon the LAN interface, take the similar procedures as RFC 8500. > > > > RFC 8042 has referred [OSPFV3-EXTENDED-LSA], which is the precedent > document of RFC8362. The text in RFC 8042 ( > https://datatracker.ietf.org/doc/html/rfc8042#section-3.4) just said the > followings: > > “Network-to-Router metric advertisement in OSPFv3 Extended Router-LSA > > [OSPFV3-EXTENDED-LSA > <https://datatracker.ietf.org/doc/html/rfc8042#ref-OSPFV3-EXTENDED-LSA>] > will be described in a separate document.” > > But I don’t see the so-called “separate document”. > > > > And, based on the discussions, I think there is no reason to differentiate > the solution for IS-IS and OSPF on LAN interface. > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* [email protected] <[email protected]> *On Behalf Of *Ketan > Talaulikar > *Sent:* Sunday, April 24, 2022 6:01 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, > > > > Perhaps I was not clear enough in my email. My question is - What is the > significant difference or improvement between what you've described and the > OSPF Two-Part Metric (RFC8042) apart from the TLV name change? > > > > Is it your point that RFC8042 does not cover OSPFv3? If so, it looks like > it was in that draft and was removed just before publication - perhaps to > remove the dependency with RFC8362? > > > > Thanks, > > Ketan > > > > > > On Sun, Apr 24, 2022 at 8:49 AM Aijun Wang <[email protected]> > wrote: > > 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]> > 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] <[email protected]> *On Behalf Of *Ketan > Talaulikar > *Sent:* Thursday, April 21, 2022 11:00 PM > *To:* Acee Lindem (acee) <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Aijun Wang < > [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, > > > > +1 to Acee's response. > > > > Thanks, > > Ketan > > > > > > On Thu, Apr 21, 2022 at 7:28 PM Acee Lindem (acee) <[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]> > *Date: *Wednesday, April 20, 2022 at 8:52 PM > *To: *'Ketan Talaulikar' <[email protected]> > *Cc: *"Les Ginsberg (ginsberg)" <[email protected]>, 'lsr' <[email protected]>, > "[email protected]" < > [email protected]>, Acee Lindem <[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]> > *Sent:* Wednesday, April 20, 2022 6:47 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; lsr < > [email protected]>; [email protected]; Acee Lindem > (acee) <[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]> > 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]> > *Sent:* Tuesday, April 19, 2022 6:59 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Acee > Lindem (acee) <[email protected]>; lsr <[email protected]>; > [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]> > 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] <[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]> *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 > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
