North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
draft-ietf-idr-ls-distribution-13

[Ballot discuss]

Note: This may sound like a scary discuss, and who knows but
it might lead to us recognising that some significant work is
needed in future, but I think this should be easily fixed for
this particular document...

This document does recognise that there can be confidentiality
or privacy issues with exporting information in this way. And
it correctly (I think) says that just not sending that
sensitive data is a good way to handle this and that
mechanisms for e.g.  aggregating to ensure privacy are out of
scope. (As an aside: strengthening that recommendation would
be a good thing I think.)

However, noting that e.g. ALTO servers can be handling data
that is privacy sensitive for specific users (e.g. see
https://tools.ietf.org/html/rfc7285#section-15.3 and
https://tools.ietf.org/html/rfc7285#section-15.4), I think
there are two more things that need to be noted here, but that
are not.

(1) First is that this document does change (what I understand,
perhaps imperfectly, as) the security model for BGP, in that
previously we have assumed that BGP speakers are not exposing
user-specific privacy sensitive information. This draft seems
to me to change that. (If it does not, then a reference to
where that was previously done would be needed, or an
explanation of why I'm wrong:-) If you could add a strong
recommendation to not do that, I think that'd be good. (I
do get that that can't be an easily implemented MUST NOT
statement though, so I'm not quite sure what text to
suggest, but it oughtn't be too hard to figure something
out.)

(2) Second, I wonder if the above change means that we need to
seriously consider confidentiality for BGP. The RPKI does not,
but then neither did DNSSEC for years until we belatedly
realised that that was a real issue. I'm not asking that this
draft provide a mechanism for confidentiality for BGP, but
that at least recognising the issue as real (if it is) seems
to be required. (And nor am I asking that a confidentiality
system as complex as the rpki be developed, I think that if
anything is needed here beyond data minimisation, then
transport layer security would be as good as it'd get.) The
change here would be to simply recognise this consequence,
if it is real, and that could be a simple sentennce in the
draft, e.g. saying that these changes to BGP might result
in PII being emitted, and hence might cause a real need
for confidentiality for BGP.

[Ballot comment]
Nicely written; thanks.  And a particular thanks for the clear guidance to the DEs in Section 5.1.  I might want to point to this from 5226bis, which means this might get me off my bum on that.

A minor editorial thing in the Introduction:

  The contents of a Link State Database (LSDB) or a Traffic Engineering
  Database (TED) has the scope of an IGP area.

I don't know what that means.  Might it be this (and might this be a clearer way to say it)?:

NEW
  The contents of a Link State Database (LSDB) or a Traffic Engineering
  Database (TED) are only visible within their IGP area.
END

[Ballot comment]
-section 5: "The SAFI assignment does
  NOT need to be out of the range 1-63 and MAY come out of the "First
  Come First Served" range 128-240."

I suspect the all-caps terms don't really apply (especially the free-floating NOT).

- section 5.1: "available for review by the IDR working group,"

What if that group concludes?

Status: draft-ietf-idr-ls-distribution-12 resolves ADs comments 

AD: Alia Atlas
WG chairs: Susan Hares, John Scudder
Shepherd: Jie Dong
QA Reviewer in RTG-DIR: Acee Linden [OK]
QA Reviewer in OPS-DIR: Ron Bonica [ok]
IANA review: Early QA REview done (3/14/2014, 10/30, 2014, 1/24/2015)

Implementation report:
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/

Specification of code points is stable with the implementation report
for juniper and cisco's implementation (2 per IDR WG requirements).

=========

1) RFC requested: Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. 

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
  current state of the connections within the network, including
  traffic engineering information.  This is information typically
  distributed by IGP routing protocols within the network.
  This document describes a mechanism by which links state and traffic
  engineering 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).
.

Working Group Summary

IDR has reviewed and discussed his document over 3 years (2011-2014),
and the WG LCs for early adoption occurred in Fall 2013, and from 1/16-1/27/2014.
WG has reached consensus due to strong implementation experience.

Document Quality

