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

[Toerless Eckert <[e-mail]>]

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

On Tue, May 18, 2021 at 05:41:00PM +0800, [e-mail] 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.