From nobody Fri May 21 07:38:57 2021 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F563A12AE; Fri, 21 May 2021 07:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0Vo-5d_9Xfke; Fri, 21 May 2021 07:38:52 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 9877F3A12A0; Fri, 21 May 2021 07:38:51 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id o5so14598991edc.5; Fri, 21 May 2021 07:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=LtvapuyXiBFjUSBHDVl0/mPkNx/bb292saiLwgAlU/g=; b=fO50PsYRIFncE54geij3hgFZ8+NzW5ZS4Ga5DIycWr/aTciYJI2uFDgcUf6YrhRe2Z Yd+zd7kHvsQ9YxUEkYpLZP8y9bw6lSxiPFExbdQKNZYCmdElCRvFDmjh2tCFWxR80Gma RhywoOqOO5cU+rzbe5ne2mz8HPUUMUGedACU4d3CKuNvREDsLBomq/F32CDnzD7qM+Z6 6ILZifA+uPBfE0cI1hFVTSWBgQyuRrRV16/9dwjLi9ca2qsgM62CljLAsRB+vR/yR1F5 R5nSb5xktWM62z78+iZ6iRzkffWoyGodiFPjWaz1+vMeuviQ9J6GUKNMOBPRE0jXOI4I 97jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=LtvapuyXiBFjUSBHDVl0/mPkNx/bb292saiLwgAlU/g=; b=eTuBR43QX5tnyXsvDSlLNcK8x0ddwkFWq9Pfa79FN1fxuQfW4ILqKTZIMfFiYPdFO5 EEtbE1Mn58EYUHQSWfYXOEwtByORVBmd/h1p/F8txR9L68xbDdKvRH+2G3tqI8AJqX2y OtUzKlt+VQlnP0kgVGpCIlCPZnHlmdIdg4YFIgMspvWIOhTwchUcyrW4WbpvlYByioKg J6hJFchmSu1iS6d4zI/nOAAufq4dHZ64eTkAVJ9i705suMzq2em2v1QAls6/KvICfQsv +pqPU1URmmJ0w8Cr9W40HEGfXZ/KufGYPh/4IIgAGNJ3En19sVcLzPzSDZ014Q/dC60p tN5w== X-Gm-Message-State: AOAM533kpZAUMe0U269DcMaIc9gEWeGB4SLNQ9cmdenySMtnAfHhv1u/ 8eIoCLzihkeZ1WmQfxkXcG2rbvAtj5rgPIaGi4s= X-Google-Smtp-Source: ABdhPJw7DVUVcHqsDvczbY6JMcJ06swaBmTHn5qeqjiyif390ATAUonSdU28fUCiVGwMs7d8RmsEq5f1vxRQtgxvSBk= X-Received: by 2002:a05:6402:5201:: with SMTP id s1mr11637436edd.86.1621607929366; Fri, 21 May 2021 07:38:49 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 May 2021 07:38:48 -0700 From: Alvaro Retana In-Reply-To: <20210518214055.GC5939@faui48e.informatik.uni-erlangen.de> References: <20210518214055.GC5939@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Date: Fri, 21 May 2021 07:38:48 -0700 Message-ID: To: Toerless Eckert Cc: draft-ietf-bier-te-arch@ietf.org, "Gengxuesong (Geng Xuesong)" , BIER WG , BIER WG Chairs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Bier] AD Review of draft-ietf-bier-te-arch-09 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 14:38:55 -0000 On May 18, 2021 at 5:41:00 PM, Toerless Eckert wrote: Toerless: Hi! Just replying to a couple of things. ... > > (1) What is this document specifying? > > > > To start, I believe it is ok for an architecture document to be in the > > Standards Track. > > > > As far as I can see, this document mainly specifies alternate semantics > > for the BitString. Beyond that, the BIER-TE architecture (=C2=A72) maps= well > > onto the layering described in =C2=A74/rfc8297, where the BIER layer (= =C2=A74.2/ > > rfc8297) is "replaced" with the BIER-TE Control Plane and the BIER-TE > > forwarding layer. =C2=A0Is this a fair high-level representation of wha= t is > > defined in this document? > > "replaced" is certainly how the doc is written, so as to make it read > as simple as possible. The intent of course is to "amend" BIER by sharing > as much as possible with it such that a joint BIER/BIER-TE implementation > is but slightly more work than just a BIER implementation. Simplicity is good, but being clear is better. =C2=A0I would like to see a list of the things in the BIER layer that are not replaced. =C2=A0I remember text about the differences -- think of something similar for the things that don't change. ... > > The BIER-TE topology is a "key new component in BIER-TE". The document > > doesn't specify, explain, or leave out of scope how "BIER-TE Controller > > discovers the network topology and creates the BIER-TE topology from it= " > > (=C2=A72.2). This omission is a significant hole in the architecture. > > How about this. As long as it is clear that no references here are > normative, but all informational (like any similar references in RFC8279 > that are all informational too). > > | In statically managed networks, such as in industrial environments, > | topology discovery may be a manual/offline process. In other networks > | topology discovery may rely on protocols such extending the LSP IGP int= o > | the controller itself, RFC7752 (BGP-LS) or RFC8345 (Yang topology) as > | well as BIER-TE specific extensions for example via draft-ietf-bier-te- > | yang. These examples are non-exhaustive. Sure, that works for me. ... > > (2) Can BIER and BIER-TE really coexist in the same network? > > > > The Abstract mentions that they can: > > > > BIER-TE can co-exist with BIER forwarding in the same domain, for > > example by using separate BIER sub-domains. > > > > The result of separate sub-domains is more akin to ships-in-the-night t= han > > having them be "mixed": in the same sub-domain using a single BIFT > > (populated by different sources). Is this correct? > > The way in which the BIER-TE draft defines BIER-TE forwarding, it is > exclusively "owning" a BIFT. This is because the code, e.g.: Figure 15 sh= ows > the bit-reset semantic for all bits to use BIER-TE ([1] vs. [2]). So, wha= t > you call "mixed" is not part of the draft. > > Of course, implementations can easily build a single implementation of > forwarding across BIER/BIER-TE, even with semantic, BIER vs. BIER-TE > different for every bit, but to me this is just implementation optimizati= on. > Reason is that i have not identified good operational benefits to make th= is > part of the BIER-TE architecture. (aka: use case with some bits using bie= r > othre bits in same bitstring using bier-te bit-reset logic). > > However, your ships-in-the night semantic is probably incorrect. > Even BIER alone can already have multiple BIFT per sub-domain, > because according to rfc8279, you need a combination of (sub-domain, bsl) > to map to a BIFT, not just a sub-domain. Does this mean that multiple BIFTs could exist in the same sub-domain, some using only BIER and other only BIER-TE? =C2=A0If so, then that should be the clarification: they can coexist even in the same sub-domain as long as the BIFTs are separate. > Here is suggested text to help clarify: > > | When BIER-TE is used with rfc8296 encapsulation, the bift-id identifies > | an SI, a sub-domain, and a BitStringLength (as specified in rfc8279) AN= D > | whether to use BIER or BIER-TE forwarding for this bift-id. Hmmm...that may be locally true: the local node "knows" how the adjacencies look like and how they were populated, but the BIFR doesn't. =C2=A0Even if the controller programs the encapsulation at the BIFR, the meaning of the BIFT-id field is not changing. =C2=A0I think this text raises more questions. Also, the text above seems to have an implication on BIER: "When BIER-TE is used...AND whether to use BIER or BIER-TE..." ... > > (3) Organization ... > Let me see if i can do the reshuffling without having to completely rewri= te > explanations (stuff was put in order of explanation dependencies). ACK Thanks! Alvaro.