IDR has reviewed and discussed his document over 3 years (2011-2014),
and the protocol has the two implementations that the IDR WG requires
for standardization of BGP protocol features.  The two implementations are reported
in the document: draft-gredler-idr-ls-distribution-impl-00.pdf.

Review timeline:

A WG LC for this draft on 3/12-3/26/14. 

Personnel:
Document Shepherd for early assignment review: Susan Hares
Responsible AD: Alia Atlas
Shepherd: Jie Dong
QA Reviewer in RTG-DIR: Acee Linden [OK]
QA Reviewer in OPS-DIR: Ron Bonica [ok]
IANA review: Early QA REview done (3/14/2014, 10/30, 2014, 1/24/2015)

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

Draft was given early allocation per RFC 7120.
Shepherd and WG-Chair have reviewed draft in versions.
draft-ietf-idr-ls-distribution-012 was reviewed by WG-Chair due to
document shepherd leave for arrival of new baby.

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

No.

Operational deployments and discussion on list have found issues that have been
fixed.  QA reviews have been done by IANA, OPS-DIR, and RTG-Directorate.
Multiple versions have been reviewed.
Implementation have been fielded to customers.

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

This draft is the first of the wave of BGP drafts that consider putting extra information
into the BGP infrastructure of some portions of the network to supply new
service routing, or SDN-based calculations. If you have concerns about
BGP carrying this data, you should review this carefully.  However,
early interoperability testing, deployments, and results have convinced the
IDR WG.  (The WG chairs started out skeptical and has been convinced by
running code and operational experience. )

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

The document shepherd feels comfortable with all sections and the text
within the document.

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

IPR disclosed by Juniper.  The list
http://datatracker.ietf.org/ipr/1864/

Authors:
Hannes Gredler disclosure:
https://mailarchive.ietf.org/arch/msg/idr/YQLjkJmmgxsj4iW9q82h1bpL0eg

Jan Medved disclosure:
https://mailarchive.ietf.org/arch/msg/idr/Yb4Ynk3a3Gwmp5qm1misrWiMqR0

Saikat Ray
https://mailarchive.ietf.org/arch/msg/idr/j4UCoWu8Lsflg3HpfkITyDeH9Xc

Adrian Farrel:
https://mailarchive.ietf.org/arch/msg/idr/YBRkdNC_exsgQjTS1hHd0E3_5LA

Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/W9MnDKZr-JmzPdzdPWPTVNLh4-w

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

Private Email has been sent to each author (3/4/14).
During WG LC, a public IPR public call will be sent (3/13 - 3/26)

(9) How solid is the WG consensus behind this document? 

Strong wide-spread consensus based on vendor implementations, early deployments,
and key responses.

(10) appeals and discontent: not seen

(11) Identify any ID nits the Document Shepherd has found in this
document. 

No nits found.

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

Not relevant for MIB Doctor, Media type, or URI.

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

Yes.

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


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

IANA - requests:
New AFI/SAFI - early allocation requested by this report
New BGP path attribute - under RFC 7120 this should occur.

New Registry for BGP LS node anchor, link descriptor, and link attribute TLVs
  0-255 are reserved
  256-65535 - code points
  (table 11 in document)

This new will need designated expert to be assigned by IESG (per RFC 5226)

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

New Registry for BGP LS node anchor, link descriptor, and link attribute TLVs
  0-255 are reserved
  256-65535 - code points
  (table 11 in document)

This new will need designated expert to be assigned by IESG (per RFC 5226)

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

No self-check required for XML, BNF, MIB definitions.

Status: draft-ietf-idr-ls-distribution-12 resolves ADs comments 

AD: Alia Atlas
WG chairs: Susan Hares, John Scudder
Shepherd: Jie Dong
QA Reviewer in RTG-DIR: Acee Linden [OK]
QA Reviewer in OPS-DIR: Ron Bonica [ok]
IANA review: Early QA REview done (3/14/2014, 10/30, 2014, 1/24/2015)

Implementation report:
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/

Specification of code points is stable with the implementation report
for juniper and cisco's implementation (2 per IDR WG requirements).

=========

1) RFC requested: Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. 

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
  current state of the connections within the network, including
  traffic engineering information.  This is information typically
  distributed by IGP routing protocols within the network.
  This document describes a mechanism by which links state and traffic
  engineering 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).
.

Working Group Summary

IDR has reviewed and discussed his document over 3 years (2011-2014),
and the WG LCs for early adoption occurred in Fall 2013, and from 1/16-1/27/2014.
WG has reached consensus due to strong implementation experience.

Document Quality

IDR has reviewed and discussed his document over 3 years (2011-2014),
and the protocol has the two implementations that the IDR WG requires
for standardization of BGP protocol features.  The two implementations are reported
in the document: draft-gredler-idr-ls-distribution-impl-00.pdf.

Review timeline:

A WG LC for this draft on 3/12-3/26/14. 

Personnel:
Document Shepherd for early assignment review: Susan Hares
Responsible AD: Alia Atlas
Shepherd: Jie Dong
QA Reviewer in RTG-DIR: Acee Linden [OK]
QA Reviewer in OPS-DIR: Ron Bonica [ok]
IANA review: Early QA REview done (3/14/2014, 10/30, 2014, 1/24/2015)

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

Draft was given early allocation per RFC 7120.
Shepherd and WG-Chair have reviewed draft in versions.
draft-ietf-idr-ls-distribution-012 was reviewed by WG-Chair due to
document shepherd leave for arrival of new baby.

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

No.

Operational deployments and discussion on list have found issues that have been
fixed.  QA reviews have been done by IANA, OPS-DIR, and RTG-Directorate.
Multiple versions have been reviewed.
Implementation have been fielded to customers.

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

This draft is the first of the wave of BGP drafts that consider putting extra information
into the BGP infrastructure of some portions of the network to supply new
service routing, or SDN-based calculations. If you have concerns about
BGP carrying this data, you should review this carefully.  However,
early interoperability testing, deployments, and results have convinced the
IDR WG.  (The WG chairs started out skeptical and has been convinced by
running code and operational experience. )

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

The document shepherd feels comfortable with all sections and the text
within the document.

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

IPR disclosed by Juniper.  The list
http://datatracker.ietf.org/ipr/1864/

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

Private Email has been sent to each author (3/4/14).
During WG LC, a public IPR public call will be sent (3/13 - 3/26)

(9) How solid is the WG consensus behind this document? 

Strong wide-spread consensus based on vendor implementations, early deployments,
and key responses.

(10) appeals and discontent: not seen

(11) Identify any ID nits the Document Shepherd has found in this
document. 

No nits found.

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

Not relevant for MIB Doctor, Media type, or URI.

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

Yes.

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


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

IANA - requests:
New AFI/SAFI - early allocation requested by this report
New BGP path attribute - under RFC 7120 this should occur.

New Registry for BGP LS node anchor, link descriptor, and link attribute TLVs
  0-255 are reserved
  256-65535 - code points
  (table 11 in document)

This new will need designated expert to be assigned by IESG (per RFC 5226)

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

New Registry for BGP LS node anchor, link descriptor, and link attribute TLVs
  0-255 are reserved
  256-65535 - code points
  (table 11 in document)

This new will need designated expert to be assigned by IESG (per RFC 5226)

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

No self-check required for XML, BNF, MIB definitions.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-ls-distribution-10.  Please report any inaccuracies and respond to the questions below as soon as possible. IANA also requests two edits to the document's IANA Considerations section.

IANA understands that, upon approval of this document, there are eight actions which IANA is required to complete.

First, IANA will update the reference for the following Address Family Number registration at https://www.iana.org/assignments/address-family-numbers:

16388 BGP-LS [RFC-to-be] 2013-03-20

REQUESTED EDIT: Section 5 says, "This document requests a code point from the registry of Address Family Numbers.  As per early allocation procedure this is AFI 16388." However, the term "early allocation" doesn't fit here. The "early allocation" procedure is a procedure defined by RFC 7120 that allows for a one-year temporary registration. 16388 was registered before this document was approved, but it's a permanent registration made in accordance with the registry's normal first-come, first-served procedure.

