Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

From: "Susan Hares" <[email-masked]>
Date: Fri, 13 Sep 2013 19:12:43 -0400

This is to start at 2 week WG last call for 

The Accumulated IGP Metric Attribute for BGP

draft-ietf-idr-aigp-10.txt

http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/

This last call will end 9/27/13 

Three implementations exist: ALU, Cisco, Juniper. 

Vote early and speak often. 

Sue and John 

IDR co-chairs

---

From: <[email-masked]>
Date: Tue, 24 Sep 2013 14:32:51 +0000

Hi,

1) A question for my own culture, regarding TLV encoding:

draft-ietf-idr-aigp defines the Length field as
"Length: Two octets encoding the length in octets of the TLV, including the type and length fields."

Is there any reason to include the type and length?
Especially since, IS-IS and ISO defines the length of TLVs as the length of the Value field.

This translates into (IMHO) less intuitive usage and notes, e.g.
- "(Note that the minimum length is 3,  indicating that no value field is present.)"
- "Length: 11" [...] "The value field of the AIGP TLV is always 8 bytes long."

Is there an IETF or routing area recommendation for encoding the length field of TLVs?

2) Please find below some additional comments:
- "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.'
Strictly speaking, I'm not sure that the word "arbitrary" is true.

- "The default value of AIGP_SESSION, for IBGP and confederation-EBGP sessions, MUST be "enabled."
IMHO the "MUST be enabled by default" is questionable. IMHO people wanting AIGP should be able to configure it. And people not wanting the attribute, should have nothing to do.
And IMHO if I were using AIGP, I would rather call for a global cli enabling AIGP on all IBGP/confederation-EBGP sessions.

- Error handling
>From my reading of draft-ietf-idr-error-handling, a length error in the AIGP attribute (which seems doable as per the first comment) would result in "treat-as-withdraw".
Is this the desired behavior?
"attribute discard" may be more appropriate given the following text:
 "If a Route Reflector supports the AIGP attribute, but some of its
   clients do not, then the routing choices that result may not all reflect the intended routing policy."

- list of ASes in the AIGP Administrative Domain
[The AIGP attribute] "may be added only to routes that satisfy one of the following conditions:
[...]
The route is an EBGP-learned route whose AS_PATH contains only ASes that are in the same AIGP Administrative Domain as the BGP speaker."

This seems to mandate that implementations MUST support a configuration item listing the ASes numbers which are part of the AIGP AD.

- references
" Thus is it highly recommended that the procedures of
   [BESTEXT] and [ADDPATH] be used in conjunction with the AIGP
   Attribute."

Shouldn't [BESTEXT] and [ADDPATH] be normative references?
Usually the name [ADDPATH] refers to "draft-ietf-idr-add-paths" and not to "draft-pmohapat-idr-fast-conn-restore". Hence IMHO, I find the name of the reference misleading.

Thanks,
Regards,
Bruno

-------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Saturday, September 14, 2013 1:13 AM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

Sue and John 
IDR co-chairs 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Tony Li <[email-masked]>
Date: Tue, 24 Sep 2013 09:11:18 -0700

> Is there an IETF or routing area recommendation for encoding the length field of TLVs?

I've never seen one and I've never seen a strong argument for including or not including the type and length fields in the count.

There are some trivial arguments, but nothing that is compelling, so it seems to be up to the authors.  

The arguments that I can think of:

- Be consistent with the remainder of the protocol.

- There is some programming ease when parsing if the length does not include the type and length fields.  This allows you to just load the length field and use it directly in iteration across the value.  This save a whole '- 3'.  Not a big deal.

- You actually lose 3 bytes of potential payload.  For a 1 byte length field, this is of course more of a concern.

Again, nothing worth arguing about.

Tony

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 24 Sep 2013 18:00:38 +0100

Hello,

Sorry, I did not know about this draft before today - hence the late comments.

> Again, nothing worth arguing about.

