Re: [Idr] draft-chen-bgp-redist - A Juniper Perspective
Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 20 August 2021 22:59 UTC
Return-Path: <jefftant.ietf@gmail.com>
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 652063A08D5; Fri, 20 Aug 2021 15:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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=gmail.com
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 LMl05UZfvWVS; Fri, 20 Aug 2021 15:59:42 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 C93033A08C7; Fri, 20 Aug 2021 15:59:42 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id fa24-20020a17090af0d8b0290178bfa69d97so8384358pjb.0; Fri, 20 Aug 2021 15:59:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=s/esH0sHaBgGJYdwDQSC6v/rQXdrrr1LqrRDNbL0odM=; b=sl3QagJSu44umUWPosoczSKsUjqXs74agw1ma6f/qXzksE2LiodK8ENCeXcPccutow 1nFbNsdz5HF9k5rKqQhgs2/uA8HmJAx9q0vn9Y7hGOTuEg1gUFrCYRrxqvy8py8E4H2T PQak45OuqhAXqwGAaFnXPx7+qJJ3n95nJewwx5tXA1Bd83H323ATCDY7r+/jKvVvWq2H kW/sXSl/a0fPXOFK8cTswUo3i4dIPuPjlQVSqxj4iSMK/15l9VmrF83vt6ozvtUCJCsk k/tOZyaFz/aLk5SVQu9QgOSVwdTOfKLWbNBNvZivSTub4QHUrJ71rh3X6BYXkFAybCD9 Al5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=s/esH0sHaBgGJYdwDQSC6v/rQXdrrr1LqrRDNbL0odM=; b=NZAqeK8jaW0PBObqE3VKRSrcbU3qTZmJ30gEW9DNagwA7MmAGU5OfJLEy1ixQaf+ot U7seBvVlXiVTv6kbhBnNiilP719QGkhBhRSSFyjNzcOah3rw2tlvguScmfd9/x4ufaEd SVANOOrO7wkxSlg9HrojlNQQPFiLn8c/zDao9BluTen7hJ5A/ZK0UKWpUfn9gYXCEG+1 qEubOJEAlGrO/VzwOCVVdkk05r+eS49YdKCvWPcsypDye6kl5LJ5K7yr0AnmLvMWgCMD sZ1HomikXW9yFHouwsGeTeHbXAprGmUnbme2ZcPlBzMjzRkxCx1aGRD2k51bkEQSzowX a6+Q==
X-Gm-Message-State: AOAM531DyKnr0XqJz9X5EWi9LR39Gz5Ng5xP/ExmagcXRhCYJvkRQO1H DWEbP8EvYdEresQw5o1dX10yoKCuLWMPxg==
X-Google-Smtp-Source: ABdhPJwnjLKoLB2Fow5fPuZSlUamjI6xVsmcOcl7slN2ESlP7JgkjQ9o/p52ZcQ0ii24Uph7Pv9Znw==
X-Received: by 2002:a17:90b:1d88:: with SMTP id pf8mr6807810pjb.152.1629500380500; Fri, 20 Aug 2021 15:59:40 -0700 (PDT)
Received: from smtpclient.apple (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id v1sm8856061pgj.40.2021.08.20.15.59.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Aug 2021 15:59:39 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-7B8FC2E1-A25F-4C6B-8812-036F1ED25D37"
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 20 Aug 2021 15:59:38 -0700
Message-Id: <5D874729-4FC1-4AD6-BD6C-BDC473B6B342@gmail.com>
References: <CANJ8pZ-mz8KuWBkgYjuKSRwTW2ycq2VkQKYRqnnFquPQEQ=GNg@mail.gmail.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, idr@ietf.org, draft-chen-bgp-redist@ietf.org
In-Reply-To: <CANJ8pZ-mz8KuWBkgYjuKSRwTW2ycq2VkQKYRqnnFquPQEQ=GNg@mail.gmail.com>
To: Enke Chen <enchen@paloaltonetworks.com>
X-Mailer: iPhone Mail (18G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xYUOyBzxIRX7pKGYNUnAu_m6t9Y>
Subject: Re: [Idr] draft-chen-bgp-redist - A Juniper Perspective
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 20 Aug 2021 22:59:49 -0000
Jeff, Many thanks for the analysis and detailed explanation of Junos behavior. It would be great if other vendors would do a similar work and post to the list. Perhaps RFC5004/router-id (in densely meshed eBGP topologies) behavior deserves a good discussion as well. Cheers, Jeff > On Aug 20, 2021, at 14:28, Enke Chen <enchen@paloaltonetworks.com> wrote: > > > Hi, Jeff: > > Thanks for the pointer to JUNOS's BGP path selection. It's great that the Gated/JUNOS already has some consideration of the "admin-distance" / "preference" in BGP. That should take care of the case described in Sect. 2.1 ("On a single router"). It's not clear to me, though, whether and how the cases described in Sec. 2.2 ("Network-wide behavior") are handled. > > This is just a quick comment. I am still trying to digest your email. > > -- Enke > > >> On Fri, Aug 20, 2021 at 12:22 PM Jeffrey Haas <jhaas@pfrc.org> wrote: >> Enke & Jenny, >> >> While I'm inclined to say that the matters described in >> draft-chen-bgp-redist aren't a problem, it's probably more reasonable to say >> "this isn't a problem for everyone". >> >> I'm not going to debate what other implementations do. Instead, I'll spend >> the much of my message discussing what the implementation I work on does. >> This does leave us in an interesting headache as a working group whether >> there's more general work to do here that merits discussion as an RFC. >> >> ---- >> >> One thing I will contribute toward some possible need for discussion is the >> sloppy ground that RFC 4271 had with regards to interactions with non-BGP >> protocols. We had quite a difficult time getting the text for this "right" >> and there was multiple pushes to try to NOT discuss non-BGP protocols at >> all. Such discussions got very deep in the internal details of various >> implementations. What we did end up with in RFC 4271 was the following: >> >> The BGP RIBs are a distinct entity from the "Routing Table". >> >> Section 9.1.2 places the best BGP route in the Loc-RIB. >> It also says, "Whether the new BGP route replaces an existing non-BGP route >> in the Routing Table depends on the policy configured on the BGP speaker." >> >> Section 9.1.3 for Route Dissemination then says the following: >> : The Phase 3 decision function is invoked on completion of Phase 2, or >> : when any of the following events occur: >> : [...] >> : b) when locally generated routes learned by means outside of BGP >> : have changed >> : [...] >> : >> : All routes in the Loc-RIB are processed into Adj-RIBs-Out according >> : to configured policy. >> >> So... there's not a lot of normative text there. The last sentence above, >> "configured policy", is the wiggle room the RFC has to say "I'm originating >> a route". >> >> The general call in the RFC to not advertise things you can't forward to >> also provides some level of wiggle room that the best route in the Routing >> Table is what should be redistributed: >> : A route SHALL NOT >> : be installed in the Adj-Rib-Out unless the destination, and NEXT_HOP >> : described by this route, may be forwarded appropriately by the >> : Routing Table. >> >> Anyway, the text is sloppy and discussions about how redistribution is done >> and whether that is shown in the Loc-Rib view or as an override to the >> rib-out manifests in discussions in things like BMP or the Yang modules. >> It's still not as cleanly settled as it should be. >> >> Offering my opinion on this abstract model, I've tended to think about a >> better route in the Routing Table (e.g. a static route with a better admin >> distance/preference) as being selected into the Loc-Rib by considering it a >> route injected via a virtual Adj-Rib-In. But that's just my personal >> justification. >> >> ---- >> >> Juniper's implementation roughly works like the following. Since it's >> derived from GateD heritage, many similar implementations will behave in a >> similar fashion. >> >> In a single routing table, there is a total ordering on all contributors to >> a given destination. >> >> The highest level of ordering is "preference", which roughly corresponds to >> admin-distance. >> >> When routes are BGP routes, the BGP routes are ordered based largely on >> standard RFC rules. The deviations from those rules are the usual vendor >> deviations from standards based on when the later standards were published, >> and the mix of features the operator wants. Examples of deviations are >> whether RFC 5004 is used for temporal vs. router-id based deterministic >> tie-breaking. >> >> BGP routes vs. non-BGP routes are not directly comparable, even when they >> have the same preference, but we have criteria that permits them to be >> selected deterministically. >> >> For non-BGP routes vs. non-BGP routes of two different protocols, we >> similarly will select things deterministically, but may be willing to use >> particular properties of the routes that may be comparable; e.g. metric. >> >> Much of this process is documented here: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junos_topics_reference_general_routing-2Dprotocols-2Daddress-2Drepresentation.html&d=DwIBAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=-dwyFCMbZS-tuTtu3oL1HNFBH-2mpqRlUm9F7wDkv6g&s=R7AEen-1wMEbbOC4rK4EjfOnMRVPTfQpMnYKMWKGmAA&e= >> >> For the described scenarios in draft-chen-bgp-redist, JUNOS doesn't have >> determinism issues. >> >> In our more recent multi-threaded BGP mode, we at one point in the design >> had an issue somewhat related to the one described in the draft. In our >> implementation, we address the issue by always making the Routing Table and >> the BGP thread always exchange the best route in the local total-ordering. >> >> -- Jeff > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr
- [Idr] draft-chen-bgp-redist - A Juniper Perspecti… Jeffrey Haas
- Re: [Idr] draft-chen-bgp-redist - A Juniper Persp… Robert Raszuk
- Re: [Idr] draft-chen-bgp-redist - A Juniper Persp… Enke Chen
- Re: [Idr] draft-chen-bgp-redist - A Juniper Persp… Jeff Tantsura
- Re: [Idr] draft-chen-bgp-redist - A Juniper Persp… Jeffrey Haas
- Re: [Idr] draft-chen-bgp-redist - A Juniper Persp… Jeffrey Haas
- Re: [Idr] draft-chen-bgp-redist - A Juniper Persp… Jeff Tantsura