The Accumulated IGP Metric Attribute for BGP
draft-ietf-idr-aigp-18

[Ballot comment]
Aside from this relatively minor nit, which I express as a DISCUSS solely because of the tiny potential for interoperability issues, the document looks good and is clear and understandable, at least to the limits of my comprehension of routing documents. :)

Former DISCUSS text:
In section 3, isn't Accumulated IGP Metric a 64-bit (unsigned?) integer expressed in network byte order?  The current text suggests that IGP metrics might be added together to produce the AIGP metric, but without specifying a representation, I don't see how you can have interoperability.  The current text could as easily apply to an 8-octet ascii string, for instance.  I realize that this is a bit obvious, but it seems easy and harmless to fix.

This DISCUSS should be easy to address, either by specifying the data representation, or by pointing out to me why that's a bad idea.

[Ballot comment]

-
  When an AIGP attribute is created, it SHOULD contain no more than one
  AIGP TLV.  However, if it contains more than one AIGP TLV, only the
  first one is used as described in Section 3.4 and Section 4.  In the
  remainder of this document, we will use the term "value of the AIGP
  TLV" to mean the value of the first AIGP TLV in the AIGP attribute.
  Any other AIGP TLVs in the AIGP attribute MUST be passed along
  unchanged if the AIGP attribute is passed along.

Like Stefan in his OPS-DIR, I was confused by this.
Figure 1 only shows one TLV.
And the spec. says: SHOULD contain no more than one TLV
But if there is more than one, don't pay attention to it.
I saw Eric's answer:

    This allows for a future expansion in which additional TLVs can be appended
    without impacting path selection in nodes that don't understand the
    additional TLVs.

It's in line with "Be conservative in what you send, be liberal in what you accept", but looks weird.
I read this as: I have some protocol extensions in mind, so let me prepare the spec for multiple TLVs, but I won't mention those in this spec. Or maybe I missed something (maybe this is common practice for BGP attributes?)
If not,
1. the writeup mentions implementations, which is a good thing
2. this is only a comment
are two good reasons to ignore this, unless you feel like replying.

-
  This document only considers the use of the AIGP attribute in
  networks where each router uses tunneling of some sort to deliver a
  packet to its BGP next hop.  Use of the AIGP attribute in other
  scenarios is outside the scope of this document.

Don't you need stronger RFC 2119 wording here?
  The AIGP attribute MUST only be applied if each router uses tunneling
  of some sort to deliver a packet to its BGP next hop.

- Editorial. First occurrence of AIGP:

  We will refer to the set of
  ASes in a common administrative domain as an "AIGP Administrative
  Domain".

A in AIGP = AS?
Well, no, if we pay attention the title, A = Accumulated

[Ballot discuss]
In section 3, isn't Accumulated IGP Metric a 64-bit (unsigned?) integer expressed in network byte order?  The current text suggests that IGP metrics might be added together to produce the AIGP metric, but without specifying a representation, I don't see how you can have interoperability.  The current text could as easily apply to an 8-octet ascii string, for instance.  I realize that this is a bit obvious, but it seems easy and harmless to fix.

This DISCUSS should be easy to address, either by specifying the data representation, or by pointing out to me why that's a bad idea.

[Ballot comment]
Aside from this relatively minor nit, which I express as a DISCUSS solely because of the tiny potential for interoperability issues, the document looks good and is clear and understandable, at least to the limits of my comprehension of routing documents. :)

[Ballot comment]
3.3/3.4.1: I really don't like MUSTs and SHOULDs for configuration items. Blech! Ptew! I'd much rather see an explanation of expected *behaviors* (with as many MUSTs and SHOULDs as you like) and leave the configuration items as "implementation advice". This one I find especially silly:

  It SHOULD be possible to set AIGP_ORIGINATE to "enabled for the
  routes of a particular IGP that are redistributed into BGP" (where "a
  particular IGP" might be "OSPF" or "ISIS").

But, now having tilted at that windmill, I will move on with my day.

3.4.1:

  The AIGP attribute may be added only to routes that satisfy one of
  the following conditions:

Should that be, "The AIGP attribute MUST NOT be added to routes unless they satisfy one of the following conditions"? Seems like a straightforward requirement to me, unless I'm misunderstanding what this is trying to say. Is this just a definition, or are you telling implementations that they ought not apply the attribute to other routes even though they might want to?

[Ballot comment]
No objection to this document, but the shepherd write-up seems to be truncated at one position under Working Group Summary :
"The draft-ietf-idr-aigp-14.txt was"

Not sure if this is a left-over or if any information is missing.

[Ballot comment]
I agree with Alissa that there should be a mention of the possibility of leakage in the Security Considerations section. 

Although the scope is limited to an administrative domain boundary, a statement is made in Section 2, that says "The specified procedures prevent the AIGP attribute from "leaking
  out" past an AIGP administrative domain boundary into the Internet." 

