IGP Flexible Algorithm
draft-ietf-lsr-flex-algo-26

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-lsr-flex-algo-24
CC @evyncke

Thank you for the work put into this document. The underlying concept is brillant and can be useful, but it was hard for me to understand all the details as the document is rather tedious to read (and to author -- so congrats!), I may have misunderstood several points.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. ***But***, I regret the lack of reply to the question about `WG discussion and conclusion regarding the IPR disclosures`.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Alvaro's DISCUSS

Just to write that I find Alvaro's DISCUSS points sensible, but I am sure that the authors will address those points.

### Who allocates the flex algo ID

After reading the I-D (and skipping some too deeply technical parts to be honest), I still wonder whether it is the operator who defines locally significant flex algo ID or whether it will be the IETF by standard actions. I was about to raise a DISCUSS on this point.

### Section 1

For the non-expert reader, it would be nice to shortly indicate why this document is about SRv6 locators and not SRv6 SIDs. (no need to explain this to me BTW ;-) )

### Section 4

In `We want the mapping`, who is the "we" ? Please do not use such ambiguous sentence patterns.

In `As long as all routers in the domain`, what is the "domain" ? The OSPF area? the AS? another concept ?

In `The following values area allocated from this registry for Flex-Algorithms`, the reader would benefit to already understand which party (operator/IANA/?) will assign specific values in that range.

### Section 5.1

Even if obvious, it will not hurt to have the unit specified in `Length: variable,`.

### Section 5.1 Calc-Type

I am probably confused and lost due to my lack of knowledge... But the definition of Calc-Type:

1) specifies that type 0 is SPF, which is useless as the IANA https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types already says so. I.e., why addin useless/redundant information in the normative part (use of MUST)

2) the same IANA registry https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types has a clear indication that value 2-127 are unassigned. I.e., this I-D should not add constraints in this registry.

### Section 5.1 Priority tie

What is the expected behavior when there is a priority tie ? Perhaps add a forward reference to section 5.3 ?

### Sections 6.2 and 6.3

Suggest to repeat the TLV format from section 6.1.

### Sections 6.4, 7.4

Sorry, but cannot understand/parse `Bits that are not transmitted MUST be treated as if they are set to 0 on receipt.` Is the meaning "bits defined by further specification but not in the actual transmitted TLV" ?

What is the expected behavior when length is 0, i.e., I would assume that SRv6 nodes will either do not send this TLV or send it with length=0.

### Section 11

Again a "we" in `we say it`, please rephrase without using ambiguous "we".

### Section 20.1

Is RFC 8986 really normative? I would have assumed it is informative.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments


*************
As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I really think that the
document would be improved with a change here, but can be convinced otherwise.

Check for IPv4, IPv6, address, NAT, ICMP, MTU

As usual, as the responsible AD for the ADD WG, I have done an AD review before the IETF Last Call. Please find a MD-formatted review below. Before going further, I am requesting the authors to act/reply/comment on all the points below. The end goal is to ease the rest of the publication process.

Please note that Tim Winters is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Tim will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/reviewrequest/16061/

[Ballot comment]
# Internet AD comments for {draft-ietf-lsr-flex-algo-24}
CC @ekline

## Comments

### S6.4, S7.4

* Is it safer to perhaps say that the M-flag is not only "not applicable"
  for SRv6 locators but add some kind of "MUST NOT be sent" and "MUST be
  ignored" ~type clauses?

  S8 has this kind of language and I think it may help grab the attention
  of an implementer.

### S9

* Should there be any qualifications here for SRv6 locator prefixes?

