Re: [Lsr] Genart last call review of draft-ietf-lsr-ospf-bfd-strict-mode-07

[Ketan Talaulikar]

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 documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-lsr-ospf-bfd-strict-mode-07
> Reviewer: Russ Housley
> Review Date: 2022-09-09
> IETF LC End Date: 2022-09-20
> IESG Telechat date: unknown
>
>
> Summary: Ready
>
>
> Major Concerns: None
>
>
> Minor Concerns: None
>
> None:  The document is well written.  It was easy to review.
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request for early allocation for pending IANA allocation for draft-ietf-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar]

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)?
>
> Please refer:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-07#section-13.3
>
> Thanks,
> Ketan
>
> On Wed, Aug 24, 2022 at 12:11 AM Acee Lindem (acee) 
> wrote:
>
>> The Working Group Last Call (WGLC) has completed. There is more than
>> sufficient support for publication. As result of the WGLC discussion, there
>> have been some changes and these reflected in the -07 version.
>>
>>
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-07
>>
>>
>>
>> Please review the changes resulting from the WGLC discussion. Note that
>> the locator TLV will now use the PrefixOptions field common to other OSPFv3
>> LSAs advertising prefixes and will contain the Anycast (AC-bit). This
>> change is reflected in sections 6 and 7.1.
>>
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>
>> *From: *Lsr  on behalf of "Acee Lindem (acee)"
>> 
>> *Date: *Friday, July 29, 2022 at 1:18 PM
>> *To: *lsr 
>> *Cc: *"draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" <
>> draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>
>> *Subject: *[Lsr] Working Group Last Call for "OSPFv3 Extensions for
>> SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>>
>>
>>
>> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
>> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
>> extra week is to account for PIST (Post-IETF Stress Syndrome). The
>> corresponding IS-IS draft is already on the RFC Queue and there are
>> implementations.
>>
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Acee & Chris
>>
>>
>>
>>
>>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[Ketan Talaulikar]

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 Mon, Sep 12, 2022 at 8:50 PM tom petch  wrote:

> From: John Scudder 
> Sent: 12 September 2022 13:47
>
> Hi Tom,
>
> Needless (?) to say, I’m sympathetic with your position, and thanks for
> bringing up the parallel case. I take it however, that you aren’t taking
> the position that this reorganization/restructuring/call it what you will
> needs to be done by draft-ietf-lsr-ospf-l2bundles, though? Right now it
> looks to me as though there’s not consensus that it *should* be done in
> draft-ietf-lsr-ospf-l2bundles, which suggests to me that,
>
> - We should ask Ketan to revert to the version where the registry is left
> untouched (the “nothing” option),
> - We should then send draft-ietf-lsr-ospf-l2bundles for IETF LC and
> proceed with the publication process, and concurrently,
> - Someone who sees value in reorganizing the registry should write a
> standalone draft to do that, and propose it as a WG draft.
>
> Any objection to that approach?
>
> 
>
> That sounds like a good plan,
>
> Tom Petch
>
> Thanks,
>
> —John
>
> > On Sep 12, 2022, at 5:33 AM, tom petch  wrote:
> >
> > From: Lsr  on behalf of John Scudder  40juniper@dmarc.ietf.org>
> > Sent: 06 September 2022 22:04
> >
> >> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee)  wrote:
> >>
> >>   I guess if we do decide to either abandon the reorganization
> suggestion altogether, or to pursue it as a separate draft, then
> draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of
> listing restrictions in their own subsections of the main spec, do you
> agree? Recall that we got here (in part) because it seemed strange to me to
> update the registry to list some restrictions, but not all of them.
> >>
> >> [ACEE] This would be my choice except I wouldn't add the "L2 Member
> Bundle Attributes" restriction to the IANA registry unless we do it for all
> the Sub-TLVs as you suggest.
> >
> > We agree; that was what I meant. All or nothing, either do the whole
> reorganization (or whatever you want to call it) or back out the 05 change
> to the IANA section and just roll with what was in 04 and earlier. Halfway
> doesn’t make a lot of sense to me.
> >
> > 
> > All; you have to do it sometime, better sooner than later.
> >
> > I see a close parallel with MPLS which got itself into a tangle,
> attempts to clarify were rebuffed until eventually the problems were just
> too great and the work was done.
> >
> > Look at the TLVs registry in the IANA Multiprotocol Label Switching
> Architecture (MPLS) Group.  I think that you need a strong reason not to
> adopt a similar approach (if only for users who use MPLS as well as OSPF).
> No need for ten columns, just a structured approach.
> >
> > It took a lot of detailed review to get it right - Loa knows that well -
> but I believe that the effort was worth it.
> >
> > Tom Petch
> >
> > —John
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-ietf-lsr-ospf-l2bundles-06.txt

