Re: [Idr] I-D Action: draft-ietf-idr-add-paths-10.txt

Robert Raszuk <robert@raszuk.net> Fri, 24 October 2014 16:25 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E12A1A1AE7 for <idr@ietfa.amsl.com>; Fri, 24 Oct 2014 09:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVUXky60agWK for <idr@ietfa.amsl.com>; Fri, 24 Oct 2014 09:25:30 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA7A1A1A87 for <idr@ietf.org>; Fri, 24 Oct 2014 09:25:30 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id rl12so2688556iec.9 for <idr@ietf.org>; Fri, 24 Oct 2014 09:25:29 -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:message-id:subject :from:to:cc:content-type; bh=uULleqt9j7o9BKtmJU2qzrOrsOPxq+DvUUgBGBMR4nw=; b=kHhAMeTQWtk1nmzVyz0BVTWvJQNxcKl8Qiyje3Gaplz9GDRTOHCe0hq+iSUAyrwnJX zj7qn4PbVNk4x0yCWOLV4gVyjG+2r6Y+D4Eze+owlA1bSptlB1xx+hGhvF5T4dDBJ4Ea qdtou+PWWnecAjGuIOKaAVMsIt3i81FpA+vdIfKcd1jl3m00X0nenaUB+uDZT/d5Dz2q TZLfB2QSKrSpHmbN+HQ3xQ+3j5s+B6C5i80JuEP+jfzg/G2hY9Nmq4jX5khoZ+hpqd0A 4AEZoUIXEacea7JkwV0vtlLpnnan1FiBZQUdOdkrBvcFZuCE70i0wQu/BD1FSKypvi7w tg5Q==
MIME-Version: 1.0
X-Received: by 10.107.159.18 with SMTP id i18mr5090771ioe.33.1414167929867; Fri, 24 Oct 2014 09:25:29 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.156.208 with HTTP; Fri, 24 Oct 2014 09:25:29 -0700 (PDT)
In-Reply-To: <5F1FD493E541C642ABBC18EDC327C82F1FF47470@xmb-aln-x11.cisco.com>
References: <20141024135742.19022.17526.idtracker@ietfa.amsl.com> <20141024141859.GF30433@pfrc> <D06FE1A9.675B%acee@cisco.com> <5F1FD493E541C642ABBC18EDC327C82F1FF4724F@xmb-aln-x11.cisco.com> <5F1FD493E541C642ABBC18EDC327C82F1FF472FE@xmb-aln-x11.cisco.com> <CA+b+ERnR_4FgRED1ArOOE44gx2hnBoW9V38JP1pNea3GASb2pQ@mail.gmail.com> <5F1FD493E541C642ABBC18EDC327C82F1FF47470@xmb-aln-x11.cisco.com>
Date: Fri, 24 Oct 2014 18:25:29 +0200
X-Google-Sender-Auth: UcjeR9-jM1P0vXxTe1vWoAHvHgQ
Message-ID: <CA+b+ERn_74R0rA_EqzKe1-+eYO88rNvPMEAns=Dp0sLHh9H9mQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: "Bertrand Duvivier (bduvivie)" <bduvivie@cisco.com>
Content-Type: multipart/alternative; boundary="001a1140f94e1cf75505062da18c"
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yUcRBzXPx1rYAKA8o13-En_1lQM
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-add-paths-10.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 24 Oct 2014 16:25:33 -0000

Bertrand,

There are number of optional elements and implementation choices when
developing add-paths functionality.

It would be desirable to see in one place comparison what advertisement
options given implementation supports and which ones are missing.

You may recall a draft from Piere which lists in section 4.3 various
selection options ...

https://tools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-06

Does all cisco implementations support all of those ?

I am not to push processes, but even if IETF becomes a bit more modern and
for each protocol extensions have a wiki where developer can just click
when implementing an optional functionality - it would be very helpful.

Procedurally indeed there is a problem with implementation report drafts as
they seems to be not progressing to RFCs ...

For example this one seems hanging:
https://tools.ietf.org/html/draft-mynam-grow-diverse-path-impl-01

