Re: Shepherd review of draft-ietf-rtgwg-bgp-pic

Robert Raszuk <robert@raszuk.net> Sat, 04 January 2020 19:06 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1174312008D for <rtgwg@ietfa.amsl.com>; Sat, 4 Jan 2020 11:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 a_YPrpEMybmq for <rtgwg@ietfa.amsl.com>; Sat, 4 Jan 2020 11:06:12 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A1F12000F for <rtgwg@ietf.org>; Sat, 4 Jan 2020 11:06:12 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id x129so36450827qke.8 for <rtgwg@ietf.org>; Sat, 04 Jan 2020 11:06:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q1HWoozHGJsbNCNhKYu6bpC1WZD8wg/MeboBY5+3H74=; b=CiarOhj8XW4WqHk2RZ/YN2+9PUHWuh/p6FGfor+eZRrPbJwYUDMpRWCVSkjHke+S3K 0bqZI6hHLLup5RRUWyQ/EgjLfY/TRkA+VfhYbWqV40TOHe/+MT/HbGmKJcVg9Ls7w1Gz 6fEKMmySXaLB8gJ2p5XH/FVTZqTJDPfsrwNcFb34XXuk/0oy8650drQm8a8Gb/apWzC+ DIujpKw0HVZ7m+tYf4RiapbjXOaQ5WjoLea9OPWqaeFNnyqAeOZs/zTPVRLQWwmWBBhe TPkvDoTAM0+4fuYcVWIxnVYVpJU7Y+RQN1rCNsWDhWFr8ZpHooZa5lLwqCi7vQkFEXeA RBQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q1HWoozHGJsbNCNhKYu6bpC1WZD8wg/MeboBY5+3H74=; b=Txhoy141IhFrG4WuuuAQMvmzafEWGmB5zi6uaBRfrKI1F/0O6gxc6YZyRGGokbpZQ7 3mDYzlr/9DvoApgPTJocf1L3GFwELwnSB3Sb6NtrI3NdQrZOa2ee/KgsZQ19DGBvgRmE o3632bvsdFVj/ozNdBPi4SOhbLwv56rKiHhqEdUNU2d9v2wD+s0KsRvESOabUglMPvw8 LVSscOmTVUfzFqLWiVCx1GqI/OkF7HKWU4FxCpOHuwGipfzTbZT0nNZoIgxBuvd7SAul +y47R5coLvTyfHtjbBEP/v9p4x2HFAdHlcSthOpnBkf53bS/isP0jCOZP8SuK+kygRTK VV9Q==
X-Gm-Message-State: APjAAAXq3ByTZA3UrIYGV+/EDIc2Dk9NgixBIZn06qqJTkpvsv3B+Icp K4FAtrpnRqllQxQ4Ih9RSl2IX6jpENTxKVK56nU0QQ==
X-Google-Smtp-Source: APXvYqxATMmuLhg7xhW+kNC3N6rUaLeHAoscXoeHgLWAscTSJAGKZgtFNMiR46jghWRs3P9+DF8kGDfMUWQCXLtY8CM=
X-Received: by 2002:a37:274a:: with SMTP id n71mr72995254qkn.302.1578164771023; Sat, 04 Jan 2020 11:06:11 -0800 (PST)
MIME-Version: 1.0
References: <0485C9EC-624C-4E4A-A199-9F62B0CA7B0A@futurewei.com> <CABNhwV2ehxf5PX054o7uXj4DqnTbMW1yrLgoB28wC5KAxN=9cA@mail.gmail.com>
In-Reply-To: <CABNhwV2ehxf5PX054o7uXj4DqnTbMW1yrLgoB28wC5KAxN=9cA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 04 Jan 2020 20:06:01 +0100
Message-ID: <CAOj+MMFdWjK589Pg57Qj296az6gyJgyqdg+w9Pz9+dh78tV78A@mail.gmail.com>
Subject: Re: Shepherd review of draft-ietf-rtgwg-bgp-pic
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Yingzhen Qu <yingzhen.qu@futurewei.com>, "draft-ietf-rtgwg-bgp-pic@ietf.org" <draft-ietf-rtgwg-bgp-pic@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000092feaa059b551e03"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/hIQihk0w4yiPguWvFIr2x8PaazY>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Jan 2020 19:06:14 -0000

Gyan,

I noticed in the document there is a mention in the beginning of the draft
> regarding “best-external” but the detailed use of that knob is not
> documented as part of BGP PIC edge functionality.
>

It does not need to be documented. Section 2.1.2 just makes is clear that
to use BGP PIC you need more paths. How you organize your BGP such that
multiple paths are present is beyond the scope of this draft.

I noticed that the router reflector critical functions of selecting all
> paths and advertising additional paths is not mentioned which is critical
> for BGP PIC operation.
>

Use of route reflection is just a way to distribute your BGP paths. It is
not a necessity. Moreover RRs if deployed well do not select bgp paths
based on their view of IGP metric. Hint: Pls look at Optimal Route
Reflection draft.


> Another critical feature to mention in the draft related to route
> reflector and BGP PIC edge functionality is that for L3 VPN vpnv4 and vpnv6
> the route reflector is not able to advertise all paths as with IPv4 and
> IPv6..  Workaround to this issue is that the RD must be unique for each PE
> within the VPN
>

Unique RD per VRF is not a workaround. It is best practice for years now.
Number of implementations allocate RDs by default (auto-rd) per VRF. Other
deployments do it properly via NMS.


> Also mention that PIC edge can be used independently of PIC core however
> in most cases PIC core if the platform supports is enabled by default.  PIC
> edge can be configured even if PIC core is not supported on the hardware
> platform and would still improve convergence.
>

That would be a bit stating the obvious :)

We should also I think mention NHT next hop tracking FIB watcher and
> basically part of using the hierarchal fib is similar to NHT feature
> tracking the next hop PE exit points that correlate to all BGP NLRI from
> the exit point.  For hardware platforms that don’t support hierarchical fib
> that NHT can be used as a workaround to achieve the same convergence.
>

NHT and hierarchical FIB are completely orthogonal features. First is
responsible to detect the failure via watching RIB updates (registers next
hops and get's callback when IGP deletes or modifies it) while latter is
part of the repair mechanism. There is nothing "similar" between those two
features.

Also note that for PIC Core to really be beneficial that the IGP timers
> must be optimized as well as use of IP LFA, R-LFA for ldp and BFD should be
> configured to optimize next hop convergence.
>

Sorry - no. PIC can work fine without IGP too just using BGP recursive next
hops. Use of any flavour of LFA helps to quickly restore connectivity to a
given next hop - it is completely orthogonal to BGP PIC feature.


> Should also be noted that if exit point PEs edge uses  BGP next-hop-self ;
> next hop rewrite to loopback ; the loopback never goes down even if PE-CE
> failure occurs and that can impact overall convergence and this issue
> exists for both MPLS and  IP core scenario.
> I am trying to develop a workaround for this issue but have not found a
> solution yet.
>

We solved this problem over 11 years ago by defining new Edge_Discriminator
attribute. However the draft was not progressed due to lack of real
interest and easy workaround of not setting next hop self.

https://tools.ietf.org/html/draft-pmohapat-idr-fast-conn-restore-03

Thx,
Robert.