I was thinking _exactly_ the same thing. As this TLV was clearly created to allow the creation of other TYPE later, I think it should be done right ! Even without speaking of other protocol, it is not consistent with the rest of the protocol... the BGP header only contain the size of the BODY, etc.

As I like the idea, I believe it should be done right.
Otherwise why bother, as AIGP is a double size MED and could have be encoded as such !

>   clients do not, then the routing choices that result may not all reflect the intended routing policy."

I agree.

As well, should the document reserve all the known attributes values, should someone at a later date unify the presentation of attributes within TLV.
This would clearly require the value of 1 for AIGP to be changed.

Sincerely,

Thomas

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 24 Sep 2013 18:43:49 +0100

> This would clearly require the value of 1 for AIGP to be changed.

At first reading I assumed that the TLV code namespace would be global (but it does not seems to be the intend of the authors).
So this comment is moot.

Thomas

---

From: Eric Rosen <[email-masked]>
Date: Tue, 24 Sep 2013 15:34:01 -0400

>    draft-ietf-idr-aigp defines the Length field as "Length: Two octets
>    encoding the length in octets of the TLV, including the type and length
>    fields." 

> Is there any reason to include the type and length?

After five years and at least three implementations, there would need to be
a very strong technical justification for changing the encoding.

> "The default value of AIGP_SESSION, for IBGP and confederation-EBGP
> sessions, MUST be "enabled."  IMHO the "MUST be enabled by default" is
> questionable.  IMHO people wanting AIGP should be able to configure it. And
> people not wanting the attribute, should have nothing to do.

If you leave the AIGP_SESSION and AIGP_ORIGINATE parameters at their default
values in all your routers, then you will never attach an AIGP attribute to
any prefix, and you will discard any AIGP attribute that arrives from
another administrative domain.  So I think the draft meets your requirement,
i.e., if you don't want to use AIGP you don't have to do anything.

If you do want to attach AIGP to a prefix, you have to configure it at the
routers that originate routes to that prefix.

The purpose of AIGP_SESSION is to ensure that you ignore AIGP attributes
that mistakenly leak out of other administrative domains.

> And IMHO if I were using AIGP, I would rather call for a global cli
> enabling AIGP on all IBGP/confederation-EBGP sessions.

That would be a very reasonable request to make of your vendor.

> From my reading of draft-ietf-idr-error-handling, a length error in the
> AIGP attribute (which seems doable as per the first comment) would result
> in "treat-as-withdraw".

I have the same interpretation.

> Is this the desired behavior?

I don't see a problem with it.

---

From: "Dickson, Brian" <[email-masked]>
Date: Tue, 24 Sep 2013 20:07:23 +0000

I have briefly skimmed the document, and in-line below, have comments.

>routers that originate routes to that prefix.

Here's where IMHO things break down:

It violates the "two missile key" approach to networking, even if it is
intended to be limited to iBGP or confederations.

This basically boils down to presuming that "should not" is equivalent to
"will not", in operational environments.
How many times must large networks collapse before vendors and/or
standards stop making this assumption?

I'd be happy to point the authors at a variety of cases where introducing
something new/different in the transitive environment broke things.
Breaking things can have global-Internet-scale impact, even if it was not
the intention. A session reset between IBGP speakers WILL cause EBGP
traffic collapse, if the IBGP speakers were also both EBGP speakers. IBGP
is full mesh, and there would not be any alternative path for BGP prefixes
heard by one, sent to the other, and announced to EBGP neighbors. A
session reset is a withdraw-trigger.

Yes, this AIGP is intentionally limited to self-originated prefixes, but
is still potentially hazardous.

At a minimum, the AIGP_SESSION should be dependent on validating the
peer's ability to not do session resets (e.g if/when the new error
handling standard is implemented, that the capability is known to be
running on the peer).

Otherwise, this creates a place where unilateral activity by a single
individual, has the potential to cause harm to large networks.