[Ballot comment]
Thank you very much for this document, and also for working with Linda to address her OpsDir review (https://datatracker.ietf.org/doc/review-ietf-lsr-flex-algo-23-opsdir-lc-dunbar-2022-09-21/ )
Also (obviously!) thanks to Linda for the OpsDir review.

I don't have much to add, other than to support Alvaro's DISCUSS position - a bit more text would be helpful.

[Ballot comment]
Thank you very much for this document, and also for working with Linda to address her OpsDir review (https://datatracker.ietf.org/doc/review-ietf-lsr-flex-algo-23-opsdir-lc-dunbar-2022-09-21/ )

I don't have much to add, other than to support Alvaro's DISCUSS position - a bit more text would be helpful.

[Ballot comment]
Hi,

Thanks for this document.  I don't really have much to say.

I was slightly surprised by the IPR declaration 3910, which unless I am misreading it, seems to be asserting possible IPR on the BCP 14 text (i.e., section 2 of revision 03)!  Perhaps worth flagging to see if an update to the IPR declaration is needed?

One minor nit:

(1) p 3, sec 1.  Introduction

  This document also specifies a way for a router to use IGPs to
  associate one or more Segment Routing with the MPLS Data Plane (SR-
  MPLS) Prefix-SIDs [RFC8660], or Segment Routing over IPv6 (SRv6)
  locators [RFC8986] with a particular Flex-Algorithm.

I found this sentence clunky to parse/understand - possibly putting quotes around "Segment Routing with the MPLS Data Plane" and "Segment Routing over IPv6 (SRv6) locators" would help.

Regards,
Rob

[Ballot discuss]
I am balloting DISCUSS because I believe that operational and security considerations need to be addressed or at least mentioned.

I believe these points should be easy to address with some additional text.


(1) When is a router's participation in a particular Flex-Algorithm advertised?

It seems to me that there might be a "chicken-and-egg" problem that should at least be mentioned in the Operational Considerations.  Let me explain:

§11:

  When a router is configured to support a particular Flex-Algorithm,
  we say it is participating in that Flex-Algorithm.

§5:

  To guarantee loop-free forwarding for paths computed for a particular
  Flex-Algorithm, all routers that (a) are configured to participate in
  a particular Flex-Algorithm, and (b) are in the same Flex-Algorithm
  definition advertisement scope MUST agree on the definition of the
  Flex-Algorithm.  The following procedures ensure this condition is
  fulfilled.


These statements make it look like support for a particular Flex-Algorithm is advertised when the routing process is enabled -- because the router is "configured to support/participate".  However, at this point, the router may not have received a FAD for the Flex-Algorithm it is advertising support for.

Besides the number of the Flex-Algorithm, the participation advertisement implies support for a specific Metric-Type and Calc-Type.  But, again, nodes may be advertising this support blindly if the FAD is not known yet.

Presumably, the operator configures support for a specific Flex-Algorithm with a FAD in mind.  IOW, there should be no surprises.  However, I would like to see the relationship between the support/participation configuration and the FAD components explicitly called out.

Note that this issue is related to the ability of an attacker to hijack a particular Flex-Algorithm, but oriented at the ability of the operator to cause harm to their network.



(2) Related to the point above.

What should a node configured to advertise support for a specific Flex-Algorithm do if it receives a FAD that it cannot support?  For example, if the calc-type is unknown or unsupported.

[§13 already addresses the case of an unsupported metric-type.]



(3) The Security Considerations section says that the attacks listed can be addressed through authentication.  However, it fails to consider what a rogue node (one that is authenticated and taken over by an attacker) can do. 

This type of attack is not preventable through authentication, and it is not different from advertising any other incorrect information through IS-IS/OSPF.  It should be mentioned in the Security Considerations section.

Also, the effect of a hijacked/modified FAD may result in traffic not being delivered at all -- for example, by using an unsupported Metric-Type or Calc-Type.

[Ballot comment]
Thank you to Charlie Kaufman for the SECDIR review.

** Section 4.
  We want the mapping between the Flex-Algorithm and its
  meaning to be flexible and defined by the user. 

Is a “Flex-Algorithm” (with hyphen) the same as a “Flex Algorithm” (no hyphen) defined in Section 3?  Why the difference in notation?

** Section 4.
  The set consisting of (a) calculation-type, (b) metric-type, and (c)
  a set of constraints is referred to as a Flexible-Algorithm
  Definition.

  Flexible-Algorithm is a numeric identifier in the range 128-255 that
  is associated via configuration with the Flexible-Algorithm
  Definition.

This text repeats the text in Section 3 verbatim.  Is it needed twice?

** Section 5.

... and (b) are in the same Flex-Algorithm
  definition advertisement scope

What is a “FAD advertisement scope?”  Should this be an additional term defined in Section 3?

** Section 5.1.  Should the explanation of “Metric-Type” say that it’s value comes from the “IGP Metric-Type Registry” per Section 18.1.2?

Section 5.1.  Is it possible for a peer not to support a particular Metric-Type?  If so, have is that signaled?

** Section 5.1.
  An IS-IS L1/L2 router MAY be configured to re-generate the winning
  FAD from level 2, ...

What is the “winning FAD?”

** Section 5.1 and 5.2.  Editorial. Definition of Flex-Algorithm in the TLV.

-- Section 5.1
Flex-Algorithm: Single octet value between 128 and 255 inclusive.

-- Section 5.2
      Flex-Algorithm:: Flex-Algorithm number.  Value between 128 and 255
      inclusive.

Should this text be the same?

** Section 5.2.  Editorial. Why is the text defining Metric-Type repeated verbatim from what is written in Section 5.1, but Calc-Type and Priority cite Section 5.1?

** Section 6.4.
  New flag bits may be defined in the future.  Implementations MUST
  check all advertised flag bits in the received IS-IS FADF Sub-TLV -
  not just the subset currently defined.

Let’s assume bits other than those define in this document are set.  Is there an IANA registry to check to understand their semantics?

** Section 13.1.

  During the route computation, it is possible for the Flex-Algorithm
  specific metric to exceed the maximum value that can be stored in an
  unsigned 32-bit variable.  In such scenarios, the value MUST be
  considered to be of value 0xFFFFFFFF during the computation and
  advertised as such.

Should this guidance be referenced in Section 8 – that 0xFFFFFFFF could be 0xFFFFFFFF or an overflow value?

** Section 17. 
  This draft adds two new ways to disrupt IGP networks:

      An attacker can hijack a particular Flex-Algorithm by advertising
      a FAD with a priority of 255 (or any priority higher than that of
      the legitimate nodes).

      An attacker could make it look like a router supports a particular
      Flex-Algorithm when it actually doesn't, or vice versa.


What are the consequences of the described attacker behaviors?  Is “disrupt[ing] the IGP networks” just a denial of service?  Could it also be steering traffic in a particular way to allow inspection or modification; or to avoid network based mitigations?

[Ballot comment]
# GEN AD review of draft-ietf-lsr-flex-algo-23

CC @larseggert

Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ttCI9O3hhN2Ryyic_0GWCj-ZDMY).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditionally`; alternatives might be `classic`, `classical`,
  `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`
* Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
  `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 4, paragraph 4
```
-    is associated via configuratin with the Flexible-Algorithm
+    is associated via configuration with the Flexible-Algorithm
+                                +
```

#### Section 5.3, paragraph 9
```
-    A router that is not participating in a particular Flex-Algorithm is
-                                                                      ^^
-    allowed to advertise FAD for such Flex-Algorithm.  Receiving routers
-  -----------
+    A router that is not participating in a particular Flex-Algorithm MAY
+                                                                      ^^^
```

#### Section 6, paragraph 1
```
-    FAD may be split into multiple such sub-TLVs and the content of the
-        ^^^
+    FAD MAY be split into multiple such sub-TLVs and the content of the
+        ^^^
```

#### Section 6.4, paragraph 10
```
-    Bits that are NOT transmitted MUST be treated as if they are set to 0
-                  ^^^
+    Bits that are not transmitted MUST be treated as if they are set to 0
+                  ^^^
```

#### Section 6.4, paragraph 13
```
-    TLV, all the bits are assumed to be set to 0.
+    TLV, all the bits MUST be treated as set to 0.
```

#### Section 7.4, paragraph 10
```
-    Bits that are NOT transmitted MUST be treated as if they are set to 0
-                  ^^^
+    Bits that are not transmitted MUST be treated as if they are set to 0
+                  ^^^
```

#### Section 7.4, paragraph 12
```
-    the bits are assumed to be set to 0.
+    the bits MUST be treated as set to 0.
```

#### Section 9, paragraph 17
```
-      Reserved: Must be set to 0, ignored at reception.
-                  ^^^
+      Reserved: MUST be set to 0, ignored at reception.
+                  ^^^
```

#### Section 10.2, paragraph 11
```
-      Reserved: Three octets.  Must be set to 0, ignored at reception.
-                                ^^^
+      Reserved: Three octets.  MUST be set to 0, ignored at reception.
+                                ^^^
```

#### Section 12, paragraph 2
```
-    then legacy advertisements are to be used, subject to the procedures
-                              ^^^^^^
+    then legacy advertisements MUST be used, subject to the procedures
+                              ^^^^
```

#### Section 13.1, paragraph 1
```
-    Algorithm in the next area or domain, the traffic may be dropped by
-                                                      ^^^
+    Algorithm in the next area or domain, the traffic MAY be dropped by
+                                                      ^^^
```

#### Section 13.1, paragraph 13
```
-    considered to be of value 4,294,967,295 during the computation and
-                              ^^^^^^^^^^^^^
+    considered to be of value 0xFFFFFFFF during the computation and
+                              ^^^^^^^^^^
```

#### Section 14.1, paragraph 4
```
-    paths, MUST be dropped when there are no such paths available.
-        -
```

### Grammar/style

#### Section 2, paragraph 1
```
ation. IGP Algorithm - value from the the "IGP Algorithm Types" registry def
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 6, paragraph 1
```
red LSP from a given IS MUST be used and any other occurrences MUST be ignor
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 6.1, paragraph 4
```
red LSP from a given IS MUST be used and any other occurrences MUST be ignor
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 6.2, paragraph 2
```
red LSP from a given IS MUST be used and any other occurrences MUST be ignor
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 6.3, paragraph 6
```
red LSP from a given IS MUST be used and any other occurrences MUST be ignor
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 7.4, paragraph 11
```
h a Flex-Algorithm prefix metric larger then MAX_PATH_METRIC as defined in [R
                                ^^^^^^^^^^^
```
Did you mean "larger than"?

#### Section 10.2, paragraph 15
```
efined for each data-plane and is outside of the scope of this document. 12.
                                  ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

#### Section 11, paragraph 1
```
that Flex-Algorithm. No specific two way connectivity check is performed du
                                  ^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 11, paragraph 2
```
existing, Flex-Algorithm agnostic, two way connectivity check is used during
                                  ^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 11, paragraph 2
```
-Algorithm value at the same time, and and as such, share the FAD for it. Tr
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 12, paragraph 8
```
uce an end-to-end path, which is sub-optimal based on Flex-Algorithm constra
                                ^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 13, paragraph 7
```
achable for that Flex-Algorithm. Similarly in the case of OSPF, for ASBRs in
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Similarly".

#### Section 13, paragraph 14
```
s defined in Section 5.3 does not includes the M-flag, then the IGP metrics
                                  ^^^^^^^^
```
The auxiliary verb "do" requires the base form of the verb.

#### Section 13.1, paragraph 17
```
efined for each data-plane and is outside of the scope of this document. 15.
                                  ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

#### Section 13.1, paragraph 18
```
ch prevents it from being flooded outside of the level in which it was origin
                                  ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

#### Section 14.2, paragraph 5
```
-IS, OSPFv2 and OSPFv3 all have well defined handling of unrecognized TLVs an
                                ^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 15.4, paragraph 2
```
Prefix Metric Bits" registry under the under the "Open Shortest Path First (O
                            ^^^^^^^^^^^^^^^^^^^
```
This phrase is duplicated. You should probably use "under the" only once.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lsr-flex-algo-22. If any part of this review is inaccurate, please let us know.

We understand that, upon approval of this document, there are fourteen actions which we must complete.

First, in the IGP Algorithm Types registry on the Interior Gateway Protocol (IGP) Parameters registry page located at:

https://www.iana.org/assignments/igp-parameters

the temporary registration:

Type: 128-255
Description: Flexible Algorithms
Reference: [ RFC-to-be ]

will be made permanent and the reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the IGP Metric-Type registry. The new registry will be created on the Interior Gateway Protocol (IGP) Parameters registry page located at:

https://www.iana.org/assignments/igp-parameters

The registry will be managed via Standards Action as defined by RFC 8126. There are initial registrations in the new registry as follows:

Type: 0
Description: IGP metric
Reference: [ RFC-to-be ], Section 5.1

Type: 1
Description: Min Unidirectional Link Delay as defined in
[RFC8570], section 4.2, and [RFC7471], section 4.2.
Reference: [ RFC-to-be ], Section 5.1

Type: 2
Description: Traffic Engineering Default Metric as defined in
[RFC5305], section 3.7, and Traffic engineering metric as defined
in [RFC3630], section 2.5.5
Reference: [ RFC-to-be ], Section 5.1

Third, a new registry is to be created called the IS-IS Flexible Algorithm Definition Flags registry. The new registry will be created on the Interior Gateway Protocol (IGP) Parameters registry page located at:

https://www.iana.org/assignments/igp-parameters

The registry will be managed via Standards Action as defined by RFC 8126. There is a single initial registration in the new registry as follows:

Bit: 0
Name: Prefix Metric Flag (M-flag)
Reference: [ RFC-to-be ], Section 6.4, Section 7.4

Fourth, in the IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV registry on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints

the temporary registration:

Type: 26
Description: Flexible Algorithm Definition (FAD)
Reference: [ RFC-to-be ], Section 5.1

will be made permanent and the reference changed to [ RFC-to-be ].

Fifth, in the IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints

the temporary registration:

Type: 6
Description: Flexible Algorithm Prefix Metric (FAPM)
Reference: [ RFC-to-be ], Section 8

will be made permanent and the reference changed to [ RFC-to-be ].

Sixth, a new registry called Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV registry will be created. The new registry will be created on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The registry will be managed via Expert Review as defined by RFC 8126. There are initial registrations in the new registry as follows:

Type: 1
Description: Flexible Algorithm Exclude Admin Group
Reference: [ RFC-to-be ], Section 6.1

Type: 2
Description: Flexible Algorithm Include-Any Admin Group
Reference: [ RFC-to-be ], Section 6.2

Type: 3
Description: Flexible Algorithm Include-All Admin Group
Reference: [ RFC-to-be ], Section 6.3

Type: 4
Description: Flexible Algorithm Definition Flags
Reference: [ RFC-to-be ], Section 6.4

Type: 5
Description: Flexible Algorithm Exclude SRLG
Reference: [ RFC-to-be ], Section 6.5

Seventh, in the OSPF Router Information (RI) TLVs registry on the Open Shortest Path First (OSPF) Parameters registry page located at:

https://www.iana.org/assignments/ospf-parameters

the temporary registration:

Type: 16
Description: Flexible Algorithm Definition (FAD) TLV
Reference: [ RFC-to-be ], Section 5.2

will be made permanent and the reference changed to [ RFC-to-be ].

Eighth, in the OSPFv2 Extended Prefix TLV Sub-TLVs registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

https://www.iana.org/assignments/ospfv2-parameters

the temporary registration:

Type: 3
Description: Flexible Algorithm Prefix Metric (FAPM)
Reference: [ RFC-to-be ], Section 9

will be made permanent and the reference changed to [ RFC-to-be ].

Ninth, in the OSPFv3 Extended-LSA Sub-TLVs registry on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

https://www.iana.org/assignments/ospfv3-parameters

the temporary registration:

Value: 26
Description: Flexible Algorithm Prefix Metric (FAPM)
Reference: [ RFC-to-be ], Section 9

will be made permanent and the reference changed to [ RFC-to-be ].

In addition, a new registration will be added to the registry as follows:

Value: TBD
Description: OSPF Flexible Algorithm ASBR Metric Sub-TLV
Reference: [ RFC-to-be ], Section 10.2

IANA notes that the authors suggest a value of 33 for this new registration.

Tenth, a new registry called the OSPF Flex-Algorithm Prefix Metric Bits registry will be created. The new registry will be created on the Open Shortest Path First (OSPF) Parameters registry page located at:

https://www.iana.org/assignments/ospf-parameters

The registry will be managed via IETF Review as defined by RFC 8126. There is a single initial registration in the new registry as follows:

Bit Number: 0
Description: E bit - External Type
Reference: [ RFC-to-be ], Section 9

Eleventh, in the Opaque Link-State Advertisements (LSA) Option Types registry on the Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types registry page located at:

https://www.iana.org/assignments/ospf-opaque-types

A new registration will be made as follows:

Value: TBD
Description: OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA
Reference: [ RFC-to-be ], Section 10.1

IANA notes that the authors suggest a value of 11 for this new registration.

NOTE: Section 18.4.5 says, "Opaque Link-State Advertisements (LSA) Option Types" registry under the "Open Shortest Path First v2 (OSPFv2) Parameters" grouping." The registry page should be updated to Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types instead of Open Shortest Path First v2 (OSPFv2) Parameters.

Twelfth, the following registries will be created on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

https://www.iana.org/assignments/ospfv2-parameters

OSPFv2 Extended Inter-Area ASBR TLVs

The allocation policy for the new registry is:

0: Reserved
1-32767: IETF Review or IESG Approval
32768-33023: Reserved for Experimental Use
33024-65535: Reserved

There is a single initial registration in the new registry as follows:

Value: 1
Description: Extended Inter-Area ASBR TLV
Reference: [ RFC-to-be ]

OSPFv2 Extended Inter-Area ASBR Sub-TLVs

The allocation policy for the new registry is:

0: Reserved
1-32767: IETF Review or IESG Approval
32768-33023: Reserved for Experimental Use
33024-65535: Reserved

There is a single initial registration in the new registry as follows:

Value: 1
Description: OSPF Flexible Algorithm ASBR Metric Sub-TLV
Reference: [ RFC-to-be ]

Thirteenth, a new registry is to be created called OSPF Flexible Algorithm Definition TLV sub-TLV registry. The new registry will be created on the Open Shortest Path First (OSPF) Parameters registry page located at:

https://www.iana.org/assignments/ospf-parameters

The allocation policy for the new registry is:

0-32767: IETF Review or IESG Approval
32768-33023: Reserved for Experimental Use
33024-65535: Reserved

There are initial registrations in the new registry as follows:

Type: 1
Description: Flexible Algorithm Exclude Admin Group
Reference: [ RFC-to-be ], Section 7.1

Type: 2
Description: Flexible Algorithm Include-Any Admin Group
Reference: [ RFC-to-be ], Section 7.2

Type: 3
Description: Flexible Algorithm Include-All Admin Group
Reference: [ RFC-to-be ], Section 7.3

Type: 4
Description: Flexible Algorithm Definition Flags
Reference: [ RFC-to-be ], Section 7.4

Type: 5
Description: Flexible Algorithm Exclude SRLG
Reference: [ RFC-to-be ], Section 7.5

Fourteenth, in the Link Attribute Application Identifiers registry on the Interior Gateway Protocol (IGP) Parameters registry page located at:

https://www.iana.org/assignments/igp-parameters

a new registration will be made as follows:

Bit: TBD
Name: Flexible Algorithm (X-bit)
Reference: [ RFC-to-be ], Section 12

IANA notes that the authors suggest a value of 3 for this new registration.

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-09-26):

From: The IESG
To: IETF-Announce
CC: Christian Hopps , acee@cisco.com, draft-ietf-lsr-flex-algo@ietf.org, jgs@juniper.net, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IGP Flexible Algorithm) to Proposed Standard


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-call@ietf.org mailing lists by 2022-09-26. Exceptionally, comments may
be sent to iesg@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/

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides extensions to OSPF and IS-IS to use different algorithms to compute the paths to different prefixes. Since not all nodes in the computation domain (i.e., an OSPF or IS-IS area) may support every algorithm SR or SRv6 is used to between nodes.

