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