[internet-drafts]

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
  Peter Psenak
  Filename: draft-ietf-lsr-ospf-l2bundles-06.txt
  Pages   : 10
  Date: 2022-09-12

Abstract:
   There are deployments where the Layer 3 (L3) interface on which OSPF
   operates is a Layer 2 (L2) interface bundle.  Existing OSPF
   advertisements only support advertising link attributes of the Layer
   3 interface.  If entities external to OSPF wish to control traffic
   flows on the individual physical links which comprise the Layer 2
   interface bundle, link attribute information for the bundle members
   is required.

   This document defines the protocol extensions for OSPF to advertise
   the link attributes of L2 bundle members.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-l2bundles-06


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IPR Disclosure Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-lsr-isis-flood-reflection

[IETF Secretariat]

Dear Tony Przygienda, Chris Bowers, Yiu Lee, Alankar Sharma, Russ White:


An IPR disclosure that pertains to your Internet-Draft entitled "IS-IS Flood
Reflection" (draft-ietf-lsr-isis-flood-reflection) was submitted to the IETF
Secretariat on 2022-09-12 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/5807/history/). The title of the IPR
disclosure is "Juniper Networks, Inc.'s Statement about IPR related to
draft-ietf-lsr-isis-flood-reflection"


Thank you

IETF Secretariat


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] [Errata Verified] RFC3277 (7127)

[RFC Errata System]

The following errata report has been verified for RFC3277,
"Intermediate System to Intermediate System (IS-IS) Transient Blackhole 
Avoidance". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7127

--
Status: Verified
Type: Editorial

Reported by: John Scudder 
Date Reported: 2022-09-12
Verified by: Alvaro Retana (IESG)

Section: 2

Original Text
-
   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded routers LSP to be
   used.


Corrected Text
--
   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded router's LSP to be
   used.


Notes
-
"reloaded router's" should be possessive singular.

--
RFC3277 (draft-ietf-isis-transient-02)
--
Title   : Intermediate System to Intermediate System (IS-IS) 
Transient Blackhole Avoidance
Publication Date: April 2002
Author(s)   : D. McPherson
Category: INFORMATIONAL
Source  : IS-IS for IP Internets
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-flex-algo-20

[Acee Lindem (acee)]

Thanks John - I the changes in -21 and -22 improve the specification. 
Acee

On 9/12/22, 8:41 AM, "Lsr on behalf of John Scudder"  wrote:

Hi Peter,

Thanks. I’ve requested IETF LC.

—John

