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

[Ketan Talaulikar <[e-mail]>]

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.

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