Version: 24 February 2012.
AD: Alvaro Retano
Shepherd: Susan Hares
Co:Chairs: Susan Hares, John Scudder
WG LC: 1/19/2015 to 2/5/2015
IPR Second call: (2/5 to 3/15/2016)
Sent to IESG: 3/15/2016
(1) type of RFC: Standards:
Why Standards: Specifies a new BGP optional transitive attribute
(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
Network administrators typically enforce Quality of Service (QoS)
policies according to Service Level Agreement (SLA) with their
providers. The enforcement of such policies often relies upon
vendor-specific configuration language. Both learning of SLA, either
thru SLA documents or via some other out-of-band method, and
translating them to vendor specific configuration language is a
complex, often manual, process and prone to errors.
This document specifies an optional transitive attribute to signal
SLA parameters in-band, across administrative boundaries (considered
as Autonomous Systems (AS)), thus simplifying and facilitating some
of the complex provisioning tasks in situations where BGP is
available as a routing protocol.
Working Group Summary
WG approved after 2-3 years of discussion.
The WG discussion is provided as question answers for brevity:
Should policy be sent in BGP Updates? BGP Flow Specification sends policy and it
has not caused issues.
What is Expected deployment? Service Providers that negotiate
SLAs out-of-band in order to reduce configuration.
What about Yang versus BGP:? The existence of BGP Flow Specification
with BGP Yang modules proposals for BGP Flow specification indicates that
it is not "either yang or BGP" but both. This will be one of the
extended BGP yang modules with configuration and operational state.
What type of state does the BGP SLA create: BGP Session ephemeral
state which is more ephemeral than I2RS reboot state.
Document Quality
Are there existing implementations of the protocol?
https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20implementations
TSWG QA Review: David Black - change to IPFIX references to SLA based on his work.
https://mailarchive.ietf.org/arch/search/?email_list=idr&q=sla-exchange
RTG-DIR QA Reviewer: Bruno Decraene
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02593.html
Document Shepherd: Susan Hares
AD: Alvaro Retana
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.
a) Early discussion with David Black and TSWG on diff-serv code points used
b) Shepherd did extensive discussion with authors to correct
English text in the document,
c) Bruno Decraene - gave excellent technical review (5/18-May-2015)
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02593.html
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No, these review worked through the document, and discussed the
implementation review. We spent almost a year in getting the
text in shape. This shepherd will do this on the front-end of
WG LC next time.
(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.
OPS-DIR and SEC-DIR should review this document as
similar to BGP Flow Specification, it is passing policy within BGP Updates.
The use of ROA to validate the insertion of the Policy (section 9)
or BGPSEC to secure the whole stream (section 9) is listed as a "MAY"
due to the assumption that many of the BGP peer sessions are on
private Provider exchanges which are P2P. In such point, the risk of
attack is lessened by physical restriction of connectivity.
However, it is important that OPS-DIR and SEC-DIR consider whether
the "MAY" should be strengthened to a "SHOULD".
(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?
After years with BGP Flow Specification deployments being wisely handled,
and bgp-ls-distribution being handled, the document shepherd is
not concerned about putting policy in BGP or the overload of data.
The authors and Shepherd spent time working through initial concerns
with key reviewers when on-list review was not as strong as wished.
In the future, this shepherd will do the process before WG LC rather
than after WG LC. This draft has been sent to the WG for a final
textual review.
(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.
WG LC:
https://mailarchive.ietf.org/arch/msg/idr/wyVYai_ole4l6pJGY84IQoMXRAM
Shitsanshu Shah IPR statement:
https://mailarchive.ietf.org/arch/msg/idr/irN9TCfZ_Sz_czSk5BxtuLzppFgmohamed.boucadair@orange.comhttps://mailarchive.ietf.org/arch/msg/idr/UQmWunLqxxPP1EWpUyj0Pb_uaXg
Keyur Patel
[not listed]
S. Bajaj
[not listed]
L. Tomotaki
[not listed]
(8) Has an IPR disclosure been filed that references this document?
Unusually IPR has been disclosed not by the authors:
https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xOm1Vz_HNdAM3P250
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
The IPR was disclosed before WG LC, and a second
call was done in 2016 after all editing to make sure no problems occurred.
Shepherd/co-Chair review with co-chair (John Scudder) and
felt the IPR review by the WG was sufficient. The thread is at:
https://www.ietf.org/mail-archive/web/idr/current/msg15342.html
(9) How solid is the WG consensus behind this document?
Does it represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
This represents a strong convergence of the providers and vendors interested in this document,
and a "no objection" from other providers. This type of convergence is
normal for optional transitive attribute that is not going to be utilized by providers.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
No malcontent or concern. This draft is seen as a target solution for a group
of providers.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
ID-nits - find the sidr-bgpsec protocol draft is downref. However,
I-D.ietf-sidr-bgpsec-protocol has passed WG LC and is in the process of
IESG standardization.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No MIB. Yang module will follow this document as an extension to BGP yang modules.
(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?
The sidr-bgpsec protocol draft is downref for informative reference. However,
I-D.ietf-sidr-bgpsec-protocol has passed WG LC and is in the process of
IESG standardization.
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No downref normative references.
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
No, this is an additional BGP optional transitive attribute.
(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 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.
(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.