Re: [Idr] Opsdir last call review of draft-ietf-idr-rfc7752bis-13
Gyan Mishra <hayabusagsm@gmail.com> Fri, 18 November 2022 01:15 UTC
Return-Path: <hayabusagsm@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 A6A05C14CF1B; Thu, 17 Nov 2022 17:15:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.084
X-Spam-Level:
X-Spam-Status: No, score=-7.084 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 frbHv8S5lqrm; Thu, 17 Nov 2022 17:14:59 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 6C279C14F746; Thu, 17 Nov 2022 17:14:59 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id z6so2298601qtv.5; Thu, 17 Nov 2022 17:14:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1oEMiEbg8buMLjMhHTVFtYd5z7ncqxULdrQXD9rSj0o=; b=DlVPRSLtIXshbp59cs6eQ8VjCAchoIX08kr6Mz9OPuWl5N4+gCEhod+7sBs7WTlIMA w8P7fil7ihrUuPFtjmgmtDB/ja4SY1ptKi/iahPh6gZ7hUZ+60xGbQTLomjjT3Xwl1PG K/PvMT9B2ONsjfYO381OK3ziklVVQTn12MiaJOhLfQdVF13X+DYCdd1r46nownCHbewM 13GEhrLbXywlF2cPWueH8Qlvya3jdQ10DsdiYv3auXQlBLHaAG91+4ErEq+p6SM4GVdi sJVycvXe3EPP0fRXmCyftO3IZDzUsWo8Dw+7xzLJqTHv6FJv0NA1x2UUAo7bBOJyMVdt BITQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=1oEMiEbg8buMLjMhHTVFtYd5z7ncqxULdrQXD9rSj0o=; b=SlHxMJ7EzEC0FnAqhFN2h77FVfzRxxYglh759e6URTBqGpW7Enw5IWjB1rSgp8ZDpH tr6zhvbSxbU3K2DGzuoXr9nFkSpP7+M4OeknMcpnm1fQGjDvJEa1F5r0r4etGYqej0Rm 7twm/G4uBfXAJuuNQiQyM9ZxmtCob0QcU6/2HVG3DUtmkVUKcfN+RuEYjKvijjkHb7Rh Fk196gvTr5OXytGbcGmwccBjw4sVMDGkj6X7Y9hufeZORh04X5LqtW9M1U56hFUQQBya 2QjPoodPjrhEMVJfSezVp6ICuvhCEe5X+I+o5j2jBEMJ884gXKzFRsxlgPc94pZqZ588 OKQA==
X-Gm-Message-State: ANoB5pmKkkJDpMfgsi4W7duBmyB60zbReeCEVWBOgIvxJP57FVLNHN0N KkfyrJd4PW+BTbyW27hfKPrD2qOO82chkHDeWBg7/4q/bzE=
X-Google-Smtp-Source: AA0mqf4PrFsjf14kdIMIgsbd1XIggaUIg0RRcLpMpwSpIBOe9LQik1rDrzhCyLaILD8asJuXgD6v6RIPrkE+MIM+aiI=
X-Received: by 2002:ac8:7312:0:b0:3a5:3628:4304 with SMTP id x18-20020ac87312000000b003a536284304mr4674384qto.517.1668734098128; Thu, 17 Nov 2022 17:14:58 -0800 (PST)
MIME-Version: 1.0
References: <166853127826.27308.14883176524823344383@ietfa.amsl.com> <CAH6gdPw6z21yPEVweMqtazTceLE2arRtHZT_tf0to-w-+F7nHQ@mail.gmail.com> <CABNhwV3wwJA+ckKYnCaD0vr+7hce65QSeqbt9tnaSHPbvPtm7A@mail.gmail.com> <CAH6gdPzaOSLDZVXe2AxMrSFSxphgLFbXQhTH0e89r9GYRybFsw@mail.gmail.com> <CABNhwV2iLjzcoOPnCwjOGW8XMQHZaqvSQAMts+D7QKLUWbP=Zg@mail.gmail.com> <CAH6gdPxWDfYT8tzk94vyeM46KH5KUSjg5h8aV6rmKMz6tbzTDg@mail.gmail.com>
In-Reply-To: <CAH6gdPxWDfYT8tzk94vyeM46KH5KUSjg5h8aV6rmKMz6tbzTDg@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 17 Nov 2022 20:14:46 -0500
Message-ID: <CABNhwV3r6Eh70UP661GrXsCjCp_5fpNW7X6wiP+jTpvpbtWB8g@mail.gmail.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: draft-ietf-idr-rfc7752bis.all@ietf.org, idr@ietf.org, last-call@ietf.org, ops-dir@ietf.org
Content-Type: multipart/alternative; boundary="00000000000024c22405edb46fd4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nED5PyPfhclg5NOf_v06MCF3lUA>
Subject: Re: [Idr] Opsdir last call review of draft-ietf-idr-rfc7752bis-13
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: Fri, 18 Nov 2022 01:15:03 -0000
Hi Ketan See in-line Gyan3 I am all set. The document is ready for publication. Excellent work! Gyan On Thu, Nov 17, 2022 at 10:00 AM Ketan Talaulikar <ketant.ietf@gmail.com> wrote: > Hi Gyan, > > Please check responses inline below with KT3. > > On Thu, Nov 17, 2022 at 8:37 AM Gyan Mishra <hayabusagsm@gmail.com> wrote: > >> >> Hi Ketan >> >> Responses in-line >> >> Thanks >> >> Gyan >> >> On Wed, Nov 16, 2022 at 1:59 AM Ketan Talaulikar <ketant.ietf@gmail.com> >> wrote: >> >>> Hi Gyan, >>> >>> I am trimming to only retain the open points below. Please check inline >>> with KT2. >>> >>> On Wed, Nov 16, 2022 at 8:33 AM Gyan Mishra <hayabusagsm@gmail.com> >>> wrote: >>> >>>> >>>>>> I don’t think this is mentioned in the draft but I think it’s >>>>>> important related >>>>>> to the number of BGP-LS NBI peers necessary and the two options where >>>>>> the NBI >>>>>> could be to a controller or multiple controllers within the same AS >>>>>> for >>>>>> redundancy as well as the NBI could be a dedicated PCE router SBI >>>>>> that also >>>>>> share the NBI and having redundancy for router or controller and at >>>>>> least two >>>>>> peerings. As well as mention that it is not necessary for the NBI >>>>>> exist to all >>>>>> PEs and only one NBI to one PE in the AS at a minimum but better to >>>>>> have at >>>>>> least 2 for redundancy. As well as the NBI can be setup iBGP and the >>>>>> RR can >>>>>> double up as PCE/BGP-LS node SBI & NBI or you can have the controller >>>>>> or router >>>>>> SBI/NBI sitting in a separate AS and eBGP multihop to two PEs NBI >>>>>> session for >>>>>> redundancy. >>>>>> >>>>> >>>>> KT> I am not sure that I understand what exactly is meant by NBI here. >>>>> The document only talks about BGP. The interface/API between a BGP Speaker >>>>> and (consumer) applications is out of scope - whether it be an "external" >>>>> northbound API (e.g., via REST) or something "internal" IPC within a >>>>> router/system. >>>>> >>>>> >>>> Gyan> I was referring to the NBI as the SDN / PCE controller or >>>> router which in the draft is the consumer peering to the PE being the >>>> producer. >>>> >>> >>> KT2> I am sorry, but your use of the term NBI is still not clear to me >>> and there is no such term in the document. The discussion would be a lot >>> easier if you were to use the terms in the documents. For now, I will >>> assume that whenever you say "consumer" you are referring to the BGP-LS >>> Consumer as defined in Sec 3 of the document. If this is not your >>> intention, then is it possible for you to rephrase your comment? >>> >>> >> Gyan2> Let me try again with correct semantics >> >> As Alvaro mentioned we definitely need a drawing here describing the >> roles as it’s very confusing >> > > KT3> There is Figure 1 which is being referred to and Alvaro's review > comments have been addressed. > > >> >> I was referring to the NBI as the SDN / PCE controller or router which >> in the draft is the BGP-LS consumer peering to the PE being the BGP-LS >> producer. So I am referring to the BGP-Las producer to BGP-LS consumer >> peering but the BGP-LS producer side of the peering and how to configure >> the BGP-LS producer side I think should be in scope as far as redundancy >> and having at least 2 producers PE nodes peering to the consumer as a best >> practice. Also that each PE BGP-LS producer does not need to peer to the >> BGP-LS consumer but at least 2 minimum for redundancy. >> > > KT3> Doesn't the text we discussed further below to be added in Sec 8.1.1 > cover all this? Those are operational guidelines. > Gyan3> Yes it addresses all set here > > > >> I am referring to the BGP peering BGP-LS consumer design aspects and >> not the BGP-LS application consumer which is out of scope - agreed. Please >> review above related to BGP BGP-LS Consumer which is relevant as their are >> a bunch of ways to configure the BGP BGP-LS consumer colocated on the RR or >> dedicated router in the domain or could be setup a BGP-LS consumer node >> that eBGP connects to the domain and so sits in a separate AS and could be >> eBGP multihop peering to remote producer PE or direct eBGP peeing to the >> BGP-LS producer PE. >> > > KT3> Agreed. There are N ways to design BGP peerings. This standards track > document does not aim to capture them. > > Gyan3> Understood > >> >> So I am referring to the producer to consumer peering >>>> >>> >>> KT2> BGP-LS Consumer is not a BGP Speaker and the interface to such >>> consumer is outside the scope of this document. >>> >> >> Gyan2> This paragraph is confusing as it refers to consumer as two >> different contents an BGP-LS application consumer and a BGP-LS BGP Consumer >> > > KT3> You seem to be introducing two new terms for consumers which are not > there in the document. > > >> >> BGP-LS Consumer: The term BGP-LS Consumer refers to a consumer >> application/process and not a BGP Speaker. >> >> >> Gyan2> So here we are saying application/process meaning API driven / Netconf >> >> or SDN or BGP or other controller based mechanism? >> >> > KT3> Consumer is an application that is outside of the BGP/BGP-LS > functional block which this document specifies. So it is not part of BGP > (which is IDR WG scope) and could be anything else. > > Gyan> Understood > >> Which node is RR1 and which is Rn and are they both route reflectors >> >> > KT3> As the name and description suggest, the nodes with "RR" in their > names are route reflectors. > > Gyan3>That’s what I thought > >> The BGP Speakers RR1 >> and Rn are handing off the BGP-LS information that they have >> collected to a consumer application. >> >> >> Gyan2> It sounds like there is a BGP component to the BGP-LS consumer and a application >> >> Component. >> >> > KT3> No. There is no BGP peering/interface to a BGP-LS consumer (it is > some app). > Gyan3> Got it. All set > > >> >> Rn is the BGP-LS producer node, what is RR1, is or the BGP-LS consumer BGP implementation in scope ? >> >> >> The BGP protocol >> implementation and the consumer application may be on the same or >> different nodes. >> >> >> Gyan> So here there are 2 components a BGP component and a application component >> >> And they can be on same node or different nodes >> >> > KT3> Yes > > >> >> This document only covers the BGP >> implementation. >> >> >> Gyan3> So here the BGP component is in scope - you agree >> >> >> So to reiterate the BGP-LS Consumer “BGP component” is in scope, correct? >> >> > KT3> No. Please see my previous responses. > > Gyan3> Got it now thanks > >> The consumer application and the design of the >> interface between BGP and the consumer application may be >> implementation specific and are outside the scope of this >> document. >> >> >> Gyan> So only the BGP-LS Consumer “application component” is out of scope >> >> >> The communication of information is expected to be >> unidirectional (i.e., from a BGP Speaker to the BGP-LS Consumer >> application) and a BGP-LS Consumer is not able to send information >> to a BGP Speaker for origination into BGP-LS. >> >> >> Gyan> Bundling these two together into one role makes it >> very confusing. >> > > KT3> There is no such "bundling" in the text. > > Gyan3> Understood. > >> I think BGP-LS Consumer Application should be decoupled into separate >> role so that the BGP-LS Consumer would be in scope. >> >>> >>> >>>> but the producer side of the peering and how to configure the producer >>>> side I think should be in scope as far as redundancy and having at least 2 >>>> producers PE nodes peering to the consumer as a best practice. Also that >>>> each PE producer does not need to peer to the consumer but at least 2 for >>>> redundancy. I am referring to the BGP peering consumer design aspects and >>>> not the application consumer which is out of scope - agreed. Please review >>>> above related to BGP Consumer which is relevant as their are a bunch of >>>> ways to configure the BGP consumer colocated on the RR or dedicated router >>>> in the domain or could be setup a consumer node that eBGP connects to the >>>> domain and so sits in a separate AS and could be eBGP multihop peering to >>>> remote producer PE or direct eBGP peeing to the producer PE. >>>> >>> >>> KT2> If your point is to capture redundancy aspects of the BGP-LS >>> deployment design, we can perhaps add the following text in Sec 8.1.1. >>> >>> It is RECOMMENDED that operators deploying BGP-LS enable at least two >>> >>> or more BGP-LS Producers in each IGP flooding domain to achieve >>> >>> redundancy in the origination of link-state information into BGP-LS. >>> >>> It is also RECOMMENDED that operators ensure BGP peering designs that >>> >>> ensure redundancy in the BGP update propagation paths (e.g., using at >>> >>> least a pair of route reflectors) and ensuring that BGP-LS Consumers are >>> >>> receiving the topology information from at least two BGP-LS Speakers. >>> >>> >>> >>>> Gyan> perfect! >>>>> >>>>> >> >>>>>> In cases of migration where you have full overlay any permutations of >>>>>> MPLS, >>>>>> SR-MPLS, SRv6 and the core is dual stacked and not single protocol >>>>>> and so you >>>>>> have a dual plane or multi plane core the caveats related to the NBI >>>>>> BGP-LS >>>>>> peering and that you should for redundancy 2 NBI peers per plane for >>>>>> example >>>>>> IPv4 peer for SR-MPLS IPv4 plane NabI and IPv6 peer for SRv6 plane >>>>>> NBI. >>>>>> >>>>> >>>>> KT> Please see my previous response clarifying the AFI for BGP-LS. As >>>>> such, I don't see how MPLS/SR-MPLS/SRv6 makes any difference here. >>>>> >>>> >>>> Gyan> Agreed. Here I was trying to give an example of a migration >>>> scenario where you have multiple planes, ships in the night and how best to >>>> configure the BGP LS peering producer to BGP consumer which is in scope. >>>> So I think this can be a very relevant scenario that should be included in >>>> the draft. >>>> >>> >>> KT2> The choice of IPv4 or IPv6 for BGP-LS sessions has no impact on the >>> topology information that is being carried in BGP-LS updates. >>> >> >> Gyan> Understood. My point here is the redundancy aspects similar to >> every domain having two BGP-LS producers but in this case we have to plane >> so having 2 producers per plane. Also as you pointed out I think we should >> have verbiage to state that the choice of IPv4 or IPv6 peer has no impact >> on the topology information produced will be for both plane provided by the >> IPv4 peer providing the IPv4 and IPv6 plane topology graph and IPv6 peer >> providing the as well the same IPv4 and IPV6 topology. >> > > KT3> This is already covered in sec 5.5. > > Gyan> Understood > I wonder in that case within a single domain you could have 1 peer on IPv4 >> and 1 peer on IPv4 and not need 2 per plane and that is sufficient >> redundancy. That should be spelled out as that is very common for >> operators migrating from SR-MPLS to SRv6 and having the dual plane setup. >> > > KT3> There is no need for this document to refer to either SR-MPLS or SRv6 > since they are not relevant here. > > Gyan> Understood > >> New comment >> >> The purpose of the BGP-LS propagator is very confusing and I think we >> definitely need a diagram to lay out the topology and all the device roles. >> > > KT3> That is what Figure 1 is for. > > Gyan> In the diagram is it possible to label the role names > >> BGP-LS consumer has decide RR1 and Rn >> >> BGP-LS producer has device RRm >> >> BGP-LS propagator >> > > KT3> Sorry, but I do not understand the statements above. > Gyan> I was trying to map the node name to role name - if you can add the roles to figure 1 would help > > > >> The BGP Speaker RRm propagates the BGP-LS >> information between the BGP Speaker Rn and the BGP Speaker RR1. >> >> > KT3> Yes > > >> >> So the BGP-LS propagator is the Route Reflector ? >> > > KT3> Yes > > >> >> With BGP-LS it’s just one way propagation that the producers propagate >> BGP-LS state to the BGP-LS Consumer BGP implementation in scope so why >> would there be any propagation feedback to the BGP-LS producer PE nodes. >> > > KT3> That is how BGP works. A policy can be created to prevent > advertisements from propagating to BGP speakers that may not be interested > in the information. > > Thanks, > Ketan > > >> >> I think once the drawing is created that will help tremendously. >> >>> >>> Thanks, >>> Ketan >>> >>> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* >> >> >> >> *M 301 502-1347* >> >> -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [Idr] Opsdir last call review of draft-ietf-idr-r… Gyan Mishra via Datatracker
- Re: [Idr] Opsdir last call review of draft-ietf-i… Ketan Talaulikar
- Re: [Idr] Opsdir last call review of draft-ietf-i… Gyan Mishra
- Re: [Idr] Opsdir last call review of draft-ietf-i… Ketan Talaulikar
- Re: [Idr] Opsdir last call review of draft-ietf-i… Gyan Mishra
- Re: [Idr] Opsdir last call review of draft-ietf-i… Ketan Talaulikar
- Re: [Idr] Opsdir last call review of draft-ietf-i… Gyan Mishra
- Re: [Idr] Opsdir last call review of draft-ietf-i… Ketan Talaulikar
- Re: [Idr] Opsdir last call review of draft-ietf-i… Gyan Mishra
- Re: [Idr] Opsdir last call review of draft-ietf-i… Ketan Talaulikar
- Re: [Idr] Opsdir last call review of draft-ietf-i… Gyan Mishra