> On Sep 12, 2022, at 7:36 AM, Peter Psenak  wrote:
> 
> 
> Hi John,
> 
> please see inline (##PP2)
> 
> On 09/09/2022 17:29, John Scudder wrote:
>> Hi Peter,
>> 
>> Thanks for your reply and for the ping.
>> 
>> Where necessary I’ve replied in line below. I’ve snipped any points that
>> are agreed and don’t need further discussion. I’ve also reviewed the -21
>> diffs, basically LGTM. It looks like you missed a few of the nits, I
>> don’t know if this was by choice or oversight. I’ve attached an edited
>> version of -21 that captures the remaining ones, plus a few new ones I
>> noticed. You can diff if you want to pick those up for inclusion in -22.
> 
> ##PP2
> I fixed all nits, hopefully.
> 
>> 
>>> On Aug 31, 2022, at 10:23 AM, Peter Psenak 
 wrote:
>>> 
>>> [External Email. Be cautious of content]
>>> 
>>> 
>>> Hi John,
>>> 
>>> thanks a lot for the thorough review.
>>> 
>>> I incorporated all your edits and almost all of your comments.
>>> 
>>> For the few that I have not, please see inline (loop for ##PP):
>> 
>> [snip]
>> 
  Any change in the Flex-Algorithm definition may result in 
temporary
  disruption of traffic that is forwarded based on such 
Flex-Algorithm
  paths.  The impact is similar to any other event that requires
  network-wide convergence.
 +
 +jgs: IMO this would merit discussion in the Operational Considerations
 +section.  In particular, is there any advice regarding how to
 +stage/sequence FAD config changes in order to minimize disruption?
>>> 
>>> ##PP
>>> I don't really see much to add here. FAD changes the constraints used
>>> during the algo specific SPF and as such any change in it requires all
>>> routers to recompute the entire topology. In terms of the order of
>>> changes, I don't see why that would be significant and why someone would
>>> not want to advertise all changes at once if there are any multiple
>>> changes in the FAD.
>> 
>> I take your point, thanks. I guess about the most that you could say in
>> Operational Considerations would be something like
>> 
>> ---
>> 15.X  FAD Changes
>> 
>> As [Section 5.3] notes, a change in the Flex-Algorithm definition may
>> require network-wide SPF recomputation and network reconvergence. This
>> potential for disruption should be taken into consideration when
>> planning and making changes to the FAD.
> 
> ##PP2
> Added above to the Operational Consideration section.
> 
>> ---
>> 
>> Obvs, re-word as appropriate. IMHO it's worth elevating in the O.C.
>> section even if only briefly, but I don’t insist.
>> 
>> [snip]
>> 
 +jgs: Are "sender" and "receiver" sufficiently clear to OSPF 
practitioners
 +that there would be no ambiguity? I can think of two different ways
 +to read them -- one is that the "sender" is the router that
 +originates the LSA, and the "receiver" is any router that processes
 +the LSA. I think that's what you mean. The other, pedantic, reading,
 +is the "sender" is any router that puts the LSA on the wire, and the
 +"receiver" is any router that takes the LSA from the wire, so anyone
 +participating in flooding would be both a "sender" and a "receiver"
 +at times.
 +
 +If this is how people write OSPF specs and talk about OSPF, fine.
 +But if there are more precise terms than "sender" and "receiver" in
 +use, it would be nice to use them.
>>> 
>>> ##PP
>>> send/receive is the standard term used, e.g
>>> 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8665*section-5__;Iw!!NEt6yMaO-gk!HAdyT2s3c5I_fktGSY3YPuQdVeF95m5Yb-utZWsGn9214bNEm1SkQ1dDgtbTL2tEJz4kJBwXudGrWyHF3P9zB8IEVqDz$
>> 

>>> 
>>> I can replace sender with originator, if you prefer, but receiver would
>>> remain.
>> 
>> As you prefer. It’s not a big deal. I agree, by the way, that receiver
>> is unambiguous.
> 
> ##PP
> replaced sender with originator.
> 
>> 
>> [snip]
>> 
 
 @@ -1194,15 +1258,36 @@
|   
|
+-TLVs 
-+
| 

Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[tom petch]

From: John Scudder 
Sent: 12 September 2022 13:47

Hi Tom,

Needless (?) to say, I’m sympathetic with your position, and thanks for 
bringing up the parallel case. I take it however, that you aren’t taking the 
position that this reorganization/restructuring/call it what you will needs to 
be done by draft-ietf-lsr-ospf-l2bundles, though? Right now it looks to me as 
though there’s not consensus that it *should* be done in 
draft-ietf-lsr-ospf-l2bundles, which suggests to me that,

- We should ask Ketan to revert to the version where the registry is left 
untouched (the “nothing” option),
- We should then send draft-ietf-lsr-ospf-l2bundles for IETF LC and proceed 
with the publication process, and concurrently,
- Someone who sees value in reorganizing the registry should write a standalone 
draft to do that, and propose it as a WG draft.

Any objection to that approach?



That sounds like a good plan,

Tom Petch

Thanks,

—John

> On Sep 12, 2022, at 5:33 AM, tom petch  wrote:
>
> From: Lsr  on behalf of John Scudder 
> 
> Sent: 06 September 2022 22:04
>
>> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee)  wrote:
>>
>>   I guess if we do decide to either abandon the reorganization suggestion 
>> altogether, or to pursue it as a separate draft, then 
>> draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of 
>> listing restrictions in their own subsections of the main spec, do you 
>> agree? Recall that we got here (in part) because it seemed strange to me to 
>> update the registry to list some restrictions, but not all of them.
>>
>> [ACEE] This would be my choice except I wouldn't add the "L2 Member Bundle 
>> Attributes" restriction to the IANA registry unless we do it for all the 
>> Sub-TLVs as you suggest.
>
> We agree; that was what I meant. All or nothing, either do the whole 
> reorganization (or whatever you want to call it) or back out the 05 change to 
> the IANA section and just roll with what was in 04 and earlier. Halfway 
> doesn’t make a lot of sense to me.
>
> 
> All; you have to do it sometime, better sooner than later.
>
> I see a close parallel with MPLS which got itself into a tangle, attempts to 
> clarify were rebuffed until eventually the problems were just too great and 
> the work was done.
>
> Look at the TLVs registry in the IANA Multiprotocol Label Switching 
> Architecture (MPLS) Group.  I think that you need a strong reason not to 
> adopt a similar approach (if only for users who use MPLS as well as OSPF).  
> No need for ten columns, just a structured approach.
>
> It took a lot of detailed review to get it right - Loa knows that well - but 
> I believe that the effort was worth it.
>
> Tom Petch
>
> —John


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Last Call: (IGP Flexible Algorithm) to Proposed Standard

[The IESG]

The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'IGP Flexible Algorithm'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2022-09-26. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   IGP protocols traditionally compute best paths over the network based
   on the IGP metric assigned to the links.  Many network deployments
   use RSVP-TE based or Segment Routing based Traffic Engineering to
   steer traffic over a path that is computed using different metrics or
   constraints than the shortest IGP path.  This document specifies a
   solution that allows IGPs themselves to compute constraint-based
   paths over the network.  This document also specifies a way of using
   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
   along the constraint-based paths.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/


The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3248/
   https://datatracker.ietf.org/ipr/3910/






___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi Henk,

> My point was: multipart TLVs exist today, before the introduction of the
> capability advertisement. So when you look at a LSPDB, you still don't know 
> for
> sure which routers support multipart TLVs. Some might, but don't advertise it.
> Because their software was written before the new capability existed.


True, but irrelevant. The point is that if a router does advertise the 
capability, then you can reasonably infer that it is ready to receive 
multi-part TLVs.


> I hope not. And I will oppose those attempts too.


Example: MPLS MNA is coming. It’s a bundle of independent network actions, plus 
user defined actions. The MPLS WG is going to need a capability for each 
action. I expect that they will come here (LSR) and ask.


>> we still do not have an effective management plane and
>> continue to stuff things into the LSDB that belong in the management plane.
> 
> Yes. But that does not make it an excuse to put just anything in the LSPDB.


That’s what we’ve been doing for decades.

Yes, I’m advocate for putting things elsewhere, but that proposal has met with 
crickets.  You don’t get it both ways: no capabilities in the protocol and 
nowhere else does not work.

If the IGP is not a dump truck, then what else is?


> I've seen you in this work-group as someone who tried to keep things out of
> IS-IS that don't belong there. I am surprised to see you want this capability 
> in.


Because the thought of trying to deploy this capability at scale without this 
attribute seems impossible. Consider the case of Tier 1 providers who have 
large IS-IS deployments. Are you really going to evaluate 2000+ nodes without 
some kind of help?


>> The entire definition of a Flex Algo topology constraint should be
>> in the management plane.
> 
> Sure. But at least the routers do make route-calculation decisions based on
> that information.


And the routers will do computations based on the multi-part TLVs.  One level 
of indirection for a capability does not seem extreme.


>> That's not an excuse for not trying to do a good job now.
> 
> That is the whole question. This capability is adding 2 more octets to LSPs..
> Is that worth it?


Yes.


> What if indeed a few dozen drafts will follow to advertise
> more of these capabilities?


They are coming regardless.


> Should we define a new top-level TLV for "feature/software support 
> capability"?


No, since duplicating an existing TLV is wasteful of TLV code points. The 
current capability TLV is both necessary and sufficient.


> Not whether something is configured or not (as does the router-capability 
> TLV),
> but whether a router's software has that capability to begin with.
> Or should we define a new variable-length bitmask sub-TLV for the existing 
> router
> capability TLV. Where every bit indicates another piece of software the router
> supports?


That’s coming. See above.


> Regardless whether we do that or not, this discussion maybe should be done
> outside the multipart TLV  discussion. Maybe another draft should be written
> about these software-capabilities in general?


Please feel free.  My proposal was shot down.

T

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Editorial Errata Reported] RFC3277 (7127)

