Subject: [Lsr] Rtgdir last call review of draft-ietf-lsr-flex-algo-18

From: Henning Rogge via Datatracker <[email-masked]>
Date: Mon, 01 Nov 2021 03:18:06 -0700

Reviewer: Henning Rogge
Review result: Ready

Hi,

I have been asked to do a review of draft-ietf-lsr-flex-algo (currently in
draft 18).

First I have to say its very interesting to see that the similarities for the
routing/forwarding backplanes make it possible to have a common RFC that
modifies routing behavior for multiple routing protocols.

My area of knowledge is coming from the MANET area, but I can clearly see that
the mechanisms of this draft are generic enough to apply to most
'multi-topology' capable routing protocols. I wonder if a similar approach
could also be used in MANETs to clearly define sub-topologies that can then be
used to forward trafic along.

I think the draft is well written, most issues I had with the document were
caused by me not knowing the referenced other documents (which would not be a
problem for someone implementing this draft).

The draft uses both OSPF and OSPFv2 and OSPFv3 in the text. I assume that every
text using "OSPF" means "both v2 and v3"?

I have also a few questions about specific chapters...

In chapter 6.1-6.3 (7.1-7.3 for OSPF) you define a subset of "boolean algebra"
among the extended admin groups. I assume that more complex boolean conditions
are not necessary for most deployments (and could be done by defining more EAGs
that represent the specific condition)?

Chapter 7.4 defines that the Flags field has to have a length with a multiple
of 4 octets, which is not the case for the definition in chapter 6.4. Is the
length constraint only necessary in OSPF?

The IANA registries all state "this document" as a reference (and most of them
add a link to a chapter). I think the "this document" could just be omitted to
shorten the reference.

Henning Rogge

---

From: Peter Psenak <[email-masked]>
Date: Tue, 2 Nov 2021 12:07:17 +0100

Hi Henning,

thanks for your review, please see some responses inline (##PP):

> text using "OSPF" means "both v2 and v3"?

##PP
yes, that is indeed the wording that we used in many past documents.

> that represent the specific condition)?

##PP
the include/exclude rules that we defined have been used in traditional 
RSVP-TE for a long time. They have proved to be sufficient. We can 
always add more if needed in the future.

> length constraint only necessary in OSPF?

##PP
yes, OSPF TLVs are always 4 bytes aligned, which is not the case for 
ISIS TLVs.

> add a link to a chapter). I think the "this document" could just be omitted to

sure, will remove "this document" with the next update.

thanks,
Peter

---

From: Henning Rogge <[email-masked]>
Date: Tue, 2 Nov 2021 14:57:10 +0100

> always add more if needed in the future.

I wonder if it can make sense to allow multiple include/exclude-All
TLVs and define the "ANY logic" based on the fact that it's enough
that one sub-TLV "ALL" condition is met.

This might allow for a more flexible system, but I am not sure it's
worth the complexity in this case.

Henning Rogge

---

From: Peter Psenak <[email-masked]>
Date: Tue, 2 Nov 2021 15:20:25 +0100

Henning,

> worth the complexity in this case.

multiple include/exclude TLVs can be specified in the FAD. In such case, 
constraints in all of these TLVs must be met during the flex-algo 
calculation. So it's a logical AND between these TLVs. What you suggest 
is to allow OR logic between TLVs. I don't see the need for that as you 
can perform both AND and OR operation with the individual affinities - 
include/exclude ANY is the logical OR operation, include ALL is the 
logical AND operation.

I believe what we have is sufficient for now. If needed we can extend in 
the future.

thanks,
Peter

---

From: Henning Rogge <[email-masked]>
Date: Tue, 2 Nov 2021 16:09:09 +0100

> I believe what we have is sufficient for now. If needed we can extend in

Thats okay for me, thank you for the additional explanation.

Henning Rogge