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