Re: [Bier] draft-ietf-bier-bier-yang (was: Re: draft bier yang expired and it needs a bier te branch as well)

Toerless Eckert <tte@cs.fau.de> Tue, 18 May 2021 18:25 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 1717D3A1C52; Tue, 18 May 2021 11:25:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 WfIHJor1d4KJ; Tue, 18 May 2021 11:25:49 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A133A1C4F; Tue, 18 May 2021 11:25:48 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 121F5548017; Tue, 18 May 2021 20:25:42 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0A1064E74E6; Tue, 18 May 2021 20:25:42 +0200 (CEST)
Date: Tue, 18 May 2021 20:25:41 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: bier@ietf.org, chen.ran@zte.com.cn
Cc: aretana.ietf@gmail.com, draft-ietf-bier-te-arch@ietf.org, draft-ietf-bier-bier-yang@ietf.org, bier-chairs@ietf.org, draft-ietf-bier-te-yang@ietf.org
Message-ID: <20210518182541.GB16353@faui48e.informatik.uni-erlangen.de>
References: <20210517180558.GD40483@faui48e.informatik.uni-erlangen.de> <202105181741009543295@zte.com.cn> <20210518180839.GA5939@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210518180839.GA5939@faui48e.informatik.uni-erlangen.de>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/50EMTW4eCcRz21FbiazO4kyuc90>
Subject: Re: [Bier] draft-ietf-bier-bier-yang (was: Re: draft bier yang expired and it needs a bier te branch as well)
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2021 18:25:54 -0000

[resending after mailman rightfully complained about too many recipients. eliminated duplicates]

On Tue, May 18, 2021 at 05:41:00PM +0800, chen.ran@zte.com.cn wrote:
> 3.4 Q: Can someone (authors) please explain what bift-id-base is ? And then put this explanation into the description for that field.
>  Ran:It means bift-id. We will update it.

Still not clear to me, what it means. How does it relate to e.g.: in-bift-id and out-bift-id ?

> The most simple model might be something like this:
>  
>   rename underlay-protocol-type to birt-owner
>  
>   Then add a value "controller" to this field.
>   So, when the value is "controller", then the BIRT is writeable via yang,
>   otherwise it is read-only because it is populated by the protocol
>  Ran:  Agree.

Ok, then next step towards useful/writeable BIRT:

RFC8279/6.3: The "Bit Index Routing Table" (BIRT) is a table that maps from the
BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix of
that BFER, and to the BFR-NBR on the path to that BFER.

These tables are not in the yang model BIRT. I would argue that what the
yang model calls birt is mostly rfc8296 encap information. but not the actual birt.

 +--rw birt* [sub-domain-id]
            +--rw sub-domain-id             uint16
            +--rw bfr-id?                   uint16
       >    +-- rw tbd-resolve-nbr-from-rip
            +--rw birt-bitstringlength* [bitstringlength]
               +--rw bitstringlength    uint16
       >       +--rw bfer* [bfer-id]
       >          +--rw bfer-id
       >             +-- rw bfr-id
       >             +-- rw bfr-prefix
       >             +-- rw bfr-nbr
               +--rw encap* [si]
                  +--rw si                    uint16
                  +--rw in-bift-id?           uint32
                  +--rw bfr-nbr
                     +--rw bfr-nbr               inet:ip-prefix
                     +--rw encapsulation-type?   enumeration
                     +--rw out-bift-id           uint32

I think(hope) this would make it complete:

When a controller (without any IGP) wants to set up BIER, it could do this
by setting up the bfr table for every bfr by setting the bfr-nbr. And then
of course the encap for every nbr. I changed "birt-si" to "encap" for cosmetic
reasons. And of course, when a routing protocol is in control, this info is all RO.

Making the controller set bfr-prefix would not
be required for BIER itself, the BIFT is solely determined from the bfr-nbr
and encap info. But some overlay signaling may want to know the bfr-prefix,
and besides, the bible (rfc8279) says that BIRT includes this info.