Section 3.3 tells you what to do when you receive this value where it is not expected, so clearly there is a way to handle the possibility of leakage. - and -
Section 3.4.1 seems to cover the restrictions of sending this value, limiting it to an administrative domain.

It's a little confusing to have the document state that leakages are prevented and then having a way to handle the leakage.  A mention of the possibility appearing in the security considerations section could be helpful.

[Ballot comment]
In Section 7, it seems like improper configuration on both ends of an EBGP connection could result not only in unsound path selection, but also in the leakage of information outside of an administrative domain that was meant to be kept inside. Might be worth a mention.

[Ballot comment]
I am happy to support this well-written document.

Pedantry alert!
Section 3 has...
      The value field of the AIGP TLV is always 8 bytes long.  IGP
      metrics are frequently expressed as 4-octet values, and this
      ensures that the AIGP attribute can be used to hold the sum of an
      arbitrary number of 4-octet values.
Well, of course, the number of 4-octet values containing the value zero can be arbitrary, but otherwise "a very large number" would be more accurate than "an arbitrary number".

I think that section 7 could expand on the relationship between ASes. In particular, this mechanism provides a way for a bad actor to attract traffic. However, since the advice is to apply this mechanisms only to ASes within a single administration, this issue is not significant. You could make both of these points and move on.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-aigp-16.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.  However we have an editorial question about
the name of the requested new registry.

First, in BGP Path Attributes subregistry of the Border Gateway Protocol (BGP) Parameters registry located at:

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

the value 26 had a temporary, early assignment. This assignment should now be made permanent as follows:

Value: 26
Code: AIGP
Reference: [ RFC-to-be ]

Second a new registry called the "BGP AIGP Attribute Types" registry will be created in the Border Gateway Protocol (BGP) Parameters registry located at:

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

QUESTION: Should the acronym "AIGP" in the name "BGP AIGP Attribute
Types" be expanded to "Accumulated IGP Metric Attribute for BGP"
to become "Accumulated IGP Metric Attribute for BGP Attribute Types"
or "BGP Accumulated IGP Metric Attribute Types"?

Values in this registry will integers in the range of 0-255 inclusive. Maintenance of the registry will be done via Standards Action as defined in RFC 5226.

The value 0 will be marked as reserved with a reference of [ RFC-to-be ].

There is a single initial registration in the new registry as follows:

Value: 1
Attribute Type: AIGP
Reference: [ RFC-to-be ]

IANA 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 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: Last Call:  (The Accumulated IGP Metric Attribute for BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'The Accumulated IGP Metric Attribute for 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 2014-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


  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.





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

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


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

  http://datatracker.ietf.org/ipr/1160/
  http://datatracker.ietf.org/ipr/1159/

As part of my standard processing for progressing routing drafts, I do a review of drafts before requesting IETF Last Call or progressing the draft. 

This is a well-written clear draft.  I do have a few comments and clarifying questions, as below.
Once you have responded and we've resolved this concerns, I'll be happy to progress the draft.

1) In Sec 3., it says " The value field of the AIGP TLV is always 8 bytes long. IGP metrics are frequently expressed as 4-octet values, and this ensures that the AIGP attribute can be used to hold the sum of an arbitrary number of 4-octet values."  How does this interact with the values used to indicate either infinity or a max metric in the IGP?  For instance, these are used with RFC3137 in OSPF where the ISIS overload bit isn't available.  It is also common to cost-out a link that has planned maintenance to migrate traffic. 

2) In Sec 3.1, it says " This document only considers the use of the AIGP attribute in networks where each router uses tunneling of some sort to deliver a packet to its BGP next hop. Use of the AIGP attribute in networks that do not use tunneling is outside the scope of this document."
I assume this means that the end-point of the tunnel must be the BGP next-hop, but the text doesn't clearly say so.  Could you please verify and update the text?  For instance:
"This document only considers the use of the AIGP attribue in networks where each router has a tunnel terminating at the BGP next hop and those tunnels are used to deliver the packets to their BGP next-hops.  Use of the AIGP attribute in networks that do not use such tunnels is outside the scope of this document."

3) In Sec 3.2, it says " If an AIGP attribute is received, and its first AIGP TLV contains the maximum value 0xffffffffffffffff, the attribute SHOULD be considered to be malformed, and discarded as specified in this section. (Since the TLV value cannot be increased any further, it is not useful for metric-based path selection.)"

I'd like to explore this a bit further.  By discarding the AIGP TLV with the max value, you are discarding what is useful information - do not use this path.  Can you explain why it is preferable to use a path that is costed-out compared to a BGP path without the AIGP distance?

4) In Sec 3.4.2, in addition to dampening based upon a threshold for the difference in value, I would expect to see some words about dampening in terms of frequency of updates.  Where the value is from the IGP, I can see that dampening might come from the SPF backoffs in the IGP, but at least some words around dampening the frequency would be quite good. 

5) In the IANA considerations,  is there any downside to having a small section of the range set to experimental?

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