[Idr] Re: draft-smn-idr-inter-domain-ibgp

Robert Raszuk <robert@raszuk.net> Thu, 20 June 2024 16:57 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 1E8F8C14F610 for <idr@ietfa.amsl.com>; Thu, 20 Jun 2024 09:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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=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 LyG--GSpLgJ4 for <idr@ietfa.amsl.com>; Thu, 20 Jun 2024 09:57:41 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 DA1C8C14F604 for <idr@ietf.org>; Thu, 20 Jun 2024 09:57:41 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-57a4d7ba501so1154972a12.2 for <idr@ietf.org>; Thu, 20 Jun 2024 09:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1718902660; x=1719507460; 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=0vU3uZ0Ba0C+ajpizFM5jCxf+86i8W9avN7kEh/GT1Y=; b=SVEjhq5D8UkeoNZ8ZMGkaV8rx88mjDeyJI1X1W3fjAGwDGTW+vwV0UQZ7hRzU9E5EC pRW2NDy+HjCDc0XMqAPZTlgUDPnm+kUn2IUNrrcP7ASwowETeQtLc4DOCKAypOKXEiVQ 0r91P0X+/Tf6LDDVjgch3/pUeBnfC/y035Q98xtG9s8QSRgsCtYncZmF05tO0VkJKvKz /3ras6YM+GAoVxiyBozX7rCw7T7pyIQNyqAz/yIMm8ZssImG6BtGf/uQCO6KzKqouocM ZNp7l6/4B/vwdLYSjX5zOkQBIdn1GeEyp2p8wab6bESmA1M2v/QgENVi7OyV+6jcEzjR Dm8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718902660; x=1719507460; 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=0vU3uZ0Ba0C+ajpizFM5jCxf+86i8W9avN7kEh/GT1Y=; b=guDQ42WlxZ4uyEEP1k4dzY2lRYTWn7l6yFkcQYmj6t7VrVdeOgxiN14TGTcboUxtOi pN9So2FXMKmP7sfH5MB0VDCKw/rmddqe57mE81bqzG7OfDLWUc6pzyJ2QQ0+aJu6ElOn jaqukGww0tT+Sv7dUCj7xQNHKD1QR4aZpopCfgphQhs4WS9rACS+3DqO8r5JdVUflYIU f2FxZLVNjlKw95aHQbde1xkTKWSvkzpd5ONWEtIZoqtx0SryTS2AJASGyqeE/eWlo3HS 1mET+RC3Bh5GvhrAaGjbqdW1VTP9+/AROseEZfFByzx9XdsYxzI2EKhtNxoGIzQgGRVG F4/w==
X-Forwarded-Encrypted: i=1; AJvYcCUTzqEWPZN/XHzX1D9YI7jmGjh7ze6Mk22L3E+n917PpeAeTDJDqGg/pwuPhSJaykZ9RZhLgWsnntMc3cU=
X-Gm-Message-State: AOJu0YyDQsnbtx5vZj9ddJ+RrxwbipzwxP5bwnycJBbFzcBvVghq8MI5 FKYRr8qhj0Nv/fX/FZ64eHzAa8uMm4g7TzucpdWBPeO1YmGwsSpkhukajHuRiFUi1x+vujf5pDo ZQLeL9qipI8i3ccUTf1cGx5AuT61//+KQfs9Igw==
X-Google-Smtp-Source: AGHT+IF8dQxOJOTX1KEnA0PWD50Cdwv9aag7i119RmNAfXp3O8eZvEuJyQLeDiKCZ3bHZ05lanFAERTCSwjho13Koso=
X-Received: by 2002:a50:a458:0:b0:57c:7eb6:440a with SMTP id 4fb4d7f45d1cf-57d17ceca2bmr2696119a12.3.1718902659606; Thu, 20 Jun 2024 09:57:39 -0700 (PDT)
MIME-Version: 1.0
References: <AS2PR02MB883932457DEB84F94E7AA28AF0D8A@AS2PR02MB8839.eurprd02.prod.outlook.com> <07D43173-DE35-449E-BACA-9EF3AE59D6F5@juniper.net> <1E48D211-2970-4D19-9936-6CAD5B456ED2@juniper.net>
In-Reply-To: <1E48D211-2970-4D19-9936-6CAD5B456ED2@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 20 Jun 2024 18:57:27 +0200
Message-ID: <CAOj+MMFfGmTQbODCyRisp5t56w=R_MG973-GQJU_8tqpM8HdeQ@mail.gmail.com>
To: Moshiko Nayman <mnayman=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006e0578061b553650"
Message-ID-Hash: JYXKWE63GHO4T6AD5Q2YJDID66WNRCTF
X-Message-ID-Hash: JYXKWE63GHO4T6AD5Q2YJDID66WNRCTF
X-MailFrom: robert@raszuk.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Krzysztof Szarkowicz <kszarkowicz@juniper.net>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, idr <idr@ietf.org>, "draft-smn-idr-inter-domain-ibgp@ietf.org" <draft-smn-idr-inter-domain-ibgp@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: draft-smn-idr-inter-domain-ibgp
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/82D5iIzAge27Ja8IEVrB4auMz2s>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

