[Idr] Fwd: I-D Action: draft-ietf-idr-bgp-fwd-rr-02.txt

Robert Raszuk <robert@raszuk.net> Sun, 17 March 2024 13:28 UTC

Return-Path: <robert@raszuk.net>
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 0B286C14F60F for <idr@ietfa.amsl.com>; Sun, 17 Mar 2024 06:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PUORO5fJaFe for <idr@ietfa.amsl.com>; Sun, 17 Mar 2024 06:28:07 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4032C14F60C for <idr@ietf.org>; Sun, 17 Mar 2024 06:28:07 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-56a0c0a7ebcso81395a12.1 for <idr@ietf.org>; Sun, 17 Mar 2024 06:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1710682085; x=1711286885; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ETEoEcudhlWLtfSr8TvGU8hjKd0Q84vjAUn3yne5J8I=; b=Ag3vAqULrN5PLfOlbIi0JNi1topguZ6+l15Acic8ydHjT/X4h+ZOPoWQEDx5eeG5+3 P5zyduRy+05ZHn/g4GrNUPaPu/WGt3+L6fmvVN444GCLxP4Hy5+CGaR0iRkdzx6nrIBj mORIzB64eVlruReB85hfahT4wjU5zfbYaBMrbL6HCvUULXcfv0WEa9+bBy9xGpne8s9i lQAkTD4+0+LLr4YkGApXR9ED//hF8KkBwRPrVPsWshlTsq+M/m+oKG5Rgip/GRhWng5K 7RZsrGS6mnYNxXw1PVnZNEsJ+MR1Fx044BPZJuZK68ACK9fxLa/etWoXrusviSrJcso4 gsfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710682085; x=1711286885; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ETEoEcudhlWLtfSr8TvGU8hjKd0Q84vjAUn3yne5J8I=; b=ksQf+nkaQMtyabAM+bffrf2kjVPopt+87wbq+O7mtXhBpjuIPbW1+8nr1mhMptb/Y7 aLT7YhqWQuOXG0YN5dxShVNOAaEFCwciLZhd8o3VKhc7hVzl2Lju//0envj9h9AP0lMj 8gRZfCmsot9Y5kW6tcQ1OuUS6cYPwgooAgdMq9cIl/rwgrfxv/lonSqBgW+Zw8itN0WW oq3MzUBZgfqNw6q5KEOd2loor7PmuNqx9XuIbakKrE8P5jI9RbtArWHg+amnT0d24hi7 tlhEE/WEzrF2ZfNroxXRPknp+wpL+elvCHxDM15XLyolouHlUGBm6rlhNhM55APoyMBW ThDQ==
X-Gm-Message-State: AOJu0Yycw97YwTQ0GqvOvAkg56tFYGPz5zHawTD1dW8j+povhaTWaJXr XQYPBlcJ1guRpFN8kO+FwBXXDMM0wEICG9FTBDyCss/gYcQU43R750icYIBIFvXUqBAO0OWcn9I HPtnpjtTS+tRjr0Tlv6T4ha2SaE7lv2ySMQp9tqb9x8LkJRY6U3I=
X-Google-Smtp-Source: AGHT+IEySRrW7yW32dWifqgXFaRD1Ybsi8qDQ3ikQcx+B1isSeb2cfNNI+aOeYVGV40bahvnKaYK2e4fyC5amXx2huQ=
X-Received: by 2002:a05:6402:c4e:b0:567:9306:5d0b with SMTP id cs14-20020a0564020c4e00b0056793065d0bmr8124554edb.28.1710682085313; Sun, 17 Mar 2024 06:28:05 -0700 (PDT)
MIME-Version: 1.0
References: <171065415177.59997.7631576612994148063@ietfa.amsl.com>
In-Reply-To: <171065415177.59997.7631576612994148063@ietfa.amsl.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 17 Mar 2024 14:27:54 +0100
Message-ID: <CAOj+MMEsp_UfuiHdc4U_Bv5o7xsYYK_RryusUZ88u+SH9xifSA@mail.gmail.com>
To: Kaliraj Vairavakkalai <kaliraj@juniper.net>
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000004e3d70613db3666"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/2Q_35D45Y42Md4bkJnww2PPJZAQ>
Subject: [Idr] Fwd: I-D Action: draft-ietf-idr-bgp-fwd-rr-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 17 Mar 2024 13:28:12 -0000

Hi Kaliraj,

Thx for posting the new version.

I have one observation or clarification to be made in respect to text you
added in section 4.1:

> However this approach does not allow the ABR-ABR tunnels to be
> used as backup path, in the event where an ABR looses all tunnels
> to upstream ASBR.

So you are talking about the delta time it takes for ABR which looses all
tunnels to upstream ASBRs to send BGP withdraws for those learned
infrastructure routes - correct ? So we are talking 10s of milliseconds
here from the moment all such paths are invalidated (which  -the detection
and invalidation is needed in any scenario).

As you have established each ABR will set next hop self and advertise
routes to local PEs (directly or via yet one more pair of RRs (RR26 here)).
So each PE will already have backup paths all what you are observing here
is the time before PEs invalidate paths advertised by ASBR which
looses upstream tunnels.

So if such failure models are really likely to happen (in spite of
redundant ABR connectivity in each area)  I would rather focus on fast
removal of broken paths from the network with one next hop invalidation
(single BGP or IGP message, single RIB to FIB switchover on PEs) etc ...

Thx,
Robert

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Sun, Mar 17, 2024 at 6:42 AM
Subject: I-D Action: draft-ietf-idr-bgp-fwd-rr-02.txt
To: <i-d-announce@ietf.org>
Cc: <idr@ietf.org>


Internet-Draft draft-ietf-idr-bgp-fwd-rr-02.txt is now available. It is a
work
item of the Inter-Domain Routing (IDR) WG of the IETF.

   Title:   BGP Route Reflector with Next Hop Self
   Authors: Kaliraj Vairavakkalai
            Natrajan Venkataraman
   Name:    draft-ietf-idr-bgp-fwd-rr-02.txt
   Pages:   9
   Dates:   2024-03-16

Abstract:

   The procedures in BGP Route Reflection (RR) spec RFC4456 primarily
   deal with scenarios where the RR is reflecting BGP routes with next
   hop unchanged.  In some deployments like Inter-AS Option C
   (Section 10, RFC4364), the ABRs may perform RR functionality with
   nexthop set to self.  If adequate precautions are not taken, the
   RFC4456 procedures can result in traffic forwarding loop in such
   deployments.

   This document illustrates one such looping scenario, and specifies
   approaches to minimize possiblity of traffic forwarding loop in such
   deployments.  An example with Inter-AS Option C (Section 10, RFC4364)
   deployment is used, where RR with next hop self is used at redundant
   ABRs when they re-advertise BGP transport family routes between
   multiple IGP domains.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-fwd-rr/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-bgp-fwd-rr-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce