Skip to main content

Distribution of Link-State and Traffic Engineering Information Using BGP
draft-ietf-idr-rfc7752bis-17

Revision differences

Document history

Date Rev. By Action
2023-12-22
(System)
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-idr-rfc7752bis and RFC 9552, changed IESG state to RFC …
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-idr-rfc7752bis and RFC 9552, changed IESG state to RFC Published)
2023-12-19
17 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-12-15
17 (System) RFC Editor state changed to AUTH48
2023-11-22
17 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-10-26
17 (System) RFC Editor state changed to EDIT from IESG
2023-08-25
17 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-17.txt
2023-08-25
17 Ketan Talaulikar New version accepted (logged-in submitter: Ketan Talaulikar)
2023-08-25
17 Ketan Talaulikar Uploaded new revision
2023-05-02
16 (System) RFC Editor state changed to IESG from EDIT
2023-04-11
16 Carlos Jesús Bernardos Request closed, assignment withdrawn: Ron Bonica Telechat INTDIR review
2023-04-11
16 Carlos Jesús Bernardos Closed request for Telechat review by INTDIR with state 'Overtaken by Events'
2023-03-09
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2023-03-09
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2023-03-09
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2023-03-02
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2023-02-28
16 (System) RFC Editor state changed to EDIT
2023-02-28
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-02-28
16 (System) Announcement was received by RFC Editor
2023-02-28
16 (System) IANA Action state changed to In Progress
2023-02-28
16 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2023-02-28
16 Cindy Morgan IESG has approved the document
2023-02-28
16 Cindy Morgan Closed "Approve" ballot
2023-02-28
16 (System) Removed all action holders (IESG state changed)
2023-02-28
16 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2023-02-28
16 Alvaro Retana Ballot approval text was generated
2023-02-28
16 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2023-02-22
16 Alvaro Retana Ballot approval text was generated
2023-02-20
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-02-20
16 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-16.txt
2023-02-20
16 Ketan Talaulikar New version accepted (logged-in submitter: Ketan Talaulikar)
2023-02-20
16 Ketan Talaulikar Uploaded new revision
2023-02-20
15 John Scudder
[Ballot comment]
Thanks for addressing my DISCUSS and comments. I have a few residual comments, which I sent in a followup email to the DISCUSS …
[Ballot comment]
Thanks for addressing my DISCUSS and comments. I have a few residual comments, which I sent in a followup email to the DISCUSS thread.
2023-02-20
15 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2023-02-17
15 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-02-17
15 (System) Changed action holders to Alvaro Retana (IESG state changed)
2023-02-17
15 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-02-17
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-02-17
15 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-15.txt
2023-02-17
15 Ketan Talaulikar New version accepted (logged-in submitter: Ketan Talaulikar)
2023-02-17
15 Ketan Talaulikar Uploaded new revision
2023-02-09
14 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2023-02-09
14 Tero Kivinen Assignment of request for Last Call review by SECDIR to Christopher Wood was rejected
2022-12-15
14 Jean Mahoney Request closed, assignment withdrawn: Vijay Gurbani Last Call GENART review
2022-12-15
14 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events': Gen AD has already balloted
2022-12-15
14 (System) Changed action holders to Alvaro Retana, Ketan Talaulikar (IESG state changed)
2022-12-15
14 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-12-15
14 Gyan Mishra Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Gyan Mishra. Sent review to list.
2022-12-15
14 Robert Wilton
[Ballot comment]
Hi,

Thanks for this update to RFC 7752.  I've been short of time this week, and hence I'm somewhat relying on the …
[Ballot comment]
Hi,

Thanks for this update to RFC 7752.  I've been short of time this week, and hence I'm somewhat relying on the responsible AD and OPSDIR review (thanks Gyan!).

I did have a couple of minor comments:

On:
  To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST be
  ordered in ascending order by TLV Type.  If there are multiple TLVs
  of the same type within a single NLRI, then the TLVs sharing the same
  type MUST be in ascending order based on the value field.  Comparison
  of the value fields is performed by treating the entire field as
  opaque binary data and ordered lexicographically.

I'm not convinced that lexicographical comparison of binary data is that well-defined, since it is generally applied to strings, so I this could potentially be stated more clearly.

It also wasn't obvious to me why BGP-LS Attribute TLVs SHOULD be ordered, but are allowed to be unordered.  I.e., if sending them unordered doesn't  break interop then is it really a 'should' rather than a 'SHOULD'?

Regards,
Rob
2022-12-15
14 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2022-12-15
14 Lars Eggert
[Ballot comment]
# GEN AD review of draft-ietf-idr-rfc7752bis-14

CC @larseggert

## Comments

I have restricted my review to the parts that have changed
relative to …
[Ballot comment]
# GEN AD review of draft-ietf-idr-rfc7752bis-14

CC @larseggert

## Comments

I have restricted my review to the parts that have changed
relative to RFC7752.

### Section 5.1, paragraph 5
```
    To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST be
    ordered in ascending order by TLV Type.  If there are multiple TLVs
    of the same type within a single NLRI, then the TLVs sharing the same
    type MUST be in ascending order based on the value field.  Comparison
    of the value fields is performed by treating the entire field as
    opaque binary data and ordered lexicographically.
```
I think you need to say a bit more about what variant of lexicographic
ordering you have in mind, since the values can be of different
lengths. (I assume value bytes are compared left-to-right?)

### Section 7.2, paragraph 0
```
  7.2.  Guidance for Designated Experts
```
Much of this seems to duplicate a variant RFC7120 early allocation
procedures, which is a bit disappointing. If RFC7120 isn't suitable,
it'd be better to fix it rather than to define one-offs like this
one.

### IANA

The IANA review of this document seems to not have concluded yet.

## 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 2.1, paragraph 2
```
r of the path. This may lead to sub-optimal paths, makes alternate/back-up p
                                ^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 2.1, paragraph 3
```
of the network, but this may be sub-optimal when the network is subject to a
                                ^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 4, paragraph 2
```
or auxiliary Router-IDs of nodes, etc.. It is desirable to keep the dependen
                                      ^^
```
Two consecutive dots.

