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

[Ketan Talaulikar <[e-mail]>]

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*
>
>