Skip to main content

Last Call Review of draft-ietf-lsr-flex-algo-18

Request Review of draft-ietf-lsr-flex-algo
Requested revision No specific revision (document currently at 26)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2021-08-27
Requested 2021-08-10
Requested by John Scudder
Authors Peter Psenak , Shraddha Hegde , Clarence Filsfils , Ketan Talaulikar , Arkadiy Gulko
I-D last updated 2021-11-01
Completed reviews Rtgdir Last Call review of -12 by Eric Gray (diff)
Rtgdir Last Call review of -18 by Henning Rogge (diff)
Opsdir Last Call review of -23 by Linda Dunbar (diff)
Secdir Last Call review of -23 by Charlie Kaufman (diff)
Genart Last Call review of -23 by Dan Romascanu (diff)
Opsdir Telechat review of -25 by Linda Dunbar (diff)
Please assign to Eric Gray. 

Eric, your earlier review indicated nits; it looks like the current revision has quite a few changes since the one you reviewed. Can you please confirm your nits have been addressed (and of course flag anything new)? Thanks!
Assignment Reviewer Henning Rogge
State Completed
Request Last Call review on draft-ietf-lsr-flex-algo by Routing Area Directorate Assigned
Posted at
Reviewed revision 18 (document currently at 26)
Result Ready
Completed 2021-11-01

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