Working Group Summary:

The was good collaboration on the document. The only controversy came at the tail end of the process when there was some discussion as to whether RFC 8919 /RFC 8920 Application Specific Link Attributes (ASLAs) should be used for alternate metrics or whether the advetisements used for RSVP TE could also be used. The consensus was to allow RFC 8919/RFC 8920 attributes to be required.

Discussion and implementation uncovered that some additional OSPF encodings were needed for ASBR routes. This resulted in updates and second WG Last Call. During the second WG Last Call, the discussion of the application specific attributes resulted in Errata to both RFC 8919 and 8920:

https://www.rfc-editor.org/errata/eid6631
https://www.rfc-editor.org/errata/eid6630


Document Quality:

The document is of high quality with vendors and operators reviewing.
There are existing implementations of the document and three other WG documents that augment
the base document:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
  https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: John Scudder

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document multiple times and provided editorial and consistency comments.  The shepherd's review is acknowledged in the draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus behind the document and it is considered a bulding block for other functionality including network slicing. Several network operators have reviewed and commented on the draft.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The nits have been all fixed.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of these are applicable. The YANG model augmentations will be added in a separate draft.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes - the OSPFv3 SRv6 enhancements is behind this document and will block publication until published. This document will be advanced soon after the IS-IS SRv6 extensions complete WG last call.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has IANA registrations. However, the document has gone through the early allocation process and has going through extensive reviews by designated experts and the Working Group. The only comment that came up was whether 1/2 of the IGP algorithm space should be devoted to flexible algorithms. As document shepherd, I have reviewed the IANA requirements at each stage.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV", "OSPF Flexible Algorithm Definition TLV sub-TLV", "OSPFv2 Extended Inter-Area ASBR TLVs", "OSPFv2 Extended Inter-Area ASBR Sub-TLVs", and "OSPF Flex-Algorithm Prefix Metric Bits" registries are created by this document. The allocation policy is designated as Expert Review. Designated experts should be drawn from the WG membership and will most likely be different for IS-IS and OSPF.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides extensions to OSPF and IS-IS to use different algorithms to compute the paths to different prefixes. Since not all nodes in the computation domain (i.e., an OSPF or IS-IS area) may support every algorithm SR or SRv6 is used to between nodes.