Can you change this paragraph to "This document has registered Address Family Number 16388, BGP-LS" or "This document is the reference for Address Family Number 16388, BGP-LS," or something along those lines?

Second, IANA will update the reference for the following SAFI Value registration at https://www.iana.org/assignments/safi-namespace:

71 BGP-LS [RFC-to-be]

REQUESTED EDIT: As above, this registration was not an early allocation, as defined by RFC 7120. (An example of an early allocation is BGP Path Attribute BGP-LS Attribute, which has an expiration date listed in the registry.) Please change "This document requests a code point from the registry of Subsequent Address Family Numbers named 'BGP-LS'.  As per early allocation procedure this is SAFI 71" to remove the reference to early allocation.

Third, also in the Subsequent Address Family Identifiers (SAFI) Parameters registry at

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

a new SAFI value will be registered as follows:

Value: [ RFC-to-be ]
Description: BGP-LS-VPN
Reference: [ RFC-to-be ]

QUESTION: The document notes that the value doesn't have to come from the 1-63 range, but doesn't specify which range to use. Does the registration belong in the 64-127 "First Come First Served" range, or in the 128-240 range marked "Some recognized assignments below, others Reserved"?

Fourth, the early allocation made by this document in the BGP Path Attributes registry at

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

will be made permanent. Value 29 will have its reference changed to [ RFC-to-be ].

Fifth, a new registry called the BGP-LS NLRI-Types registry will be created in the Border Gateway Protocol - Link State (BGP-LS) Parameters top-level registry at

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

The registry will be maintained via Specification Required as defined by RFC 5226.

Initial registrations:

+------+---------------------------+---------------+
| Type | NLRI Type | Reference |
+------+---------------------------+---------------+
| 0 | Reserved | [ RFC-to-be ] |
| 1 | Node NLRI | [ RFC-to-be ] |
| 2 | Link NLRI | [ RFC-to-be ] |
| 3 | IPv4 Topology Prefix NLRI | [ RFC-to-be ] |
| 4 | IPv6 Topology Prefix NLRI | [ RFC-to-be ] |
| 5-65535 | Unassigned
+------+---------------------------+---------------+

Sixth, a new registry called the BGP-LS Protocol-IDs registry will be created under the Border Gateway Protocol - Link State (BGP-LS) Parameters heading at

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

The registry will be maintained via Specification Required as defined by RFC 5226.

Initial registrations:

+-------------+----------------------------------+---------------+
| Protocol-ID | NLRI information source protocol | Reference |
+-------------+----------------------------------+---------------+
| 0 | Reserved | [ RFC-to-be ] |
| 1 | IS-IS Level 1 | [ RFC-to-be ] |
| 2 | IS-IS Level 2 | [ RFC-to-be ] |
| 3 | OSPFv2 | [ RFC-to-be ] |
| 4 | Direct | [ RFC-to-be ] |
| 5 | Static configuration | [ RFC-to-be ] |
| 6 | OSPFv3 | [ RFC-to-be ] |
| 7-255 | Unassigned
+-------------+----------------------------------+---------------+

Seventh, a new registry called the BGP-LS Well-known Instance-IDs registry will be created under the Border Gateway Protocol - Link State (BGP-LS) Parameters top-level  heading at

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

The registry will be maintained via Specification Required as defined by RFC 5226.

Initial registrations:

+------------+----------------------------------+---------------+
| Identifier | Routing Universe | Reference: |
+------------+----------------------------------+---------------+
| 0 | Default Layer 3 Routing topology | [ RFC-to-be ] |
| 1-31 | Reserved | [ RFC-to-be ] |
+------------+----------------------------------+---------------+

Eighth, a new registry called the Node Anchor, Link Descriptor and Link Attribute TLVs registry will be created under the Border Gateway Protocol - Link State (BGP-LS) Parameters heading at

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

The registry will be maintained via Specification Required as defined by RFC 5226.

Initial registrations:

