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

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.

Kind Regards

Gyan

On Thu, Apr 14, 2022 at 1:10 AM Ketan Talaulikar <ketant.ietf@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) <acee@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-bounces@ietf.org> on behalf of "Acee Lindem (acee)"
>> <acee=40cisco.com@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-metric@ietf.org" <
>> draft-ietf-lsr-ospf-reverse-metric@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.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*

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