Skip to main content

Shepherd writeup
draft-ietf-idr-aigp

Short Shepherd write-up form (per Barry Leiba)

Shepherd report: version 2 (3/4/14)
RFC type: proposed standard:
Shepherd: Susan Hares (WG chair)
WG chairs: John Scudder and Susan Hares
AD: Stewart Bryant
draft-ietf-idr-aigp-14.txt: posted to the list on 12/16/13

Document announcement:

Technical

   Routing protocols that have been designed to run within a single
   administrative domain ("IGPs") generally do so by assigning a metric
   to each link, and then choosing as the installed path between two
   nodes the path for which the total distance (sum of the metric of
   each link along the path) is minimized.  BGP, designed to provide
   routing over a large number of independent administrative domains
   ("autonomous systems"), does not make its path selection decisions
   through the use of a metric.  It is generally recognized that any
   attempt to do so would incur significant scalability problems, as
   well as inter-administration coordination problems.  However, there
   are deployments in which a single administration runs several
   contiguous BGP networks.  In such cases, it can be desirable, within
   that single administrative domain, for BGP to select paths based on a
   metric, just as an IGP would do.  The purpose of this document is to
   provide a specification for doing so.

Working Group Summary

The working actively reviewed this draft considering the following:

a) error handling with malformed packets or malformed transitive bits,
b) placement of AIGP TLV in the draft;
c) default setting for AIGP_SESSION on IBGP setting at SHOULD be "enabled"
  (AIGP_SESSION aids flagging the AIGP packets exiting the
   restricted environment to the wild),

d) AIGP value is capped at maximum. This value cannot wrap, and
   any attempts to increase it past its maximum is treated as
   a malformed packet, and
e) TLV formatting..

Discussions were active since 9/27 with authors responding until all WG
participants were satisfied. The draft-ietf-idr-aigp-14.txt was

Document quality:

This  WG draft has been implemented by 3 vendors (including Juniper and Cisco),
and seen deployment in ISPs.  The debates around this draft have been resolved
by the authors by the -14 draft. Shepherd did editorial pass on the draft, and
the authors address the nits that shepherd found.

Reviews:

Reviewers on the list were interested and complete in their review. The
reviewers on the IDR list included long-time experts, newer implementers,
deployment and research.  While additional review is always good, this was a
good review.

IPR LC was done based on two disclosures from cisco:
id #1159, #1160.  No concerns were raised.

Reviews done:

Early OPS-IDR review by Ron Bonica resulted in several changes, and Ron Bonica
approving the document.  An Early IANA Review also resulted in changes. No
comments were received from an early request for a Routing Directorate review.
No MIB Doctor review is relevant for this review outside an OPS-DIR review.

[6] specific concerns or issues that the Document Shepherd has:

The key issue is that the misconfiguration (error or malfeasance) can cause
selection of paths other than desired.  The focus of the misconfiguration is
the ability to generate an  unrecognized non-transitive attribute by erroneous
configuration.

EBGP could cause this to float between service providers. This specification
has knobs, but the risk/reward choice must be made per AS, and per AS pair. 
This is an optional attribute.  [This is the rope + chair = lion tamer or
hang-man argument.]

Ron also asked whether an IGP change could cause an excessive amount of BGP
activity.  The authors feel this is not an issue due to the draft's
applicability being restricted to a single "AIGP Administrative Domain", and we
have specified constraints that prevent AIGP from being attached to customer
routes or to Internet routes.

The constraints are do not use unless the routes are:
a) static route into BGP, not leading outside the AIGP
       administrative domain, that is being redistributed into BGP;
b) IGP route into BGP
c) IBGP route with empty AS_PATH
d) EBGP with specific set of AS numbers (see AD domain)

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

A 2 Week IPR last call has been made (1/8 - 1/22/14), and no additional IPR
outside of #1159, and #1160 were added.

(8) Has an IPR disclosure been filed that references this document?

The IPR on the draft (#1159, #1160)  has been listed since the draft was
published in 2009. No concerns were given raised.

[9]    WG consensus: Strong
[10]  Appeal threatened or possible: not likely
[11]  id nits run -
Only warning now is older date.  However, this was delayed due to transition
in ADs.

[12] Formal review:

Should formally ask for IANA review, OPS-DIR review, and Routing Directorate
review.

(13) References:
a) all normative or informative

Question: Is RFC 2119 informative or informative?

(14) Normative references: all ready to go
(15) Informative references

  [ADD-PATH] "Advertisement of Multiple Paths in BGP", D. Walton, A.
   Retana, E. Chen, J. Scudder, draft-ietf-idr-add-paths-09.txt, October
   2013. - WG LC awaiting 2 implementations

   [BESTEXT], "Advertisement of the Best External Route in BGP", P.
   Marques, R. Fernando, E. Chen, P. Mohapatra, H. Gredler, draft-ietf-
   idr-best-external-05.txt, January 2012. - pending, awaits 2 implementations

   [BGP-ERROR] "Revised Error Handling for BGP UPDATE Messages", J.
   Scudder, E. Chen, P. Mohapatra, K. Patel, draft-ietf-idr-error-
   handling-04.txt, June 2013. [3 implementations, pushing author].

(15) downward normative references: No

(16) Publication of this document  does not change the status of any
existing RFC.

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

An early IANA Review is being request based on addition lf
BGP AIGP Attribute Type (code point 26), and
a new registry for the BGP AIGP attribute types.

[18] The two registry actions.

Existing registry: BGP Path Attributes  - for AIGP new code point
New registry: BGP AIGP Attribute Types - for AIGP Type in TLV

Both are standard actions for early allocation requiring the IDR WG to review
and propose assignment for IESG and IANA Review.  No additional expert is
needed.

(19) nits - run on draft, no issues

Back