Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

[Ketan Talaulikar <[e-mail]>]

Hi Aijun,

Please check inline below.


On Fri, Apr 22, 2022 at 8:57 AM Aijun Wang <[e-mail]>
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:* [e-mail] <[e-mail]> *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Thursday, April 21, 2022 11:00 PM
> *To:* Acee Lindem (acee) <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <[e-mail]>; Aijun Wang <
> [e-mail]>; [e-mail];
> lsr <[e-mail]>
> *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) <[e-mail]> 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 <[e-mail]>
> *Date: *Wednesday, April 20, 2022 at 8:52 PM
> *To: *'Ketan Talaulikar' <[e-mail]>
> *Cc: *"Les Ginsberg (ginsberg)" <[e-mail]>, 'lsr' <[e-mail]>,
> "[e-mail]" <
> [e-mail]>, Acee Lindem <[e-mail]>
> *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 <[e-mail]>
> *Sent:* Wednesday, April 20, 2022 6:47 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <ginsberg=[e-mail]>; lsr <
> [e-mail]>; [e-mail]; Acee Lindem
> (acee) <acee=[e-mail]>
> *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 <[e-mail]>
> 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 <[e-mail]>
> *Sent:* Tuesday, April 19, 2022 6:59 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <ginsberg=[e-mail]>; Acee
> Lindem (acee) <acee=[e-mail]>; lsr <[e-mail]>;
> [e-mail]
> *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 <[e-mail]>
> 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:* [e-mail] <[e-mail]> *On Behalf Of *Les
> Ginsberg (ginsberg)
> *Sent:* Tuesday, April 19, 2022 2:44 PM
> *To:* Acee Lindem (acee) <acee=[e-mail]>; [e-mail]
> *Cc:* [e-mail]
> *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 <[e-mail]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Thursday, April 7, 2022 12:18 PM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>