Re: [6lo] instance ID in rfc6775 update

[Tony Przygienda <[e-mail]>]

Yes, we do have discussions over RIFT where it seems a multi-plane or if
you want multi-topology concept as introduced originally in RFC5120 would
be helpful. RIFT can be very easily instantiated on multiple ports and with
that has no problem to run multi-instance/topology but the dataplane
correlation from the leaf would be very helpful. RIFT leaf implementation
is very "thin" and with that architectures that don't rely on either LOC-ID
or BGP overlays become feasible, albeit obviously not @ the scale something
like 2547bis or EVPN can operate.

So in short, I think I support this suggestion fully.

For the practical encoding, I suggest to choose TID=0 as "default
topology", i.e. "what you do today" and avoid an I bit which will cause an
encoding corner case if it's not set but TID<>0?

>From experience, 8 bits is just about enough but 12 bits are plenty for #
of topologies people sometimes think they need on building network
architectures ...

my 2c ...

--- tony

On Thu, Apr 12, 2018 at 7:23 AM, Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Hi again
>
>
>
> A proposed text would be like:
>
>
>
>
>
>    0                   1                   2                   3
>
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   |     Type      |     Length    |    Status     |    Opaque     |
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   |  Rsvd | I |R|T|     TID       |     Registration Lifetime     |
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   |                                                               |
>
> ...             Registration Ownership Verifier                 ...
>
>   |                                                               |
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> ….
>
>
>
> Opaque:
>
>        One-byte Opaque field; this is an octet that ND does not need to
> process
>
>        but that the 6LN wishes the 6LR to pass transparently to another
> process.
>
> I:
>
>        Two-bit Integer: A value of zero indicates that the Opaque field
> carries
>
>        an abstract index that is used to decide in which routing topology
> the
>
>        address is expected to be injected. In that case, the Opaque field
> is
>
>        passed to a routing process with the indication that this is a
> topology
>
>        information and the value of 0 indicates default. All other values
> are
>
>        reserved.
>
>
>
>
>
> Does that work?
>
>
>
> Pascal
>
>
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* jeudi 12 avril 2018 15:40
> *To:* [e-mail]
> *Cc:* Yan Filyurin <[e-mail]>; Tony Przygienda <
> [e-mail]>; [e-mail]
> *Subject:* instance ID in rfc6775 update
>
>
>
> Dear all :
>
>
>
> During a conversation on the RIFT protocol it appeared that there are use
> cases in RIFT to support host mobility with rfc6775-update.
>
> There is a caveat, though, which is in fact common with RPL. Both cases
> need a concept of multi topology routing.
>
> In the case of RPL, the topology is indexed by an instance ID. In the case
> of RIFT, there is a need for an index to a RIB, so one octet is probably
> enough.
>
> A suggestion is thus to use the reserved octet in the ARO to carry an
> instance ID, and use a bit to signal that this is what that field does, in
> case there is a need later to overload it with something else.
>
>
>
> I understand this is coming late in the process; but then there is no
> logic associated to the change, this is just passing on an additional
> information that is useful for more than one candidate protocol.
>
>
>
> Please let me know if there is an issue pursuing this. If there is no
> opposition, my plan it currently to add this in rev-19.
>
>
>
> All the best,
>
>
>
> Pascal
>