Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement
draft-ietf-idr-bgp-ls-flex-algo-12

[Ballot comment]
Thanks for working on the this specification.

As a part of my discuss resolution I would note that TBD in the type field should be amended by Editor's note or more descriptive text that reflects that this type would be assigned after IANA review.

[Ballot discuss]
Thanks for working on the this specification.

I would like to discuss if Flexible Algorithm Unsupported sub-TLV type should be TBD when it is suggested to 1046 in section 5?

[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-idr-bgp-ls-flex-algo-10
CC @evyncke

Thank you for the work put into this document. It is important and easy to read. The -11 revision addresses all my previous DISCUSS/COMMENT/NITS, those are kept below only for archiving.

Special thanks to Jie Dong for the shepherd's detailed write-up including the WG consensus, alas there is no justification for the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## Historic DISCUSS for archiving

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 3.6 unknown ?

```
      sub-TLV types: Zero or more sub-TLV types that are unknown or
      unsupported by the node originating the BGP-LS advertisement.  The
      size of each sub-TLV type depends on the protocol indicated by the
      Protocol-ID field.  For example, for IS-IS each sub-TLV type would
      be of size 1 byte while for OSPF each sub-TLV type would be of
      size 2 bytes.
```

How would an originating node know that some TLVs are unknown to it ? I am probably missing something obvious here, but some clarification text would be welcome. Or simply use 'unsupported'.

## Historic COMMENTS for archiving


### Section 1

`IGP protocols (OSPF and IS-IS)` kind of assumes that RIPng is not an IGP protocol ;-) Suggest adding 'e.g.,' before OSPF.

### Section 3.1 and others

Suggest adding "sub-TLV" at the end of the section title.

### Section 3.1 sharing tag space ?

Nothing too bad but I wonder why TLV and sub-TLVs share the same 'tag space', i.e., 1039, 1040, ... Mainly out of curiosity...

### Section 3.6, missing reference to IANA

Please add a normative reference to https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#protocol-ids or at least add the URI in the text.

## NITS

### E.g.,

Please check that all "e.g." are followed by a "," ;-)

### Be consistent with byte or octet

Suggest to select 'octet' everywhere and not mixing 'octet' and 'byte'.

## 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

[Ballot comment]
I sure wish I'd read / remembered draft-ietf-lsr-flex-algo before getting most of the way through my review and being very confused (I was reviewing it on tablet without Internet access, and didn't have draft-ietf-lsr-flex-algo cached...)

Perhaps it this is just triggered by Eric's "`IGP protocols (OSPF and IS-IS)` kind of assumes that RIPng is not an IGP protocol" comment, but I personally find the first sentence of the Abstract clunky:
"Flexible Algorithm is a solution that allows routing protocols (viz. OSPF and IS-IS) to compute paths over a network based on user-defined (and hence, flexible) constraints and metrics."
I'd think that just "Flexible Algorithm is a solution that allows OSPF and IS-IS to compute paths..." or "Flexible Algorithm is a solution that allows some routing protocols (e.g. OSPF and IS-IS) to compute paths..." (if you think it may be expanded in the future). Again, this may just be because I just read Eric's comment and so was primed...

3.  Flexible Algorithm Definition
Figure 1:
  *  Length: variable length that represents the total length of the
      value field in octets.  The length value MUST be 4 or larger.

This definition seem wrong / confusing to me; the "variable length that represents the total length" make it sound like the length field is a variable number of octets. This sufficiently confused me that that I had to go and double check that this really isn't a variable length field.

I'm unclear why this isn't instead just something like:
  *  Length: total length of the value field in octets. The length value MUST be 4 or larger.