[Acee Lindem (acee)]

Hi John, 
Agree - this can go straight to verified. 
Thanks,
Acee

On 9/12/22, 8:54 AM, "Lsr on behalf of RFC Errata System" 
 wrote:

The following errata report has been submitted for RFC3277,
"Intermediate System to Intermediate System (IS-IS) Transient Blackhole 
Avoidance".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7127

--
Type: Editorial
Reported by: John Scudder 

Section: 2

Original Text
-
   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded routers LSP to be
   used.


Corrected Text
--
   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded router's LSP to be
   used.


Notes
-
"reloaded router's" should be possessive singular.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC3277 (draft-ietf-isis-transient-02)
--
Title   : Intermediate System to Intermediate System (IS-IS) 
Transient Blackhole Avoidance
Publication Date: April 2002
Author(s)   : D. McPherson
Category: INFORMATIONAL
Source  : IS-IS for IP Internets
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] [Editorial Errata Reported] RFC3277 (7127)

[RFC Errata System]

The following errata report has been submitted for RFC3277,
"Intermediate System to Intermediate System (IS-IS) Transient Blackhole 
Avoidance".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7127

--
Type: Editorial
Reported by: John Scudder 

Section: 2

Original Text
-
   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded routers LSP to be
   used.


Corrected Text
--
   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded router's LSP to be
   used.


