Re: [Idr] BGP Path Marking comments for IETF 87 session

Robert Raszuk <robert@raszuk.net> Sat, 03 August 2013 09:44 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D7611E8165 for <idr@ietfa.amsl.com>; Sat, 3 Aug 2013 02:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.537
X-Spam-Level:
X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEopFgERM91Y for <idr@ietfa.amsl.com>; Sat, 3 Aug 2013 02:44:47 -0700 (PDT)
Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9A11E8162 for <idr@ietf.org>; Sat, 3 Aug 2013 02:44:46 -0700 (PDT)
Received: by mail-oa0-f53.google.com with SMTP id k18so3168757oag.12 for <idr@ietf.org>; Sat, 03 Aug 2013 02:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ODcZ89oM+MK/lnu3kzXXtPkJDvGuvLuxtaOL2HO2n+8=; b=myAQYAybc1CIwzxZDbrE7aZYW8qSzqR2YGxZP62euhvHk/PQtIuObZ1/EsMi/xVoeD 3g8mi42G+CSUKgdJ7jP62/eYvVN7gUeErL7A5DsdocCW6tyW1hKaliMJKxY6yy5XOL02 mlQtldZIbvVV+hwTb8IC8luJLdZsWuDqrh4QwOVOK+KSsw2zwrVRiyZMuVRbCDa7YJfZ aqJzF9V2VAnz2QqbG6Sd4WZfgRwVnYOibnzNLw9pKK+HngrQwtS7IU7G8+k0awJSFXfV /QBc/OzXODwOYPSoqKRreUZoV94CZP7kusgWp9444XAwfEwXjCHYHQXM+30ASgyxZdO3 zPog==
MIME-Version: 1.0
X-Received: by 10.50.18.5 with SMTP id s5mr300858igd.6.1375523086346; Sat, 03 Aug 2013 02:44:46 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.28.168 with HTTP; Sat, 3 Aug 2013 02:44:46 -0700 (PDT)
In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A05C2CC60@xmb-rcd-x13.cisco.com>
References: <20130801141342.GA23273@pfrc> <8ED5B0B0F5B4854A912480C1521F973A05C2CC60@xmb-rcd-x13.cisco.com>
Date: Sat, 03 Aug 2013 11:44:46 +0200
X-Google-Sender-Auth: _0nvaxOZorLgpwdMSVmy4xQlK20
Message-ID: <CA+b+ERmmMgfnDKQTs+_5L2FALzxg1=ECpiEV9BO=h6R4Ji5r2A@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: "Saikat Ray (sairay)" <sairay@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] BGP Path Marking comments for IETF 87 session
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Aug 2013 09:44:47 -0000

Saikat,

As we have discussed after the meeting while I am not worried about
churn that much - as  churn may mostly be in the case of add-paths I
am concerned that the consequence of this marking is intended to have
direct impact on best path selection algorithm of BGP speakers.

In IDR we have decided few meetings back that we should group all
proposals which tent to impact best path selection under common
umbrella and stop proposing point solutions which do punch more holes
in the best path algorithm. That applies equally to multipath
selection as well.

One protocol which is designed to be universal solution for this is
cost community draft. Sure additional POIs may be needed or it may
need to be explicitly extended to also play active role in not only
best path selection, but also multipath selection. For your
application (which is for some reasons ability not to select best
external as multipath candidate) it seems the pre-best path POI of
cost community will work just fine today.

If we add now a lot of new colors yet not clearly spell out their
impact to local best path selection rules leaving this just for the
configuration policy the result especially in IBGP networks may be
rather poor.

So I suggest we first wait for general WG consensus on how much we
should continue to create more wholes in the best path selection and
once we reach consensus that this is required we generalize the
mechanism for it via standards track.

Best regards,
R.


On Fri, Aug 2, 2013 at 11:31 AM, Saikat Ray (sairay) <sairay@cisco.com> wrote:
> As the draft says, no additional advertisements should be done just to send the extcomm. I.e., the path is advertised only if the path would have been advertised anyway (due to other reasons), and you tack on the extcomm.