I realize that this is lifted verbatim from RFC7752 (and IDR often uses the "Length: variable" construct (e.g https://datatracker.ietf.org/doc/rfc9294/), but it still seems like it could be clearer). Actually, the "Length" definitions should be normalized throughout the document -- e.g the descriptions are different between S3.3 and S3.4 -- either one works, but consistency would be nice.








Nits:
Section 2: "The BGP-LS [RFC7752] specifies the Node Network Layer Reachability" -- it seems like there should be a word before 'specifies', but I cannot really figure out what :-P. "The BGP-LS" isn't really a "protocol", and "attribute" doesn't really seem to fit here. Perhaps "extensions"? Or just drop "The" and hope that no-one notices - I think that the meaning/intent is clear, but how to correctly refer to BGP-LS seems tricky...

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-idr-bgp-ls-flex-algo-10
CC @evyncke

Thank you for the work put into this document. It is important and easy to read (even if I may have missed some points, hence my DISCUSS ballot).

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

Special thanks to Jie Dong for the shepherd's detailed write-up including the WG consensus, alas there is no justification for the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 3.6 unknown ?

```
      sub-TLV types: Zero or more sub-TLV types that are unknown or
      unsupported by the node originating the BGP-LS advertisement.  The
      size of each sub-TLV type depends on the protocol indicated by the
      Protocol-ID field.  For example, for IS-IS each sub-TLV type would
      be of size 1 byte while for OSPF each sub-TLV type would be of
      size 2 bytes.
```

How would an originating node know that some TLVs are unknown to it ? I am probably missing something obvious here, but some clarification text would be welcome. Or simply use 'unsupported'.

[Ballot comment]

## COMMENTS


### Section 1

`IGP protocols (OSPF and IS-IS)` kind of assumes that RIPng is not an IGP protocol ;-) Suggest adding 'e.g.,' before OSPF.

### Section 3.1 and others

Suggest adding "sub-TLV" at the end of the section title.

### Section 3.1 sharing tag space ?

Nothing too bad but I wonder why TLV and sub-TLVs share the same 'tag space', i.e., 1039, 1040, ... Mainly out of curiosity...

### Section 3.6, missing reference to IANA

Please add a normative reference to https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#protocol-ids or at least add the URI in the text.

## NITS

### E.g.,

Please check that all "e.g." are followed by a "," ;-)

### Be consistent with byte or octet

Suggest to select 'octet' everywhere and not mixing 'octet' and 'byte'.

## 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

[Ballot comment]
# GEN AD review of draft-ietf-idr-bgp-ls-flex-algo-10

CC @larseggert

Thanks to Vijay Gurbani for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/XdX6DQcSJviepiZBVDd2WehpoW8).

## 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`

## 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.

### Grammar/style

#### Section 3, paragraph 10
```
e is advertising. The following sub-sections define the sub-TLVs for the FAD
                                ^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.5, paragraph 3
```
ing it for computation purposes. Therefore the FAD is different from most ot
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

## 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

[Ballot discuss]
Hi,

Thanks for this document.  I found the document to be pretty easy to read, but there is one point that I think may be helpful to clarify, or otherwise an explanation as to why it shouldn't be clarified:

In draft-ietf-lsr-flex-algo-20, when describing TLVs like "IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV" it states:

  The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in a single
  IS-IS FAD Sub-TLV.  If it appears more than once, the IS-IS FAD Sub-
  TLV MUST be ignored by the receiver.

However, I couldn't find any similar text in this document.  My presumption would be that the FAD sub-TLVs cannot appear more then once, but this didn't obviously appear to be stated anywhere (maybe it is specified in the base BGP LS spec?).  Does this need to be stated/clarified in this document at all?  Also, is the expected behaviour clear if the FAD TLV is not well constructed?

Regards,
Rob

[Ballot discuss]
Hi,

Thanks for this document.  I found that document pretty easy to read, but there is one point that I think may be helpful to clarify, or otherwise an explanation as to why it shouldn't be clarified:

In draft-ietf-lsr-flex-algo-20, when describing TLVs like "IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV" it states:

  The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in a single
  IS-IS FAD Sub-TLV.  If it appears more than once, the IS-IS FAD Sub-
  TLV MUST be ignored by the receiver.

However, I couldn't find any similar text in this document.  My presumption would be that the FAD sub-TLVs cannot appear more then once, but this didn't obviously appear to be stated anywhere (maybe it is specified in the base BGP LS spec?).  Does this need to be stated/clarified in this document at all?  Also, is the expected behaviour clear if the FAD TLV is not well constructed?

Regards,
Rob