Now, there is one IMHO very interesting option where bfr-prefix would be
used by BIER, and that is when the controller would actually not set bfr-nbr,
but only bfr-prefix, and it would be part of the BIRT->BIFT resolution logic
to track the next-hop for bfr-prefix in the RIB and dynamically change
the bfr-nbr based on unicast routing for the bfr-prefix. This setup
would therefore allow to use BIER with _any_ routing protocols, including
any type of static routing/path-engineering, but without the need for any
BIER extensions: All the BIER extensions would be instead configured by
the controller (via bfr-id/bfr-prefix and encap configs).

So, i indicated that option through the maybe binary tbd-resolve-nbr-from-rib
element. Lets say it is binary, and if it is set, then such BIRT->BIFT
logic could be used. Whether or not a vendors BIRT implementation
is decoupled from IGPs such that it is tracking bfr-prefix routes to determine
bfr-neighbor, independent of which protocol sources the route information
for bfr-prefix. I can think of at least one vendor with a very flexible
RIB infra architecure where i would expect this to be true (just guessing).

> 5. Sender-only BFIR
>  
> The BIFT-ID in BIER packet headers is only for the benefit of the BFER,
> and especially overlay stuff. I can imagine, that there can be really good
> usecases of many BIFER, for example sensors delivering packets to fewer
> number of BFIR acting as processing elements. To support this, we
> would set up BIER to maybe only have one SI for up to 256 of such BFER,
> but on the BFIR, we still configure a bfr-id (larger than 256), and
> would also announce it in the IGP so that BFER can map back from bfr-id
> in received packets to the IPv6 or IPv4 identifier of the BFIR.
>  
> So: what would we need to do to ensure that all applications will
> accordingly process bfr-id > (max-si * bsl) in the IGP, but not
> create/waste BIFT space ?

>  Ran???This kind of scenario is uncommon scenario, and I am not sure whether this scenario needs to be considered in the YANG model.

As explained above, it would depend IMHO on the deployment use-case. For
the most common SP use-case it might be not required, yes.

But the main question for the yang model is how we can make it clearer how it
is meant to work: Will it be an error to configure in the yang model a
bfr-id that is larger than (bsl * max-si) ? If we think it should be an
error, how can we codify this in the Yang model ? If we think this is not
an error, how can we codify in he yang model, what the expected behavior
of the system is when this is configured - e.g.: as i outlined above.

I just think we should not let this be underspecified but be very clear.
If implementers have different opinions about the matter, we can introduce
a RO binary yang object that allows implementations to express their
implementation behavior. 

This is just local configuration. he other question of course is what happens
when the IGP receives bfr-id information that is > than locally configured
(max-six * bsl). What should implementations do, and how do we express this.
E.g.: add bfr-id out-of-range notification for example.

> 
> 6. exemplary workflow
>  
> If would be great to add an explanatory chapter outlining a simple
> reference case:
>  
>    This yang model is used to consistently provision the BIER parameters
>    for one or more BIER subdomains across all BFIR/BFR/BFER. This configuration
>    will also be read by BIER enabled IGPs , such as IS-IS with RFC8401  
>    to learn the BIER parameters it needs to know.
>  
>    And then follow up with something like:
>  
>    On a BFR the following parameters from this YANG model need to be
>    configured to enable a BIER subdomain using ISIS with RFC8401 and
>    MPLS encapsulation:
>  
>    (BFR of course not requiring a bfr-id, but for diagnostics purposes of the
>     IGP, highly recommended to assign one - but beyond max-si*bls IMHO...)
>    ...
>  
>    On a BFIR, the following...
>  
>    (BFIR of course requiring a bfr-id, but not necessarily a bit in the BIFT)
>    ...
>  
>    On a BFER, the following...
>    (BFER of course requiring a bfr-id that must have an assigned bit).
>    ...
>  Ran:I will try my best and refer to other RFCs related to the YANG model.

Thanks a lot!

Cheers
    Toerless

> Thanks.