Reviewer: Yoav Nir
Review result: Has Nits

This is an early review with a specific request to review the Security
Considerations section.

The draft adds a bunch of TLVs to be sent from routers regarding the link state
of the link used for IGP. The draft references RFC 7752 which defined earlier
TLVs used to carry NLRI (reachability) information.

What I found difficult about both 7752 and this draft is the vagueness about
who the consumer of this information is. The abstract of 7752 begins like this:
"In a number of environments, a component external to a network is called upon
to perform computations based on the network topology and current state of the
connections within the network, including Traffic Engineering (TE)
information." There is also a diagram with information flowing to a "consumer"
and that's it. Is it an SDN controller? Some kind of application?

OK. On to the Security Considerations section. It begins with a statement that
this does not affect the security model of BGP.  Although that is just claimed
and not supported in text, it seems reasonable. I should note that this
paragraph is copied from 7752.

The second (and last) paragraph in the security considerations section talks
about the new attributes. It mentions that security and authentication are
assumed to be used just as in RFCs 7810 and 7471. With proper authentication
this information is not sent except to the proper consumer. However, there is
an important difference that I think needs to be addressed. 7810 and 7471 are
about IS-IS and OSPF respectively. There routing protocols are typically used
in closed environments, and the Security Considerations of 7810 state that
explicitly. BGP (the subject of this document) is different in that it is
typically used all over the Internet. Without further clarity about who and
where the "consumer" is, it has to be assumed that the information might at
least leak out.

Another issue I have with this section is that the draft specifies how to send
new information (the link state TLVs) from one node to another. This is
information that was not sent before. When a change like that is made, I think
the Security Considerations section should justify why it is OK to distribute
this information. Typically you need to justify that leaking this information
(to the intended recipient or to the rest of the world) does not (1) make it
easier to attack some part of the system, or (2) distributes privacy-sensitive
information, or (3) undermines some other confidentiality interest. I think
it's fairly easy to make the argument that the information in these TLVs does
not do any of the above, but the argument should be made.  The last paragraph
in the Security Considerations section of RFC 7752 has just such an argument.