Re: [Idr] Regd. https://datatracker.ietf.org/doc/draft-mohanty-idr-secondary-label/
Igor Malyushkin <gmalyushkin@gmail.com> Sat, 12 August 2023 12:39 UTC
Return-Path: <gmalyushkin@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 7B392C15257C for <idr@ietfa.amsl.com>; Sat, 12 Aug 2023 05:39:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, 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=gmail.com
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 xiaRvqZ6IQOL for <idr@ietfa.amsl.com>; Sat, 12 Aug 2023 05:39:01 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 8D17CC1526F4 for <idr@ietf.org>; Sat, 12 Aug 2023 05:39:01 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-5650ec45a7cso1727869a12.3 for <idr@ietf.org>; Sat, 12 Aug 2023 05:39:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691843940; x=1692448740; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0bx0YBk+1ntrTCkVd/l/eR9KXx762D8C+X4GTHZGJbQ=; b=d3U4embh4juUEW4xNxQ0tNMLYHkPLW9QryLUBnp2gh6YhI9J+WGd2INeYcb2XbFcTb RvMIku/DVjj6AUYxBBpJIJp1Fj1N9mKJqYU2EoduIWL97Fe6Lh2/5HLiP8OmXH2YS7LM 8GBa192ed5i0uxFGPsxddqsimV0N/RZRYZb2/5gA63yTwIWDPpEy6Tf+leWy6fNoCh7G ZsI+KVfFkQ94Hdcu4ZNlFH3WCB0KFkhJREXho+CUR/RrCNiO1RGY+HvuguGeKfUCBOE/ djRrDMe5k9uB/BsH/bbiPtUQBSImIEsoeXWCJGPb6NkLoXFkk0a6YiTQZURfY9fGKu1c 0rSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691843940; x=1692448740; 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=0bx0YBk+1ntrTCkVd/l/eR9KXx762D8C+X4GTHZGJbQ=; b=jw2zpL5+T5+Ro1gMRURcX4JAxmZhwluV/hputAv1Xi6KQX/a1Df/kIZgw3tbqSVJs1 +DEzYTkXn5ttSkLcZYKXws4T7IF3o6noRjgv5MJomgdLMaMyzlL5f7ixXiMxGipZJSoq FVHHDjw5pfPdW409icckcvhJOj0oN0t+FljyvN1jUfhmJGumdQoDWAO58U3m9l+MQNoK L91OrikHTxkKEsrQmaaofE7On8X5ShCrBH1D2bEp+3osC2DkvHS+BfK3D+AjHpo4xAuE 0gXCSk94wf0e2ucdB+qI/N4TuvFxeV5W+Uddc0IKvUMQBe9CZlt7PrB/Gc9LSc2k1D5X KvZg==
X-Gm-Message-State: AOJu0YzScvCG5aXC6hIqou0b5YhLO56haeoIEHEc0fDqyzxHfDq24XIS eZWZxiBMQw7YPT29J+0TYrQOg8VwiLTZvedS0dw=
X-Google-Smtp-Source: AGHT+IF9y7pJmRHiqOH5XiIyX4XCQogta16afbwBsYRONTEFBSA5s/bQqYDZhbZcs7SQlO32sVqB9GzXWwHsGsrN3/I=
X-Received: by 2002:a17:90b:3105:b0:263:514:5eda with SMTP id gc5-20020a17090b310500b0026305145edamr2467381pjb.29.1691843940470; Sat, 12 Aug 2023 05:39:00 -0700 (PDT)
MIME-Version: 1.0
References: <40ad79902852443d8783a322dffbab8a@huawei.com> <CH2PR11MB4312EC318A3E8C1667C784ADD431A@CH2PR11MB4312.namprd11.prod.outlook.com> <BY5PR11MB43055C64B2497F586ACB64BED401A@BY5PR11MB4305.namprd11.prod.outlook.com> <CAOj+MMFP+u6UGpTAyvn7KhRww00mmd-iGmHxBnFg9OeGNF-X7Q@mail.gmail.com>
In-Reply-To: <CAOj+MMFP+u6UGpTAyvn7KhRww00mmd-iGmHxBnFg9OeGNF-X7Q@mail.gmail.com>
From: Igor Malyushkin <gmalyushkin@gmail.com>
Date: Sat, 12 Aug 2023 16:38:48 +0400
Message-ID: <CAEfhRrx5oNeW2z4V9pDqs9nSgFzFH6oiK1CCEOf+FQj_DuimsQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "Satya Mohanty (satyamoh)" <satyamoh=40cisco.com@dmarc.ietf.org>, "idr@ietf.org" <idr@ietf.org>, "RAMADENU, PRAVEEN" <pr9637@att.com>
Content-Type: multipart/alternative; boundary="0000000000001653c10602b91d82"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/G2ALWUv3McCeBIxbHWE9Lyb4JGk>
Subject: Re: [Idr] Regd. https://datatracker.ietf.org/doc/draft-mohanty-idr-secondary-label/
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, 12 Aug 2023 12:39:02 -0000
Hello, Robert, Satya, Using different CLUSTER_IDs for inline RRs at the same hierarchy level is common. Especially when there is a labeled unicast underneath. Although, I don't understand why two RRs should be clients to each other instead of regular non-client peers. For PD#1, it is possible to signal LU addresses of PE1, PE2, and both RRs and use them as NHs for VPN prefixes. In this case for labeled unicast prefixes a per-prefix label allocation mode completely solves the problem. For VPN sessions RRs do not apply next-hop-self but act as classical RRs (or even can be unaware of any VPN sessions at all). Classical seamless MPLS approach. With the different CLUSTER_IDs, PIC between the RRs can be maintained also. If we talk about Option B, the solution with LU does not obviously work, but there are several approaches to cope with scaling problems, Option A/B, and Option B/C (draft-zzhang-bess-vpn-option-bc-00). The latest is the new draft that combines a two-labeled approach but does not require new path attributes. For PD#2, here I agree with Robert that it is strange to use internal BGP paths instead of external ones for PIC in that case. What if the ISP1 box goes down? All the traffic will go to the ISP2 box from both PEs anyway. Isn't it wise not to use internal BGP paths for a link failure? Actually, we don't even differentiate a link down even from a node failure. But we are trying to apply different FFR technics there. Also, for a possible loop, does not NFRR from the MNA framework solve this issue at the transport level? My 2 cents. сб, 12 авг. 2023 г. в 15:45, Robert Raszuk <robert@raszuk.net>: > Satya, > > *Reg PD#1: * > > Problem described as PD#1 arises by violation of RFC4456 rules. When your > RRs are part of the same cluster (and here they clearly are) it is > mandatory to use the same CLUSTER_ID on both route reflectors. That will > prevent any reflected routes to get accepted by the other RR client. > > Both these RRs are also clients of each other and advertise VPN routes to each other with the > next-hop set to the peering address. > > > Please do not invent a bandage to heal wounds which should not be self > made in the first place. PD#1 as described is a misconfiguration. > > *Reg PD#2:* > > You say: > > > Failure scenario 2 (FS#2) The links from ISP1 to PE1 and PE2 are down > > at the same time; > > If those two links go down in the same time both PEs should notice it > (optics or BFD) and apply PIC accordingly. PIC on PE1 should result in > shifting traffic to ISP2. So should PIC action on PE2. > > As with PIC the FIB rewrite is prefix independent so no loop should form. > > As you said both ISPs advertise identical set of routes: "Both ISPs > advertise the same 700k prefixes/" > > Only in a situation when you would apply eiBGP multipath there could be > some micr-loop. > > PIC should be smart and ignore IBGP paths (if their local pref is > preferred in steady state) if local EBGP paths exist to heal data plane > during the fast repair. Tnen BGP will converge to the policy > aligned selection of exist. > > Kind regards, > Robert > > > On Thu, Jul 27, 2023 at 9:36 AM Satya Mohanty (satyamoh) <satyamoh= > 40cisco.com@dmarc.ietf.org> wrote: > >> Hi Keyur and the chairs, >> >> >> >> Towards the end of my IETF presentation, the audio was coming garbled at >> my end and not at all coherent. >> >> I went over the recording today. I am replying to the two >> questions/observations. >> >> >> >> 1) Suggestion was given to use another label mode i.e., per-prefix >> (per-vrf does not apply here). However, using per-prefix label allocation >> would result in the inline RRs/ASBRs exhausting their label threshold >> (platform dependent very quickly as the route scale increases (platform >> dependent upper-limit). Therefore, using per-prefix label allocation was >> ruled out in this deployment after being given due consideration. >> >> >> >> Cisco IOS-XR supports the per-nexthop-recvd-label mode for some-time now >> in Option-B ASBR and RR with nh-self use-cases, precisely for this reason. >> I believe other vendors has an equivalent mode. Idea is to take advantage >> of the optimal label allocation by this mode and simultaneously ensure fast >> convergence via BGP PIC. >> >> >> >> 2) Regarding the suggestion of not using the proposed attribute, the >> original thought was to use tunnel-encaps attribute. The problem that I saw >> is that the tunnel-encaps can have many sub-tlvs for different purposes, >> and if we wanted to restrict the advertisement of the secondary label to >> routers that do not need it, it will not be that easy as those same routers >> may need some other TLVs present in that same tunnel-encaps attribute. But, >> we do look forward to getting your inputs/suggestions on this as you >> indicated. >> >> >> >> Thanks. >> >> >> >> Best Regards, >> >> --Satya >> >> >> >> >> >> >> >> *From: *Idr <idr-bounces@ietf.org> on behalf of Satya Mohanty (satyamoh) >> <satyamoh=40cisco.com@dmarc.ietf.org> >> *Date: *Tuesday, July 11, 2023 at 9:44 PM >> *To: *Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org>, >> idr@ietf.org <idr@ietf.org>, MEANS, ISRAEL L <im8327@att.com>, RAMADENU, >> PRAVEEN <pr9637@att.com> >> *Cc: *idr-chairs@ietf.org <idr-chairs@ietf.org> >> *Subject: *Re: [Idr] Call for IETF 117 IDR agenda items >> >> Hi Jie, >> >> >> >> We would like to request a slot of 10 minutes to present the following >> draft. Tuesday slot is preferable. >> >> https://datatracker.ietf.org/doc/draft-mohanty-idr-secondary-label/ >> >> >> >> Thanks, >> >> --Satya >> >> >> >> *From: *Idr <idr-bounces@ietf.org> on behalf of Dongjie (Jimmy) >> <jie.dong=40huawei.com@dmarc.ietf.org> >> *Date: *Tuesday, June 27, 2023 at 3:57 PM >> *To: *idr@ietf.org <idr@ietf.org> >> *Cc: *idr-chairs@ietf.org <idr-chairs@ietf.org> >> *Subject: *[Idr] Call for IETF 117 IDR agenda items >> >> Dear all, >> >> >> >> The draft agenda of IETF 117 is available at >> https://datatracker.ietf.org/meeting/117/agenda. The IDR sessions are >> scheduled as below: >> >> >> >> - Monday Session II 13:00 - 15:00 (local time) Plaza B >> >> >> >> - Thursday Session IV 17:00 – 18:00 (local time) Continental 4 >> >> >> >> Please start to send any IDR agenda item request to me and CC the chairs ( >> idr-chairs@ietf.org). Please include the name of the person who will be >> presenting, and the estimate time you'll need (including Q/A). >> >> >> >> If you plan to make a presentation, please keep in mind the IDR >> tradition, "no Internet Draft - no time slot". You should also plan to send >> your slides to me and CC the chairs no later than 24 hours prior to the IDR >> session, though earlier is better. Please number your slides for the >> benefit of remote attendees. By default your slides will be converted to >> PDF and presented from the PDF. >> >> >> >> Potential presenters may want to take a look at the checklist for >> presenting at IDR: >> >> >> >> >> https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%20at%20an%20IDR%20meeting >> >> >> >> Best regards, >> >> Jie >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >
- [Idr] Call for IETF 117 IDR agenda items Dongjie (Jimmy)
- Re: [Idr] Call for IETF 117 IDR agenda items Gyan Mishra
- Re: [Idr] Call for IETF 117 IDR agenda items Linda Dunbar
- Re: [Idr] Call for IETF 117 IDR agenda items Reshma Das
- Re: [Idr] Call for IETF 117 IDR agenda items Dongjie (Jimmy)
- Re: [Idr] Call for IETF 117 IDR agenda items Chongfeng Xie
- Re: [Idr] Call for IETF 117 IDR agenda items Kaliraj Vairavakkalai
- Re: [Idr] Call for IETF 117 IDR agenda items Dongjie (Jimmy)
- Re: [Idr] Call for IETF 117 IDR agenda items Dongjie (Jimmy)
- Re: [Idr] Call for IETF 117 IDR agenda items gengnan
- Re: [Idr] Call for IETF 117 IDR agenda items Linda Dunbar
- Re: [Idr] Call for IETF 117 IDR agenda items liu.yao71
- Re: [Idr] Call for IETF 117 IDR agenda items Satya Mohanty (satyamoh)
- [Idr] Regd. https://datatracker.ietf.org/doc/draf… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Alexander Okonnikov
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… MEANS, ISRAEL L
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Igor Malyushkin
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Zhuangshunwan
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Kaliraj Vairavakkalai
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Satya Mohanty (satyamoh)
- Re: [Idr] Regd. https://datatracker.ietf.org/doc/… Robert Raszuk