Working Group Summary:

The was good collaboration on the document. The only controversy came at the tail end of the process when there was some discussion as to whether RFC 8919 /RFC 8920 Application Specific Link Attributes (ASLAs) should be used for alternate metrics or whether the advetisements used for RSVP TE could also be used. The consensus was to allow RFC 8919/RFC 8920 attributes to be required.

Discussion and implementation uncovered that some additional OSPF encodings were needed for ASBR routes. This resulted in updates and second WG Last Call. During the second WG Last Call, the discussion of the application specific attributes resulted in Errata to both RFC 8919 and 8920:

https://www.rfc-editor.org/errata/eid6631
https://www.rfc-editor.org/errata/eid6630


Document Quality:

The document is of high quality with vendors and operators reviewing.
There are existing implementations of the document and three other WG documents that augment
the base document:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
  https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: John Scudder

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document multiple times and provided editorial and consistency comments.  The shepherd's review is acknowledged in the draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus behind the document and it is considered a bulding block for other functionality including network slicing. Several network operators have reviewed and commented on the draft.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The nits have been all fixed.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of these are applicable. The YANG model augmentations will be added in a separate draft.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes - the OSPFv3 SRv6 enhancements is behind this document and will block publication until published. This document will be advanced soon after the IS-IS SRv6 extensions complete WG last call.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has IANA registrations. However, the document has gone through the early allocation process and has going through extensive reviews by designated experts and the Working Group. The only comment that came up was whether 1/2 of the IGP algorithm space should be devoted to flexible algorithms. As document shepherd, I have reviewed the IANA requirements at each stage.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV", "OSPF Flexible Algorithm Definition TLV sub-TLV", "OSPFv2 Extended Inter-Area ASBR TLVs", "OSPFv2 Extended Inter-Area ASBR Sub-TLVs", and "OSPF Flex-Algorithm Prefix Metric Bits" registries are created by this document. The allocation policy is designated as Expert Review. Designated experts should be drawn from the WG membership and will most likely be different for IS-IS and OSPF.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides extensions to OSPF and IS-IS to use different algorithms to compute the paths to different prefixes. Since not all nodes in the computation domain (i.e., an OSPF or IS-IS area) may support every algorithm SR or SRv6 is used to between nodes.

