Subject: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)

From: Daniel Ginsburg <[email-masked]>
Date: Fri, 2 Dec 2011 17:12:48 +0400

Hi,

This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribute.

The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous.

If the network employs the "no-aggregator-id" knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about.

In other words, the "no-aggregator-id" knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute.

On 02.12.2011, at 1:56, Jeff Tantsura wrote:

> Hi,
> 
> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols.
> There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds.
> 
> To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though. 
> So for those who have it configured - please rethink whether you really need it.
> 
> As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code.
> Patch will be made available.
> 
> Please contact me for any further clarifications.
> 
> Regards,
> Jeff
> 
> P.S. Warren has recently  included AGGREGATOR in the draft, please see
> 
> 2. Behavior
>   This document specifies that a BGP speaker MUST NOT originate or
>   propagate a route with an AS number of zero.  If a BGP speaker
>   receives a route which has an AS number of zero in the AS_PATH (or
>   AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
>   This same behavior applies to routes containing zero as the
>   Aggregator or AS4 Aggregator.
>

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 3 Dec 2011 03:21:33 -0500

Hi Daniel,

I do understand the use of it however have my doubts about usability as such, I'd really like to see anyone using it for the reason below.
All of updates with ASN 0 I have seen in the past few years were there due to software bugs, not explicit configuration - same as this one.

Warren/ idr -  I do support addition of AGGREGATOR in the draft

Regards,
Jeff

P.S. Jeffrey/John -  this draft makes use of "no-aggregator-id"  de facto illigal, are you (your customers) OK with it? 
Thanks!

-----Original Message-----
From: Daniel Ginsburg [mailto:[email-masked]] 
Sent: Friday, December 02, 2011 5:13 AM
To: Jeff Tantsura; Warren Kumari
Cc: [email-masked]; [email-masked]
Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)

Hi,

---

From: Brian Dickson <[email-masked]>
Date: Sat, 3 Dec 2011 12:22:56 -0500

Can anyone familiar with this knob and its usage, answer a question:

Would anything break, in terms of use of that knob, if instead of
"zeroing" the AGGREGATOR, the local AS (as seen from the outside
world, in the case of confederations) were used?

Would the functionality of the knob, in reducing updates, be preserved?

Would routes be considered malformed or would it trigger any other bad behavior?

Perhaps this is a way of resolving the conflict between this knob and
the AS0 draft?

Brian

On Fri, Dec 2, 2011 at 8:12 AM, Daniel Ginsburg <[email-masked]> wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: <[email-masked]>
Date: Tue, 6 Dec 2011 11:59:53 +0100

Hi all,

Just a quick feedback about "no-aggregator-id" option on Juniper.
Brian, it seems to work already as you proposed, it's zeroing only the router ID , not the AS. And IMHO, by zeroing only the router ID, the non duplicate update behavior which was expected by the feature is working well.

Moreover this is how it is described in JUNOS doc :
"Set the router ID in the BGP aggregator path attribute to zero. (This is one of the path attributes included in BGP update messages.) Doing this prevents different routing devices within an AS from creating aggregate routes that contain different AS paths"

Here is a lab example :

Without the knob :

Dec  6 11:52:27.697866 BGP SEND x.x.x.x+179 -> y.y.y.y+23415
Dec  6 11:52:27.697873 BGP SEND message type 2 (Update) length 56
Dec  6 11:52:27.697879 BGP SEND Update PDU length 56
Dec  6 11:52:27.699070 BGP SEND flags 0x40 code Origin(1): IGP
Dec  6 11:52:27.699078 BGP SEND flags 0x40 code ASPath(2) length 0: <null>
Dec  6 11:52:27.699084 BGP SEND flags 0x40 code NextHop(3): x.x.x.x
Dec  6 11:52:27.699089 BGP SEND flags 0x40 code LocalPref(5): 100
Dec  6 11:52:27.699095 BGP SEND flags 0xc0 code Aggregator(7): 64532 81.52.26.126
Dec  6 11:52:27.699108 BGP SEND         54.54.0.0/16

With the knob :

Dec  6 11:54:02.968636 BGP SEND x.x.x.x+179 -> y.y.y.y+23415
Dec  6 11:54:02.968643 BGP SEND message type 2 (Update) length 56
Dec  6 11:54:02.968649 BGP SEND Update PDU length 56
Dec  6 11:54:02.968655 BGP SEND flags 0x40 code Origin(1): IGP
Dec  6 11:54:02.968661 BGP SEND flags 0x40 code ASPath(2) length 0: <null>
Dec  6 11:54:02.968666 BGP SEND flags 0x40 code NextHop(3): x.x.x.x
Dec  6 11:54:02.968671 BGP SEND flags 0x40 code LocalPref(5): 100
Dec  6 11:54:02.968681 BGP SEND flags 0xc0 code Aggregator(7): 64532 0.0.0.0
Dec  6 11:54:02.968690 BGP SEND         54.54.0.0/16 

Hope it helps,

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Brian Dickson
Envoyé : samedi 3 décembre 2011 18:23
À : Daniel Ginsburg
Cc : [email-masked]; [email-masked]
Objet : Re: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)

Would anything break, in terms of use of that knob, if instead of "zeroing" the AGGREGATOR, the local AS (as seen from the outside world, in the case of confederations) were used?

Perhaps this is a way of resolving the conflict between this knob and the AS0 draft?

Brian

_________________________________________________________________________________________________________________________

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, 
France Telecom - 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 authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments. 
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.