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*
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
