Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
Robert Raszuk <robert@raszuk.net> Sat, 17 February 2024 09:24 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 09E99C14CE4D for <idr@ietfa.amsl.com>; Sat, 17 Feb 2024 01:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=unavailable 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 VgBIeDYlNH07 for <idr@ietfa.amsl.com>; Sat, 17 Feb 2024 01:24:02 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 4FB09C14CE54 for <idr@ietf.org>; Sat, 17 Feb 2024 01:24:01 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-563c595f968so2918124a12.0 for <idr@ietf.org>; Sat, 17 Feb 2024 01:24:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1708161840; x=1708766640; 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=tj6Cr/x1LKHNb1zhoa2j4+B7DOxg5WKHtt0oy/4cjsU=; b=LZyNJgvYZAJXKeAwKhvus/eBqA1paGbWov9CwSJ5+HtQY11EDsP1rQdrhC3G3pkUr+ YwX4/9X6s81ciovfC5wBSXMgTkq1CjUxd8yOtvKsio717jJyzejKyn48ql/JrR1pbTXw 5CS1Vzm4tqdI1n3Xpe2J8C3mYahsfKvSTm9irD/mi09yU0nsr8G7VL7QIqxrxymp8uH9 Z0fOHgiGkqPgmBOCACPebFDcC9wcWEJShekNEcZwxx9RlBF9sWAbtWmdz7SFtRxI+YuN u6L9UrNFfyKyOHp4VTAfz2uepmL6bCWw5vUcQY6up+ZaUPGdW0A1Ik1PBGvYeH92nnnV 1YZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708161840; x=1708766640; 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=tj6Cr/x1LKHNb1zhoa2j4+B7DOxg5WKHtt0oy/4cjsU=; b=RoKDLQmRS5ONQYNQOgfBz6j9d2S9TOyT0OlQ7P61MjnMlu3pdGmzYCwKstPBalo3/u qPPRtMkHEyunNWo3ij+f6DFid05gM/hgIwOrJC3OaaXb3rmCiHnBNr1YdbXsN6RQPPvN LPWqnea7JR8jDElN1LIMWJfzVqzGYf0WfTZ/+uS/W09PQQtjwUQkg7XscArQI31BVdGI HbBDZF7qkCOIymquOUjlEAZzZwnfLSslIZvSA3nfTPE7hHBhwlHruLoZBom12qWDfbRl AtWPMsYxYV3rZZg5Uu8HYboZwvplVr7v+GjOFBx7DcFuutMfOibT+4/rslHwtQnu4V6O Al3Q==
X-Forwarded-Encrypted: i=1; AJvYcCWL7PbfRFHJVVcheMY6ZYtbEJY6VFhYZAVVuuPrBDCKhVjUa2fPUclIhsHGfs3p3Aap1J1EyW1P22CdxCg=
X-Gm-Message-State: AOJu0YyseiF0rublZwrch63BnpbMgHMB+ozYyA98ezwuDscy8KKhxIVA k/fUcdSRlcRwYPIRUaXgeD6gN1j8Dx035ED/CFdimOSJ5y3cslaJtH32groALWOrwLrUAMLzA6L YeJoxjvlvGXyWMfD9MMoFjKaTao43iTo2KwIgJw==
X-Google-Smtp-Source: AGHT+IGYliBvZsN58RkHxGk3M9mkOeHhsYzdinQu9bSvZA81GA4I29Gx7f2wW2qmfkeFnYgKtJcdh4LJEosrGfwEskw=
X-Received: by 2002:a05:6402:b23:b0:561:347f:ec5e with SMTP id bo3-20020a0564020b2300b00561347fec5emr5337820edb.32.1708161839725; Sat, 17 Feb 2024 01:23:59 -0800 (PST)
MIME-Version: 1.0
References: <170808979403.62450.15246162512138575009@ietfa.amsl.com> <CAOj+MMF_E+PiV=-=CztdWt+iseir+tytYwBVYw=4ttR=VKNn4w@mail.gmail.com> <CAOj+MMH9Bo65KzheHwHLSaW6L-QzCPAGiQVxceHGOna9993NzA@mail.gmail.com> <CAEfhRrw3WdfReMaiaFpmd7ngxcLOziN4qzvH4roY1PJoThPV6Q@mail.gmail.com> <CAOj+MMENdNFEfjed+KKwbw2CVr-eQmR74_LytnFpu8oYsuJbmw@mail.gmail.com> <SJ0PR05MB863208BE5AB824F40A6DFB50A24C2@SJ0PR05MB8632.namprd05.prod.outlook.com> <CAOj+MMHtoocwr_yvXfhY3mJ0u_XWW5GuZ_cx0GTjOx=V6Xd3Dw@mail.gmail.com> <SJ0PR05MB8632255397EEB21A7AEE4E97A24C2@SJ0PR05MB8632.namprd05.prod.outlook.com> <CAOj+MMFAZoGOmVNkGW_6E1=5jBZxyQoMytBU6qxuE1rCW0N2Xw@mail.gmail.com> <SJ0PR05MB8632E38B85FAFA6BD2B38491A24C2@SJ0PR05MB8632.namprd05.prod.outlook.com> <CAOj+MMHHU0XDgQTjGxKtUWZg8o7ScD-L_PV3dmH4PnDJijW+RQ@mail.gmail.com> <SJ0PR05MB863230BFF8286777FE1F5A19A24C2@SJ0PR05MB8632.namprd05.prod.outlook.com> <CAOj+MMGWRYdbCXYv+oBZNEHAybyz6Dpe_TTAouBfxFEoVTUJfQ@mail.gmail.com> <SJ0PR05MB8632EC72BD8DD7F718CEB897A2532@SJ0PR05MB8632.namprd05.prod.outlook.com>
In-Reply-To: <SJ0PR05MB8632EC72BD8DD7F718CEB897A2532@SJ0PR05MB8632.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 17 Feb 2024 10:23:48 +0100
Message-ID: <CAOj+MMG4oxJa_g10k34__6qu_-CKjf5wCwvxQ7K6cC9r1+qw0w@mail.gmail.com>
To: Kaliraj Vairavakkalai <kaliraj@juniper.net>
Cc: Igor Malyushkin <gmalyushkin@gmail.com>, Natrajan Venkataraman <natv@juniper.net>, "idr@ietf. org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>, Keyur Patel <keyur@arrcus.com>, Jeff Haas <jhaas@juniper.net>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ad117c0611906baa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YcwyGS1m9NRh98D9zuEzzwt3-gc>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.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: Sat, 17 Feb 2024 09:24:07 -0000
Hi Kaliraj, As mentioned building such web of RRs sitting both in data plane and outside of data plane is precisely the example why CLUSTER_ID was invented to solve such issues. In fact it seems there are two problems here: - First CLUSTER_ID on ABRs acting as RRs should be the same - Second CLUSTER_ID of RRs in a given area should also be the same. You have RRs configured as clients of each other (RR26 <--> ABR23 as well as RR26 <--> ABR24 ) with no care taken to prevent loops. That is really bad ! > Some deployments may use unique CLUSTER_IDs by design. This seems just a broken design. Cheers, Robert On Sat, Feb 17, 2024 at 1:52 AM Kaliraj Vairavakkalai <kaliraj@juniper.net> wrote: > >. So in presented topology when ABRs are RRs CLUSTER_LIST will likely be > of the very same length > > > > No Robert. > > > > Take the following propagation paths for PE11 route in the Reference > Topology in Fig 1 > <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00#figure-1> > : > > > > Rt1 : ABR23 <- RR27 <- ASBR21 > > Rt2 : ABR23 <- RR26 <- ABR24 <- RR27 <- ASBR21 > > > > Rt1 will have a smaller CLUSTER_LIST (RR27) than Rt2 (RR26, ABR24, RR27). > > > > Rt1 has next hop of ASBR21. > > Rt2 has next hop of ABR24. > > > > Desired outcome is: ABR23 should chose ASBR21 as next hop, and not ABR24 > > > > The cluster-list based tie-breaking will choose Rt1, ASBR21 as next hop. > > > > Thanks > > Kaliraj > > Juniper Business Use Only > > *From: *Robert Raszuk <robert@raszuk.net> > *Date: *Friday, February 16, 2024 at 4:01 PM > *To: *Kaliraj Vairavakkalai <kaliraj@juniper.net> > *Cc: *Igor Malyushkin <gmalyushkin@gmail.com>, Natrajan Venkataraman < > natv@juniper.net>, idr@ietf. org <idr@ietf.org>, Susan Hares < > shares@ndzh.com>, Keyur Patel <keyur@arrcus.com>, Jeff Haas < > jhaas@juniper.net>, idr-chairs@ietf.org <idr-chairs@ietf.org> > *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt > > *[External Email. Be cautious of content]* > > > > > > But I am saying that I do not see how your change will yield any > additional consistency here. > > > > Today's best path and even your draft only compares CLUSTER_LIST *length* > not the actual values. So in presented topology when ABRs are RRs > CLUSTER_LIST will likely be of the very same length. If so we move down to > the next step in best path selection - so we gain null. > > > > Do you agree ? > > > > Thx, > > R. > > > > On Sat, Feb 17, 2024 at 12:51 AM Kaliraj Vairavakkalai < > kaliraj@juniper.net> wrote: > > I did not say same CLUSTER_ID will cause inconsistency. > > > > I said, without depending on specific CLUSTER_ID values (and > Router-id/Originator-id values), > > path-selection should yeild consistent results. That’s a desired feature. > > > > That’s achieved by the path selection change proposed in this draft. viz. > tie-break on > > cluster-list step before router-id/originator-id step. > > > > Thanks > > Kaliraj > > > > Juniper Business Use Only > > *From: *Robert Raszuk <robert@raszuk.net> > *Date: *Friday, February 16, 2024 at 3:06 PM > *To: *Kaliraj Vairavakkalai <kaliraj@juniper.net> > *Cc: *Igor Malyushkin <gmalyushkin@gmail.com>, Natrajan Venkataraman < > natv@juniper.net>, idr@ietf. org <idr@ietf.org>, Susan Hares < > shares@ndzh.com>, Keyur Patel <keyur@arrcus.com>, Jeff Haas < > jhaas@juniper.net>, idr-chairs@ietf.org <idr-chairs@ietf.org> > *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt > > *[External Email. Be cautious of content]* > > > > > > I do not see how with the same CLUSTER_ID set on both RRs in your scenario > as described in the draft current best path selection would provide > inconsistent results on the clients. > > > > Thx. > R. > > > > On Fri, Feb 16, 2024 at 11:58 PM Kaliraj Vairavakkalai < > kaliraj@juniper.net> wrote: > > Some deployments may use unique CLUSTER_IDs by design. > > > > I’d just say providing consistent path-selection is a desirable feature, > irrespective of choice/assumptions on CLUSTER_ID values. > > > > That’s what this proposed text on path-sel chagne attempts to do. > > > > Thanks > > Kaliraj > > > > Juniper Business Use Only > > *From: *Robert Raszuk <robert@raszuk.net> > *Date: *Friday, February 16, 2024 at 1:14 PM > *To: *Kaliraj Vairavakkalai <kaliraj@juniper.net> > *Cc: *Igor Malyushkin <gmalyushkin@gmail.com>, Natrajan Venkataraman < > natv@juniper.net>, idr@ietf. org <idr@ietf.org>, Susan Hares < > shares@ndzh.com>, Keyur Patel <keyur@arrcus.com>, Jeff Haas < > jhaas@juniper.net>, idr-chairs@ietf.org <idr-chairs@ietf.org> > *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt > > *[External Email. Be cautious of content]* > > > > Hi, > > > > > So do you agree that with distinct CLUSTER_ID on the > > > RRs/ABRs, there is an issue? > > > > I do. But I call it misconfiguration. > > > > Of course you can/will say that in most if not all BGP implementations > configuring CLUSTER_ID is optional and by default BGP RTR_ID is taken which > makes it different by default RR by RR - but oh well - there is few things > in BGP one is expected to just know before getting to the keyboard. > > > > Setting next-hop-self on RRs in IBGP is yet another topic for discussion, > but I don't think we need to really spend time on it now. > > > > > Configuring same CLUSTER_ID, if feasible, is another way to deal with > it, agree. > > > > Glad we agree on that one. > > > > Thx, > > R. > > > > > > On Fri, Feb 16, 2024 at 10:01 PM Kaliraj Vairavakkalai < > kaliraj@juniper.net> wrote: > > OK, now onto the technical discussion, > > > > > On the technical side just configured same CLUSTER_ID on both RRs/ABRs > and there is no issue. > > > > So do you agree that with distinct CLUSTER_ID on the RRs/ABRs, there is an > issue? > > > > Configuring same CLUSTER_ID, if feasible, is another way to deal with it, > agree. > > > > Thanks > > Kaliraj > > > > Juniper Business Use Only > > *From: *Robert Raszuk <robert@raszuk.net> > *Date: *Friday, February 16, 2024 at 12:27 PM > *To: *Kaliraj Vairavakkalai <kaliraj@juniper.net> > *Cc: *Igor Malyushkin <gmalyushkin@gmail.com>, Natrajan Venkataraman < > natv@juniper.net>, idr@ietf. org <idr@ietf.org>, Susan Hares < > shares@ndzh.com>, Keyur Patel <keyur@arrcus.com>, Jeff Haas < > jhaas@juniper.net>, idr-chairs@ietf.org <idr-chairs@ietf.org> > *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt > > *[External Email. Be cautious of content]* > > > > Hi Kaliraj & Sue, > > > > > The text in this draft has been reviewed by WG, as part of draft-ct. > > > > I do not agree with this explanation/justification. If someone is not > interested at all in CT draft lot's of smuggled features and extensions may > not get sufficient attention. > > > > So I am very glad chairs recommended to remove it from the CT draft into a > separate document. As such I am afraid it would have a hard time to even > become an IDR WG document so I am not sure if the fact that some orthogonal > text was pulled out of WG document makes is automatically a WG document. > > > > On the technical side just configured same CLUSTER_ID on both RRs/ABRs and > there is no issue. > > > > Cheers, > > R. > > > > > > On Fri, Feb 16, 2024 at 8:28 PM Kaliraj Vairavakkalai <kaliraj@juniper.net> > wrote: > > Hi Robert, Igor, > > > > To provide some context – > > > > The text in this draft has been reviewed by WG, as part of draft-ct. > > > > > https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-23.html#name-avoiding-loops-between-rout > <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-23.html*name-avoiding-loops-between-rout__;Iw!!NEt6yMaO-gk!HK1hMYBmWLPwtF2YCSAargxA_wbJrNC8lBcRa2wgLKBTusa6Yay2o3Ttz1O02ODTI36LdYU1PN5-1jQ3$> > > > > During the WG Directorate and Chair reviews of draft-ct, it was suggested > to pull out this section to a new draft, as the described problem is not > specific to CT. > > > > This document history is described in: > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00#appendix-A.1 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00*appendix-A.1__;Iw!!NEt6yMaO-gk!HK1hMYBmWLPwtF2YCSAargxA_wbJrNC8lBcRa2wgLKBTusa6Yay2o3Ttz1O02ODTI36LdYU1PF2tKmx3$> > > > > I will cleanup the Author and Contributor list, to not inherit from > draft-CT. > > > > About whether the problem being described is real or not, we can have > further discussions, and clarify draft text as required. We hit these > issues in our testing with LU and CT, and I think it is very likely to hit > it in the field. That’s why it is important to document it. > > > > Just wanted to first clear the confusion on the origin/history of this > draft. So that we can focus on technical discussion. > > > > IDR-chairs may want to add something. > > > > Thanks > > Kaliraj > > > > Juniper Business Use Only > > *From: *Robert Raszuk <robert@raszuk.net> > *Date: *Friday, February 16, 2024 at 9:49 AM > *To: *Igor Malyushkin <gmalyushkin@gmail.com> > *Cc: *Kaliraj Vairavakkalai <kaliraj@juniper.net>, Natrajan Venkataraman < > natv@juniper.net>, idr@ietf. org <idr@ietf.org> > *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt > > *[External Email. Be cautious of content]* > > > > Hey Igor, > > > > Well I think there is no problem to be solved here to start with. > > > > It looks to me like someone completely unfamiliar with IETF process or > even BGP Route Reflection took a CT draft and deleted most text except > Appendix A, Co-Authors, Contributors and part of References :) > > > > I am actually surprised that IETF Submit script allowed to post it with > such document name. Looks like it is broken. > > > > Cheers, > > R. > > > > > > On Fri, Feb 16, 2024 at 6:37 PM Igor Malyushkin <gmalyushkin@gmail.com> > wrote: > > Hello all, > > Agreed with Robert. I thought too I missed the adoption call and was > surprised to see the doc already adopted. > > About CT parts, to me they look like a some form of advertising, not sure > they are necessary to express the problem statement at all. Not to mention > that it looks like AIGP solves the problem in general. > > > > пт, 16 февр. 2024 г. в 19:27, Robert Raszuk <robert@raszuk.net>: > > All, > > > > > draft-ietf-idr-bgp-fwd-rr-00.txt > > > > Also please kindly indicate why this text is posted as an IDR WG document > as the format of the name suggests ... > > > > I do not recall any single discussion on this proposal on the IDR WG list. > > > > Are the authors, so many co-authors and a large list of contributors not > aware about the draft naming convention not to mention BGP Route Reflection > principles of operation ? > > > > The Ack section also seems copied from CT draft ... not too mention it > says this: > > The decision to not reuse SAFI 128 and create a new address-family to > carry these transport-routes was based on suggestion made by Richard > Roberts and Krzysztof Szarkowicz.¶ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00*appendix-C-2__;Iw!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl8ErvDlz$> > > I think it would be simply best if you delete this doc from datatracker at > this point. > > > > Cheers, > > Robert > > > > > > > > On Fri, Feb 16, 2024 at 5:24 PM Robert Raszuk <robert@raszuk.net> wrote: > > Hi, > > > > I have two comments on your draft: > > > > #1 - RFC4456 does not assume RRs not to be in the data plane. Quite > contrary when this RFC was originally written all RRs were in the > forwarding path as most networks did not use any form of encapsulation. Yes > I do recall running network which did not run MPLS nor SR :) In fact the > mentioned above encapsulations moved the RRs out of data path as > encapsulated packets did not need IP lookup. > > > > #2 - What you are saying in respect to CLUSTER_LIST is incorrect. The > entire point of CLUSTER_LIST is not to allow paths with local CLUSTER_ID to > enter Route Reflector in the first place. Quote from RFC4456: > > > > *If the local CLUSTER_ID is found in the CLUSTER_LIST, the advertisement > received SHOULD be ignored**.* > > > > Best path has nothing to do with it. The augmentation to BGP best path > selection only aims for consistent selection not to prevent the loops. > > > > Conclusion: What you are describing is a route reflector > misconfiguration not a protocol bug. > > > > ** "ignored - really means dropped here. > > > > Cheers, > > Robert > > > > ---------- Forwarded message --------- > From: <internet-drafts@ietf.org> > Date: Fri, Feb 16, 2024 at 2:23 PM > Subject: I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt > To: <i-d-announce@ietf.org> > Cc: <idr@ietf.org> > > > > Internet-Draft draft-ietf-idr-bgp-fwd-rr-00.txt is now available. It is a > work > item of the Inter-Domain Routing (IDR) WG of the IETF. > > Title: BGP Route Reflector in Forwarding Path > Authors: Kaliraj Vairavakkalai > Natrajan Venkataraman > Name: draft-ietf-idr-bgp-fwd-rr-00.txt > Pages: 8 > Dates: 2024-02-16 > > Abstract: > > The procedures in BGP Route Reflection (RR) spec [RFC4456] primarily > deal with scenarios where the RR is not in forwarding path, and is > reflecting BGP routes with next hop unchanged. > > These procedures can sometimes result in traffic forwarding loops in > deployments where the RR is in forwarding path, and is reflecting BGP > routes with next hop set to self. > > This document specifies approaches to minimize possiblity of such > traffic forwarding loops. One of those approaches updates path > selection procedures specified in Section 9 of BGP RR. [RFC4456] > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-fwd-rr/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-bgp-fwd-rr/__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl6sQStEm$> > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl5yt5xQa$> > > 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 > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/i-d-announce__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl_q06C-f$> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl9CJwiz8$> > >
- [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt internet-drafts
- [Idr] Fwd: I-D Action: draft-ietf-idr-bgp-fwd-rr-… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Igor Malyushkin
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Kaliraj Vairavakkalai
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Susan Hares
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Igor Malyushkin
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Kaliraj Vairavakkalai
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Kaliraj Vairavakkalai
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Kaliraj Vairavakkalai
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Kaliraj Vairavakkalai
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… James Uttaro
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Kaliraj Vairavakkalai
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Igor Malyushkin
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Kaliraj Vairavakkalai
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Robert Raszuk
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Kaliraj Vairavakkalai
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Igor Malyushkin
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Kaliraj Vairavakkalai
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Susan Hares
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-0… Igor Malyushkin