Hi Jeffrey, Thanks for confirming that we are ok with this draft's relationship with RFC8042.
Thanks, Ketan On Thu, Apr 14, 2022 at 12:13 AM Jeffrey (Zhaohui) Zhang <[email protected]> wrote: > Hi Ketan, > > > > My fault. When I initially grepped for it, I used “8402” instead of “8042” > and did not find it hence the comment ☹ > > Sorry about that. > > > > Jeffrey > > > > > > Juniper Business Use Only > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Wednesday, April 13, 2022 10:06 AM > *To:* Jeffrey (Zhaohui) Zhang <[email protected]> > *Cc:* Acee Lindem (acee) <[email protected]>; [email protected]; > [email protected] > *Subject:* Re: Working Group Last Call for > draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey, > > > > Could you grep for RFC8042 in this draft and then let us know what more is > needed? > > > > Thanks, > > Ketan > > > > > > On Wed, Apr 13, 2022 at 7:18 PM Jeffrey (Zhaohui) Zhang < > [email protected]> wrote: > > Hi, > > > > I just noticed this draft, and I would like to refer to > https://datatracker.ietf.org/doc/html/rfc8042 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8042__;!!NEt6yMaO-gk!RPUE_VAZZzupPzS38nxXHMUbqLbJRk0sAmgaPk6bQwszemzqwH1ULDh1bF2rLV6x$> > “OSPF Two-Part Metric”. > > If this has been discussed before, please point me to an existing email > thread. > > > > It seems that in the LAN case, the two-part metric mechanism would work > better. > > > > +--------+ > > | R0 | > > | Router | > > +--------+ +--------+ > > (a) Physical ^ ^ ^ (b) Layer-3 | R0 | > > Topology | | | Topology +--------+ > > v v v ^ ^ ^ > > +----------------+ | | | > > | Layer 2 Switch | | | | > > | (Aggregation) | +---+ | +---+ > > +----------------+ | | | > > ^^ ^ ^ ^ ^ ^ v | v > > || | | | | | +------+ | +------+ > > +----+| | | | | | | R1 | | | R3 | > > | +---+ | | | | +----+ +------+ | +------+ > > v v v v v v v v > > +--------+ +--------+ +--------+ +--------+ > > | R1 | | R2 | | R3 | | R2 | > > | Router | | Router | | Router | +--------+ > > +-- -----+ +--------+ +--------+ > > > > The reason is, when R1’s link to the switch goes up/down, the reverse > metric from R0 to R1 is not only determined by R1 itself – it depends on > the capacity between R0 and the switch as well. The two-part metric > mechanism handles that well – each router advertises its metric to/from the > “network”, and the R0->R1 metric is the sum of the R0-network and > network-R1 metric. > > > > It would be good for this draft to clarify its use in LAN and compare with > the two-part-metric mechanism. > > > > Thanks. > Jeffrey > > > > > > Juniper Business Use Only > > *From:* Lsr <[email protected]> *On Behalf Of *Acee Lindem (acee) > *Sent:* Thursday, April 7, 2022 3:18 PM > *To:* [email protected] > *Cc:* [email protected] > *Subject:* [Lsr] Working Group Last Call for > draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric" > > > > *[External Email. Be cautious of content]* > > > > 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
