Re: [MBONED] Continued Review of multicast-yang-model

["Holland, Jake" <[e-mail]>]

Hi Sandy,

From: "[e-mail]" <[e-mail]>
> Date: Sat,2021-05-08 at 1:49 AM
>
> 2.
> In 3.2/3.3, the multicast-keys list seems to be a problem, especially with
> respect to vni-type and vni-value, because there's only 3 possibilities for
> virtual-type (vxlan, nvgre, and geneve), but a value is required in order
> to have it as a key.  Likewise, I'm not sure the vpn-rd and vni-value make
> sense for all (S,G)s, do these have a value?  (What about in a traditional
> PIM network?)
>
> Would it make sense to use a type that permits these to be blank where
> appropriate?
> Sandy> Yes. If these keys are not used, it can be set to blank or zero.

OK, thanks.  I think in that case something in the doc needs to explain
the semantics of setting these values to values that indicate "unused",
because I don't think it's obvious that 0 is meant to be an invalid
vni-value for all virtual-types, and if it's intended that virtual-type
be possible to have set to a value indicating "not using any", it
probably needs a "none" value or something in the enumeration.  (I think
because it's part of the key in the list, an entry that leaves it unset
would get an error, and it's not at all clear to me which of vxlan, nvgre,
or geneve should be used if my network has none of those.)

> 4.
> In section 3.3, there are a lot of grammar problems.  I'll list some of
> them here, do you need text suggestions for these?
> Sandy> Much appreciate if you make some suggestion for these. :-)

I think I'm going to defer that for a later version of the draft after
I understand a little more about it, since for some of these I'm not
quite sure what the text means to say.  But I'll try to keep it in mind
as guidance for next time.

> 5.
> In section 3.3, I was confused by this bit:
>
>    ... One or
>    several transport technologies could be defined at the same time.
> 
> What does it mean if several transport technologies are defined at
> the same time, are those for redundant paths or something?
>
> Likewise this about the underlay:
>
>     ... One or several underlay
>    technologies could be defined at the same time if there is protective
>    requirement.
>
> By "protective environment" do you mean a redundant setup that can
> forward the traffic through multiple paths?  (And if so, what if the
> redundant paths use the same type of underlay?  Or if not, what does
> it mean?)
> Sandy> Yes. But I am not sure if these usage is existed actually. Do you think it's better to only keep one for it?

I think I like the idea of being able to express that there is
redundancy in the underlay and/or the overlay, that seems like a
helpful feature to support. 

But I think if you want to support it, the semantics probably have
to be clearer than just allowing multiple values of different types
to co-exist, the way it is now.  I think it's possible for instance
to have a backup path that uses multiple different OSPF underlay
instances, and I'm not sure why that would get a different treatment
than having one path using ISIS and another path using OSPF.

Maybe put only one overlay and only one underlay in a container,
and then have those inside a list?  (Maybe the list could be named
something like "transport-networks" or "paths" or something?). Or
maybe it makes more sense to have a list of underlays and a list of
overlays that refer to the underlays they can operate over?  (And
then the typical case is just one, but anything can be expressed.)

If that's the use case it also might make sense to specify something
like "active/passive" enum mentioning the intended usage?  Or a list
of active path references?  Just an idea.

Anyway, I'm not completely sure whether it's needed, since I think
there's still some things about how this model is used and what the
expected effects are for the network, but I can imagine that having
a preconfigured active/passive redundancy setup could make a
difference in failover convergence time that might be important for
some use cases, so I guess if the details of the protocols used in
the underlay and overlay are necessary in this model, it seems like
it would also be a good idea to allow for configuring the failover.

But it also might be possible to do that with a separate controller
instance that's configured as passive, and have only one underlay
and only one overlay at the model layer.

I'm not sure which way is best, I think it probably depends on
some details of how this should be used that I'm not sure I fully
understand yet.  But my rough guess is that of those 2 options, it's
better to represent multiple backup path options as a list of multiple
objects that each use a single unambiguous way to define the config,
rather than the current structure that allows multiple overlays and
underlays, but only of different types with no hints about what's
primary or backup and whether it's active and whether different
overlays (if multiple ones are configured) are running on all or
only some of the different underlays (if multiple ones are configured),
which seems to add a lot of confusing options that are legal configs.

Anyway, I hope those comments have some useful food for thought, and
I'll try to give this another look at in a later version.  I'll be
especially interested to see the examples and the descriptions of
how they affect the network when applied to the server.

Thanks and regards,
Jake