+-----------+---------------------+---------------+-----------------+
| TLV Code Point | Description | IS-IS TLV/Sub-TLC | Reference |
+-----------+---------------------+---------------+-----------------+
| 0-255 | Reserved |[RFC-to-be ]
| 256 | Local Node Descriptors | --- | Section 3.2.1.2 |
| 257 | Remote Node Descriptors | --- | Section 3.2.1.3 |
| 258 | Link Local/Remote Identifiers | 22/4 | [RFC5307]/1.1 |
| 259 | IPv4 interface address | 22/6 | [RFC5305]/3.2 |
| 260 | IPv4 neighbor address | 22/8 | [RFC5305]/3.3 |
| 261 | IPv6 interface address | 22/12 | [RFC6119]/4.2 |
| 262 | IPv6 neighbor address | 22/13 | [RFC6119]/4.3 |
| 263 | Multi-Topology ID | --- | Section 3.2.1.5 |
| 264 | OSPF Route Type | --- | Section 3.2.3 |
| 265 | IP Reachability Information | --- | Section 3.2.3 |
| 266-511 | Unassigned
| 512 | Autonomous System | --- | Section 3.2.1.4 |
| 513 | BGP-LS Identifier | --- | Section 3.2.1.4 |
| 514 | OSPF Area ID | --- | Section 3.2.1.4 |
| 515 | IGP Router-ID | --- | Section 3.2.1.4 |
| 516-1023 | Unassigned
| 1024 | Node Flag Bits | --- | Section 3.3.1.1 |
| 1025 | Opaque Node Properties | --- | Section 3.3.1.5 |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area Identifier | variable | Section 3.3.1.2 |
| 1028 | IPv4 Router-ID of Local Node | 134/--- | [RFC5305]/4.3 |
| 1029 | IPv6 Router-ID of Local Node | 140/--- | [RFC6119]/4.1 |
| 1030 | IPv4 Router-ID of Remote Node | 134/--- | [RFC5305]/4.3 |
| 1031 | IPv6 Router-ID of Remote Node | 140/--- | [RFC6119]/4.1 |
| 1032-1087 | Unassigned
| 1088 | Administrative group (color) | 22/3 | [RFC5305]/3.1 |
| 1089 | Maximum link bandwidth | 22/9 | [RFC5305]/3.3 |
| 1090 | Max. reservable link bandwidth | 22/10 | [RFC5305]/3.5 |
| 1091 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection Type | 22/20 | [RFC5307]/1.2 |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link Group | --- | Section 3.3.2.5 |
| 1097 | Opaque link attribute | --- | Section 3.3.2.6 |
| 1098 | Link Name attribute | --- | Section 3.3.2.7 |
| 1099-1151 | Unassigned
| 1152 | IGP Flags | --- | Section 3.3.3.1 |
| 1153 | Route Tag | --- | [RFC5130] |
| 1154 | Extended Tag | --- | [RFC5130] |
| 1155 | Prefix Metric | --- | [RFC5305] |
| 1156 | OSPF Forwarding Address | --- | [RFC2328] |
| 1157 | Opaque Prefix Attribute | --- | Section 3.3.3.6 |
| 1158-65535 | Unassigned
+-----------+---------------------+---------------+-----------------+

IANA understands that these eight actions are the only ones required upon completion.

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 only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: REVISED Last Call:  (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'North-Bound Distribution of Link-State and TE 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
ietf@ietf.org mailing lists by 2015-04-08. 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 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 information.  This is information typically
  distributed by IGP routing protocols within the network.

  This document describes a mechanism by which links state and traffic
  engineering 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).





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ballot/


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

  http://datatracker.ietf.org/ipr/1864/

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'North-Bound Distribution of Link-State and TE 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
ietf@ietf.org mailing lists by 2015-04-01. 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 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 information.  This is information typically
  distributed by IGP routing protocols within the network.

  This document describes a mechanism by which links state and traffic
  engineering 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).





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ballot/


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

  http://datatracker.ietf.org/ipr/1864/

Status: Awaiting draft-07 rom authors