Best,
R.






On Fri, Oct 24, 2014 at 6:14 PM, Bertrand Duvivier (bduvivie) <
bduvivie@cisco.com> wrote:

>  Robert,
>
>
>
> Add-Path has been deployed by many SP’s  with mix vendor environment since
> years and does works fine...
>
>
>
> Thus we may need to ask, what is the added value of such document (outside
> of following processes).
>
>
>
> For Cisco, my BGP team is ready to provide full support if someone start
> this exercise/ implementation draft but  I’m not ready to take the lead and
> fund this works, this is not our priority.
>
>
>
> BTW:  my personal opinion (Not Cisco): I’m in favor to ask SP’s who
> deployed Add-Path to speak up and provide feedback and bypass the
> implementation draft if we believe we got enough return from experience.
>
>
>
> Best Regards Bertrand Duvivier
>
> IP routing Product Manager
>
>
>
>
>
> *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* vendredi 24 octobre 2014 18:00
> *To:* Bertrand Duvivier (bduvivie)
> *Cc:* Acee Lindem (acee); Jeffrey Haas; idr@ietf.org
>
> *Subject:* Re: [Idr] I-D Action: draft-ietf-idr-add-paths-10.txt
>
>
>
>
>
> Shouldn't we have an implementation report draft documenting those details
> before WG last call on the main draft ?
>
>
>
> r.
>
>
>
> On Fri, Oct 24, 2014 at 5:56 PM, Bertrand Duvivier (bduvivie) <
> bduvivie@cisco.com> wrote:
>
> Acee, Jeff,
>
> To be more precise for Cisco we already support it in our 3 OS's
> - IOS XE and IOS classic (CPE and Access routing platform OS)
> - IOS XR (hig-end routing platform OS)
> - NXOS (switching platform OS)
> And interoperability have been tested between Cisco OS's, with Juniper
> JUNOS, and few others
>
> Best Regards Bertrand Duvivier
> IP routing Product Manager
>
>
>
> -----Original Message-----
>
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Bertrand Duvivier
> (bduvivie)
> Sent: vendredi 24 octobre 2014 17:49
> To: Acee Lindem (acee); Jeffrey Haas; idr@ietf.org
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-add-paths-10.txt
>
> Agree, has been implemented in many OS's already
>
> Best Regards Bertrand Duvivier
> IP routing Product Manager
>
>
>
> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
> Sent: vendredi 24 octobre 2014 17:02
> To: Jeffrey Haas; idr@ietf.org
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-add-paths-10.txt
>
> I just reread it for the first time in a couple years and would agree that
> it is ready for WG last call.
> Thanks,
> Acee
>
> On 10/24/14, 10:18 AM, "Jeffrey Haas" <jhaas@pfrc.org> wrote:
>
> >The update below addressed the major open issue that remained for the
> >feature, as deployed, to match the spec: The behavior for ebgp has been
> >moved out of operation and into deployment considerations.
> >
> >I'm not an author, but I believe this draft is finally read for a
> >hopefully short Working Group Last Call.
> >
> >-- Jeff
> >
> >On Fri, Oct 24, 2014 at 06:57:42AM -0700, internet-drafts@ietf.org wrote:
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >>directories.
> >>  This draft is a work item of the Inter-Domain Routing Working Group
> >>of the IETF.
> >>
> >>         Title           : Advertisement of Multiple Paths in BGP
> >>         Authors         : Daniel Walton
> >>                           Alvaro Retana
> >>                           Enke Chen
> >>                           John Scudder
> >>      Filename        : draft-ietf-idr-add-paths-10.txt
> >>      Pages           : 8
> >>      Date            : 2014-10-24
> >>
> >> Abstract:
> >>    In this document we propose a BGP extension that allows the
> >>    advertisement of multiple paths for the same address prefix without
> >>    the new paths implicitly replacing any previous ones.  The essence of
> >>    the extension is that each path is identified by a path identifier in
> >>    addition to the address prefix.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/
> >
> >_______________________________________________
> >Idr mailing list
> >Idr@ietf.org
> >https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
>