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