AD: Alia Atlas
WG chairs: Susan Hares, John Scudder
Shepherd: Jie Dong
QA Reviewer in RTG-DIR: Acee Linden [OK]
QA Reviewer in OPS-DIR: Ron Bonica [ok]
IANA review: Early QA REview done (3/14/2014, 10/30, 2014, 1/24/2015)

Implementation report:
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/

Specification of code points is stable with the implementation report
for juniper and cisco's implementation (2 per IDR WG requirements).

=========

1) RFC requested: Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. 

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
  current state of the connections within the network, including
  traffic engineering information.  This is information typically
  distributed by IGP routing protocols within the network.
  This document describes a mechanism by which links state and traffic
  engineering 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).
.

Working Group Summary

IDR has reviewed and discussed his document over 3 years (2011-2014),
and the WG LCs for early adoption occurred in Fall 2013, and from 1/16-1/27/2014.
WG has reached consensus due to strong implementation experience.

Document Quality

IDR has reviewed and discussed his document over 3 years (2011-2014),
and the protocol has the two implementations that the IDR WG requires
for standardization of BGP protocol features.  The two implementations are reported
in the document: draft-gredler-idr-ls-distribution-impl-00.pdf.

Review timeline:

A WG LC for this draft begins on 3/12-3/26/14. 

Early  review of this document will be requested of gen-art, operations directorate,
routing directorate, and of the ISIS WG starting on 3/12/14. It is anticipated that this package will be forwarded to Alia Atlas with on 3/27/14 for IESG review


Personnel
Document Shepherd for early assignment review: Susan Hares
Responsible AD: Alia Atlas


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

Draft is being forwarded for early allocation per RFC 7120.
Draft revision to catch shepherds, nits, and WG editorial comments posts IETF 89  is expected by 3/12/14, and then the final WG LC will occur for publication.

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

Operational deployments and discussion on list have found issues that have been
fixed. Shepherd will call for reviewers at IETF 89, and do targeted reviews
(Gen-ART, OPS-DIR, RTG-DIR, Security-DIR, ISIS WG, I2RS WG, IANA and specific key technical reviewers).

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

This draft is the first of the wave of BGP drafts that consider putting extra information
into the BGP infrastructure of some portions of the network to supply new
service routing, or SDN-based calculations. If you have concerns about
BGP carrying this data, you should review this carefully.  However,
early interoperability testing, deployments, and results have convinced the
IDR WG.  (This WG started out skeptical and has been convinced by
running code and operational experience. )


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

The document shepherd feels comfortable with all sections and the text
within the document.

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

IPR disclosed by Juniper.  The list
http://datatracker.ietf.org/ipr/1864/

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

Private Email has been sent to each author (3/4/14).
During WG LC, a public IPR public call will be sent (3/13 - 3/26)

(9) How solid is the WG consensus behind this document? 

Strong wide-spread consensus based on vendor implementations, early deployments,
and key responses.

(10) appeals and discontent: not seen

(11) Identify any ID nits the Document Shepherd has found in this
document. 

Id-nts occur with IP Addresses, previous year templates, and mis-refs.
It is anticipated that editorial version (-05) wll fix these issues.
Due to co-author Adrian Farrel

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

Not relevant for MIB Doctor, Media type, or URI.

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

Yes - but version 5 will need to fix the informative references that have been upgraded.

(14) /(15) normative references - all referenced ok. No downward references on normative.  Informative references

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


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

IANA - requests:
New AFI/SAFI - early allocation requested by this report
New BGP path attribute - under RFC 7120 this should occur.

New Registry for BGP LS node anchor, link descriptor, and link attribute TLVs
  0-255 are reserved
  256-65535 - code points
  (table 11 in document)

This new will need designated expert to be assigned by IESG (per RFC 5226)


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

New Registry for BGP LS node anchor, link descriptor, and link attribute TLVs
  0-255 are reserved
  256-65535 - code points
  (table 11 in document)

This new will need designated expert to be assigned by IESG (per RFC 5226)

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

No self-check required for XML, BNF, MIB definitions.

Status: Awaiting draft-07 rom authors