>  cluster-id attribute will be enhanced

The draft does not talk about "enhancing" CLUSTER_LIST attribute.

So I hope your use of word "enhance" is incorrect above.

You are just planning on adding to CLUSTER_LIST new IDs - correct ?

Thx,
R.



On Thu, Jun 20, 2024 at 6:47 PM Moshiko Nayman <mnayman=
40juniper.net@dmarc.ietf.org> wrote:

> Hi Bruno,
>
>
>
> There will be no routing loop because the cluster-id attribute will be
> enhanced so even when four different cluster-id, the loop will be broken.
>
>
>
> In a box topology where each RR is assigned a different cluster-id,
> routing loops will be prevented because each DBR (act as RR) includes its
> own cluster-id when advertising routes to other DBRs. This attribute will
> be enhanced with every advertisement within the box to ensures that when
> one DBR (e.g., DBR1) receives routes from another DBR, it will detect its
> own cluster-id in the received route's cluster list and break the loop.
>
>
>
>
>
> Moshiko.
>
>
>
> Juniper Business Use Only
>
> *From: *Krzysztof Szarkowicz <kszarkowicz@juniper.net>
> *Date: *Friday, October 27, 2023 at 12:52 PM
> *To: *"bruno.decraene@orange.com" <bruno.decraene@orange.com>
> *Cc: *idr <idr@ietf.org>, "draft-smn-idr-inter-domain-ibgp@ietf.org" <
> draft-smn-idr-inter-domain-ibgp@ietf.org>
> *Subject: *Re: [Idr] draft-smn-idr-inter-domain-ibgp
>
>
>
> Hi Bruno,
>
>
>
> Thank you for your review. Please see inline.
>
>
>
> Regards,
>
> Krzysztof
>
>
>
>
>
> On 2023 -Oct-23, at 18:34, bruno.decraene@orange.com wrote:
>
>
>
> Hi authors,
>
>
>
> Thanks for the draft.
>
>
>
> I’ve very quickly had a look at your draft. (so please take those comments
> with a grain of salt)
>
>
>
> Use case looks valid to me. IINM, it can be done today with or without a
> draft (I’m pretty sure at least for a sub-part of the daft 😉 )
>
>
>
> Krzysztof> Indeed, there is (some) information scattered here and there.
> We intend to consolidate, and enhance, where needed.
>
>
>
>
>
> Please find below some proposed comments.
>
>
>
> Avoiding BGP routing loops seems important to me. I would suggest:
>
>    - Duplicating (or factoring) the text in both options (B & C)
>    (currently it’s only described for option B)
>    - Mandating the same cluster-ID with a MUST (currently a SHOULD and I
>    don’t see any reason why someone would want to create a signaling loop.)
>    - Representing two inter-domain BGP signaling paths in all figures so
>    that every reader has a chance to see the loop. (believe me, some people
>    may miss the loop when figures show a single path hence no possibility for
>    loops; while any real network typically has redundant paths/signaling and
>    hence would create loops)
>
>
>
> Krzysztof> That are valid comments. We will enhance in the next revision
> of the draft.
>
>
>
> --
>
> Option C seems essentially the same (or a subset) of
> draft-ietf-mpls-seamless-mpls
>
>
>
> Krzysztof> Indeed. Similar concepts are used.
> However, draft-ietf-mpls-seamless-mpls ihas expired long time ago, and we
> hope to bring draft-smn-idr-inter-domain-ibgp to the RFC, eventually.
>
>
>
> ---
>
> For both option C & B, the loopbacks of the ASBR essentially “carry” a
> large part of the traffic (half of the traffic assuming equal repartition
> of PE/customers across domains). Therefore it would make sense to mark
> those loopback as very high priority during FIB rewrite following an IGP
> convergence. (assuming that the implementation supports multiple/enough
> priorities for FIB prioritization)
>
>
>
> Krzysztof> Ack.
>
>
>
>
>
> § 6. Security Considerations
>
> “Consequently, interfaces facilitating DBR connections where Option B or
> C is implemented should be associated with this newly introduced table
> label.”
>
>
>
> +1 May be I would call for a :s/should/SHOULD to make it real. That been
> said, vendors not implementing this may not agree. Also, what is important
> is the requirement for the isolation, not the solution. So alternatively
> you could refers to RFC4364 which already mention the requirement without
> mentioning a solution.
>
>
>
> “If MPLS is being used as the tunneling technology, this means that a
>
>    router in the backbone MUST NOT accept a labeled packet from any
>
>    adjacent non-backbone device unless the following two conditions
>
>    hold:
>
>
>
>       1. the label at the top of the label stack was actually
>
>          distributed by that backbone router to that non-backbone
>
>          device, and »
>
> https://www.rfc-editor.org/rfc/rfc4364.html#section-6
>
>
>
> Finally, I’d say that the security considerations should probably be
> different for option B & option C. (I don’t see that this “trick” really
> helps for option C)
>
>
>
> Krzysztof> Noted, we will work in security section
>
>
>
>
>
> Regards,
>
> --Bruno
>
> ____________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
> _______________________________________________
> Idr mailing list -- idr@ietf.org
> To unsubscribe send an email to idr-leave@ietf.org
>