Last Call Review of draft-ietf-idr-aigp-16
review-ietf-idr-aigp-16-opsdir-lc-winter-2014-04-03-00

Hi,

I'm a first-time reviewer, please bear with me.

ops-dir review of 

http://www.ietf.org/id/draft-ietf-idr-aigp-16.txt


===================================================================

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
 These comments were written primarily for the benefit of the
operational area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

Intended status: Standards Track
Current draft status: IETF Last Call
IANA Review State: Actions needed (create registry for "BGP AIGP
Attribute Types")
IANA Action State: None
The draft is: ready with issues

Has deployment been discussed?
------------------------------
The document contains a Deployment Considerations section which covers
important points to consider.

The section's last paragraph makes clear that any route with AIGP (even
if it has a very bad metric) will be preferred over a route which does
not support/make use of the AIGP attribute. It is good it document that.
I think the document could be better though if it also discussed that
the AIGP attribute will only have a chance to have a positive effect on
routing if it is supported on all (or nearly all) routes; if it is
deployed only sparsely, this sparse overlay network will always carry
all traffic, leaving non-enabled routes empty. This would actually have
a detrimental effect on routing efficiency, which is counter to what the
document tries to achieve.

The deployment model has a "double opt-in" mechanism; the receiving end
of the route must be configured to accept the new attribute on a
per-session basis (default DISABLE for EBGP); and the sending end must
be configured to add this attribute (either via an automatic metric
calculation or by manual configuration of the value). This ensures that
no sender can cause harm on other routers on its own. It could be a
source of concern that for IBGP, the default is ENABLED, but the proto
write-up indicated that this has been discussed at length in the WG; so
I guess that this default was a conscious choice with understood
consequences.

The document is very clear that deployment on the general internet is
NOT in scope; the AIGP attribute is meant for use exclusively inside one
administrative domain (which for some reason needs to interconnect
multiple IGP islands via BGP). With that scope, scalability needs not be
considered as thoroughly as for general internet use. It is noteworthy
however that there is substantial manual configuration involved (quite
possibly spanning multiple vendors and configuration languages), which
is necessarily error-prone. Such a manual configuration may also become
stale; keeping it in sync with deployed reality may be quite
challenging. E.g. if I read a sentence like: "A BGP speaker MUST NOT add
the AIGP attribute to any route whose path leads outside the "AIGP
administrative domain" to which the BGP speaker belongs." - then I
wonder if a once-enabled route will actually be taken out of the
configuration if the "AIGP administrative domain" morphs (company
merger, split, other re-org). Also the requirement that all AIGP values
need to be comparable may be a tough requirement - this requires a
global view of the network across all IGP islands (and in my
understanding, this BGP extension is for cases where one global view
over all islands is not practical). There is however no concrete wording
which I could suggest for this draft; it's complex manual config, and
probably has to be. I would predict poor scalability, but can live with
that given the suggested deployment scope of the document.

There are no significant coexistence issues; routers not supporting the
attribute are supposed to silently discard the incoming unknown attribute.

Has installation and initial setup been discussed?
--------------------------------------------------
The document discusses configuration items, and their default values
appear reasonable. It is not clear if enabling/disabling and metrics
configuration is supposed to happen from a central management station or
incrementally "by hand" on a per-IGP basis. If the latter, the routing
algorithm may prefer unexpected routes while configuration is underway,
because the first links to come up with an AIGP attribute will get
preference over the not-yet-configured ones.

Has the migration path been discussed?
--------------------------------------
This topic is not mentioned explicitly in the document; transitioning
the administrative domain from a non-AIGP state to an enabled one is
left as an exercise to the reader. It might make sense for the document
to suggest that a specific order should be maintained: first disable all
receiving of the attribute everywhere, then configure all nodes in turn
to *send* their AIGP attribute (no changes on routing preference because
no receiver is going to consider it yet), and only then re-enable
receivers to process them; in that case, all attributes from all senders
will be known to the receiver from the start.

Has the impact on network operation been discussed?
---------------------------------------------------
Again, not being a routing expert: is it possible that an IGP protocol
dynamically changes a given route's metric, e.g. dynamically makes a
route more expensive if it discovers high link utilisation? If that is
the case, the metrics to be communicated in the AIGP attribute may
change very frequently, like on a sub-second basis. This would trigger
continuous updates and thrashing on the BGP export.

Management: is management information discussed?
------------------------------------------------
Provisioning of configuration data is not discussed. This can of course
be done via proprietary configuration means (say, SSH shell and typing
it in). I expect that this is the expected way of configuring; but
wonder if it would be worthwhile to include or work on a MIB definition
(old-style), or yang module.
Unfortunately, I cannot see from the idr working group charter if such
work is underway. The work items list mentions the AIGP work, but the
current milestone list on 

http://datatracker.ietf.org/wg/idr/charter/


ends at Mar 2011 - and does not mention the AIGP attribute work at all!
So it's impossible to see if there is accompanying work going on.

Non ops-dir General Questions
-----------------------------
3.2 Why is (only) 0xffffffffffffffff considered malformed? The reason
given is that it can't be incremented and is thus useless. While that's
true, being useless is not the same as being malformed. Also, section
3.4.3 states that increments are done by a value of A, not 1. So, a
value of 0xfffffffffffffffe is not very useful in many situations as
well; should it be considered "almost malformed" because it's "almost
useless" (except where A=1)? I suggest to either not designate the value
0xffffffffffffffff as malformed, or to change its definition to
"reserved value to indicate max-metric-size-reached" without the
"uselessness" explanation.

3: having an 8-Byte value may practically mean "arbitrary" amounts of
added 4-Byte values; but there is a theoretical limit which could be
mentioned (or not, I don't care much) - at least 2^32 such 4-Byte values
can be added; at most 2^64-1 ?

What is the purpose of the second and subsequent TLV? It shouldn't be
present, and it appears to be ignored as extraneous data if present
anyway? But then why does it have to be sent onwards verbatimly? In that
case, wouldn't it be better to require that only exactly one value is
present; and chop off extra values when seen?

Nit:

Section 3.3 mentions the term "confederation-EBGP", which is not
explained and no reference to its definition is provided next to it.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me



http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66




Attachment:


0x8A39DC66.asc




Description:

 application/pgp-keys




Attachment:


signature.asc




Description:

 OpenPGP digital signature