Working Group Summary:

The was good collaboration on the document. The only controversy came at the tail end of the process when there was some discussion as to whether RFC 8919 /RFC 8920 Application Specific Link Attributes (ASLAs) should be used for alternate metrics or whether the advetisements used for RSVP TE could also be used. The consensus was to allow RFC 8919/RFC 8920 attributes to be required.

Document Quality:

There are existing implementations of the document.

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document multiple times and provided editorial and consistency comments.  The shepherd's review is acknowledged in the draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus behind the document and it is considered a bulding block for other functionality including network slicing. Several network operators have reviewed and commented on the draft.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Currently, there are nits and the authors are going to fix them.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of these are applicable. The YANG model augmentations will be added in a separate draft.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes - the OSPFv3 SRv6 enhancements is behind this document and will block publication until published. This document will be advanced soon after the IS-IS SRv6 extensions complete WG last call.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has IANA registrations. However, the document has gone through the early allocation process and has going through extensive reviews by designated experts and the Working Group. The only comment that came up was whether 1/2 of the IGP algorithm space should be devoted to flexible algorithms. As document shepherd, I have reviewed the IANA requirements at each stage.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV", "OSPF Flexible Algorithm Definition TLV sub-TLV", "OSPFv2 Extended Inter-Area ASBR TLVs", "OSPFv2 Extended Inter-Area ASBR Sub-TLVs", and "OSPF Flex-Algorithm Prefix Metric Bits" registries are created by this document. The allocation policy is designated as Expert Review. Designated experts should be drawn from the WG membership and will most likely be different for IS-IS and OSPF.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