E.g. suppose a heterogenous network (of multiple vendors and/or multiple
hardware platforms and/or multiple firmware revisions) has one or more
AIGP-capable routers introduced into it. Further suppose that some subset
of the non-AIGP-capable routers does not handle unknown attributes nicely.
If the AIGP-capable routers default to AIGP_SESSION enabled, then the only
thing preventing a network calamity is the installation of an
AIGP_ORIGINATE parameter. This is a single step, which could be done by
e.g. a network administrator either intentionally experimenting with new
features, or by accidentally hitting return while doing "command
completion" to discover the syntax of new commands.

While it is a PITA, having to configure both ends of a peering session for
every pair of routers is the only way to be safe from single-command
catastrophe.

>that mistakenly leak out of other administrative domains.

Again, this presumes that "ignore" functionality works as expected. What
happens when the attribute is attached to prefixes that get reflected by
route-reflectors? The identity and status of recipients is not necessarily
obvious, if there are reflectors involved, which may lead to unintended
outages.

Other than the DEFAULT state of the session parameter, I don't see
anything big (perhaps the TLV thing that Tony pointed out).

Brian

---

From: <[email-masked]>
Date: Wed, 25 Sep 2013 07:15:02 +0000

Eric,

>a very strong technical justification for changing the encoding.

I agree with you.
However, to clarify, that was neither my question (is there any reason for preferring one option or the other) nor my point (for my information; for future documents/usages).
To come back to my question, I guess your answer is "no".

>I don't see a problem with it.

The problem is that in case of error, you withdraw the route -which is usually used- while you could only withdraw the attribute -which apparently is not required (to be consistent within the AS)-. 

That being said, if this is intended, I'm fine with this because I'm not using it.

Thank you
Bruno

---

From: Thomas Mangin <[email-masked]>
Date: Wed, 25 Sep 2013 09:57:36 +0100

Hello Eric,

>> a very strong technical justification for changing the encoding.

I found the positive answer for you :-)

At the point you are parsing the TLV, all the data has already been read, so the value is not here to provide a number of bytes to read but to provide the location of the separation in the read buffer.
so by having the size, you have the offset at which to split the buffer ... It is therefore simpler than having the size of the data.

For the other points .. we are still not agreeing, but I fear that nothing I can say can change your mind if you are trying to get the feature in the hands of users in a timely fashion.

Thomas

---

From: Eric Rosen <[email-masked]>
Date: Wed, 25 Sep 2013 11:00:40 -0400

Eric> After five years and at least three implementations, there would need
Eric> to be a very strong technical justification for changing the encoding.

Bruno> I agree with you.  However, to clarify, that was neither my question
Bruno> (is there any reason for preferring one option or the other) nor my
Bruno> point (for my information; for future documents/usages).  To come
Bruno> back to my question, I guess your answer is "no".

There is no particular reason why the draft specifies one TLV encoding
rather than another, and I'm not aware of any document recommending a
particular encoding technique.

> in case of error, you withdraw the route -which is usually used- while you
> could only withdraw the attribute -which apparently is not required (to be
> consistent within the AS)

I can't say that I have strong feelings about this one way or the other.

Bruno> Shouldn't [BESTEXT] and [ADDPATH] be normative references?

I don't think so, as they are not strictly required in order to implement
AIGP.

Bruno> Usually the name [ADDPATH] refers to "draft-ietf-idr-add-paths" and
Bruno> not to "draft-pmohapat-idr-fast-conn-restore"

I will change the reference name.

draft> [The AIGP attribute] "may be added only to routes that satisfy one of
draft> the following conditions:  [...]  The route is an EBGP-learned route
draft> whose AS_PATH contains only ASes that are in the same AIGP
draft> Administrative Domain as the BGP speaker."

Bruno> This seems to mandate that implementations MUST support a
Bruno> configuration item listing the ASes numbers which are part of the
Bruno> AIGP AD.

