Hi Ketan I was mentioning the use case of LDP-IGP used in RFC 8500 for LAN use case where with LDP-IGP sync all nodes on the LAN get set to max metric, however with reverse metric optimization only on the nodes pairs that require the max metric get the reverse metric for outbound and inbound without impacting all other nodes on the LAN.
So this would be an optimization to existing LDP-IGP sync which has been around for decades. All nodes that would receiving the reverse metric would require upgrade to support the feature. So this seems to be an important application of reverse metric for OSPF as well. 1.4 <https://datatracker.ietf.org/doc/html/rfc8500#section-1.4>. LDP IGP Synchronization In [RFC5443 <https://datatracker.ietf.org/doc/html/rfc5443>], a mechanism is described to achieve LDP IGP synchronization by using the maximum link metric value on the interface. But in the case of a new IS-IS node joining the broadcast network (LAN), it is not optimal to change all the nodes on the LAN to the maximum link metric value, as described in [RFC6138 <https://datatracker.ietf.org/doc/html/rfc6138>]. In this case, the Reverse Metric can be used to discourage both outbound and inbound traffic without affecting the traffic of other IS-IS nodes on the LAN. Thanks Gyan On Sun, Apr 17, 2022 at 12:51 PM Ketan Talaulikar <[email protected]> wrote: > Hi Gyan, > > Perhaps I am not able to parse your email well. > > 1) The LDP-IGP sync is something already implemented and supported widely > and is not the subject of this draft. Especially related to p2p link > operations, is there anything that needs the reverse metric? > > 2) This draft does not apply to LAN interfaces - that functionality is > provided by RFC8042. > > So I am not sure that I follow what is it that you are proposing to be > added to the OSPF reverse metric draft that is related to IGP-LDP sync. Can > you please explain or better still, propose text? > > Thanks, > Ketan > > > On Sun, Apr 17, 2022 at 5:09 AM Gyan Mishra <[email protected]> wrote: > >> >> Hi Ketan >> >> Welcome. >> >> Responses in-line >> >> Kind Regards >> >> Gyan >> >> On Thu, Apr 14, 2022 at 3:04 AM Ketan Talaulikar <[email protected]> >> wrote: >> >>> Hi Gyan, >>> >>> Thanks for your review and feedback. Please check inline below. >>> >>> >>> On Thu, Apr 14, 2022 at 11:47 AM Gyan Mishra <[email protected]> >>> wrote: >>> >>>> Hi Ketan >>>> >>>> I reviewed the draft and support publication. >>>> >>>> Can you add the two use cases in ISIS RM RFC 8500 about LDP IGP >>>> synchronization and the DC lead to spine scenario where the spine had links >>>> down or congestion. >>>> >>> >>> KT> The LDP IGP synchronization use case in RFC8500 is related to LAN >>> environments and addressed by OSPF Two-Part Metric RFC8042. So it is out of >>> the scope of this draft. The DC spine/leaf use case in RFC8500 is very >>> similar to what is already covered by Sec 2.2. Also, note that the RFC8500 >>> Spine Leaf Sec 1.3 references draft-ietf-lsr-isis-spine-leaf-ext and is not >>> applicable for OSPF. >>> >> >> Gyan> LDP - IGP synchronization has to do with the MPLS data plane >> convergence and is independent of network type broadcast or point-to-point >> but is generally used for /31 or /127 P2P networks were the IGP metric is >> set to “max metric” until the LDP comes up and can be further delayed in >> second “ ldp igp sync delay x” to prevent the IGP from black hole of >> traffic until LDP control plane state is Up at which time the IGP max >> metric is unset back to its original metric and traffic can be converged >> back onto the link. LDP-IGP synchronization and sync delay implementation >> CLI knob is critical for MPLS data plane operation. The RFC 8042 two part >> metric has a use case for router/satellite and router/terminal use cases >> which I can’t see how that would apply to LDP-IGP sync. The reverse metric >> completely makes sense as the max metric would be advertised to override >> the configured metric and then would get unset to original metric when LDP >> comes Up. >> >>> >>> Thanks, >>> Ketan >>> >>> >>>> >>>> Kind Regards >>>> >>>> Gyan >>>> >>>> On Thu, Apr 14, 2022 at 1:10 AM Ketan Talaulikar <[email protected]> >>>> wrote: >>>> >>>>> Hi Acee, >>>>> >>>>> Thanks a lot for your detailed review and your suggestions. We will be >>>>> incorporating them in the next update. >>>>> >>>>> Please also check inline below for further responses. >>>>> >>>>> >>>>> On Wed, Apr 13, 2022 at 10:39 PM Acee Lindem (acee) <[email protected]> >>>>> wrote: >>>>> >>>>>> Speaking as WG member and document shepherd: >>>>>> >>>>>> >>>>>> >>>>>> I support publication of this draft. IS-IS has had this capability >>>>>> for some time now and we need it in OSPF. The technical aspects of the >>>>>> draft are sound. >>>>>> >>>>>> >>>>>> >>>>>> One detail that I think needs to be added is the stub link metric >>>>>> corresponding to the link is not modified by acceptance of the reverse >>>>>> metric. At least this is my understanding and opinion. >>>>>> >>>>> >>>>> KT> That is correct. The draft talks about router links (thanks for >>>>> that suggestion) and does not cover stub links since there are no >>>>> neighbors >>>>> on those links to signal the RM in the first place. >>>>> >>>>> >>>>>> >>>>>> >>>>>> I also have some comments on the readability. I’ve attempted to >>>>>> correct these in the attached diff (there may be mistakes as I did this >>>>>> editing quickly). >>>>>> >>>>>> >>>>>> >>>>>> 1. I don’t like the “to itself” terminology. I know what it mean >>>>>> since I’ve seen both the OSPF and IS-IS presentations on the feature. >>>>>> This >>>>>> constitutes most of my suggested changes. >>>>>> 2. Avoid run-on sentences like the one at the end of section 2. >>>>>> 3. I don’t think “use case” should be hyphenated. >>>>>> >>>>>> KT> Ack to all of the above. >>>>> >>>>> >>>>>> >>>>>> 1. Should we really refer to “statically provisioned metrics” >>>>>> when in many case reference bandwidth is used? >>>>>> >>>>>> KT> Changed to "provisioned metric" to cover both scenarios where >>>>> metric value is specified or derived via specified reference bandwidth >>>>> configuration. >>>>> >>>>> Thanks, >>>>> Ketan >>>>> >>>>> >>>>> >>>>>> >>>>>> 1. >>>>>> 2. Some other editorial changes. >>>>>> >>>>>> >>>>>> >>>>>> Anyway, you can use your best judgement on these. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>> >>>>>> >>>>>> *From: *Lsr <[email protected]> on behalf of "Acee Lindem (acee)" >>>>>> <[email protected]> >>>>>> *Date: *Thursday, April 7, 2022 at 3:18 PM >>>>>> *To: *"[email protected]" <[email protected]> >>>>>> *Cc: *"[email protected]" < >>>>>> [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 >>>>> >>>> -- >>>> >>>> <http://www.verizon.com/> >>>> >>>> *Gyan Mishra* >>>> >>>> *Network Solutions A**rchitect * >>>> >>>> *Email [email protected] <[email protected]>* >>>> >>>> >>>> >>>> *M 301 502-1347* >>>> >>>> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *Email [email protected] <[email protected]>* >> >> >> >> *M 301 502-1347* >> >> -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