The document was missing a significant part of the OSPF specification -- it has now been added, and the WG will issue a new WGLC.  I am sending this document back to the WG.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides extensions to OSPF and IS-IS to use different algorithms to compute the paths to different prefixes. Since not all nodes in the computation domain (i.e., an OSPF or IS-IS area) may support every algorithm SR or SRv6 is used to between nodes.

Working Group Summary:

The was good collaboration on the document. The only controversy came at the tail end of the process when there was some discussion as to whether RFC 8919 /RFC 8920 Application Specific Link Attributes (ASLAs) should be used for alternate metrics or whether the advetisements used for RSVP TE could also be used. The consensus was to allow RFC 8919/RFC 8920 attributes to be required.

Document Quality:

There are existing implementations of the document.

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document multiple times and provided editorial and consistency comments.  The shepherd's review is acknowledged in the draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus behind the document and it is considered a bulding block for other functionality including network slicing. Several network operators have reviewed and commented on the draft.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The nits have been all fixed other than one reference.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of these are applicable. The YANG model augmentations will be added in a separate draft.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes - the OSPFv3 SRv6 enhancements is behind this document and will block publication until published. This document will be advanced soon after the IS-IS SRv6 extensions complete WG last call.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has IANA registrations. However, the document has gone through the early allocation process and has going through extensive reviews by designated experts and the Working Group. The only comment that came up was whether 1/2 of the IGP algorithm space should be devoted to flexible algorithms. As document shepherd, I have reviewed the IANA requirements at each stage.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Both the "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" and "OSPF Flexible Algorithm Definition TLV sub-TLV" registries are created by this document. The allocation policy is designated as Expert Review. Designated experts should be drawn from the WG membership and will most likely be different for IS-IS and OSPF.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