AD: Alia Atlas
WG chairs: Susan Hares, John Scudder
Shepherd: Jie Dong
QA Reviewer in RTG-DIR: Acee Linden [OK]
QA Reviewer in OPS-DIR: Ron Bonica
IANA review: Early QA REview done (3/14/2014, 10/30/2015) 

Implementation report:
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/

Specification of code points is stable with the implementation report
for juniper and cisco's implementation (2 per IDR WG requirements).

=========

1) RFC requested: Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. 

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
  current state of the connections within the network, including
  traffic engineering information.  This is information typically
  distributed by IGP routing protocols within the network.
  This document describes a mechanism by which links state and traffic
  engineering 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).
.

Working Group Summary

IDR has reviewed and discussed his document over 3 years (2011-2014),
and the WG LCs for early adoption occurred in Fall 2013, and from 1/16-1/27/2014.
WG has reached consensus due to strong implementation experience.

Document Quality

IDR has reviewed and discussed his document over 3 years (2011-2014),
and the protocol has the two implementations that the IDR WG requires
for standardization of BGP protocol features.  The two implementations are reported
in the document: draft-gredler-idr-ls-distribution-impl-00.pdf.

Review timeline:

A WG LC for this draft begins on 3/12-3/26/14. 

Early  review of this document will be requested of gen-art, operations directorate,
routing directorate, and of the ISIS WG starting on 3/12/14. It is anticipated that this package will be forwarded to Alia Atlas with on 3/27/14 for IESG review


Personnel
Document Shepherd for early assignment review: Susan Hares
Responsible AD: Alia Atlas


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

Draft is being forwarded for early allocation per RFC 7120.
Draft revision to catch shepherds, nits, and WG editorial comments posts IETF 89  is expected by 3/12/14, and then the final WG LC will occur for publication.

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

Operational deployments and discussion on list have found issues that have been
fixed. Shepherd will call for reviewers at IETF 89, and do targeted reviews
(Gen-ART, OPS-DIR, RTG-DIR, Security-DIR, ISIS WG, I2RS WG, IANA and specific key technical reviewers).

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

This draft is the first of the wave of BGP drafts that consider putting extra information
into the BGP infrastructure of some portions of the network to supply new
service routing, or SDN-based calculations. If you have concerns about
BGP carrying this data, you should review this carefully.  However,
early interoperability testing, deployments, and results have convinced the
IDR WG.  (This WG started out skeptical and has been convinced by
running code and operational experience. )


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

The document shepherd feels comfortable with all sections and the text
within the document.

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

IPR disclosed by Juniper.  The list
http://datatracker.ietf.org/ipr/1864/

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

Private Email has been sent to each author (3/4/14).
During WG LC, a public IPR public call will be sent (3/13 - 3/26)

(9) How solid is the WG consensus behind this document? 

Strong wide-spread consensus based on vendor implementations, early deployments,
and key responses.

(10) appeals and discontent: not seen

(11) Identify any ID nits the Document Shepherd has found in this
document. 

Id-nts occur with IP Addresses, previous year templates, and mis-refs.
It is anticipated that editorial version (-05) wll fix these issues.
Due to co-author Adrian Farrel

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

Not relevant for MIB Doctor, Media type, or URI.

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

Yes - but version 5 will need to fix the informative references that have been upgraded.

(14) /(15) normative references - all referenced ok. No downward references on normative.  Informative references

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


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

IANA - requests:
New AFI/SAFI - early allocation requested by this report
New BGP path attribute - under RFC 7120 this should occur.

New Registry for BGP LS node anchor, link descriptor, and link attribute TLVs
  0-255 are reserved
  256-65535 - code points
  (table 11 in document)

This new will need designated expert to be assigned by IESG (per RFC 5226)


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

New Registry for BGP LS node anchor, link descriptor, and link attribute TLVs
  0-255 are reserved
  256-65535 - code points
  (table 11 in document)

This new will need designated expert to be assigned by IESG (per RFC 5226)

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

No self-check required for XML, BNF, MIB definitions.