#### Section 5.1, paragraph 5
```
], by using capability code 1 (multi-protocol BGP), with AFI 16388 / SAFI 71
                              ^^^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 5.2, paragraph 18
```
omains. The Identifier field carries a 8-octet BGP-LS Instance Identifier (I
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 5.2, paragraph 21
```
port multiple IGP instances, an implementations needs to support the configur
                            ^^^^^^^^^^^^^^^^^^
```
The plural noun "implementations" cannot be used with the article "an". Did you
mean "an implementation" or "implementations"?

#### Section 5.2.1.2, paragraph 1
```
provides a similar functionality. Hence the inclusion of the BGP-LS Identif
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

#### Section 5.2.3, paragraph 1
```
ny trailing bits MUST be set to 0. Thus the IP Prefix field contains the most
                                  ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 5.3.1.5, paragraph 3
```
k TLV The following bits are defined and the reserved bits MUST be set to zer
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 5.3.3.6, paragraph 1
```
realize that area 1 is partitioned. Also if R2 continues to report Node and P
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Also".

#### Section 5.10, paragraph 2
```
istries listed in the following sub-sections are BGP-LS specific and are acc
                                ^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 7.1.1, paragraph 2
```
ted in the form of an Internet-Draft but MAY arrive in any form that can be
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 7.1.1, paragraph 2
```
that can be reviewed and exchanged amongst reviewers. 2. The designated expe
                                    ^^^^^^^
```
Do not mix variants of the same word ("amongst" and "among") within a single
text.

#### Section 7.2, paragraph 10
```
MUST allow the operator to configure a 8-octet BGP-LS Instance-ID. Refer to
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 8.2.2, paragraph 23
```
een BGP Speaker and BGP-LS Consumers but their discussion is outside the sco
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

## 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
2022-12-15
14 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2022-12-15
14 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-idr-rfc7752bis-14
CC @evyncke

Thank you for the work put into this document, it appears to add …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-idr-rfc7752bis-14
CC @evyncke

Thank you for the work put into this document, it appears to add welcomed clarification to RFC 7752. Due to lack of time, I have only reviewed the diff with RFC 7752 and I trust Brian Haberman's intdir review at:
https://datatracker.ietf.org/doc/review-ietf-idr-rfc7752bis-14-intdir-telechat-haberman-2022-12-14/ (thank you Brian).

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

Special thanks to Jeffrey Haas for the *very detailed* shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I have also appreciated that you list the RFC 7752 authors as contributors to this document.

I hope that this review helps to improve the document,

Regards,

-éric
## COMMENTS

### Section 5.2.2

The IPv4 address family has also link-local addresses (RFC 3927), to the text about link-local should be address family agnostic, i.e., either use "IPv6/IPv4 link-local address" or simply "link-local address". As this is mostly academic (IPv4 LLA are usually never used by routers), I am not raising a DISCUSS though.

### Section 5.3.2.3

What is the expected behaviour of the receiver/consumer when the trailing be are not 0 ?

### Section 5.3.2.7

Unsure what a `subset of the FQDN` is ... Do you mean a substring ?

### Section 5.4

Rather than `The Enterprise Codes are listed at .`, suggest to use a normative reference.

## NITS

### ISIS vs. IS-IS

Isn't the right writing "IS-IS" ? (I saw at least one such occurence)

## 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
2022-12-15
14 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-12-15
14 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on this -bis specification.

A comparison of this document to RFC9029 and RFC7752 didn't raise TSV related issues in my …
[Ballot comment]
Thanks for working on this -bis specification.

A comparison of this document to RFC9029 and RFC7752 didn't raise TSV related issues in my review.
2022-12-15
14 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-12-14
14 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-idr-rfc7752bis-14
CC @ekline

Thanks to Brian for the INT DIR review.

"""
Reviewer: Brian Haberman
Review result: Ready …
[Ballot comment]
# Internet AD comments for draft-ietf-idr-rfc7752bis-14
CC @ekline

Thanks to Brian for the INT DIR review.

"""
Reviewer: Brian Haberman
Review result: Ready with Nits

I reviewed the diff of this draft with RFC 7752 and did not find any issues
related to the normal concerns that come from Internet Area reviews. I do agree
with John Scudder's DISCUSS on the subtle changes to BGP processing rules.
"""
2022-12-14
14 Erik Kline Ballot comment text updated for Erik Kline
2022-12-14
14 Erik Kline
[Ballot comment]
Thanks to Brian for the INT DIR review.

"""
Reviewer: Brian Haberman
Review result: Ready with Nits

I reviewed the diff of this …
[Ballot comment]
Thanks to Brian for the INT DIR review.

"""
Reviewer: Brian Haberman
Review result: Ready with Nits

I reviewed the diff of this draft with RFC 7752 and did not find any issues
related to the normal concerns that come from Internet Area reviews. I do agree
with John Scudder's DISCUSS on the subtle changes to BGP processing rules.
"""
2022-12-14
14 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-12-14
14 Paul Wouters
[Ballot comment]
Note that my knowledge here is severely limited but I did compare the bis to the rfc and for as far as I …
[Ballot comment]
Note that my knowledge here is severely limited but I did compare the bis to the rfc and for as far as I could understand, the changes look reasonable.
2022-12-14
14 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2022-12-14
14 Brian Haberman Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Brian Haberman. Sent review to list.
2022-12-13
14 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-12-13
14 Roman Danyliw
[Ballot comment]
This is feedback on text that remains unchanged from RFC7752.  The underlying process of BGP-LS seems to be sharing “link-state and TE …
[Ballot comment]
This is feedback on text that remains unchanged from RFC7752.  The underlying process of BGP-LS seems to be sharing “link-state and TE information ... collected from networks ... with external components using the BGP routing protocol” (per Section 1).  The Security Considerations (Section 10) reiterate that “[p]rocedures and protocol extensions defined in this document do not affect the BGP security model”.  Additionally, the following caution is noted:

  Additionally, it may be considered that the export of link-state and
  TE information as described in this document constitutes a risk to
  confidentiality of mission-critical or commercially sensitive
  information about the network.  BGP peerings are not automatic and
  require configuration; thus, it is the responsibility of the network
  operator to ensure that only trusted BGP Speakers are configured to
  receive such information.

Not fully appreciating the deployment scenarios of BGP-LS, but also not finding any written constraints or a definition of what “external components” means, it seems like this “mission-critical or commercially sensitive information about the network” could be shared via BGP without transport-provided confidentiality (e.g., only TCP-AO) subjecting it to on-path inspection.  Why would that be acceptable?  Is there some expectation that these BGP peers are directly connected, or that these “external components” are in the same administrative domain?  How should it be handled if they are not-directly attached and in separate administrative domains?

Would it make sense to add a recommendation to use transport mode protection (e.g., IPsec) for BGP-LS communication in some prescribed circumstances?
2022-12-13
14 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2022-12-12
14 John Scudder
[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-idr-rfc7752bis-14
CC @jgscudder

Thanks for the work you've put into this needed document. I reviewed the …
[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-idr-rfc7752bis-14
CC @jgscudder

Thanks for the work you've put into this needed document. I reviewed the diff vs. RFC 7752, but didn't focus on any unchanged sections.

Thanks also to the shepherd, Jeff Haas, for the meticulous and helpful shepherd write-up.

As an aside to the author, my review would have been easier if a native HTML rendering had been available. I assume you must have uploaded txt instead of XML -- please consider uploading XML in the future? Thanks.

## DISCUSS

### Section 5.2.1, using ASN to disambiguate Router ID

```
  BGP-LS uses the Autonomous System (AS) Number to
  disambiguate the Router-IDs, as described in Section 5.2.1.1.
```
My concern with this is straightforward: Section 5.2.1.1 doesn't describe the use of ASN to disambiguate Router ID. In fact, it's a little hard to understand WHAT Section 5.2.1.1 describes :-( but it's not that.

I see that this claim is a carry forward from RFC 7752, but since you're touching it, I think you need to make it right, sorry. If I were confident I knew what the intent was, I'd propose a rewrite, but since I'm not, I'm just flagging the problem.

### Section 8.2.2, treat-as-withdraw

I have a concern about this:

```
  When the error that is determined allows for the router to skip the
  malformed NLRI(s) and continue the processing of the rest of the BGP
  UPDATE message (e.g. when the TLV ordering rule is violated), then it
  MUST handle such malformed NLRIs as 'Treat-as-withdraw'.
```
It's novel, in the context of RFC 7606, to allow malformed NLRI to result in something other than a session reset (or equivalent). I see why you are OK with it in the context of TLV misordering, however I think it's better to limit the exception to the exact case, instead of making it a general guideline open to implementor creativity.

A second comment (not DISCUSS level but I'll include it here) is that you don't have to characterize this as treat-as-withdraw. Since an implementation that follows this rule will never accept such an NLRI, there will never be anything to withdraw. So, following the example of RFC 7606 Section 5.4, we'd have something like this as a replacement for the quoted sentence: "An NLRI that violates the TLV ordering rule MUST be discarded." There's probably a little knock-on rewriting that would suggest, too, as in:

```
  An NLRI that violates the TLV ordering rule MUST be discarded. Other NLRI
  error cases SHOULD be handled using 'AFI/SAFI disable', when...
```
If you think there are other NLRI error cases that should get the more lenient treatment, my preference would be to enumerate them specifically, but if I'm missing some reason this should be left as written, let's discuss.
2022-12-12
14 John Scudder
[Ballot comment]
## COMMENT

### Throughout, use of "new"

The first four occurrences of "new" (up to but not including Section 5.2) might have been …
[Ballot comment]
## COMMENT

### Throughout, use of "new"

The first four occurrences of "new" (up to but not including Section 5.2) might have been appropriate in RFC 7752 but these aren't new any more, you could remove them without harm.

### Section 3, bullet 1

```
          If R1 and
      R2 are in the same IGP flooding domain, then they should originate
      the same link-state information into BGP-LS.
```
I assume the "should" above indicates expectation. It's a perfectly good English sentence, but I think there would be less scope for ambiguity if it were re-worded like "... then they would ordinarily originate the same..."  The "ordinarily" is suggested because as the document mentions elsewhere, BGP-LS is subject to policy so it would be possible, though not wise, to configure R1 and R2 with different policies leading to origination of different information into LS.

It's true that formally speaking, the RFC 2119 boilerplate moots this point, but the difference between theory and practice is greater in practice than it is in theory. I haven't picked on every lower-case "may" and "should" in your changeset, only the one that struck me as having genuine potential to lead to confusion (and a few more noted later in their own points).

And since I'm commenting on this paragraph anyway, "source... sources" is a little funny:
```
              R1 may also source
      information from sources other than IGP
```
especially since one is a verb and one is a noun. Consider "R1 can also originate information into BGP-LS from sources other than IGP"?

### Section 3, bullet 3

```
      The BGP implementation on RRm is doing the propagation of BGP-LS
      UPDATE messages and performing BGP Decision Process. 
```
It's not, strictly speaking, propagating the messages, it's propagating the information from the messages, right? So perhaps, "The BGP implementation on RRm is propagating BGP-LS information. It performs the BGP Decision Process as part of deciding what information is to be propagated."

I realize this is a fairly picky point but I've spent enough time, over the years, explaining to people that no we do not blindly forward UPDATE messages around, that I'd like to avoid propagating [*] the meme further.

[*] Oops, sorry.

### Section 4

You set up, but do not resolve, a conflict, in your first two paragraphs:

```
  The origination and propagation of IGP link-state information via BGP
  needs to provide a consistent and true view of the topology of the
  IGP domain.
```
and,

```
  The link-state information advertised in BGP-LS from the IGPs is
  derived from the IGP LSDB built using the OSPF Link State
  Advertisements (LSAs) or the IS-IS Link State Packets (LSPs).
  However, it does not serve as a true reflection of the originating
  router's LSDB.
```
What's a reader to think when they encounter this contradiction, between "needs to provide... a true view" and "does not serve as a true reflection"? I guess the former talks about the *topology* and the latter talks about the *LSDB*, but if you intend to make something of this subtle difference, it's escaped me. I presume that having set up this dichotomy, you have some resolution in mind for it -- please don't leave it as a conundrum to be solved by the reader.

### Section 5.1, malformed

```
          NLRIs having TLVs
  which do not follow the above ordering rules MUST be considered as
  malformed by a BGP-LS Propagator.  This ensures that multiple copies
  of the same NLRI from multiple BGP-LS Producers and the ambiguity
  arising therefrom is prevented.
```
This is OK as written but the last sentence might be even clearer with a bit of additional explanatory text, as in "This insistence on canonical ordering ensures that multiple variant copes of..."?

### Section 5.2, alleged deviation from RFC 7606

```
  does not support a particular Link-State NLRI type.  To allow the
  introduction of new Link-State NLRI types seamlessly in the future,
  without the need for upgrading all BGP speakers in the propagation
  path (e.g., a route reflector), this document deviates from the
  default handling behavior specified by [RFC7606] for Link-State
  address-family.  An implementation MUST handle unknown Link-State
  NLRI types as opaque objects and MUST preserve and propagate them.
```
I think you must be referring to the generic advice from Section 5.4 of RFC 7606:

  A BGP speaker advertising support for such a typed address family
  MUST handle routes with unrecognized NLRI types within that address
  family by discarding them, unless the relevant specification for that
  address family specifies otherwise.

Right? If so I guess it would be helpful to cite that specifically, "... specified by Section 5.4, paragraph 2, of [RFC7606]" (paragraph-level citation optional but why not).

(And thanks for taking care with this case!)

### Section 5.2.1.4, deprecate harder!

You note in Table 3 that the BGP-LS Identifier is deprecated, but in the description that follows you just call it optional. Regrettably, experience shows that although everyone thinks they know what "deprecated" means, different people have different assumptions. The paragraph at the end of the section helps, somewhat, but I think more could be done.

```
  BGP-LS Identifier:  Opaque value (32-bit ID).  This is an optional
      TLV.  Its original purpose was that, in conjunction with
      Autonomous System Number (ASN), it would uniquely identify the
      BGP-LS domain and that the combination of ASN and BGP-LS ID would
      be globally unique.  However, the BGP-LS Instance-ID carried in
      the Identifier field in the fixed part of the NLRI also provides a
      similar functionality.  Hence the inclusion of the BGP-LS
      Identifier TLV is not necessary.  If advertised, all BGP-LS
      speakers within an IGP flooding-set (set of IGP nodes within which
      an LSP/LSA is flooded) MUST use the same (ASN, BGP-LS ID) tuple
      and if an IGP domain consists of multiple flooding-sets, then all
      BGP-LS speakers within the IGP domain SHOULD use the same (ASN,
      BGP-LS ID) tuple.
```
It seems to me this could be cut down considerably, since a bunch of it is historical trivia and justification, and especially since the final paragraph repeats some of the needed information, and more clearly too.

```
  BGP-LS Identifier:  Opaque value (32-bit ID).  This is an optional
      TLV.  By default, it SHOULD NOT be advertised, but MAY be advertised
      when enabled by configuration, for compatibility with [RFC7752]
      implementations. See the final paragraph of this section for further
      considerations and recommended default value.
```
The curious reader can find the former definition and rules (that you're deprecating) by referring back to RFC 7752, I don't think it's needed to inline them, and indeed I think it's unhelpful for document usability. If you think it's desirable to retain the justification for deprecating it, that could go in Appendix A.

### Section 5.2.2, more lower-case "may"

In this paragraph, I have a similar concern to the one I raised about Section 3 --

```
  An implementation may end up suppressing the advertisement of a Link
  NLRI, corresponding to a half-link, from a link-state IGP unless the
  IGP has verified that the link is being reported in the IS-IS LSP or
  OSPF Router LSA by both the nodes connected by that link.  This 'two-
  way connectivity check' is performed by link-state IGPs during their
  computation and may be leveraged before passing information for any
  half-link that is reported from these IGPs into BGP-LS.  This ensures
  that only those Link State IGP adjacencies which are established get
  reported via Link NLRIs.  Such a 'two-way connectivity check' may be
  also required in certain cases (e.g., with OSPF) to obtain the proper
  link identifiers of the remote node.
```
There are three "may" in this paragraph. I think the first ("may end up") expresses expectation, but is that your desired meaning? If so, perhaps reword as "could end up"? If you're actually expressing permission, that's something more like an RFC 2119 MAY, perhaps either use the MAY, or at least get rid of "end up". The second doesn't concern me, though it could be "can". The third also is not very concerning but could be "could".

### Section 5.3, limiting the size of the BGP-LS Attribute

Thanks for this discussion. One of the points you raise is:

```
        BGP-LS Producers MUST
  ensure that they limit the TLVs included in the BGP-LS Attribute to
  ensure that a BGP UPDATE message for a single Link-State NLRI does
  not cross the maximum limit for a BGP message.  The determination of
  the types of TLVs to be included may be made by the BGP-LS Producer
  based on the BGP-LS Consumer applications requirement and is outside
  the scope of this document.
```
In other words, it's a policy decision. But that means that in this scenario such policy filtering of TLVs would be expected on a per-producer basis -- does this motivate any concern that inconsistent policy being applied at different BGP-LS Producers could lead to redundant but non-comparable information being propagated into BGP-LS? If so, is this worth noting?

### Section 5.3.1.1, reserved bits

I notice the reserved bits are no longer flagged as such, which is OK, I see they're still called out as unallocated in the IANA registry. Is there a reason you haven't provided the customary SHOULD be zero on Tx, MUST be disregarded on Rx guidance, though? I guess you might have refrained simply because the advice isn't in RFC 7752, but it seems like good advice nonetheless and wouldn't introduce any backward compatibility issues.

### Section 5.3.1.5, here's "may" again

```
  In the case of OSPF, this TLV may be used only to advertise the TLVs
  in the OSPF Router Information (RI) LSA [RFC7770].
```
It sounds like you're trying to forbid use of the TLV for anything else, in which case this really does seem like a candidate for RFC 2119 treatment, as in something like,

```
  In the case of OSPF, this TLV MUST NOT be used to advertise TLVs
  other than those in the OSPF Router Information (RI) LSA [RFC7770].
```
If you're not trying to do that, then this is yet again a case of the confusing "may".

### Section 5.3.2.4, small metrics wording

This wording is a little funny, as written it's contradictory:

```
        IS-IS small metrics have a length of 1 octet.  Since the
  ISIS small metrics are of 6-bit size, the two most significant bits
  MUST be set to 0 and MUST be ignored by the receiver.
```
I guess you mean something like "IS-IS small metrics are of 6-bit size, but are encoded in a 1 octet field; therefore the two most significant bits of the field MUST be set to 0 by the originator and MUST be ignored by the receiver." (You could also use a formulation around the legal range of small metrics being 0-63, but that makes it a little harder to talk coherently about the top two bits of the field.)

### Section 5.3.2.6, "may" again

Same comment as for 5.3.1.5, mutatis mutandis.

### Section 5.3.3.1, reserved bits

same comment as for 5.3.1.1.

### Section 5.3.3.6, "may" again

Same comment as for 5.3.1.5, mutatis mutandis.

### Section 5.4, needs a reference

I'm glad you've started to introduce this practice into BGP! But I think this needs to be a reference, not a naked URL embedded in the body:

```
  The Enterprise Codes are listed at
```
Apart from other reasons to put this in the (Normative) references, the way it's embedded in the body right now ends up making it wrap as shown, leading the unwary reader to the wrong landing page.

### Section 5.7, expand acronyms

VRF should be expanded on first use. (Not starred on https://www.rfc-editor.org/materials/abbrev.expansion.txt)

## NITS

## 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
2022-12-12
14 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2022-12-10
14 Bernie Volz Request for Telechat review by INTDIR is assigned to Brian Haberman
2022-12-10
14 Bernie Volz Request for Telechat review by INTDIR is assigned to Brian Haberman
2022-12-10
14 Bernie Volz Request for Telechat review by INTDIR is assigned to Ron Bonica
2022-12-10
14 Bernie Volz Request for Telechat review by INTDIR is assigned to Ron Bonica
2022-12-07
14 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Gyan Mishra
2022-12-07
14 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Gyan Mishra
2022-12-07
14 Dan Romascanu Assignment of request for Telechat review by OPSDIR to Dan Romascanu was rejected
2022-12-04
14 Éric Vyncke Requested Telechat review by INTDIR
2022-12-03
14 Éric Vyncke Requested Telechat review by INTDIR
2022-11-22
14 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Dan Romascanu
2022-11-22
14 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Dan Romascanu
2022-11-18
14 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-14.txt
2022-11-18
14 Ketan Talaulikar New version accepted (logged-in submitter: Ketan Talaulikar)
2022-11-18
14 Ketan Talaulikar Uploaded new revision
2022-11-15
13 Gyan Mishra Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Gyan Mishra. Sent review to list.
2022-11-15
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-11-15
13 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-13.txt
2022-11-15
13 Ketan Talaulikar New version accepted (logged-in submitter: Ketan Talaulikar)
2022-11-15
13 Ketan Talaulikar Uploaded new revision
2022-11-14
12 Cindy Morgan Placed on agenda for telechat - 2022-12-15
2022-11-14
12 Alvaro Retana Ballot has been issued
2022-11-14
12 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2022-11-14
12 Alvaro Retana Created "Approve" ballot
2022-11-14
12 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2022-11-14
12 Alvaro Retana Ballot writeup was changed
2022-11-14
12 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-11-10
12 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2022-11-10
12 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-rfc7752bis-12. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-rfc7752bis-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

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

First, on the IANA Protocol Parameter Matrix at:

https://www.iana.org/protocols

all references to RFC7752 and RFC9029 will be changed to [ RFC-to-be ].

Second, on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

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

all references to RFC7752 and RFC9029 will be changed to [ RFC-to-be ].

Third, in the Address Family Numbers registry located at:

https://www.iana.org/assignments/address-family-numbers/

the existing registration for Number 16388 (Description BGP-LS) will have its reference changed to [ RFC-to-be ].

Fourth, in the Subsequent Address Family Identifiers (SAFI) Parameters registry located at:

https://www.iana.org/assignments/safi-namespace/

the existing registration for Value 71 (Description: BGP-LS) and Value 72 (Description: BGP-LS-VPN) will have their references changed to [ RFC-to-be ].

Fifth, in the BGP Path Attributes registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

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

the existing registration for Value 29 (Code: BGP-LS Attribute) will have its reference changed to [ RFC-to-be ].

Sixth, in the BGP-LS NLRI-Types registry on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

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

changes are to be made to the registration policy of the registry. Values 0-4 will have their references changed to [ RFC-to-be ]. Values 5-64999 will be registered via Expert Review as defined by RFC 8126. Values 65000-65536 will be reserved for Private Use as defined by RFC 8126.

Seventh, in the BGP-LS Protocol-IDs registry also on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

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

changes are to be made to the registration policy of the registry. Values 7-199 will be registered via Expert Review as defined by RFC 8126. Values 200-255 will be reserved for Private Use as defined by RFC 8126.

Eighth, in the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

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

the authors request the removal of the BGP-LS Well-Known Instance-IDs registry.

IANA Question --> Should the registry be marked "obsolete" with no new registrations allowed as a way to reflect the registry's intended status while also being consistent with a reader of RFC7752 or RFC9029?

Ninth, a new registry is to be created called the BGP-LS Node Flags registry. The new registry will be located on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

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

The registration policy for the new registry will be Expert Review as defined by RFC8126. There are initial registrations in the registry as follows:

Bit Description Reference
------------------------------------------
0 Overload Bit (O-bit) [ RFC-to-be ]
1 Attached Bit (A-bit) [ RFC-to-be ]
2 External Bit (E-bit) [ RFC-to-be ]
3 ABR Bit (B-bit) [ RFC-to-be ]
4 Router Bit (R-bit) [ RFC-to-be ]
5 V6 Bit (V-bit) [ RFC-to-be ]
6-7 Unassigned

Tenth, a new registry is to be created called the BGP-LS MPLS Protocol Mask registry. The new registry will be located on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

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

The registration policy for the new registry will be Expert Review as defined by RFC8126. There are eight bits to be registered in the new registry. There are initial registrations in the registry as follows:

Bit Description Reference
--------------------------------------------------------------
0 Label Distribution Protocol (L-bit) [ RFC-to-be ]
1 Extension to RSVP for LSP Tunnels (R-bit) [ RFC-to-be ]
2-7 Unassigned

Eleventh, a new registry is to be created called the BGP-LS IGP Prefix Flags registry. The new registry will be located on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

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

The registration policy for the new registry will be Expert Review as defined by RFC8126. There are eight bits to be registered in the new registry. There are initial registrations in the registry as follows:

Bit Description Reference
----------------------------------------------------------
0 IS-IS Up/Down Bit (D-bit) [ RFC-to-be ]
1 OSPF "no unicast" Bit (N-bit) [ RFC-to-be ]
2 OSPF "local address" Bit (L-bit) [ RFC-to-be ]
3 OSPF "propagate NSSA" Bit (P-bit) [ RFC-to-be ]
4-7 Unassigned

Twelfth, in the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

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

the existing BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs registry will be renamed to BGP-LS NLRI and Attribute TLVs. In addition, the registry will have the column for IS-IS TLV/Sub-TLV fields removed. The registry's registration procedures will be changed to:

TLV Code Point Registration Process
---------------------------------------------------
0-255 Reserved (not to be allocated)
256-65000 Expert Review
65000-65535 Private Use

as defined by RFC8126. For the TLV Code Points enumerated in Section 9 of the current document, IANA will update the references to [ RFC-to-be ] and the specific section indicated in Section 9. No other changes will be made to other registrations in the newly named BGP-LS NLRI and Attribute TLVs registry.

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
2022-11-07
12 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-12.txt
2022-11-07
12 Ketan Talaulikar New version accepted (logged-in submitter: Ketan Talaulikar)
2022-11-07
12 Ketan Talaulikar Uploaded new revision
2022-10-30
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Wood
2022-10-30
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Wood
2022-10-27
11 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2022-10-27
11 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2022-10-27
11 Joel Halpern Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Joel Halpern. Sent review to list.
2022-10-25
11 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Joel Halpern
2022-10-25
11 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Joel Halpern
2022-10-25
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Gyan Mishra
2022-10-25
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Gyan Mishra
2022-10-24
11 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-10-24
11 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-11-14):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-idr-rfc7752bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, jhaas@pfrc.org …
The following Last Call announcement was sent out (ends 2022-11-14):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-idr-rfc7752bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, jhaas@pfrc.org, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Distribution of Link-State and Traffic Engineering Information Using BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Distribution of Link-State and Traffic
Engineering Information Using
  BGP'
  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-11-14. 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


  In many environments, a component external to a network is called
  upon to perform computations based on the network topology and the
  current state of the connections within the network, including
  Traffic Engineering (TE) information.  This is information typically
  distributed by IGP routing protocols within the network.

  This document describes a mechanism by which link-state and TE
  information can be collected from networks and shared with external
  components using the BGP routing protocol.  This is achieved using a
  new BGP Network Layer Reachability Information (NLRI) encoding
  format.  The mechanism applies to physical and virtual (e.g., tunnel)
  IGP links.  The mechanism described is subject to policy control.

  Applications of this technique include Application-Layer Traffic
  Optimization (ALTO) servers and Path Computation Elements (PCEs).

  This document obsoletes RFC7752 by completely replacing that
  document.  It makes some small changes and clarifications to the
  previous specification.  This document also obsoletes RFC9029 by
  incorporating the updates that it made to RFC7752.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/


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

  https://datatracker.ietf.org/ipr/5145/
  https://datatracker.ietf.org/ipr/3623/





2022-10-24
11 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-10-24
11 Alvaro Retana Requested Last Call review by RTGDIR
2022-10-24
11 Alvaro Retana Last call was requested
2022-10-24
11 Alvaro Retana Ballot approval text was generated
2022-10-24
11 Alvaro Retana Ballot writeup was generated
2022-10-24
11 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2022-10-24
11 Alvaro Retana Last call announcement was changed
2022-10-24
11 Alvaro Retana Last call announcement was generated
2022-09-29
11 (System) Changed action holders to Alvaro Retana (IESG state changed)
2022-09-29
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-09-29
11 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-11.txt
2022-09-29
11 Ketan Talaulikar New version accepted (logged-in submitter: Ketan Talaulikar)
2022-09-29
11 Ketan Talaulikar Uploaded new revision
2022-09-20
10 Alvaro Retana === AD Review of draft-ietf-idr-rfc7752bis-10 ===
https://mailarchive.ietf.org/arch/msg/idr/ogqqSawVcx3TFueiKNxmnuG00h8/
2022-09-20
10 (System) Changed action holders to Alvaro Retana, Ketan Talaulikar (IESG state changed)
2022-09-20
10 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2022-09-19
10 Alvaro Retana
: (1) What type of RFC is being requested:

Proposed Standard
: Why is this the proper type of RFC?

Replaces RFC7752

: Is this …
: (1) What type of RFC is being requested:

Proposed Standard
: Why is this the proper type of RFC?

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

In a number of environments, a component external to a network is called upon
to perform computations based on the network topology and the current state of
the connections within the network, including Traffic Engineering (TE)
information.  This is information typically distributed by IGP routing
protocols within the network.

This document describes a mechanism by which link-state and TE information can
be collected from networks and shared with external components using the BGP
routing protocol.  This is achieved using a new BGP Network Layer Reachability
Information (NLRI) encoding format.  The mechanism is applicable to physical
and virtual IGP links.  The mechanism described is subject to policy control.

Applications of this technique include Application-Layer Traffic Optimization
(ALTO) servers and Path Computation Elements (PCEs).

This document obsoletes RFC 7752 by completely replacing that document.  It
makes some small changes and clarifications to the previous specification.
This document also obsoletes RFC 9029 by incorporating the updates which it
made to RFC 7752.

:    Working Group Summary:

Work on this document primarily happened off the Working Group mail list.  A
substantial amount of the original content was produced in the original
document, draft-ketant-idr-rfc7752bis.  Refinements that happened to the draft
occurred through discussions including those at IETF to address known issues in
the original RFC 7752.

:    Was there anything in WG process that is worth noting?

Participation was light, but the participants were deeply versed in the
technology under consideration.

:    Document Quality:

The document is of high quality.  Since this is a -bis document, the original
content had been through the RFC process and started in good shape.  The new
text and clarifications that were introduced in each revision were well
considered and cleanly worded.

:    Are there existing implementations of the protocol?


https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20
:
:    Have a significant number of vendors indicated their plan to implement the
:    specification?

RFC7752 is widely deployed.

This draft corrects the specification for things learned from deployment.

:    Personnel:
:      Document Shepherd:

Jeffrey Haas

:      Area Director:

Alvaro Retana

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

A thorough review of the document was done.  There were some small number of
nits to be resolved.

During review, three error handling considerations were highlighted that were
not covered in the draft:
  - NLRI keying consistency when optional TLVs can be used.
  - BGP-LS Attribute consistency created by multiple BGP-LS Producers.
  - A desire for more discussion about error handling procedures for BGP-LS
    Consumers in the face of syntactically valid but semantically invalid
    protocol state.

This discussion resulted in small updates to the document to address the raised
points.

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

The changes to the document are straight-forward alterations providing clarity
vs. clearly traceable requirements for the covered IGP state in most cases.  In
the other cases, protocol ambiguities are addressed that are mostly based in BGP
route propagation semantics.

: (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.  The changes are largely either clarifications with clear reference to the
source IGP material, or localized to BGP impacts of the protocol.

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

No.

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

Author:
  K. Talaulikar, Cisco:
  Cisco Systems
  India
  Email: ketant@cisco.com
  https://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/

Contributors:
  Hannes Gredler
  Rtbrick
  Email: hannes@rtbrick.com
  https://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/


  Jan Medved
  Cisco Systems Inc.
  USA
  Email: jmedved@cisco.com
  https://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/


  Stefano Previdi
  Huawei Technologies
  Italy
  Email: stefano@previdi.net
  https://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/

  Adrian Farrel
  Old Dog Consulting
  Email: adrian@olddog.co.uk
  https://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/

  Saikat Ray
  Individual
  USA
  Email: raysaikat@gmail.com
  https://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/

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

Prior IPR vs. RFC 7752 was disclosed by a third-party:
https://datatracker.ietf.org/ipr/3623/

Juniper Networks provided the overlapping first-party disclosure at a later date.

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

Being a technology heavily focused on IGP and TE state, participation in the
Working Group Last Call was low.  Of those pariticipants, several individuals
who have heavy focus on those technologies supported it.  This included one of
the LSR Working Group chairs.

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

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.

No substantive nits.

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

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

No.

: (15) Are there downward normative references references (see RFC 3967)?

No.

: (16) Will publication of this document change the status of any existing RFCs?

Obsolete RFC 7752 and RFC 9029.

:      Are those RFCs listed on the title page header, listed in the abstract,
:      and discussed in the introduction?

Yes.

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

A review of all code points vs. registries was completed.

Three new registries were identified that were not previously created via
RFC 7752:
  - 6.1.4.  BGP-LS Node Flags Registry
  - 6.1.5.  BGP-LS MPLS Protocol Mask Registry
  - 6.1.6.  BGP-LS IGP Prefix Flags Registry

Each of these registries have a policy of RFC Required.

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

N/A.  There is currently no YANG module for BGP-LS.
2022-08-11
10 Alvaro Retana Notification list changed to shares@ndzh.com, jhaas@pfrc.org, aretana.ietf@gmail.com from shares@ndzh.com, jhaas@pfrc.org
2022-08-11
10 (System) Changed action holders to Alvaro Retana (IESG state changed)
2022-08-11
10 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2021-11-10
10 Jeffrey Haas
: (1) What type of RFC is being requested:

Proposed Standard
: Why is this the proper type of RFC?

Replaces RFC5575

: Is this …
: (1) What type of RFC is being requested:

Proposed Standard
: Why is this the proper type of RFC?

Replaces RFC5575

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

In a number of environments, a component external to a network is called upon
to perform computations based on the network topology and the current state of
the connections within the network, including Traffic Engineering (TE)
information.  This is information typically distributed by IGP routing
protocols within the network.

This document describes a mechanism by which link-state and TE information can
be collected from networks and shared with external components using the BGP
routing protocol.  This is achieved using a new BGP Network Layer Reachability
Information (NLRI) encoding format.  The mechanism is applicable to physical
and virtual IGP links.  The mechanism described is subject to policy control.

Applications of this technique include Application-Layer Traffic Optimization
(ALTO) servers and Path Computation Elements (PCEs).

This document obsoletes RFC 7752 by completely replacing that document.  It
makes some small changes and clarifications to the previous specification.
This document also obsoletes RFC 9029 by incorporating the updates which it
made to RFC 7752.

:    Working Group Summary:

Work on this document primarily happened off the Working Group mail list.  A
substantial amount of the original content was produced in the original
document, draft-ketant-idr-rfc7752bis.  Refinements that happened to the draft
occurred through discussions including those at IETF to address known issues in
the original RFC 7752.

:    Was there anything in WG process that is worth noting?

Participation was light, but the participants were deeply versed in the
technology under consideration.

:    Document Quality:

The document is of high quality.  Since this is a -bis document, the original
content had been through the RFC process and started in good shape.  The new
text and clarifications that were introduced in each revision were well
considered and cleanly worded.

:    Are there existing implementations of the protocol?


https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20
:
:    Have a significant number of vendors indicated their plan to implement the
:    specification?

RFC7752 is widely deployed.

This draft corrects the specification for things learned from deployment.

:    Personnel:
:      Document Shepherd:

Jeffrey Haas

:      Area Director:

Alvaro Retana

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

A thorough review of the document was done.  There were some small number of
nits to be resolved.

During review, three error handling considerations were highlighted that were
not covered in the draft:
  - NLRI keying consistency when optional TLVs can be used.
  - BGP-LS Attribute consistency created by multiple BGP-LS Producers.
  - A desire for more discussion about error handling procedures for BGP-LS
    Consumers in the face of syntactically valid but semantically invalid
    protocol state.

This discussion resulted in small updates to the document to address the raised
points.

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

The changes to the document are straight-forward alterations providing clarity
vs. clearly traceable requirements for the covered IGP state in most cases.  In
the other cases, protocol ambiguities are addressed that are mostly based in BGP
route propagation semantics.

: (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.  The changes are largely either clarifications with clear reference to the
source IGP material, or localized to BGP impacts of the protocol.

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

No.

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

Editor:
  K. Talaulikar, Cisco:
  Cisco Systems
  India
  Email: ketant@cisco.com
  https://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/

Co-authors:
  Hannes Gredler
  Rtbrick
  Email: hannes@rtbrick.com
  https://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/


  Jan Medved
  Cisco Systems Inc.
  USA
  Email: jmedved@cisco.com
  https://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/


  Stefano Previdi
  Huawei Technologies
  Italy
  Email: stefano@previdi.net
  https://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/

  Adrian Farrel
  Old Dog Consulting
  Email: adrian@olddog.co.uk
  https://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/

  Saikat Ray
  Individual
  USA
  Email: raysaikat@gmail.com
  https://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/

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

Prior IPR vs. RFC 7752 was disclosed by a third-party:
https://datatracker.ietf.org/ipr/3623/

Juniper Networks provided the overlapping first-party disclosure at a later date.

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

Being a technology heavily focused on IGP and TE state, participation in the
Working Group Last Call was low.  Of those pariticipants, several individuals
who have heavy focus on those technologies supported it.  This included one of
the LSR Working Group chairs.

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

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.

No substantive nits.

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

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

No.

: (15) Are there downward normative references references (see RFC 3967)?

No.

: (16) Will publication of this document change the status of any existing RFCs?

Obsolete RFC 7752 and RFC 9029.

:      Are those RFCs listed on the title page header, listed in the abstract,
:      and discussed in the introduction?

Yes.

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

A review of all code points vs. registries was completed.

Three new registries were identified that were not previously created via
RFC 7752:
  - 6.1.4.  BGP-LS Node Flags Registry
  - 6.1.5.  BGP-LS MPLS Protocol Mask Registry
  - 6.1.6.  BGP-LS IGP Prefix Flags Registry

Each of these registries have a policy of RFC Required.

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

N/A.  There is currently no YANG module for BGP-LS.
2021-11-10
10 Jeffrey Haas Responsible AD changed to Alvaro Retana
2021-11-10
10 Jeffrey Haas IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-11-10
10 Jeffrey Haas IESG state changed to Publication Requested from I-D Exists
2021-11-10
10 Jeffrey Haas IESG process started in state Publication Requested
2021-11-10
10 Jeffrey Haas Changed consensus to Yes from Unknown
2021-11-10
10 Jeffrey Haas Intended Status changed to Proposed Standard from None
2021-11-10
10 Jeffrey Haas Tag Doc Shepherd Follow-up Underway cleared.
2021-11-10
10 Jeffrey Haas
: (1) What type of RFC is being requested:

Proposed Standard
: Why is this the proper type of RFC?

Replaces RFC5575

: Is this …
: (1) What type of RFC is being requested:

Proposed Standard
: Why is this the proper type of RFC?

Replaces RFC5575

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

In a number of environments, a component external to a network is called upon
to perform computations based on the network topology and the current state of
the connections within the network, including Traffic Engineering (TE)
information.  This is information typically distributed by IGP routing
protocols within the network.

This document describes a mechanism by which link-state and TE information can
be collected from networks and shared with external components using the BGP
routing protocol.  This is achieved using a new BGP Network Layer Reachability
Information (NLRI) encoding format.  The mechanism is applicable to physical
and virtual IGP links.  The mechanism described is subject to policy control.

Applications of this technique include Application-Layer Traffic Optimization
(ALTO) servers and Path Computation Elements (PCEs).

This document obsoletes RFC 7752 by completely replacing that document.  It
makes some small changes and clarifications to the previous specification.
This document also obsoletes RFC 9029 by incorporating the updates which it
made to RFC 7752.

:    Working Group Summary:

Work on this document primarily happened off the Working Group mail list.  A
substantial amount of the original content was produced in the original
document, draft-ketant-idr-rfc7752bis.  Refinements that happened to the draft
occurred through discussions including those at IETF to address known issues in
the original RFC 7752.

:    Was there anything in WG process that is worth noting?

Participation was light, but the participants were deeply versed in the
technology under consideration.

:    Document Quality:

The document is of high quality.  Since this is a -bis document, the original
content had been through the RFC process and started in good shape.  The new
text and clarifications that were introduced in each revision were well
considered and cleanly worded.

:    Are there existing implementations of the protocol?


https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20
:
:    Have a significant number of vendors indicated their plan to implement the
:    specification?

RFC7752 is widely deployed.

This draft corrects the specification for things learned from deployment.

:    Personnel:
:      Document Shepherd:

Jeffrey Haas

:      Area Director:

Alvaro Retana

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

A thorough review of the document was done.  There were some small number of
nits to be resolved.

During review, three error handling considerations were highlighted that were
not covered in the draft:
  - NLRI keying consistency when optional TLVs can be used.
  - BGP-LS Attribute consistency created by multiple BGP-LS Producers.
  - A desire for more discussion about error handling procedures for BGP-LS
    Consumers in the face of syntactically valid but semantically invalid
    protocol state.

This discussion resulted in small updates to the document to address the raised
points.

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

The changes to the document are straight-forward alterations providing clarity
vs. clearly traceable requirements for the covered IGP state in most cases.  In
the other cases, protocol ambiguities are addressed that are mostly based in BGP
route propagation semantics.

: (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.  The changes are largely either clarifications with clear reference to the
source IGP material, or localized to BGP impacts of the protocol.

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

No.

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

Editor:
  K. Talaulikar, Cisco:
  Cisco Systems
  India
  Email: ketant@cisco.com
  https://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/

Co-authors:
  Hannes Gredler
  Rtbrick
  Email: hannes@rtbrick.com
  https://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/


  Jan Medved
  Cisco Systems Inc.
  USA
  Email: jmedved@cisco.com
  https://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/


  Stefano Previdi
  Huawei Technologies
  Italy
  Email: stefano@previdi.net
  https://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/

  Adrian Farrel
  Old Dog Consulting
  Email: adrian@olddog.co.uk
  https://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/

  Saikat Ray
  Individual
  USA
  Email: raysaikat@gmail.com
  https://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/

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

Prior IPR vs. RFC 7752 was disclosed by a third-party:
https://datatracker.ietf.org/ipr/3623/

Juniper Networks provided the overlapping first-party disclosure at a later date.

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

Being a technology heavily focused on IGP and TE state, participation in the
Working Group Last Call was low.  Of those pariticipants, several individuals
who have heavy focus on those technologies supported it.  This included one of
the LSR Working Group chairs.

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

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.

No substantive nits.

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

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

No.

: (15) Are there downward normative references references (see RFC 3967)?

No.

: (16) Will publication of this document change the status of any existing RFCs?

Obsolete RFC 7752 and RFC 9029.

:      Are those RFCs listed on the title page header, listed in the abstract,
:      and discussed in the introduction?

Yes.

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

A review of all code points vs. registries was completed.

Three new registries were identified that were not previously created via
RFC 7752:
  - 6.1.4.  BGP-LS Node Flags Registry
  - 6.1.5.  BGP-LS MPLS Protocol Mask Registry
  - 6.1.6.  BGP-LS IGP Prefix Flags Registry

Each of these registries have a policy of RFC Required.

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

N/A.  There is currently no YANG module for BGP-LS.
2021-11-10
10 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-10.txt
2021-11-10
10 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-11-10
10 Ketan Talaulikar Uploaded new revision
2021-10-25
09 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-09.txt
2021-10-25
09 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-10-25
09 Ketan Talaulikar Uploaded new revision
2021-09-15
Jasmine Magallanes Posted related IPR disclosure Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-idr-rfc7752bis
2021-08-27
08 Jeffrey Haas
: (1) What type of RFC is being requested:

Proposed Standard
: Why is this the proper type of RFC?

Replaces RFC5575

: Is this …
: (1) What type of RFC is being requested:

Proposed Standard
: Why is this the proper type of RFC?

Replaces RFC5575

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

In a number of environments, a component external to a network is called upon
to perform computations based on the network topology and the current state of
the connections within the network, including Traffic Engineering (TE)
information.  This is information typically distributed by IGP routing
protocols within the network.

This document describes a mechanism by which link-state and TE information can
be collected from networks and shared with external components using the BGP
routing protocol.  This is achieved using a new BGP Network Layer Reachability
Information (NLRI) encoding format.  The mechanism is applicable to physical
and virtual IGP links.  The mechanism described is subject to policy control.

Applications of this technique include Application-Layer Traffic Optimization
(ALTO) servers and Path Computation Elements (PCEs).

This document obsoletes RFC 7752 by completely replacing that document.  It
makes some small changes and clarifications to the previous specification.
This document also obsoletes RFC 9029 by incorporating the updates which it
made to RFC 7752.

:    Working Group Summary:

Work on this document primarily happened off the Working Group mail list.  A
substantial amount of the original content was produced in the original
document, draft-ketant-idr-rfc7752bis.  Refinements that happened to the draft
occurred through discussions including those at IETF to address known issues in
the original RFC 7752.

:    Was there anything in WG process that is worth noting?

Participation was light, but the participants were deeply versed in the
technology under consideration.

:    Document Quality:

The document is of high quality.  Since this is a -bis document, the original
content had been through the RFC process and started in good shape.  The new
text and clarifications that were introduced in each revision were well
considered and cleanly worded.

:    Are there existing implementations of the protocol?


https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20
:
:    Have a significant number of vendors indicated their plan to implement the
:    specification?

RFC7752 is widely deployed.

This draft corrects the specification for things learned from deployment.

:    Personnel:
:      Document Shepherd:

Jeffrey Haas

:      Area Director:

Alvaro Retana

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

A thorough review of the document was done.  There were some small number of
nits to be resolved.

During review, three error handling considerations were highlighted that were
not covered in the draft:
  - NLRI keying consistency when optional TLVs can be used.
  - BGP-LS Attribute consistency created by multiple BGP-LS Producers.
  - A desire for more discussion about error handling procedures for BGP-LS
    Consumers in the face of syntactically valid but semantically invalid
    protocol state.

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

The changes to the document are straight-forward alterations providing clarity
vs. clearly traceable requirements for the covered IGP state in most cases.  In
the other cases, protocol ambiguities are addressed that are mostly based in BGP
route propagation semantics.

: (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.  The changes are largely either clarifications with clear reference to the
source IGP material, or localized to BGP impacts of the protocol.

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

No.

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

Editor:
  K. Talaulikar, Cisco:
  Cisco Systems
  India
  Email: ketant@cisco.com
  https://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/

Co-authors:
  Hannes Gredler
  Rtbrick
  Email: hannes@rtbrick.com
  https://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/


  Jan Medved
  Cisco Systems Inc.
  USA
  Email: jmedved@cisco.com
  https://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/


  Stefano Previdi
  Huawei Technologies
  Italy
  Email: stefano@previdi.net
  https://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/

  Adrian Farrel
  Old Dog Consulting
  Email: adrian@olddog.co.uk
  https://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/

  Saikat Ray
  Individual
  USA
  Email: raysaikat@gmail.com
  https://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/

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

Prior IPR vs. RFC 7752 was disclosed by a third-party:
https://datatracker.ietf.org/ipr/3623/

Junper Networks has been contacted to see if they'll add an official first-party
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?

Being a technology heavily focused on IGP and TE state, participation in the
Working Group Last Call was low.  Of those pariticipants, several individuals
who have heavy focus on those technologies supported it.  This included one of
the LSR Working Group chairs.

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

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.

No substantive nits.

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

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

No.

: (15) Are there downward normative references references (see RFC 3967)?

No.

: (16) Will publication of this document change the status of any existing RFCs?

Obsolete RFC 7752 and RFC 9029.

:      Are those RFCs listed on the title page header, listed in the abstract,
:      and discussed in the introduction?

Yes.

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

A review of all code points vs. registries was completed.

Three new registries were identified that were not previously created via
RFC 7752:
  - 6.1.4.  BGP-LS Node Flags Registry
  - 6.1.5.  BGP-LS MPLS Protocol Mask Registry
  - 6.1.6.  BGP-LS IGP Prefix Flags Registry

Each of these registries have a policy of RFC Required.

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

N/A.  There is currently no YANG module for BGP-LS.
2021-08-06
08 Susan Hares Notification list changed to shares@ndzh.com, jhaas@pfrc.org from shares@ndzh.com because the document shepherd was set
2021-08-06
08 Susan Hares Document shepherd changed to Jeffrey Haas
2021-08-06
08 Susan Hares Tag Doc Shepherd Follow-up Underway set.
2021-08-06
08 Susan Hares IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-07-26
08 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-08.txt
2021-07-26
08 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-07-26
08 Ketan Talaulikar Uploaded new revision
2021-07-09
07 Susan Hares
RFC 4858 Shepherd Write-Up (11/1/2019)

This version is dated 1 November 2019.

(1) What type of RFC is being requested:  Proposed Standard
Why is this …
RFC 4858 Shepherd Write-Up (11/1/2019)

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? Replaces RFC5575
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:
  In a number of environments, a component external to a network is
  called upon to perform computations based on the network topology and
  the current state of the connections within the network, including
  Traffic Engineering (TE) information.  This is information typically
  distributed by IGP routing protocols within the network.

  This document describes a mechanism by which link-state and TE
  information can be collected from networks and shared with external
  components using the BGP routing protocol.  This is achieved using a
  new BGP Network Layer Reachability Information (NLRI) encoding
  format.  The mechanism is applicable to physical and virtual IGP
  links.  The mechanism described is subject to policy control.

  Applications of this technique include Application-Layer Traffic
  Optimization (ALTO) servers and Path Computation Elements (PCEs).

  This document obsoletes RFC 7752 by completely replacing that
  document.  It makes some small changes and clarifications to the
  previous specification.  This document also obsoletes RFC 9029 by
  incorporating the updates which it made to RFC 7752.



Working Group Summary:
(TBD)

Was there anything in WG process that is worth noting?
[TBD]

Document Quality:
[TBd]



Are there existing implementations of the protocol?
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20

Have a significant number of vendors indicated their plan to implement the specification?
RFC7752 is widely deployed.
This draft corrects the specification for things learne din deployment.

RTG-DIR:
OPS

Personnel:
Document Shepherd:  (All IDR chairs)
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)

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

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

Editor:
  K. Talaulikar, Cisco:
  Cisco Systems
  India
  Email: ketant@cisco.com
https://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/

Co-authors:
  Hannes Gredler
  Rtbrick
  Email: hannes@rtbrick.com
https://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/


  Jan Medved
  Cisco Systems Inc.
  USA
  Email: jmedved@cisco.com
  https://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/


  Stefano Previdi
  Huawei Technologies
  Italy
  Email: stefano@previdi.net
https://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/

  Adrian Farrel
  Old Dog Consulting
  Email: adrian@olddog.co.uk
https://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/

  Saikat Ray
  Individual
  USA
  Email: raysaikat@gmail.com
https://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
https://datatracker.ietf.org/ipr/3623/
3rd party IPR mentioned in call

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

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

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

(16) Will publication of this document change the status of any existing RFCs?
Obsolete RFC7752

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.

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

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

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

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

2021-06-21
07 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-07.txt
2021-06-21
07 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-06-21
07 Ketan Talaulikar Uploaded new revision
2021-06-21
06 Susan Hares 2 weeks IPR call and Shepherd review (all IDR chairs will review)
2 weeks WG LC
2021-06-21
06 Susan Hares IETF WG state changed to In WG Last Call from WG Document
2021-06-21
06 Susan Hares Notification list changed to shares@ndzh.com because the document shepherd was set
2021-06-21
06 Susan Hares Document shepherd changed to Susan Hares
2021-05-02
06 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-06.txt
2021-05-02
06 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-05-02
06 Ketan Talaulikar Uploaded new revision
2020-11-02
05 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-05.txt
2020-11-02
05 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2020-11-02
05 Ketan Talaulikar Uploaded new revision
2020-09-04
04 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-04.txt
2020-09-04
04 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2020-09-04
04 Ketan Talaulikar Uploaded new revision
2020-03-05
03 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-03.txt
2020-03-05
03 (System) New version approved
2020-03-05
03 (System) Request for posting confirmation emailed to previous authors: Ketan Talaulikar
2020-03-05
03 Ketan Talaulikar Uploaded new revision
2019-11-01
02 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-02.txt
2019-11-01
02 (System) New version approved
2019-11-01
02 (System) Request for posting confirmation emailed to previous authors: Ketan Talaulikar
2019-11-01
02 Ketan Talaulikar Uploaded new revision
2019-09-14
01 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-01.txt
2019-09-14
01 (System) New version approved
2019-09-14
01 (System)
Request for posting confirmation emailed to previous authors: Adrian Farrel , idr-chairs@ietf.org, Saikat Ray , Ketan Talaulikar , Hannes Gredler , Jan Medved , …
Request for posting confirmation emailed to previous authors: Adrian Farrel , idr-chairs@ietf.org, Saikat Ray , Ketan Talaulikar , Hannes Gredler , Jan Medved , Stefano Previdi
2019-09-14
01 Ketan Talaulikar Uploaded new revision
2019-09-05
00 Susan Hares This document now replaces draft-ketant-idr-rfc7752bis instead of None
2019-09-05
00 Ketan Talaulikar New version available: draft-ietf-idr-rfc7752bis-00.txt
2019-09-05
00 (System) WG -00 approved
2019-09-05
00 Ketan Talaulikar Set submitter to "Ketan Talaulikar ", replaces to draft-ketant-idr-rfc7752bis and sent approval email to group chairs: idr-chairs@ietf.org
2019-09-05
00 Ketan Talaulikar Uploaded new revision