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 <hayabusa...@gmail.com> 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 <ketant.i...@gmail.com> > 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 <hayabusa...@gmail.com> >> wrote: >> >>> >>> Hi Ketan >>> >>> Welcome. >>> >>> Responses in-line >>> >>> Kind Regards >>> >>> Gyan >>> >>> On Thu, Apr 14, 2022 at 3:04 AM Ketan Talaulikar <ketant.i...@gmail.com> >>> wrote: >>> >>>> Hi Gyan, >>>> >>>> Thanks for your review and feedback. Please check inline below. >>>> >>>> >>>> On Thu, Apr 14, 2022 at 11:47 AM Gyan Mishra <hayabusa...@gmail.com> >>>> 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 < >>>>> ketant.i...@gmail.com> 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) <a...@cisco.com> >>>>>> 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 <lsr-boun...@ietf.org> on behalf of "Acee Lindem >>>>>>> (acee)" <acee=40cisco....@dmarc.ietf.org> >>>>>>> *Date: *Thursday, April 7, 2022 at 3:18 PM >>>>>>> *To: *"lsr@ietf.org" <lsr@ietf.org> >>>>>>> *Cc: *"draft-ietf-lsr-ospf-reverse-met...@ietf.org" < >>>>>>> draft-ietf-lsr-ospf-reverse-met...@ietf.org> >>>>>>> *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 >>>>>> Lsr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>> >>>>> -- >>>>> >>>>> <http://www.verizon.com/> >>>>> >>>>> *Gyan Mishra* >>>>> >>>>> *Network Solutions A**rchitect * >>>>> >>>>> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >>>>> >>>>> >>>>> >>>>> *M 301 502-1347* >>>>> >>>>> -- >>> >>> <http://www.verizon.com/> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions A**rchitect * >>> >>> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >>> >>> >>> >>> *M 301 502-1347* >>> >>> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
