Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
Robert Raszuk <robert@raszuk.net> Sat, 17 February 2024 10:44 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 00501C14F6AC for <idr@ietfa.amsl.com>; Sat, 17 Feb 2024 02:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.005
X-Spam-Level:
X-Spam-Status: No, score=-2.005 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 G6zWDx3L_mN6 for <idr@ietfa.amsl.com>; Sat, 17 Feb 2024 02:44:24 -0800 (PST)
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 A42EEC14F698 for <idr@ietf.org>; Sat, 17 Feb 2024 02:44:18 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-55a5e7fa471so1920997a12.1 for <idr@ietf.org>; Sat, 17 Feb 2024 02:44:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1708166656; x=1708771456; 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=dgCC8yqiZTW08Z9Aa/oDJoVvtKCM4kFE5hCIUp1aYTY=; b=Igj8Tm9VyLEFllC5HbDs1b8hPeJjCNVxH94POabXvuFt8uy45S/bkXyKhjzgzzsGM8 lpt7FjkbwR7gGYGloW15ef1FiZzszG10YNIpZzEUFly1VEk5Me5CUUmRjVbXvNRa2Fib 77uWwr5cu6W9qsMI5ch7pavhf/AKDIEgQhT/6gGpx9W3+eEXK/NAF0m6mlUSAOqBkzj5 iE7SOR70P3YXhSClpujvhsrC++n9+WRNucmzMVVP/1f73AYKKW0ykDR6bi1NdUouERtB s/nZFMq07SQfUABGtGN9UEg46oUnIE4v9SGMfsTFBM/6c7g23TMl8dZ/5RwRiToFTEv4 SvcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708166656; x=1708771456; 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=dgCC8yqiZTW08Z9Aa/oDJoVvtKCM4kFE5hCIUp1aYTY=; b=XxCnlQ16TUdwnvi6LA4RzXZY1HFfxzut6eBbzAThwqviGAam310CMxQpFqWJCVeft+ oeCVMZUFcDp6uzSiTV5/1H7Mlier32C9JCgonVwjoI1oBqvDm/n0nqOepmwwPBJDEvBd 31Px5fdUQlyfQEz8t6qWHjP1elVq8sk266pP0XWeqLW47FD80b8+8tfmGv6oqbxHk92n KBbQ6M7qGGbr1NCxOujjM7UafqQ0cb5NEabtseXx1LUwZl1Bux1PM+eog8rkOB2Y7gTY 8DdoJIE0g245RboN65RFiakRNLeggFDLBSQgTmkf/LpNkIiUQHzJmVfgbIfZiMa0Xe19 C1sw==
X-Forwarded-Encrypted: i=1; AJvYcCWDEXZrs8Io+JN5VUD1IIo+J3VQRtEVfuLV/6fNSDF+w9xgPw/zF9N7asQLe2y7BuR1SRtN5pbxRCXSupk=
X-Gm-Message-State: AOJu0Yz0cnFyT90okeIi9UgWcFstSYpSjb7kVx0VhuOnYGVBR4Q4xKf8 9PxUrnlw/nWzzaXz9MJZFwIZZPRaTO7ifGLapPIOsa60LPWaSScjRSCF7oIFbJ5AveTKWqbpCsm ZyXdCynQ4yvVCD3SAHyNAyFfBjgByGMDmRL3zog==
X-Google-Smtp-Source: AGHT+IE0b/FkOJkS5GJoq2l7DKSXqr7mxVZN+QBCZdyOSqc9WMR4gGnfprgyXk9b39L1fbhmyFAgOaFuvqCiG4l/gIs=
X-Received: by 2002:aa7:d84d:0:b0:563:eca6:7345 with SMTP id f13-20020aa7d84d000000b00563eca67345mr3067502eds.9.1708166656407; Sat, 17 Feb 2024 02:44:16 -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> <CAOj+MMG4oxJa_g10k34__6qu_-CKjf5wCwvxQ7K6cC9r1+qw0w@mail.gmail.com>
In-Reply-To: <CAOj+MMG4oxJa_g10k34__6qu_-CKjf5wCwvxQ7K6cC9r1+qw0w@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 17 Feb 2024 11:44:05 +0100
Message-ID: <CAOj+MMG+-MCGMtBLV8eVPgSt3of1__giN8vbeqO4cLmyDxzuaQ@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="000000000000c5ced40611918a83"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Qul-JpjhoRTNQa3zdBeJUoi-r80>
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 10:44:28 -0000
Hi Kaliraj, Two more comments .. The new version you posted says: "These procedures can sometimes result in traffic forwarding loops in deployments where the RR is in forwarding path, because of reflecting BGP routes with next hop set to self." Allow me to observe that RRs can be (and were/are still in lots of deployments) placed in the forwarding path without next hop self. Your sentence seems to suggest that if you put RR in the forwarding path all reflected paths will have (or will have to have by cfg) next hop set to self. That is not the case. It is IGP and area/asn topology which directs traffic towards such RRs. That is why proper care should be taken such that (in this case classful transport) information on both ABRs is symmetrical between areas (or in the case of ASBRs between ASNs). Now let's zoom into crux of your recommendation: Implementations SHOULD provide a way to alter the tie-breaking rule specified in Section 9 of BGP RR [RFC4456] so as to tie-break on CLUSTER_LIST step before ORIGINATOR_ID step, when performing path selection for BGP routes. What you are proposing is really to introduce inconsistent path selection in the case where prefixes are advertised from a multihomed sites (via different PEs) and there is no RR symmetry (like btw in your case). So you are trying to fix your specific (questionable) design while in the same time breaking path consistency for many other deployments if best path goes that far in path selection steps. Your section 3.2 got updated with CLUSTER_ID (thank you) - so now we have three different solutions to the questionable problem. Why do we need a 4th one which is not better then the alternatives ? While we are discussing solutions you could also in this scenario create a policy (yes policy on RRs is a bad thing - but here you are talking really about RRs which act much more as ASBRs then real RRs) and deprefer all paths with tandem ABR as next hop. Two lines of cfg and no BGP code change needed. Kind regards, Robert On Sat, Feb 17, 2024 at 10:23 AM Robert Raszuk <robert@raszuk.net> wrote: > 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