Reviewer: Roni Even
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more
Chris -
Not trying to convince you of anything - just want to step back and summarize
where we are.
MP-TLV support has been explicitly allowed in multiple cases - and in these
cases no additional signaling has been specified i.e., all TLVs in the "set"
are encoded the same way they would be
Sending multi-part TLVs where the TLV type was not defined or talked about in the
standard as supporting MP TLV behavior is not "according to existing
standards". The fact that conforming implementations can be confused by this new
behavior should be proof enough of that. But, then we have
Martin Duke has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-10: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Chris -
Not sure what SE means but...one more significant point.
Multiple implementations have successfully deployed MP-TLV without any protocol
extensions. We did not require a new sub-TLV, a new flag, a sequence
number...we simply send additional information encoded according to existing
Dear LSR WG,
> MP-TLVs (explicit or implicit) are not an extension of the protocol -
they are completely consistent
> with the base operation of the protocol. I have always viewed lack of
support for MP-TLVs as an
> implementation limitation - not a gap in the protocol.
I don't agree with this
The IESG has approved the following document:
- 'OSPF BFD Strict-Mode'
(draft-ietf-lsr-ospf-bfd-strict-mode-10.txt) as Proposed Standard
This document is the product of the Link State Routing Working Group.
The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder.
A URL of
It sounds like you're talking about networks defined to work by SE not by
standards. I don't want to argue about this, so perhaps we can agree to
disagree.
Thanks,
Chris.
[as wg-member]
"Les Ginsberg (ginsberg)" writes:
Chris -
-Original Message-
From: Christian Hopps
Sent:
Chris -
> -Original Message-
> From: Christian Hopps
> Sent: Thursday, October 6, 2022 1:36 PM
> To: Peter Psenak (ppsenak)
> Cc: Christian Hopps ; Tony Li ; Les
> Ginsberg (ginsberg) ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for
Chris -
An example of what I refer to as "Do Not Apply" is "2 IIS Neighbors".
This is the old style (AKA narrow metric) neighbor advertisement which has a
fixed format and does not support sub-TLVs. It is impossible to advertise
information about the same neighbor in multiple TLVs (unless you
"Les Ginsberg (ginsberg)" writes:
With this in mind, Tony (as I have commented to you privately) your
table needs to be revised as there are some TLVs to which
“multi-part” simply doesn’t apply.
Those are what I believe we should refer to as "implicit single-part TLVs",
TLVS that it would
Peter Psenak writes:
Chris,
On 06/10/2022 18:34, Christian Hopps wrote:
Peter Psenak writes:
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the advertisements of the
MP-capability from other
All,
Please see the attached minutes from the LSR Interim on 9/21/2022 as long as
the Meetecho chat log. Thanks to Yingzhen Qu for taking them.
https://datatracker.ietf.org/meeting/interim-2022-lsr-01/materials/minutes-interim-2022-lsr-01-202209211000-00.txt
Here are the complete meeting
[posting to keep the WG in the loop]
Hi Ketan,
As discussed in the parallel thread with Amanda @ IANA, this looks good, except
that it would be a good idea to supply specific text for IANA to use as an
annotation on the registry. Amanda pointed to the Note on
Sooo, Tony asked that feedback on the table be unicast for now (which is wise)
- but I think there is one point that needs to be understood publicly - which
has to do with what is the meaning of "MP-TLV".
As per
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.html#section-3
On Thu, Oct 6, 2022 at 2:44 AM Ketan Talaulikar
wrote:
> Hi Martin,
>
> Thanks for your review and comments/feedback. Please check inline below
> for responses.
>
> We have also posted an update that includes the changes discussed below:
>
Gentlebeings,
The spreadsheet is NOT documenting implementations. It’s documenting what I
could find in the relevant specifications.
Tony
> On Oct 6, 2022, at 9:51 AM, Peter Psenak
> wrote:
>
> Chris,
>
> On 06/10/2022 18:34, Christian Hopps wrote:
>> Peter Psenak writes:
>>> Tony,
Chris,
On 06/10/2022 18:34, Christian Hopps wrote:
Peter Psenak writes:
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the advertisements of the
MP-capability from other routers - it would break
Peter Psenak writes:
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the advertisements of the
MP-capability from other routers - it would break existing networks. Even the
text in the MP-TLV draft
Hi Chris,
> On Oct 5, 2022, at 1:26 PM, Christian Hopps wrote:
>
> That is great news b/c it means we can fix those 3 unpublished TLV to be
> explicit multi-part. After fixing those 3 we are in a much friendly place of
> defining only future behavior/standard requirements without concern of
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : IGP Flexible Algorithm
Authors : Peter Psenak
Shraddha Hegde
Eric,
On 06/10/2022 16:45, Peter Psenak wrote:
### Sections 6.2 and 6.3
Suggest to repeat the TLV format from section 6.1.
##PP
is that really needed? :)
I can do if you insist.
I repeated the TLV format in section 6.2 and 6.3 as well as in section
7.2 and 7.3.
thanks,
Peter
Thanks Warren.
On Thu, Oct 6, 2022 at 8:33 PM Warren Kumari wrote:
>
>
>
>
> On Thu, Oct 06, 2022 at 3:37 AM, Ketan Talaulikar
> wrote:
>
>> Hi Warren,
>>
>> Thanks for your review and comments. Please check inline below for
>> response.
>>
>> On Thu, Oct 6, 2022 at 4:10 AM Warren Kumari via
Hi Alvaro,
We've posted an update to include the changes discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-10
I hope this addresses your DISCUSS and comments.
Thanks,
Ketan
On Thu, Oct 6, 2022 at 5:43 PM Ketan Talaulikar
wrote:
> Hi Alvaro,
>
> Please
On Thu, Oct 06, 2022 at 3:37 AM, Ketan Talaulikar
wrote:
> Hi Warren,
>
> Thanks for your review and comments. Please check inline below for
> response.
>
> On Thu, Oct 6, 2022 at 4:10 AM Warren Kumari via Datatracker ietf.org> wrote:
>
>> Warren Kumari has entered the following ballot position
Hi Rob,
We've posted an update to include the changes discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-10
Thanks,
Ketan
On Thu, Oct 6, 2022 at 5:28 PM Ketan Talaulikar
wrote:
> Hi Rob,
>
> Thanks for your review and comments/suggestions. Please check
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : OSPF Reverse Metric
Authors : Ketan Talaulikar
Peter Psenak
Hi John,
We've posted an update of the draft with the changes as per option 1 below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-09
Please let us know if there are any other concerns. Will also let the IANA
team know of this update on the parallel thread so they can also
Hi Eric,
thanks for your comments, please see inline (##PP):
On 06/10/2022 15:45, Éric Vyncke via Datatracker wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-lsr-flex-algo-24: No Objection
When responding, please keep the subject line intact and reply to all
email
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : Advertising Layer 2 Bundle Member Link Attributes in
OSPF
Authors : Ketan Talaulikar
Hi Rob,
We've posted an update that includes the changes discussed in the thread
below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-10
Thanks,
Ketan
On Thu, Oct 6, 2022 at 5:05 PM Ketan Talaulikar
wrote:
> Hi Rob,
>
> Thanks for your review and
Hi Eric,
We've posted an update that includes the changes discussed in the thread
below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-10
Thanks,
Ketan
On Wed, Oct 5, 2022 at 12:37 PM Ketan Talaulikar
wrote:
> Hi Eric,
>
> Thanks for your quick response and please
A new version (-12) has been submitted for
draft-ietf-lsr-pce-discovery-security-support:
https://www.ietf.org/archive/id/draft-ietf-lsr-pce-discovery-security-support-12.txt
Sub state has been changed to AD Followup from Revised ID Needed
The IETF datatracker page for this Internet-Draft
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : IGP extension for PCEP security capability support in
PCE discovery
Authors : Diego R. Lopez
Thanks for the review, Rich. One tiny nit, mostly for the authors:
> On Oct 3, 2022, at 12:23 PM, Rich Salz via Datatracker
> wrote:
>
> s/could be in most extreme case/could be in THE most extreme case/
Please don’t put “the” in all caps when you do the edit. Even though there’s no
formal
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : OSPF BFD Strict-Mode
Authors : Ketan Talaulikar
Peter Psenak
IESG state changed:
New State: IESG Evaluation::Revised I-D Needed
(The previous state was IESG Evaluation)
Datatracker URL:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/
___
Lsr mailing list
Lsr@ietf.org
Hi Ketan, Alvaro,
From: Ketan Talaulikar
Date: Thursday, October 6, 2022 at 8:10 AM
To: Alvaro Retana
Cc: Martin Duke , "lsr@ietf.org" ,
Christian Hopps , Acee Lindem ,
"lsr-cha...@ietf.org" , The IESG ,
"draft-ietf-lsr-ospf-reverse-met...@ietf.org"
Subject: Re: [Lsr] Martin Duke's Discuss
Éric Vyncke has entered the following ballot position for
draft-ietf-lsr-flex-algo-24: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Dhruv,
Thank you for the quick turnaround.
I sincerely hope that my review has helped to improve (the already good)
document ;-)
Cheers
-éric
From: Dhruv Dhody
Date: Thursday, 6 October 2022 at 15:07
To: Eric Vyncke
Cc: The IESG ,
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org"
Wow!
I didn't expect you to go to that much trouble just to make me happy, but
that all looks great to me.
Remind me that I owe y'all a frosty beverage in London (assuming you are
going)
Thank you all again,
W
On Thu, Oct 6 2022 at 9:05 AM, Dhruv Dhody wrote:
> Hi Warren,
>
> Thanks for
Hi Ketan,
Thanks for the analysis. A few comments below.
> On Oct 6, 2022, at 8:30 AM, Ketan Talaulikar wrote:
>
> Hi John/Lars,
>
> I hope this topic can be discussed in the upcoming telechat to conclude on
> the option to be adopted.
>
> To make it easier, let me provide a pointer to the
Hi John,
Disclaimer is removed from working copy!
Thanks!
Dhruv
On Wed, Oct 5, 2022 at 11:51 PM John Scudder wrote:
> Silly me,
>
> > On Oct 5, 2022, at 2:17 PM, John Scudder wrote:
> >
> > see that warning from idnits pretty often too, I don’t know what
> triggers it,
>
> … it’s right
Hi Eric,
Thanks for your review. The working copy is at -
TXT - https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-
lsr-pce-discovery-security-support-12.txt
DIFF - https://www.ietf.org/rfcdiff?url1=draft-ietf-lsr-pce-discovery-
Hi Warren,
Thanks for your review. Apologies for making you sad (we definitely
don't want that :)! How about this text instead of removing ->
6. Management Considerations
Manageability considerations for PCE Discovery are addressed in
Section 4.10 of [RFC4674] and Section 9 of [RFC5088]
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the
advertisements of the MP-capability from other routers - it would break
existing networks. Even the text in the MP-TLV draft does not suggest
that to
Hi John/Lars,
I hope this topic can be discussed in the upcoming telechat to conclude on
the option to be adopted.
To make it easier, let me provide a pointer to the text for each inline
below. I am not sure that I understand option 3 very well.
On Wed, Oct 5, 2022 at 9:42 PM John Scudder
Hi Alvaro,
Please check inline with KT3 for response.
On Thu, Oct 6, 2022 at 5:29 PM Alvaro Retana wrote:
> On October 6, 2022 at 7:44:51 AM, Ketan Talaulikar wrote:
>
>
> Ketan:
>
>
> > > > > (1) The main behavior in this document (using the reverse metric)
> is
> > > > > covered in the
Hi Alvaro,
Please check inline below for response with KT2.
On Thu, Oct 6, 2022 at 4:42 PM Alvaro Retana wrote:
> On October 6, 2022 at 5:44:57 AM, Ketan Talaulikar wrote:
>
>
> Ketan:
>
> Hi!
>
>
> ...
> > KT> Added text in the security considerations that cover this issue as
> well
> > as a
On October 6, 2022 at 7:44:51 AM, Ketan Talaulikar wrote:
Ketan:
> > > > (1) The main behavior in this document (using the reverse metric) is
> > > > covered in the following sentences:
> > > >
> > > > §6:
> > > > A router receiving a Hello packet from its neighbor that contains the
> > > >
Hi Rob,
Thanks for your review and comments/suggestions. Please check inline below
for responses.
Will update these changes (and further changes, if required) in the next
version once we conclude.
On Thu, Oct 6, 2022 at 4:20 PM Robert Wilton via Datatracker <
nore...@ietf.org> wrote:
> Robert
Hi Erik,
please see inline:
On 06/10/2022 02:32, Erik Kline via Datatracker wrote:
Erik Kline has entered the following ballot position for
draft-ietf-lsr-flex-algo-24: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC
Thanks Ketan!
On October 6, 2022 at 7:25:06 AM, Ketan Talaulikar (ketant.i...@gmail.com)
wrote:
Hi Alvaro,
Thanks for your review and comment.
I agree that there is a need to cover the part about the info from this new
TLV going into the BGP-LS TLV specified in RFC9085. Have added a section to
On October 6, 2022 at 6:58:18 AM, Peter Psenak wrote:
Peter:
...
> > (1) The text above instructs implementations of [RFC8667] and
> > [RFC8665] to stop advertising the specific Flex-Algorithm value, but
> > those RFCs (if I remember correctly) don't say anything about *not*
> > advertising
Hi Peter,
Thanks. I think that John has already followed up and flagged the IPR, so
probably nothing more that needs to be done from your side on that.
Thanks,
Rob
> -Original Message-
> From: Peter Psenak
> Sent: 06 October 2022 12:33
> To: Rob Wilton (rwilton) ; The IESG
> Cc:
Hi Alvaro,
Thanks for your quick response and please check inline below with KT2 for
response.
On Thu, Oct 6, 2022 at 4:27 PM Alvaro Retana wrote:
> On October 6, 2022 at 5:46:59 AM, Ketan Talaulikar wrote:
>
> Ketan:
>
> Hi!
>
>
> ...
> > > (1) The main behavior in this document (using the
Hi Rob,
Thanks for your review and comments/suggestions. Please check inline below
for responses.
The changes as discussed will reflect in the next update of this document.
On Thu, Oct 6, 2022 at 4:44 PM Robert Wilton via Datatracker <
nore...@ietf.org> wrote:
> Robert Wilton has entered the
Hi Warren,
please see inline:
On 05/10/2022 23:51, Warren Kumari via Datatracker wrote:
Warren Kumari has entered the following ballot position for
draft-ietf-lsr-flex-algo-24: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the
Hi Robert,
please see inline:
On 05/10/2022 18:12, Robert Wilton via Datatracker wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-flex-algo-24: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the
Hi Alvaro,
Thanks for your review and comment.
I agree that there is a need to cover the part about the info from this new
TLV going into the BGP-LS TLV specified in RFC9085. Have added a section to
cover this. Also marking "updates" RFC9085 based on your suggestion.
We have posted an update
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : Advertising Layer 2 Bundle Member Link Attributes in
OSPF
Authors : Ketan Talaulikar
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-bfd-strict-mode-09: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
On October 6, 2022 at 5:44:57 AM, Ketan Talaulikar wrote:
Ketan:
Hi!
...
> KT> Added text in the security considerations that cover this issue as well
> as a proposed mitigation. Please let us know if that works.
This is the text that you added:
A router that is misbehaving or
Alvaro,
please see inline (##PP2)
On 06/10/2022 02:30, Alvaro Retana wrote:
On October 5, 2022 at 12:02:30 PM, Peter Psenak wrote:
Peter:
Hi!
...
(1) When is a router's participation in a particular Flex-Algorithm
advertised?
...
Presumably, the operator configures support for a
On October 6, 2022 at 5:46:59 AM, Ketan Talaulikar wrote:
Ketan:
Hi!
...
> > (1) The main behavior in this document (using the reverse metric) is
> > covered in the following sentences:
> >
> > §6:
> > A router receiving a Hello packet from its neighbor that contains the
> > Reverse Metric TLV
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Ketan
As always, thank you for your prompt reply and actions.
Very much appreciated
-éric
From: Ketan Talaulikar
Date: Thursday, 6 October 2022 at 11:42
To: Eric Vyncke
Cc: The IESG , "draft-ietf-lsr-ospf-reverse-met...@ietf.org"
, "lsr-cha...@ietf.org"
, "lsr@ietf.org" ,
Hi Alvaro,
Thanks for your review and comments/suggestions. Please check inline below
for responses.
We have posted an update which includes the changes as discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-09
On Thu, Oct 6, 2022 at 6:21 AM Alvaro Retana
Hi Martin,
Thanks for your review and comments/feedback. Please check inline below for
responses.
We have also posted an update that includes the changes discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-09
On Thu, Oct 6, 2022 at 5:56 AM Martin Duke via
Hi Warren,
Thanks for your review and your feedback. I agree that while this is a
useful capability for specific deployments (especially costing out links in
both directions), it does need to be used carefully. I believe the document
does also describe the challenges involved with the use of this
Hi Eric,
Thanks for your review and comments/suggestions. Please check inline below
for responses.
The updates as discussed below have been posted in the latest version:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-09
On Wed, Oct 5, 2022 at 8:42 PM Éric Vyncke via
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : OSPF Reverse Metric
Authors : Ketan Talaulikar
Peter Psenak
Hi Warren,
Thanks for your review and comments. Please check inline below for response.
On Thu, Oct 6, 2022 at 4:10 AM Warren Kumari via Datatracker <
nore...@ietf.org> wrote:
> Warren Kumari has entered the following ballot position for
> draft-ietf-lsr-ospf-bfd-strict-mode-09: Yes
>
> When
Hi Peter,
I support this "update" - not sure if it qualifies as a "clarification".
Also, this obviously is doable only when the network has migrated to use
only Extended LSAs (i.e., legacy LSAs are removed) as indicated in
https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1
Thanks,
Ketan
74 matches
Mail list logo