IETF LLCRFC EditorIANAIABIRTFIETF TrustSecretariat: AMSISOCPrivacy StatementWebsite feedback

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides extensions to OSPF and IS-IS to use different algorithms to compute the paths to different prefixes. Since not all nodes in the computation domain (i.e., an OSPF or IS-IS area) may support every algorithm SR or SRv6 is used to between nodes.

Working Group Summary:

The was good collaboration on the document. The only controversy came at the tail end of the process when there was some discussion as to whether RFC 8919 /RFC 8920 Application Specific Link Attributes (ASLAs) should be used for alternate metrics or whether the advetisements used for RSVP TE could also be used. The consensus was to allow RFC 8919/RFC 8920 attributes to be required.

Document Quality:

There are existing implementations of the document.

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document multiple times and provided editorial and consistency comments.  The shepherd's review is acknowledged in the draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus behind the document and it is considered a bulding block for other functionality including network slicing. Several network operators have reviewed and commented on the draft.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The nits have been all fixed other than one reference.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of these are applicable. The YANG model augmentations will be added in a separate draft.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes - the OSPFv3 SRv6 enhancements is behind this document and will block publication until published. This document will be advanced soon after the IS-IS SRv6 extensions complete WG last call.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has IANA registrations. However, the document has gone through the early allocation process and has going through extensive reviews by designated experts and the Working Group. The only comment that came up was whether 1/2 of the IGP algorithm space should be devoted to flexible algorithms. As document shepherd, I have reviewed the IANA requirements at each stage.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Both the "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" and "OSPF Flexible Algorithm Definition TLV sub-TLV" registries are created by this document. The allocation policy is designated as Expert Review. Designated experts should be drawn from the WG membership and will most likely be different for IS-IS and OSPF.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

IETF LLCRFC EditorIANAIABIRTFIETF TrustSecretariat: AMSISOCPrivacy StatementWebsite feedback

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides extensions to OSPF and IS-IS to use different algorithms to compute the paths to different prefixes. Since not all nodes in the computation domain (i.e., an OSPF or IS-IS area) may support every algorithm SR or SRv6 is used to between nodes.

