Hi Acee/All,
I am not aware of any IPR that applies to this document.
Thanks,
Ketan
On Fri, Apr 8, 2022 at 12:51 AM Acee Lindem (acee) wrote:
> Authors,
>
>
>
> There are no IPR disclosures for this draft.
>
>
>
> Are you aware of any IPR that applies to draft-ietf-lsr-ip-flexalgo-04?
>
>
>
>
Hello All,
Following are some comments on this draft:
1) Is this draft about opening the use of all IGP Algorithms for IP (Algo)
Routing or intended to be specific to Flexible Algorithms (i.e. algo
128-255) alone. I think it is important to specify the scope unambiguously.
Perhaps it makes sense
Hi Peter,
Please check inline below.
On Mon, Apr 11, 2022 at 1:06 PM Peter Psenak wrote:
> Hi Ketan,
>
> please responses to some of your comments inline (##PP):
>
> On 11/04/2022 08:25, Ketan Talaulikar wrote:
> > Hello All,
> >
> > Following are some comm
Hi Peter,
Please check inline below with KT2. I am trimming everything other than the
one point of continuing debate.
> >
> > > 2) The relationship between the algo usage for IP FlexAlgo and
> other
> > > data planes (e.g. FlexAlgo with SR) is not very clear. There arise
> > >
>
> On 13/04/2022 06:00, Ketan Talaulikar wrote:
> > Hi Peter,
> >
> > Please check inline below with KT2. I am trimming everything other than
> > the one point of continuing debate.
> >
> > > >
> > > > 2) T
Hi Robert,
Please check inline below with KT4.
On Wed, Apr 13, 2022 at 1:31 PM Robert Raszuk wrote:
> Hi Ketan,
>
> > KT2> I see the primary use case for IP FlexAlgo (or another data plane)
>> > to be that the data plane is used by itself. In the (rare?) case where
>> > multiple data planes ar
n
On Wed, Apr 13, 2022 at 2:35 PM Peter Psenak wrote:
> Hi Ketan,
>
> please see inline (##PP4):
>
>
> On 13/04/2022 10:52, Ketan Talaulikar wrote:
> > Hi Peter,
> >
> > I will not press this point further if I am the only one that finds this
> > c
Hi Jeffrey,
Could you grep for RFC8042 in this draft and then let us know what more is
needed?
Thanks,
Ketan
On Wed, Apr 13, 2022 at 7:18 PM Jeffrey (Zhaohui) Zhang
wrote:
> Hi,
>
>
>
> I just noticed this draft, and I would like to refer to
> https://datatracker.ietf.org/doc/html/rfc8042 “OS
gt; and did not find it hence the comment ☹
>
> Sorry about that.
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar
> *Sent:* Wednesday, April 13, 2022 10:06 AM
> *To:* Jeffrey (Zhaohui) Zhang
> *Cc:* Acee Lindem (acee
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) wrote:
> Speaking as WG member and document shepherd:
>
>
>
> I supp
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
>
assertions from the document. It is
>> > sufficient to just say that the document enables the use of IGP
>> FlexAlgo
>> > for IP prefixes with native IP forwarding.
>>
>> ##PP
>> where do you see such assertion? Each flex-algo data-plane/app can be
>> deployed indep
ports the application Segment Routing with (SR) data planes - SR
> MPLS and SRv6.
> >
> > This document extends IGP Flex-Algorithm, so that it can be used
> > natively with IPv4 and IPv6 forwarding.
>
>
>
>
>
> Kind Regards
>
> Gyan
>
> Sent f
:09 AM Gyan Mishra wrote:
>
> Hi Ketan
>
> Welcome.
>
> Responses in-line
>
> Kind Regards
>
> Gyan
>
> On Thu, Apr 14, 2022 at 3:04 AM Ketan Talaulikar
> wrote:
>
>> Hi Gyan,
>>
>> Thanks for your review and feedback. Please check inline
This question is for Ketan as well…
>
> Thanks,
>
> Acee
>
>
>
>
>
> *From: *Lsr on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date: *Friday, April 15, 2022 at 10:38 PM
> *To: *Acee Lindem
> *Cc: *"lsr@ietf.org" , Ketan Talauli
38
> <https://datatracker.ietf.org/doc/html/rfc6138>]. In this
>case, the Reverse Metric can be used to discourage both outbound and
>inbound traffic without affecting the traffic of other IS-IS nodes on
>the LAN.
>
>
> Thanks
>
> Gyan
>
> On Sun, A
Hi Les,
Please check inline below.
On Tue, Apr 19, 2022 at 12:13 PM Les Ginsberg (ginsberg)
wrote:
> I support progressing this draft.
>
> However, I have some concerns about the current content – specifically the
> use cases – which I would like to see addressed before going to Last Call.
>
>
Hi Aijun,
Please check inline below for responses.
On Tue, Apr 19, 2022 at 1:00 PM Aijun Wang
wrote:
> Hi, All:
>
> I have the similar opinions as Les.
>
> Such mechanism is actually one maintenance tools and can’t be used to
> accomplish the metric auto adjustment, as that described in sectio
2.1,
> the draft is very easy to understand. By replacing it with the maintenance
> case, you’ll make the entire draft understandable.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Ketan Talaulikar
> *Date: *Tuesday, April 19, 2022 at 6:53 AM
> *To: *"Les Gin
ndicates the maximum
> value is (2^24-1)(corresponding to the “wide”metric).
>
>
>
> Considering that the only applicable scenarios is for maintenance, the
> introduction of H/U bit complexes its usage. It should be simplified.
>
>
>
>
>
> Best Regards
>
>
&g
Hi Gyan,
Please check inline below.
On Wed, Apr 20, 2022 at 8:21 AM Gyan Mishra wrote:
>
> I support publication of this draft.
>
> The revere metric concept used for maintenance work is similar to the BGP
> Graceful shutdown conceptually to de-prefer links to take traffic off the
> box.
>
> I
vior.
Thanks,
Ketan
On Thu, Apr 21, 2022 at 3:13 AM Acee Lindem (acee) wrote:
> Hi Ketan,
>
>
>
> *From: *Ketan Talaulikar
> *Date: *Sunday, April 17, 2022 at 1:03 PM
> *To: *Acee Lindem
> *Cc: *Gyan Mishra , "lsr@ietf.org" ,
> "draft-ietf-lsr-ip-flexa...@
Thanks Les for that clarification.
Gyan, + 1 to what Les said :-)
Thanks,
Ketan
On Thu, Apr 21, 2022 at 3:13 AM Les Ginsberg (ginsberg)
wrote:
> Gyan –
>
>
>
> While I don’t speak for Ketan, in regards to:
>
>
>
>
>
>
>
> Also maybe mention of OSPF multi instance RFC 6549 and any caveats relat
in RFC 8500. In fact, this draft is, IMO, cleaner.
>
>
>
> *From: *Aijun Wang
> *Date: *Wednesday, April 20, 2022 at 8:52 PM
> *To: *'Ketan Talaulikar'
> *Cc: *"Les Ginsberg (ginsberg)" , 'lsr' ,
> "draft-ietf-lsr-ospf-reverse-met...@ietf.org&
plementation doesn’t imply it is the best.
>
>
>
> Anyway, you can insist your direction.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Thursday,
ISIS due to some fundamental differences between the protocols. If
> you have worked out a solution to the LAN problem that is significantly
> better than the OSPF Two-Part Metric mechanism and one that leverages
> Reverse Metric, then I am eager to see it. Please provide the solution and
> the
Hi Matthew,
Thanks for your review and we've fixed all the nits identified by you in
the updated version posted below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-05
Thanks,
Ketan
On Wed, Apr 27, 2022 at 9:15 PM Matthew Bocci via Datatracker <
nore...@ietf.org> wro
the updates.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Thursday, April 28, 2022 2:23 AM
> *To:* Aijun Wang ; 'Acee Lindem (acee)' 40cisco...
ow if there is anything else that needs to be addressed or
updated in the draft.
Thanks,
Ketan
On Wed, Apr 20, 2022 at 12:18 PM Ketan Talaulikar
wrote:
> Hi Acee,
>
> Thanks for your inputs and we'll update the draft accordingly.
>
> Thanks,
> Ketan
>
>
> On Tue
nt.
>
> I am considering other general solution to accomplish the application
> scenarios of the reverse metric mechanism.
>
> Will try to write one draft when the thought has finalized.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
> *From:*
Hi Acee/All,
I am not aware of any IPR associated with this draft.
Thanks,
Ketan
On Thu, 5 May, 2022, 11:21 pm Acee Lindem (acee), wrote:
> Authors,
>
>
>
> There are no IPR disclosures for this draft.
>
>
>
> Are you aware of any IPR that applies to draft-ietf-lsr-ospf-l2bundles-03?
>
>
>
>
Hi Anoop,
Sure. We'll clarify in the next update.
Thanks,
Ketan
On Fri, 6 May, 2022, 11:35 pm Anoop Ghanwani, wrote:
> If I have router R1 connected to an L2 switch by an L2 bundle, and router
> R2 connected to that L2 switch by a single link, is it still OK to
> configure R1 to send L2 Bund
Hi Acee,
Thanks for your detailed review and we've incorporated all of the edits
suggested by you. They would reflect on the next update.
Please also check inline below for response.
On Mon, May 9, 2022 at 9:14 PM Acee Lindem (acee) wrote:
> Speaking as Document Shepherd and WG member:
>
>
>
#PP):
>
> On 11/04/2022 08:25, Ketan Talaulikar wrote:
> > Hello All,
> >
> > Following are some comments on this draft:
> >
> > 1) Is this draft about opening the use of all IGP Algorithms for IP
> > (Algo) Routing or intended to be specific to Flexible A
Thanks Peter and the changes look good to me.
Thanks,
Ketan
On Mon, May 16, 2022 at 3:25 PM Peter Psenak wrote:
> Hi Ketan,
>
>
> On 13/05/2022 15:32, Ketan Talaulikar wrote:
> > Hi Peter,
> >
> > Thanks for your updates to the draft and your responses below.
>
Hi Acee,
We've just posted an update of the draft that addresses the comments and
includes the feedback from the WGLC.
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-04
Thanks,
Ketan
On Sun, May 22, 2022 at 10:19 PM Acee Lindem (acee) wrote:
> All,
> The WG last call has
Hi Stewart & Acee,
Thanks for catching that and the pointer to the latest spec. This update
will reflect in the next version of the draft.
Thanks,
Ketan
On Sun, May 29, 2022 at 5:34 PM Acee Lindem (acee) wrote:
> Hi Stewart -
> Thanks for review. I agree we should update the reference and wil
the FR/client L2 adjacencies are in BGP-LS
> already per normal procedures (and the fact that you see client/reflector
> flag on both nodes & cluster ID allows you to derive the property of the
> adjacency) but the L1 mesh (if used) has no business in BGP-LS unless it
> forms IGP L1 adjacen
for
>
KT> The main sticking point for me here is that you have not allowed for
the BGP-LS Flood Reflection TLV to have support for sub-TLVs as is the case
with its underlying ISIS Flood Reflection TLV. It is a very minor thing
that can be easily fixed and I am unable to understand why thi
24, 2022 at 6:43 PM Ketan Talaulikar
> wrote:
>
>> Hi Tony,
>>
>> Please check inline below.
>>
>> On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda
>> wrote:
>>
>>> hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1
>>>
Hi All,
We have posted an update to this WG document:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-04
Most of the changes are editorial. The only content change is the
introduction of new "Route Types" to enable distinction between Type1/Type2
external and NSSA adve
Hello Authors,
I was pointed to your draft while looking around for some clarifications on
how information for a single object can be split across multiple TLVs in
ISIS.
Having gone through your document, I believe it is very useful and I am
glad to see that you have taken on this work.
While th
TLVs that aren’t in the catalog.
>
> What we’re trying to accomplish is to write some general rules that we all
> understand that apply uniformly across all TLVs that don’t specify their
> own overflow mechanisms.
>
> Does this work for you?
>
> Tony
>
>
> > On Jun 2
part of the fixed form
and hence the problem (unspecified keys) that I mentioned in my first email
on this thread does not arise. There are though, some TLVs, where the keys
remain unspecified and I strongly believe that (at least the most important
of those?) need to be tackled in this documen
e are existing RFCs that have already
> explicitly specified the use of multi-part-TLVs. These include:
>
>
>
> RFC 5307 SRLG TLV
>
> RFC 7981 Router Capability TLV
>
>
>
> Les
>
>
>
> *From:* Huzhibo
> *Sent:* Thursday, June 30, 2022 12:43 AM
&
Hi Les,
Please check inline below for some clarifications with KT2.
On Thu, Jun 30, 2022 at 10:57 PM Les Ginsberg (ginsberg)
wrote:
> Ketan –
>
>
>
> Inline.
>
>
>
> *From:* Ketan Talaulikar
> *Sent:* Thursday, June 30, 2022 10:12 AM
> *To:* Les Ginsberg (gin
o.
> However, this isn't required?
KT> Here the advertisement is in a separate LSA so the advertisement with
LSInfinity metric is not required. Not sure if I've got your question right
though ...
>
>
> See suggested edits attached.
KT> Ack.
Thanks,
Ketan
>
>
> T
Hello Acee/Chris,
We (authors) would like to request for early allocation of code points by
IANA for
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-05
More specifically for the suggested values in the following sections:
https://datatracker.ietf.org/doc/html/draft-iet
ll implementations today choose to send link ids all the time – no reason
> to force them to do so.
>
> And I could go on…
>
>
>
> Hopefully I have made my point.
>
KT> Thanks for the discussion. It shares the views of the two of us with
the WG and I'll let others in t
Hi Tony & Co-authors,
The introduction of the capabilities (at this stage) might be a challenge
given existing implementations that do multi-part TLVs and are shipping and
deployed. If this was intended mainly to aid debugging and for the operator
to evaluate the capabilities in the network, it mi
: Zhenbin Li
> Zhibo Hu
> Ketan Talaulikar
> Peter Psenak
> Filename: draft-ietf-lsr-ospfv3-srv6-extensions-06.txt
> Pages : 26
> Date: 2022-07-23
>
> Abstrac
Hello Authors,
I am sharing some comments on the latest version of this document since we
seem to have a packed agenda in LSR this time.
1) I notice that in the latest update of the draft, there is a big change
to start using LSInfinity for indicating prefix unreachability (similar
to draft-ppsen
Hello Authors,
Please find below my comments/suggestions on this draft. I am sharing them
upfront given the packed LSR agenda.
1) Sec 3 the rationale provided for not using the Inter-AS TE LSAs/TLVs is
not sound in my opinion. I would say that the TE encoding may not be
suitable for use in all de
having an explicit indication in addition to the
use of LSInfinity in draft-ppsenak. Perhaps a prefix attribute flag as was
already suggested to the authors of draft-ppsenak (
https://mailarchive.ietf.org/arch/msg/lsr/Q9wU3Bo1uzhPd5C7bT_WE7k_3JI/).
But certainly not the prefix originator as propose
hanks,
Ketan
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人:* Ketan Talaulikar [mailto:ketant.i...@gmail.com]
> *发送时间:* 2022年7月27日 17:45
> *收件人:* Aijun Wang
> *抄送:* draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; ls
> points.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom.
>
>
>
> *发件人:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *代表 *Ketan
> Talaulikar
> *发送时间:* 2022年7月27日 17:32
> *收件人:* draft-wang-lsr-stub-link-attribu...@ietf.org
&
Hello Authors,
Sharing some comments upfront on this draft given the packed LSR agenda.
1) There is currently no change in protocol encoding (see also further
comment), however, there are protocol procedures at the ABR being specified
using normative language. Specifically, the text related to th
e WG to the
> problem space – but the solution offered is not deployable. Given the long
> period of time during which this draft has been published and the many
> times it has been presented/discussed in the WG I think it is now time to
> say thank you to the authors for their work, but
Aijun, please correct me, if I am wrong here.
> See inline.
>
>
>
>
>
> *From: *Lsr on behalf of Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Date: *Wednesday, July 27, 2022 at 5:33 AM
> *To: *"draft-wang-lsr-stub-link-attribu...@ietf.org" <
> draf
r the draft, but at some point the WG needs
> to say we have done due diligence and the WG consensus is NOT to adopt the
> draft. The continued discussion of this draft consumes WG resources
> (including presentation slots) and diverts WG attention from other work.
>
>
>
>Les
he network simple and easy to
> operate.
>
KT> These things may not be coming out as well. Let me try to summarize on
a fresh thread.
Thanks,
Ketan
>
> Aijun Wang
> China Telecom
>
> On Jul 28, 2022, at 14:58, Ketan Talaulikar wrote:
>
>
> Hi Acee,
>
>
un Wang
> China Telecom
>
> On Jul 28, 2022, at 15:03, Ketan Talaulikar wrote:
>
>
> Hi Aijun,
>
> Similar to Les, I disagree with you on the use of Prefix TLV as an
> attribute of the "Stub Link". The reason is that this attribute is not
> required for the
Hi Aijun,
I am trying to summarize my understanding here just to make sure we are all
on the same page. There are also some suggestions on how we might be able
to make some progress here.
1) What "kind" of stub links is the draft proposing to address? (a)
Inter-AS links (this was the original use
ns a lot of additional unnecessary overhead and
> complexity. I think the WG should adopt UPA and not spend any more time on
> this discussion.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr on behalf of Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Date
Hi Acee,
I am not aware of any IPR for this document other than the one already
reported.
Thanks,
Ketan
On Fri, 29 Jul, 2022, 10:48 pm Acee Lindem (acee), wrote:
> Co-authors,
>
>
>
> Are you aware of any IPR that applies to
> draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?
>
>
>
> If so, has t
Hi Dirk,
Thanks for your review and please check inline below for my responses.
On Thu, Aug 11, 2022 at 7:10 PM Goethals, Dirk (Nokia - BE/Antwerp) <
dirk.goeth...@nokia.com> wrote:
> Hi authors,
>
>
>
> I’ve read draft-ietf-lsr-ospfv3-srv6-extensions-06, and have one comment.
>
>
>
> In chapte
Hi Chris/All,
I support the adoption of this document. It is a much-required
clarification and I hope this can be fast-tracked through the WG.
Thanks,
Ketan
On Mon, Aug 8, 2022 at 3:52 PM Christian Hopps wrote:
>
> Hi Folks,
>
> This begins a 2 week WG Adoption Call for the following draft:
>
Hi Chris/All,
I support the adoption of this document. It is a much-required
clarification and I hope this can be fast-tracked through the WG.
Thanks,
Ketan
On Mon, Aug 8, 2022 at 3:51 PM Christian Hopps wrote:
>
> Hi Folks,
>
> This begins a 2 week WG Adoption Call for the following draft:
>
Hi Dirk,
Please check inline below again with KT2 and I am trimming to limit to the
open discussion point.
On Thu, Aug 11, 2022 at 9:28 PM Goethals, Dirk (Nokia - BE/Antwerp) <
dirk.goeth...@nokia.com> wrote:
> KT> The Attached (A/LA) flag was used in RFC8666/8667 for the propagation
> of SRMS
Hi Yingzhen,
Thanks for your review and please check inline below for responses.
The changes as discussed below will be reflected in the upcoming update of
the draft.
On Wed, Aug 17, 2022 at 5:22 AM Yingzhen Qu wrote:
> I support progressing this draft.
>
> I have the following minor comments
Hello Acee/All,
There has not been any further comment/feedback on the point that Dirk
brought up in the thread below:
https://mailarchive.ietf.org/arch/msg/lsr/_4HcJEsteNQxjxuot1uLdoXeH6s/
I want to point out that not just the LA-flag, but also the P-flag is
required for propagation of the SRv6
Hi Acee,
Please check inline below.
On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee) wrote:
> Hi Ketan,
>
>
>
> *From: *Lsr on behalf of Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Date: *Wednesday, August 17, 2022 at 9:48 AM
> *To: *Acee Lindem
> *
ycast.
Thanks,
Ketan
On Wed, Aug 17, 2022 at 8:44 PM Acee Lindem (acee) wrote:
> Hi Ketan,
>
>
>
> *From: *Ketan Talaulikar
> *Date: *Wednesday, August 17, 2022 at 11:04 AM
> *To: *Acee Lindem
> *Cc: *lsr , "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org"
&g
Hi Shraddha,
Thanks for your detailed review and please check inline below for responses.
On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde wrote:
> Authors,
>
> OSPFv3 extensions for Srv6 is a useful draft and I support progressing
> this draft.
> I have below comments.
>
>
>
> 1. Add a sectio
> Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar
> *Sent:* Thursday, August 18, 2022 11:28 PM
> *To:* Shraddha Hegde
> *Cc:* Yingzhen Qu ; Acee Lindem (acee) 40cisco@dmarc.ietf.org>; lsr ;
> draft-ietf-lsr-ospfv3-srv6-extensi...@
Hi Dhruv,
Thanks for your review and feedback. Will incorporate your suggestions in
the upcoming update.
Thanks,
Ketan
On Mon, Aug 22, 2022 at 7:54 PM Dhruv Dhody wrote:
> Hi,
>
> I support WG LC. It is in good shape!
>
> It might be a good idea to include some text (perhaps in the appendix)
of the IETF.
>
> Title : OSPFv3 Extensions for SRv6
> Authors : Zhenbin Li
> Zhibo Hu
> Ketan Talaulikar
> Peter Psenak
> Filename: draft-ietf-lsr-ospfv3-srv6
2022 at 9:08 PM Acee Lindem (acee) wrote:
> Hi Ketan,
>
>
>
> *From: *Ketan Talaulikar
> *Date: *Wednesday, August 17, 2022 at 11:35 AM
> *To: *Acee Lindem
> *Cc: *lsr , "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org"
> , "Goethals, Dirk (Nokia
> -
ments pending to be
addressed.
Thanks,
Ketan
On Mon, Aug 22, 2022 at 10:22 AM Ketan Talaulikar
wrote:
> Hi Shraddha,
>
> Thanks for your response. Please check inline below with KT2 for some
> clarifications.
>
> We'll work on posting the update once this one remaining
Intra-Area-Prefix TLV
> in the E-Intra-Area-Prefix LSA (e.g., for algo 0). Can you please confirm?
>
>
>
> Yes. That is correct.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar
> *Sent:* Monday, August 22, 2022 10:23 AM
> *To:* Shra
Hi Dirk,
Thanks again for your review and confirmation.
Thanks,
Ketan
On Mon, Aug 29, 2022 at 4:31 PM Goethals, Dirk (Nokia - BE/Antwerp) <
dirk.goeth...@nokia.com> wrote:
> Hi Ketan,
>
> The update looks good to me.
>
> Thx,
>
> Dirk
>
>
>
> *From
Hi Acee/Chris,
Now that the WGLC is done for this document, would it be a good time to
request for early allocation for the pending item (OSPFv3 PrefixOption)?
Please refer:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-07#section-13.3
Thanks,
Ketan
On Wed, Aug 24,
Hi John,
Thanks for your detailed review and comments/suggestions. We've accepted
your editorial changes and please check inline for responses to your
comments.
We have also posted the updated version with these changes:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-06
ld be happier if the ambiguity were resolved somehow.
>
KT2> How about the following?
Implementations MAY provide a local configuration option to force BFD
operation only in
OSPF BFD strict-mode (i.e, adjacency will not come up unless BFD
session is established).
>
> Other
Hi John,
Thanks for your detailed review. We've incorporated the editorial changes
suggested by you. Please check inline below for responses.
An update with these changes has also been posted:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-06
On Thu, Sep 1, 2022 at 2:2
Hi John,
Thanks for your review.
I think it is a good idea to indicate and capture applicability as part of
the IANA registry. This will ensure compliance for sub-TLVs defined in the
future. An updated version of the draft that captures these changes is
posted for your and WG review/comments:
ht
need - to indicate the
applicability of a sub-TLV to L2 Bundle Member TLV.
I am open to your and WG's suggestions on this.
Thanks,
Ketan
On Fri, Sep 2, 2022 at 10:23 PM John Scudder wrote:
> Hi Ketan,
>
> Thanks for the update.
>
> > On Sep 2, 2022, at 9:16 AM, Ke
Hi John,
Thanks for your quick response and please check inline below for response
with KT2.
We've also posted an update with the changes discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-07
On Sat, Sep 3, 2022 at 1:03 AM John Scudder wrote:
> Hi Ketan,
er.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-07
On Sat, Sep 3, 2022 at 2:06 AM John Scudder wrote:
> Hi Ketan,
>
> My comments in line below.
>
> > On Sep 2, 2022, at 6:37 AM, Ketan Talaulikar
> wrote:
> >
> > Hi John,
> >
> > Please check i
Thanks John.
On Sat, Sep 3, 2022 at 11:31 PM John Scudder wrote:
> Thanks, Ketan. Enough tweaking :-), I’ve requested it move to IETF last
> call.
>
> —John
>
> > On Sep 3, 2022, at 5:03 AM, Ketan Talaulikar
> wrote:
> >
> >
> > [External Email. B
Thanks John.
On Sat, Sep 3, 2022 at 11:32 PM John Scudder wrote:
> LGTM. IETF LC requested.
>
> —John
>
> > On Sep 3, 2022, at 4:51 AM, Ketan Talaulikar
> wrote:
> >
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi John
ait for WG's input before making such
(feature creep) changes.
Thanks,
Ketan
On Sat, Sep 3, 2022 at 11:41 PM John Scudder wrote:
> > On Sep 3, 2022, at 4:46 AM, Ketan Talaulikar
> wrote:
> >
> > Hi John,
> >
> > Thanks again for your quick response.
&g
Hi John,
Please check inline below with KT for a quick clarification.
On Mon, Sep 5, 2022 at 8:39 PM John Scudder wrote:
> Hi Ketan,
>
> Seems like a good plan. Comments below.
>
> > On Sep 5, 2022, at 3:31 AM, Ketan Talaulikar
> wrote:
> >
> > I am personall
Hi All,
Thanks for the discussion and inputs. The plan proposed by John looks good
to me and we've just posted an update for the L2 Bundle member draft so it
can progress further without the IANA changes.
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-06
Thanks,
Ketan
On M
Hi Acee/Chris,
Any update on this?
Thanks,
Ketan
On Tue, Aug 30, 2022 at 9:23 PM Ketan Talaulikar
wrote:
> Hi Acee/Chris,
>
> Now that the WGLC is done for this document, would it be a good time to
> request for early allocation for the pending item (OSPFv3 PrefixOption)?
>
Hi Russ,
Thanks for your review.
Ketan
On Fri, Sep 9, 2022 at 7:24 PM Russ Housley via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Russ Housley
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documen
Hi Thomas,
Thanks a lot for your detailed review and your suggestions. We've
incorporated all of those changes and they will reflect in the next update
of the document.
Please check inline below for some responses.
On Fri, Sep 9, 2022 at 6:27 PM Thomas Fossati via Datatracker <
nore...@ietf.org
e early
> > codepoint allocations associated with this draft.
> >
> > Thanks,
> > Acee
> >
> > From: Ketan Talaulikar
> > Date: Tuesday, August 30, 2022 at 11:54 AM
> > To: Acee Lindem
> > Cc: Acee Lindem , lsr , "draft-ietf-lsr-
> &g
s draft is a work item of the Link State Routing WG of the IETF.
>
> Title : OSPFv3 Extensions for SRv6
> Authors : Zhenbin Li
> Zhibo Hu
> Ketan Talaulikar
> Peter Psen
Hi Martin,
Thanks for your review and please check inline below for responses.
The changes as discussed below will be updated in the next version of the
document.
On Fri, Sep 16, 2022 at 11:22 PM Acee Lindem (acee) wrote:
> Thanks Martin - Thanks for the Routing Directorate review!!
>
>
> On
1 - 100 of 442 matches
Mail list logo