[Ballot comment]
Thanks for this document, I found it easy to review (I'm sure it helped
that I've recently reviewed draft-ietf-lsr-flex-algo).  I have just a
few comments.

1. In the Security Considerations section, we have

  The TLVs introduced in this document are used to propagate the IGP
  Flexible Algorithm extensions defined in [I-D.ietf-lsr-flex-algo].
  It is assumed that the IGP instances originating these TLVs will
  support all the required security (as described in
  [I-D.ietf-lsr-flex-algo]) to prevent any security issues when
  propagating the TLVs into BGP-LS.

Apart from my usual complaint :-| that "prevent any security issues"
is a notably broad claim, I also have the concern that it isn't clear
to me what's really being gotten at.

Maybe you're saying something like "The Security Considerations section
of [I-D.ietf-lsr-flex-algo] discusses potential issues related to
Flexible Algorithm deployment", in which case just saying that would
seem sufficient (although you don't have to, IMO).  It seems to me that
this document need only address new issues -- if any -- that might
arise specifically as a result of propagating the information from the
IGP into BGP-LS.

If it were me I'd probably just remove this paragraph.

Nits:

2. Abstract: "Flexible Algorithm definition" should be "Flexible
  Algorithm Definition" (uppercase D).

3. Various: "ISIS" should be "IS-IS" throughout unless there's
  some specific reason for the variant spelling.

[Ballot comment]
Thanks for this document, I found it easy to review (I'm sure it helped
that I've recently reviewed draft-ietf-lsr-flex-algo).  I have just a
few comments.

1. In the Security Considerations section, we have

  The TLVs introduced in this document are used to propagate the IGP
  Flexible Algorithm extensions defined in [I-D.ietf-lsr-flex-algo].
  It is assumed that the IGP instances originating these TLVs will
  support all the required security (as described in
  [I-D.ietf-lsr-flex-algo]) to prevent any security issues when
  propagating the TLVs into BGP-LS.

Apart from my usual complaint :-| that "prevent any security issues"
is a notably broad claim, I also have the concern that it isn't clear
to me what's really being gotten at.

Maybe you're saying something like "The Security Considerations section
of [I-D.ietf-lsr-flex-algo] discusses potential issues related to
Flexible Algorithm deployment", in which case just saying that would
seem sufficient (although you don't have to, IMO).  It seems to me that
this document need only address new issues -- if any -- that might
arise when propagating the information from the IGP into BGP-LS.

If it were me I'd probably just remove this paragraph.

Nits:

2. Abstract:

"Flexible Algorithm definition" should be "Flexible
Algorithm Definition" (upper case D).

3. Various: "ISIS" should be "IS-IS" throughout unless there's
  some specific reason for the variant spelling.

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

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

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs registry on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

https://www.iana.org/assignments/bgp-ls-parameters/

Seven early allocations will be made permanent and their references changed to [ RFC-to-be ] as follows:

+------------+-----------------------------------------+
| Code Point | Description |
+------------+-----------------------------------------+
| 1039 | Flexible Algorithm Definition |
| 1040 | Flexible Algorithm Exclude Any Affinity |
| 1041 | Flexible Algorithm Include Any Affinity |
| 1042 | Flexible Algorithm Include All Affinity |
| 1043 | Flexible Algorithm Definition Flags |
| 1044 | Flexible Algorithm Prefix Metric |
| 1045 | Flexible Algorithm Exclude SRLG |
+------------+-----------------------------------------+

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

TLV Code Point: [ TBD-at-Registration ]
Description: Flexible Algorithm Unknown
IS-IS TLV/Sub-TLV:
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a value of 1046 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 this is the only action 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,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-08-17):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-idr-bgp-ls-flex-algo@ietf.org, idr-chairs@ietf.org, idr@ietf.org, jie.dong@huawei.com, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Flexible Algorithm Definition Advertisement with BGP Link-State) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Flexible Algorithm Definition
Advertisement with BGP Link-State'
  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-08-17. 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


  Flexible Algorithm is a solution that allows routing protocols (viz.
  OSPF and IS-IS) to compute paths over a network based on user-defined
  (and hence, flexible) constraints and metrics.  The computation is
  performed by routers participating in the specific network in a
  distributed manner using a Flexible Algorithm definition.  This
  definition is provisioned on one or more routers and propagated (viz.
  OSPF and IS-IS flooding) through the network.

  BGP Link-State (BGP-LS) enables the collection of various topology
  information from the network.  This document defines extensions to
  the BGP-LS address family to advertise the Flexible Algorithm
  Definition as a part of the topology information from the network.




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



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested ?  Proposed standard
Why is this the proper type of RFC?  Adds features to RFC7752

Is this type of RFC indicated in the title page header? yes

(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:

  Flexible Algorithm is a solution that allows routing protocols (viz.
  OSPF and IS-IS) to compute paths over a network based on user-defined
  (and hence, flexible) constraints and metrics.  The computation is
  performed by routers participating in the specific network in a
  distribute manner using a Flex Algorithm definition.  This definition
  provisioned on one or more routers and propagated (viz.  OSPF and IS-
  IS flooding) through the network.

  BGP Link-State (BGP-LS) enables the collection of various topology
  information from the network.  This draft defines extensions to BGP-
  LS address-family to advertise the Flexible Algorithm Definition as a
  part of the topology information from the network.

Working Group Summary:

Consensus was normal for the BGP-LS documents with the corresponding OSPF and ISIS document and implementation.

Document Quality:
Implementations of the protocol:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-flex-algo%20implementations

Personnel:
Document shepherd: Jie Dong
WG co-chairs: Susan Hares, Jeff Haas, Keyur Patel
AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

The document shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd provided the review comments on version -05 to the authors, and those comments have been resolved in version -06, thus this document is ready for publication.


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

Early Reviews has been requested for RTG-DIR, and the review comments have been resolved.


(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.

Nothing beyond the normal checks.

(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?

Ketan Talaulikar: no IPR
https://mailarchive.ietf.org/arch/msg/idr/HuPLM2ZJrk6J7af2x8Ue6Vu9q94/

Peter Psenak: no IPR
https://mailarchive.ietf.org/arch/msg/idr/JofdkQ3Bv9ERv4-m7KWsCLGrChg/

Shawn Zandi: no IPR
https://mailarchive.ietf.org/arch/msg/idr/I-5sVRI69d8C6P9nRNF5CJaJ62A/

Gaurav Dawra: no IPR
https://mailarchive.ietf.org/arch/msg/idr/EnOGHSM9U97_WyTzyUOfJdnJ9IM/

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

No IPR disclosure.

(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?

This document defines the BGP-LS extensions corresponding to the IGP Flex-Algo extensions, which has been widely discussed in LSR WG, there was not much discussion about the technical part in the WG, while the consensus on the publication of this document is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? 

none.

(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.

None.

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

No formal reviews.

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

All references have been identified as either normative or informative.

(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?

No, all normative references are either RFCs or WG documents which passed the 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).

IANA has allocated the following code points from the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"

    +------------+----------------------------------------+----------+
    | Code Point |        Description                    | Length  |
    +------------+----------------------------------------+----------+
    |  1039    | Flex Algorithm Definition TLV          | variable |
    |  1040    | Flex Algo Exclude Any Affinity sub-TLV | variable |
    |  1041    | Flex Algo Include Any Affinity sub-TLV | variable |
    |  1042    | Flex Algo Include All Affinity sub-TLV | variable |
    |  1043    | Flex Algo Definition Flags sub-TLV    | variable |
    |  1044    | Flex Algorithm Prefix Metric TLV      | variable |
    |  1045    | Flex Algorithm Exclude SRLG sub-TLV    | variable |
    +------------+----------------------------------------+----------+

The IANA consideration section is consistent with the body of the document.

One concern about the code point allocation is that both the Flex-Algo Definition TLV and its sub-TLVs are allocated with code points from this registry in parrallel.

(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.

None.

(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?

No YANG module.

Returning the document to the WG: (1) some work needs to be done related to the registries, and  (2) the base document (draft-ietf-lsr-flex-algo) is still in the lsr WG.

Returning the document to the WG: (1) some work needs to be done related to the registries, and  (2) the base document (draft-ietf-lsr-flex-algo) is still in the lsr WG.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested ?  Proposed standard
Why is this the proper type of RFC?  Adds features to RFC7752

Is this type of RFC indicated in the title page header? yes

(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:

  Flexible Algorithm is a solution that allows routing protocols (viz.
  OSPF and IS-IS) to compute paths over a network based on user-defined
  (and hence, flexible) constraints and metrics.  The computation is
  performed by routers participating in the specific network in a
  distribute manner using a Flex Algorithm definition.  This definition
  provisioned on one or more routers and propagated (viz.  OSPF and IS-
  IS flooding) through the network.

  BGP Link-State (BGP-LS) enables the collection of various topology
  information from the network.  This draft defines extensions to BGP-
  LS address-family to advertise the Flexible Algorithm Definition as a
  part of the topology information from the network.

Working Group Summary:

Consensus was normal for the BGP-LS documents with the corresponding OSPF and ISIS document and implementation.

Document Quality:
Implementations of the protocol:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-flex-algo%20implementations

Personnel:
Document shepherd: Jie Dong
WG co-chairs: Susan Hares, Jeff Haas, Keyur Patel
AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

The document shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd provided the review comments on version -05 to the authors, and those comments have been resolved in version -06, thus this document is ready for publication.


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

Early Reviews has been requested for RTG-DIR, and the review comments have been resolved.


(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.

Nothing beyond the normal checks.

(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?

Ketan Talaulikar: no IPR
https://mailarchive.ietf.org/arch/msg/idr/HuPLM2ZJrk6J7af2x8Ue6Vu9q94/

Peter Psenak: no IPR
https://mailarchive.ietf.org/arch/msg/idr/JofdkQ3Bv9ERv4-m7KWsCLGrChg/

Shawn Zandi: no IPR
https://mailarchive.ietf.org/arch/msg/idr/I-5sVRI69d8C6P9nRNF5CJaJ62A/

Gaurav Dawra: no IPR
https://mailarchive.ietf.org/arch/msg/idr/EnOGHSM9U97_WyTzyUOfJdnJ9IM/

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

No IPR disclosure.

(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?

This document defines the BGP-LS extensions corresponding to the IGP Flex-Algo extensions, which has been widely discussed in LSR WG, there was not much discussion about the technical part in the WG, while the consensus on the publication of this document is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? 

none.

(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.

None.

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

No formal reviews.

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

All references have been identified as either normative or informative.

(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?

No, all normative references are either RFCs or WG documents which passed the 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).

IANA has allocated the following code points from the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"

    +------------+----------------------------------------+----------+
    | Code Point |        Description                    | Length  |
    +------------+----------------------------------------+----------+
    |  1039    | Flex Algorithm Definition TLV          | variable |
    |  1040    | Flex Algo Exclude Any Affinity sub-TLV | variable |
    |  1041    | Flex Algo Include Any Affinity sub-TLV | variable |
    |  1042    | Flex Algo Include All Affinity sub-TLV | variable |
    |  1043    | Flex Algo Definition Flags sub-TLV    | variable |
    |  1044    | Flex Algorithm Prefix Metric TLV      | variable |
    |  1045    | Flex Algorithm Exclude SRLG sub-TLV    | variable |
    +------------+----------------------------------------+----------+

The IANA consideration section is consistent with the body of the document.

One concern about the code point allocation is that both the Flex-Algo Definition TLV and its sub-TLVs are allocated with code points from this registry in parrallel.

(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.

None.

(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?

No YANG module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested ?  Proposed standard
Why is this the proper type of RFC?  Adds features to RFC7752

Is this type of RFC indicated in the title page header? yes

(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:

  Flexible Algorithm is a solution that allows routing protocols (viz.
  OSPF and IS-IS) to compute paths over a network based on user-defined
  (and hence, flexible) constraints and metrics.  The computation is
  performed by routers participating in the specific network in a
  distribute manner using a Flex Algorithm definition.  This definition
  provisioned on one or more routers and propagated (viz.  OSPF and IS-
  IS flooding) through the network.

  BGP Link-State (BGP-LS) enables the collection of various topology
  information from the network.  This draft defines extensions to BGP-
  LS address-family to advertise the Flexible Algorithm Definition as a
  part of the topology information from the network.

Working Group Summary:

Consensus was normal for the BGP-LS documents with the corresponding OSPF and ISIS document and implementation.

Document Quality:
Implementations of the protocol:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-flex-algo%20implementations

Personnel:
Document shepherd: Jie Dong
WG co-chairs: Susan Hares, Jeff Haas, Keyur Patel
AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

The document shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd provided the review comments on version -05 to the authors, and those comments have been resolved in version -06, thus this document is ready for publication.


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

Early Reviews has been requested for RTG-DIR, and the review comments have been resolved.


(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.

Nothing beyond the normal checks.

(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?

Ketan Talaulikar: no IPR
https://mailarchive.ietf.org/arch/msg/idr/HuPLM2ZJrk6J7af2x8Ue6Vu9q94/

Peter Psenak: no IPR
https://mailarchive.ietf.org/arch/msg/idr/JofdkQ3Bv9ERv4-m7KWsCLGrChg/

Shawn Zandi: no IPR
https://mailarchive.ietf.org/arch/msg/idr/I-5sVRI69d8C6P9nRNF5CJaJ62A/

Gaurav Dawra: no IPR
https://mailarchive.ietf.org/arch/msg/idr/EnOGHSM9U97_WyTzyUOfJdnJ9IM/

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

No IPR disclosure.

(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?

This document defines the BGP-LS extensions corresponding to the IGP Flex-Algo extensions, which has been widely discussed in LSR WG, there was not much discussion about the technical part in the WG, while the consensus on the publication of this document is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? 

none.

(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.

None.

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

No formal reviews.

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

All references have been identified as either normative or informative.

(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?

No, all normative references are either RFCs or WG documents which passed the 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).

IANA has allocated the following code points from the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"

    +------------+----------------------------------------+----------+
    | Code Point |        Description                    | Length  |
    +------------+----------------------------------------+----------+
    |  1039    | Flex Algorithm Definition TLV          | variable |
    |  1040    | Flex Algo Exclude Any Affinity sub-TLV | variable |
    |  1041    | Flex Algo Include Any Affinity sub-TLV | variable |
    |  1042    | Flex Algo Include All Affinity sub-TLV | variable |
    |  1043    | Flex Algo Definition Flags sub-TLV    | variable |
    |  1044    | Flex Algorithm Prefix Metric TLV      | variable |
    |  1045    | Flex Algorithm Exclude SRLG sub-TLV    | variable |
    +------------+----------------------------------------+----------+

The IANA consideration section is consistent with the body of the document.

One concern about the code point allocation is that both the Flex-Algo Definition TLV and its sub-TLVs are allocated with code points from this registry in parrallel.

(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.

None.

(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?

No YANG module.

[Jie Dong  - try creating this write-up.  Let me know if you need help.
  I've only filled in the IPR section and the reference to implementations.
  Try querying the mail list and determining the consensus.]


As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested ?  Proposed standard
Why is this the proper type of RFC?  Adds features to RFC7752

Is this type of RFC indicated in the title page header? yes

(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:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Consensus was normal for the BGP-LS documents with
OSPF and ISIS implementation.

Document Quality:
Implementations of the protocol:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-flex-algo%20implementations

Personnel:
Document shepherd: Jie Dong
WG co-chairs: Susan Hares, Jeff Haas, Keyur Patel
AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.
(TBD)


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
(TBD)
Early Reviews requested for RTG-DIR, OPS-DIR, SEC-DIR


(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.

(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.
(TBD)

(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?
IPR disclosures:
No IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/HuPLM2ZJrk6J7af2x8Ue6Vu9q94/

  Peter Psenak
https://mailarchive.ietf.org/arch/msg/idr/JofdkQ3Bv9ERv4-m7KWsCLGrChg/

Shawn Zandi
https://mailarchive.ietf.org/arch/msg/idr/I-5sVRI69d8C6P9nRNF5CJaJ62A/

Gaurav Dawra
https://mailarchive.ietf.org/arch/msg/idr/EnOGHSM9U97_WyTzyUOfJdnJ9IM/

(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?
[TBD]

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? 
none.

(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.
TBD

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

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

(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?
(TBD)

(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.
(TBd)

(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).
(TBD)

(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.


  This document requests assigning code-points from the registry "BGP-
  LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
  TLVs".    All values have been given early allocation.

(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?
no yang