Notes
-
"reloaded router's" should be possessive singular.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC3277 (draft-ietf-isis-transient-02)
--
Title   : Intermediate System to Intermediate System (IS-IS) 
Transient Blackhole Avoidance
Publication Date: April 2002
Author(s)   : D. McPherson
Category: INFORMATIONAL
Source  : IS-IS for IP Internets
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[John Scudder]

Hi Tom,

Needless (?) to say, I’m sympathetic with your position, and thanks for 
bringing up the parallel case. I take it however, that you aren’t taking the 
position that this reorganization/restructuring/call it what you will needs to 
be done by draft-ietf-lsr-ospf-l2bundles, though? Right now it looks to me as 
though there’s not consensus that it *should* be done in 
draft-ietf-lsr-ospf-l2bundles, which suggests to me that,

- We should ask Ketan to revert to the version where the registry is left 
untouched (the “nothing” option),
- We should then send draft-ietf-lsr-ospf-l2bundles for IETF LC and proceed 
with the publication process, and concurrently,
- Someone who sees value in reorganizing the registry should write a standalone 
draft to do that, and propose it as a WG draft.

Any objection to that approach?

Thanks,

—John

> On Sep 12, 2022, at 5:33 AM, tom petch  wrote:
> 
> From: Lsr  on behalf of John Scudder 
> 
> Sent: 06 September 2022 22:04
> 
>> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee)  wrote:
>> 
>>   I guess if we do decide to either abandon the reorganization suggestion 
>> altogether, or to pursue it as a separate draft, then 
>> draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of 
>> listing restrictions in their own subsections of the main spec, do you 
>> agree? Recall that we got here (in part) because it seemed strange to me to 
>> update the registry to list some restrictions, but not all of them.
>> 
>> [ACEE] This would be my choice except I wouldn't add the "L2 Member Bundle 
>> Attributes" restriction to the IANA registry unless we do it for all the 
>> Sub-TLVs as you suggest.
> 
> We agree; that was what I meant. All or nothing, either do the whole 
> reorganization (or whatever you want to call it) or back out the 05 change to 
> the IANA section and just roll with what was in 04 and earlier. Halfway 
> doesn’t make a lot of sense to me.
> 
> 
> All; you have to do it sometime, better sooner than later.
> 
> I see a close parallel with MPLS which got itself into a tangle, attempts to 
> clarify were rebuffed until eventually the problems were just too great and 
> the work was done.
> 
> Look at the TLVs registry in the IANA Multiprotocol Label Switching 
> Architecture (MPLS) Group.  I think that you need a strong reason not to 
> adopt a similar approach (if only for users who use MPLS as well as OSPF).  
> No need for ten columns, just a structured approach.
> 
> It took a lot of detailed review to get it right - Loa knows that well - but 
> I believe that the effort was worth it.
> 
> Tom Petch
> 
> —John

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-flex-algo-20

[John Scudder]

Hi Peter,

Thanks. I’ve requested IETF LC.

—John

