Re: [Last-Call] Opsdir last call review of draft-ietf-idr-rfc7752bis-13
Ketan Talaulikar <ketant.ietf@gmail.com> Thu, 17 November 2022 15:00 UTC
Return-Path: <ketant.ietf@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA1C1524C8; Thu, 17 Nov 2022 07:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level:
X-Spam-Status: No, score=-2.085 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 AgHf8Mea75Cg; Thu, 17 Nov 2022 07:00:33 -0800 (PST)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 256A4C14CF06; Thu, 17 Nov 2022 07:00:33 -0800 (PST)
Received: by mail-oi1-x234.google.com with SMTP id b124so2126843oia.4; Thu, 17 Nov 2022 07:00:33 -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=We1KsOheQYQkt7jg/XKBcvBAxylJ7uRMOa+Sd2AyWn0=; b=pDcpOEfJVG/BfiO6NnrEr6FcLKogaHsHoy0vxSCc0RKl8UpEstiJXtYGNG6lwqI77z pgl/g77fcS8LKPew+POUdBJtNgSGWEsc2GW62hmj9jahWVDjTpBEqdNE34v0DQuyPg4n 4dFHpnp0XhxAv6adQoTRbf9vfMu1OykV/rPeVe/kVpIiFGgM8DBLwsP0l+UC5AO/MkIm eW5JX9S1GqVyNbx3BbLilBCKJgJj/8DQ4//op9xyUPpv6DnWRIduWjNE7Q4B10L7RgDX fi4btzK9RSsw4YDTsfdKXBRU3cVxcNEbpE8qTCJfvPXNSw3i7vT8dK3qt1ImDxN6kQCh ZOgg==
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=We1KsOheQYQkt7jg/XKBcvBAxylJ7uRMOa+Sd2AyWn0=; b=ybx89ZwbHGrrXBs3ZnD1y60IyC5MZovyAt10xbVw0U2mAiYBDMm2quE3HE+5XhL4WL jCRzYriqLdhuYjanydw9Bk264Q/f3oY+P8gh0VLzJkA0pHuP/8ePQ7xGnmhTMATieBKR AxMPKzve96RfbyfhIjUbpUb9S5olJqVrIqEmVn4bA8fKivf8ySa36tKq/zFLmiI5kinV rC+2LKYjFwOkf+gKDEAiDqBSiLB8sfs8n7gQs9bAAqduoCEYDhzRDtMU2tBHn52p3mu/ tgd2x/l4p0kUvFm0y7DXrK6neS2Eyi5pOG3zWKBDWYk7KOS2ru04tu2mrUFCdx9/iRQv gg4w==
X-Gm-Message-State: ANoB5pmOcnSCplwGOm/pmzZqqKXFeu7d9W156fWTTk2QSDZMw6PZDeBM 4DbfvNJV2e8aOKo6SWdEwe3ionbLChwnOLheO1kbmlUbx/8=
X-Google-Smtp-Source: AA0mqf7vJEUyrwxgI66ES2RzZZO5dzzmeCFcoPRbAe3Qmgy+UkY0BKhEqUwEhxvV4xjXvGRW9OlpsyIQsc1PBPv98Yg=
X-Received: by 2002:aca:1c10:0:b0:35a:78ae:d666 with SMTP id c16-20020aca1c10000000b0035a78aed666mr1350965oic.60.1668697232203; Thu, 17 Nov 2022 07:00:32 -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>
In-Reply-To: <CABNhwV2iLjzcoOPnCwjOGW8XMQHZaqvSQAMts+D7QKLUWbP=Zg@mail.gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Thu, 17 Nov 2022 20:30:19 +0530
Message-ID: <CAH6gdPxWDfYT8tzk94vyeM46KH5KUSjg5h8aV6rmKMz6tbzTDg@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@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="000000000000c3681b05edabd9e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/6D3kPf3ocQ6r5xT29qt4RHaKY_g>
Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-idr-rfc7752bis-13
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2022 15:00:37 -0000
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. > 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. > > > 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. > > 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. > > 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). > > 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. > > 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. > > 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. > 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. > > 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. > > 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. > 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* > >
- [Last-Call] Opsdir last call review of draft-ietf… Gyan Mishra via Datatracker
- Re: [Last-Call] Opsdir last call review of draft-… Ketan Talaulikar
- Re: [Last-Call] Opsdir last call review of draft-… Gyan Mishra
- Re: [Last-Call] Opsdir last call review of draft-… Ketan Talaulikar
- Re: [Last-Call] Opsdir last call review of draft-… Gyan Mishra
- Re: [Last-Call] Opsdir last call review of draft-… Ketan Talaulikar
- Re: [Last-Call] Opsdir last call review of draft-… Gyan Mishra
- Re: [Last-Call] Opsdir last call review of draft-… Ketan Talaulikar
- Re: [Last-Call] Opsdir last call review of draft-… Gyan Mishra
- Re: [Last-Call] Opsdir last call review of draft-… Ketan Talaulikar
- Re: [Last-Call] Opsdir last call review of draft-… Gyan Mishra