Working Group Summary:

The was good collaboration on the document. The only controversy came at the tail end of the process when there was some discussion as to whether RFC 8919 /RFC 8920 Application Specific Link Attributes (ASLAs) should be used for alternate metrics or whether the advetisements used for RSVP TE could also be used. The consensus was to allow RFC 8919/RFC 8920 attributes to be required.

Document Quality:

There are existing implementations of the document.

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document multiple times and provided editorial and consistency comments.  The shepherd's review is acknowledged in the draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus behind the document and it is considered a bulding block for other functionality including network slicing. Several network operators have reviewed and commented on the draft.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Currently, there are nits and the authors are going to fix them.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of these are applicable. The YANG model augmentations will be added in a separate draft.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes - the OSPFv3 SRv6 enhancements is behind this document and will block publication until published. This document will be advanced soon after the IS-IS SRv6 extensions complete WG last call.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has IANA registrations. However, the document has gone through the early allocation process and has going through extensive reviews by designated experts and the Working Group. The only comment that came up was whether 1/2 of the IGP algorithm space should be devoted to flexible algorithms. As document shepherd, I have reviewed the IANA requirements at each stage.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Both the "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" and "OSPF Flexible Algorithm Definition TLV sub-TLV" registries are created by this document. The allocation policy is designated as Expert Review. Designated experts should be drawn from the WG membership and will most likely be different for IS-IS and OSPF.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

IETF LLCRFC EditorIANAIABIRTFIETF TrustSecretariat: AMSISOCPrivacy StatementWebsite feedback

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides extensions to OSPF and IS-IS to use different algorithms to compute the paths to different prefixes. Since not all nodes in the computation domain (i.e., an OSPF or IS-IS area) may support every algorithm SR or SRv6 is used to between nodes.

Working Group Summary:

The was good collaboration on the document. The only controversy came at the tail end of the process when there was some discussion as to whether RFC 8919 /RFC 8920 Application Specific Link Attributes (ASLAs) should be used for alternate metrics or whether the advetisements used for RSVP TE could also be used. The consensus was to allow RFC 8919/RFC 8920 attributes to be required.

Document Quality:

There are existing implementations of the document.

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document multiple times and provided editorial and consistency comments.  The shepherd's review is acknowledged in the draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus behind the document and it is considered a bulding block for other functionality including network slicing. Several network operators have reviewed and commented on the draft.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Currently, there are nits and the authors are going to fix them.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of these are applicable. The YANG model augmentations will be added in a separate draft.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes - the OSPFv3 SRv6 enhancements is behind this document and will block publication until published. This document will be advanced soon after the IS-IS SRv6 extensions complete WG last call.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has IANA registrations. However, the document has gone through the early allocation process and has going through extensive reviews by designated experts and the Working Group. The only comment that came up was whether 1/2 of the IGP algorithm space should be devoted to flexible algorithms. As document shepherd, I have reviewed the IANA requirements at each stage.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry is created by this document. The allocation policy is designated as "IETF review or IESG Approval". Futher discussion is required here.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

IETF LLCRFC EditorIANAIABIRTFIETF TrustSecretariat: AMSISOCPrivacy StatementWebsite feedback

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides extensions to OSPF and IS-IS to use different algorithms to compute the paths to different prefixes. Since not all nodes in the computation domain (i.e., an OSPF or IS-IS area) may support every algorithm SR or SRv6 is used to between nodes.

Working Group Summary:

The was good collaboration on the document. The only controversy came at the tail end of the process when there was some discussion as to whether RFC 8919 /RFC 8920 Application Specific Link Attributes (ASLAs) should be used for alternate metrics or whether the advetisements used for RSVP TE could also be used. The consensus was to allow RFC 8919/RFC 8920 attributes to be required.

Document Quality:

There are existing implementations of the document.

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document multiple times and provided editorial and consistency comments.  The shepherd's review is acknowledged in the draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus behind the document and it is considered a bulding block for other functionality including network slicing. Several network operators have reviewed and commented on the draft.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Currently, there are nits and the authors are going to fix them.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of these are applicable. The YANG model augmentations will be added in a separate draft.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes - the OSPFv3 SRv6 enhancements is behind this document and will block publication until published. This document will be advanced soon after the IS-IS SRv6 extensions complete WG last call.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has IANA registrations. However, the document has gone through the early allocation process and has going through extensive reviews by designated experts and the Working Group. The only comment that came up was whether 1/2 of the IGP algorithm space should be devoted to flexible algorithms. As document shepherd, I have reviewed the IANA requirements at each stage.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry is created by this document. The allocation policy is designated as "IETF review or IESG Approval". Futher discussion is required here.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

IETF LLCRFC EditorIANAIABIRTFIETF TrustSecretariat: AMSISOCPrivacy StatementWebsite feedback