I think there are a variety of ways to meet this condition without having
such a configuration item.

---

From: "Gaurav Dawra (gdawra)" <[email-masked]>
Date: Wed, 25 Sep 2013 15:02:16 +0000

Support.

Thanks,
-Gaurav

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 13, 2013 4:12 PM
To: idr wg <[email-masked]<mailto:[email-masked]>>
Cc: "'John G. Scudder'" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

Sue and John
IDR co-chairs

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Wed, 25 Sep 2013 15:29:09 +0000

Support,

Just to mention, at Cisco we do support AIGP on both IOS Classic OS and XR OS, therefore we should consider this as 2 separate BGP implementations.

Therefore we talking about 4  implementations.

BRGDS Bertrand

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gaurav Dawra (gdawra)
Sent: mercredi 25 septembre 2013 17:02
To: Susan Hares; idr wg
Cc: 'John G. Scudder'
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

Support.

Thanks,
-Gaurav

Sue and John
IDR co-chairs

---

From: Bhavani Parise <[email-masked]>
Date: Wed, 25 Sep 2013 08:43:16 -0700

support

regards,
Bhavani

On 9/13/13 4:12 PM, Susan Hares wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Eric Rosen <[email-masked]>
Date: Wed, 25 Sep 2013 11:48:04 -0400

Brian> I'd be happy to point the authors at a variety of cases where
Brian> introducing something new/different in the transitive environment
Brian> broke things.

What is meant by "the transitive environment"?

The AIGP attribute is a non-transitive attribute, so it won't generally get
passed along by BGP speakers who don't understand it.  Thus it shouldn't be
subject to the "each BGP speaker passes it along and then crashes" problem
that we sometimes see with new transitive attributes.

Brian> It violates the "two missile key" approach to networking

Eric> The purpose of AIGP_SESSION is to ensure that you ignore AIGP
Eric> attributes that mistakenly leak out of other administrative domains.

Brian> Again, this presumes that "ignore" functionality works as expected.

If you receive an AIGP attribute from another administrative domain, then
a mistake has been made on the other side of your BGP session.  AIGP_SESSION
is the "second missile key" that you seem to want in this case; it protects
you if you understand the non-transitive attribute but don't want to receive
it on a particular session.

However, I have no particular objection to changing the default value of
AIGP_SESSION if it is the consensus of the WG that it should always default
to "disabled".  I am skeptical though that it will have much of a protective
effect on internal BGP sessions, as it will probably just get enabled
semi-automatically by script or template on those sessions.

---

From: "Dickson, Brian" <[email-masked]>
Date: Wed, 25 Sep 2013 16:08:35 +0000

Hi, Eric,

I think it would be sufficient to have this be a negotiated capability.

E.g. router A and router B both speak AIGP (and have it enabled, e.g. by
default) -> both advertise the capability -> both ends have AIGP_SESSION
enabled. All other cases (either A or B does not speak AIGP, or have it
disabled globally or for this session) result in AIGP_SESSION being
disabled FOR THAT NEIGHBOR PAIR. A router that does not speak AIGP would
never receive the attribute, so the issue becomes moot.

Add global enable/disable, plus per-peer enable/disable, and the risk is
significantly mitigated.

>What is meant by "the transitive environment"?

The DFZ, the global set of BGP speakers.
Typically new attributes, or changes to implementations of attributes,
normally transitive attributes caused the problem.

The issue is, past issues were triggered between EBGP speakers of
different vendor boxes.
If the problem triggered session resents on vendor C, but was being
propagated by vendor J, for an issue originated by vendor A, major chaos
was the result.

Here, what I am cautioning is, breaking things on an IBGP basis (if a
session reset occurs), can lead to similar effects, perhaps at a lesser
scale (single AS breakage). But the impact, if the AS in question is not a
"leaf" AS, is larger than just the AS in question.

E.g. if the problem manifested itself in one of the 10 biggest ASes
globally, the impact would likely be felt by thousands of ASes.