> On Sep 12, 2022, at 7:36 AM, Peter Psenak  wrote:
> 
> 
> Hi John,
> 
> please see inline (##PP2)
> 
> On 09/09/2022 17:29, John Scudder wrote:
>> Hi Peter,
>> 
>> Thanks for your reply and for the ping.
>> 
>> Where necessary I’ve replied in line below. I’ve snipped any points that
>> are agreed and don’t need further discussion. I’ve also reviewed the -21
>> diffs, basically LGTM. It looks like you missed a few of the nits, I
>> don’t know if this was by choice or oversight. I’ve attached an edited
>> version of -21 that captures the remaining ones, plus a few new ones I
>> noticed. You can diff if you want to pick those up for inclusion in -22.
> 
> ##PP2
> I fixed all nits, hopefully.
> 
>> 
>>> On Aug 31, 2022, at 10:23 AM, Peter Psenak 
>>>  wrote:
>>> 
>>> [External Email. Be cautious of content]
>>> 
>>> 
>>> Hi John,
>>> 
>>> thanks a lot for the thorough review.
>>> 
>>> I incorporated all your edits and almost all of your comments.
>>> 
>>> For the few that I have not, please see inline (loop for ##PP):
>> 
>> [snip]
>> 
  Any change in the Flex-Algorithm definition may result in temporary
  disruption of traffic that is forwarded based on such Flex-Algorithm
  paths.  The impact is similar to any other event that requires
  network-wide convergence.
 +
 +jgs: IMO this would merit discussion in the Operational Considerations
 +section.  In particular, is there any advice regarding how to
 +stage/sequence FAD config changes in order to minimize disruption?
>>> 
>>> ##PP
>>> I don't really see much to add here. FAD changes the constraints used
>>> during the algo specific SPF and as such any change in it requires all
>>> routers to recompute the entire topology. In terms of the order of
>>> changes, I don't see why that would be significant and why someone would
>>> not want to advertise all changes at once if there are any multiple
>>> changes in the FAD.
>> 
>> I take your point, thanks. I guess about the most that you could say in
>> Operational Considerations would be something like
>> 
>> ---
>> 15.X  FAD Changes
>> 
>> As [Section 5.3] notes, a change in the Flex-Algorithm definition may
>> require network-wide SPF recomputation and network reconvergence. This
>> potential for disruption should be taken into consideration when
>> planning and making changes to the FAD.
> 
> ##PP2
> Added above to the Operational Consideration section.
> 
>> ---
>> 
>> Obvs, re-word as appropriate. IMHO it's worth elevating in the O.C.
>> section even if only briefly, but I don’t insist.
>> 
>> [snip]
>> 
 +jgs: Are "sender" and "receiver" sufficiently clear to OSPF practitioners
 +that there would be no ambiguity? I can think of two different ways
 +to read them -- one is that the "sender" is the router that
 +originates the LSA, and the "receiver" is any router that processes
 +the LSA. I think that's what you mean. The other, pedantic, reading,
 +is the "sender" is any router that puts the LSA on the wire, and the
 +"receiver" is any router that takes the LSA from the wire, so anyone
 +participating in flooding would be both a "sender" and a "receiver"
 +at times.
 +
 +If this is how people write OSPF specs and talk about OSPF, fine.
 +But if there are more precise terms than "sender" and "receiver" in
 +use, it would be nice to use them.
>>> 
>>> ##PP
>>> send/receive is the standard term used, e.g
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8665*section-5__;Iw!!NEt6yMaO-gk!HAdyT2s3c5I_fktGSY3YPuQdVeF95m5Yb-utZWsGn9214bNEm1SkQ1dDgtbTL2tEJz4kJBwXudGrWyHF3P9zB8IEVqDz$
>> 
>>> 
>>> I can replace sender with originator, if you prefer, but receiver would
>>> remain.
>> 
>> As you prefer. It’s not a big deal. I agree, by the way, that receiver
>> is unambiguous.
> 
> ##PP
> replaced sender with originator.
> 
>> 
>> [snip]
>> 
 
 @@ -1194,15 +1258,36 @@
|   |
+-TLVs -+
| ...   |
 +
 +jgs: Maybe add something like
 
 +   Other than where specified below, these fields' definitions are as
 +   given in [RFC2328] Section A.4.1.
>>> 
>>> ##PP
>>> RFC2328 does not use TLVs, so that would not be correct.
>> 
>> I looked again, and the fields that are excluded from my suggested
>> statement, since they are “where specified below” are Opaque Type,
>> Opaque ID, Length, and TLVs. That leaves LS Age, Options, LS Type,
>> Advertising Router, LS sequence number, and LS checksum. But if my
>> suggested wording is wrong, 

[Lsr] I-D Action: draft-ietf-lsr-flex-algo-22.txt

[internet-drafts]

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
  Clarence Filsfils
  Ketan Talaulikar
  Arkadiy Gulko
  Filename: draft-ietf-lsr-flex-algo-22.txt
  Pages   : 49
  Date: 2022-09-12

Abstract:
   IGP protocols traditionally compute best paths over the network based
   on the IGP metric assigned to the links.  Many network deployments
   use RSVP-TE based or Segment Routing based Traffic Engineering to
   steer traffic over a path that is computed using different metrics or
   constraints than the shortest IGP path.  This document specifies a
   solution that allows IGPs themselves to compute constraint-based
   paths over the network.  This document also specifies a way of using
   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
   along the constraint-based paths.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-22

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-22


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-flex-algo-20

[Peter Psenak]

Hi John,

please see inline (##PP2)

On 09/09/2022 17:29, John Scudder wrote:

Hi Peter,

Thanks for your reply and for the ping.

Where necessary I’ve replied in line below. I’ve snipped any points that 
are agreed and don’t need further discussion. I’ve also reviewed the -21 
diffs, basically LGTM. It looks like you missed a few of the nits, I 
don’t know if this was by choice or oversight. I’ve attached an edited 
version of -21 that captures the remaining ones, plus a few new ones I 
noticed. You can diff if you want to pick those up for inclusion in -22.


##PP2
I fixed all nits, hopefully.




On Aug 31, 2022, at 10:23 AM, Peter Psenak  
wrote:

[External Email. Be cautious of content]


Hi John,

thanks a lot for the thorough review.

I incorporated all your edits and almost all of your comments.

For the few that I have not, please see inline (loop for ##PP):


[snip]


 Any change in the Flex-Algorithm definition may result in temporary
 disruption of traffic that is forwarded based on such Flex-Algorithm
 paths.  The impact is similar to any other event that requires
 network-wide convergence.
+
+jgs: IMO this would merit discussion in the Operational Considerations
+section.  In particular, is there any advice regarding how to
+stage/sequence FAD config changes in order to minimize disruption?


##PP
I don't really see much to add here. FAD changes the constraints used
during the algo specific SPF and as such any change in it requires all
routers to recompute the entire topology. In terms of the order of
changes, I don't see why that would be significant and why someone would
not want to advertise all changes at once if there are any multiple
changes in the FAD.


I take your point, thanks. I guess about the most that you could say in 
Operational Considerations would be something like


---
15.X  FAD Changes

As [Section 5.3] notes, a change in the Flex-Algorithm definition may 
require network-wide SPF recomputation and network reconvergence. This 
potential for disruption should be taken into consideration when 
planning and making changes to the FAD.


##PP2
Added above to the Operational Consideration section.


---

Obvs, re-word as appropriate. IMHO it's worth elevating in the O.C. 
section even if only briefly, but I don’t insist.


[snip]


+jgs: Are "sender" and "receiver" sufficiently clear to OSPF practitioners
+that there would be no ambiguity? I can think of two different ways
+to read them -- one is that the "sender" is the router that
+originates the LSA, and the "receiver" is any router that processes
+the LSA. I think that's what you mean. The other, pedantic, reading,
+is the "sender" is any router that puts the LSA on the wire, and the
+"receiver" is any router that takes the LSA from the wire, so anyone
+participating in flooding would be both a "sender" and a "receiver"
+at times.
+
+If this is how people write OSPF specs and talk about OSPF, fine.
+But if there are more precise terms than "sender" and "receiver" in
+use, it would be nice to use them.


##PP
send/receive is the standard term used, e.g
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8665*section-5__;Iw!!NEt6yMaO-gk!HAdyT2s3c5I_fktGSY3YPuQdVeF95m5Yb-utZWsGn9214bNEm1SkQ1dDgtbTL2tEJz4kJBwXudGrWyHF3P9zB8IEVqDz$ 




I can replace sender with originator, if you prefer, but receiver would
remain.


As you prefer. It’s not a big deal. I agree, by the way, that receiver 
is unambiguous.


##PP
replaced sender with originator.



[snip]



@@ -1194,15 +1258,36 @@
   |   |
   +-    TLVs -+
   | ...   |
+
+jgs: Maybe add something like

+   Other than where specified below, these fields' definitions are as
+   given in [RFC2328] Section A.4.1.


##PP
RFC2328 does not use TLVs, so that would not be correct.


I looked again, and the fields that are excluded from my suggested 
statement, since they are “where specified below” are Opaque Type, 
Opaque ID, Length, and TLVs. That leaves LS Age, Options, LS Type, 
Advertising Router, LS sequence number, and LS checksum. But if my 
suggested wording is wrong, that’s fine, choose your own -- the more 
general observation is that specs that provide a packet diagram usually 
tell the reader what the fields mean, either by defining them, or by 
saying what reference to look in.


##PP2
A I added reference to all fields in the Opaque LSA.



[snip]


##PP
Though I agree that the order is not important for now, one can imagine
that in the future there could be rules added for which the order would
be important. I feel numbering these rules and keep them in the strict
order 

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Henk Smit]

Hi Tony,

> Some exist today. There are many TLVs where they have never been specified.

My point was: multipart TLVs exist today, before the introduction of the
capability advertisement. So when you look at a LSPDB, you still don't know for
sure which routers support multipart TLVs. Some might, but don't advertise it.
Because their software was written before the new capability existed.

>> In the end, every detail, will get its own router capability.
>  That's correct. It will. That's going to happen independently of this draft.

I hope not. And I will oppose those attempts too.

> we still do not have an effective management plane and
> continue to stuff things into the LSDB that belong in the management plane.

Yes. But that does not make it an excuse to put just anything in the LSPDB.

I've seen you in this work-group as someone who tried to keep things out of
IS-IS that don't belong there. I am surprised to see you want this capability 
in.

> The entire definition of a Flex Algo topology constraint should be
> in the management plane.

Sure. But at least the routers do make route-calculation decisions based on
that information.

> That's not an excuse for not trying to do a good job now.

That is the whole question. This capability is adding 2 more octets to LSPs.
Is that worth it? What if indeed a few dozen drafts will follow to advertise
more of these capabilities?

Should we define a new top-level TLV for "feature/software support capability"?
Not whether something is configured or not (as does the router-capability TLV),
but whether a router's software has that capability to begin with.
Or should we define a new variable-length bitmask sub-TLV for the existing 
router
capability TLV. Where every bit indicates another piece of software the router
supports?

Regardless whether we do that or not, this discussion maybe should be done
outside the multipart TLV  discussion. Maybe another draft should be written
about these software-capabilities in general?

henk.



> Op 11-09-2022 21:32 schreef Tony Li :
> 
>  
> Hi Henk,
> 
> > > If we want to introduce MP-TLVs, that change would warrant the existence 
> > > of the flag.
> > 
> > Multipart TLVs already exist today. 
> 
> 
> Some exist today.  There are many TLVs where they have never been specified.
> 
> 
> > As discussed here, after introducing a "software capability TLV", if a 
> > router doesn't
> > advertise any of those new capabilities, we still don't know whether that 
> > router supports
> > multipart TLVs or not.
> > So the new capability seems to have limited value.
> 
> 
> In particular, the current proposal on the table is to have the capability 
> apply to the TLVs where multi-part has not been previously defined.
> 
> 
> > > I dispute that a binary flag warrants the word 'complexity'.
> > 
> > You might think of a single bit now. 
> > But people might want to add more. What TLVs on a router can and can not be 
> > received
> > multipart? What about sub-TLVs?
> 
> 
> We are not proposing that level of specificity. It’s all or nothing.
> 
> 
> > It seems these days we have more people in the LSR work-group that prefer 
> > to write drafts
> > than that prefer to write code.
> 
> 
> Ok, I’m offended.
> 
> 
> > I fear a large amount of drafts about router capabilities to
> > advertise support for every bit, every TLV and every sub-TLV in LSPs. In 
> > the end, every
> > feature, every detail or option in a feature, will get its own router 
> > capability.
> 
> 
> That’s correct. It will. That’s going to happen independently of this draft.
> 
> 
> > I'm happy nobody wants routers to react to advertised software 
> > capabilities. 
> > But if routers don't react to info in a LSP, I don't think that info 
> > belongs in the control-plane.
> > It belongs in the management-plane.
> 
> 
> Thank you, but we still (40 years in?) do not have an effective management 
> plane and continue to stuff things into the LSDB that belong in the 
> management plane.
> 
> 
> > That's a different thing, imho. It's a single exception. It's very useful 
> > to identify LSPs and routers.
> > I don't see other management information we should put in LSPs.
> 
> 
> There’s tons of stuff.  The entire definition of a Flex Algo topology 
> constraint should be in the management plane. Almost everything that is in 
> the router capability TLV should be in the management plane.
> 
> We stepped down this slippery slope a long, long, time ago.
> 
> 
> > Twenty-five years ago, you and me were the first people to implement 
> > support for wide metrics.
> > I came up with a strategy to migrate a running network.
> > I introduced the "metric-style [wide|narrow]" command. That was supposed to 
> > be a temporary thing.
> > Just for use in the next 1-2 years, when every IS-IS network was migrating 
> > to wide metrics.
> 
> 
> And it’s still there.
> 
> 
> > When I came back to work, in 2015, I saw that the Nokia SR-OS routers still 
> > have narrow metrics as
> > the default 

Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[tom petch]

From: Lsr  on behalf of John Scudder 

Sent: 06 September 2022 22:04

> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee)  wrote:
>
>I guess if we do decide to either abandon the reorganization suggestion 
> altogether, or to pursue it as a separate draft, then 
> draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of 
> listing restrictions in their own subsections of the main spec, do you agree? 
> Recall that we got here (in part) because it seemed strange to me to update 
> the registry to list some restrictions, but not all of them.
>
> [ACEE] This would be my choice except I wouldn't add the "L2 Member Bundle 
> Attributes" restriction to the IANA registry unless we do it for all the 
> Sub-TLVs as you suggest.

We agree; that was what I meant. All or nothing, either do the whole 
reorganization (or whatever you want to call it) or back out the 05 change to 
the IANA section and just roll with what was in 04 and earlier. Halfway doesn’t 
make a lot of sense to me.


All; you have to do it sometime, better sooner than later.

I see a close parallel with MPLS which got itself into a tangle, attempts to 
clarify were rebuffed until eventually the problems were just too great and the 
work was done.

Look at the TLVs registry in the IANA Multiprotocol Label Switching 
Architecture (MPLS) Group.  I think that you need a strong reason not to adopt 
a similar approach (if only for users who use MPLS as well as OSPF).  No need 
for ten columns, just a structured approach.

It took a lot of detailed review to get it right - Loa knows that well - but I 
believe that the effort was worth it.

Tom Petch

—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr