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

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
>> wrote:
>>
>>>
>>> Hi Ketan
>>>
>>> Welcome.
>>>
>>> Responses in-line
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>> On Thu, Apr 14, 2022 at 3:04 AM Ketan Talaulikar <[e-mail]>
>>> wrote:
>>>
>>>> Hi Gyan,
>>>>
>>>> Thanks for your review and feedback. Please check inline below.
>>>>
>>>>
>>>> On Thu, Apr 14, 2022 at 11:47 AM Gyan Mishra <[e-mail]>
>>>> 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 <
>>>>> [e-mail]> 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) <[e-mail]>
>>>>>> 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 <[e-mail]> on behalf of "Acee Lindem
>>>>>>> (acee)" <acee=[e-mail]>
>>>>>>> *Date: *Thursday, April 7, 2022 at 3:18 PM
>>>>>>> *To: *"[e-mail]" <[e-mail]>
>>>>>>> *Cc: *"[e-mail]" <
>>>>>>> [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
>>>>>>
>>>>> --
>>>>>
>>>>> <http://www.verizon.com/>
>>>>>
>>>>> *Gyan Mishra*
>>>>>
>>>>> *Network Solutions A**rchitect *
>>>>>
>>>>> *Email [e-mail] <[e-mail]>*
>>>>>
>>>>>
>>>>>
>>>>> *M 301 502-1347*
>>>>>
>>>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>> *Email [e-mail] <[e-mail]>*
>>>
>>>
>>>
>>> *M 301 502-1347*
>>>
>>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
>