>semi-automatically by script or template on those sessions.

See my top-reply comments. Negotiated is much better than unilateral, when
it comes to "default".

Brian

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Sep 2013 18:09:52 +0200

Hi Eric,

> AIGP_SESSION if it is the consensus of the WG that it should always
> default to "disabled".

If by "disable" you mean that default policy on EBGP sessions on
inbound is to drop such attribute (meaning strip it from BGP_UPDATE
message) unless explicitly permitted by policy then perhaps it will
address Brian's concern

> I am skeptical though that it will have much of a protective

I am not sure we should filter anything on IBGP sessions at all.

Best,
r.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 25 Sep 2013 16:24:37 +0000

"Enabling" by default greatly simplifies the operational model.

Jim Uttaro

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 25 Sep 2013 16:29:25 +0000

Support as co-author.. FYI we ( AT&T ) are currently suing the AIGP in the architecture of our domestic and global networks.. We have not encountered a need to change the encoding and I would be wary of changing this without better understanding..

Jim Uttaro

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 25 Sep 2013 16:36:42 +0000

Comments In-Line

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rosen
Sent: Tuesday, September 24, 2013 3:34 PM
To: [email-masked]
Cc: idr wg; [email-masked]; [email-masked]
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

[Jim U>] Along with the fact that it is implemented in a production network

[Jim U>] As intended.

[Jim U>] +1

---

From: <[email-masked]>
Date: Wed, 25 Sep 2013 16:42:17 +0000

Eric,

Thank you for answering and addressing all my comments.

That's fine for me.

Regards,
Bruno

>From: Eric Rosen [mailto:[email-masked]]
>
>

---

From: Thomas Mangin <[email-masked]>
Date: Wed, 25 Sep 2013 18:01:23 +0100

As I make some criticism about the draft, I will make my position clear, Support.
I believe that this draft has achieved "rough consensus and running code".

And ExaBGP supports the draft since 1 minute ago so Bertrand mail should read 5 working implementations :-)

Thomas

On 25 Sep 2013, at 16:29, Bertrand Duvivier (bduvivie) <[email-masked]> wrote:

> From: Susan Hares <[email-masked]>
> To: idr wg <[email-masked]>
> Cc: "'John G. Scudder'" <[email-masked]>

---

From: "Anoop Kapoor (ankapoor)" <[email-masked]>
Date: Wed, 25 Sep 2013 17:14:15 +0000

Support.

Anoop.

From: Thomas Mangin <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 25, 2013 10:01 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>, "'John G. Scudder'" <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

Thomas

On 25 Sep 2013, at 16:29, Bertrand Duvivier (bduvivie) <[email-masked]<mailto:[email-masked]>> wrote:

Support,

BRGDS Bertrand

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gaurav Dawra (gdawra)
Sent: mercredi 25 septembre 2013 17:02
To: Susan Hares; idr wg
Cc: 'John G. Scudder'
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

Support.

Thanks,
-Gaurav

Sue and John
IDR co-chairs

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 25 Sep 2013 13:46:06 -0400

> I will change the reference name.

I believe the RFC Editor changes the reference names according to their own style guide anyway, so it's probably moot.

--John

---

From: t.petch <[email-masked]>
Date: Thu, 26 Sep 2013 10:06:15 +0100

The Type registry is defined to be 0 to 255 but the first allocated
value is one.  I suggest reserving zero and 255; no sound technical
reason at present but it is common practice and good housekeeping.

Also, most of the existing BGP registries are in fact sub-registries of
Border Gateway Protocol (BGP) Parameters registry
so  suggest making this one one as well.

Tom Petch

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Sep 2013 07:48:04 -1000

> reason at present but it is common practice and good housekeeping.

i think we should reserve 42 as well :)

don't needlessly manufacture more magic numbers.  we have waaaaay to
many of them already.

randy

---

