Understood. Thanks for the clarification. Thanks Ketan
Gyan On Sun, Apr 17, 2022 at 11:10 PM Ketan Talaulikar <[email protected]> wrote: > Hi Gyan, > > As mentioned previously, the OSPF reverse metric mechanism is not > applicable for LAN (at least not proposed in this draft) since there is an > existing OSPF two-part metric mechanism RFC8042 for LANs. > > Thanks, > Ketan > > > On Mon, Apr 18, 2022 at 6:54 AM Gyan Mishra <[email protected]> wrote: > >> >> 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* >> >> -- <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