From: Ilya Varlashkin <[email-masked]>
Date: Thu, 26 Sep 2013 22:26:16 +0100

Hi all,

I didn't plan originally to post following text but it was suggested to me that the real-world scenario that I've encountered might be worth mentioning before WGLC for AIGP concludes. Please consider this only as "info", and neither "for" nor "against" current edition of AIGP draft.

Several weeks ago I've started looking into various methods to employ while re-organising a BGP confederation. The network involves set of disjoint IGP domains, hence no end-to-end path-cost visibility. (BGP) Best-path selection for global table in this environment often boils down to "lowest IGP-cost exit" (and they can be 5-50ms apart). When exits are in different IGP domains I thought AIGP could be used, but turned out AIGP was not made for this kind of use case. Currently AIGP is designed to be absolute decision maker. Although the draft does say that a router calculates AIGP+IGP cost, it stops short of using result in place where rfc4271 BGP would use IGP cost. 

To give an example, if I have an external prefix NetA coming via ASBR1 in AS1 and ASBR2 in AS2 (both AS1 and AS2 are members of the same BGP confederation, each AS has its own IGP). I'd like to prefer shortest AS_PATH, and if all are of equal length then take nearest exit. Suppose I  was to use AIGP, the resulting best path would be what I'd like only if AS_PATH via ASBR1 and ASBR2 are of equal length. If AS_PATH via ASBR2 is shorter than via ASBR1, but ASBR1 is closer to me then AIGP would force traffic to exit via ASBR1 anyway, though I'd want it to go via ASBR2 in this case. In order to achieve desired behaviour the AIGP draft would need to be modified so that AIGP+IGP cost would be considered not as foremost tie-breaker, but where IGP cost is currently used in BGP tie-breaking rules.

The above described modification is of course different from what the draft says now, and won't serve people who use it now. However, it looks like the modification is rather simple and could be turned on and off by a configuration knob so AIGP could work in both current scenario (multiple real AS's under common administration) and in case of BGP confederation (as described above). This switch would simply move order where AIGP+IGP is used (somewhat similar to how this is done with cost community).

Is the above something that IDR should consider for amending the draft?

Kind regards,
iLya

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 26 Sep 2013 22:31:52 +0000

Ilya,

                Comments In-Line..

Jim Uttaro

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ilya Varlashkin
Sent: Thursday, September 26, 2013 5:26 PM
To: idr wg
Cc: Susan Hares; John G. Scudder
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

Hi all,

To give an example, if I have an external prefix NetA coming via ASBR1 in AS1 and ASBR2 in AS2 (both AS1 and AS2 are members of the same BGP confederation, each AS has its own IGP). I'd like to prefer shortest AS_PATH, and if all are of equal length then take nearest exit. Suppose I  was to use AIGP, the resulting best path would be what I'd like only if AS_PATH via ASBR1 and ASBR2 are of equal length. If AS_PATH via ASBR2 is shorter than via ASBR1, but ASBR1 is closer to me then AIGP would force traffic to exit via ASBR1 anyway, though I'd want it to go via ASBR2 in this case. In order to achieve desired behaviour the AIGP draft would need to be modified so that AIGP+IGP cost would be considered not as foremost tie-breaker, but where IGP cost is currently used in BGP tie-breaking rules.
[Jim U>] This behavior is why AIGP is not at the POI of IGP but above AS_PATH, An ex, assuming a global network comprised of 3 AS domains corresponding to US, EMEA and AP connecting in a triangle .. Further assume that India is in AP.. For traffic destined from NY to India the current decision making would select the shorter AS-PATH which would force traffic to traverse from NY( US) ->AP (India). The desired path is NY->EMEA->AP ( India ) which is the shorter latency..

The above described modification is of course different from what the draft says now, and won't serve people who use it now. However, it looks like the modification is rather simple and could be turned on and off by a configuration knob so AIGP could work in both current scenario (multiple real AS's under common administration) and in case of BGP confederation (as described above). This switch would simply move order where AIGP+IGP is used (somewhat similar to how this is done with cost community).
[Jim U>] So that would be a POI knob ?

Kind regards,
iLya

On Sep 14, 2013, at 12:12 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Sue and John
IDR co-chairs

---

From: Ilya Varlashkin <[email-masked]>
Date: Fri, 27 Sep 2013 00:21:37 +0100

> [Jim U>] This behavior is why AIGP is not at the POI of IGP but above AS_PATH, An ex, assuming a global network comprised of 3 AS domains corresponding to US, EMEA and AP connecting in a triangle .…

I fully understand and don't dispute your use case. So the current AIGP specification should not be removed. What I'm proposing is an amendment, to cater to more use cases. Though also notice that in your case AIGP works only for networks directly connected to you or for which you have devised latency/proximity from external sources, not for a random prefix you receive from "blackbox peers".

> [Jim U>] So that would be a POI knob ?

in a simplistic form - yes, locally-significant (but consistently configured within your administrative domain) POI knob. This would allow AIGP to work _either_ for your (real AS's) case or mine (BGP confed), but not for both at the same time.

Now after reviewing AIGP attribute format, I see there's potentially room for more flexible solution. We could leave Type=1 AIGP TLV to be fore "real AS's case" (what you have described, exactly what current implementations do), then we can add Type=2 AIGP TLV for "BGP confederations" that will have exactly same originating and propagating rules as current Type 1, but will have POI just before IGP cost.

/iLya

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 27 Sep 2013 00:27:53 +0000

Comments In-Line

                Jim Uttaro

From: Ilya Varlashkin [mailto:[email-masked]]
Sent: Thursday, September 26, 2013 7:22 PM
To: UTTARO, JAMES
Cc: idr wg; Susan Hares; John G. Scudder
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

I fully understand and don't dispute your use case. So the current AIGP specification should not be removed. What I'm proposing is an amendment, to cater to more use cases. Though also notice that in your case AIGP works only for networks directly connected to you or for which you have devised latency/proximity from external sources, not for a random prefix you receive from "blackbox peers".
[Jim U>] This was designed for a group of domains under a single admin domain.. Extending to "blackbox peers" where the underlying metric may not be the same will yield unpredictable results and is not recommended..

Now after reviewing AIGP attribute format, I see there's potentially room for more flexible solution. We could leave Type=1 AIGP TLV to be fore "real AS's case" (what you have described, exactly what current implementations do), then we can add Type=2 AIGP TLV for "BGP confederations" that will have exactly same originating and propagating rules as current Type 1, but will have POI just before IGP cost.
[Jim U>] The addl TLVs were put there for future use.. I had thought there may be other metric types i.e availability, robustness, reliability.. I see no reason why your use case could not advantage these TLVs..

/iLya

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 27 Sep 2013 01:46:11 +0000

Ilya, your use-case seems quite valid  and I like your proposal to define a new type to address it. This is a cleaner / better approach than having to put the POI change everywhere.

We should not limit it to confed though.

Cheers,
Rajiv

Sent from my Phone

On Sep 26, 2013, at 8:29 PM, "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>> wrote:

Comments In-Line

                Jim Uttaro

I fully understand and don't dispute your use case. So the current AIGP specification should not be removed. What I'm proposing is an amendment, to cater to more use cases. Though also notice that in your case AIGP works only for networks directly connected to you or for which you have devised latency/proximity from external sources, not for a random prefix you receive from "blackbox peers".
[Jim U>] This was designed for a group of domains under a single admin domain.. Extending to “blackbox peers” where the underlying metric may not be the same will yield unpredictable results and is not recommended..

/iLya

---

From: t.petch <[email-masked]>
Date: Fri, 27 Sep 2013 08:55:28 +0100

----- Original Message -----
From: "Eric Rosen" <[email-masked]>
To: <[email-masked]>
Cc: "idr wg" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, September 25, 2013 4:00 PM
> particular encoding technique.

Sigh.  One problem, two solutions, an increase in the likelihood of
coding errors:-(

I think that other SDOs got it right.  The manufacturer I worked for had
a simple rule, TLV was always the length of the value field whereas LDV
always included the length of the header as well.  A simple rule, so
deeply engrained that I would probably make a coding error whenever TLV
is not defined in that way.

But, if this protoocol has been the 'wrong' way for five years, it is
probably best left alone.

Tom Petch

---

From: "SAAD, SAMIR S" <[email-masked]>
Date: Fri, 27 Sep 2013 16:15:37 +0000

Support

Samir Saad
AT&T Labs

From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, September 13, 2013 7:13 PM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)

Sue and John
IDR co-chairs

---

From: Eric Rosen <[email-masked]>
Date: Fri, 27 Sep 2013 14:23:15 -0400

> Is the above something that IDR should consider for amending the draft?

I think it would be much better to leave the AIGP draft as is, and for
someone to write a new draft, possibly updating the AIGP draft, that
specifies the option you want.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 27 Sep 2013 19:15:02 +0000

Agreed

---

From: "Dickson, Brian" <[email-masked]>
Date: Fri, 27 Sep 2013 19:20:39 +0000

So, what about the suggestion of using a capability-negotiate rather than
(intrinsically) a capability-"assume"?

It would not change the operational model of "default enable", while
removing the possibility of introducing problems in cases of iBGP sessions
between AIGP and non-AIGP routers.

It seems like a very small change, IMHO.

You may have overlooked it in my larger email.

(The impacted code is basically exercised only on session set-up, and
disables AIGP_SESSION if the capability is not negotiated.)

Thoughts?

Brian

---

From: Ilya Varlashkin <[email-masked]>
Date: Sat, 28 Sep 2013 23:47:38 +0100

Ok, but then current draft should say how to handle AIGP Types an implementation doesn't recognise.

/iLya

---

From: Thomas Mangin <[email-masked]>
Date: Sun, 29 Sep 2013 10:31:00 +0100

Hello Brian,

At first read I was also surprised not to find a capability, as nearly every BGP RFC adds one, but thinking about it I do not believe it is necessary, but I believe something important was missed (see last paragraph).

In this case, the default behaviour of BGP is to already ignore the unknown attribute, It will not be transmitted neither, so adding some code for the negotiation of the feature is not really required. One could add the code complexity of an capability, but I see no advantage.

Capability negotiation is useful :
 - when both parties need to know about the feature to make sense of the new data format sent on the wire, as otherwise the data received would be seen as invalid and would cause the tearing down of the session
 - to prevent the propagation of new NLRI or otherwise transitive attributes, which could cause bugs in routers quite a few ASN away from the originating network.

However nothing prevent the propagation of a TRANSITIVE attribute 26. The default behaviour on EBGP is to ignore the attribute, but the RFC does not explicitly ask for the TRANSITIVE attribute to be blocked. 

As RFC 4271 says : "Paths with unrecognized transitive optional attributes SHOULD be accepted.". I would suggest that the RFC adds some wording to explicitly ignore transitive attribute received with attribute 26. As without this limitation, one could cause the activation of the feature on a foreign network on IBGP ( capability or no capability ) through messages sent through EBGP.

Thomas

---

From: Eric Rosen <[email-masked]>
Date: Mon, 30 Sep 2013 17:02:23 -0400

> current draft should say how to handle AIGP Types an implementation
> doesn't recognise

We can add that unrecognized types have no impact on the bestpath
selection.  I don't think there's anything more to say about them.

With regard to type 1, the draft should probably state what to do if there
is more than a single type 1 TLV.  I propose to add a statement saying that
an implementation originating an AIGP attribute MUST NOT include more than
one type 1 TLV, and that an implementation receiving an AIGP attribute with
more than one type 1 TLV MUST use only the AIGP value in the first one.